date:20180821

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] [Searchlight] Reaching out to the Searchlight core members for Stein - Call for team meeting

Thanks Matt.


*Trinh Nguyen *| Founder & Chief Architect



*E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *



On Tue, Aug 21, 2018 at 10:53 PM Matt Riedemann  wrote:

> On 8/20/2018 10:10 AM, Trinh Nguyen wrote:
> >
> > Thanks for your response. What is your IRC handler?
>
> Kevin_Zheng.
>
> --
>
> 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] [TC][Searchlight] Setting up milestones for Searchlight on Launchpad

Hi Kendall,

Thanks for offering the help. Sure, please do that.

Let me know if you need anything.

Bests,


*Trinh Nguyen *| Founder & Chief Architect



*E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *



On Wed, Aug 22, 2018 at 3:16 AM Kendall Nelson 
wrote:

> Hello Trinh,
>
> Since Searchlight is in flux right now, it might be an appropriate time to
> consider migrating to StoryBoard from Launchpad. Since you are working on
> getting organized and figuring out the state of Seachlight, it might make
> more sense to do that in the new tool, rather than doing it now in
> Launchpad and then again in the future when you migrate to Storyboard down
> the road.
>
> If this sounds like something you want to look into, let me know and I can
> do a test migration into our dev environment. If that works out, I expect
> we could migrate you before the end of the week.
>
> -Kendall Nelson (diablo_rojo)
>
> On Tue, Aug 21, 2018 at 2:21 AM Trinh Nguyen 
> wrote:
>
>> Hi Thierry,
>>
>> I just saw that link. Thanks :)
>>
>> Because I couldn't contact any of the core members I emailed this list. I
>> will update the searchlight-core as planned after I am added.
>>
>> Thanks for your response,
>>
>> *Trinh Nguyen *| Founder & Chief Architect
>>
>> 
>>
>> *E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *
>>
>>
>>
>> On Tue, Aug 21, 2018 at 6:15 PM Thierry Carrez 
>> wrote:
>>
>>> Trinh Nguyen wrote:
>>> > In an effort to get Searchlight back on track, I would like to set up
>>> > milestones as well as clean up the incomplete bugs, blueprints etc. on
>>> > Launchpad [1] I was added to the Searchlight Drivers team but I still
>>> > can not touch the milestone configuration.
>>>
>>> As a member of the "maintainer" team in Launchpad you should be able to
>>> register a series ("stein") and then add milestones to that series. You
>>> should see a "Register a series" link under "Series and milestones" at
>>> https://launchpad.net/searchlight
>>>
>>> > In addition, I would like to move forward with unreviewed patched on
>>> > Gerrit so I need PTL privileges on Searchlight project. Do I have to
>>> > wait for [2] to be merged?
>>>
>>> For the TC to step in and add you to searchlight-core, yes, we'll have
>>> to wait for the merging of that patch.
>>>
>>> To go faster, you could ask any of the existing members in that group to
>>> directly add you:
>>>
>>> https://review.openstack.org/#/admin/groups/964,members
>>>
>>> (NB: this group looks like it should be updated :) )
>>>
>>> --
>>> 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
>>>
>> __
>> 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?


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] [magnum] K8s Conformance Testing

2018-08-21 Thread Mohammed Naser

Hi Chris,

This is an awesome effort. We can provide nested virt resources which are 
leveraged by Kata at the moment. 

Thanks!
Mohammed

Sent from my iPhone

> On Aug 21, 2018, at 6:38 PM, Chris Hoge  wrote:
> 
> As discussed at the Vancouver SIG-K8s and Copenhagen SIG-OpenStack sessions,
> we're moving forward with obtaining Kubernetes Conformance certification for
> Magnum. While conformance test jobs aren't reliably running in the gate yet,
> the requirements of the program make sumbitting results manually on an
> infrequent basis something that we can work with while we wait for more
> stable nested virtualization resources. The OpenStack Foundation has signed
> the license agreement, and Feilong Wang is preparing an initial conformance
> run to submit for certification.
> 
> My thanks to the Magnum team for their impressive work on building out an
> API for deploying Kubernetes on OpenStack clusters.
> 
> [1] https://www.cncf.io/certification/software-conformance/
> 
> __
> 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?

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

[openstack-dev] [magnum] K8s Conformance Testing

2018-08-21 Thread Chris Hoge

As discussed at the Vancouver SIG-K8s and Copenhagen SIG-OpenStack sessions,
we're moving forward with obtaining Kubernetes Conformance certification for
Magnum. While conformance test jobs aren't reliably running in the gate yet,
the requirements of the program make sumbitting results manually on an
infrequent basis something that we can work with while we wait for more
stable nested virtualization resources. The OpenStack Foundation has signed
the license agreement, and Feilong Wang is preparing an initial conformance
run to submit for certification.

My thanks to the Magnum team for their impressive work on building out an
API for deploying Kubernetes on OpenStack clusters.

[1] https://www.cncf.io/certification/software-conformance/

__
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 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] New Contributor

2018-08-21 Thread Ivoline Ngong

Thanks KendallWith the link you sent, I succesfully joined IRC  





On Tue, Aug 21, 2018 9:10 PM, Kendall Nelson kennelso...@gmail.com  wrote:
Ivoline,
If you need help getting on IRC[1] or setup with any of the other tools we use,
please let me know!
[1]https://docs.openstack.org/contributors/common/irc.html
-Kendall Nelson
On Tue, Aug 21, 2018 at 4:44 AM Telles Nobrega  wrote:
That is great to hear. Plese join us at #openstack-sahara so we can discuss a
little more of what work you want to do.
Welcome aboard.
On Tue, Aug 21, 2018 at 5:22 AM Ivoline Ngong  wrote:
Hello Kendall and Telles,
Thanks so much for warm welcome. I feel at home already.The links sent were
quire helpful and gave me an insight into what OpenStack is all about.After
reading lightly about the different projects, the Sahara project caught my
attention.
Probably because I am interested in data science. I will love to explore the
Sahara project some more.
Cheers,Ivoline  





On Mon, Aug 20, 2018 8:42 PM, Telles Nobrega tenob...@redhat.com  wrote:
Hi Ivoline,
Also a little late but wanted to say welcome aboard, hopefully you will find a
very welcoming community here and of course a lot of work to do.
I work with Sahara, the big data processing project of OpenStack, we need help
for sure.
If this area interests you in any way, feel free to join us at #openstack-sahara
on IRC or email me and we can send some work at your direction.

On Mon, Aug 20, 2018 at 2:37 PM Kendall Nelson  wrote:
Hello Ivoline,
While I'm a little late to the party, I still wanted to say welcome and offer my
help :)
If you have any questions based about the links you've been sent, I'm happy to
answer them! I can also help you find/get started with a team and introduce you
to community members whenever you're ready.
-Kendall Nelson (diablo_rojo)

On Mon, 20 Aug 2018, 4:08 am Ivoline Ngong,  wrote:
Thanks so much for help Josh and Thierry. I'll check out the links and hopefully
find a way forward from there. Will get back here in case I have any questions.
Cheers,Ivoline
On Mon, Aug 20, 2018, 12:01 Thierry Carrez  wrote:
Ivoline Ngong wrote:
> I am Ivoline Ngong. I am a Cameroonian who lives in Turkey. I will love 
> to contribute to Open source through OpenStack. I code in Java and 
> Python and I think OpenStack is a good fit for me.
> I'll appreciate it if you can point me to the right direction on how I 
> can get started.

Hi Ivoline,

Welcome to the OpenStack community !

The OpenStack Technical Committee maintains a list of areas in most need 
of help:

https://governance.openstack.org/tc/reference/help-most-needed.html

Depending on your interest, you could pick one of those projects and 
reach out to the mentioned contact points.

For more general information on how to contribute, you can check out our 
contribution portal:

https://www.openstack.org/community/

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

SOFTWARE ENGINEER

Red Hat Brasil

Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo

tenob...@redhat.com

TRIED. TESTED. TRUSTED. Red Hat é reconhecida entre as melhores empresas para
trabalhar no Brasil peloGreat Place to Work.
__
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
-- 
TELLESNOBREGA

SOFTWARE ENGINEER

Red Hat Brasil

Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo

tenob...@redhat.com

TRIED. TESTED. TRUSTED. Red Hat é reconhecida entre as melhores empresas para
trabalhar no Brasil peloGreat Place to Work.
__
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:

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] [Openstack-sigs] UC Elections will not be held

2018-08-21 Thread Amy Marrich

Congrats to VW and Joseph. Thank you to Saverio for his hard work. And
lastly thank you to Ed, Chandan, and Mohamed for serving as our election
officials!

Amy (spotz)
User Committee

On Tue, Aug 21, 2018 at 2:44 PM, Ed Leafe  wrote:

> As there were only 2 nominations for the 2 open seats, elections will not
> be needed. Congratulations to Matt Van Winkle and Joseph Sandoval!
>
> -- Ed Leafe
>
>
>
>
>
>
> ___
> openstack-sigs mailing list
> openstack-s...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs
>
__
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] [User-committee] UC Elections will not be held

2018-08-21 Thread Edgar Magana

Congratulations Matt and Joseph!

Our community is in good hands with your leadership, looking forward to seeing 
you in Berlin. Do not hesitate to ask for help at any time.

Edgar

On 8/21/18, 12:45 PM, "Ed Leafe"  wrote:

As there were only 2 nominations for the 2 open seats, elections will not 
be needed. Congratulations to Matt Van Winkle and Joseph Sandoval!

-- Ed Leafe






___
User-committee mailing list
user-commit...@lists.openstack.org

https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_user-2Dcommittee=DwIGaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=zJVnmWwuk3H0ySNWzMvn_WFZHaXuHfYFrGXivVpZ4I8=b5cPci7YTmu4pkYg7k429mism5WKSUOkJpnub4U_Fp8=


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

[openstack-dev] UC Elections will not be held

2018-08-21 Thread Ed Leafe

As there were only 2 nominations for the 2 open seats, elections will not be 
needed. Congratulations to Matt Van Winkle and Joseph Sandoval!

-- 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] [barbican][oslo][release][requirements] FFE request for castellan

2018-08-21 Thread Matthew Thode

On 18-08-21 14:00:41, Ben Nemec wrote:
> Because castellan is in global-requirements, we need an FFE from
> requirements too.  Can someone from the requirements team respond to the
> review?  Thanks.
> 
> On 08/16/2018 04:34 PM, Ben Nemec wrote:
> > The backport has merged and I've proposed the release here:
> > https://review.openstack.org/592746
> > 
> > On 08/15/2018 11:58 AM, Ade Lee wrote:
> > > Done.
> > > 
> > > https://review.openstack.org/#/c/592154/
> > > 
> > > Thanks,
> > > Ade
> > > 
> > > On Wed, 2018-08-15 at 09:20 -0500, Ben Nemec wrote:
> > > > 
> > > > On 08/14/2018 01:56 PM, Sean McGinnis wrote:
> > > > > > On 08/10/2018 10:15 AM, Ade Lee wrote:
> > > > > > > Hi all,
> > > > > > > 
> > > > > > > I'd like to request a feature freeze exception to get the
> > > > > > > following
> > > > > > > change in for castellan.
> > > > > > > 
> > > > > > > https://review.openstack.org/#/c/575800/
> > > > > > > 
> > > > > > > This extends the functionality of the vault backend to provide
> > > > > > > previously uninmplemented functionality, so it should not break
> > > > > > > anyone.
> > > > > > > 
> > > > > > > The castellan vault plugin is used behind barbican in the
> > > > > > > barbican-
> > > > > > > vault plugin.  We'd like to get this change into Rocky so that
> > > > > > > we can
> > > > > > > release Barbican with complete functionality on this backend
> > > > > > > (along
> > > > > > > with a complete set of passing functional tests).
> > > > > > 
> > > > > > This does seem fairly low risk since it's just implementing a
> > > > > > function that
> > > > > > previously raised a NotImplemented exception.  However, with it
> > > > > > being so
> > > > > > late in the cycle I think we need the release team's input on
> > > > > > whether this
> > > > > > is possible.  Most of the release FFE's I've seen have been for
> > > > > > critical
> > > > > > bugs, not actual new features.  I've added that tag to this
> > > > > > thread so
> > > > > > hopefully they can weigh in.
> > > > > > 
> > > > > 
> > > > > As far as releases go, this should be fine. If this doesn't affect
> > > > > any other
> > > > > projects and would just be a late merging feature, as long as the
> > > > > castellan
> > > > > team has considered the risk of adding code so late and is
> > > > > comfortable with
> > > > > that, this is OK.
> > > > > 
> > > > > Castellan follows the cycle-with-intermediary release model, so the
> > > > > final Rocky
> > > > > release just needs to be done by next Thursday. I do see the
> > > > > stable/rocky
> > > > > branch has already been created for this repo, so it would need to
> > > > > merge to
> > > > > master first (technically stein), then get cherry-picked to
> > > > > stable/rocky.
> > > > 
> > > > Okay, sounds good.  It's already merged to master so we're good
> > > > there.
> > > > 
> > > > Ade, can you get the backport proposed?
> > > > 

I've approved it for a UC only bump

-- 
Matthew Thode (prometheanfire)


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] [barbican][oslo][release][requirements] FFE request for castellan

2018-08-21 Thread Ben Nemec

Because castellan is in global-requirements, we need an FFE from 
requirements too.  Can someone from the requirements team respond to the 
review?  Thanks.


On 08/16/2018 04:34 PM, Ben Nemec wrote:
The backport has merged and I've proposed the release here: 
https://review.openstack.org/592746


On 08/15/2018 11:58 AM, Ade Lee wrote:

Done.

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

Thanks,
Ade

On Wed, 2018-08-15 at 09:20 -0500, Ben Nemec wrote:


On 08/14/2018 01:56 PM, Sean McGinnis wrote:

On 08/10/2018 10:15 AM, Ade Lee wrote:

Hi all,

I'd like to request a feature freeze exception to get the
following
change in for castellan.

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

This extends the functionality of the vault backend to provide
previously uninmplemented functionality, so it should not break
anyone.

The castellan vault plugin is used behind barbican in the
barbican-
vault plugin.  We'd like to get this change into Rocky so that
we can
release Barbican with complete functionality on this backend
(along
with a complete set of passing functional tests).


This does seem fairly low risk since it's just implementing a
function that
previously raised a NotImplemented exception.  However, with it
being so
late in the cycle I think we need the release team's input on
whether this
is possible.  Most of the release FFE's I've seen have been for
critical
bugs, not actual new features.  I've added that tag to this
thread so
hopefully they can weigh in.



As far as releases go, this should be fine. If this doesn't affect
any other
projects and would just be a late merging feature, as long as the
castellan
team has considered the risk of adding code so late and is
comfortable with
that, this is OK.

Castellan follows the cycle-with-intermediary release model, so the
final Rocky
release just needs to be done by next Thursday. I do see the
stable/rocky
branch has already been created for this repo, so it would need to
merge to
master first (technically stein), then get cherry-picked to
stable/rocky.


Okay, sounds good.  It's already merged to master so we're good
there.

Ade, can you get the backport proposed?

_
_
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
cribe
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


__
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-dev] octavia 3.0.0.0rc2 (rocky)


Hello everyone,

A new release candidate for octavia for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/octavia/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

https://git.openstack.org/cgit/openstack/octavia/log/?h=stable/rocky

Release notes for octavia can be found at:

https://docs.openstack.org/releasenotes/octavia/




__
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-dev] neutron-lbaas-dashboard 5.0.0.0rc2 (rocky)


Hello everyone,

A new release candidate for neutron-lbaas-dashboard for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/neutron-lbaas-dashboard/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:


https://git.openstack.org/cgit/openstack/neutron-lbaas-dashboard/log/?h=stable/rocky

Release notes for neutron-lbaas-dashboard can be found at:

https://docs.openstack.org/releasenotes/neutron-lbaas-dashboard/

If you find an issue that could be considered release-critical, please
file it at:

https://storyboard.openstack.org/#!/project/907

and tag it *rocky-rc-potential* to bring it to the neutron-lbaas-dashboard
release crew's attention.


__
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-dev] octavia-dashboard 2.0.0.0rc2 (rocky)


Hello everyone,

A new release candidate for octavia-dashboard for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/octavia-dashboard/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:


https://git.openstack.org/cgit/openstack/octavia-dashboard/log/?h=stable/rocky

Release notes for octavia-dashboard can be found at:

https://docs.openstack.org/releasenotes/octavia-dashboard/

If you find an issue that could be considered release-critical, please
file it at:

https://storyboard.openstack.org/#!/project/909

and tag it *rocky-rc-potential* to bring it to the octavia-dashboard
release crew's attention.


__
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-dev] [goals][python3] please check with me before submitting any zuul migration patches

2018-08-21 Thread Doug Hellmann

We have a few folks eager to join in and contribute to the python3 goal
by helping with the patches to migrate zuul settings. That's great!
However, many of the patches being proposed are incorrect, which means
there is either something wrong with the tool or the way it is used.

The intent was to have a very small group, 3-4 people, who knew how
the tools worked to propose all of those patches.  Having incorrect
patches can break the CI for a project, so we need to be especially
careful with them.  We do not want every team writing the patches
for themselves, and we do not want lots and lots of people who we
have to train to use the tools.

If you are not one of the people already listed as a goal champion
on [1], please PLEASE stop writing patches and get in touch with
me personally and directly (via IRC or email) BEFORE doing any more
work on the goal.

Thanks,
Doug

[1] https://governance.openstack.org/tc/goals/stein/python3-first.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] [Freezer] Reactivate the team

2018-08-21 Thread Kendall Nelson

If you also wanted to add migrating from Launchpad to Storyboard to this
list I am happy to help do the test migration and coordinate the real
migration.

-Kendall (diablo_rojo)

On Fri, Aug 17, 2018 at 6:50 PM Trinh Nguyen  wrote:

> Dear Freezer team,
>
> Since we have appointed a new PTL for the Stein cycle (gengchc2), I
> suggest that we should reactivate the team follows these actions:
>
>1. Have a team meeting to formalize the new leader as well as discuss
>the new direction.
>2. Grant PTL privileges for gengchc2 on Launchpad and Project Gerrit
>repositories.
>3. Reorganize the core team to make sure we have enough active core
>reviewers for new patches.
>4. Clean up bug reports, blueprints on Launchpad, as well as
>unreviewed patched on Gerrit.
>
> I hope that we can revive Freezer.
>
> Best regards,
>
> *Trinh Nguyen *| Founder & Chief Architect
>
> 
>
> *E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *
>
> __
> 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 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] [TC][Searchlight] Setting up milestones for Searchlight on Launchpad

2018-08-21 Thread Kendall Nelson

Hello Trinh,

Since Searchlight is in flux right now, it might be an appropriate time to
consider migrating to StoryBoard from Launchpad. Since you are working on
getting organized and figuring out the state of Seachlight, it might make
more sense to do that in the new tool, rather than doing it now in
Launchpad and then again in the future when you migrate to Storyboard down
the road.

If this sounds like something you want to look into, let me know and I can
do a test migration into our dev environment. If that works out, I expect
we could migrate you before the end of the week.

-Kendall Nelson (diablo_rojo)

On Tue, Aug 21, 2018 at 2:21 AM Trinh Nguyen  wrote:

> Hi Thierry,
>
> I just saw that link. Thanks :)
>
> Because I couldn't contact any of the core members I emailed this list. I
> will update the searchlight-core as planned after I am added.
>
> Thanks for your response,
>
> *Trinh Nguyen *| Founder & Chief Architect
>
> 
>
> *E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *
>
>
>
> On Tue, Aug 21, 2018 at 6:15 PM Thierry Carrez 
> wrote:
>
>> Trinh Nguyen wrote:
>> > In an effort to get Searchlight back on track, I would like to set up
>> > milestones as well as clean up the incomplete bugs, blueprints etc. on
>> > Launchpad [1] I was added to the Searchlight Drivers team but I still
>> > can not touch the milestone configuration.
>>
>> As a member of the "maintainer" team in Launchpad you should be able to
>> register a series ("stein") and then add milestones to that series. You
>> should see a "Register a series" link under "Series and milestones" at
>> https://launchpad.net/searchlight
>>
>> > In addition, I would like to move forward with unreviewed patched on
>> > Gerrit so I need PTL privileges on Searchlight project. Do I have to
>> > wait for [2] to be merged?
>>
>> For the TC to step in and add you to searchlight-core, yes, we'll have
>> to wait for the merging of that patch.
>>
>> To go faster, you could ask any of the existing members in that group to
>> directly add you:
>>
>> https://review.openstack.org/#/admin/groups/964,members
>>
>> (NB: this group looks like it should be updated :) )
>>
>> --
>> 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
>>
> __
> 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 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] New Contributor

2018-08-21 Thread Kendall Nelson

Ivoline,

If you need help getting on IRC[1] or setup with any of the other tools we
use, please let me know!

[1] https://docs.openstack.org/contributors/common/irc.html

-Kendall Nelson

On Tue, Aug 21, 2018 at 4:44 AM Telles Nobrega  wrote:

> That is great to hear. Plese join us at #openstack-sahara so we can
> discuss a little more of what work you want to do.
>
> Welcome aboard.
>
> On Tue, Aug 21, 2018 at 5:22 AM Ivoline Ngong 
> wrote:
>
>> Hello Kendall and Telles,
>>
>> Thanks so much for warm welcome. I feel at home already.
>> The links sent were quire helpful and gave me an insight into what
>> OpenStack is all about.
>> After reading lightly about the different projects, the Sahara project
>> caught my attention.
>>
>> Probably because I am interested in data science. I will love to explore
>> the Sahara project some more.
>>
>> Cheers,
>> Ivoline
>>
>>
>>
>> On Mon, Aug 20, 2018 8:42 PM, Telles Nobrega tenob...@redhat.com wrote:
>>
>>> Hi Ivoline,
>>>
>>> Also a little late but wanted to say welcome aboard, hopefully you will
>>> find a very welcoming community here and of course a lot of work to do.
>>>
>>> I work with Sahara, the big data processing project of OpenStack, we
>>> need help for sure.
>>>
>>> If this area interests you in any way, feel free to join us at
>>> #openstack-sahara on IRC or email me and we can send some work at your
>>> direction.
>>>
>>>
>>> On Mon, Aug 20, 2018 at 2:37 PM Kendall Nelson 
>>> wrote:
>>>
>>> Hello Ivoline,
>>>
>>> While I'm a little late to the party, I still wanted to say welcome and
>>> offer my help :)
>>>
>>> If you have any questions based about the links you've been sent, I'm
>>> happy to answer them! I can also help you find/get started with a team and
>>> introduce you to community members whenever you're ready.
>>>
>>> -Kendall Nelson (diablo_rojo)
>>>
>>>
>>> On Mon, 20 Aug 2018, 4:08 am Ivoline Ngong, 
>>> wrote:
>>>
>>> Thanks so much for help Josh and Thierry. I'll check out the links and
>>> hopefully find a way forward from there. Will get back here in case I have
>>> any questions.
>>>
>>> Cheers,
>>> Ivoline
>>>
>>> On Mon, Aug 20, 2018, 12:01 Thierry Carrez 
>>> wrote:
>>>
>>> Ivoline Ngong wrote:
>>> > I am Ivoline Ngong. I am a Cameroonian who lives in Turkey. I will
>>> love
>>> > to contribute to Open source through OpenStack. I code in Java and
>>> > Python and I think OpenStack is a good fit for me.
>>> > I'll appreciate it if you can point me to the right direction on how I
>>> > can get started.
>>>
>>> Hi Ivoline,
>>>
>>> Welcome to the OpenStack community !
>>>
>>> The OpenStack Technical Committee maintains a list of areas in most need
>>> of help:
>>>
>>> https://governance.openstack.org/tc/reference/help-most-needed.html
>>>
>>> Depending on your interest, you could pick one of those projects and
>>> reach out to the mentioned contact points.
>>>
>>> For more general information on how to contribute, you can check out our
>>> contribution portal:
>>>
>>> https://www.openstack.org/community/
>>>
>>> --
>>> 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
>>>
>>>
>>> __
>>> 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
>>>
>>> --
>>>
>>> TELLES NOBREGA
>>>
>>> SOFTWARE ENGINEER
>>>
>>> Red Hat Brasil  
>>>
>>> Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo
>>>
>>> tenob...@redhat.com
>>> 
>>> TRIED. TESTED. TRUSTED. 
>>>  Red Hat é reconhecida entre as melhores empresas para trabalhar no
>>> Brasil pelo Great Place to Work.
>>>
>> __
>> 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
>>
> --
>
> TELLES NOBREGA
>
> SOFTWARE ENGINEER
>
> Red Hat Brasil  
>
> Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo
>
> tenob...@redhat.com
> 
> TRIED. TESTED. TRUSTED. 
>  Red Hat é reconhecida entre as melhores empresas para

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] [ironic] Next bug day is Tuesday August 28th! Vote for timeslot!

2018-08-21 Thread Michael Turek


Hello,

With the next bug day coming in a week from today, I wanted to bring up 
the timeslot poll we have going again.

https://doodle.com/poll/ef4m9zmacm2ey7ce

I'd like to finalize a time slot for this on Thursday so if you want to 
cast your vote, please do it soon! Hope to see you there!


Thanks,
Mike Turek

On 8/2/18 11:24 AM, Michael Turek wrote:

Hey all!

Bug day was pretty productive today and we decided to schedule another 
one for the end of this month, on Tuesday the 28th. For details see 
the etherpad for the event [0]


Also since we're changing things up, we decided to also put up a vote 
for the timeslot [1]


If you have any questions or suggestions on how to improve bug day, I 
am all ears! Hope to see you there!


Thanks,
Mike Turek 

[0] https://etherpad.openstack.org/p/ironic-bug-day-august-28-2018
[1] https://doodle.com/poll/ef4m9zmacm2ey7ce


__ 


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-dev] [nova][neutron] Proposal to make SR-IOV port attach explicitly fail in nova

None of the in-tree nova virt drivers support attaching SR-IOV ports to 
a running instance, you can only create a server with an SR-IOV port. I 
have a patch proposed [1] to make this an explicit failure rather than 
the user getting an obscure 500 KeyError failure. Supporting this would 
be a feature change [2].


However, the out of tree powervm driver apparently supports attaching 
SR-IOV ports to running servers, so I'm sending this email to make any 
other out of tree virt drivers aware of the change to make it explicitly 
fail in case they also support his functionality downstream.


[1] https://review.openstack.org/#/c/591898/
[2] 
https://blueprints.launchpad.net/nova/+spec/sriov-interface-attach-detach


--

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] Stepping down from Ironic core

2018-08-21 Thread Jim Rollenhagen

On Tue, Aug 21, 2018 at 11:00 AM, Julia Kreger 
wrote:

> This is sad news to read, but completely understandable!
>
> Thank you for all of your excellent work on Ironic, and should time
> and focus ever make sense later down the road for you to rejoin
> ironic-core, know you'll be welcomed back.
>

+1000. Thanks for all the great work you've done, even if it means you now
have dents in your forehead from banging it against the wall making grenade
and friends happy. :)

Hope to see you around \o

// jim
__
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] Stepping down from Ironic core

2018-08-21 Thread Julia Kreger

This is sad news to read, but completely understandable!

Thank you for all of your excellent work on Ironic, and should time
and focus ever make sense later down the road for you to rejoin
ironic-core, know you'll be welcomed back.

Thanks again!

-Julia

On Tue, Aug 21, 2018 at 8:38 AM, John Villalovos
 wrote:
> Good morning Ironic,
>
> I have come to realize that I don't have the time needed to be able to
> devote the attention needed to continue as an Ironic core.
>
> I'm hopeful that in the future I will work on Ironic or OpenStack again! :)
>
> The Ironic (and OpenStack) community has been a great one and I have really
> enjoyed my time working on it and working with all the people. I will still
> be hanging around on IRC and you may see me submitting a patch here and
> there too :)
>
> Thanks again,
> John
>
> __
> 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-dev] Stepping down from Ironic core

2018-08-21 Thread John Villalovos

Good morning Ironic,

I have come to realize that I don't have the time needed to be able to
devote the attention needed to continue as an Ironic core.

I'm hopeful that in the future I will work on Ironic or OpenStack again! :)

The Ironic (and OpenStack) community has been a great one and I have really
enjoyed my time working on it and working with all the people. I will still
be hanging around on IRC and you may see me submitting a patch here and
there too :)

Thanks again,
John
__
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-dev] Pending patches of openstack/intel-nfv-ci-tests Project

2018-08-21 Thread Katsaounis Molyvas Stamatios

Dear all,



I am sending you this email because there exists an effort to integrate Intel 
NFV CI tests tempest plugin with Opnfv Functional Testing project 
(https://wiki.opnfv.org/display/functest).



In order to integrate them though, there are some pending patches which should 
be merged in order to make intel test cases functional to multi-node 
environments.



I have already managed to run them successfully on a multi node environment by 
cherry-picking all the patches together in master branch.



Apart from Artom' s patches, me and my colleague Dimitris (cc), have pushed 
some changes too.



The pending patches are the following:

https://review.openstack.org/576606

https://review.openstack.org/593604

https://review.openstack.org/576607

https://review.openstack.org/576605

https://review.openstack.org/590303

https://review.openstack.org/576604

https://review.openstack.org/571004



I would like to know when will they be merged in order to proceed to the 
completion of the integration with the FuncTest project.



I am willing to offer my help, if it is needed, in order to get the job done. 
Thank you all in advance.



Kind regards,

Stamatis



Stamatis Katsaounis
Software Enginner

Software Development Center
__
Intracom Telecom
19.7 km Markopoulou Ave., Peania, GR 19002
t:   +30 2106677689
  mok...@intracom-telecom.com
  http://www.intracom-telecom.com/



















JOIN US

Mobile World Congress Americas

12-14 September
Los Angeles, USA



Gitex Technology Week

14-18 October
Dubai, UAE



FutureCom

15-18 October

Sao Paulo, Brazil



AfricaCom

13-15 November

Cape Town, S. Africa



Mobile World Congress

25-28 February 2019

Barcelona, Spain



Mobile World Congress Shanghai

26-28 June 2019
Shanghai, China




The information in this e-mail message and any attachments are intended only 
for the individual or entity to whom it is addressed and may be confidential. 
If you have received this transmission in error, and you are not an intended 
recipient, be aware that any copying, disclosure, distribution or use of this 
transmission or its contents is prohibited. Intracom Telecom and the sender 
accept no liability for any loss, disruption or damage to your data or computer 
system that may occur while using data contained in, or transmitted with, this 
email. Views or opinions expressed in this message may be those of the author 
and may not necessarily represent those of Intracom Telecom.





__
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-dev] [cinder][manila] Team Dinner Planning at PTG...

2018-08-21 Thread Jay S Bryant


All,

We talked in the Cinder team meeting about doing a joint Cinder/Manila 
team dinner at the PTG in Denver.


I have created a Doodle Poll to indicate what night would work best for 
everyone. [1]  Also, if you are planning to come please add your name in 
the Cinder Etherpad [2].


Look forward to seeing you all at the PTG!

Jay

[1] https://doodle.com/poll/8rm3ahdyhmrtx5gp#table

[2] https://etherpad.openstack.org/p/cinder-ptg-planning-denver-9-2018


__
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-dev] [goal][python3] dealing with new jobs failing on old branches

2018-08-21 Thread Doug Hellmann

Goal champions,

Most of the jobs in the project-templates do not have branch
specifiers.  That allows us to add a job to a repository and then
not realize that it doesn't work on an old branch. We're finding
some of those with this zuul migration (for example,
https://review.openstack.org/#/c/593012/ and
https://review.openstack.org/#/c/593016/).

To deal with these, we need to remove that job or template from the
repository's settings in the project-config repository, and not include
it in the import patches.

1. First we want to wait for the team to land as many of the unaltered
   import patches as possible, so those jobs stay on the master branch
   and recent stable branches where they work.

2. Then, propose a patch to project-config to remove just the problem jobs
   and templates from the repositories where they are a problem.

3. Then, rebase the patch that removes all of a team's project settings
   on top of the one created in step 2.

4. Finally, modify the import patch(es) on the older stable branches
   where the jobs fail and remove the jobs or templates that cause
   problems.  Set those patches to depend on the patch created in
   step 2, since they cannot land without the project-config change.

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?


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] [Searchlight] Reaching out to the Searchlight core members for Stein - Call for team meeting


On 8/20/2018 10:10 AM, Trinh Nguyen wrote:


Thanks for your response. What is your IRC handler?


Kevin_Zheng.

--

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] [mistral] No Denver PTG Sessions

2018-08-21 Thread Renat Akhmerov

It’s disappointing that we can’t make it this time. Really bad coincidence of 
different issues..

I’d love to have a virtual PTG and Dmitry’s notes look very helpful to me.

Thanks

Renat Akhmerov
@Nokia
On 21 Aug 2018, 17:15 +0700, Dmitry Tantsur , wrote:
> On 08/21/2018 10:22 AM, Dougal Matthews wrote:
> > Hi all,
> >
> > Unfortunately due to some personal conflicts and trouble with travel plans,
> > there will be no Mistral cores at the Denver PTG. This means that we have 
> > had to
> > cancel the Mistral sessions. I recently asked if anyone was planning to 
> > attend
> > and only got one maybe.
> >
> > I am considering trying to arrange a "virtual PTG", so we can do some 
> > planning
> > for Stein. However, I'm not sure how/if that could work. Do you think this 
> > would
> > be a good idea? Suggestions how to organise one would be very welcome!
>
> We did a few virtual midcycles for ironic, and it ended up quite well. While 
> it
> did require some people to stay awake at unusual times, it did allow people
> without travel budget to attend.
>
> Initially we used the OpenStack SIP system, but we found Bluejeans to be a bit
> easier to use. I think it has a limit of 300 participants, which is more than
> enough. Anyone from Red Hat can host it.
>
> We dedicated 1-2 days with 4-5 hours each. I'd recommend against taking up the
> whole day - will be too exhausting. The first time we tried splitting the 
> slots
> into two per day: APAC friendly and EMEA friendly. Relatively few people 
> showed
> up at the former, so the next time we only had one slot.
>
> As with the PTG, having an agenda upfront helps a lot. We did synchronization
> and notes through an etherpad - exactly the same was as on the PTG.
>
> Hope that helps,
> Dmitry
>
> >
> > Thanks,
> > Dougal
> >
> >
> > __
> > 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] PyCharm Licences


On 8/20/2018 11:24 PM, Swapnil Kulkarni wrote:

I have renewed the Pycharm licenses for community till Aug 13, 2019.
Everyone who is using it should have it updated automatically. Please
do not request again for renewal.

At the same time, I would request not to request multiple licenses
with multiple email addresses.


Thanks Swapnil. I use PyCharm daily so appreciate you handling this for 
the community.


--

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] [neutron] live migration with multiple port bindings.

2018-08-21 Thread Jay Pipes

On Tue, Aug 21, 2018, 8:29 AM Matt Riedemann  wrote:

> On 8/21/2018 7:28 AM, Matt Riedemann wrote:
> > On 8/20/2018 3:18 PM, Sean Mooney wrote:
> >> in both the ovs-dpdk tests, when the migration failed and the vm
> >> contiuned to run on the source node however
> >> it had no network connectivity. on hard reboot of the vm, it went to
> >> error state because the vif binding
> >> was set to none as the vif:bidning-details:host_id  was set to none so
> >> the vif_type was also set to none.
> >> i have opened a nova bug to track the fact that the vm is left in an
> >> invalid state even though the status is active.
> >> see bug 1788014
> >
> > I've got a nova patch for this here:
> >
> > https://review.openstack.org/#/c/594139/
> >
> > However, I'd like Miguel to look at that bug because I assumed that when
> > nova deletes the dest host port binding, the only remaining port binding
> > is the inactive one for the source host, and neutron would automatically
> > activate it, similar to how neutron will automatically deactivate all
> > other bindings for a port when one of the other bindings is activated
> > (like when nova activates the dest host port binding during live
> > migration, the source host port binding is automatically deactivated
> > because only one port binding can be active at any time). If there is a
> > good reason why neutron doesn't do this on port binding delete, then I
> > guess we go with fixing this in nova.
> >
>
> By the way, Sean, thanks a ton for doing all of this testing. It's super
> helpful and way above anything I could have gotten setup myself for the
> various neutron backend configurations.
>

Agreed, big +1 and thanks to Sean for doing this.

However, I'd like to point out that this highlights the unfortunate
situation we're in: only a select couple contributors actually are able to
understand the overly complex, ludicrously inconsistent, and all too often
incompatible networking technologies that OpenStack has come to rely on 

This reminds me of a recent conversation I had on Twitter with an old
coworker of mine who is now at booking. com who stated the frustrating
complexity of networking and SDN setup in OpenStack was the reason he
switched to Kubernetes and hasn't looked back since.

-jay


> 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 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] [TripleO]Addressing Edge/Multi-site/Multi-cloud deployment use cases (new squad)

2018-08-21 Thread James Slagle

On Tue, Aug 21, 2018 at 2:40 AM Csatari, Gergely (Nokia - HU/Budapest)
 wrote:
>
> Hi,
>
> There was a two days workshop on edge requirements back in Dublin. The notes 
> are stored here: 
> https://wiki.openstack.org/wiki/OpenStack_Edge_Discussions_Dublin_PTG I think 
> there are some areas there what can be interesting for the squad.
> Edge Computing Group plans to have a day long discussion in Denver. Maybe we 
> could have a short discussion there about these requirements.

Thanks! I've added my name to the etherpad for the PTG and will plan
on spending Tuesday with the group.
https://etherpad.openstack.org/p/EdgeComputingGroupPTG4


-- 
-- James Slagle
--

__
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] [neutron] live migration with multiple port bindings.


On 8/21/2018 7:28 AM, Matt Riedemann wrote:

On 8/20/2018 3:18 PM, Sean Mooney wrote:

in both the ovs-dpdk tests, when the migration failed and the vm
contiuned to run on the source node however
it had no network connectivity. on hard reboot of the vm, it went to
error state because the vif binding
was set to none as the vif:bidning-details:host_id  was set to none so
the vif_type was also set to none.
i have opened a nova bug to track the fact that the vm is left in an
invalid state even though the status is active.
see bug 1788014


I've got a nova patch for this here:

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

However, I'd like Miguel to look at that bug because I assumed that when 
nova deletes the dest host port binding, the only remaining port binding 
is the inactive one for the source host, and neutron would automatically 
activate it, similar to how neutron will automatically deactivate all 
other bindings for a port when one of the other bindings is activated 
(like when nova activates the dest host port binding during live 
migration, the source host port binding is automatically deactivated 
because only one port binding can be active at any time). If there is a 
good reason why neutron doesn't do this on port binding delete, then I 
guess we go with fixing this in nova.




By the way, Sean, thanks a ton for doing all of this testing. It's super 
helpful and way above anything I could have gotten setup myself for the 
various neutron backend configurations.


--

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] [neutron] live migration with multiple port bindings.


On 8/20/2018 3:18 PM, Sean Mooney wrote:

in both the ovs-dpdk tests, when the migration failed and the vm
contiuned to run on the source node however
it had no network connectivity. on hard reboot of the vm, it went to
error state because the vif binding
was set to none as the vif:bidning-details:host_id  was set to none so
the vif_type was also set to none.
i have opened a nova bug to track the fact that the vm is left in an
invalid state even though the status is active.
see bug 1788014


I've got a nova patch for this here:

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

However, I'd like Miguel to look at that bug because I assumed that when 
nova deletes the dest host port binding, the only remaining port binding 
is the inactive one for the source host, and neutron would automatically 
activate it, similar to how neutron will automatically deactivate all 
other bindings for a port when one of the other bindings is activated 
(like when nova activates the dest host port binding during live 
migration, the source host port binding is automatically deactivated 
because only one port binding can be active at any time). If there is a 
good reason why neutron doesn't do this on port binding delete, then I 
guess we go with fixing this in 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

[openstack-dev] nova 18.0.0.0rc2 (rocky)


Hello everyone,

A new release candidate for nova for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/nova/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

https://git.openstack.org/cgit/openstack/nova/log/?h=stable/rocky

Release notes for nova can be found at:

https://docs.openstack.org/releasenotes/nova/




__
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/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] New Contributor

2018-08-21 Thread Telles Nobrega

That is great to hear. Plese join us at #openstack-sahara so we can discuss
a little more of what work you want to do.

Welcome aboard.

On Tue, Aug 21, 2018 at 5:22 AM Ivoline Ngong 
wrote:

> Hello Kendall and Telles,
>
> Thanks so much for warm welcome. I feel at home already.
> The links sent were quire helpful and gave me an insight into what
> OpenStack is all about.
> After reading lightly about the different projects, the Sahara project
> caught my attention.
>
> Probably because I am interested in data science. I will love to explore
> the Sahara project some more.
>
> Cheers,
> Ivoline
>
>
>
> On Mon, Aug 20, 2018 8:42 PM, Telles Nobrega tenob...@redhat.com wrote:
>
>> Hi Ivoline,
>>
>> Also a little late but wanted to say welcome aboard, hopefully you will
>> find a very welcoming community here and of course a lot of work to do.
>>
>> I work with Sahara, the big data processing project of OpenStack, we need
>> help for sure.
>>
>> If this area interests you in any way, feel free to join us at
>> #openstack-sahara on IRC or email me and we can send some work at your
>> direction.
>>
>>
>> On Mon, Aug 20, 2018 at 2:37 PM Kendall Nelson 
>> wrote:
>>
>> Hello Ivoline,
>>
>> While I'm a little late to the party, I still wanted to say welcome and
>> offer my help :)
>>
>> If you have any questions based about the links you've been sent, I'm
>> happy to answer them! I can also help you find/get started with a team and
>> introduce you to community members whenever you're ready.
>>
>> -Kendall Nelson (diablo_rojo)
>>
>>
>> On Mon, 20 Aug 2018, 4:08 am Ivoline Ngong, 
>> wrote:
>>
>> Thanks so much for help Josh and Thierry. I'll check out the links and
>> hopefully find a way forward from there. Will get back here in case I have
>> any questions.
>>
>> Cheers,
>> Ivoline
>>
>> On Mon, Aug 20, 2018, 12:01 Thierry Carrez  wrote:
>>
>> Ivoline Ngong wrote:
>> > I am Ivoline Ngong. I am a Cameroonian who lives in Turkey. I will love
>> > to contribute to Open source through OpenStack. I code in Java and
>> > Python and I think OpenStack is a good fit for me.
>> > I'll appreciate it if you can point me to the right direction on how I
>> > can get started.
>>
>> Hi Ivoline,
>>
>> Welcome to the OpenStack community !
>>
>> The OpenStack Technical Committee maintains a list of areas in most need
>> of help:
>>
>> https://governance.openstack.org/tc/reference/help-most-needed.html
>>
>> Depending on your interest, you could pick one of those projects and
>> reach out to the mentioned contact points.
>>
>> For more general information on how to contribute, you can check out our
>> contribution portal:
>>
>> https://www.openstack.org/community/
>>
>> --
>> 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
>>
>> __
>> 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
>>
>> --
>>
>> TELLES NOBREGA
>>
>> SOFTWARE ENGINEER
>>
>> Red Hat Brasil  
>>
>> Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo
>>
>> tenob...@redhat.com
>> 
>> TRIED. TESTED. TRUSTED. 
>>  Red Hat é reconhecida entre as melhores empresas para trabalhar no
>> Brasil pelo Great Place to Work.
>>
> __
> 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
>
-- 

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat Brasil  

Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
 Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
pelo Great Place to Work.
__
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] [goal][python3] week 2 update

2018-08-21 Thread Telles Nobrega

Thanks. We merged most of them, there is only one that failed the tests so
I'm rechecking it.

On Mon, Aug 20, 2018 at 5:43 PM Doug Hellmann  wrote:

> Excerpts from Doug Hellmann's message of 2018-08-20 16:34:22 -0400:
> > Excerpts from Telles Nobrega's message of 2018-08-20 15:07:29 -0300:
> > > Hi Doug,
> > >
> > > I believe Sahara is ready to have those patches worked on.
> > >
> > > Do we have to do anything specific to get the env ready?
> >
> > Just be ready to do the reviews. I am generating the patches now and
> > will propose them in a little while when the script finishes.
>
> And here they are:
>
>
> +--+-+-+
> | Subject  | Repo
>   | URL |
>
> +--+-+-+
> | import zuul job settings from project-config |
> openstack/python-saharaclient   | https://review.openstack.org/593904 |
> | switch documentation job to new PTI  |
> openstack/python-saharaclient   | https://review.openstack.org/593905 |
> | add python 3.6 unit test job |
> openstack/python-saharaclient   | https://review.openstack.org/593906 |
> | import zuul job settings from project-config |
> openstack/python-saharaclient   | https://review.openstack.org/593918 |
> | import zuul job settings from project-config |
> openstack/python-saharaclient   | https://review.openstack.org/593923 |
> | import zuul job settings from project-config |
> openstack/python-saharaclient   | https://review.openstack.org/593928 |
> | import zuul job settings from project-config |
> openstack/python-saharaclient   | https://review.openstack.org/593933 |
> | import zuul job settings from project-config | openstack/sahara
>   | https://review.openstack.org/593907 |
> | switch documentation job to new PTI  | openstack/sahara
>   | https://review.openstack.org/593908 |
> | add python 3.6 unit test job | openstack/sahara
>   | https://review.openstack.org/593909 |
> | import zuul job settings from project-config | openstack/sahara
>   | https://review.openstack.org/593919 |
> | import zuul job settings from project-config | openstack/sahara
>   | https://review.openstack.org/593924 |
> | import zuul job settings from project-config | openstack/sahara
>   | https://review.openstack.org/593929 |
> | import zuul job settings from project-config | openstack/sahara
>   | https://review.openstack.org/593934 |
> | import zuul job settings from project-config |
> openstack/sahara-dashboard  | https://review.openstack.org/593910 |
> | switch documentation job to new PTI  |
> openstack/sahara-dashboard  | https://review.openstack.org/593911 |
> | import zuul job settings from project-config |
> openstack/sahara-dashboard  | https://review.openstack.org/593920 |
> | import zuul job settings from project-config |
> openstack/sahara-dashboard  | https://review.openstack.org/593925 |
> | import zuul job settings from project-config |
> openstack/sahara-dashboard  | https://review.openstack.org/593930 |
> | import zuul job settings from project-config |
> openstack/sahara-dashboard  | https://review.openstack.org/593935 |
> | import zuul job settings from project-config | openstack/sahara-extra
>   | https://review.openstack.org/593912 |
> | import zuul job settings from project-config | openstack/sahara-extra
>   | https://review.openstack.org/593921 |
> | import zuul job settings from project-config | openstack/sahara-extra
>   | https://review.openstack.org/593926 |
> | import zuul job settings from project-config | openstack/sahara-extra
>   | https://review.openstack.org/593931 |
> | import zuul job settings from project-config | openstack/sahara-extra
>   | https://review.openstack.org/593936 |
> | import zuul job settings from project-config |
> openstack/sahara-image-elements | https://review.openstack.org/593913 |
> | import zuul job settings from project-config |
> openstack/sahara-image-elements | https://review.openstack.org/593922 |
> | import zuul job settings from project-config |
> openstack/sahara-image-elements | https://review.openstack.org/593927 |
> | import zuul job settings from project-config |
> openstack/sahara-image-elements | https://review.openstack.org/593932 |
> | import zuul job settings from project-config |
> openstack/sahara-image-elements | https://review.openstack.org/593937 |
> | import zuul job settings from project-config | openstack/sahara-specs
>   | https://review.openstack.org/593914 |
> | import zuul job settings from project-config | openstack/sahara-tests
>   | https://review.openstack.org/593915 |
> | switch documentation job to new PTI  | openstack/sahara-tests
>   |

Re: [openstack-dev] [Openstack-operators] [nova][cinder] Disabling nova volume-update (aka swap volume; aka cinder live migration)

2018-08-21 Thread Lee Yarwood

On 20-08-18 16:29:52, Matthew Booth wrote:
> For those who aren't familiar with it, nova's volume-update (also
> called swap volume by nova devs) is the nova part of the
> implementation of cinder's live migration (also called retype).
> Volume-update is essentially an internal cinder<->nova api, but as
> that's not a thing it's also unfortunately exposed to users. Some
> users have found it and are using it, but because it's essentially an
> internal cinder<->nova api it breaks pretty easily if you don't treat
> it like a special snowflake. It looks like we've finally found a way
> it's broken for non-cinder callers that we can't fix, even with a
> dirty hack.
> 
> volume-updateessentially does a live copy of the
> data on  volume to  volume, then seamlessly swaps the
> attachment to  from  to . The guest OS on 
> will not notice anything at all as the hypervisor swaps the storage
> backing an attached volume underneath it.
> 
> When called by cinder, as intended, cinder does some post-operation
> cleanup such that  is deleted and  inherits the same
> volume_id; that is  effectively becomes . When called any
> other way, however, this cleanup doesn't happen, which breaks a bunch
> of assumptions. One of these is that a disk's serial number is the
> same as the attached volume_id. Disk serial number, in KVM at least,
> is immutable, so can't be updated during volume-update. This is fine
> if we were called via cinder, because the cinder cleanup means the
> volume_id stays the same. If called any other way, however, they no
> longer match, at least until a hard reboot when it will be reset to
> the new volume_id. It turns out this breaks live migration, but
> probably other things too. We can't think of a workaround.
> 
> I wondered why users would want to do this anyway. It turns out that
> sometimes cinder won't let you migrate a volume, but nova
> volume-update doesn't do those checks (as they're specific to cinder
> internals, none of nova's business, and duplicating them would be
> fragile, so we're not adding them!). Specifically we know that cinder
> won't let you migrate a volume with snapshots. There may be other
> reasons. If cinder won't let you migrate your volume, you can still
> move your data by using nova's volume-update, even though you'll end
> up with a new volume on the destination, and a slightly broken
> instance. Apparently the former is a trade-off worth making, but the
> latter has been reported as a bug.
> 
> I'd like to make it very clear that nova's volume-update, isn't
> expected to work correctly except when called by cinder. Specifically
> there was a proposal that we disable volume-update from non-cinder
> callers in some way, possibly by asserting volume state that can only
> be set by cinder. However, I'm also very aware that users are calling
> volume-update because it fills a need, and we don't want to trap data
> that wasn't previously trapped.
> 
> Firstly, is anybody aware of any other reasons to use nova's
> volume-update directly?
> 
> Secondly, is there any reason why we shouldn't just document then you
> have to delete snapshots before doing a volume migration? Hopefully
> some cinder folks or operators can chime in to let me know how to back
> them up or somehow make them independent before doing this, at which
> point the volume itself should be migratable?
> 
> If we can establish that there's an acceptable alternative to calling
> volume-update directly for all use-cases we're aware of, I'm going to
> propose heading off this class of bug by disabling it for non-cinder
> callers.

I'm definitely in favor of hiding this from users eventually but
wouldn't this require some form of deprecation cycle?

Warnings within the API documentation would also be useful and even
something we could backport to stable to highlight just how fragile this
API is ahead of any policy change.

Cheers,

-- 
Lee Yarwood A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76


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] [mistral] No Denver PTG Sessions

2018-08-21 Thread Dmitry Tantsur


On 08/21/2018 10:22 AM, Dougal Matthews wrote:

Hi all,

Unfortunately due to some personal conflicts and trouble with travel plans, 
there will be no Mistral cores at the Denver PTG. This means that we have had to 
cancel the Mistral sessions. I recently asked if anyone was planning to attend 
and only got one maybe.


I am considering trying to arrange a "virtual PTG", so we can do some planning 
for Stein. However, I'm not sure how/if that could work. Do you think this would 
be a good idea? Suggestions how to organise one would be very welcome!


We did a few virtual midcycles for ironic, and it ended up quite well. While it 
did require some people to stay awake at unusual times, it did allow people 
without travel budget to attend.


Initially we used the OpenStack SIP system, but we found Bluejeans to be a bit 
easier to use. I think it has a limit of 300 participants, which is more than 
enough. Anyone from Red Hat can host it.


We dedicated 1-2 days with 4-5 hours each. I'd recommend against taking up the 
whole day - will be too exhausting. The first time we tried splitting the slots 
into two per day: APAC friendly and EMEA friendly. Relatively few people showed 
up at the former, so the next time we only had one slot.


As with the PTG, having an agenda upfront helps a lot. We did synchronization 
and notes through an etherpad - exactly the same was as on the PTG.


Hope that helps,
Dmitry



Thanks,
Dougal


__
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 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] [TC][Searchlight] Setting up milestones for Searchlight on Launchpad

Hi Thierry,

I just saw that link. Thanks :)

Because I couldn't contact any of the core members I emailed this list. I
will update the searchlight-core as planned after I am added.

Thanks for your response,

*Trinh Nguyen *| Founder & Chief Architect



*E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *



On Tue, Aug 21, 2018 at 6:15 PM Thierry Carrez 
wrote:

> Trinh Nguyen wrote:
> > In an effort to get Searchlight back on track, I would like to set up
> > milestones as well as clean up the incomplete bugs, blueprints etc. on
> > Launchpad [1] I was added to the Searchlight Drivers team but I still
> > can not touch the milestone configuration.
>
> As a member of the "maintainer" team in Launchpad you should be able to
> register a series ("stein") and then add milestones to that series. You
> should see a "Register a series" link under "Series and milestones" at
> https://launchpad.net/searchlight
>
> > In addition, I would like to move forward with unreviewed patched on
> > Gerrit so I need PTL privileges on Searchlight project. Do I have to
> > wait for [2] to be merged?
>
> For the TC to step in and add you to searchlight-core, yes, we'll have
> to wait for the merging of that patch.
>
> To go faster, you could ask any of the existing members in that group to
> directly add you:
>
> https://review.openstack.org/#/admin/groups/964,members
>
> (NB: this group looks like it should be updated :) )
>
> --
> 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
>
__
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] [TC][Searchlight] Setting up milestones for Searchlight on Launchpad

2018-08-21 Thread Thierry Carrez


Trinh Nguyen wrote:
In an effort to get Searchlight back on track, I would like to set up 
milestones as well as clean up the incomplete bugs, blueprints etc. on 
Launchpad [1] I was added to the Searchlight Drivers team but I still 
can not touch the milestone configuration.


As a member of the "maintainer" team in Launchpad you should be able to 
register a series ("stein") and then add milestones to that series. You 
should see a "Register a series" link under "Series and milestones" at 
https://launchpad.net/searchlight


In addition, I would like to move forward with unreviewed patched on 
Gerrit so I need PTL privileges on Searchlight project. Do I have to 
wait for [2] to be merged?


For the TC to step in and add you to searchlight-core, yes, we'll have 
to wait for the merging of that patch.


To go faster, you could ask any of the existing members in that group to 
directly add you:


https://review.openstack.org/#/admin/groups/964,members

(NB: this group looks like it should be updated :) )

--
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] [senlin] Senlin Weekly Meeting Time Change

2018-08-21 Thread Qiming Teng

Works for me.

-Qiming

On Mon, Aug 20, 2018 at 09:34:46PM -0700, Duc Truong wrote:
> Hi,
> 
> As we are starting the Stein cycle, I would like to start having weekly
> meetings again for Senlin.  I'm proposing to move the weekly meeting
> to the following time:
> 
> Friday 5:30 UTC to 6:30 UTC in #senlin channel
> 
> Please reply if this works for you or reply with an alternative time
> slot.
> 
> Thanks,
> 
> Duc


__
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-dev] [mistral] No Denver PTG Sessions

2018-08-21 Thread Dougal Matthews

Hi all,

Unfortunately due to some personal conflicts and trouble with travel plans,
there will be no Mistral cores at the Denver PTG. This means that we have
had to cancel the Mistral sessions. I recently asked if anyone was planning
to attend and only got one maybe.

I am considering trying to arrange a "virtual PTG", so we can do some
planning for Stein. However, I'm not sure how/if that could work. Do you
think this would be a good idea? Suggestions how to organise one would be
very welcome!

Thanks,
Dougal
__
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] New Contributor

2018-08-21 Thread Ivoline Ngong

Hello Kendall and Telles,
Thanks so much for warm welcome. I feel at home already.The links sent were
quire helpful and gave me an insight into what OpenStack is all about.After
reading lightly about the different projects, the Sahara project caught my
attention.
Probably because I am interested in data science. I will love to explore the
Sahara project some more.
Cheers,Ivoline  

On Mon, Aug 20, 2018 8:42 PM, Telles Nobrega tenob...@redhat.com  wrote:
Hi Ivoline,
Also a little late but wanted to say welcome aboard, hopefully you will find a
very welcoming community here and of course a lot of work to do.
I work with Sahara, the big data processing project of OpenStack, we need help
for sure.
If this area interests you in any way, feel free to join us at #openstack-sahara
on IRC or email me and we can send some work at your direction.

On Mon, Aug 20, 2018 at 2:37 PM Kendall Nelson  wrote:
Hello Ivoline,
While I'm a little late to the party, I still wanted to say welcome and offer my
help :)
If you have any questions based about the links you've been sent, I'm happy to
answer them! I can also help you find/get started with a team and introduce you
to community members whenever you're ready.
-Kendall Nelson (diablo_rojo)

On Mon, 20 Aug 2018, 4:08 am Ivoline Ngong,  wrote:
Thanks so much for help Josh and Thierry. I'll check out the links and hopefully
find a way forward from there. Will get back here in case I have any questions.
Cheers,Ivoline
On Mon, Aug 20, 2018, 12:01 Thierry Carrez  wrote:
Ivoline Ngong wrote:
> I am Ivoline Ngong. I am a Cameroonian who lives in Turkey. I will love 
> to contribute to Open source through OpenStack. I code in Java and 
> Python and I think OpenStack is a good fit for me.
> I'll appreciate it if you can point me to the right direction on how I 
> can get started.

Hi Ivoline,

Welcome to the OpenStack community !

The OpenStack Technical Committee maintains a list of areas in most need 
of help:

https://governance.openstack.org/tc/reference/help-most-needed.html

Depending on your interest, you could pick one of those projects and 
reach out to the mentioned contact points.

For more general information on how to contribute, you can check out our 
contribution portal:

https://www.openstack.org/community/

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

SOFTWARE ENGINEER

Red Hat Brasil

Av. Brg. Faria Lima, 3900 - 8º andar - Itaim Bibi, São Paulo

tenob...@redhat.com

TRIED. TESTED. TRUSTED. Red Hat é reconhecida entre as melhores empresas para
trabalhar no Brasil peloGreat Place to Work.__
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-dev] [TC][Searchlight] Setting up milestones for Searchlight on Launchpad