On Fri, 28 Sep 2018, melanie witt wrote:
I'm concerned about a lot of repetition here and maintenance headache for
operators. That's where the thoughts about whether we should provide
something like a key-value construct to API callers where they can instead
say:
* OWNER=CINDER
* RAID=10
* NUMA_CELL=0
for each resource provider.
If I'm off base with my example, please let me know. I'm not a placement
expert.
Anyway, I hope that gives an idea of what I'm thinking about in this
discussion. I agree we need to pick a direction and go with it. I'm just
trying to look out for the experience operators are going to be using this
and maintaining it in their deployments.
Despite saying "let's never do this" with regard to having formal
support for key/values in placement, if we did choose to do it (if
that's what we chose, I'd live with it), when would we do it? We
have a very long backlog of features that are not yet done. I
believe (I hope obviously) that we will be able to accelerate
placement's velocity with it being extracted, but that won't be
enough to suddenly be able to do quickly do all the things we have
on the plate.
Are we going to make people wait for some unknown amount of time,
in the meantime? While there is a grammar that could do some of
these things?
Unless additional resources come on the scene I don't think is
either feasible or reasonable for us to considering doing any model
extending at this time (irrespective of the merit of the idea).
In some kind of weird belief way I'd really prefer we keep the
grammar placement exposes simple, because my experience with HTTP
APIs strongly suggests that's very important, and that experience is
effectively why I am here, but I have no interest in being a
fundamentalist about it. We should argue about it strongly to make
sure we get the right result, but it's not a huge deal either way.
--
Chris Dent ٩◔̯◔۶ https://anticdent.org/
freenode: cdent tw: @anticdent
__________________________________________________________________________
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