Open Stack

On 05/19/2017 01:38 PM, Dean Troyer wrote:
> On Fri, May 19, 2017 at 11:53 AM, Chris Friesen
> <chris.friesen at 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.

It's fine to have other ways to consume things. I feel like "make
OpenStack easier to use by requiring you install a client side API
server for your own requests" misses the point of the easier part. It's
cool you can do it as a power user. It's cool things like Heat exist for
people that don't want to write API calls (and just do templates). But
it's also not helping on the number of pieces of complexity to manage in
OpenStack to have a workable cloud.

I consider those things duct tape, leading use to the eventually
consistent place where we actually do that work internally. Because,
having seen with the ec2-api proxy, the moment you get beyond trivial
mapping, you now end up with a complex state tracking system, that's
going to need to be highly available, and replicate a bunch of your data
to be performent, and then have inconsistency issues, because a user
deployed API proxy can't have access to the notification bus, and... boom.

You end up replicating the Ceilometer issue where there was a break down
in getting needs expressed / implemented, and the result was a service
doing heavy polling of other APIs (because that's the only way it could
get the data it needed). Literally increasing the load on the API
surfaces by a factor of 10
(http://superuser.openstack.org/articles/cern-cloud-architecture-update/
last graph). That was an anti pattern. We should have gotten to the
bottom of the mismatches and communication issues early on, because the
end state we all inflicted on users to get a totally reasonable set of
features, was not good. Please lets not do this again.

These should be used as ways to experiment with the kinds of interfaces
we want cheaply, then take them back into services (which is a more
expensive process involving compatibility stories, deeper documentation,
performance implications, and the like), not an end game on their own.

> 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.

You can get the behavior. It also has other behaviors. I'm not sure any
user has actually argued for "please make me do more rest calls to
create a server".

Anyway, this gets pretty meta pretty fast. I agree with Zane saying "I
want my server to build", or "I'd like Nova to build a volume for me"
are very odd things to call PaaS. I think of PaaS as "here is a ruby on
rails app, provision me a db for it, and make it go". Heroku style.

	-Sean

-- 
Sean Dague
http://dague.net