Open Stack

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.toews at 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 at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140117/38f6a178/attachment.html>