Open Stack

On 8/21/2018 4:28 AM, Chris Dent wrote:
> 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.

Regarding microversions I was mostly thinking of the various times I've 
been asked in the placement channel if something warrants a microversion 
or if we can just bug fix it in, like microversion 1.26. I then 
generally feel like I need to be defensive when I say, "yes it's a 
behavior change in the API so it should." That makes me question how 
stringent others would be about upholding interoperability concerns if I 
weren't around. Maybe I'm admittedly too stringent and opt to be 
conservative at times, but I do make exceptions, e.g.:

https://review.openstack.org/#/c/583907/

Suffice it to say I realize "does this need a microversion?" is not 
always an easy question to answer, and I appreciate that you, jaypipes 
and efried at least ask me for my input on the matter. I have obviously 
failed to appreciate that.

> 
> 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)?

If the question is, should nova be talking about solving one problem 
while there are still more unsolved problems? Ideally we should not, but 
that's not the nature of probably anything in openstack, at least in a 
project as big as nova. If it were, the compute API would be 100% 
compatible with volume-backed instances, and shelve wouldn't be such a 
dumpster fire. :) But we don't live in an ideal situation with infinite 
time and resources nor the luxury of forethought at all times so we must 
move forward with *something* lest we get nothing done.

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

I totally agree, and realize there can be an echo chamber within nova 
which can be less than productive. As I noted earlier, I'm not sure the 
entire consumer types for counting qoutas solution is fully thought out 
at this point, so questioning it is appropriate until that's happened.

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

Yup, again I agree with you. I've had more than one reply written in 
this thread where after re-reading it, realized I was being hypocritical 
and deleted my reply (I'm amazed I've had the restraint at times to 
re-read my replies before sending, I'm usually putting my foot in my 
mouth). For example, nova wants consumer types in placement and there 
was pushback on that as convoluting an otherwise minimal consumers API. 
At the same time, nova is actively rejecting people every release that 
want to pass volume type through the compute API during boot from 
volume. Our reason being, "you can already achieve this by calling 
cinder, and our API is already terribly complex, so let's not add fuel 
to the fire." So I realize it goes both ways and I'm trying to keep that 
in mind when replying on this thread.

At this point, I think we're at:

1. Should placement be extracted into it's own git repo in Stein while 
nova still has known major issues which will have dependencies on 
placement changes, mainly modeling affinity?

2. If we extract, does it go under compute governance or a new project 
with a new PTL.

As I've said, I personally believe that unless we have concrete plans 
for the big items in #1, we shouldn't hold up the extraction. We said in 
Dublin we wouldn't extract to a new git repo in Rocky but we'd work up 
to that point so we could do it in Stein, so this shouldn't surprise 
anyone. The actual code extraction and re-packaging and all that is 
going to be the biggest technical issue with all of this, and will 
likely take all of stein to complete it after all the bugs are shaken out.

For #2, I think for now, in the interim, while we deal with the 
technical headache of the code extraction itself, it's best to leave the 
new repo under compute governance so the existing team is intact and we 
don't conflate the people issue with the technical issue at the same 
time. Get the hard technical part done first, and then we can move it 
out of compute governance. Once it's in its own git repo, we can change 
the core team as needed but I think it should be initialized with 
existing nova-core.

I'm only speaking for myself here. Others on the nova core team have 
their own thoughts (Dan, Jay and Mel have all mentioned theirs). The 
rest of the core team probably doesn't even care either way. Except Vek. 
Vek cares *deeply*.

-- 

Thanks,

Matt