subject:"\[openstack\-dev\] \[all\] \[nova\] \[placement\] placement below or beside compute after extraction\?"

There have been plenty of cross project goals set forth from the TC and 
implemented by the various projects such as wsgi or python3. Those have been 
worked on by each of the projects in priority to some project specific goals by 
devs interested in bettering OpenStack. Why is it so hard to believe if the TC 
gave out a request for a grander user/ops supporting feature, that the 
community wouldn't step up? PTL's are supposed to be neutral to vendor specific 
issues and work for the betterment of the Project.

I don't buy the complexity argument either. Other non OpenStack projects are 
implementing similar functionality with far less complexity. I attribute a lot 
of that to difference in governence. Through governence we've made hard things 
much harder. They can't be fixed until the governence issues are fixed first I 
think.

Thanks,
Kevin

From: Jeremy Stanley [fu...@yuggoth.org]
Sent: Tuesday, August 21, 2018 4:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [nova] [placement] placement below or beside 
compute after extraction?

On 2018-08-21 22:42:45 + (+), Fox, Kevin M wrote:
[...]
> 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 remain unconvinced that if someone (the TC, the OSF board, the now
defunct product management nee hidden influencers working group)
declared for example that secrets management was a higher priority
than shared storage, that any significant number of people who could
work on the latter would work on the former instead.

The TC has enough trouble getting developers in different projects
to cooperate on more than a couple of prioritized cross-project
goals per cycle. The OSF board has repeatedly shown its members are
rarely in the positions within member companies that they have any
influence over what upstream features/projects those companies work
on. The product management working group thought they had that
influence over the companies in which they worked, but were
similarly unable to find developers who could make progress toward
their identified goals.

OpenStack is an extremely complex (arguably too complex) combination
of software, for which there are necessarily people with very strong
understanding of very specific pieces and at best a loose
understanding of the whole. In contrast, there are few people who
have both the background and interest (much less leeway from their
employers in the case of paid contributors) to work on any random
feature of any random project and be quickly effective at it. If
you're familiar with, say, Linux kernel development, you see very
much the same sort of specialization with developers who are
familiar with specific kernel subsystems and vanishingly few who can
efficiently (that is to say without investing lots of time to come
up to speed) implement novel features in multiple unrelated
subsystems.

We'll all continue to work on get better at this, but hard things
are... well... hard.
--
Jeremy Stanley

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?


On Tue, 21 Aug 2018 17:36:18 -0500, Eric Fried wrote:

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.

Sorry, I'm confused - are we talking about NUMA cells or cellsv2 cells?
If the latter, what additional placement-side support is needed to
support it?


Cells v2 cells. We were thinking about native affinity modeling in 
placement for this one because the single cell and legacy case relied on 
compute calling up to the API database to do one last check about 
whether affinity policy was violated, once the instance landed on 
compute, in a race situation. If the check failed, the build was aborted 
and sent back for rescheduling. With multiple cells and split message 
queues, compute cannot call up to the API database to do the 
late-affinity check any longer (cannot reach the API database via 
message queue). So we are susceptible to affinity policy violations 
during races with multiple cells and split message queues.


If we were able to model affinity in placement, placement could tell us 
which compute host to place the instance on, satisfying affinity policy 
and protected from races (via claiming we already do in placement).


-melanie






__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-21 Thread Jeremy Stanley

On 2018-08-21 22:42:45 + (+), Fox, Kevin M wrote:
[...]
> 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 remain unconvinced that if someone (the TC, the OSF board, the now
defunct product management nee hidden influencers working group)
declared for example that secrets management was a higher priority
than shared storage, that any significant number of people who could
work on the latter would work on the former instead.

The TC has enough trouble getting developers in different projects
to cooperate on more than a couple of prioritized cross-project
goals per cycle. The OSF board has repeatedly shown its members are
rarely in the positions within member companies that they have any
influence over what upstream features/projects those companies work
on. The product management working group thought they had that
influence over the companies in which they worked, but were
similarly unable to find developers who could make progress toward
their identified goals.

OpenStack is an extremely complex (arguably too complex) combination
of software, for which there are necessarily people with very strong
understanding of very specific pieces and at best a loose
understanding of the whole. In contrast, there are few people who
have both the background and interest (much less leeway from their
employers in the case of paid contributors) to work on any random
feature of any random project and be quickly effective at it. If
you're familiar with, say, Linux kernel development, you see very
much the same sort of specialization with developers who are
familiar with specific kernel subsystems and vanishingly few who can
efficiently (that is to say without investing lots of time to come
up to speed) implement novel features in multiple unrelated
subsystems.

We'll all continue to work on get better at this, but hard things
are... well... hard.
-- 
Jeremy Stanley

signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-21 Thread Chris Friesen


On 08/21/2018 04:33 PM, melanie witt wrote:


If we separate into two different groups, all of the items I discussed in my
previous reply will become cross-project efforts. To me, this means that the
placement group will have their own priorities and goal setting process and if
their priorities and goals happen to align with ours on certain items, we can
agree to work on those in collaboration. But I won't make assumptions about how
much alignment we will have. The placement group, as a hypothetical example,
won't necessarily find helping us fix issues with compute functionality like
vGPUs as important as we do, if we need additional work in placement to support 
it.


I guess what I'm saying is that even with placement under nova governance, if 
the placement developers don't want to implement what the nova cores want them 
to implement there really isn't much that the nova cores can do to force them to 
implement it.


And if the placement developers/cores are on board with what nova wants, I don't 
see how it makes a difference if placement is a separate project, especially if 
all existing nova cores are also placement cores to start.


(Note that this is in the context of scratch-your-own-itch developers.  It would 
be very different if the PTL could order developers to work on something.)


Chris



__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

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 [melwi...@gmail.com]
Sent: Tuesday, August 21, 2018 3:05 PM
To: openstack-dev@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 m

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-21 Thread Eric Fried

> The reshaper code
> is still going through code review, then next we have the integration to
> do.

To clarify: we're doing the integration in concert with the API side.
Right now the API side patches [1][2] are in series underneath the nova
side [3].

In a placement-in-its-own-repo world, the only difference would have
been that these would be separate series with a Depends-On linking them,
and would require a placement release. (In fact, with a couple of
additional "placement cores", the API side could have been completed
faster and we might have landed the whole in Rocky.)

In a placement-under-separate-governance world, I contend there would
have been *zero* additional difference. Speculating on who the
"placement team" would be, the exact same people would have been present
at the hangouts and participating in the spec and code reviews.

[1] https://review.openstack.org/#/c/576927/
[2] https://review.openstack.org/#/c/585033/
[3] https://review.openstack.org/#/c/584598/ and up

> I think going through this
> integration would be best done *before* extraction to a new repo.

Agree. That could happen this week with some focused reviewing.

> I am OK with the idea of doing the extraction first, if that is
> what most people want to do.

Sweet. To close on this part of the discussion, is there anyone who
still objects to doing at least the repository-and-code part of the
extraction now?

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

Sorry, I'm confused - are we talking about NUMA cells or cellsv2 cells?
If the latter, what additional placement-side support is needed to
support it?

> Shared storage support is something
> operators have badly needed for years now and was envisioned to be
> solved with placement.

Again, I'm pretty sure the placement side work for this is done, or very
close to it; the remaining work is on the nova side.

But regardless, let's assume both of the above require significant
placement work in close coordination with nova for specs, design,
implementation, etc. How would separating governance have a negative
impact on that? As for reshaper, it would be all the same people in the
room. As Doug says:

> 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?
>
> What can they do to reassure you that they will work on the items
> nova needs, regardless of the governance structure?

More...

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

You answered your own question. If operators need a thing that involves
placement and nova, placement and nova have a shared interest in making
it happen. s/placement|nova/$openstack_project/. It's what we're about...

> separate goals and priorities

...because those priorities should largely overlap and be aligned with
OpenStack's goals and priorities, right?

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

This brings us to another part of the discussion I think we can close on
right now. I don't think I've heard any objections to: "The initial
placement-core team should be a superset of the nova-core team." Do we
have a consensus on that?

(Deferring discussion of who the additional members ought to be. That
probably needs its own thread and/or a different audience.)

-efried

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?


On Tue, 21 Aug 2018 14:55:26 -0600, Chris Friesen wrote:

On 08/21/2018 01:53 PM, melanie witt wrote:


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?


As someone who is not involved in the governance of nova, this seems like kind
of an odd statement for an open-source project.

  From the outside, it seems like there is a fairly small pool of active
placement developers.  And either the placement developers are willing to
implement the capabilities desired by compute or else they're not.  And if
they're not, I don't see how being under compute governance would resolve that
since the only official hard leverage the compute governance has is refusing to
review/merge placement patches (which wouldn't really help implement compute's
desires anyways).


I'm not sure I follow. As of now, placement developers are participating 
in the same priorities and goals setting as the rest of compute, each 
cycle. We discuss work that needs to be done and how to prioritize it, 
in the context of compute. We are one group.


If we separate into two different groups, all of the items I discussed 
in my previous reply will become cross-project efforts. To me, this 
means that the placement group will have their own priorities and goal 
setting process and if their priorities and goals happen to align with 
ours on certain items, we can agree to work on those in collaboration. 
But I won't make assumptions about how much alignment we will have. The 
placement group, as a hypothetical example, won't necessarily find 
helping us fix issues with compute functionality like vGPUs as important 
as we do, if we need additional work in placement to support it.


That's how I'm thinking about it, from a practical standpoint. I'm 
thinking about what it will look like delivering the functionality I 
discussed in my previous reply, for operators and users. I think it 
helps to be one group.


-melanie




__
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

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-21 Thread Chris Friesen


On 08/21/2018 01:53 PM, melanie witt wrote:


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?


As someone who is not involved in the governance of nova, this seems like kind 
of an odd statement for an open-source project.


From the outside, it seems like there is a fairly small pool of active 
placement developers.  And either the placement developers are willing to 
implement the capabilities desired by compute or else they're not.  And if 
they're not, I don't see how being under compute governance would resolve that 
since the only official hard leverage the compute governance has is refusing to 
review/merge placement patches (which wouldn't really help implement compute's 
desires anyways).


Chris

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-21 Thread Doug Hellmann

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?

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?

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

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?


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?


I understand that placement wants to appeal to more consumers (by way of 
splitting governance) but at present, Nova is the only consumer. And by 
consumer, I mean Nova is the only one consuming data *from* placement 
and relying on it to do something. I don't understand why it's really 
important *right now* to separate priorities before there are other 
viable consumers. I would like to share priorities and goals, for now, 
under the compute program to best serve operators and users in solving 
the specific problems I've mentioned in my replies to this thread.


Best,
-melanie




__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?


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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-21 Thread Jeremy Stanley

On 2018-08-21 17:18:40 + (+), Fox, Kevin M wrote:
[...]
> I'm really sure at this point that you can't have a project as
> large as OpenStack without leadership setting a course and
> sometimes making hard choices for the betterment of the whole.
> That doesn't mean a benevolent dictator. But our self govened
> model with elected officials should be a good balance. If they are
> too unreasonable, they don't get reelected. But not leading isn't
> an option either anymore.
[...]

Divining a consensual direction in which to steer the community is
not the same thing as telling people what to do, but is still very
much leadership. But I'd rather stop dancing in generalities and
just talk about concrete examples instead. In this case, separation
of governance between Nova and (as of yet unnamed) placement teams.

If the Nova team is against wholly handing over control of the
placement service to the current placement contributors, then having
the OpenStack Technical Committee tell them to get over it isn't the
way to foster productive future relationships between those two
groups of people. The placement team is already entirely empowered,
should they wish, to fork the placement service out of the nova
repository and then apply to the TC to have that recognized as a
separate team but doing so in no way guarantees the Nova team will
work with them to use that version of placement and deprecate the
one on which they currently rely. For that, there needs to be a
positive working relationship, one we can't simply demand into
being, so it's in their best interests to work things out amicably
and directly instead of asking someone else (the TC) to decide this
for them.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

Heh. And some things don't change...

Having a large project such as OpenStack, made up of large numbers of 
volunteers, each with their own desires means it will be impossible to make 
everyone happy all of the time.

For the good of the community, the community needs to decide on a common 
direction, and sometimes individuals need to be asked to go against their own 
desires for the betterment of the entire community. Yes, that risks an 
individual contributor leaving. But if it really is in the best interest of the 
community, others will continue on.

We've ignored that for so long, we've built a huge system on letting 
individuals set their own course without common direction and with their own 
desires. The projects don't integrate as well as they should, the whole of 
OpenStack gets overly complex and unwieldy to use or worse, large gaps in user 
needed functionality, and users end up leaving.

I'm really sure at this point that you can't have a project as large as 
OpenStack without leadership setting a course and sometimes making hard choices 
for the betterment of the whole. That doesn't mean a benevolent dictator. But 
our self govened model with elected officials should be a good balance. If they 
are too unreasonable, they don't get reelected. But not leading isn't an option 
either anymore.

Thanks,
Kevin

From: Jeremy Stanley [fu...@yuggoth.org]
Sent: Tuesday, August 21, 2018 9:53 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [nova] [placement] placement below or beside 
compute after extraction?

On 2018-08-21 16:38:41 + (+), Fox, Kevin M wrote:
[...]
> You need someone like the TC to be able to step in, in those cases
> to help sort that kind of issue out. In the past, the TC was not
> willing to do so. My gut feeling though is that is finally
> changing.
[...]

To be clear, it's not that TC members are unwilling to step into
these discussions. Rather, it's that most times when a governing
body has to tell volunteers to do something they don't want to do,
it tends to not be particularly helpful in solving the underlying
disagreement.
--
Jeremy Stanley

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-21 Thread Jeremy Stanley

On 2018-08-21 16:38:41 + (+), Fox, Kevin M wrote:
[...]
> You need someone like the TC to be able to step in, in those cases
> to help sort that kind of issue out. In the past, the TC was not
> willing to do so. My gut feeling though is that is finally
> changing.
[...]

To be clear, it's not that TC members are unwilling to step into
these discussions. Rather, it's that most times when a governing
body has to tell volunteers to do something they don't want to do,
it tends to not be particularly helpful in solving the underlying
disagreement.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

So, nova's worried about having to be in the boat many of us have been in where 
they depend on another project not recognizing their important use cases? heh...

ok, so, yeah. that is a legitimate concern. You need someone like the TC to be 
able to step in, in those cases to help sort that kind of issue out. In the 
past, the TC was not willing to do so. My gut feeling though is that is finally 
changing. This is a bigger problem then just Nova, so getting a proper 
procedure in place to handle this is really important for OpenStack in general. 
Lets solve that rather then one offing a solution by keeping placement under 
Nova's control.

How do I say this nicely Better to talk about it instead of continuing to 
ignore the hard issues I guess. Nova has been very self centered compared to 
other projects in the tent. This thread feels like more of the same. If 
OpenStack as a whole is to get healthier, we need to stop having selfish 
projects and encourage ones that help each other.

I think splitting out placement from Nova's control has at least two benefits
1. Nova has complained a lot about having too much code so they can't take 
other projects requests. This reduces Nova's code base so they can focus on 
their core functionality, and more importantly, their users use cases. This 
will make OpenStack as a whole, healthier.
2. It reduces Nova's special project status leveling the playing field a bit. 
Nova can help influence the TC to solving difficult cross project problems 
along with the rest of us rather then going off and doing things on their own.

Thanks,
Kevin

From: Matt Riedemann [mriede...@gmail.com]
Sent: Monday, August 20, 2018 6:23 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] [nova] [placement] placement below or beside 
compute after extraction?

On 8/20/2018 8:08 PM, Matt Riedemann wrote:
> On 8/20/2018 6:42 PM, Ed Leafe wrote:
>> It was said in the #openstack-tc discussions, but for those on the
>> mailing list, the biggest concern among the Nova core developers is
>> that the consensus among Placement cores will certainly not align with
>> the needs of Nova. I personally think that's ridiculous, and, as one
>> of the very opinionated people involved, a bit insulting. No one wants
>> to see either Nova or Placement to fail.
>
> I believe you're paraphrasing what I said, and I never said I was
> speaking for all nova core developers. I don't think anyone working on
> placement would intentionally block things nova needs or try to see nova
> fail.

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.

[1] Line 55 https://etherpad.openstack.org/p/SYD-forum-nova-placement-update

--

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

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-21 Thread Matt Riedemann


On 8/21/2018 7:55 AM, Thierry Carrez wrote:

Matt Riedemann wrote:

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


The issue with that kind of distrust by default is that it's not 
sustainable... In a large project you can't have every individual review 
everything because they trust noone else.


It's not distrust by default. I said, "thinking of the *various times*". 
Which means more than once. But I also said I was asked for input, and 
failed to reflect on that until I actually wrote it down. That's my fault.




That is why in OpenStack we instituted a culture of "trust by default, 
then escalate to PTL or TC if shit ever hits the fan". And the fact is, 
the PTL (at team level) or the TC (between teams) rarely had to 
arbitrate conflicts, because there aren't so many conflicts that are 
escalated rather than solved by consensus at the lower level.


Sure, but I'm sure there are also times where people don't escalate 
simply because they want to avoid conflict. There have been many times 
where I've questioned another nova core's +2/+W on a change and rather 
than make a big deal out of it, I push that frustration way down but it 
comes out in other ways, like distrust later. Again, that's my fault, 
but I suspect I'm not the only person in OpenStack that does this. On a 
good day I'll ask the person directly in IRC, or failing that on the 
review, "hey why did you do this? Did you think about X?".




Restoring "trust by default" between placement and the rest of Nova 
seems to be the root of the problem here. In a community, it's generally 
done by documenting general expectations and shared understandings, so 
that you create a common culture and trust by default people to apply it.


What would you suggest we do to improve that in this specific case?



Trust falls! I don't know, Thierry. Likely just improved direct 
communication with the people involved rather than back-channeling and 
distrust/hurt feelings which lead to "sides" being setup. As I said 
above, direct communication can be hard because of the confrontation and 
awkwardness so it's easier at times to take the shitty way out and just 
complain about so-and-so to someone else that thinks the same way you do 
rather than try to gain understanding and listen to other viewpoints. We 
(I) go over this every retrospective but still fail to learn from and 
practice it.


--

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-21 Thread Emilien Macchi

If I would be a standalone consummer of OpenStack Placement (e.g. I only
run cinder or ironic to manage volume / baremetal), and I had to run
something like:
$ pip install -U placement

I would prefer "placement" to be a project driven by diverse people
interested by Infrastructure resources placement and not just nova.

In other words, I would be afraid of seeing this project owned by the nova
team since the scope of placement seems to go beyond compute. Instead I
would be at ease to see a separated PTL and core team, who closely work
with OpenStack projects consuming placement service.
People writting placement's code would *own* this project, and decide of
their future. They would serve projects like nova, cinder, maybe ironic one
day, etc.
By making this team more independent, I believe they could build trust in
our community, which is something we desperately need nowadays and have
been encouraging over the last years. I have an high level of confidence
that this new team would be smart enough to collaborate when it comes to
code design decisions, no matter what happened in the past.

Let's reset a little bit and give these people a chance here.
Let's create this independent team.
I believe we could even write down a (short) vision for placement, and a
(short) mission statement, then we can set expectations for the near future.

On Tue, Aug 21, 2018 at 8:55 AM Thierry Carrez 
wrote:

> Matt Riedemann wrote:
> > [...]
> > 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. [...]
>
> The issue with that kind of distrust by default is that it's not
> sustainable... In a large project you can't have every individual review
> everything because they trust noone else.
>
> That is why in OpenStack we instituted a culture of "trust by default,
> then escalate to PTL or TC if shit ever hits the fan". And the fact is,
> the PTL (at team level) or the TC (between teams) rarely had to
> arbitrate conflicts, because there aren't so many conflicts that are
> escalated rather than solved by consensus at the lower level.
>
> Restoring "trust by default" between placement and the rest of Nova
> seems to be the root of the problem here. In a community, it's generally
> done by documenting general expectations and shared understandings, so
> that you create a common culture and trust by default people to apply it.
>
> What would you suggest we do to improve that in this specific case?
>
> --
> Thierry Carrez (ttx)
>
> __
> 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
>

-- 
Emilien Macchi
__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-21 Thread Thierry Carrez


Matt Riedemann wrote:

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


The issue with that kind of distrust by default is that it's not 
sustainable... In a large project you can't have every individual review 
everything because they trust noone else.


That is why in OpenStack we instituted a culture of "trust by default, 
then escalate to PTL or TC if shit ever hits the fan". And the fact is, 
the PTL (at team level) or the TC (between teams) rarely had to 
arbitrate conflicts, because there aren't so many conflicts that are 
escalated rather than solved by consensus at the lower level.


Restoring "trust by default" between placement and the rest of Nova 
seems to be the root of the problem here. In a community, it's generally 
done by documenting general expectations and shared understandings, so 
that you create a common culture and trust by default people to apply it.


What would you suggest we do to improve that in this specific case?

--
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-21 Thread Matt Riedemann


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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-21 Thread Chris Dent

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

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.

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]

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?


On 8/20/2018 8:08 PM, Matt Riedemann wrote:

On 8/20/2018 6:42 PM, Ed Leafe wrote:
It was said in the #openstack-tc discussions, but for those on the 
mailing list, the biggest concern among the Nova core developers is 
that the consensus among Placement cores will certainly not align with 
the needs of Nova. I personally think that's ridiculous, and, as one 
of the very opinionated people involved, a bit insulting. No one wants 
to see either Nova or Placement to fail.


I believe you're paraphrasing what I said, and I never said I was 
speaking for all nova core developers. I don't think anyone working on 
placement would intentionally block things nova needs or try to see nova 
fail.


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.


[1] Line 55 https://etherpad.openstack.org/p/SYD-forum-nova-placement-update

--

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?


On 8/20/2018 6:42 PM, Ed Leafe wrote:

It was said in the #openstack-tc discussions, but for those on the mailing 
list, the biggest concern among the Nova core developers is that the consensus 
among Placement cores will certainly not align with the needs of Nova. I 
personally think that's ridiculous, and, as one of the very opinionated people 
involved, a bit insulting. No one wants to see either Nova or Placement to fail.


I believe you're paraphrasing what I said, and I never said I was 
speaking for all nova core developers. I don't think anyone working on 
placement would intentionally block things nova needs or try to see nova 
fail.


--

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?


On 8/20/2018 1:32 PM, Hongbin Lu wrote:

* Is placement stable enough so that it won't break us often?


Yes, we use microversions for this reason.

* If there is a breaking change in placement and we contribute a fix, 
how fast the fix will be merged?


Eric hedged on this, but I think the answer is yes - if there is a thing 
that breaks you and you let us know it breaks you, we'll give attention 
to the fix, especially regressions. We've done this with Ironic when it 
comes up, and we've done it with other projects that consume not only 
placement but nova in general (trove, triple-o, etc).


* If there is a feature request from our side and we contribute patches 
to placement, will the patches be accepted?


As anything it depends on the feature request. API changes require 
deeper review because it's a long-term commitment to supporting that 
API, so they aren't taken lightly. But chances are if you need something 
from placement, someone else likely needs the same thing.


--

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-20 Thread Ed Leafe

On Aug 20, 2018, at 6:27 PM, Matt Riedemann  wrote:
> 
> 3. The biggest fear is on the people involved in what placement on its own 
> might be, because the current placement team is made of, for the most part, 
> highly opinionated people that spend a lot of time arguing because they have, 
> at times, conflicting design principles which can impede getting anything 
> done. Concessions are made after (1) people weigh in from the "outside" or 
> (2) exhaustion sets in.

While this is certainly true, the experience with Nova is not unusual in that 
regard. There have always been highly opinionated people with conflicting 
ideas. Eventually a choice is made; occasionally it is by persuasion, but the 
exhaustion bit is there too. What we've seen in Nova over the years is that 
generally those who have different opinions eventually fall by the wayside, 
leaving behind those who share the opinion of the choice. It becomes 
self-selecting. There isn't any reason that a similar process will happen among 
those highly-opinionated placement people.

It was said in the #openstack-tc discussions, but for those on the mailing 
list, the biggest concern among the Nova core developers is that the consensus 
among Placement cores will certainly not align with the needs of Nova. I 
personally think that's ridiculous, and, as one of the very opinionated people 
involved, a bit insulting. No one wants to see either Nova or Placement to fail.

-- Ed Leafe

signature.asc
Description: Message signed with OpenPGP
__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?


On 8/18/2018 7:25 AM, Chris Dent wrote:

5. In OpenStack we have a tradition of the contributors having a
strong degree of self-determination. If that tradition is to be
upheld, then it would make sense that the people who designed and
wrote the code that is being extracted would get to choose what
happens with it. As much as Mel's and Dan's (only picking on them
here because they are the dissenting voices that have showed up so
far) input has been extremely important and helpful in the evolution
of placement, they are not those people.


To be fair, lots of changes *in* placement *for* nova have been 
influenced by Dan even if Dan wasn't writing the placement side changes, 
because we definitely have a placement sub-team that works on the 
placement side of things and nova people that work on the client side 
nova things. For example, the atomic POST /allocations stuff Dan needed 
for fixing doubled-up allocations during move operations in nova. So my 
point is, a lot of the stuff done has been a team effort.




So my hope is that (in no particular order) Jay Pipes, Eric Fried,
Takashi Natsume, Tetsuro Nakamura, Matt Riedemann, Andrey Volkov,
Alex Xu, Balazs Gibizer, Ed Leafe, and any other contributor to
placement whom I'm forgetting [1] would express their preference on
what they'd like to see happen.


I'll try to summarize my position:

1. Placement should eventually be its own project under OpenStack 
governance, not under compute, because it's not just nova; I don't 
really care if it's under compute in some interim while it's technically 
extracted to a new repo. As Zane pointed out, that might be the best 
compromise for now to iterate and make progress on what is the hardest 
*technical* part of this extraction.


2. I don't think we can forever block the extraction on big changes that 
nova needs, especially if we don't already have concrete plans for what 
is needed to get those things done now.


3. The biggest fear is on the people involved in what placement on its 
own might be, because the current placement team is made of, for the 
most part, highly opinionated people that spend a lot of time arguing 
because they have, at times, conflicting design principles which can 
impede getting anything done. Concessions are made after (1) people 
weigh in from the "outside" or (2) exhaustion sets in.


Related to the extraction question, I think if we want to make progress, 
keeping a new placement repo under compute in governance is an 
incremental step so we can add a new core team with nova-core being a 
subset of the initial placement-core team, and then we can add people 
that wouldn't have otherwise been made nova-core because of a sole focus 
on placement (cdent is an obvious candidate here). But I realize keeping 
it under compute means risking #2 could keep it under compute for a long 
time. I don't really know how you fix #3 except people being honest 
about it and actually talking through things to reach consensus, and 
doing what we've said to do in retrospectives many times before - reach 
out for external input earlier and have face-to-face conversations 
(hangouts) earlier *before* conflicts start to damage relationships.


--

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?


On 8/17/2018 12:47 PM, Ed Leafe wrote:

I’d like this to be a technical discussion, with as little political overtones 
as possible.


Everyone agrees that technically placement should be in its own repo. 
The entire debate is political and regards people and who will be making 
decisions in the placement repo once it's split out. It's just hard to 
say that because it's confrontational and awkward.


--

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?


On 8/17/2018 12:30 PM, Dan Smith wrote:

I know politics will be involved in this, but this is a really terrible
reason to do a thing, IMHO. After the most recent meeting we had with
the Cinder people on placement adoption, I'm about as convinced as ever
that Cinder won't (and won't need to)_consume_  placement any time
soon. I hope it will_report_  to placement so Nova can make better
decisions, just like Neutron does now, but I think that's the extent
we're likely to see if we're honest.


[1] is a concrete example of where cinder would benefit from using 
placement to avoid scheduling conflicts, which was one of the primary 
reasons it was developed for nova as well.


[1] https://review.openstack.org/#/c/559718/

--

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?


On 8/17/2018 11:56 AM, melanie witt wrote:
We've seen exciting progress in finally solving a lot of these issues as 
we've been developing placement. But, there is still a significant 
amount of important work to do in Nova that depends on placement. For 
example, we need to integrate nested resource providers into the virt 
drivers in Nova to leverage it for vGPUs and NUMA modeling. We need 
affinity modeling in placement to properly handle affinity with multiple 
cells. We need shared storage accounting to properly handle disk usage 
for deployments on shared storage.


As was mentioned in the epic #openstack-tc channel discussion today, 
most of this is either already done in placement and nova, as a client, 
is lagging (N-R-P and shared storage) or we don't have concrete plans 
for the rest (affinity modeling). Right?




As we've worked to develop placement and use it in Nova, we've found in 
most cases that we've had to develop the Nova side and the placement 
side together, at the same time, to make things work. This isn't really 
surprising, as with any brand new functionality, it's difficult to 
fulfill a use case completely without integrating things together and 
iterating until everything works. Given that, I'd rather see placement 
stay under compute so we can iterate quickly, as we still need to 
develop new features in placement and exercise them for the first time, 
in Nova. Once the major aforementioned efforts have been figured out and 
landed with close coordination, I think it would make more sense to look 
at placement being outside of the compute project.


It's definitely true that major changes done across two separate APIs 
and teams will be more complicated and take longer, case in point is 
volume multi-attach which took at least 3 microversions in cinder (3.27, 
3.44, 3.48) before nova, as a client, was fully working properly with it.


I can't say we're really iterating quickly as it stands today. And 
unless we have concrete plans on what we need out of placement *today* 
for these big things that nova needs (affinity modeling is probably the 
hardest) it's hard to justify not making it its own project in 
governance - otherwise we could delay that move for a very long time, 
like how many cycles did we push off fixing [1] because we said 
placement would solve this so just sit tight?


Once we split, it will take leadership for major efforts from someone 
like ildiko did for volume multi-attach to bring both teams together to 
get things done, although I expect any split out placement would at 
least have nova-core as an initial subset of the placement-core team.


I personally don't care much either way if the placement repo is under 
the compute program for some interim amount of time, but I don't think 
we can keep it from being a separately governed project for an undefined 
amount of time while nova figures out what major things we need first.


[1] https://bugs.launchpad.net/nova/+bug/1469179

--

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?


On 8/20/2018 5:40 PM, Ed Leafe wrote:

That detail aside, the question is still valid: did the split from working 
within the Nova project to working as an independent project have positive or 
negative effects? Or both?


I'm sure the answer has got to be "both", right? Neutron integration 
with nova took several years. Just stabilizing neutron and getting it to 
the point of being able to run in production took a long time (I'm not 
an operator but I'm sure there are operators that can attest to this - 
hell it was even a performance/race problem in our gate for a long 
time). Where we're at now, and have been for the last several cycles, 
neutron is great* and I'm glad it's separate. But everyone working in 
both projects knew it took a long time to get there.


*I still have to read the manual every time I want to create a port from 
scratch, but hey...


--

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?


On 8/17/2018 11:09 AM, Sean McGinnis wrote:

This reluctance on having it part of Nova may be real or just perceived, but
with it within Nova it will likely be an uphill battle for some time convincing
other projects that it is a nicely separated common service that they can use.


Cyborg, Ironic and Neutron are all already involved in interfacing with 
placement to get things done in nova. I assume the majority of people 
that have a perception that it's part of nova don't know enough about 
it, or don't realize that placement is a separate service type entry in 
the service catalog. When you're talking to placement, you're not 
talking to nova. The code is just in the nova repo and the core team is 
the nova core team. The code was written as separate as possible from 
the start so it could be extracted to its own repo (no RPC usage for 
example with the nova services). The core team issue is a community 
problem at this point, which is the main source of conflict on whether 
or not placement remains within the compute program, at least for some 
interim, or if it's directly extracted into it's own program in governance.


--

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-20 Thread Ed Leafe

On Aug 20, 2018, at 5:31 PM, Matt Riedemann  wrote:
> 
>> I would like to hear from the Cinder and Neutron teams, especially those who 
>> were around when those compute sub-projects were split off into their own 
>> projects. Did you feel that being independent of compute helped or hindered 
>> you? And to those who are in those projects now, is there any sense that 
>> things would be better if you were still part of compute?
> 
> Neutron wasn't split out of nova.

Yes, that’s correct, and the continued existence of nova-network testifies to 
that. But what is also correct is that the networking effort was separated from 
Nova. Since the existing nova-network code wasn’t designed to handle the sort 
of networking that was envisioned to be needed, a separate Quantum project was 
started, by many of the people who contributed to nova-network in the past. 

That detail aside, the question is still valid: did the split from working 
within the Nova project to working as an independent project have positive or 
negative effects? Or both?

-- Ed Leafe

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?


On 8/17/2018 2:21 PM, Tom Barron wrote:
I think that even standalone if I'm running a scheduler (i.e., not doing 
emberlib version of standalone) then I'm likely to want to run them 
active-active on multiple nodes and will need a solution for the current 
races.  So even standalone we face the question of do we use placement 
to solve that issue or do we introduce some coordination among the 
schedulers themselves to solve it.


Why *wouldn't* you use placement in that case? It's extremely light 
weight (in its current form), it's just DB and API. It was meant to 
solve scheduler races (like we have had in nova since the beginning).


--

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?


On 8/17/2018 10:59 AM, Ed Leafe wrote:

I would like to hear from the Cinder and Neutron teams, especially those who 
were around when those compute sub-projects were split off into their own 
projects. Did you feel that being independent of compute helped or hindered 
you? And to those who are in those projects now, is there any sense that things 
would be better if you were still part of compute?


Neutron wasn't split out of nova.

--

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-20 Thread Zane Bitter

On 18/08/18 18:22, Eric Fried wrote:

A year ago we might have developed a feature where one patch would
straddle placement and nova. Six months ago we were developing features
where those patches were separate but in the same series. Today that's
becoming less and less the case: nrp, sharing providers, consumer
generations, and other things mentioned have had their placement side
completed and their nova side - if started at all - done completely
independently. The reshaper series is an exception - but looking back on
its development, Depends-On would have worked just as well.

So you've given a list here of things that you think wouldn't gain any
particular benefit from being under the same governance. (Or possibly
this is just an argument for being in a separate repo, which everybody
already agrees with?) Mel gave a list of things she thinks _would_
benefit from shared governance. Was there anything on her list that
you'd disagree with? Is there anything on your list that Mel or Dan or
anybody else would disagree with? Why?

(Note: I personally don't even think it matters, but this is how you
reach consensus.)

Agree the nova project is overloaded and would benefit from having
broader core reviewer coverage over placement code. The list Chris
gives above includes more than one non-nova core who should be made
placement cores as soon as that's a thing.

I agree with this, but separate governance is not a prerequisite for it.
Having a different/larger core team for a repo in Gerrit is technically
very easy, and our governance rules leave it completely up to the
project team (represented by the PTL) to decide. Mel indicated what I'd
describe as non-opposition to that on IRC, provided that the nova-core
team retained core review rights on the placement repo.[1] How does the
Nova team as a whole feel about that? Would anybody object? Would that
be sufficient to resolve the placement team's concerns about core
reviewer coverage?

cheers,
Zane.

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-20.log.html#t2018-08-20T17:36:58

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-20 Thread Hongbin Lu

On Mon, Aug 20, 2018 at 3:15 PM Eric Fried  wrote:

> This is great information, thanks Hongbin.
>
> If I'm understanding correctly, it sounds like Zun ultimately wants to
> be a peer of nova in terms of placement consumption. Using the resource
> information reported by nova, neutron, etc., you wish to be able to
> discover viable targets for a container deployment (GET
> /allocation_candidates) and claim resources to schedule to them (PUT
> /allocations/{uuid}). And you want to do it while Nova is doing the same
> for VMs, in the same cloud. Do I have that right?
>

Yes, your interpretation is right.


>
> > * Is placement stable enough so that it won't break us often?
>
> Yes.
>
> > * If there is a breaking change in placement and we contribute a fix,
> > how fast the fix will be merged?
> > * If there is a feature request from our side and we contribute patches
> > to placement, will the patches be accepted?
>
> I believe this to be one of the main issues in the decision about
> independent governance. If placement remains under nova, it is more
> likely that fixes and features impacting the nova team would receive
> higher priority than those impacting zun.
>
> -efried
>
> > I express the Zun's point of view.
> >
> > Zun has a scheduler to schedule containers to nodes based on the
> > demanded and available compute resources (i.e. cpu, memory). Right now,
> > Zun's scheduler is independent of Nova so VMs and containers have to be
> > separated into two set of resource pools. One of the most demanding
> > features from our users (e.g. requested from Chinese UnionPay via
> > OpenStack Financial WG) is to have VMs and containers share the same set
> > of resource pool to maximize utilization. To satisfy this requirement,
> > Zun needs to know the current resource allocation that are made by
> > external services (i.e. Nova) so that we can take those information into
> > account when scheduling the containers. Adopting placement is a
> > straightforward and feasible approach to address that.
> >
> > As a summary, below are high-level requirements from Zun's perspective:
> > * Have VMs and containers multiplex into a pool of compute nodes.
> > * Make optimal scheduling decisions for containers based on information
> > (i.e. VM allocations) query from placement.
> > * Report container allocations to placement and hope external schedulers
> > can make optimal decisions.
> >
> > We haven't figured out the technical details yet. However, to look
> > forward, if Zun team decides to adopt placement, I would have the
> > following concerns:
> > * Is placement stable enough so that it won't break us often?
> > * If there is a breaking change in placement and we contribute a fix,
> > how fast the fix will be merged?
> > * If there is a feature request from our side and we contribute patches
> > to placement, will the patches be accepted?
> >
> > Regardless of whether placement is extracted or not, above are the
> > concerns that I mostly care about.
> >
> > Best regards,
> > Hongbin
> >
> >
> >
> >
> __
> > 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
> >
>
> __
> 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
>
__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-20 Thread Eric Fried

This is great information, thanks Hongbin.

If I'm understanding correctly, it sounds like Zun ultimately wants to
be a peer of nova in terms of placement consumption. Using the resource
information reported by nova, neutron, etc., you wish to be able to
discover viable targets for a container deployment (GET
/allocation_candidates) and claim resources to schedule to them (PUT
/allocations/{uuid}). And you want to do it while Nova is doing the same
for VMs, in the same cloud. Do I have that right?

> * Is placement stable enough so that it won't break us often?

Yes.

> * If there is a breaking change in placement and we contribute a fix,
> how fast the fix will be merged?
> * If there is a feature request from our side and we contribute patches
> to placement, will the patches be accepted?

I believe this to be one of the main issues in the decision about
independent governance. If placement remains under nova, it is more
likely that fixes and features impacting the nova team would receive
higher priority than those impacting zun.

-efried

> I express the Zun's point of view.
> 
> Zun has a scheduler to schedule containers to nodes based on the
> demanded and available compute resources (i.e. cpu, memory). Right now,
> Zun's scheduler is independent of Nova so VMs and containers have to be
> separated into two set of resource pools. One of the most demanding
> features from our users (e.g. requested from Chinese UnionPay via
> OpenStack Financial WG) is to have VMs and containers share the same set
> of resource pool to maximize utilization. To satisfy this requirement,
> Zun needs to know the current resource allocation that are made by
> external services (i.e. Nova) so that we can take those information into
> account when scheduling the containers. Adopting placement is a
> straightforward and feasible approach to address that.
> 
> As a summary, below are high-level requirements from Zun's perspective:
> * Have VMs and containers multiplex into a pool of compute nodes.
> * Make optimal scheduling decisions for containers based on information
> (i.e. VM allocations) query from placement.
> * Report container allocations to placement and hope external schedulers
> can make optimal decisions.
> 
> We haven't figured out the technical details yet. However, to look
> forward, if Zun team decides to adopt placement, I would have the
> following concerns:
> * Is placement stable enough so that it won't break us often?
> * If there is a breaking change in placement and we contribute a fix,
> how fast the fix will be merged?
> * If there is a feature request from our side and we contribute patches
> to placement, will the patches be accepted?
> 
> Regardless of whether placement is extracted or not, above are the
> concerns that I mostly care about.
> 
> Best regards,
> Hongbin
> 
> 
> 
> __
> 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
> 

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-20 Thread Chris Dent


On Mon, 20 Aug 2018, Zane Bitter wrote:

If you want my personal opinion then I'm a big believer in incremental 
change. So, despite recognising that it is born of long experience of which I 
have been blissfully mostly unaware, I have to disagree with Chris's position 
that if anybody lets you change something then you should try to change as 
much as possible in case they don't let you try again.


Because you called me out specifically, I feel obliged to say, this
is neither what I said nor what I meant. It wasn't "in case they
don't let you try again". It was "we've been trying to do some of
this for two years and if we do it incrementally, the end game is
further away, because it seems us take us forever to do anything."

Perhaps not a huge difference.

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-20 Thread Jeremy Stanley

On 2018-08-20 14:25:06 -0400 (-0400), Zane Bitter wrote:
> On 20/08/18 14:02, Chris Friesen wrote:
> > In order to address the "velocity of change in placement"
> > issues, how about making the main placement folks members of
> > nova-core with the understanding that those powers would only be
> > used in the new placement repo?
> 
> That kind of 'understanding' is only needed (because of
> limitations in Gerrit) when working in the same repo. Once it's in
> a separate repo you just create a new 'placement-core' group and
> make nova-core a member of it.

More correctly, the effort you'd go through to correctly
characterize subsets of a repository under control of different
groups of people is within the same order of magnitude as just
putting them in separate Git repositories (especially when you take
in to consideration the knock-on effects of duplicating things like
review dashboards for the various prolog rules defined for those
different subsets of the repository). If you're going to attempt to
delegate review on portions of a Git repository, in most cases you
may as well go ahead and make it a separate repository anyway.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-20 Thread Hongbin Lu

On Sat, Aug 18, 2018 at 8:25 AM Chris Dent  wrote:

>
> 5. In OpenStack we have a tradition of the contributors having a
> strong degree of self-determination. If that tradition is to be
> upheld, then it would make sense that the people who designed and
> wrote the code that is being extracted would get to choose what
> happens with it. As much as Mel's and Dan's (only picking on them
> here because they are the dissenting voices that have showed up so
> far) input has been extremely important and helpful in the evolution
> of placement, they are not those people.
>
> So my hope is that (in no particular order) Jay Pipes, Eric Fried,
> Takashi Natsume, Tetsuro Nakamura, Matt Riedemann, Andrey Volkov,
> Alex Xu, Balazs Gibizer, Ed Leafe, and any other contributor to
> placement whom I'm forgetting [1] would express their preference on
> what they'd like to see happen.
>
> At the same time, if people from neutron, cinder, blazar, zun,
> mogan, ironic, and cyborg could express their preferences, we can get
> through this by acclaim and get on with getting things done.
>
> Thank you.
>

I express the Zun's point of view.

Zun has a scheduler to schedule containers to nodes based on the demanded
and available compute resources (i.e. cpu, memory). Right now, Zun's
scheduler is independent of Nova so VMs and containers have to be separated
into two set of resource pools. One of the most demanding features from our
users (e.g. requested from Chinese UnionPay via OpenStack Financial WG) is
to have VMs and containers share the same set of resource pool to maximize
utilization. To satisfy this requirement, Zun needs to know the current
resource allocation that are made by external services (i.e. Nova) so that
we can take those information into account when scheduling the containers.
Adopting placement is a straightforward and feasible approach to address
that.

As a summary, below are high-level requirements from Zun's perspective:
* Have VMs and containers multiplex into a pool of compute nodes.
* Make optimal scheduling decisions for containers based on information
(i.e. VM allocations) query from placement.
* Report container allocations to placement and hope external schedulers
can make optimal decisions.

We haven't figured out the technical details yet. However, to look forward,
if Zun team decides to adopt placement, I would have the following concerns:
* Is placement stable enough so that it won't break us often?
* If there is a breaking change in placement and we contribute a fix, how
fast the fix will be merged?
* If there is a feature request from our side and we contribute patches to
placement, will the patches be accepted?

Regardless of whether placement is extracted or not, above are the concerns
that I mostly care about.

Best regards,
Hongbin
__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-20 Thread Zane Bitter


On 20/08/18 14:02, Chris Friesen wrote:
In order to address the "velocity of change in placement" issues, how 
about making the main placement folks members of nova-core with the 
understanding that those powers would only be used in the new placement 
repo?


That kind of 'understanding' is only needed (because of limitations in 
Gerrit) when working in the same repo. Once it's in a separate repo you 
just create a new 'placement-core' group and make nova-core a member of it.


__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-20 Thread Chris Friesen


On 08/20/2018 11:44 AM, Zane Bitter wrote:


If you want my personal opinion then I'm a big believer in incremental change.
So, despite recognising that it is born of long experience of which I have been
blissfully mostly unaware, I have to disagree with Chris's position that if
anybody lets you change something then you should try to change as much as
possible in case they don't let you try again. (In fact I'd go so far as to
suggest that those kinds of speculative changes are a contributing factor in
making people reluctant to allow anything to happen at all.) So I'd suggest
splitting the repo, trying things out for a while within Nova's governance, and
then re-evaluating. If there are that point specific problems that separate
governance would appear to address, then it's only a trivial governance patch
and a PTL election away. It should also be much easier to get consensus at that
point than it is at this distance where we're only speculating what things will
be like after the extraction.

I'd like to point out for the record that Mel already said this and said it
better and is AFAICT pretty much never wrong :)


In order to address the "velocity of change in placement" issues, how about 
making the main placement folks members of nova-core with the understanding that 
those powers would only be used in the new placement repo?


Chris

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-20 Thread Zane Bitter


On 17/08/18 11:51, Chris Dent wrote:

One of the questions that has come up on the etherpad is about how
placement should be positioned, as a project, after the extraction.
The options are:

* A repo within the compute project
* Its own project, either:
   * working towards being official and governed
   * official and governed from the start


So since this is under heavy discussion in #openstack-tc, and Ed asked 
for folks who are not invested in either side, allow me to offer this 
suggestion:


It just doesn't matter.

The really important thing here, and it sounds like one that everybody 
agrees on, is that placement gets split out into its own repo. That will 
enable things to move forward both technically (helping other projects 
to more easily consume it) and socially (allowing it to use a separate 
Gerrit ACL so it can add additional core reviewers with +2 rights only 
on that repo). So let's focus on getting that done.


It seems unlikely to me that having the placement repo technically under 
the governance of the Nova project will present anywhere near the level 
of obstacle to other projects using as having it in the same repo as 
Nova currently does, if they are even aware of it at all. Conversely, I 
consider it equally unlikely that placement living outside of the Nova 
umbrella altogether would result in significant divergence between its 
interests and those of Nova.


If you want my personal opinion then I'm a big believer in incremental 
change. So, despite recognising that it is born of long experience of 
which I have been blissfully mostly unaware, I have to disagree with 
Chris's position that if anybody lets you change something then you 
should try to change as much as possible in case they don't let you try 
again. (In fact I'd go so far as to suggest that those kinds of 
speculative changes are a contributing factor in making people reluctant 
to allow anything to happen at all.) So I'd suggest splitting the repo, 
trying things out for a while within Nova's governance, and then 
re-evaluating. If there are that point specific problems that separate 
governance would appear to address, then it's only a trivial governance 
patch and a PTL election away. It should also be much easier to get 
consensus at that point than it is at this distance where we're only 
speculating what things will be like after the extraction.


I'd like to point out for the record that Mel already said this and said 
it better and is AFAICT pretty much never wrong :)


cheers,
Zane.

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-20 Thread Dan Smith

>> So my hope is that (in no particular order) Jay Pipes, Eric Fried,
>> Takashi Natsume, Tetsuro Nakamura, Matt Riedemann, Andrey Volkov,
>> Alex Xu, Balazs Gibizer, Ed Leafe, and any other contributor to
>> placement whom I'm forgetting [1] would express their preference on
>> what they'd like to see happen.

I apparently don't qualify for a vote, so I'll just reply to Jay's
comments here.

> I am not opposed to extracting the placement service into its own
> repo. I also do not view it as a priority that should take precedence
> over the completion of other items, including the reshaper effort and
> the integration of placement calls into Nova (nested providers,
> sharing providers, etc).
>
> The remaining items are Nova-centric. We need Nova-focused
> contributors to make placement more useful to Nova, and I fail to see
> how extracting the placement service will meet that goal. In fact, one
> might argue, as Melanie implies, that extracting placement outside of
> the Compute project would increase the velocity of the placement
> project *at the expense of* getting things done in the Nova project.

Yep, this. I know it's a Nova-centric view, but unlike any other
project, we have taken the risk of putting placement in our critical
path. That has yielded several fire drills right before releases, as
well as complicated backports to fix things that we have broken in the
process, etc. We've got a list of things that are half-finished or
promised-but-not-started, and those are my priority over most everything
else.

> We've shown we can get many things done in placement. We've shown we
> can evolve the API fairly quickly. The velocity of the placement
> project isn't the problem. The problem is the lag between features
> being written into placement (sometimes too hastily IMHO) and actually
> *using* those features in Nova.

Right, and the reshaper effort is a really good example of what I'm
concerned about. Nova has been getting ready for NRPs for several cycles
now, and just before crunch time in Rocky, we realize there's a huge
missing piece of the puzzle on the placement side. That's not the first
time that has happened and I'm sure it won't be the last.

> As for the argument about other projects being able (or being more
> willing to) use placement, I think that's not actually true. The
> projects that might want to ditch their own custom resource tracking
> and management code (Cyborg, Neutron, Cinder, Ironic) have either
> already done so or would require minimal changes to do that. There are
> no projects other than Ironic that I'm aware of that are interested in
> using the allocation candidates functionality (and the allocation
> claim process that entails) for the rough scheduling functionality
> that provides. I'm not sure placement being extracted would change
> that.

My point about this is that "reporting" and "consuming" placement are
different things. Neutron reports, we'd like Cinder to report. Ironic
reports, but indirectly. Cyborg would report. Those reporting activities
are to help projects that "consume" placement make better decisions, but
I think it's entirely likely that Nova will be the only one that ever
does that.

--Dan

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-20 Thread Jay Pipes


On 08/18/2018 08:25 AM, Chris Dent wrote:

So my hope is that (in no particular order) Jay Pipes, Eric Fried,
Takashi Natsume, Tetsuro Nakamura, Matt Riedemann, Andrey Volkov,
Alex Xu, Balazs Gibizer, Ed Leafe, and any other contributor to
placement whom I'm forgetting [1] would express their preference on
what they'd like to see happen.

At the same time, if people from neutron, cinder, blazar, zun,
mogan, ironic, and cyborg could express their preferences, we can get
through this by acclaim and get on with getting things done.


I am not opposed to extracting the placement service into its own repo. 
I also do not view it as a priority that should take precedence over the 
completion of other items, including the reshaper effort and the 
integration of placement calls into Nova (nested providers, sharing 
providers, etc).


The remaining items are Nova-centric. We need Nova-focused contributors 
to make placement more useful to Nova, and I fail to see how extracting 
the placement service will meet that goal. In fact, one might argue, as 
Melanie implies, that extracting placement outside of the Compute 
project would increase the velocity of the placement project *at the 
expense of* getting things done in the Nova project.


We've shown we can get many things done in placement. We've shown we can 
evolve the API fairly quickly. The velocity of the placement project 
isn't the problem. The problem is the lag between features being written 
into placement (sometimes too hastily IMHO) and actually *using* those 
features in Nova.


As for the argument about other projects being able (or being more 
willing to) use placement, I think that's not actually true. The 
projects that might want to ditch their own custom resource tracking and 
management code (Cyborg, Neutron, Cinder, Ironic) have either already 
done so or would require minimal changes to do that. There are no 
projects other than Ironic that I'm aware of that are interested in 
using the allocation candidates functionality (and the allocation claim 
process that entails) for the rough scheduling functionality that 
provides. I'm not sure placement being extracted would change that.


Would extracting placement out into its own repo result in a couple more 
people being added to the new placement core contributor team? Possibly. 
Will that result in Nova getting the integration pieces written that 
make use of placement? No, I don't believe so.


So, I'm on the fence. I understand the desire for separation, and I'm 
fully aware of my bias as a current Nova core contributor. I even 
support the process of extracting placement. But do I think it will do 
much other than provide some minor measure of independence? No, not really.


Consider me +0.

Best,
-jay

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-20 Thread TETSURO NAKAMURA


So my hope is that (in no particular order) Jay Pipes, Eric Fried,
Takashi Natsume, Tetsuro Nakamura, Matt Riedemann, Andrey Volkov,
Alex Xu, Balazs Gibizer, Ed Leafe, and any other contributor to
placement whom I'm forgetting [1] would express their preference on
what they'd like to see happen.


+1 on extract.

1) Since we are open source, we should keep thinking about getting new 
developers. Keeping functions in one big project is not a good strategy 
to get new participants.
2) Let projects get small sounds a good strategy to get more core 
reviewers. Being a core is a strong reason for one to spend more time on 
OpenStack in a company... at least in the company I work for.


--
Tetsuro Nakamura 
NTT Network Service Systems Laboratories




__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-20 Thread Thierry Carrez


Chris Dent wrote:

[...]
So my hope is that (in no particular order) Jay Pipes, Eric Fried,
Takashi Natsume, Tetsuro Nakamura, Matt Riedemann, Andrey Volkov,
Alex Xu, Balazs Gibizer, Ed Leafe, and any other contributor to
placement whom I'm forgetting [1] would express their preference on
what they'd like to see happen.

At the same time, if people from neutron, cinder, blazar, zun,
mogan, ironic, and cyborg could express their preferences, we can get
through this by acclaim and get on with getting things done.
[...]


I fully support that existing and potential placement contributors
decide its destiny.

Upstream development work in OpenStack is (currently) organized in 
"project teams" (groups of people), not programs (domains). If the 
existing and potential contributors match an existing project team, then 
work can be placed within it. If it's just a very partial overlap, I'd 
recommend creating a specific team, especially if placement is expected 
to attract other contributors.


Notes:
- the new project team "officialization" can be fast-tracked as this 
would be a split of official code, not new code

- being in separate teams does not prevent cooperation or coordination

--
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-18 Thread Eric Fried

> So my hope is that (in no particular order) Jay Pipes, Eric Fried,
> Takashi Natsume, Tetsuro Nakamura, Matt Riedemann, Andrey Volkov,
> Alex Xu, Balazs Gibizer, Ed Leafe, and any other contributor to
> placement whom I'm forgetting [1] would express their preference on
> what they'd like to see happen.

Extract now, as a fully-independent project, under governance right out
of the gate.

A year ago we might have developed a feature where one patch would
straddle placement and nova. Six months ago we were developing features
where those patches were separate but in the same series. Today that's
becoming less and less the case: nrp, sharing providers, consumer
generations, and other things mentioned have had their placement side
completed and their nova side - if started at all - done completely
independently. The reshaper series is an exception - but looking back on
its development, Depends-On would have worked just as well.

Agree with the notion that nova needs to catch up with placement
features, and would therefore actually *benefit* from a placement
"feature freeze".

Agree the nova project is overloaded and would benefit from having
broader core reviewer coverage over placement code.  The list Chris
gives above includes more than one non-nova core who should be made
placement cores as soon as that's a thing.

The fact that other projects are in various stages of adopting/using
placement in various capacities is a great motive to extract. But IMO
the above would be sufficient reason without that.

Plus other things that other people have said.

Do it. Do it completely. Do it now.

-efried
.

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-18 Thread Doug Hellmann

Excerpts from Chris Dent's message of 2018-08-18 13:25:25 +0100:
> 
> 2. There are other projects actively using placement, not merely
> interested. If you search codesearch.o.o for terms like "resource
> provider" you can find them. But to rattle off those that I'm aware
> of (which I'm certain is an incomplete list):

This is the bit I was trying to ask about, and it sounds like the
answer is clearly "yes, there are other services using placement".
If the answer had been "no, there is no interest" then it would not
make sense to go further.

Now, as you point out, the next step is to find out from the
contributors to placement what they want the ultimate home for the
service to be, and what steps need to be taken to reach that point.

Doug

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-18 Thread Chris Dent


On Fri, 17 Aug 2018, Tom Barron wrote:

Has there been a discussion on record of how use of placement by cinder would 
affect "standalone" cinder (or manila) initiatives where there is a desire to 
be able to run cinder by itself (with no-auth) or just with keystone (where 
OpenStack style multi-tenancy is desired)?


This has been sort of glancingly addressed elsewhere in the thread,
but I wanted to make it explicit:

* It's possible now to run placement now with faked auth (the
  noauth2 concept) or keystone. Making auth handling more flexible
  would be a matter of choosing a different piece of middleware.

* Partly driven by discussion with Cinder people and also with fast
  forward upgrade people, there's a feature in placement called
  "PlacementDirect". This makes it possible to interact with
  placement in the same process as the thing that is using it,
  rather than over HTTP. So no additional placement server is
  required, if that's how people want it. More info at:

  
https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/direct.py
  
http://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/reshape-provider-tree.html#direct-interface-to-placement

  However, since placement is lightweight (a simple-ish wsgi app over
  some database tables) it likely easier just to run it like normal,
  maybe in some containers to allow it to scale up and down easily.

If you have a look at https://github.com/cdent/placedock and some of
the links in the README, the flexibility and lightness may become a
bit more clear.

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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-18 Thread Chris Dent

On Fri, 17 Aug 2018, Doug Hellmann wrote:

If we ignore the political concerns in the short term, are there
other projects actually interested in using placement? With what
technical caveats? Perhaps with modifications of some sort to support
the needs of those projects?

I think ignoring the political concerns (in any term) is not
possible. We are a group of interacting humans, politics are always
present. Cordial but active debate to determine the best course of
action is warranted.

(tl;dr: Let's have existing and potential placement contributors
decide its destiny.)

Five topics I think are relevant here, in order of politics, least
to most:

1. Placement has been designed from the outset to have a hard
contract between it and the services that use it. Being embedded
and/or deeply associated with one other single service means that
that contract evolves in a way that is strongly coupled. We made
placement have an HTTP API, not use RPC, and not produce or consume
notifications because it is supposed to be bounded and independent.
Sharing code and human management doesn't enable that. As you'll
read below, placement's progress has been overly constrained by
compute.

2. There are other projects actively using placement, not merely
interested. If you search codesearch.o.o for terms like "resource
provider" you can find them. But to rattle off those that I'm aware
of (which I'm certain is an incomplete list):

* Cyborg is actively working on using placement to track FPGA
e.g., https://review.openstack.org/#/c/577438/

* Blazar is working on using them for reservations:

https://review.openstack.org/#/q/status:open+project:openstack/blazar+branch:master+topic:bp/placement-api

* Neutron has been reporting to placement for some time and has work
in progress on minimum bandwidth handling with the help of
placement:

https://review.openstack.org/#/q/status:open+project:openstack/neutron-lib+branch:master+topic:minimum-bandwidth-allocation-placement-api

* Ironic uses resource classes to describe types of nodes

* Mogan (which may or may not be dead, not clear) was intending to
track nodes with placement:

http://git.openstack.org/cgit/openstack/mogan-specs/tree/specs/pike/approved/track-resources-using-placement.rst

* Zun is working to use placement for "unified resource management":
https://blueprints.launchpad.net/zun/+spec/use-placement-resource-management

* Cinder has had discussion about using placement to overcome race
conditions in its existing scheduling subsystem (a purpose to
which placement was explicitly designed).

3. Placement's direction and progress is heavily curtailed by the
choices and priorities that compute wants or needs to make. That
means that for the past year or more much of the effort in placement
has been devoted to eventually satisfying NFV use cases driven by
"enhanced platform awareness" to the detriment of the simple use
case of "get me some resource providers". Compute is under a lot of
pressure in this area, and is under-resourced, so placement's
progress is delayed by being in the (necessarily) narrow engine of
compute. Similarly, computes's overall progress is delayed because a
lot of attention is devoted to placement.

I think the relevance of that latter point has been under-estimated
by the voices that are hoping to keep placement near to nova. The
concern there has been that we need to continue iterating in concert
and quickly. I disagree with that from two angles. One is that we
_will_ continue to work in concert. We are OpenStack, and presumably
all the same people working on placement now will continue to do so,
and many of those are active contributors to nova. We will work
together.

The other angle is that, actually, placement is several months ahead
of nova in terms of features and it would be to everyone's advantage if
placement, from a feature standpoint, took a time out (to extract)
while nova had a chance to catch up with fully implementing shared
providers, nested resource providers, consumer generations, resource
request groups, using the reshaper properly from the virt drivers,
having a fast forward upgrade script talking to PlacementDirect, and
other things that I'm not remembering right now. The placement side
for those things is in place. The work that it needs now is a
_diversity_ of callers (not just nova) so that the features can been
fully exercised and bugs and performance problems found.

The projects above, which might like to--and at various times have
expressed desire to do so--work on features within placement that
would benefit their projects, are forced to compete with existing
priorities to get blueprint attention. Though runways seemed to help
a bit on that front this just-ending cycle, it's simply too dense a
competitive environment for good, clean progress.

4. While extracting the placement code into another repo within the
compute umbrella might help a small amount with some of the
competition described in item

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-17 Thread Tom Barron


On 17/08/18 14:09 -0500, Jay S Bryant wrote:



On 8/17/2018 1:34 PM, Sean McGinnis wrote:

Has there been a discussion on record of how use of placement by cinder
would affect "standalone" cinder (or manila) initiatives where there is a
desire to be able to run cinder by itself (with no-auth) or just with
keystone (where OpenStack style multi-tenancy is desired)?

Tom Barron (tbarron)


A little bit. That would be one of the pieces that needs to be done if we were
to adopt it.

Just high level brainstorming, but I think we would need something like we have
now with using tooz where if it is configured for it, it will use etcd for
distributed locking. And for single node installs it just defaults to file
locks.


Sean and Tom,

That brief discussion was in Vancouver: 
https://etherpad.openstack.org/p/YVR-cinder-placement


Thanks, Jay.



But as Sean indicated I think the long story short was that we would 
make it so that we could use the placement service if it was available 
but would leave the existing functionality in the case it wasn't 
there.


I think that even standalone if I'm running a scheduler (i.e., not 
doing emberlib version of standalone) then I'm likely to want to run 
them active-active on multiple nodes and will need a solution for the 
current races.  So even standalone we face the question of do we use 
placement to solve that issue or do we introduce some coordination 
among the schedulers themselves to solve it.


-- Tom Barron (tbarron)



Jay

__
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


__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-17 Thread Jay S Bryant




On 8/17/2018 12:30 PM, Dan Smith wrote:

The subject of using placement in Cinder has come up, and since then I've had a
few conversations with people in and outside of that team. I really think until
placement is its own project outside of the nova team, there will be resistance
from some to adopt it.

I know politics will be involved in this, but this is a really terrible
reason to do a thing, IMHO. After the most recent meeting we had with
the Cinder people on placement adoption, I'm about as convinced as ever
that Cinder won't (and won't need to) _consume_ placement any time
soon. I hope it will _report_ to placement so Nova can make better
decisions, just like Neutron does now, but I think that's the extent
we're likely to see if we're honest.

Dan,

I don't know of any reason we wouldn't want to report to placement. Just 
a matter of getting a person to implement it.


Also, from a consumption standpoint we really only have one or two 
people are are opposed at this point.  We have time scheduled at the PTG 
to discuss this further.  The discussions in Vancouver seemed to be 
tilting toward the fact that it might solve other technical issues we 
have been having from an Active/Active HA configuration standpoint.  
Just need to get the right people in the room to talk about it.


Jay

What other projects are _likely_ to _consume_ placement even if they
don't know they'd want to? What projects already want to use it but
refuse to because it has Nova smeared all over it? We talked about this
a lot in the early justification for placement, but the demand for that
hasn't really materialized, IMHO; maybe it's just me.


This reluctance on having it part of Nova may be real or just perceived, but
with it within Nova it will likely be an uphill battle for some time convincing
other projects that it is a nicely separated common service that they can use.

Splitting it out to another repository within the compute umbrella (what
do we call it these days?) satisfies the _technical_ concern of not
being able to use placement without installing the rest of the nova code
and dependency tree. Artificially creating more "perceived" distance
sounds really political to me, so let's be sure we're upfront about the
reasoning for doing that if so :)

--Dan

__
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



__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-17 Thread Tom Barron


On 17/08/18 13:34 -0500, Sean McGinnis wrote:


Has there been a discussion on record of how use of placement by cinder
would affect "standalone" cinder (or manila) initiatives where there is a
desire to be able to run cinder by itself (with no-auth) or just with
keystone (where OpenStack style multi-tenancy is desired)?

Tom Barron (tbarron)



A little bit. That would be one of the pieces that needs to be done if we were
to adopt it.

Just high level brainstorming, but I think we would need something like we have
now with using tooz where if it is configured for it, it will use etcd for
distributed locking. And for single node installs it just defaults to file
locks.


So I want to understand better what problems placement would solve and 
whether those problems need to be solved even in the cinder/manila 
standalone case.  And if they do have to be solved in both cases, why 
not use the same solution for both cases?


That *might* mean running the placement service even in the standalone 
case if it's sufficiently lightweight and can be run without the rest 
of nova.  (Whether it's "under" nova umbrella doesn't matter for this 
decoupling - nothing I'm saying here is intended to argue against e.g. 
Mel's or Dan's points in this thread.)


-- Tom Barron (tbarron)





__
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


__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-17 Thread Jay S Bryant




On 8/17/2018 1:34 PM, Sean McGinnis wrote:

Has there been a discussion on record of how use of placement by cinder
would affect "standalone" cinder (or manila) initiatives where there is a
desire to be able to run cinder by itself (with no-auth) or just with
keystone (where OpenStack style multi-tenancy is desired)?

Tom Barron (tbarron)


A little bit. That would be one of the pieces that needs to be done if we were
to adopt it.

Just high level brainstorming, but I think we would need something like we have
now with using tooz where if it is configured for it, it will use etcd for
distributed locking. And for single node installs it just defaults to file
locks.


Sean and Tom,

That brief discussion was in Vancouver: 
https://etherpad.openstack.org/p/YVR-cinder-placement


But as Sean indicated I think the long story short was that we would 
make it so that we could use the placement service if it was available 
but would leave the existing functionality in the case it wasn't there.


Jay

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-17 Thread melanie witt


On Fri, 17 Aug 2018 13:37:41 -0500, Sean Mcginnis wrote:

On Fri, Aug 17, 2018 at 12:47:10PM -0500, Ed Leafe wrote:

On Aug 17, 2018, at 12:30 PM, Dan Smith  wrote:


Splitting it out to another repository within the compute umbrella (what
do we call it these days?) satisfies the _technical_ concern of not
being able to use placement without installing the rest of the nova code
and dependency tree. Artificially creating more "perceived" distance
sounds really political to me, so let's be sure we're upfront about the
reasoning for doing that if so :)


Characterizing the proposed separation as “artificial” seems to be quite 
political in itself.



Other than currently having a common set of interested people, is there
something about placement that makes it something that should be under the
compute umbrella?
I explained why I think placement belongs under the compute umbrella for 
now in my reply [1]. My reply might have been missed in the shuffle.


-melanie

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-August/133452.html





__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

On Fri, Aug 17, 2018 at 12:47:10PM -0500, Ed Leafe wrote:
> On Aug 17, 2018, at 12:30 PM, Dan Smith  wrote:
> > 
> > Splitting it out to another repository within the compute umbrella (what
> > do we call it these days?) satisfies the _technical_ concern of not
> > being able to use placement without installing the rest of the nova code
> > and dependency tree. Artificially creating more "perceived" distance
> > sounds really political to me, so let's be sure we're upfront about the
> > reasoning for doing that if so :)
> 
> Characterizing the proposed separation as “artificial” seems to be quite 
> political in itself.
> 

Other than currently having a common set of interested people, is there
something about placement that makes it something that should be under the
compute umbrella?

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

> 
> Has there been a discussion on record of how use of placement by cinder
> would affect "standalone" cinder (or manila) initiatives where there is a
> desire to be able to run cinder by itself (with no-auth) or just with
> keystone (where OpenStack style multi-tenancy is desired)?
> 
> Tom Barron (tbarron)
> 

A little bit. That would be one of the pieces that needs to be done if we were
to adopt it.

Just high level brainstorming, but I think we would need something like we have
now with using tooz where if it is configured for it, it will use etcd for
distributed locking. And for single node installs it just defaults to file
locks.


__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-17 Thread Doug Hellmann

Excerpts from Dan Smith's message of 2018-08-17 10:30:41 -0700:
> > The subject of using placement in Cinder has come up, and since then I've 
> > had a
> > few conversations with people in and outside of that team. I really think 
> > until
> > placement is its own project outside of the nova team, there will be 
> > resistance
> > from some to adopt it.
> 
> I know politics will be involved in this, but this is a really terrible
> reason to do a thing, IMHO. After the most recent meeting we had with
> the Cinder people on placement adoption, I'm about as convinced as ever
> that Cinder won't (and won't need to) _consume_ placement any time
> soon. I hope it will _report_ to placement so Nova can make better
> decisions, just like Neutron does now, but I think that's the extent
> we're likely to see if we're honest.
> 
> What other projects are _likely_ to _consume_ placement even if they
> don't know they'd want to? What projects already want to use it but
> refuse to because it has Nova smeared all over it? We talked about this
> a lot in the early justification for placement, but the demand for that
> hasn't really materialized, IMHO; maybe it's just me.
> 
> > This reluctance on having it part of Nova may be real or just perceived, but
> > with it within Nova it will likely be an uphill battle for some time 
> > convincing
> > other projects that it is a nicely separated common service that they can 
> > use.
> 
> Splitting it out to another repository within the compute umbrella (what
> do we call it these days?) satisfies the _technical_ concern of not
> being able to use placement without installing the rest of the nova code
> and dependency tree. Artificially creating more "perceived" distance
> sounds really political to me, so let's be sure we're upfront about the
> reasoning for doing that if so :)
> 
> --Dan
> 

If we ignore the political concerns in the short term, are there
other projects actually interested in using placement? With what
technical caveats? Perhaps with modifications of some sort to support
the needs of those projects?

Doug

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-17 Thread Ed Leafe

On Aug 17, 2018, at 12:30 PM, Dan Smith  wrote:
> 
> Splitting it out to another repository within the compute umbrella (what
> do we call it these days?) satisfies the _technical_ concern of not
> being able to use placement without installing the rest of the nova code
> and dependency tree. Artificially creating more "perceived" distance
> sounds really political to me, so let's be sure we're upfront about the
> reasoning for doing that if so :)

Characterizing the proposed separation as “artificial” seems to be quite 
political in itself.

Of course there are political factors; it would be naive to think otherwise. 
That’s why I’d like to get input from those people who are not in the middle of 
it, and have no political motivation. I’d like this to be a technical 
discussion, with as little political overtones as possible.

-- Ed Leafe

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-17 Thread Dan Smith

> The subject of using placement in Cinder has come up, and since then I've had 
> a
> few conversations with people in and outside of that team. I really think 
> until
> placement is its own project outside of the nova team, there will be 
> resistance
> from some to adopt it.

I know politics will be involved in this, but this is a really terrible
reason to do a thing, IMHO. After the most recent meeting we had with
the Cinder people on placement adoption, I'm about as convinced as ever
that Cinder won't (and won't need to) _consume_ placement any time
soon. I hope it will _report_ to placement so Nova can make better
decisions, just like Neutron does now, but I think that's the extent
we're likely to see if we're honest.

What other projects are _likely_ to _consume_ placement even if they
don't know they'd want to? What projects already want to use it but
refuse to because it has Nova smeared all over it? We talked about this
a lot in the early justification for placement, but the demand for that
hasn't really materialized, IMHO; maybe it's just me.

> This reluctance on having it part of Nova may be real or just perceived, but
> with it within Nova it will likely be an uphill battle for some time 
> convincing
> other projects that it is a nicely separated common service that they can use.

Splitting it out to another repository within the compute umbrella (what
do we call it these days?) satisfies the _technical_ concern of not
being able to use placement without installing the rest of the nova code
and dependency tree. Artificially creating more "perceived" distance
sounds really political to me, so let's be sure we're upfront about the
reasoning for doing that if so :)

--Dan

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-17 Thread Tom Barron


On 17/08/18 11:47 -0500, Jay S Bryant wrote:



On 8/17/2018 10:59 AM, Ed Leafe wrote:

On Aug 17, 2018, at 10:51 AM, Chris Dent  wrote:

One of the questions that has come up on the etherpad is about how
placement should be positioned, as a project, after the extraction.
The options are:

* A repo within the compute project
* Its own project, either:
 * working towards being official and governed
 * official and governed from the start

I would like to hear from the Cinder and Neutron teams, especially those who 
were around when those compute sub-projects were split off into their own 
projects. Did you feel that being independent of compute helped or hindered 
you? And to those who are in those projects now, is there any sense that things 
would be better if you were still part of compute?

Ed,

I started working with Cinder right after the split had taken place.  
I have had several discussions as to how the split took place and why 
over the years since.


In the case of Cinder we split because the pace at which things were 
changing in the Cinder project had exceeded what could be handled by 
the Nova team.  Nova has always been a busy project and the changes 
coming in for Nova Volume were getting lost in the larger Nova 
picture.  So, Nova Volume was broken out to become Cinder so that 
people could focus on the storage aspect of things and get change 
through more quickly.


So, I think, for the most part that it has been something that has 
benefited the project.  The exception would be all the challenges that 
have come working cross project on changes that impact both Cinder and 
Nova but that has improved over time.  Given the good leadership I 
envision for the Placement Service I think that is less of a concern.


For the placement service, I would expect that there will be a greater 
rate of change once more projects are using it.  This would also 
support splitting the service out.

My opinion has been that Placement should have been separate from the start. 
The longer we keep Placement inside of Nova, the more painful it will be to 
extract, and hence the likelihood of that every happening is greatly diminished.


I do agree that pulling the service out sooner than later is probably best.


Has there been a discussion on record of how use of placement by 
cinder would affect "standalone" cinder (or manila) initiatives where 
there is a desire to be able to run cinder by itself (with no-auth) or 
just with keystone (where OpenStack style multi-tenancy is desired)?


Tom Barron (tbarron)


-- Ed Leafe






__
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



__
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


__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-17 Thread melanie witt


On Fri, 17 Aug 2018 16:51:10 +0100 (BST), Chris Dent wrote:


Earlier I posted a message about a planning etherpad for the
extraction of placement

http://lists.openstack.org/pipermail/openstack-dev/2018-August/133319.html
https://etherpad.openstack.org/p/placement-extract-stein

One of the goals of doing the planning and having the etherpad was
to be able to get to the PTG with some of the issues resolved so
that what little time we had at the PTG could be devoted to
resolving any difficult technical details we uncovered in the lead
up.

One of the questions that has come up on the etherpad is about how
placement should be positioned, as a project, after the extraction.
The options are:

* A repo within the compute project
* Its own project, either:
* working towards being official and governed
* official and governed from the start

The etherpad has some discussion about this, but since that etherpad
is primarily for listing out the technical concerns I thought it
might be useful to bring the discussion out into a wider audience,
in a medium more oriented towards discussion. As placement is a
service targeted to serving the entire OpenStack community, talking
about it widely seems warranted.

The outcome I'd like to see happen is the one that makes sure
placement becomes useful to the most people and is worked on by the
most people, as quickly as possible. If how it is arranged as a
project will impact that, now is a good time to figure that out.

If you have thoughts about this, please share them in response.


Thanks for kicking off this discussion, Chris.

I'd like to see placement extracted as a repo within the compute 
project, as a start. My thinking is, placement was developed to solve 
several long-standing problems and limitations in Nova (including poor 
filter scheduler performance, parallel scheduling races, resource 
tracker issues, and shared storage accounting, just to name a few).


We've seen exciting progress in finally solving a lot of these issues as 
we've been developing placement. But, there is still a significant 
amount of important work to do in Nova that depends on placement. For 
example, we need to integrate nested resource providers into the virt 
drivers in Nova to leverage it for vGPUs and NUMA modeling. We need 
affinity modeling in placement to properly handle affinity with multiple 
cells. We need shared storage accounting to properly handle disk usage 
for deployments on shared storage.


As we've worked to develop placement and use it in Nova, we've found in 
most cases that we've had to develop the Nova side and the placement 
side together, at the same time, to make things work. This isn't really 
surprising, as with any brand new functionality, it's difficult to 
fulfill a use case completely without integrating things together and 
iterating until everything works. Given that, I'd rather see placement 
stay under compute so we can iterate quickly, as we still need to 
develop new features in placement and exercise them for the first time, 
in Nova. Once the major aforementioned efforts have been figured out and 
landed with close coordination, I think it would make more sense to look 
at placement being outside of the compute project.


Cheers,
-melanie





__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

2018-08-17 Thread Jay S Bryant




On 8/17/2018 10:59 AM, Ed Leafe wrote:

On Aug 17, 2018, at 10:51 AM, Chris Dent  wrote:

One of the questions that has come up on the etherpad is about how
placement should be positioned, as a project, after the extraction.
The options are:

* A repo within the compute project
* Its own project, either:
  * working towards being official and governed
  * official and governed from the start

I would like to hear from the Cinder and Neutron teams, especially those who 
were around when those compute sub-projects were split off into their own 
projects. Did you feel that being independent of compute helped or hindered 
you? And to those who are in those projects now, is there any sense that things 
would be better if you were still part of compute?

Ed,

I started working with Cinder right after the split had taken place.  I 
have had several discussions as to how the split took place and why over 
the years since.


In the case of Cinder we split because the pace at which things were 
changing in the Cinder project had exceeded what could be handled by the 
Nova team.  Nova has always been a busy project and the changes coming 
in for Nova Volume were getting lost in the larger Nova picture.  So, 
Nova Volume was broken out to become Cinder so that people could focus 
on the storage aspect of things and get change through more quickly.


So, I think, for the most part that it has been something that has 
benefited the project.  The exception would be all the challenges that 
have come working cross project on changes that impact both Cinder and 
Nova but that has improved over time.  Given the good leadership I 
envision for the Placement Service I think that is less of a concern.


For the placement service, I would expect that there will be a greater 
rate of change once more projects are using it.  This would also support 
splitting the service out.

My opinion has been that Placement should have been separate from the start. 
The longer we keep Placement inside of Nova, the more painful it will be to 
extract, and hence the likelihood of that every happening is greatly diminished.


I do agree that pulling the service out sooner than later is probably best.

-- Ed Leafe






__
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



__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?

On Fri, Aug 17, 2018 at 10:59:47AM -0500, Ed Leafe wrote:
> On Aug 17, 2018, at 10:51 AM, Chris Dent  wrote:
> > 
> > One of the questions that has come up on the etherpad is about how
> > placement should be positioned, as a project, after the extraction.
> > The options are:
> > 
> > * A repo within the compute project
> > * Its own project, either:
> >  * working towards being official and governed
> >  * official and governed from the start
> 
> I would like to hear from the Cinder and Neutron teams, especially those who 
> were around when those compute sub-projects were split off into their own 
> projects. Did you feel that being independent of compute helped or hindered 
> you? And to those who are in those projects now, is there any sense that 
> things would be better if you were still part of compute?
> 

I wasn't around at the beginning of the separation, but I don't think Cinder
would be anything like it is today (you can decide if that's a good thing or
not) if it had remained a component of Nova.

> My opinion has been that Placement should have been separate from the start. 
> The longer we keep Placement inside of Nova, the more painful it will be to 
> extract, and hence the likelihood of that every happening is greatly 
> diminished.

I have to agree with this statement.

> 
> 
> -- Ed Leafe
> 
> 
> 
> 
> 
> 
> __
> 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

__
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

Re: [openstack-dev] [all] [nova] [placement] placement below or beside compute after extraction?