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