On Wed, Aug 22, 2018 at 11:03:43AM -0700, melanie witt wrote:
[...]
[Randomly jumping in on one specific point.]
> Aside from that, it has always been difficult to add folks to
> nova-core because of the large scope and expertise needed to approve
> code across all of Nova.
The complexity of
On Sat, 2018-08-25 at 08:08 +0800, Alex Xu wrote:
>
>
> 2018-08-18 20:25 GMT+08:00 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
> > >
On Sat, 2018-08-25 at 08:08 +0800, Alex Xu wrote:
>
>
> 2018-08-18 20:25 GMT+08:00 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
> > >
2018-08-18 20:25 GMT+08:00 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
>>
Matt Riedemann wrote:
On 8/23/2018 4:00 AM, Thierry Carrez wrote:
In the OpenStack governance model, contributors to a given piece of
code control its destiny.
This is pretty damn fuzzy.
Yes, it's definitely not binary.
So if someone wants to split out nova-compute
into a new
On 8/23/2018 4:00 AM, Thierry Carrez wrote:
In the OpenStack governance model, contributors to a given piece of code
control its destiny.
This is pretty damn fuzzy. So if someone wants to split out nova-compute
into a new repo/project/governance with a REST API and all that,
nova-core has no
On 8/22/2018 1:25 PM, Jeremy Stanley wrote:
On 2018-08-22 11:03:43 -0700 (-0700), melanie witt wrote:
[...]
I think it's about context. If two separate projects do their own priority
and goal setting, separately, I think they will naturally be more different
than they would be if they were one
melanie witt wrote:
[...]
I have been trying to explain why over several replies to this thread.
Fracturing a group is not something anyone does to foster cooperation
and shared priorities and goals.
[...]
I would argue that the group is already fractured, otherwise we would
not even be
On 2018-08-22 00:17:41 + (+), Fox, Kevin M wrote:
> 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
On 2018-08-22 11:03:43 -0700 (-0700), melanie witt wrote:
[...]
> I think it's about context. If two separate projects do their own priority
> and goal setting, separately, I think they will naturally be more different
> than they would be if they were one project. Currently, we agree on goals
>
On Wed, 22 Aug 2018 09:49:13 -0400, Doug Hellmann wrote:
Excerpts from melanie witt's message of 2018-08-21 15:05:00 -0700:
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
Excerpts from melanie witt's message of 2018-08-21 15:05:00 -0700:
> 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:
On Sat, Aug 18, 2018 at 2:25 PM, 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
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
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,
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
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
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:
> Excer
> 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
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,
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
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
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
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,
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
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.
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 tha
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
: 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 bigges
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
>>
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
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
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
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
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
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
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
> >
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
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
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
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
>> 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
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
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.
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
> 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
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
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
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
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
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
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
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
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_
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
>
> 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
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
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.
> 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
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
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
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
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
On Fri, Aug 17, 2018 at 04:51:10PM +0100, Chris Dent wrote:
>
> [snip]
>
> 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,
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
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
81 matches
Mail list logo
