Re: [openstack-dev] a common client library
On Thu, Jan 16, 2014 at 1:23 PM, Donald Stufft don...@stufft.io wrote: On Jan 16, 2014, at 4:06 PM, Jesse Noller jesse.nol...@rackspace.com wrote: On Jan 16, 2014, at 2:22 PM, Renat Akhmerov rakhme...@mirantis.com wrote: Since it’s pretty easy to get lost among all the opinions I’d like to clarify/ask a couple of things: - Keeping all the clients physically separate/combining them in to a single library. Two things here: - In case of combining them, what exact project are we considering? If this list is limited to core projects like nova and keystone what policy could we have for other projects to join this list? (Incubation, graduation, something else?) - In terms of granularity and easiness of development I’m for keeping them separate but have them use the same boilerplate code, basically we need a OpenStack Rest Client Framework which is flexible enough to address all the needs in an abstract domain agnostic manner. I would assume that combining them would be an additional organizational burden that every stakeholder would have to deal with. Keeping them separate is awesome for *us* but really, really, really sucks for users trying to use the system. I agree. Keeping them separate trades user usability for developer usability, I think user usability is a better thing to strive for. 100% agree with this. In order for OpenStack to be its most successful, I believe firmly that a focus on end-users and deployers needs to take the forefront. That means making OpenStack clouds as easy to consume/leverage as possible for users and tool builders, and simplifying/streamlining as much as possible. I think 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
Re: [openstack-dev] a common client library
On Thu, Jan 16, 2014 at 5:42 PM, Jesse Noller jesse.nol...@rackspace.comwrote: On Jan 16, 2014, at 4:59 PM, Renat Akhmerov rakhme...@mirantis.com wrote: On 16 Jan 2014, at 13:06, Jesse Noller jesse.nol...@rackspace.com wrote: Since it’s pretty easy to get lost among all the opinions I’d like to clarify/ask a couple of things: - Keeping all the clients physically separate/combining them in to a single library. Two things here: - In case of combining them, what exact project are we considering? If this list is limited to core projects like nova and keystone what policy could we have for other projects to join this list? (Incubation, graduation, something else?) - In terms of granularity and easiness of development I’m for keeping them separate but have them use the same boilerplate code, basically we need a OpenStack Rest Client Framework which is flexible enough to address all the needs in an abstract domain agnostic manner. I would assume that combining them would be an additional organizational burden that every stakeholder would have to deal with. Keeping them separate is awesome for *us* but really, really, really sucks for users trying to use the system. You may be right but not sure that adding another line into requirements.txt is a huge loss of usability. It is when that 1 dependency pulls in 6 others that pull in 10 more - every little barrier or potential failure from the inability to make a static binary to how each tool acts different is a paper cut of frustration to an end user. Most of the time the clients don't even properly install because of dependencies on setuptools plugins and other things. For developers (as I've said) the story is worse: you have potentially 22+ individual packages and their dependencies to deal with if they want to use a complete openstack install from their code. So it doesn't boil down to just 1 dependency: it's a long laundry list of things that make consumers' lives more difficult and painful. This doesn't even touch on the fact there aren't blessed SDKs or tools pointing users to consume openstack in their preferred 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
Re: [openstack-dev] [nova] api schema validation pattern changes
Jay Pipes jaypi...@gmail.com wrote: On Tue, 2014-01-14 at 11:45 +0800, Christopher Yeoh wrote: On Tue, Jan 14, 2014 at 10:59 AM, Jay Pipes jaypi...@gmail.com wrote: We don't need API extensions and they make our Compute API laughably complex and cumbersome. We should ditch entirely the concept of API extensions in our next Compute API major release. I think it way too late in the cycle to make this sort of change for the V3 API. Completely agreed. I never said anything about v3. Specifically, in the tl;dr section I said in the next major API version we should get rid of API extensions. Jay, thank you so much for eloquently articulating my frustrations with API extensions in Nova. I wholeheartedly agree that this is the right path for v4, and I also think that any move to Pecan or validation framework should wait until this time, as well. If it wasn't clear, I was not proposing changing anything to do with the existing v3 API or any of the extensions. I am saying we should get rid of them for the next major version, which would 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're really after -- because I can almost guarantee it's not yet more API extensions. As a deployer, I again agree. -- Jonathan LaCour VP, Cloud DreamHost ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Support for Pecan in Nova
On December 11, 2013 at 2:34:07 PM, Doug Hellmann (doug.hellm...@dreamhost.com) wrote: On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello wrote: 1. It looks like the Nova v3 API is composed *entirely* of extensions (including “core” API calls), and that extensions and their routes are discoverable and extensible via installed software that registers itself via stevedore. This seems to lead to an API that’s composed of installed software, which in my opinion, makes it fairly hard to map out the API (as opposed to how routes are manually defined in other WSGI frameworks). I assume at this time, this design decision has already been solidified for v3? Yeah, I brought this up at the summit. I am still having some trouble understanding how we are going to express a stable core API for compatibility testing if the behavior of the API can be varied so significantly by deployment decisions. Will we just list each required extension, and forbid any extras for a compliant cloud? Maybe the issue is caused by me misunderstanding the term extension, which (to me) implies an optional component but is perhaps reflecting a technical implementation detail instead? After taking a close look at how the API is constructed, I actually think that the current approach of having the API be defined purely through extensions is flawed, for a few reasons: 1. The code is extremely difficult to read and follow, because the API structure is entirely built at runtime based upon what is installed, rather than expressed declaratively in code. 2. As a company providing a public cloud based upon OpenStack, with a desire to express compatibility with the OpenStack API, its difficult to document the standard baseline Nova API. I shouldn't have to say it depends in API documentation. 3. Based upon my read, extensions are in no way quarantined from the the baseline/standard/required API. In fact, they seem to be able to pollute the standard API with additional parameters and functionality. I can not envision a world in which this is sane. In my opinion, a well-designed and architected API should have the core functionality declaratively defined in the code itself, so as to give a good, well-documented, standard, and unchanging baseline. Then, an extension capability should be layered on in such a way that it doesn't alter the core API or serialized data. Note: my opinion isn’t altered by the fact that some of the “core” API involves “required” extensions. The result is still difficult to read and document. That said, I don’t want to diminish or minimize the hard work that has been done on the V3 API thus far! Lots of thinking and heavy lifting has already been done, and its much appreciated. I am just concerned 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
Re: [openstack-dev] Is WSME really suitable? (Was: [nova] Autogenerating the Nova v3 API specification)
James Slagle james.sla...@gmail.com 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 set the renderer in the call to pecan.make_app. This was meant to be a temporary solution until there's better support in WSME. If there is anything I can do on the Pecan side, let me know! Happy to build in new functionality to make this easier, in general. It does seem to make sense to be fixed on the WSME side, though. Best -- - Jonathan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
