On Fri, May 19, 2017 at 11:53 AM, Chris Friesen <chris.frie...@windriver.com> wrote: > ..., but it seems to me that the logical > extension of that is to expose simple orthogonal APIs where the nova boot > request should only take neutron port ids and cinder volume ids. The actual > setup of those ports/volumes would be done by neutron and cinder. > > It seems somewhat arbitrary to say "for historical reasons this subset of > simple things can be done directly in a nova boot command, but for more > complicated stuff you have to go use these other commands". I think there's > an argument to be made that it would be better to be consistent even for the > simple things.
cdent mentioned enamel[0] above, and there is also oaktree[1], both of which are wrapper/proxy services in front of existing OpenStack APIs. I don't know enough about enamel yet, but one of the things I like about oaktree is that it is not required to be deployed by the cloud operator to be useful, I could set it up and proxy Rax and/or CityCloud and/or mtreinish's closet cloud equally well. The fact that these exist, and things like shade itself, are clues that we are not meeting the needs of API consumers. I don't think anyone disagrees with that; let me know if you do and I'll update my thoughts. First and foremost, we need to have the primitive operations that get composed into the higher-level ones available. Just picking "POST /server" as an example, we do not have that today. Chris mentions above the low-level version should take IDs for all of the associated resources and no magic happening behind the scenes. I think this should be our top priority, everything else builds on top of that, via either in-service APIs or proxies or library wrappers, whatever a) can get implemented and b) makes sense for the use case. dt [BTW, I made this same type of proposal for the OpenStack SDK a few years ago and it went unmerged, so at some level folks do not agree this is necessary. I look now at what the Shade folk are doing about building low-level REST layer that they then compose and wish I had been more persistent then.] [0] https://github.com/jaypipes/enamel [1] http://git.openstack.org/cgit/openstack/oaktree -- Dean Troyer dtro...@gmail.com __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev