eferred programming language.
>
> Shipping an API isn't enough - but it can be fixed easily enough.
>
+100
OpenStack must be attractive to our end users (developers and deployers),
as I mentioned earlier. Let's make it as simple as "pip install openstack"
if at all possible!
--
Jonathan LaCour
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
ink that a single, common client project, based upon package
namespaces, with a unified, cohesive feel is a big step in this direction.
--
Jonathan LaCour
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
be v4.
>
> BTW, I challenge you to find deployers that are clamouring for the
> ability to "selectively deploy" some parts of the API and not
> others...I'd be happy to have conversations with these people and figure
> out what the real use cases are and what they'
ncerned that we lost our way somewhere. Major API revisions only
come along so often, and I’d prefer to raise my objections now
rather than to hold them in and regret it!
--
Jonathan LaCour
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
James Slagle wrote:
> WSME + pecan is being used in Tuskar:
> https://github.com/tuskar/tuskar (OpenStack management API)
>
> We encountered the same issue discussed here. A solution we settled
> on for now was to use a custom Renderer class that could handle
> different response codes. You se
