Open Stack

The stuff you are pushing back against are the very same things that other folks are trying to do at a higher level. 

You want control so you can prioritize the things you feel your users are most interested in. Folks in other projects have decided the same. Really, where should the priorities come from?

You are concerned another projects priorities will trump your own. Legitimate. But have you considered, maybe other priorities, not just Nova's actually are more important in the grand scheme of OpenStack? What entity in OpenStack is deciding the operators/users needs get what priorities? Nova currently thinks it knows whats best. Is it really?

I've wanted shared storage for a long long time. But i also have wanted proper secret management, and between the two, I'd much rather have good secret management. Where is that vote in things? How do I even express that? And, to whom?

Yes, I realize shared storage was Cinders priority and Nova's now way behind in implementing it. so it is kind of a priority to get it done. Just using it as an example though in the bigger context.

Having operators approach individual projects stating their needs, and then having the individual projects fight it out for priorities isn't a good plan. The priorities should be prioritized at a higher level then projects so the operators/users needs can be seen in a global light, not just filtered though each projects views of things.

Yes, some folks volunteer to work on the things that they want to work on. Thats great. But some folks volunteer to work on priorities to help users/operators in general. Getting clear, unbiased priorities for them is really important.

I'm not trying to pick on you here. I truly believe you are trying to do the right thing for your users/operators. And for that, I thank you. But I'm a user/operator too and have had a lot of issues ignored due to this kind of governance issue preventing traction on my own user/operator needs. And I'm sure there are others besides me too. Its not due to malice. But the governance structure we have in place is letting important things slip through the cracks because its setup walls that make it hard to see the bigger picture. This email thread has been exposing some of the walls, and thats why we've been talking about them. To try and fix it.

Thanks,
Kevin

________________________________________
From: melanie witt [melwittt at gmail.com]
Sent: Tuesday, August 21, 2018 3:05 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

On Tue, 21 Aug 2018 16:41:11 -0400, Doug Hellmann wrote:
> Excerpts from melanie witt's message of 2018-08-21 12:53:43 -0700:
>> On Tue, 21 Aug 2018 06:50:56 -0500, Matt Riedemann wrote:
>>> 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 in support of extracting placement into its own git repo because
>> Chris has done a lot of work to reduce dependencies in placement and
>> moving it into its own repo would help in not having to keep chasing
>> that. As has been said before, I think all of us agree that placement
>> should be separate as an end goal. The question is when to fully
>> separate it from governance.
>>
>> It's true that we don't have concrete plans for affinity modeling and
>> shared storage modeling. But I think we do have concrete plans for vGPU
>> enhancements (being able to have different vGPU types on one compute
>> host and adding support for traits). vGPU support is an important and
>> highly sought after feature for operators and users, as we witnessed at
>> the last Summit in Vancouver. vGPU support is currently using a flat
>> resource provider structure that needs to be migrated to nested in order
>> to do the enhancement work, and that's how the reshaper work came about.
>> (Reshaper work will migrate a flat resource provider structure to a
>> nested one.)
>>
>> We have the nested resource provider support in placement but we need to
>> integrate the Nova side, leveraging the reshaper code. The reshaper code
>> is still going through code review, then next we have the integration to
>> do. I think things are bound to break when we integrate it, just because
>> nothing is ever perfect, as much as we scrutinize it and the real test
>> is when we start using it for real. I think going through this
>> integration would be best done *before* extraction to a new repo. But
>> given that there is never a "good" time to extract something to a new
>> repo, I am OK with the idea of doing the extraction first, if that is
>> what most people want to do.
>>
>> What I'm concerned about on the governance piece is how things look as
>> far as project priorities between the two projects if they are split.
>> Affinity modeling and shared storage support are compute features
>> OpenStack operators and users need. Operators need affinity modeling in
>> the placement is needed to achieve parity for affinity scheduling with
>> multiple cells. That means, affinity scheduling in Nova with multiple
>> cells is susceptible to races and does *not* work as well as the
>> previous single cell support. Shared storage support is something
>> operators have badly needed for years now and was envisioned to be
>> solved with placement.
>>
>> Given all of that, I'm not seeing how *now* is a good time to separate
>> the placement project under separate governance with separate goals and
>> priorities. If operators need things for compute, that are well-known
>> and that placement was created to solve, how will placement have a
>> shared interest in solving compute problems, if it is not part of the
>> compute project?
>>
>
> Who are candidates to be members of a review team for the placement
> repository after the code is moved out of openstack/nova?
>
> How many of them are also members of the nova-core team?

I assume you pose this question in the proposed situation I described
where placement is a repo under compute. I expect the review team to be
nova-core as a start with consideration for new additions or removals
based on our usual process of discussion and consensus as a group. I
expect there to be members of one group who are not members of the other
group. But all are members of the compute project and have shared
interest in achieving shared goals for operators and users.

> What do you think those folks are more interested in working on than the
> things you listed as needing to be done to support the nova use cases?

I'm not thinking of anything specific here. At a high level, I don't see
how separating into two separate groups under separate leadership helps
us deliver the listed things for operators and users. I tend to think
that a unified group will be more successful at that.

> What can they do to reassure you that they will work on the items
> nova needs, regardless of the governance structure?

If they were separate groups, I don't see why the leadership of
placement would necessarily share goals and priorities with compute. I
think that is why it's much more difficult to get things done with two
separate groups, in general.

I want to reiterate again that the only thing I care about here is
delivering functionality that operators and users need. vGPUs, in
particular, has been highly sought after at a community-wide level, not
just from the compute community. I want to deliver the features that
people are depending on and IMHO, being a unified group helps that. I
don't see how being two separate groups helps that.

-melanie





__________________________________________________________________________
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