Mark & Everett, I agree that there's good potential alignment w/ the DefCore data needs. It would be very interesting to know which API calls are required by different client libraries. That would help identify classes of tests for review. We've already captured that as a desired criteria for weighting but I don't know how we're doing to determine that on a test-by-test basis!
Rob From: Mark Collier [mailto:m...@collierclan.net] Sent: Friday, January 17, 2014 4:28 PM To: Everett Toews Cc: openstack@lists.openstack.org; user-commit...@lists.openstack.org Subject: Re: [Openstack] Formulate application developer oriented questions for the user survey Importance: Low Thanks for bringing up the opportunity to expand the survey to gather feedback from end-users (of the API...) Everett. I think this is a great idea, and I was also thinking that as we make progress on the interop efforts with things like DefCore[1][2][3] (and RefStack) that Rob Hirshfeld & others are leading, it's critical that we get input from this class of "user". For example, it would be ideal IMHO to identify which APIs (and underlying functions) are most valued, to inform the list of tests included and ultimately the ones that "must pass". Today there is an optional component in the survey for "deployment" which obviously fits the operator class of "user", so perhaps there is a similar path with more detailed question for the devs targeting the APIs (i.e. deploying apps on openstack clouds, for lack of a better phrase) that includes some kind of feedback mechanism for individual APIs (don't care /nice to have/ must have) as well as related issues like api discoverability. [1] http://robhirschfeld.com/category/clouds/openstack/defcore/ [2] https://wiki.openstack.org/wiki/Governance/DefCoreCommittee [3] http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee On Fri, Jan 17, 2014 at 2:09 PM, Everett Toews <everett.to...@rackspace.com<mailto:everett.to...@rackspace.com>> wrote: On Jan 17, 2014, at 5:45 AM, Gregor von Laszewski wrote: > Everett: > > you may want to add a question such as > > * "Why did you use this library?" That's a good point. One of the things that concerns me about how the questions are worded right now is that they are very reactionary. That's great for finding out the current state of thing but does nothing to inform us on where users want to go in the future and how we can help them get there. They're more "What are you using right now?" not "What will you need in the future?" Asking why will also help reveal requirements. Personally I need to think on this a bit more and take another crack at the questions later. > This may give an additional insight and possibly motivation for further > actions/development. Some examples > > a) in Python the use of libcloud via the EC2 is popular. Why?: compatibility > > b) in the cloudmesh project we developed our own compatibility library that > makes use of the native openstack protocol instead of using lib cloud/EC2 to > access openstack. Why: (1) libcloud/EC2 has limited functionality, (2) > debugging of production clouds with native protocols (starting thousands of > vms), (3) easier integration into user interfaces while leveraging JSON. (4) > Together this allows us to have an API that accesses and manages VMS on AWS, > Azure, and Openstack the same way but uses in case of Openstack the native > protocol instead of lib cloud/EC2. Just out of curiosity, why didn't you contribute to the libcloud project to fill in the missing functionality rather than start your own? Thanks, Everett _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org<mailto:openstack@lists.openstack.org> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
