date:20180820

Excerpts from Doug Hellmann's message of 2018-08-08 09:18:44 -0400:
> Excerpts from Doug Hellmann's message of 2018-08-01 09:27:09 -0400:
> > Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
> > during the Rocky cycle to add driver support. Based on that work,
> > and a discussion we have had since then about general cleanup needed
> > in oslo.config, I think he would make a good addition to the
> > oslo.config review team.
> > 
> > Please indicate your approval or concerns with +1/-1.
> > 
> > Doug
> 
> Normally I would have added moguimar to the oslo-config-core team
> today, after a week's wait. Funny story, though. There is no
> oslo-config-core team.
> 
> oslo.config is one of a few of our libraries that we never set up with a
> separate review team. It is managed by oslo-core. We could set up a new
> review team for that library, but after giving it some thought I
> realized that *most* of the libraries are fairly stable, our team is
> pretty small, and Moisés is a good guy so maybe we don't need to worry
> about that.
> 
> I spoke with Moisés, and he agreed to be part of the larger core team.
> He pointed out that the next phase of the driver work is going to happen
> in castellan, so it would be useful to have another reviewer there. And
> I'm sure we can trust him to be careful with reviews in other repos
> until he learns his way around.
> 
> So, I would like to amend my original proposal and suggest that we add
> Moisés to the oslo-core team.
> 
> Please indicate support with +1 or present any concerns you have. I
> apologize for the confusion on my part.
> 
> Doug

There being no objections, I have added Moisés Guimarães (moguimar) to
the oslo-core team today.

Welcome to the team!

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2018-08-20 Thread Eric Fried

This is great information, thanks Hongbin.

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

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

Yes.

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

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

-efried

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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2018-08-20 Thread Matthew Booth

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.

Matt
-- 
Matthew Booth
Red Hat OpenStack Engineer, Compute DFG

Phone: +442070094448 (UK)

__
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] [docs][all] Testing installation guides for Rocky

2018-08-20 Thread Petr Kovar

Hi all,

With the Rocky release quickly approaching, I wanted to draw your attention
to installation guides testing. With each project team now maintaining
their own installation guide, and with the old coordinated effort to test
installation docs now retired, the Docs team recently updated guidelines
for IGs testing, you can find the instructions here:

https://docs.openstack.org/doc-contrib-guide/release/taskdetail.html#installation-guides-testing

As a reminder, all installation guides should be based on the common
installation guide found at https://docs.openstack.org/install-guide/ and
should be tested together with installation instructions from related
project teams docs:

https://docs.openstack.org/rocky/install/

We set up an Installation Guides Review Inbox that tracks all open patches
touching files under doc/source/install/ in project team repositories:

https://gerrit-dash-creator.readthedocs.io/en/latest/dashboards/dashboard_doc-install-guides.html

This will hopefully make it easier for project teams and individual docs
contributors to monitor and follow-up on changes happening across
OpenStack projects.

Thanks,
pk

__
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-20 Thread Kendall Nelson

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

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

2018-08-20 Thread Zane Bitter


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

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

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


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


It just doesn't matter.

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


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


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


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


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Searchlight] Reaching out to the Searchlight core members for Stein - Call for team meeting

2018-08-20 Thread Trinh Nguyen

Hi Zhenyu Zheng,

Thanks for your response. What is your IRC handler? I would like to have a
team meeting this week to decide what we gonna do with Searchlight in Stein.

Searchlight IRC channel: #openstack-searchlight
My IRC: dangtrinhnt

Bests,

*Trinh Nguyen *| Founder & Chief Architect



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



On Sat, Aug 18, 2018 at 1:16 AM Trinh Nguyen  wrote:

> Dear Searchlight team,
>
> As you may know, the Searchlight project has missed several milestones,
> especially the Rocky cycle. The TC already has the plan to remove
> Searchlight from governance [1] but I volunteer to take over it [2]. But
> due to the unresponsive on IRC and launchpad, I send this email to reach
> out to all the Searchlight core members to discuss our plan in Stein as
> well as re-organize the team. Hopefully, this effort will work well and may
> bring Searchlight back to life.
>
> If anyone on the core team sees this email, please reply.
>
> My IRC is dangtrinhnt.
>
> [1] https://review.openstack.org/#/c/588644/
> [2] https://review.openstack.org/#/c/590601/
>
> 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

Re: [openstack-dev] [ironic] ironic-staging-drivers: what to do?

2018-08-20 Thread Ruby Loo

Hi,

On Mon, Aug 13, 2018 at 2:40 PM, Julia Kreger 
wrote:

> Greetings fellow ironicans!
>
> As many of you might know an openstack/ironic-staging-drivers[1]
> repository exists. What most might not know is that it was
> intentionally created outside of ironic's governance[2].
> ...
>
> This topic has come up in passing at PTGs and most recently on IRC[9],
> and I think we ought to discuss it during our next weekly meeting[10].
> I've gone ahead and added an item to the agenda, but we can also
> discuss via email.
>
>
We had a short discussion on this in our meeting today [1]. To summarize,
we did not discuss whether to put it under the ironic governance. We did
agree that it would be ok to have the ironic cores be cores in
ironic-staging-drivers. There would be no guarantee (of course) that the
ironic cores would actually review any of these. Julia will get in touch
with the cores in ironic-staging-drivers, to see if they would like to add
ironic-cores as cores.

--ruby

[1]
http://eavesdrop.openstack.org/meetings/ironic/2018/ironic.2018-08-20-15.00.log.html#l-118
__
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] Early Bird Registration Deadline Extended to 8/28 - Berlin Summit

2018-08-20 Thread Kendall Waters

Hi everyone,

The OpenStack Summit Berlin  schedule is now 
live and in order to give people some extra time to book tickets, we have 
decided to extend early bird registration. The NEW early bird registration 
deadline is August 28 at 11:59pm PT (August 29, 6:59 UTC). 

Register now  before the 
price increases! Don’t miss out on sessions and workshops from organizations 
such as Oerlikon ManMade Fibers, Workday, CERN, Volkswagen, BMW and more. 

If you have any questions, please email sum...@openstack.org 
.

Cheers,
Kendall

Kendall Waters
OpenStack Marketing & Events
kend...@openstack.org __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2018-08-20 Thread Zane Bitter


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


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


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2018-08-20 Thread Chris Friesen


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


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

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


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


Chris

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] proposing Moisés Guimarães for oslo.config core

2018-08-20 Thread Moises Guimaraes de Medeiros

o/

Em seg, 20 de ago de 2018 às 17:30, Doug Hellmann 
escreveu:

> Excerpts from Doug Hellmann's message of 2018-08-08 09:18:44 -0400:
> > Excerpts from Doug Hellmann's message of 2018-08-01 09:27:09 -0400:
> > > Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
> > > during the Rocky cycle to add driver support. Based on that work,
> > > and a discussion we have had since then about general cleanup needed
> > > in oslo.config, I think he would make a good addition to the
> > > oslo.config review team.
> > >
> > > Please indicate your approval or concerns with +1/-1.
> > >
> > > Doug
> >
> > Normally I would have added moguimar to the oslo-config-core team
> > today, after a week's wait. Funny story, though. There is no
> > oslo-config-core team.
> >
> > oslo.config is one of a few of our libraries that we never set up with a
> > separate review team. It is managed by oslo-core. We could set up a new
> > review team for that library, but after giving it some thought I
> > realized that *most* of the libraries are fairly stable, our team is
> > pretty small, and Moisés is a good guy so maybe we don't need to worry
> > about that.
> >
> > I spoke with Moisés, and he agreed to be part of the larger core team.
> > He pointed out that the next phase of the driver work is going to happen
> > in castellan, so it would be useful to have another reviewer there. And
> > I'm sure we can trust him to be careful with reviews in other repos
> > until he learns his way around.
> >
> > So, I would like to amend my original proposal and suggest that we add
> > Moisés to the oslo-core team.
> >
> > Please indicate support with +1 or present any concerns you have. I
> > apologize for the confusion on my part.
> >
> > Doug
>
> There being no objections, I have added Moisés Guimarães (moguimar) to
> the oslo-core team today.
>
> Welcome to the team!
>
> 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
>
-- 

MOISÉS GUIMARÃES

SOFTWARE ENGINEER

Red Hat




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2018-08-20 Thread Hongbin Lu

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

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

I express the Zun's point of view.

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

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

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

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

Best regards,
Hongbin
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [goal][python3] week 2 update

This is week 2 of the roll-out of the "Run under Python 3 by default"
goal (https://governance.openstack.org/tc/goals/stein/python3-first.html).

== What we learned last week ==

As we worked on approving the changes to add the zuul settings to
a few Oslo repositories, we had trouble with some of the older
branches because they were running newer versions of the jobs, as
configured in project-config. To work around this problem, we removed
those job templates in project-config by submitting separate patches
(rather than waiting for the full clean-up patch). We used the Oslo
team repos when we were testing some of the new jobs, so it is
possible this won't come up for any other teams, but I thought I
would mention the problem and solution, just in case.

We had at least one question about the order in which the patches
need to land across the branches. We need the ones with the subject
"import zuul job settings from project-config" to land before the
others, but it doesn't make any difference which branches go first.
Those patches should be basically no-ops, neither adding nor changing
any of the existing testing. The other follow-up patches change or
add tests, and are submitted separately specifically so the changes
they contain can be managed and issues fixed to allow them to land.

Nguyen found a couple of cases where older branches did not work
with the existing documentation job. The fix may require backporting
changes to remove tox_install.sh, or other changes that have been
made in newer stable branches but not backported all the way. Because
the new documentation job runs through tox we may be able to use
that in the older branches, as an alternative.

We discovered last night that the version of git on CentOS does not
support the -C option, so we will need to change our scripts to be
compatible with the older platform.

== Completed work ==

Congratulations to the Documentation team for approving all of the
patches to import their zuul job configuration!

== Ongoing work ==

The Oslo team is working on migrating their zuul settings.

The Ironic, Vitrage, Cyborg, Solum, Tacker, Masakari, Congress,
Designate, Mistral, Watcher, Glance, and Requirements teams have
started migrating their zuul settings.

The Ironic team has started working on adding functional tests that
run under Python 3.

Thanks to dtantsur for adding a variant of the python 3.6 jobs that
installs neutron from source, needed by several networking-related
projects that integrate tightly with neutron.
https://review.openstack.org/#/c/593643/

== Next Steps ==

If your team is ready to have your zuul settings migrated, please
let us know by following up to this email. We will start with the
volunteers, and then work our way through the other teams.

After the Rocky cycle-trailing projects are released, I will propose
the change to project-config to change all of the packaging jobs
to use the new publish-to-pypi-python3 template. We should be able
to have that change in place before the first milestone for Stein
so that we have an opportunity to test it.

== How can you help? ==

1. Choose a patch that has failing tests and help fix it.

https://review.openstack.org/#/q/topic:python3-first+status:open+(+label:Verified-1+OR+label:Verified-2+)
2. Review the patches for the zuul changes. Keep in mind that some of
those patches will be on the stable branches for projects.
3. Work on adding functional test jobs that run under Python 3.

== How can you ask for help? ==

If you have any questions, please post them here to the openstack-dev
list with the topic tag [python3] in the subject line. Posting
questions to the mailing list will give the widest audience the
chance to see the answers.

We are using the #openstack-dev IRC channel for discussion as well,
but I'm not sure how good our timezone coverage is so it's probably
better to use the mailing list.

== Reference Material ==

Goal description:
https://governance.openstack.org/tc/goals/stein/python3-first.html
Open patches needing reviews:
https://review.openstack.org/#/q/topic:python3-first+is:open
Storyboard: https://storyboard.openstack.org/#!/board/104
Zuul migration notes: https://etherpad.openstack.org/p/python3-first
Zuul migration tracking: https://storyboard.openstack.org/#!/story/2002586
Python 3 Wiki page: https://wiki.openstack.org/wiki/Python3

__
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-20 Thread Telles Nobrega

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

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

2018-08-20 Thread Jeremy Stanley

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

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


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [os-upstream-institute] Restarting meetings on August 20

2018-08-20 Thread Kendall Nelson

Hello Everyone,

To avoid meeting conflicts with the Women of OpenStack, we will actually be
doing meetings weekly on Mondays at 20:00 UTC on odd weeks.

Long story short, our kickoff meeting after this luxurious summer break
will be a week from today on August 27th.

Thanks everyone!

See you next week :)

-Kendall Nelson (diablo_rojo)

On Sun, 12 Aug 2018, 12:44 am Ildiko Vancsa, 
wrote:

> Hi,
>
> As the Summer vacation season is getting to its end and we also need to
> start to prepare for the training just before the Berlin Summit we plan to
> resurrect the OUI meetings on every second Monday at 2000 UTC starting on
> August 20.
>
> We will post the agenda on the regular etherpad:
> https://etherpad.openstack.org/p/openstack-upstream-institute-meetings
>
>
> Further useful links:
>
> You can see the current state of the website:
> https://docs.openstack.org/upstream-training/index.html
> The current training content can be found here:
> https://docs.openstack.org/upstream-training/upstream-training-content.html
> To check the latest stage of the Contributor Guide:
> https://docs.openstack.org/contributors/index.html
>
> Open training-guide reviews:
> https://review.openstack.org/#/q/project:openstack/training-guides+status:open
> Open Contributor Guide reviews:
> https://review.openstack.org/#/q/project:openstack/contributor-guide+status:open
>
> Contributor Guide StoryBoard open Stories/Tasks:
> https://storyboard.openstack.org/#!/project/913
>
>
> Please let me know if you have any questions.
>
> Thanks and Best Regards,
> Ildikó
> (IRC: ildikov)
>
>
>
> __
> 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] [goal][python3] week 2 update

2018-08-20 Thread Telles Nobrega

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?

Thanks,

On Mon, Aug 20, 2018 at 1:13 PM Nguyễn Trí Hải 
wrote:

> Hi,
>
> Vitrage team is going to finish the zuul job soon. As I see, only few
> patches in the old branches need to be merged.
>
> For the other projects, some patches have problems with different errors.
> Please help to fix them.
>
> Thanks for your cooperation.
>
> Nguyen Hai
>
>
> On Tue, Aug 21, 2018, 12:27 AM Doug Hellmann 
> wrote:
>
>> This is week 2 of the roll-out of the "Run under Python 3 by default"
>> goal (https://governance.openstack.org/tc/goals/stein/python3-first.html
>> ).
>>
>> == What we learned last week ==
>>
>> As we worked on approving the changes to add the zuul settings to
>> a few Oslo repositories, we had trouble with some of the older
>> branches because they were running newer versions of the jobs, as
>> configured in project-config. To work around this problem, we removed
>> those job templates in project-config by submitting separate patches
>> (rather than waiting for the full clean-up patch). We used the Oslo
>> team repos when we were testing some of the new jobs, so it is
>> possible this won't come up for any other teams, but I thought I
>> would mention the problem and solution, just in case.
>>
>> We had at least one question about the order in which the patches
>> need to land across the branches. We need the ones with the subject
>> "import zuul job settings from project-config" to land before the
>> others, but it doesn't make any difference which branches go first.
>> Those patches should be basically no-ops, neither adding nor changing
>> any of the existing testing. The other follow-up patches change or
>> add tests, and are submitted separately specifically so the changes
>> they contain can be managed and issues fixed to allow them to land.
>>
>> Nguyen found a couple of cases where older branches did not work
>> with the existing documentation job. The fix may require backporting
>> changes to remove tox_install.sh, or other changes that have been
>> made in newer stable branches but not backported all the way. Because
>> the new documentation job runs through tox we may be able to use
>> that in the older branches, as an alternative.
>>
>> We discovered last night that the version of git on CentOS does not
>> support the -C option, so we will need to change our scripts to be
>> compatible with the older platform.
>>
>> == Completed work ==
>>
>> Congratulations to the Documentation team for approving all of the
>> patches to import their zuul job configuration!
>>
>> == Ongoing work ==
>>
>> The Oslo team is working on migrating their zuul settings.
>>
>> The Ironic, Vitrage, Cyborg, Solum, Tacker, Masakari, Congress,
>> Designate, Mistral, Watcher, Glance, and Requirements teams have
>> started migrating their zuul settings.
>>
>> The Ironic team has started working on adding functional tests that
>> run under Python 3.
>>
>> Thanks to dtantsur for adding a variant of the python 3.6 jobs that
>> installs neutron from source, needed by several networking-related
>> projects that integrate tightly with neutron.
>> https://review.openstack.org/#/c/593643/
>>
>> == Next Steps ==
>>
>> If your team is ready to have your zuul settings migrated, please
>> let us know by following up to this email. We will start with the
>> volunteers, and then work our way through the other teams.
>>
>> After the Rocky cycle-trailing projects are released, I will propose
>> the change to project-config to change all of the packaging jobs
>> to use the new publish-to-pypi-python3 template. We should be able
>> to have that change in place before the first milestone for Stein
>> so that we have an opportunity to test it.
>>
>> == How can you help? ==
>>
>> 1. Choose a patch that has failing tests and help fix it.
>>
>> https://review.openstack.org/#/q/topic:python3-first+status:open+(+label:Verified-1+OR+label:Verified-2+)
>> 2. Review the patches for the zuul changes. Keep in mind that some of
>>those patches will be on the stable branches for projects.
>> 3. Work on adding functional test jobs that run under Python 3.
>>
>> == How can you ask for help? ==
>>
>> If you have any questions, please post them here to the openstack-dev
>> list with the topic tag [python3] in the subject line. Posting
>> questions to the mailing list will give the widest audience the
>> chance to see the answers.
>>
>> We are using the #openstack-dev IRC channel for discussion as well,
>> but I'm not sure how good our timezone coverage is so it's probably
>> better to use the mailing list.
>>
>> == Reference Material ==
>>
>> Goal description:
>> https://governance.openstack.org/tc/goals/stein/python3-first.html
>> Open patches needing reviews:
>> https://review.openstack.org/#/q/topic:python3-first+is:open
>> Storyboard: https://storyboard.openstack.org/#!/board/104
>> Zuul migration notes:

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

2018-08-20 Thread Chris Dent


On Mon, 20 Aug 2018, Zane Bitter wrote:

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


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

Perhaps not a huge difference.

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [goal][python3] week 2 update

2018-08-20 Thread Nguyễn Trí Hải

Hi,

Vitrage team is going to finish the zuul job soon. As I see, only few
patches in the old branches need to be merged.

For the other projects, some patches have problems with different errors.
Please help to fix them.

Thanks for your cooperation.

Nguyen Hai

On Tue, Aug 21, 2018, 12:27 AM Doug Hellmann  wrote:

> This is week 2 of the roll-out of the "Run under Python 3 by default"
> goal (https://governance.openstack.org/tc/goals/stein/python3-first.html).
>
> == What we learned last week ==
>
> As we worked on approving the changes to add the zuul settings to
> a few Oslo repositories, we had trouble with some of the older
> branches because they were running newer versions of the jobs, as
> configured in project-config. To work around this problem, we removed
> those job templates in project-config by submitting separate patches
> (rather than waiting for the full clean-up patch). We used the Oslo
> team repos when we were testing some of the new jobs, so it is
> possible this won't come up for any other teams, but I thought I
> would mention the problem and solution, just in case.
>
> We had at least one question about the order in which the patches
> need to land across the branches. We need the ones with the subject
> "import zuul job settings from project-config" to land before the
> others, but it doesn't make any difference which branches go first.
> Those patches should be basically no-ops, neither adding nor changing
> any of the existing testing. The other follow-up patches change or
> add tests, and are submitted separately specifically so the changes
> they contain can be managed and issues fixed to allow them to land.
>
> Nguyen found a couple of cases where older branches did not work
> with the existing documentation job. The fix may require backporting
> changes to remove tox_install.sh, or other changes that have been
> made in newer stable branches but not backported all the way. Because
> the new documentation job runs through tox we may be able to use
> that in the older branches, as an alternative.
>
> We discovered last night that the version of git on CentOS does not
> support the -C option, so we will need to change our scripts to be
> compatible with the older platform.
>
> == Completed work ==
>
> Congratulations to the Documentation team for approving all of the
> patches to import their zuul job configuration!
>
> == Ongoing work ==
>
> The Oslo team is working on migrating their zuul settings.
>
> The Ironic, Vitrage, Cyborg, Solum, Tacker, Masakari, Congress,
> Designate, Mistral, Watcher, Glance, and Requirements teams have
> started migrating their zuul settings.
>
> The Ironic team has started working on adding functional tests that
> run under Python 3.
>
> Thanks to dtantsur for adding a variant of the python 3.6 jobs that
> installs neutron from source, needed by several networking-related
> projects that integrate tightly with neutron.
> https://review.openstack.org/#/c/593643/
>
> == Next Steps ==
>
> If your team is ready to have your zuul settings migrated, please
> let us know by following up to this email. We will start with the
> volunteers, and then work our way through the other teams.
>
> After the Rocky cycle-trailing projects are released, I will propose
> the change to project-config to change all of the packaging jobs
> to use the new publish-to-pypi-python3 template. We should be able
> to have that change in place before the first milestone for Stein
> so that we have an opportunity to test it.
>
> == How can you help? ==
>
> 1. Choose a patch that has failing tests and help fix it.
>
> https://review.openstack.org/#/q/topic:python3-first+status:open+(+label:Verified-1+OR+label:Verified-2+)
> 2. Review the patches for the zuul changes. Keep in mind that some of
>those patches will be on the stable branches for projects.
> 3. Work on adding functional test jobs that run under Python 3.
>
> == How can you ask for help? ==
>
> If you have any questions, please post them here to the openstack-dev
> list with the topic tag [python3] in the subject line. Posting
> questions to the mailing list will give the widest audience the
> chance to see the answers.
>
> We are using the #openstack-dev IRC channel for discussion as well,
> but I'm not sure how good our timezone coverage is so it's probably
> better to use the mailing list.
>
> == Reference Material ==
>
> Goal description:
> https://governance.openstack.org/tc/goals/stein/python3-first.html
> Open patches needing reviews:
> https://review.openstack.org/#/q/topic:python3-first+is:open
> Storyboard: https://storyboard.openstack.org/#!/board/104
> Zuul migration notes: https://etherpad.openstack.org/p/python3-first
> Zuul migration tracking: https://storyboard.openstack.org/#!/story/2002586
> Python 3 Wiki page: https://wiki.openstack.org/wiki/Python3
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
>

Re: [openstack-dev] [tripleo] fedora28 python3 test environment

2018-08-20 Thread Alex Schultz

On Fri, Aug 17, 2018 at 5:18 PM, Alex Schultz  wrote:
> Ahoy folks,
>
> In order to get to a spot where can start evaluate the current status
> of TripleO under python3 I've thrown together a set of ansible
> playbooks[0] to launch a fedora28 node and build the required
> python-tripleoclient (and dependencies)  These playbooks will spawn a
> VM on an OpenStack cloud, runs through the the steps from the RDO
> etherpad[1] for using the fedora stablized repo and builds all the
> currently outstanding python3 package builds[2] for
> python-tripleoclient & company.  Once the playblook has completed it
> should be at a spot to 'dnf install python3-tripleoclient'.
>
> I believe from here we can focus on getting the undercloud[3] and
> standalone[4] processes working correctly under python3.  I think
> initially we should use the existing CentOS7 containers we build under
> the existing processes to see if we can't get the services deployed as
> we work on building out all the required python3 packaging.
>

To follow up, I've started an etherpad[0] to track the various issues
related to the python3 version of tripleoclient.

[0] https://etherpad.openstack.org/p/tripleo-python3-tripleoclient-issues

> Thanks,
> -Alex
>
> [0] https://github.com/mwhahaha/tripleo-f28-testbed
> [1] https://review.rdoproject.org/etherpad/p/use-fedora-stabilized
> [2] 
> https://review.rdoproject.org/r/#/q/status:open+owner:%22Alex+Schultz+%253Caschultz%2540next-development.com%253E%22+topic:python3
> [3] 
> https://docs.openstack.org/tripleo-docs/latest/install/installation/installation.html
> [4] 
> https://docs.openstack.org/tripleo-docs/latest/install/containers_deployment/standalone.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

[openstack-dev] [TripleO]Addressing Edge/Multi-site/Multi-cloud deployment use cases (new squad)

2018-08-20 Thread James Slagle

As we start looking at how TripleO will address next generation deployment
needs such as Edge, multi-site, and multi-cloud, I'd like to kick off a
discussion around how TripleO can evolve and adapt to meet these new
challenges.

What are these challenges? I think the OpenStack Edge Whitepaper does a good
job summarizing some of them:

https://www.openstack.org/assets/edge/OpenStack-EdgeWhitepaper-v3-online.pdf

They include:

- management of distributed infrastructure
- massive scale (thousands instead of hundreds)
- limited network connectivity
- isolation of distributed sites
- orchestration of federated services across multiple sites

We already have a lot of ongoing work that directly or indirectly starts to
address some of these challenges. That work includes things like
config-download, split-controlplane, metalsmith integration, validations,
all-in-one, and standalone.

I laid out some initial ideas in a previous message:

http://lists.openstack.org/pipermail/openstack-dev/2018-July/132398.html

I'll be reviewing some of that here and going into a bit more detail.

These are some of the high level ideas I'd like to see TripleO start to
address:

- More separation between planning and deploying (likely to be further defined
  in spec discussion). We've had these concepts for a while, but we need to do
  a better job of surfacing them to users as deployments grow in size and
  complexity.

  With config-download, we can more easily separate the phases of rendering,
  downloading, validating, and applying the configuration. As we increase in
  scale to managing many deployments, we should take advantage of what each of
  those phases offer.

  The separation also makes the deployment more portable, as we should
  eliminate any restrictions that force the undercloud to be the control node
  applying the configuration.

- Management of multiple deployments from a single undercloud. This is of
  course already possible today, but we need better docs and polish and more
  testing to flush out any bugs.

- Plan and template management in git.

  This could be an iterative step towards eliminating Swift in the undercloud.
  Swift seemed like a natural choice at the time because it was an existing
  OpenStack service.  However, I think git would do a better job at tracking
  history and comparing changes and is much more lightweight than Swift. We've
  been managing the config-download directory as a git repo, and I like this
  direction. For now, we are just putting the whole git repo in Swift, but I
  wonder if it makes sense to consider eliminating Swift entirely. We need to
  consider the scale of managing thousands of plans for separate edge
  deployments.

  I also think this would be a step towards undercloud simplification.

- Orchestration between plans. I think there's general agreement around scaling
  up the undercloud to be more effective at managing and deploying multiple
  plans.

  The plans could be different OpenStack deployments potentially sharing some
  resources. Or, they could be deployments of different software stacks
  (Kubernetes/OpenShift, Ceph, etc).

  We'll need to develop some common interfaces for some basic orchestration
  between plans. It could include dependencies, ordering, and sharing parameter
  data (such as passwords or connection info). There is already some ongoing
  discussion about some of this work:

  http://lists.openstack.org/pipermail/openstack-dev/2018-August/133247.html

  I would suspect this would start out as collecting specific use cases, and
  then figuring out the right generic interfaces.

- Multiple deployments of a single plan. This could be useful for doing many
  deployments that are all the same. Of course some info might be different
  such as network IP's, hostnames, and node specific details. We could have
  some generic input interfaces for those sorts of things without having to
  create new Heat stacks, which would allow re-using the same plan/stack for
  multiple deployments. When scaling to hundreds/thousands of edge deployments
  this could be really effective at side-stepping managing hundreds/thousands
  of Heat stacks.

  We may also need further separation between a plan and it's deployment state
  to have this modularity.

- Distributed management/application of configuration. Even though the
  configuration is portable (config-download), we may still want some
  automation around applying the deployment when not using the undercloud as a
  control node. I think things like ansible-runner or Ansible AWX could help
  here, or perhaps mistral-executor agents, or "mistral as a library". This
  would also make our workflows more portable.

- New documentation highlighting some or all of the above features and how to
  take advantage of it for new use cases (thousands of edge deployments, etc).
  I see this as a sort of "TripleO Edge Deployment Guide" that would highlight
  how to take advantage of TripleO for Edge/multi-site use

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


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

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


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


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2018-08-20 Thread Zane Bitter

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

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

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

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

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

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

cheers,
Zane.

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

Re: [openstack-dev] [goal][python3] week 2 update

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 
 | https://review.openstack.org/593916 |
| add python 3.6 unit test job | openstack/sahara-tests 
 | https://review.openstack.org/593917 |

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


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


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




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


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


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


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


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


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

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2018-08-20 Thread Hongbin Lu

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

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

Yes, your interpretation is right.


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

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


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

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


Neutron wasn't split out of nova.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


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

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


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




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


I'll try to summarize my position:

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


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


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


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


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


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

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


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


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2018-08-20 Thread Ed Leafe

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

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

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

-- Ed Leafe

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


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

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


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


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


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2018-08-20 Thread Ed Leafe

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

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

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

-- Ed Leafe

signature.asc
Description: Message signed with OpenPGP
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


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

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


Yes, we use microversions for this reason.

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


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


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


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


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [goal][python3] week 2 update

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.

Doug

> 
> Thanks,
> 
> On Mon, Aug 20, 2018 at 1:13 PM Nguyễn Trí Hải 
> wrote:
> 
> > Hi,
> >
> > Vitrage team is going to finish the zuul job soon. As I see, only few
> > patches in the old branches need to be merged.
> >
> > For the other projects, some patches have problems with different errors.
> > Please help to fix them.
> >
> > Thanks for your cooperation.
> >
> > Nguyen Hai
> >
> >
> > On Tue, Aug 21, 2018, 12:27 AM Doug Hellmann 
> > wrote:
> >
> >> This is week 2 of the roll-out of the "Run under Python 3 by default"
> >> goal (https://governance.openstack.org/tc/goals/stein/python3-first.html
> >> ).
> >>
> >> == What we learned last week ==
> >>
> >> As we worked on approving the changes to add the zuul settings to
> >> a few Oslo repositories, we had trouble with some of the older
> >> branches because they were running newer versions of the jobs, as
> >> configured in project-config. To work around this problem, we removed
> >> those job templates in project-config by submitting separate patches
> >> (rather than waiting for the full clean-up patch). We used the Oslo
> >> team repos when we were testing some of the new jobs, so it is
> >> possible this won't come up for any other teams, but I thought I
> >> would mention the problem and solution, just in case.
> >>
> >> We had at least one question about the order in which the patches
> >> need to land across the branches. We need the ones with the subject
> >> "import zuul job settings from project-config" to land before the
> >> others, but it doesn't make any difference which branches go first.
> >> Those patches should be basically no-ops, neither adding nor changing
> >> any of the existing testing. The other follow-up patches change or
> >> add tests, and are submitted separately specifically so the changes
> >> they contain can be managed and issues fixed to allow them to land.
> >>
> >> Nguyen found a couple of cases where older branches did not work
> >> with the existing documentation job. The fix may require backporting
> >> changes to remove tox_install.sh, or other changes that have been
> >> made in newer stable branches but not backported all the way. Because
> >> the new documentation job runs through tox we may be able to use
> >> that in the older branches, as an alternative.
> >>
> >> We discovered last night that the version of git on CentOS does not
> >> support the -C option, so we will need to change our scripts to be
> >> compatible with the older platform.
> >>
> >> == Completed work ==
> >>
> >> Congratulations to the Documentation team for approving all of the
> >> patches to import their zuul job configuration!
> >>
> >> == Ongoing work ==
> >>
> >> The Oslo team is working on migrating their zuul settings.
> >>
> >> The Ironic, Vitrage, Cyborg, Solum, Tacker, Masakari, Congress,
> >> Designate, Mistral, Watcher, Glance, and Requirements teams have
> >> started migrating their zuul settings.
> >>
> >> The Ironic team has started working on adding functional tests that
> >> run under Python 3.
> >>
> >> Thanks to dtantsur for adding a variant of the python 3.6 jobs that
> >> installs neutron from source, needed by several networking-related
> >> projects that integrate tightly with neutron.
> >> https://review.openstack.org/#/c/593643/
> >>
> >> == Next Steps ==
> >>
> >> If your team is ready to have your zuul settings migrated, please
> >> let us know by following up to this email. We will start with the
> >> volunteers, and then work our way through the other teams.
> >>
> >> After the Rocky cycle-trailing projects are released, I will propose
> >> the change to project-config to change all of the packaging jobs
> >> to use the new publish-to-pypi-python3 template. We should be able
> >> to have that change in place before the first milestone for Stein
> >> so that we have an opportunity to test it.
> >>
> >> == How can you help? ==
> >>
> >> 1. Choose a patch that has failing tests and help fix it.
> >>
> >> https://review.openstack.org/#/q/topic:python3-first+status:open+(+label:Verified-1+OR+label:Verified-2+)
> >> 2. Review the patches for the zuul changes. Keep in mind that some of
> >>those patches will be on the stable branches for projects.
> >> 3. Work on adding functional test jobs that run under Python 3.
> >>
> >> == How can you ask for help? ==
> >>
> >> If you have any questions, please post them here to the openstack-dev
> >> list with the topic tag [python3] in the subject line. Posting
> >> questions to the mailing list will give the widest audience the
> >> chance to see the answers.
> >>
> >> We are using the #openstack-dev IRC channel for discussion as

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


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


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


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


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

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


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


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

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [os-upstream-institute] Restarting meetings on August 20

2018-08-20 Thread Tony Breeds

On Mon, Aug 20, 2018 at 10:23:07AM -0700, Kendall Nelson wrote:
> Hello Everyone,
> 
> To avoid meeting conflicts with the Women of OpenStack, we will actually be
> doing meetings weekly on Mondays at 20:00 UTC on odd weeks.
> 
> Long story short, our kickoff meeting after this luxurious summer break
> will be a week from today on August 27th.
> 
> Thanks everyone!
> 
> See you next week :)

I have a conflicting meeting on that schedule.  I'll do my best to
follow along from the meeting logs.

Yours Tony.


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

[openstack-dev] [all] [nova] [neutron] live migration with multiple port bindings.

2018-08-20 Thread Sean Mooney

HI everyone,

last week i spent some time testing the live migration capabilities
now that nova has started
to use neutron multiple port bindings. all testing unless otherwise
specifed was done
with Rocky RC1 or later commits on Centos 7.5 using devstack.


test summary
~~

i have tested the following scenarios with different levels of success.

linux bridge to linux bridge: Worked
ovs iptables to ovs iptables: Worked
ovs conntrack to ovs conntrack: Worked
ovs iptables to ovs conntrack: Worked
ovs conntrack to ovs iptables: Worked
linux bridge to ovs: migrtation succeded network connectivity broken
see bug 1788009
ovs to linux bridge: failed,  libvirt error due to lack of destination
bridge name see bug 1788012
ovs to ovs dpdk: failed qemu bug encountered on migrate. nova xml
generation appears correct.
ovs dpdk to ovs: failed another qemu bug encountered on migrate. nova
xml generation appears correct.
centos->ubuntu: failed emultor not found. see bug: 1788028

not that since iptables to conntrack migration now works operators will be able
to change this value once they have upgraded to rocky via a rolling
update using live migration.

host config



note that not all nodes were running the exact same commits as i added
addtional nodes later in my testing.
all nodes were at least at this level
nova sha: afe4512bf66c89a061b1a7ccd3e7ac8e3b1b284d
neutron sha: 1dda2bca862b1268c0f5ae39b7508f1b1cab6f15

nova was configured with
[compute]
live_migration_wait_for_vif_plug = True

and the nova commit above contains the revirt of the slow migration change.


test details


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

when i was testing live migration betweeen ovs with iptable and the
connection tracking firewall i
also did minimal testing to ensure the firewall work. i did this by
booting 3 vm.

2 VM A and B in the same security group and one in a seperate security
group VM C.

VM A and B where intially on differnet node ovs compute nodes with VM
A using iptables
and VM B using conntrack security group driver.

VM C was on the conntrac node.

before VM c was setup to ping vm B which is block by security groups
VM A was also configured to ping VM B which is allowed by security groups.

VM B was then live migrate from the conntrack node to the iptables
node and back while
observing the ping out put of VM A and C

druing this process it was observed that VM A contiued to ping VM B succesfully
and at no point was VM C able to ping VM B.

while this is by no means a complete test it indicates that security
groups appear to be configred before network conenctive
is restored on live migrating as expected.

i also noticed that the interval where network connectivity was lost
during live migrate was longer when going between
the ip table node to the conntrack node the  the reverse. i did not
investage why but i suspect this is related to some flow timeouts
in the contrack module.


other testing
~

about two week ago i also tested the numa aware vswitch sepc.
dureing that testing i confiimed that new isntaces were numa affined corectly
i also confirmed that while live migration succeded the numa pinnning
was not updated.
as this was expected i have not opened a bug for this since it will be
addressed in Stein by
the numa aware live migration sepc.


future testing
~

OVS-DPDK to OVS-DPDK
===
if i have time i will try and test live migration betwen two ovs-dpdk host.
this has worked since before nova supported vhost-user. i did not
test this case yet but its possible the qemu bug i hit in my
ovs to ovs-dpdk testing could also break ovs-dpdk to ovs-dpdk migration.

ovs to ovn

if i have time i may also test ovs to ovn migration.
this should just work but i  suspect that the same bug i hit with mixed
ovs and linux bridge clouds may exist and the vxlan tunnels mesh may
not be created.


BUGS
_

nova


when live migration fails due to a internal error rollback is not
handeled correctly. :- https://bugs.launchpad.net/nova/+bug/1788014
libvirt: nova assumed dest emultor path is the same as source and
fails to migrate if this is not true. :-
https://bugs.launchpad.net/nova/+bug/1788028


neutron
~

neutron bridge name is not always set for ml2/ovs: -
https://bugs.launchpad.net/neutron/+bug/1788009
bridge name not set in vif:binding-details by ml2/linux-bridge: -
https://bugs.launchpad.net/neutron/+bug/1788012
neutron does not form mesh tunnel overly between different ml2
driver.: - https://bugs.launchpad.net/neutron/+bug/1788023


regards
sean

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


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

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


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


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [senlin] Senlin Weekly Meeting Time Change

2018-08-20 Thread Duc Truong

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] [all] PyCharm Licences

2018-08-20 Thread Swapnil Kulkarni

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.

-- 
Best Regards,
Swapnil Kulkarni
irc : coolsvap

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

2018-08-20 Thread liu.xuefeng1

ok

























原始邮件



发件人：DucTruong 
收件人：openstack-dev@lists.openstack.org 
日 期 ：2018年08月21日 12:36
主 题 ：[openstack-dev] [senlin] Senlin Weekly Meeting Time Change


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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


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

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


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


Here is an example of the concern. In Sydney we talked about adding 
types to the consumers resource in placement so that nova could use 
placement for counting quotas [1]. Chris considered it a weird hack but 
it's pretty straight-forward from a nova consumption point of view. So 
if placement were separately governed with let's say Chris as PTL, would 
something like that become a holy war type issue because it's "weird" 
and convolutes the desire for a minimalist API? I think Chris' stance on 
this particular item has softened over time as more of a "meh" but it's 
a worry about extracting with a separate team that is against changes 
because they are not ideal for Placement yet are needed for a consumer 
of Placement. I understand this is likely selfish on the part of the 
nova people that want this (including myself) and maybe close-minded to 
alternative solutions to the problem (I'm not sure if it's all been 
thought out end-to-end yet, Mel would likely know the latest on this 
item). Anyway, I like to have examples when I'm stating something to 
gain understanding, so that's what I'm trying to do here - explain, with 
an example, what I said in the tc channel discussion today.


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

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kolla][project navigator] kolla missing in project navigator

Hi, effectively kolla-ansible is the deployment tool for container images,
and kolla the image artifact builder used by other deployment projects as
consumable.

In the project navigator wasn't kolla nor kolla-ansible, my bad for not
expecifying kolla-ansible as deployment deliverable.

Regards

On Mon, Aug 20, 2018, 4:31 PM Thierry Carrez  wrote:

> Eduardo,
>
> "Kolla" was originally left out of the map (and therefore the new
> OpenStack components page) because the map only shows deliverables that
> are directly usable by deployers. That is why "Kolla-Ansible" is listed
> there and not "Kolla".
>
> Are you making the case that Kolla should be used directly by deployers
> (rather than run it though Ansible with Kolla-Ansible), and therefore
> should appear as a deployment option on the map as well ?
>
> --
> 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] ?==?utf-8?q? [kolla][project?==?utf-8?q? navigator] kolla missing in project navigator

2018-08-20 Thread jean-philippe

On Monday, August 20, 2018 15:57 CEST, Jimmy McArthur  
wrote: 

> Eduardo,
> 
> Thanks for the heads up.  We're in the process of updating the Project 
> Navigator to match the OpenStack Map [1].  It looks like Kolla got lost 
> in the shuffle.  I've added it back to the Project [2Navigator under the 
> Deployment Tools section [2].
> 
> Please let me know if I can assist further.
> 
> Thanks,
> Jimmy
> 
> 
> [1] https://www.openstack.org/assets/software/projectmap/openstack-map.pdf
> [2] https://www.openstack.org/software/project-navigator/deployment-tools

That second link is very confusing, on the openstack-ansible case. Yes we ship 
recipes (roles, playbooks) for deployment using Ansible (any other ansible 
project could use them, maybe we need to adapt there if it's not the case...), 
but we also deal with the installation and upgrade of the openstack cloud. 
Therefore, shouldn't OSA also be listed in the "Deployment / Lifecycle Tools"?

Best regards,
Jean-Philippe Evrard (evrardjp)

__
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] ?= [kolla][project=?utf-8?q? navigator] kolla missing in project navigator


jean-phili...@evrard.me wrote:

That second link is very confusing, on the openstack-ansible case. Yes we ship recipes 
(roles, playbooks) for deployment using Ansible (any other ansible project could use 
them, maybe we need to adapt there if it's not the case...), but we also deal with the 
installation and upgrade of the openstack cloud. Therefore, shouldn't OSA also be listed 
in the "Deployment / Lifecycle Tools"?


Yes, the barrier between the two is rather porous. We used to only have 
TripleO on the other side, but more and more tools (like Charms, Helm) 
have maintained that their tooling is more than just a pile of recipes.


Once we have all that display driven through YAML files stored in a Git 
repo under Gerrit, we'll be able to fine tune that content, create more 
subcategories etc.


A bit of patience :)

--
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] [kolla][project navigator] kolla missing in project navigator


Eduardo Gonzalez wrote:
Hi, effectively kolla-ansible is the deployment tool for container 
images, and kolla the image artifact builder used by other deployment 
projects as consumable.


In the project navigator wasn't kolla nor kolla-ansible, my bad for not 
expecifying kolla-ansible as deployment deliverable.


OK, so how about we make sure *Kolla-Ansible* is present both in the map 
and the components list ?


--
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] [kolla][project navigator] kolla missing in project navigator

Yes, that was my intention. Didn't meant to say kolla as images, i meant
kolla-ansible.

On Mon, Aug 20, 2018, 4:59 PM Thierry Carrez  wrote:

> Eduardo Gonzalez wrote:
> > Hi, effectively kolla-ansible is the deployment tool for container
> > images, and kolla the image artifact builder used by other deployment
> > projects as consumable.
> >
> > In the project navigator wasn't kolla nor kolla-ansible, my bad for not
> > expecifying kolla-ansible as deployment deliverable.
>
> OK, so how about we make sure *Kolla-Ansible* is present both in the map
> and the components list ?
>
> --
> 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-dev] [neutron] Bug deputy report week Aug 12th - Aug 19th

2018-08-20 Thread Paweł Suder


Dear Neutron Team,

I was the bugs deputy for the week of Aug 12th - Aug 19th.

Here's the summary of the bugs that were filed:

Something what needs attention to clarify:

https://bugs.launchpad.net/neutron/+bug/1787385 - vpnaas and 
dynamic-routing missing neutron-tempest-plugin in test-requirements.txt
https://bugs.launchpad.net/neutron/+bug/1787420 - Floating ip 
association to router interface should be restricted - Confirmed 
behavior - should be like that?


New:

https://bugs.launchpad.net/neutron/+bug/1787534 - DNS extension broken 
for provider networks - configuration or code issue?


Confirmed:

https://bugs.launchpad.net/neutron/+bug/1786934 - Duplicating packet log 
when enable security group logging - another issue split from 
https://bugs.launchpad.net/neutron/+bug/1781372


In progress:

https://bugs.launchpad.net/neutron/+bug/1786746 - issue with not deleted 
NFLOG - fix proposed https://review.openstack.org/#/c/591978/


https://bugs.launchpad.net/neutron/+bug/1787028 - neutron returned 
internal server error on updating tags - issue observed on gates - ERROR 
neutron.api.v2.resource StaleDataError: UPDATE statement on table 
'standardattributes' expected to update 1 row(s); 0 were matched.


https://bugs.launchpad.net/neutron/+bug/1787106 - cannot ping over 
router between VMs in two different subnets, with allowed ICMP and set 
logging
https://bugs.launchpad.net/neutron/+bug/1787119 - [Logging] 
firewall_group log resource and security_group log resource could not 
co-exist correctly


Potentially RFE:

https://bugs.launchpad.net/neutron/+bug/1787793 - Does not support 
shared N-S qos per-tenant - looks like a RFE question?
https://bugs.launchpad.net/neutron/+bug/1787792 - Does not support ipv6 
N-S qos - looks like a RFE question?


Best regards,

--
Paweł Suder

__
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] [kuryr] No meeting today

2018-08-20 Thread Daniel Mellado Area

Hi folks,

since a couple of our core reviewers are on PTO today we have decided not
to host a meeting today.

If you have any questions just ping us at #openstack-kuryr

Best!

Daniel
__
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] [Openstack-operators] [puppet] migrating to storyboard


Hello Kendall,

I think you can just leave them in the group then, at your convenience.
If they are there we can start using them if so.

Best regards
Tobias

On 08/17/2018 11:08 PM, Kendall Nelson wrote:



On Fri, Aug 17, 2018 at 12:15 AM Tobias Urdin > wrote:


Hello Kendall,

I went through the list of projects [1] and could only really see
two things.

1) puppet-rally and puppet-openstack-guide is missing

I had created the projects, but missed adding them to the group. They 
should be there now :)


2) We have some support projects which doesn't really need bug
tracking, where some others do.
    You can remove puppet-openstack-specs and
puppet-openstack-cookiecutter all others would be
    nice to still have left so we can track bugs. [2]

i can remove them from the group if you want, but I don't think I can 
delete the projects entirely.


Best regards
Tobias

[1] https://storyboard-dev.openstack.org/#!/project_group/60

[2] Keeping puppet-openstack-integration (integration testing) and
puppet-openstack_spec_helper (helper for testing).
  These two usually has a lot of changes so would be good to
be able to track them.


On 08/16/2018 09:40 PM, Kendall Nelson wrote:

Hey :)

I created all the puppet openstack repos in the storyboard-dev
envrionment and made a project group[1]. I am struggling a bit
with finding all of your launchpad projects to perform the
migrations through, can you share a list of all of them?

-Kendall (diablo_rojo)

[1] https://storyboard-dev.openstack.org/#!/project_group/60


On Wed, Aug 15, 2018 at 12:08 AM Tobias Urdin
mailto:tobias.ur...@binero.se>> wrote:

Hello Kendall,

Thanks for your reply, that sounds awesome!
We can then dig around and see how everything looks when all
project bugs are imported to stories.

I see no issues with being able to move to Storyboard anytime
soon if the feedback for
moving is positive.

Best regards

Tobias


On 08/14/2018 09:06 PM, Kendall Nelson wrote:

Hello!

The error you hit can be resolved by adding launchpadlib to
your tox.ini if I recall correctly..

also, if you'd like, I can run a test migration of puppet's
launchpad projects into our storyboard-dev db (where I've
done a ton of other test migrations) if you want to see how
it looks/works with a larger db. Just let me know and I can
kick it off.

As for a time to migrate, if you all are good with it, we
usually schedule for Friday's so there is even less
activity. Its a small project config change and then we just
need an infra core to kick off the script once the change
merges.

-Kendall (diablo_rojo)

On Tue, Aug 14, 2018 at 9:33 AM Tobias Urdin
mailto:tobias.ur...@binero.se>> wrote:

Hello all incredible Puppeters,

I've tested setting up an Storyboard instance and test
migrated
puppet-ceph and it went without any issues there using
the documentation
[1] [2]
with just one minor issue during the SB setup [3].

My goal is that we will be able to swap to Storyboard
during the Stein
cycle but considering that we have a low activity on
bugs my opinion is that we could do this swap very
easily anything soon
as long as everybody is in favor of it.

Please let me know what you think about moving to
Storyboard?
If everybody is in favor of it we can request a
migration to infra
according to documentation [2].

I will continue to test the import of all our project
while people are
collecting their thoughts and feedback :)

Best regards
Tobias

[1]
https://docs.openstack.org/infra/storyboard/install/development.html
[2]
https://docs.openstack.org/infra/storyboard/migration.html
[3] It failed with an error about launchpadlib not being
installed,
solved with `tox -e venv pip install launchpadlib`


__
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-20 Thread Ivoline Ngong

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

Re: [openstack-dev] [neutron][neutron-classifier] info on common classifier

2018-08-20 Thread Shaughnessy, David

Hi Hemanth
The API is just waiting for its last review and will hopefully merge after that.
https://review.openstack.org/#/c/487182/25
We wanted to ensure that the project was thoroughly tested and setting up the 
project to run these tests took some time.
The patch to follow this one is an extension to the OpenStack client which 
would give the cli to interact with this plugin.
Regards.
David.

-Original Message-
From: Hemanth N [mailto:mail2hemant...@gmail.com] 
Sent: Monday, August 20, 2018 10:58 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron][neutron-classifier] info on common classifier

Hi

I am looking for information on Neutron Common Classifier. What is the 
implementation done today (Is API extension implemented?) and further plans for 
the same.

I could not get much information except for the specification and github 
https://specs.openstack.org/openstack/neutron-specs/specs/pike/common-classification-framework.html
https://github.com/openstack/neutron-classifier

Also could you provide any references to early adopters of 
neutron-common-classifier, if any.

Regards,
Hemanth

__
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] [neutron] neutron ipv6 radvd sends out link-local or nothing as def gw (L3 HA issue?)

Ok, so the issue here seems to be that I have a L3 HA router with SLAAC, 
both the active and standby router will
configure the SLAAC obtained address causing a conflict since both side 
share the same MAC address.


Is there any workaround for this? Should SLAAC even be enabled for 
interfaces on the standby router?


Best regards
Tobias

On 08/20/2018 11:37 AM, Tobias Urdin wrote:

Forgot [neutron] tag.

On 08/20/2018 11:36 AM, Tobias Urdin wrote:

Hello,

Note: before reading, this router was a regular router but was then 
disable, changed ha=true so it's now a L3 HA router, then it was 
enabled again.

CC openstack-dev for help or feedback if it's a possible bug.

I've been testing around with IPv6 and overall the experience has 
been positive but I've met some weird issue that I cannot put my head 
around.
So this is a neutron L3 router with an outside interface with a ipv4 
and ipv6 from the provider network and one inside interface for ipv4 
and one inside interface for ipv6.


The instances for some reason get's there default gateway as the ipv6 
link-local (in fe80::/10) from the router with SLAAC and radvd.


(. is provider network, . is inside network, they are 
masked so don't pay attention to the number per se)


*interfaces inside router:*
15: ha-9bde1bb1-bd:  mtu 1450 qdisc 
noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:05:80:32 brd ff:ff:ff:ff:ff:ff
    inet 169.254.192.7/18 brd 169.254.255.255 scope global ha-9bde1bb1-bd
   valid_lft forever preferred_lft forever
    inet 169.254.0.1/24 scope global ha-9bde1bb1-bd
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe05:8032/64 scope link
   valid_lft forever preferred_lft forever
19: qg-86e465f6-33:  mtu 1500 qdisc 
noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:3b:8b:a5 brd ff:ff:ff:ff:ff:ff
    inet 1.2.3.4/22 scope global qg-86e465f6-33
   valid_lft forever preferred_lft forever
    inet6 :::f/64 scope global nodad
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe3b:8ba5/64 scope link nodad
   valid_lft forever preferred_lft forever
1168: qr-5be04815-68:  mtu 1450 
qdisc noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:c3:85:bd brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.1/24 scope global qr-5be04815-68
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fec3:85bd/64 scope link
   valid_lft forever preferred_lft forever
1169: qr-7fad6b1b-c9:  mtu 1450 
qdisc noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:66:de:a8 brd ff:ff:ff:ff:ff:ff
    inet6 ::0:1::1/64 scope global nodad
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe66:dea8/64 scope link
   valid_lft forever preferred_lft forever

I get this error messages in dmesg on the network node:
[581085.858869] IPv6: qr-5be04815-68: IPv6 duplicate address 
::0:1:f816:3eff:fec3:85bd detected!
[581085.997497] IPv6: qr-7fad6b1b-c9: IPv6 duplicate address 
::0:1:f816:3eff:fe66:dea8 detected!
[581142.869939] IPv6: qr-5be04815-68: IPv6 duplicate address 
::0:1:f816:3eff:fec3:85bd detected!
[581143.182371] IPv6: qr-7fad6b1b-c9: IPv6 duplicate address 
::0:1:f816:3eff:fe66:dea8 detected!


*radvd:*
interface qr-7fad6b1b-c9
{
   AdvSendAdvert on;
   MinRtrAdvInterval 30;
   MaxRtrAdvInterval 100;

   AdvLinkMTU 1450;

   RDNSS  2001:4860:4860::  {};

   prefix ::0:1::/64
   {
    AdvOnLink on;
    AdvAutonomous on;
   };
};

*inside instance:*
ipv4 = 192.168.199.7
ipv6 = ::0:1:f816:3eff:fe29:723d/64 (from radvd SLAAC)

I can ping ipv4 gateway 192.168.199.1 and internet over ipv4.
I can ping ipv6 gateway ::0:1::1 but I can't ping the internet

checking the ipv6 routing table on my instance I either get no 
default gateway at all or I get a default gateway to a fe80::/10 
link-local address.

IIRC this worked before I changed the router to a L3 HA router.

Appreciate any feedback!

Best regards
Tobias




__
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][neutron-classifier] info on common classifier

2018-08-20 Thread Hemanth N

Hi

I am looking for information on Neutron Common Classifier. What is the
implementation done today (Is API extension implemented?) and further
plans for the same.

I could not get much information except for the specification and github
https://specs.openstack.org/openstack/neutron-specs/specs/pike/common-classification-framework.html
https://github.com/openstack/neutron-classifier

Also could you provide any references to early adopters of
neutron-common-classifier, if any.

Regards,
Hemanth

__
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] [neutron] neutron ipv6 radvd sends out link-local or nothing as def gw (L3 HA issue?)

Continuing forward, these patches should've fixed that 
https://review.openstack.org/#/q/topic:bug/1667756+(status:open+OR+status:merged)

I'm on Queens.

The two inside interfaces on the backup router:
[root@controller2 ~]# ip netns exec 
qrouter-0775785e-a93a-4501-917b-be92ff03f36a cat 
/proc/sys/net/ipv6/conf/qr-7fad6b1b-c9/accept_ra

1
[root@controller2 ~]# ip netns exec 
qrouter-0775785e-a93a-4501-917b-be92ff03f36a cat 
/proc/sys/net/ipv6/conf/qr-5be04815-68/accept_ra

1

Perhaps the accept_ra patches does not apply for enable/disable or 
routers changing from a normal router to a L3 HA router?

Best regards

On 08/20/2018 11:50 AM, Tobias Urdin wrote:
Ok, so the issue here seems to be that I have a L3 HA router with 
SLAAC, both the active and standby router will
configure the SLAAC obtained address causing a conflict since both 
side share the same MAC address.


Is there any workaround for this? Should SLAAC even be enabled for 
interfaces on the standby router?


Best regards
Tobias

On 08/20/2018 11:37 AM, Tobias Urdin wrote:

Forgot [neutron] tag.

On 08/20/2018 11:36 AM, Tobias Urdin wrote:

Hello,

Note: before reading, this router was a regular router but was then 
disable, changed ha=true so it's now a L3 HA router, then it was 
enabled again.

CC openstack-dev for help or feedback if it's a possible bug.

I've been testing around with IPv6 and overall the experience has 
been positive but I've met some weird issue that I cannot put my 
head around.
So this is a neutron L3 router with an outside interface with a ipv4 
and ipv6 from the provider network and one inside interface for ipv4 
and one inside interface for ipv6.


The instances for some reason get's there default gateway as the 
ipv6 link-local (in fe80::/10) from the router with SLAAC and radvd.


(. is provider network, . is inside network, they 
are masked so don't pay attention to the number per se)


*interfaces inside router:*
15: ha-9bde1bb1-bd:  mtu 1450 qdisc 
noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:05:80:32 brd ff:ff:ff:ff:ff:ff
    inet 169.254.192.7/18 brd 169.254.255.255 scope global 
ha-9bde1bb1-bd

   valid_lft forever preferred_lft forever
    inet 169.254.0.1/24 scope global ha-9bde1bb1-bd
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe05:8032/64 scope link
   valid_lft forever preferred_lft forever
19: qg-86e465f6-33:  mtu 1500 qdisc 
noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:3b:8b:a5 brd ff:ff:ff:ff:ff:ff
    inet 1.2.3.4/22 scope global qg-86e465f6-33
   valid_lft forever preferred_lft forever
    inet6 :::f/64 scope global nodad
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe3b:8ba5/64 scope link nodad
   valid_lft forever preferred_lft forever
1168: qr-5be04815-68:  mtu 1450 
qdisc noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:c3:85:bd brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.1/24 scope global qr-5be04815-68
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fec3:85bd/64 scope link
   valid_lft forever preferred_lft forever
1169: qr-7fad6b1b-c9:  mtu 1450 
qdisc noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:66:de:a8 brd ff:ff:ff:ff:ff:ff
    inet6 ::0:1::1/64 scope global nodad
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe66:dea8/64 scope link
   valid_lft forever preferred_lft forever

I get this error messages in dmesg on the network node:
[581085.858869] IPv6: qr-5be04815-68: IPv6 duplicate address 
::0:1:f816:3eff:fec3:85bd detected!
[581085.997497] IPv6: qr-7fad6b1b-c9: IPv6 duplicate address 
::0:1:f816:3eff:fe66:dea8 detected!
[581142.869939] IPv6: qr-5be04815-68: IPv6 duplicate address 
::0:1:f816:3eff:fec3:85bd detected!
[581143.182371] IPv6: qr-7fad6b1b-c9: IPv6 duplicate address 
::0:1:f816:3eff:fe66:dea8 detected!


*radvd:*
interface qr-7fad6b1b-c9
{
   AdvSendAdvert on;
   MinRtrAdvInterval 30;
   MaxRtrAdvInterval 100;

   AdvLinkMTU 1450;

   RDNSS  2001:4860:4860::  {};

   prefix ::0:1::/64
   {
    AdvOnLink on;
    AdvAutonomous on;
   };
};

*inside instance:*
ipv4 = 192.168.199.7
ipv6 = ::0:1:f816:3eff:fe29:723d/64 (from radvd SLAAC)

I can ping ipv4 gateway 192.168.199.1 and internet over ipv4.
I can ping ipv6 gateway ::0:1::1 but I can't ping the internet

checking the ipv6 routing table on my instance I either get no 
default gateway at all or I get a default gateway to a fe80::/10 
link-local address.

IIRC this worked before I changed the router to a L3 HA router.

Appreciate any feedback!

Best regards
Tobias






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [neutron] neutron ipv6 radvd sends out link-local or nothing as def gw (L3 HA issue?)


When I removed those ips and set accept_ra to 0 on the backup router:

ip netns exec qrouter-0775785e-a93a-4501-917b-be92ff03f36a sysctl -w 
net.ipv6.conf.qr-7fad6b1b-c9.accept_ra=0
ip netns exec qrouter-0775785e-a93a-4501-917b-be92ff03f36a sysctl -w 
net.ipv6.conf.qr-5be04815-68.accept_ra=0

ip netns exec qrouter-0775785e-a93a-4501-917b-be92ff03f36a ip a l
ip netns exec qrouter-0775785e-a93a-4501-917b-be92ff03f36a ip addr del 
::0:1:f816:3eff:fe66:dea8/64 dev qr-7fad6b1b-c9
ip netns exec qrouter-0775785e-a93a-4501-917b-be92ff03f36a ip addr del 
::0:1:f816:3eff:fec3:85bd/64 dev qr-5be04815-68


And enabled ipv6 forwarding on the active router:
ip netns exec qrouter-0775785e-a93a-4501-917b-be92ff03f36a sysctl -w 
net.ipv6.conf.all.forwarding=1


It started working again, I think this is an issue when disabling a 
router, change it to L3 HA and enable it again, so a bug?


Best regards
Tobias

On 08/20/2018 11:58 AM, Tobias Urdin wrote:
Continuing forward, these patches should've fixed that 
https://review.openstack.org/#/q/topic:bug/1667756+(status:open+OR+status:merged)

I'm on Queens.

The two inside interfaces on the backup router:
[root@controller2 ~]# ip netns exec 
qrouter-0775785e-a93a-4501-917b-be92ff03f36a cat 
/proc/sys/net/ipv6/conf/qr-7fad6b1b-c9/accept_ra

1
[root@controller2 ~]# ip netns exec 
qrouter-0775785e-a93a-4501-917b-be92ff03f36a cat 
/proc/sys/net/ipv6/conf/qr-5be04815-68/accept_ra

1

Perhaps the accept_ra patches does not apply for enable/disable or 
routers changing from a normal router to a L3 HA router?

Best regards

On 08/20/2018 11:50 AM, Tobias Urdin wrote:
Ok, so the issue here seems to be that I have a L3 HA router with 
SLAAC, both the active and standby router will
configure the SLAAC obtained address causing a conflict since both 
side share the same MAC address.


Is there any workaround for this? Should SLAAC even be enabled for 
interfaces on the standby router?


Best regards
Tobias

On 08/20/2018 11:37 AM, Tobias Urdin wrote:

Forgot [neutron] tag.

On 08/20/2018 11:36 AM, Tobias Urdin wrote:

Hello,

Note: before reading, this router was a regular router but was then 
disable, changed ha=true so it's now a L3 HA router, then it was 
enabled again.

CC openstack-dev for help or feedback if it's a possible bug.

I've been testing around with IPv6 and overall the experience has 
been positive but I've met some weird issue that I cannot put my 
head around.
So this is a neutron L3 router with an outside interface with a 
ipv4 and ipv6 from the provider network and one inside interface 
for ipv4 and one inside interface for ipv6.


The instances for some reason get's there default gateway as the 
ipv6 link-local (in fe80::/10) from the router with SLAAC and radvd.


(. is provider network, . is inside network, they 
are masked so don't pay attention to the number per se)


*interfaces inside router:*
15: ha-9bde1bb1-bd:  mtu 1450 
qdisc noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:05:80:32 brd ff:ff:ff:ff:ff:ff
    inet 169.254.192.7/18 brd 169.254.255.255 scope global 
ha-9bde1bb1-bd

   valid_lft forever preferred_lft forever
    inet 169.254.0.1/24 scope global ha-9bde1bb1-bd
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe05:8032/64 scope link
   valid_lft forever preferred_lft forever
19: qg-86e465f6-33:  mtu 1500 
qdisc noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:3b:8b:a5 brd ff:ff:ff:ff:ff:ff
    inet 1.2.3.4/22 scope global qg-86e465f6-33
   valid_lft forever preferred_lft forever
    inet6 :::f/64 scope global nodad
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe3b:8ba5/64 scope link nodad
   valid_lft forever preferred_lft forever
1168: qr-5be04815-68:  mtu 1450 
qdisc noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:c3:85:bd brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.1/24 scope global qr-5be04815-68
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fec3:85bd/64 scope link
   valid_lft forever preferred_lft forever
1169: qr-7fad6b1b-c9:  mtu 1450 
qdisc noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:66:de:a8 brd ff:ff:ff:ff:ff:ff
    inet6 ::0:1::1/64 scope global nodad
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe66:dea8/64 scope link
   valid_lft forever preferred_lft forever

I get this error messages in dmesg on the network node:
[581085.858869] IPv6: qr-5be04815-68: IPv6 duplicate address 
::0:1:f816:3eff:fec3:85bd detected!
[581085.997497] IPv6: qr-7fad6b1b-c9: IPv6 duplicate address 
::0:1:f816:3eff:fe66:dea8 detected!
[581142.869939] IPv6: qr-5be04815-68: IPv6 duplicate address 
::0:1:f816:3eff:fec3:85bd detected!
[581143.182371] IPv6: qr-7fad6b1b-c9: IPv6 duplicate address 
::0:1:f816:3eff:fe66:dea8 detected!


*radvd:*
interface qr-7fad6b1b-c9

Re: [openstack-dev] New Contributor


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-dev] neutron ipv6 radvd sends out link-local or nothing as def gw (L3 HA issue?)


Hello,

Note: before reading, this router was a regular router but was then 
disable, changed ha=true so it's now a L3 HA router, then it was enabled 
again.

CC openstack-dev for help or feedback if it's a possible bug.

I've been testing around with IPv6 and overall the experience has been 
positive but I've met some weird issue that I cannot put my head around.
So this is a neutron L3 router with an outside interface with a ipv4 and 
ipv6 from the provider network and one inside interface for ipv4 and one 
inside interface for ipv6.


The instances for some reason get's there default gateway as the ipv6 
link-local (in fe80::/10) from the router with SLAAC and radvd.


(. is provider network, . is inside network, they are 
masked so don't pay attention to the number per se)


*interfaces inside router:*
15: ha-9bde1bb1-bd:  mtu 1450 qdisc 
noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:05:80:32 brd ff:ff:ff:ff:ff:ff
    inet 169.254.192.7/18 brd 169.254.255.255 scope global ha-9bde1bb1-bd
   valid_lft forever preferred_lft forever
    inet 169.254.0.1/24 scope global ha-9bde1bb1-bd
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe05:8032/64 scope link
   valid_lft forever preferred_lft forever
19: qg-86e465f6-33:  mtu 1500 qdisc 
noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:3b:8b:a5 brd ff:ff:ff:ff:ff:ff
    inet 1.2.3.4/22 scope global qg-86e465f6-33
   valid_lft forever preferred_lft forever
    inet6 :::f/64 scope global nodad
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe3b:8ba5/64 scope link nodad
   valid_lft forever preferred_lft forever
1168: qr-5be04815-68:  mtu 1450 qdisc 
noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:c3:85:bd brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.1/24 scope global qr-5be04815-68
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fec3:85bd/64 scope link
   valid_lft forever preferred_lft forever
1169: qr-7fad6b1b-c9:  mtu 1450 qdisc 
noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:66:de:a8 brd ff:ff:ff:ff:ff:ff
    inet6 ::0:1::1/64 scope global nodad
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe66:dea8/64 scope link
   valid_lft forever preferred_lft forever

I get this error messages in dmesg on the network node:
[581085.858869] IPv6: qr-5be04815-68: IPv6 duplicate address 
::0:1:f816:3eff:fec3:85bd detected!
[581085.997497] IPv6: qr-7fad6b1b-c9: IPv6 duplicate address 
::0:1:f816:3eff:fe66:dea8 detected!
[581142.869939] IPv6: qr-5be04815-68: IPv6 duplicate address 
::0:1:f816:3eff:fec3:85bd detected!
[581143.182371] IPv6: qr-7fad6b1b-c9: IPv6 duplicate address 
::0:1:f816:3eff:fe66:dea8 detected!


*radvd:*
interface qr-7fad6b1b-c9
{
   AdvSendAdvert on;
   MinRtrAdvInterval 30;
   MaxRtrAdvInterval 100;

   AdvLinkMTU 1450;

   RDNSS  2001:4860:4860::  {};

   prefix ::0:1::/64
   {
    AdvOnLink on;
    AdvAutonomous on;
   };
};

*inside instance:*
ipv4 = 192.168.199.7
ipv6 = ::0:1:f816:3eff:fe29:723d/64 (from radvd SLAAC)

I can ping ipv4 gateway 192.168.199.1 and internet over ipv4.
I can ping ipv6 gateway ::0:1::1 but I can't ping the internet

checking the ipv6 routing table on my instance I either get no default 
gateway at all or I get a default gateway to a fe80::/10 link-local address.

IIRC this worked before I changed the router to a L3 HA router.

Appreciate any feedback!

Best regards
Tobias
__
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?


Chris Dent wrote:

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

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


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

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


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

- being in separate teams does not prevent cooperation or coordination

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [all] [tc] Who is responsible for the mission and scope of OpenStack?

2018-08-20 Thread Chris Dent



TC-members and everyone else,

In the discussion on a draft technical vision for OpenStack at

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

there is a question about whether the TC is "responsible for the
mission and scope of OpenStack".

As the discussion there indicates, there is plenty of nuance, but
underlying it is a pretty fundamental question that seems important
to answer as we're going into yet another TC election period.

I've always assumed it was the case: the TC is an elected
representative body of the so-called active technical contributors
to OpenStack. So while the TC is not responsible for creating the
mission from whole cloth, they are responsible for representing the
goals of the people who elected them and thus for refining,
documenting and caring for the mission and scope while working with
all the other people invested in the community.

Does anyone disagree? If so, who is responsible if not the TC?

--
Chris Dent   ٩◔̯◔۶   https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2018-08-20 Thread TETSURO NAKAMURA


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


+1 on extract.

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


--
Tetsuro Nakamura 
NTT Network Service Systems Laboratories




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [tc] Who is responsible for the mission and scope of OpenStack?


Chris Dent wrote:

In the discussion on a draft technical vision for OpenStack at

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

there is a question about whether the TC is "responsible for the
mission and scope of OpenStack".

As the discussion there indicates, there is plenty of nuance, but
underlying it is a pretty fundamental question that seems important
to answer as we're going into yet another TC election period.

I've always assumed it was the case: the TC is an elected
representative body of the so-called active technical contributors
to OpenStack. So while the TC is not responsible for creating the
mission from whole cloth, they are responsible for representing the
goals of the people who elected them and thus for refining,
documenting and caring for the mission and scope while working with
all the other people invested in the community.

Does anyone disagree? If so, who is responsible if not the TC?


A few indications from the bylaws:

The TC manages "technical matters relating to the OpenStack Project".
The "OpenStack project" is defined as "the released projects to enable 
cloud computing and the associated library projects, gating projects, 
and supporting projects".


The TC cooperates with the board to apply the OpenStack trademark : it 
approves components for trademark programs inclusion, and the board 
decides whether to apply it to those or not. In that sense, the TC is in 
charge of the "scope" of "OpenStack", since it decides which components 
may be added to things that bear the "OpenStack" name. But ultimately 
the board is in charge of the trademark, and not apply it even to things 
we deem in scope.


As far as the mission goes, the bylaws just indicate that the OpenStack 
project is an "open source cloud computing project". Beyond that, we 
have an official OpenStack mission statement. In the past, we ruled that 
this statement was co-owned by the Board and the TC, and that changes to 
it would need to pass *both* bodies.


So I think the answer is... The Board and the TC co-own the mission and 
the scope of OpenStack. The TC is in charge of the technical side, 
especially when it comes to implementation. The Board is in charge of 
the trademark side (it ultimately owns what can be called "OpenStack").


--
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-dev] [neutron] neutron ipv6 radvd sends out link-local or nothing as def gw (L3 HA issue?)


Forgot [neutron] tag.

On 08/20/2018 11:36 AM, Tobias Urdin wrote:

Hello,

Note: before reading, this router was a regular router but was then 
disable, changed ha=true so it's now a L3 HA router, then it was 
enabled again.

CC openstack-dev for help or feedback if it's a possible bug.

I've been testing around with IPv6 and overall the experience has been 
positive but I've met some weird issue that I cannot put my head around.
So this is a neutron L3 router with an outside interface with a ipv4 
and ipv6 from the provider network and one inside interface for ipv4 
and one inside interface for ipv6.


The instances for some reason get's there default gateway as the ipv6 
link-local (in fe80::/10) from the router with SLAAC and radvd.


(. is provider network, . is inside network, they are 
masked so don't pay attention to the number per se)


*interfaces inside router:*
15: ha-9bde1bb1-bd:  mtu 1450 qdisc 
noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:05:80:32 brd ff:ff:ff:ff:ff:ff
    inet 169.254.192.7/18 brd 169.254.255.255 scope global ha-9bde1bb1-bd
   valid_lft forever preferred_lft forever
    inet 169.254.0.1/24 scope global ha-9bde1bb1-bd
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe05:8032/64 scope link
   valid_lft forever preferred_lft forever
19: qg-86e465f6-33:  mtu 1500 qdisc 
noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:3b:8b:a5 brd ff:ff:ff:ff:ff:ff
    inet 1.2.3.4/22 scope global qg-86e465f6-33
   valid_lft forever preferred_lft forever
    inet6 :::f/64 scope global nodad
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe3b:8ba5/64 scope link nodad
   valid_lft forever preferred_lft forever
1168: qr-5be04815-68:  mtu 1450 qdisc 
noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:c3:85:bd brd ff:ff:ff:ff:ff:ff
    inet 192.168.99.1/24 scope global qr-5be04815-68
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fec3:85bd/64 scope link
   valid_lft forever preferred_lft forever
1169: qr-7fad6b1b-c9:  mtu 1450 qdisc 
noqueue state UNKNOWN group default qlen 1000

    link/ether fa:16:3e:66:de:a8 brd ff:ff:ff:ff:ff:ff
    inet6 ::0:1::1/64 scope global nodad
   valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe66:dea8/64 scope link
   valid_lft forever preferred_lft forever

I get this error messages in dmesg on the network node:
[581085.858869] IPv6: qr-5be04815-68: IPv6 duplicate address 
::0:1:f816:3eff:fec3:85bd detected!
[581085.997497] IPv6: qr-7fad6b1b-c9: IPv6 duplicate address 
::0:1:f816:3eff:fe66:dea8 detected!
[581142.869939] IPv6: qr-5be04815-68: IPv6 duplicate address 
::0:1:f816:3eff:fec3:85bd detected!
[581143.182371] IPv6: qr-7fad6b1b-c9: IPv6 duplicate address 
::0:1:f816:3eff:fe66:dea8 detected!


*radvd:*
interface qr-7fad6b1b-c9
{
   AdvSendAdvert on;
   MinRtrAdvInterval 30;
   MaxRtrAdvInterval 100;

   AdvLinkMTU 1450;

   RDNSS  2001:4860:4860::  {};

   prefix ::0:1::/64
   {
    AdvOnLink on;
    AdvAutonomous on;
   };
};

*inside instance:*
ipv4 = 192.168.199.7
ipv6 = ::0:1:f816:3eff:fe29:723d/64 (from radvd SLAAC)

I can ping ipv4 gateway 192.168.199.1 and internet over ipv4.
I can ping ipv6 gateway ::0:1::1 but I can't ping the internet

checking the ipv6 routing table on my instance I either get no default 
gateway at all or I get a default gateway to a fe80::/10 link-local 
address.

IIRC this worked before I changed the router to a L3 HA router.

Appreciate any feedback!

Best regards
Tobias


__
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] [ptg] Register now ! Price increases Wednesday


Hi everyone,

If you haven't registered for the PTG in Denver yet, I'd recommend you 
do it today or tomorrow as the price will switch to last-minute pricing 
at the end of day on August 22 !


https://www.openstack.org/ptg

Protip: There might still be a couple of rooms available in the PTG 
hotel, but our hotel block closes TODAY. So book now if you want to be 
at the center of the activity !


--
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] [neutron] neutron ipv6 radvd sends out link-local or nothing as def gw (L3 HA issue?)

2018-08-20 Thread Assaf Muller

On Mon, Aug 20, 2018 at 6:06 AM, Tobias Urdin  wrote:
> When I removed those ips and set accept_ra to 0 on the backup router:
>
> ip netns exec qrouter-0775785e-a93a-4501-917b-be92ff03f36a sysctl -w
> net.ipv6.conf.qr-7fad6b1b-c9.accept_ra=0
> ip netns exec qrouter-0775785e-a93a-4501-917b-be92ff03f36a sysctl -w
> net.ipv6.conf.qr-5be04815-68.accept_ra=0
> ip netns exec qrouter-0775785e-a93a-4501-917b-be92ff03f36a ip a l
> ip netns exec qrouter-0775785e-a93a-4501-917b-be92ff03f36a ip addr del
> ::0:1:f816:3eff:fe66:dea8/64 dev qr-7fad6b1b-c9
> ip netns exec qrouter-0775785e-a93a-4501-917b-be92ff03f36a ip addr del
> ::0:1:f816:3eff:fec3:85bd/64 dev qr-5be04815-68
>
> And enabled ipv6 forwarding on the active router:
> ip netns exec qrouter-0775785e-a93a-4501-917b-be92ff03f36a sysctl -w
> net.ipv6.conf.all.forwarding=1
>
> It started working again, I think this is an issue when disabling a router,
> change it to L3 HA and enable it again, so a bug?

Quite possibly. Are you able to find a minimal reproducer?

>
> Best regards
> Tobias
>
>
> On 08/20/2018 11:58 AM, Tobias Urdin wrote:
>
> Continuing forward, these patches should've fixed that
> https://review.openstack.org/#/q/topic:bug/1667756+(status:open+OR+status:merged)
> I'm on Queens.
>
> The two inside interfaces on the backup router:
> [root@controller2 ~]# ip netns exec
> qrouter-0775785e-a93a-4501-917b-be92ff03f36a cat
> /proc/sys/net/ipv6/conf/qr-7fad6b1b-c9/accept_ra
> 1
> [root@controller2 ~]# ip netns exec
> qrouter-0775785e-a93a-4501-917b-be92ff03f36a cat
> /proc/sys/net/ipv6/conf/qr-5be04815-68/accept_ra
> 1
>
> Perhaps the accept_ra patches does not apply for enable/disable or routers
> changing from a normal router to a L3 HA router?
> Best regards
>
> On 08/20/2018 11:50 AM, Tobias Urdin wrote:
>
> Ok, so the issue here seems to be that I have a L3 HA router with SLAAC,
> both the active and standby router will
> configure the SLAAC obtained address causing a conflict since both side
> share the same MAC address.
>
> Is there any workaround for this? Should SLAAC even be enabled for
> interfaces on the standby router?
>
> Best regards
> Tobias
>
> On 08/20/2018 11:37 AM, Tobias Urdin wrote:
>
> Forgot [neutron] tag.
>
> On 08/20/2018 11:36 AM, Tobias Urdin wrote:
>
> Hello,
>
> Note: before reading, this router was a regular router but was then disable,
> changed ha=true so it's now a L3 HA router, then it was enabled again.
> CC openstack-dev for help or feedback if it's a possible bug.
>
> I've been testing around with IPv6 and overall the experience has been
> positive but I've met some weird issue that I cannot put my head around.
> So this is a neutron L3 router with an outside interface with a ipv4 and
> ipv6 from the provider network and one inside interface for ipv4 and one
> inside interface for ipv6.
>
> The instances for some reason get's there default gateway as the ipv6
> link-local (in fe80::/10) from the router with SLAAC and radvd.
>
> (. is provider network, . is inside network, they are masked
> so don't pay attention to the number per se)
>
> interfaces inside router:
> 15: ha-9bde1bb1-bd:  mtu 1450 qdisc noqueue
> state UNKNOWN group default qlen 1000
> link/ether fa:16:3e:05:80:32 brd ff:ff:ff:ff:ff:ff
> inet 169.254.192.7/18 brd 169.254.255.255 scope global ha-9bde1bb1-bd
>valid_lft forever preferred_lft forever
> inet 169.254.0.1/24 scope global ha-9bde1bb1-bd
>valid_lft forever preferred_lft forever
> inet6 fe80::f816:3eff:fe05:8032/64 scope link
>valid_lft forever preferred_lft forever
> 19: qg-86e465f6-33:  mtu 1500 qdisc noqueue
> state UNKNOWN group default qlen 1000
> link/ether fa:16:3e:3b:8b:a5 brd ff:ff:ff:ff:ff:ff
> inet 1.2.3.4/22 scope global qg-86e465f6-33
>valid_lft forever preferred_lft forever
> inet6 :::f/64 scope global nodad
>valid_lft forever preferred_lft forever
> inet6 fe80::f816:3eff:fe3b:8ba5/64 scope link nodad
>valid_lft forever preferred_lft forever
> 1168: qr-5be04815-68:  mtu 1450 qdisc
> noqueue state UNKNOWN group default qlen 1000
> link/ether fa:16:3e:c3:85:bd brd ff:ff:ff:ff:ff:ff
> inet 192.168.99.1/24 scope global qr-5be04815-68
>valid_lft forever preferred_lft forever
> inet6 fe80::f816:3eff:fec3:85bd/64 scope link
>valid_lft forever preferred_lft forever
> 1169: qr-7fad6b1b-c9:  mtu 1450 qdisc
> noqueue state UNKNOWN group default qlen 1000
> link/ether fa:16:3e:66:de:a8 brd ff:ff:ff:ff:ff:ff
> inet6 ::0:1::1/64 scope global nodad
>valid_lft forever preferred_lft forever
> inet6 fe80::f816:3eff:fe66:dea8/64 scope link
>valid_lft forever preferred_lft forever
>
> I get this error messages in dmesg on the network node:
> [581085.858869] IPv6: qr-5be04815-68: IPv6 duplicate address
> ::0:1:f816:3eff:fec3:85bd detected!
> [581085.997497] IPv6: qr-7fad6b1b-c9: IPv6 duplicate address
>

Re: [openstack-dev] [oslo] proposing Moisés Guimarães for oslo.config core

2018-08-20 Thread Stephen Finucane

On Mon, 2018-08-13 at 17:39 -0500, Ben Nemec wrote:
> 
> On 08/08/2018 08:18 AM, Doug Hellmann wrote:
> > Excerpts from Doug Hellmann's message of 2018-08-01 09:27:09 -0400:
> > > Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
> > > during the Rocky cycle to add driver support. Based on that work,
> > > and a discussion we have had since then about general cleanup needed
> > > in oslo.config, I think he would make a good addition to the
> > > oslo.config review team.
> > > 
> > > Please indicate your approval or concerns with +1/-1.
> > > 
> > > Doug
> > 
> > Normally I would have added moguimar to the oslo-config-core team
> > today, after a week's wait. Funny story, though. There is no
> > oslo-config-core team.
> > 
> > oslo.config is one of a few of our libraries that we never set up with a
> > separate review team. It is managed by oslo-core. We could set up a new
> > review team for that library, but after giving it some thought I
> > realized that *most* of the libraries are fairly stable, our team is
> > pretty small, and Moisés is a good guy so maybe we don't need to worry
> > about that.
> > 
> > I spoke with Moisés, and he agreed to be part of the larger core team.
> > He pointed out that the next phase of the driver work is going to happen
> > in castellan, so it would be useful to have another reviewer there. And
> > I'm sure we can trust him to be careful with reviews in other repos
> > until he learns his way around.
> > 
> > So, I would like to amend my original proposal and suggest that we add
> > Moisés to the oslo-core team.
> > 
> > Please indicate support with +1 or present any concerns you have. I
> > apologize for the confusion on my part.
> 
> I'm good with this reasoning, so +1 from me.

As above. +1



__
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] [kolla][project navigator] kolla missing in project navigator

Hi,

while checking around the project navigator, I don't see kolla in the
deployment tools section.

How could we get kolla appear in the navigator along other deployment tools?

Regards
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2018-08-20 Thread Jay Pipes


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

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

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


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


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


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


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


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


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


Consider me +0.

Best,
-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [astara] Retirement of astara repos?

2018-08-20 Thread Mark McClain

Yeah. I’ll post the retirement commits this week.

mark

> On Aug 18, 2018, at 13:39, Andreas Jaeger  wrote:
> 
> Mark, shall I start the retirement of astara now? I would appreciate a "go 
> ahead" - unless you want to do it yourself...
> 
> Andreas
> 
>> On 2018-02-23 14:34, Andreas Jaeger wrote:
>>> On 2018-01-11 22:55, Mark McClain wrote:
>>> Sean, Andreas-
>>> 
>>> Sorry I missed Andres’ message earlier in December about retiring astara. 
>>> Everyone is correct that development stopped a good while ago.  We 
>>> attempted in Barcelona to find others in the community to take over the 
>>> day-to-day management of the project. Unfortunately, nothing sustained 
>>> resulted from that session.
>>> 
>>> I’ve intentionally delayed archiving the repos because of background 
>>> conversations around restarting active development for some pieces bubble 
>>> up from time-to-time.  I’ll contact those I know were interested and try 
>>> for a resolution to propose before the PTG.
>> Mark, any update here?
> 
> -- 
> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>   HRB 21284 (AG Nürnberg)
>GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
> 


__
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] [tc] Who is responsible for the mission and scope of OpenStack?

Excerpts from Thierry Carrez's message of 2018-08-20 11:33:30 +0200:
> Chris Dent wrote:
> > In the discussion on a draft technical vision for OpenStack at
> > 
> >      https://review.openstack.org/#/c/592205/
> > 
> > there is a question about whether the TC is "responsible for the
> > mission and scope of OpenStack".
> > 
> > As the discussion there indicates, there is plenty of nuance, but
> > underlying it is a pretty fundamental question that seems important
> > to answer as we're going into yet another TC election period.
> > 
> > I've always assumed it was the case: the TC is an elected
> > representative body of the so-called active technical contributors
> > to OpenStack. So while the TC is not responsible for creating the
> > mission from whole cloth, they are responsible for representing the
> > goals of the people who elected them and thus for refining,
> > documenting and caring for the mission and scope while working with
> > all the other people invested in the community.
> > 
> > Does anyone disagree? If so, who is responsible if not the TC?
> 
> A few indications from the bylaws:
> 
> The TC manages "technical matters relating to the OpenStack Project".
> The "OpenStack project" is defined as "the released projects to enable 
> cloud computing and the associated library projects, gating projects, 
> and supporting projects".
> 
> The TC cooperates with the board to apply the OpenStack trademark : it 
> approves components for trademark programs inclusion, and the board 
> decides whether to apply it to those or not. In that sense, the TC is in 
> charge of the "scope" of "OpenStack", since it decides which components 
> may be added to things that bear the "OpenStack" name. But ultimately 
> the board is in charge of the trademark, and not apply it even to things 
> we deem in scope.
> 
> As far as the mission goes, the bylaws just indicate that the OpenStack 
> project is an "open source cloud computing project". Beyond that, we 
> have an official OpenStack mission statement. In the past, we ruled that 
> this statement was co-owned by the Board and the TC, and that changes to 
> it would need to pass *both* bodies.
> 
> So I think the answer is... The Board and the TC co-own the mission and 
> the scope of OpenStack. The TC is in charge of the technical side, 
> especially when it comes to implementation. The Board is in charge of 
> the trademark side (it ultimately owns what can be called "OpenStack").
> 

Thierry's description matches my understanding. The most recent
update to the mission statement (to add "users") was a joint effort
between the TC and Board.

As far as scope for new projects goes, we have said they "should
help further the OpenStack mission, by providing a cloud infrastructure
service, or directly building on an existing OpenStack infrastructure
service." [1]

I don't think there's any problem with writing down more detail
about what we mean by "should help further the OpenStack mission". If
anything, it gives us an opportunity to ensure that our interpretation
is aligned with the Board's.

Doug

[1] https://governance.openstack.org/tc/reference/new-projects-requirements.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] [kolla][project navigator] kolla missing in project navigator


Eduardo,

"Kolla" was originally left out of the map (and therefore the new 
OpenStack components page) because the map only shows deliverables that 
are directly usable by deployers. That is why "Kolla-Ansible" is listed 
there and not "Kolla".


Are you making the case that Kolla should be used directly by deployers 
(rather than run it though Ansible with Kolla-Ansible), and therefore 
should appear as a deployment option on the map as well ?


--
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] [kolla][project navigator] kolla missing in project navigator

2018-08-20 Thread Jimmy McArthur


Eduardo,

Thanks for the heads up.  We're in the process of updating the Project 
Navigator to match the OpenStack Map [1].  It looks like Kolla got lost 
in the shuffle.  I've added it back to the Project [2Navigator under the 
Deployment Tools section [2].


Please let me know if I can assist further.

Thanks,
Jimmy


[1] https://www.openstack.org/assets/software/projectmap/openstack-map.pdf
[2] https://www.openstack.org/software/project-navigator/deployment-tools

Eduardo Gonzalez wrote:

Hi,

while checking around the project navigator, I don't see kolla in the 
deployment tools section.


How could we get kolla appear in the navigator along other deployment 
tools?


Regards
__
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] [kolla][project navigator] kolla missing in project navigator