Open Stack

On 05/19/2017 07:18 AM, Sean Dague wrote:

> There was a conversation in the Cell v2 discussion around searchlight
> that puts me more firmly in the anti enamel camp. Because of some
> complexities around server list, Nova was planning on using Searchlight
> to provide an efficient backend.
>
> Q: Who in this room is running ELK already in their environment?
> A: 100% of operators in room
>
> Q: Who would be ok with standing up Searchlight for this?
> A: 0% of operators in the room
>
> We've now got an ecosystem that understands how to talk to our APIs
> (yay! -
> https://docs.google.com/presentation/d/1WAWHrVw8-u6XC7AG9ANdre8-Su0a3fdI-scjny3QOnk/pub?slide=id.g1d9d78a72b_0_0)
> so saying "you need to also run this other service to *actually* do the
> thing you want, and redo all your applications, and 3rd party SDKs" is
> just weird.
>
> And, yes, this is definitely a slider, and no I don't want Instance HA
> in Nova. But we felt that "get-me-a-network" was important enough a user
> experience to bake that in and stop poking users with sticks. And trying
> hard to complete an expressed intent "POST /server" seems like it falls
> on the line. Especially if the user received a conditional success (202).

A while back I suggested adding the vif-model as an attribute on the network 
during a nova boot request, and we were shot down because "that should be done 
in neutron".

I have some sympathy for this argument, 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.

Chris