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