Open Stack

On Tue, 21 Aug 2018 10:28:26 +0100 (BST), Chris Dent wrote:
> On Mon, 20 Aug 2018, Matt Riedemann wrote:
> 
>> Here is an example of the concern. In Sydney we talked about adding types to
>> the consumers resource in placement so that nova could use placement for
>> counting quotas [1]. Chris considered it a weird hack but it's pretty
>> straight-forward from a nova consumption point of view. So if placement were
>> separately governed with let's say Chris as PTL, would something like that
>> become a holy war type issue because it's "weird" and convolutes the desire
>> for a minimalist API? I think Chris' stance on this particular item has
>> softened over time as more of a "meh" but it's a worry about extracting with
>> a separate team that is against changes because they are not ideal for
>> Placement yet are needed for a consumer of Placement. I understand this is
>> likely selfish on the part of the nova people that want this (including
>> myself) and maybe close-minded to alternative solutions to the problem (I'm
>> not sure if it's all been thought out end-to-end yet, Mel would likely know
>> the latest on this item). Anyway, I like to have examples when I'm stating
>> something to gain understanding, so that's what I'm trying to do here -
>> explain, with an example, what I said in the tc channel discussion today.
> 
> Since we're airing things out (which I think is a good thing, at
> least in the long run), I'll add to this.
> 
> I think that's a pretty good example of where I did express some
> resistance, especially since were it to come up again, I still would
> express some (see below). But let's place that resistance in some
> context.
> 
> In the epic irc discussion you mentioned that one fear is that I
> might want to change the handling of microversions [2] because I'm
> somewhat famously ambivalent about them. That's correct, I am.
> However, I would hope that the fact that placement has one of the
> easier and more flexible microversions systems around (written by
> me) and I went to the trouble to extract it to a library [3] and I'm
> the author of the latest revision on how to microversion [4] is
> powerful evidence that once consensus is reached I will do my utmost
> to make things align with our shared plans and goals.
> 
> So, with the notion of allocation or consumer types (both have been
> discussed): If we start from the position that I've been with
> placement from very early on and am cognizant of its several goals
> and at the same time also aware of its limited "human resources" it
> seems normal and appropriate to me that at least some members of the
> group responsible for making it must make sure that we work to
> choose the right things (of several choices) to do, in part by by
> rigorously questioning additional features when existing planned
> features are not yet done. In this case we might ask: is it right to
> focus on incompletely thought out consumer type management for the
> eventual support of quota handling (and other introspection) when we
> haven't yet satisfied what has been described by some downstream
> people (eglynn is example, to be specific) as job 1: getting shared
> disk working correctly (which we still haven't managed across the
> combined picture of nova and placement)?

On this, my recollection of what happened was that I had a topic for the 
PTG to discuss *how* we could solve the problem of quota resource 
counting by querying placement for resource usage information, given 
that one instance of placement can be shared among multiple nova 
deployments, for example. As we know, there is no way to differentiate 
in placement, which resources Nova A PUT /allocations into placement vs 
which resources Nova B PUT /allocations into placement. I was looking 
for input from the placement experts on how that could possibly be 
supported, how Nova A could GET /usages for only itself and not all 
other Novas. From what I remember, the response was that the idea of 
being able to differentiate between the owners of resource allocations 
was disliked and I felt I had no direction to go forward after the 
discussion, even to do the legwork myself to research or contribute 
support to placement.

I never thought we should *focus* on the lower priority quota handling 
work vs a higher priority item like shared storage support. But I had 
hoped to get some direction on what work or research I could do on my 
own to make progress toward being able to solve my quota problem, after 
a PTG discussion about it.

Not looking for a response here -- just sharing my experience since the 
quota handling discussion was brought up.

>  From my perspective questioning additional features, so that they
> are well proven, is simply part of the job and we all should be
> doing it. If we are never hitting questions and disagreements we are
> almost certainly running blind and our results will be less good.
> 
> Once we've hashed things out, I'll help make what we've chosen
> happen. The evidence of this is everywhere. Consider this: I've
> known (at least subconsciously) about the big reveal in yesterday's
> IRC discussion for a long time, but I keep working to make nova,
> placement and OpenStack better. Day in, day out, in the face of what
> is perhaps the biggest insult to my professional integrity that I've
> ever experienced. If this were a different time some portion of "we"
> would need to do pistols at dawn, but that's dumb. I just want to
> get on with making stuff. The right stuff. Please don't question my
> commitment, but do question my designs and plans and help me make
> them the best they can be.

I hope it is understood that the "reveal" Matt said in yesterday's IRC 
discussion does not represent me or other members of the team. That is 
really something where people would have to speak for themselves.

> Elephant alert, to keep this healthy full exposure rolling: The kind
> of questioning and "proving" described above happens all the time in
> Nova with specs and other proposals that are presented. We ask
> proposers to demonstrate that their ideas are necessary and sound,
> and if they are not _or_ we don't have time, we say "no" or "later".
> This is good and correct and part of the job and helps make nova the
> best it can be given the many constraints it experiences. As far as
> I can tell the main differences between me asking questions about
> proposed placement features when they are presented by nova cores
> and the more general nova-spec situation is who is being subjected
> to the questions and by whom.
> 
>> [1] Line 55 https://etherpad.openstack.org/p/SYD-forum-nova-placement-update
> [2] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-20.log.html#t2018-08-20T20:35:51
> [3] https://pypi.org/project/microversion_parse/
> [4] http://specs.openstack.org/openstack/api-sig/guidelines/api_interoperability.html
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>