date:20180828

Excerpts from Tony Breeds's message of 2018-08-28 15:15:00 +1000:
> Election details: https://governance.openstack.org/election/
> 
> Please read the stipulations and timelines for candidates and
> electorate contained in this governance documentation.
> 
> There will be further announcements posted to the mailing list as
> action is required from the electorate or candidates. This email
> is for information purposes only.
> 
> If you have any questions which you feel affect others please reply
> to this email thread.
> 
> If you have any questions that you which to discuss in private please
> email any of the election officials[1] so that we may address your
> concerns.
> 
> Thank you,
> 
> [1] https://governance.openstack.org/election/#election-officials
> 
> 
> Yours Tony.

This is a good time for everyone in the community to start thinking
about who you want to have serving on the TC, and to encourage those
folks to run. Don't rely on them to nominate themselves without being
prompted.

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] [nova] [placement] XenServer CI failed frequently because of placement update

2018-08-28 Thread Naichuan Sun

Thank you very much for the help, Bob, Jay and Eric.

Naichuan Sun

-Original Message-
From: Bob Ball [mailto:bob.b...@citrix.com] 
Sent: Wednesday, August 29, 2018 12:22 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [nova] [placement] XenServer CI failed frequently 
because of placement update

> Yeah, the nova.CONF cpu_allocation_ratio is being overridden to 0.0:

The default there is 0.0[1] - and the passing tempest-full from Zuul on 
https://review.openstack.org/#/c/590041/ has the same line when reading the 
config[2]:

We'll have a dig to see if we can figure out why it's not defaulting to 16 in 
the ComputeNode.

Thanks!

Bob

[1] https://git.openstack.org/cgit/openstack/nova/tree/nova/conf/compute.py#n386
[2] 
http://logs.openstack.org/41/590041/17/check/tempest-full/b3f9ddd/controller/logs/screen-n-cpu.txt.gz#_Aug_27_14_18_24_078058
__
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] [tempest][qa][congress] trouble setting tempest feature flag

2018-08-28 Thread Eric K

Any thoughts on what could be going wrong that the tempest tests still
see the default conf values rather than those set here? Thanks lots!

Here is the devstack log line showing the flags being set:
http://logs.openstack.org/64/594564/4/check/congress-devstack-api-mysql/ce34264/logs/devstacklog.txt.gz#_2018-08-28_21_23_15_934

On Wed, Aug 22, 2018 at 9:12 AM Eric K  wrote:
>
> Hi all,
>
> I have added feature flags for the congress tempest plugin [1] and set
> them in the devstack plugin [2], but the flags seem to be ignored. The
> tests are skipped [3] according to the default False flag rather than
> run according to the True flag set in devstack plugin. Any hints on
> what may be wrong? Thanks so much!
>
> [1] https://review.openstack.org/#/c/594747/3
> [2] https://review.openstack.org/#/c/594793/1/devstack/plugin.sh
> [3] 
> http://logs.openstack.org/64/594564/3/check/congress-devstack-api-mysql/b2cd46f/logs/testr_results.html.gz
> (the bottom two skipped tests were expected to run)

__
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] goal champion tools

The story with all of the tasks for tracking the zuul migration has so
many comments it will no longer display in my browser. So, I've created
2 tools to look at the data from the command line.

https://review.openstack.org/597245 has a tool to list the task
assignments

https://review.openstack.org/597244 has a tool to change the task
assignment for 1 task

The UX for the assignment tool is terrible, so you have to provide
your numerical user ID. The easiest way to find that may be to use
the list tool and copy it from one of the tasks already assigned
to you.

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] [goal][python3] week 3 update

Excerpts from Michel Peterson's message of 2018-08-28 16:30:02 +0300:
> On Mon, Aug 27, 2018 at 10:37 PM, Doug Hellmann 
> wrote:
> 
> >
> > 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.
> >
> 
> The networking-odl team is willing to volunteer for this.

networking-odl is part of the neutron team, and the tools are set up to
work based on full (not partial) teams. So, if the neutron team is ready
we can go ahead with those.

Let us know.

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] [goal][python3] week 3 update

Excerpts from Doug Hellmann's message of 2018-08-28 17:42:29 -0400:
> Excerpts from Zane Bitter's message of 2018-08-28 16:47:06 -0400:
> > On 27/08/18 15:37, Doug Hellmann wrote:
> > > == 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.
> > 
> > Heat is ready. I already did master (and by extension stable/rocky) a 
> > little while back in openstack/heat, but you should check that it's 
> > correct :)
> > 
> > - ZB
> > 
> 
> OK, I ran the scripts and generated a bunch of patches for all of
> your repositories. You will want to review the ones on master
> carefully if you have already done part of the work. Let me know
> if you have questions about resolving any conflicts.

Small correction: My query tool that built the list below doesn't
differentiate based on author, so it looks like some of those patches
are actually created by other folks and using the 'python3-first'
topic.

Doug

> 
> Doug
> 
> +--+---+---+
> | Subject  | Repo 
>  | Branch|
> +--+---+---+
> | import zuul job settings from project-config | openstack-dev/heat-cfnclient 
>  | master|
> | add python 3.6 unit test job | openstack-dev/heat-cfnclient 
>  | master|
> | add python 3.6 unit test job | openstack-dev/heat-cfnclient 
>  | master|
> | convert py35 jobs to py3 | openstack/heat   
>  | master|
> | import zuul job settings from project-config | openstack/heat   
>  | master|
> | switch documentation job to new PTI  | openstack/heat   
>  | master|
> | add python 3.6 unit test job | openstack/heat   
>  | master|
> | import zuul job settings from project-config | openstack/heat   
>  | stable/ocata  |
> | import zuul job settings from project-config | openstack/heat   
>  | stable/pike   |
> | import zuul job settings from project-config | openstack/heat   
>  | stable/queens |
> | import zuul job settings from project-config | openstack/heat   
>  | stable/rocky  |
> | import zuul job settings from project-config | openstack/heat-agents
>  | master|
> | switch documentation job to new PTI  | openstack/heat-agents
>  | master|
> | add python 3.6 unit test job | openstack/heat-agents
>  | master|
> | import zuul job settings from project-config | openstack/heat-agents
>  | stable/ocata  |
> | import zuul job settings from project-config | openstack/heat-agents
>  | stable/pike   |
> | import zuul job settings from project-config | openstack/heat-agents
>  | stable/queens |
> | import zuul job settings from project-config | openstack/heat-cfntools  
>  | master|
> | switch documentation job to new PTI  | openstack/heat-cfntools  
>  | master|
> | add python 3.6 unit test job | openstack/heat-cfntools  
>  | master|
> | import zuul job settings from project-config | openstack/heat-dashboard 
>  | master|
> | switch documentation job to new PTI  | openstack/heat-dashboard 
>  | master|
> | import zuul job settings from project-config | openstack/heat-dashboard 
>  | stable/queens |
> | import zuul job settings from project-config | openstack/heat-specs 
>  | master|
> | import zuul job settings from project-config | 
> openstack/heat-tempest-plugin | master|
> | fix tox python3 overrides| openstack/heat-templates 
>  | master|
> | import zuul job settings from project-config | openstack/heat-translator
>  | master|
> | switch documentation job to new PTI  | openstack/heat-translator
>  | master|
> | add python 3.6 unit test job | openstack/heat-translator
>  | master|
> | import zuul job settings from project-config | openstack/heat-translator
>  | stable/pike   |
> | import zuul job settings from project-config | openstack/heat-translator
>  | stable/queens |
> | import zuul job settings from project-config | openstack/heat-translator
>  | stable/rocky  |
> | import zuul job settings from project-config | openstack/python-heatclient  
>  | master|
> | switch documentation job to new PTI  | openstack/python-heatclient  
>  | master|
> | add python 3.6 unit test job | openstack/python-heatclient  
>  | master|
> | import zuul job settings from

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

Excerpts from Zane Bitter's message of 2018-08-28 16:47:06 -0400:
> On 27/08/18 15:37, Doug Hellmann wrote:
> > == 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.
> 
> Heat is ready. I already did master (and by extension stable/rocky) a 
> little while back in openstack/heat, but you should check that it's 
> correct :)
> 
> - ZB
> 

OK, I ran the scripts and generated a bunch of patches for all of
your repositories. You will want to review the ones on master
carefully if you have already done part of the work. Let me know
if you have questions about resolving any conflicts.

Doug

+--+---+---+
| Subject  | Repo  
| Branch|
+--+---+---+
| import zuul job settings from project-config | openstack-dev/heat-cfnclient  
| master|
| add python 3.6 unit test job | openstack-dev/heat-cfnclient  
| master|
| add python 3.6 unit test job | openstack-dev/heat-cfnclient  
| master|
| convert py35 jobs to py3 | openstack/heat
| master|
| import zuul job settings from project-config | openstack/heat
| master|
| switch documentation job to new PTI  | openstack/heat
| master|
| add python 3.6 unit test job | openstack/heat
| master|
| import zuul job settings from project-config | openstack/heat
| stable/ocata  |
| import zuul job settings from project-config | openstack/heat
| stable/pike   |
| import zuul job settings from project-config | openstack/heat
| stable/queens |
| import zuul job settings from project-config | openstack/heat
| stable/rocky  |
| import zuul job settings from project-config | openstack/heat-agents 
| master|
| switch documentation job to new PTI  | openstack/heat-agents 
| master|
| add python 3.6 unit test job | openstack/heat-agents 
| master|
| import zuul job settings from project-config | openstack/heat-agents 
| stable/ocata  |
| import zuul job settings from project-config | openstack/heat-agents 
| stable/pike   |
| import zuul job settings from project-config | openstack/heat-agents 
| stable/queens |
| import zuul job settings from project-config | openstack/heat-cfntools   
| master|
| switch documentation job to new PTI  | openstack/heat-cfntools   
| master|
| add python 3.6 unit test job | openstack/heat-cfntools   
| master|
| import zuul job settings from project-config | openstack/heat-dashboard  
| master|
| switch documentation job to new PTI  | openstack/heat-dashboard  
| master|
| import zuul job settings from project-config | openstack/heat-dashboard  
| stable/queens |
| import zuul job settings from project-config | openstack/heat-specs  
| master|
| import zuul job settings from project-config | openstack/heat-tempest-plugin 
| master|
| fix tox python3 overrides| openstack/heat-templates  
| master|
| import zuul job settings from project-config | openstack/heat-translator 
| master|
| switch documentation job to new PTI  | openstack/heat-translator 
| master|
| add python 3.6 unit test job | openstack/heat-translator 
| master|
| import zuul job settings from project-config | openstack/heat-translator 
| stable/pike   |
| import zuul job settings from project-config | openstack/heat-translator 
| stable/queens |
| import zuul job settings from project-config | openstack/heat-translator 
| stable/rocky  |
| import zuul job settings from project-config | openstack/python-heatclient   
| master|
| switch documentation job to new PTI  | openstack/python-heatclient   
| master|
| add python 3.6 unit test job | openstack/python-heatclient   
| master|
| import zuul job settings from project-config | openstack/python-heatclient   
| stable/ocata  |
| import zuul job settings from project-config | openstack/python-heatclient   
| stable/pike   |
| import zuul job settings from project-config | openstack/python-heatclient   
| stable/queens |
| import zuul job settings from project-config | openstack/python-heatclient   
| stable/rocky  |
| import zuul job settings from project-config | openstack/tosca-parser
| master|
| switch documentation

Re: [openstack-dev] [stable][nova] Nominating melwitt for nova stable core

2018-08-28 Thread Davanum Srinivas

+1 from me

On Tue, Aug 28, 2018 at 5:27 PM Sean McGinnis  wrote:

> On Tue, Aug 28, 2018 at 03:26:02PM -0500, Matt Riedemann wrote:
> > I hereby nominate Melanie Witt for nova stable core. Mel has shown that
> she
> > knows the stable branch policy and is also an active reviewer of nova
> stable
> > changes.
> >
> > +1/-1 comes from the stable-maint-core team [1] and then after a week
> with
> > no negative votes I think it's a done deal. Of course +1/-1 from existing
> > nova-stable-maint [2] is also good feedback.
> >
> > [1] https://review.openstack.org/#/admin/groups/530,members
> > [2] https://review.openstack.org/#/admin/groups/540,members
> >
>
> +1 from me.
>
> __
> 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
>


-- 
Davanum Srinivas :: https://twitter.com/dims
__
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] [stable][nova] Nominating melwitt for nova stable core

2018-08-28 Thread Sean McGinnis

On Tue, Aug 28, 2018 at 03:26:02PM -0500, Matt Riedemann wrote:
> I hereby nominate Melanie Witt for nova stable core. Mel has shown that she
> knows the stable branch policy and is also an active reviewer of nova stable
> changes.
> 
> +1/-1 comes from the stable-maint-core team [1] and then after a week with
> no negative votes I think it's a done deal. Of course +1/-1 from existing
> nova-stable-maint [2] is also good feedback.
> 
> [1] https://review.openstack.org/#/admin/groups/530,members
> [2] https://review.openstack.org/#/admin/groups/540,members
> 

+1 from me.

__
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] proposing metalsmith for inclusion into ironic governance

2018-08-28 Thread Fox, Kevin M

Might be a good option to plug in to the kubernetes cluster api 
https://github.com/kubernetes-sigs/cluster-api too.

Thanks,
Kevin

From: Mark Goddard [m...@stackhpc.com]
Sent: Tuesday, August 28, 2018 10:55 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [ironic] proposing metalsmith for inclusion into 
ironic governance

+1. I like it. Could also be a good fit for Kayobe's undercloud equivalent at 
some point.

On Tue, 28 Aug 2018 at 18:51, Jim Rollenhagen 
mailto:j...@jimrollenhagen.com>> wrote:
On Mon, Aug 27, 2018 at 12:09 PM, Dmitry Tantsur 
mailto:dtant...@redhat.com>> wrote:
Hi all,

I would like propose the metalsmith library [1][2] for inclusion into the bare 
metal project governance.

What it is and is not
-

Metalsmith is a library and CLI tool for using Ironic+Neutron for provisioning 
bare metal nodes. It can be seen as a lightweight replacement of Nova when Nova 
is too much. The primary use case is single-tenant standalone installer.

Metalsmith is not a new service, it does not maintain any state, except for 
state maintained by Ironic and Neutron. Metalsmith is not and will not be a 
replacement for Nova in any proper cloud scenario.

Metalsmith does have some overlap with Bifrost, with one important feature 
difference: its primary feature is a mini-scheduler that allows to pick a 
suitable bare metal node for deployment.

I have a partial convergence plan as well! First, as part of this effort I'm 
working on missing features in openstacksdk, which is used in the OpenStack 
ansible modules, which are used in Bifrost. Second, I hope we can use it as a 
helper for making Bifrost do scheduling decisions.

Background
--

Metalsmith was born with the goal of replacing Nova in TripleO undercloud. 
Indeed, the undercloud uses only a small subset of Nova features, while having 
features that conflict with Nova's design (for example, bypassing the scheduler 
[3]).

We wanted to avoid putting a lot of provisioning logic into existing TripleO 
components. So I wrote a library that does not carry any TripleO-specific 
assumptions, but does allow to address its needs.

Why under Ironic

I believe the goal of Metalsmith is fully aligned with what the Ironic team is 
doing around standalone deployment. I think Metalsmith can provide a nice entry 
point into standalone deployments for people who (for any reasons) will not use 
Bifrost. With this change I hope to get more exposure for it.

The library itself is small, documented [2], follows OpenStack practices and 
does not have particular operating requirements. There is nothing in it that is 
not familiar to the Ironic team members.

I agree with all of this, after reading the code/docs. +1 from me.

// jim

Please let me know if you have any questions or concerns.

Dmitry

[1] https://github.com/openstack/metalsmith
[2] https://metalsmith.readthedocs.io/en/latest/
[3] http://tripleo.org/install/advanced_deployment/node_placement.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 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] Denver PTG Team Dinner

2018-08-28 Thread Miguel Lavalle

Dear Neutron Team,

Our PTG Denver team dinner will take place on Thursday 7pm, at
https://www.famousdaves.com/Denver-Stapleton, 0.5 miles from the
Renaissance Hotel, which translates to an easy 10 minutes walk:
https://goo.gl/JZVg8D

I am holding a reservation under my name for 20 people. Please confirm your
attendance by adding a "Yes" to the line in the etherpad where you
registered your name: https://etherpad.openstack.org/p/neutron-stein-ptg

Looking forward to see you all there

Best regards

Miguel
__
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 3 update

2018-08-28 Thread Zane Bitter


On 27/08/18 15:37, Doug Hellmann wrote:

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


Heat is ready. I already did master (and by extension stable/rocky) a 
little while back in openstack/heat, but you should check that it's 
correct :)


- ZB

__
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] [stable][nova] Nominating melwitt for nova stable core

2018-08-28 Thread Matthew Treinish

On Tue, Aug 28, 2018 at 03:26:02PM -0500, Matt Riedemann wrote:
> I hereby nominate Melanie Witt for nova stable core. Mel has shown that she
> knows the stable branch policy and is also an active reviewer of nova stable
> changes.
> 
> +1/-1 comes from the stable-maint-core team [1] and then after a week with
> no negative votes I think it's a done deal. Of course +1/-1 from existing
> nova-stable-maint [2] is also good feedback.

+1 from me.

-Matt Treinish


> 
> [1] https://review.openstack.org/#/admin/groups/530,members
> [2] https://review.openstack.org/#/admin/groups/540,members
> 


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] [stable][nova] Nominating melwitt for nova stable core

I hereby nominate Melanie Witt for nova stable core. Mel has shown that 
she knows the stable branch policy and is also an active reviewer of 
nova stable changes.


+1/-1 comes from the stable-maint-core team [1] and then after a week 
with no negative votes I think it's a done deal. Of course +1/-1 from 
existing nova-stable-maint [2] is also good feedback.


[1] https://review.openstack.org/#/admin/groups/530,members
[2] https://review.openstack.org/#/admin/groups/540,members

--

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][tc][openstack-helm] On the problem of OSF copyright headers

2018-08-28 Thread MCEUEN, MATT

Sorry for the noise folks - the change was well-intentioned but uninformed!  We 
will revert the changes.

Thanks,
Matt

-Original Message-
From: Jeremy Stanley  
Sent: Tuesday, August 28, 2018 12:00 PM
To: openstack-dev@lists.openstack.org
Cc: MCEUEN, MATT 
Subject: [all][tc][openstack-helm] On the problem of OSF copyright headers

[Obligatory disclaimer: I am not a lawyer, this is not legal advice, and I am 
not representing the OpenStack Foundation in any legal capacity here.]

TL;DR: You should not be putting "Copyright OpenStack Foundation" on content in 
Git repositories, or anywhere else for that matter (unless you know that you 
are actually an employee of the OSF or otherwise performing work-for-hire 
activities at the behest of the OSF). The OpenStack Individual Contributor 
License Agreement (ICLA) does not require copyright assignment. The foundation 
does not want, nor does it even generally accept, copyright assignment from 
developers. Your copyrightable contributions are your own, or by proxy are the 
copyright of your employer if you have created them as a part of any 
work-for-hire arrangement (unless you've negotiated with your employer to 
retain copyright of your work).

This topic has been raised multiple times in the past. In the wake of a 
somewhat protracted thread on the legal-disc...@lists.openstack.org mailing 
list (it actually started out on the openstack-dev mailing list but was then 
redirected to a more appropriate venue) back in April, 2013, we attempted to 
record a summary in the wiki article we'd been maintaining regarding various 
frequently-asked legal questions:
https://wiki.openstack.org/wiki/LegalIssuesFAQ#OpenStack_Foundation_Copyright_Headers

In the intervening years, we've worked to make sure other important 
documentation moves out of the wiki and into more durable maintenance (mostly 
Git repositories under code review, rendered and published to a Web site). I 
propose that as this particular topic is germane to contributing to the 
development of OpenStack software, the OpenStack Technical Committee should 
publish a statement on the governance site similar in nature to or perhaps as 
an expansion of the https://governance.openstack.org/tc/reference/licensing.html
page where we detail copyright licensing expectations for official OpenStack 
project team deliverables. As I look back through that wiki article, I see a 
few other sections which may also be appropriate to cover on the governance 
site.

The reason I'm re-raising this age-old discussion is because change
https://review.openstack.org/596619 came to my attention a few minutes ago, in 
which some 400+ files within the openstack/openstack-helm repository were 
updated to assign copyright to "OpenStack Foundation" based on this discussion 
from an openstack-helm IRC meeting back in March (which seems to have involved 
no legal representative of the OSF):
http://eavesdrop.openstack.org/meetings/openstack_helm/2018/openstack_helm.2018-03-20-15.00.log.html#l-101

There are also a couple of similar changes under the same review topic for the 
openstack/openstack-helm-infra and openstack/openstack-helm-addons 
repositories, one of which I managed to -1 before it could be approved and 
merged. I don't recall any follow-up discussion on the 
legal-disc...@lists.openstack.org or even openstack-dev@lists.openstack.org 
mailing lists, which I would have expected for any change of this legal 
significance.

The point of this message is of course not to berate anyone, but to raise the 
example which seems to indicate that as a community we've apparently not done a 
great job of communicating the legal aspects of contributing to OpenStack. If 
there are no objections, I'll push up a proposed addition to the 
openstack/governance repository addressing this semi-frequent misconception and 
follow up with a link to the review. I'm also going to post to the 
legal-discuss ML so as to make the subscribers there aware of this thread.
--
Jeremy Stanley

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

Re: [openstack-dev] [nova] [placement] extraction (technical) update

2018-08-28 Thread Ed Leafe

On Aug 28, 2018, at 10:47 AM, Matt Riedemann  wrote:
> 
>> 1.1 Run the git filter-branch on a copy of nova
>> 1.1.1 Add missing files to the file list:
>>   1.1.1.1 .gitignore
>>   1.1.1.2 # ANYTHING ELSE?
> 
> Unless I were to actually run the git filter-branch tooling to see what is 
> excluded from the new repo, I can't really say what is missing at this time. 
> I assume it would be clear during review - which is why I'm asking that we do 
> this stuff in gerrit where we do reviews.

Since I have run this tool a few times, I can answer that.

The tool removes all files and their history from git, saving only those you 
explicitly ask to keep. Every commit involving those files is kept, along with 
any other files that were part of that commit. The end result is a much smaller 
directory tree, and a much smaller .git directory (513M -> 113M).

Because the history is *removed*, running `git diff @^` on the result will not 
show the many files deleted by the history filter. So if you were looking for a 
diff in gerrit that shows all those deletions, it won’t be there. You can do a 
regular linux diff of the filtered directory and a nova directory to get a list 
of what has been removed, but that can be somewhat messy. I just want to set 
expectations when reviewing the extracted code in gerrit.

-- 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][tc][openstack-helm] On the problem of OSF copyright headers

2018-08-28 Thread Jeremy Stanley

On 2018-08-28 10:11:18 -0700 (-0700), John Dickinson wrote:
[...]
> It would be *really* helpful to have a simple rule or pattern for
> each file's header. Something like "Copyright (c)  created>-present by contributors to this project".

I applaud and share your desire for a clear rule on such things.
Sadly, I have serious doubts it's possible to get one.

> As you mentioned, this issue comes up about every two years, and having
> contributors police (via code review) the appropriate headers for every
> commit is not a sustainable pattern. The only thing I'm sure about is that
> the existing copyright headers are not correct, but I have no idea what the
> correct header are.

The point was not really for reviewers (who can't necessarily know
whether or not a copyright claim is in any way legitimate), but
rather for authors (please don't assign copyright of your works to
the OSF).
-- 
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

[openstack-dev] [tc] [all] TC Report 18-35

HTML: https://anticdent.org/tc-report-18-35.html

I didn't do a TC report last week because we spent much of the time
discussing the issues surrounding extracting the placement
service from nova. I've been working on making that happen—because
that's been the intent from the start—for a couple of years now, so
tend to be fairly central to those discussions. It felt
inappropriate to use these reports as a bully pulpit and in any case
I was exhausted, so took a break.

However, the topic was still a factor in the recent week's
discussion so I guess we're stuck with it: leaving it out would be
odd given that it has occupied such a lot of TC attention _and_
these reports are expressly my subjective opinion.

Placement is in the last section, in case you're of a mind to skip
it.

# The Tech Vision

There's been a bit of discussion on the [Draft Technical
Vision](https://review.openstack.org/#/c/592205/). First,
[generally what it is trying to do and how do dependencies fit
in](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-22.log.html#t2018-08-22T09:20:12).
This eventually flowed into questioning how much [voice and
discretion](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-22.log.html#t2018-08-22T18:37:24)
individual contributors have with regard to OpenStack overall, as
opposed to merely doing what their employers say. There were
_widely_ divergent perspectives on this.

The truth is probably that everyone has a different experience on a
big spectrum.

# TC Elections and Campaigning

As
[announced](http://lists.openstack.org/pipermail/openstack-dev/2018-August/133893.html),
TC Election Season approaches. We had some discussion
[Friday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-24.log.html#t2018-08-24T13:23:35)
about making sure that the right skills were present in candidates
and that any events we held with regard to campaigning, perhaps at
the PTG, were not actively exclusionary.

# That Placement Thing

The links below are for historical reference, for people who want to
catch up. The current state of affairs and immediate plans are being
worked out in [this
thread](http://lists.openstack.org/pipermail/openstack-dev/2018-August/thread.html#133781),
based on a medium term plan of doing the technical work to create a
separate and working repo and then get that repo working happily
with nova, devstack, grenade and tempest. Technical consensus is
being reached, sometimes slowly, sometimes quickly, but discussion
is working and several people are participating. The questions about
governance are not yet firmly resolved, but the hope is that before
the end of the Stein cycle placement ought to be its own official
project.

In case you're curious about why the TC is involved in this topic at
all, there are two reasons: a) Eric asked for advice, b) it is
relevant to the TC's role as [ultimate appeals
board](https://governance.openstack.org/tc/reference/charter.html).

The torrid story goes something like this: While working on a PTG
planning etherpad for [extracting placement from
nova](https://etherpad.openstack.org/p/placement-extract-stein-copy),
there were some questions about the eventual disposition of
placement: a project within or beside nova. That resulted in a [huge
email
thread](http://lists.openstack.org/pipermail/openstack-dev/2018-August/thread.html#133445).

In the midst of that thread, the nova scheduler meeting raised the
question of [how do we
decide](http://eavesdrop.openstack.org/meetings/nova_scheduler/2018/nova_scheduler.2018-08-20-14.00.log.html#l-64)?
That got moved to the TC IRC channel and mutated from "how do we
decide" to many different topics and perspectives. Thus ensued several
hours of
[argument](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-20.log.html#t2018-08-20T15:27:57).
Followed by a
["wow"
reprise](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-21.log.html#t2018-08-21T08:10:01)
on Tuesday morning.

By Thursday a potential compromise was mooted in the [nova
meeting](http://eavesdrop.openstack.org/meetings/nova/2018/nova.2018-08-23-14.00.log.html#l-205).
However, in the intervening period, several people in the TC,
notably Doug and Thierry had expressed a desire to address some of
the underlying issues (those that caused so much argument Monday and
elsewhere) in a more concrete fashion. I wanted to be sure that
they had a chance to provide their input before the compromise deal
was sealed. The conversation was moved back to the TC IRC channel
asking for input. This led to yet more
[tension](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-08-23.log.html#t2018-08-23T14:48:55).
It's not yet clear if that is resolved.

All this must seem pretty ridiculous to observers. As is so often
the case in community interactions, the tensions that are playing
out are not directly tied to any

Re: [openstack-dev] [all][tc][openstack-helm] On the problem of OSF copyright headers

2018-08-28 Thread Andreas Jaeger

In this context, there's also the question of copyright headers for 
documentation files which we do not require - see

https://wiki.openstack.org/wiki/Documentation/Copyright

This came up recently with:

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

I'm happy to see a canonical place for this information,

Andreas
--
 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] [ironic] proposing metalsmith for inclusion into ironic governance

2018-08-28 Thread Mark Goddard

+1. I like it. Could also be a good fit for Kayobe's undercloud equivalent
at some point.

On Tue, 28 Aug 2018 at 18:51, Jim Rollenhagen 
wrote:

> On Mon, Aug 27, 2018 at 12:09 PM, Dmitry Tantsur 
> wrote:
>
>> Hi all,
>>
>> I would like propose the metalsmith library [1][2] for inclusion into the
>> bare metal project governance.
>>
>> What it is and is not
>> -
>>
>> Metalsmith is a library and CLI tool for using Ironic+Neutron for
>> provisioning bare metal nodes. It can be seen as a lightweight replacement
>> of Nova when Nova is too much. The primary use case is single-tenant
>> standalone installer.
>>
>> Metalsmith is not a new service, it does not maintain any state, except
>> for state maintained by Ironic and Neutron. Metalsmith is not and will not
>> be a replacement for Nova in any proper cloud scenario.
>>
>> Metalsmith does have some overlap with Bifrost, with one important
>> feature difference: its primary feature is a mini-scheduler that allows to
>> pick a suitable bare metal node for deployment.
>>
>> I have a partial convergence plan as well! First, as part of this effort
>> I'm working on missing features in openstacksdk, which is used in the
>> OpenStack ansible modules, which are used in Bifrost. Second, I hope we can
>> use it as a helper for making Bifrost do scheduling decisions.
>>
>> Background
>> --
>>
>> Metalsmith was born with the goal of replacing Nova in TripleO
>> undercloud. Indeed, the undercloud uses only a small subset of Nova
>> features, while having features that conflict with Nova's design (for
>> example, bypassing the scheduler [3]).
>>
>> We wanted to avoid putting a lot of provisioning logic into existing
>> TripleO components. So I wrote a library that does not carry any
>> TripleO-specific assumptions, but does allow to address its needs.
>>
>> Why under Ironic
>> 
>>
>> I believe the goal of Metalsmith is fully aligned with what the Ironic
>> team is doing around standalone deployment. I think Metalsmith can provide
>> a nice entry point into standalone deployments for people who (for any
>> reasons) will not use Bifrost. With this change I hope to get more exposure
>> for it.
>>
>> The library itself is small, documented [2], follows OpenStack practices
>> and does not have particular operating requirements. There is nothing in it
>> that is not familiar to the Ironic team members.
>>
>
> I agree with all of this, after reading the code/docs. +1 from me.
>
> // jim
>
>
>>
>> Please let me know if you have any questions or concerns.
>>
>> Dmitry
>>
>>
>> [1] https://github.com/openstack/metalsmith
>> [2] https://metalsmith.readthedocs.io/en/latest/
>> [3] http://tripleo.org/install/advanced_deployment/node_placement.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 Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] proposing metalsmith for inclusion into ironic governance

2018-08-28 Thread Jim Rollenhagen

On Mon, Aug 27, 2018 at 12:09 PM, Dmitry Tantsur 
wrote:

> Hi all,
>
> I would like propose the metalsmith library [1][2] for inclusion into the
> bare metal project governance.
>
> What it is and is not
> -
>
> Metalsmith is a library and CLI tool for using Ironic+Neutron for
> provisioning bare metal nodes. It can be seen as a lightweight replacement
> of Nova when Nova is too much. The primary use case is single-tenant
> standalone installer.
>
> Metalsmith is not a new service, it does not maintain any state, except
> for state maintained by Ironic and Neutron. Metalsmith is not and will not
> be a replacement for Nova in any proper cloud scenario.
>
> Metalsmith does have some overlap with Bifrost, with one important feature
> difference: its primary feature is a mini-scheduler that allows to pick a
> suitable bare metal node for deployment.
>
> I have a partial convergence plan as well! First, as part of this effort
> I'm working on missing features in openstacksdk, which is used in the
> OpenStack ansible modules, which are used in Bifrost. Second, I hope we can
> use it as a helper for making Bifrost do scheduling decisions.
>
> Background
> --
>
> Metalsmith was born with the goal of replacing Nova in TripleO undercloud.
> Indeed, the undercloud uses only a small subset of Nova features, while
> having features that conflict with Nova's design (for example, bypassing
> the scheduler [3]).
>
> We wanted to avoid putting a lot of provisioning logic into existing
> TripleO components. So I wrote a library that does not carry any
> TripleO-specific assumptions, but does allow to address its needs.
>
> Why under Ironic
> 
>
> I believe the goal of Metalsmith is fully aligned with what the Ironic
> team is doing around standalone deployment. I think Metalsmith can provide
> a nice entry point into standalone deployments for people who (for any
> reasons) will not use Bifrost. With this change I hope to get more exposure
> for it.
>
> The library itself is small, documented [2], follows OpenStack practices
> and does not have particular operating requirements. There is nothing in it
> that is not familiar to the Ironic team members.
>

I agree with all of this, after reading the code/docs. +1 from me.

// jim


>
> Please let me know if you have any questions or concerns.
>
> Dmitry
>
>
> [1] https://github.com/openstack/metalsmith
> [2] https://metalsmith.readthedocs.io/en/latest/
> [3] http://tripleo.org/install/advanced_deployment/node_placement.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 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][openstack-helm] On the problem of OSF copyright headers

Excerpts from Jeremy Stanley's message of 2018-08-28 16:59:56 +:
> [Obligatory disclaimer: I am not a lawyer, this is not legal advice,
> and I am not representing the OpenStack Foundation in any legal
> capacity here.]
> 
> TL;DR: You should not be putting "Copyright OpenStack Foundation" on
> content in Git repositories, or anywhere else for that matter
> (unless you know that you are actually an employee of the OSF or
> otherwise performing work-for-hire activities at the behest of the
> OSF). The OpenStack Individual Contributor License Agreement (ICLA)
> does not require copyright assignment. The foundation does not want,
> nor does it even generally accept, copyright assignment from
> developers. Your copyrightable contributions are your own, or by
> proxy are the copyright of your employer if you have created them as
> a part of any work-for-hire arrangement (unless you've negotiated
> with your employer to retain copyright of your work).
> 
> This topic has been raised multiple times in the past. In the wake
> of a somewhat protracted thread on the
> legal-disc...@lists.openstack.org mailing list (it actually started
> out on the openstack-dev mailing list but was then redirected to a
> more appropriate venue) back in April, 2013, we attempted to record
> a summary in the wiki article we'd been maintaining regarding
> various frequently-asked legal questions:
> https://wiki.openstack.org/wiki/LegalIssuesFAQ#OpenStack_Foundation_Copyright_Headers
> 
> In the intervening years, we've worked to make sure other important
> documentation moves out of the wiki and into more durable
> maintenance (mostly Git repositories under code review, rendered and
> published to a Web site). I propose that as this particular topic is
> germane to contributing to the development of OpenStack software,
> the OpenStack Technical Committee should publish a statement on the
> governance site similar in nature to or perhaps as an expansion of
> the https://governance.openstack.org/tc/reference/licensing.html
> page where we detail copyright licensing expectations for official
> OpenStack project team deliverables. As I look back through that
> wiki article, I see a few other sections which may also be
> appropriate to cover on the governance site.
> 
> The reason I'm re-raising this age-old discussion is because change
> https://review.openstack.org/596619 came to my attention a few
> minutes ago, in which some 400+ files within the
> openstack/openstack-helm repository were updated to assign copyright
> to "OpenStack Foundation" based on this discussion from an
> openstack-helm IRC meeting back in March (which seems to have
> involved no legal representative of the OSF):
> http://eavesdrop.openstack.org/meetings/openstack_helm/2018/openstack_helm.2018-03-20-15.00.log.html#l-101

It's also not OK to simply change the copyright assignment for
content written by someone else without their approval. That's why
we tend not to go back and update existing copyright assignments
in the source files anywhere, it's usually too hard to ensure we
have everyone's +1.

> 
> There are also a couple of similar changes under the same review
> topic for the openstack/openstack-helm-infra and
> openstack/openstack-helm-addons repositories, one of which I managed
> to -1 before it could be approved and merged. I don't recall any
> follow-up discussion on the legal-disc...@lists.openstack.org or
> even openstack-dev@lists.openstack.org mailing lists, which I would
> have expected for any change of this legal significance.
> 
> The point of this message is of course not to berate anyone, but to
> raise the example which seems to indicate that as a community we've
> apparently not done a great job of communicating the legal aspects
> of contributing to OpenStack. If there are no objections, I'll push
> up a proposed addition to the openstack/governance repository
> addressing this semi-frequent misconception and follow up with a
> link to the review. I'm also going to post to the legal-discuss ML
> so as to make the subscribers there aware of this thread.

Yes, please do propose that documentation update in the governance
repo.  I wonder if we should address this at all in the contributors'
guide, too? Perhaps just to link to the published governance docs.

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][tc][openstack-helm] On the problem of OSF copyright headers

2018-08-28 Thread John Dickinson




On 28 Aug 2018, at 9:59, Jeremy Stanley wrote:


[Obligatory disclaimer: I am not a lawyer, this is not legal advice,
and I am not representing the OpenStack Foundation in any legal
capacity here.]

TL;DR: You should not be putting "Copyright OpenStack Foundation" on
content in Git repositories, or anywhere else for that matter
(unless you know that you are actually an employee of the OSF or
otherwise performing work-for-hire activities at the behest of the
OSF). The OpenStack Individual Contributor License Agreement (ICLA)
does not require copyright assignment. The foundation does not want,
nor does it even generally accept, copyright assignment from
developers. Your copyrightable contributions are your own, or by
proxy are the copyright of your employer if you have created them as
a part of any work-for-hire arrangement (unless you've negotiated
with your employer to retain copyright of your work).

This topic has been raised multiple times in the past. In the wake
of a somewhat protracted thread on the
legal-disc...@lists.openstack.org mailing list (it actually started
out on the openstack-dev mailing list but was then redirected to a
more appropriate venue) back in April, 2013, we attempted to record
a summary in the wiki article we'd been maintaining regarding
various frequently-asked legal questions:
https://wiki.openstack.org/wiki/LegalIssuesFAQ#OpenStack_Foundation_Copyright_Headers

In the intervening years, we've worked to make sure other important
documentation moves out of the wiki and into more durable
maintenance (mostly Git repositories under code review, rendered and
published to a Web site). I propose that as this particular topic is
germane to contributing to the development of OpenStack software,
the OpenStack Technical Committee should publish a statement on the
governance site similar in nature to or perhaps as an expansion of
the https://governance.openstack.org/tc/reference/licensing.html
page where we detail copyright licensing expectations for official
OpenStack project team deliverables. As I look back through that
wiki article, I see a few other sections which may also be
appropriate to cover on the governance site.

The reason I'm re-raising this age-old discussion is because change
https://review.openstack.org/596619 came to my attention a few
minutes ago, in which some 400+ files within the
openstack/openstack-helm repository were updated to assign copyright
to "OpenStack Foundation" based on this discussion from an
openstack-helm IRC meeting back in March (which seems to have
involved no legal representative of the OSF):
http://eavesdrop.openstack.org/meetings/openstack_helm/2018/openstack_helm.2018-03-20-15.00.log.html#l-101

There are also a couple of similar changes under the same review
topic for the openstack/openstack-helm-infra and
openstack/openstack-helm-addons repositories, one of which I managed
to -1 before it could be approved and merged. I don't recall any
follow-up discussion on the legal-disc...@lists.openstack.org or
even openstack-dev@lists.openstack.org mailing lists, which I would
have expected for any change of this legal significance.

The point of this message is of course not to berate anyone, but to
raise the example which seems to indicate that as a community we've
apparently not done a great job of communicating the legal aspects
of contributing to OpenStack. If there are no objections, I'll push
up a proposed addition to the openstack/governance repository
addressing this semi-frequent misconception and follow up with a
link to the review. I'm also going to post to the legal-discuss ML
so as to make the subscribers there aware of this thread.
--
Jeremy Stanley


It would be *really* helpful to have a simple rule or pattern for each 
file's header. Something like "Copyright (c) created>-present by contributors to this project".


As you mentioned, this issue comes up about every two years, and having 
contributors police (via code review) the appropriate headers for every 
commit is not a sustainable pattern. The only thing I'm sure about is 
that the existing copyright headers are not correct, but I have no idea 
what the correct header are.


--John





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

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

[openstack-dev] [all][tc][openstack-helm] On the problem of OSF copyright headers

2018-08-28 Thread Jeremy Stanley

[Obligatory disclaimer: I am not a lawyer, this is not legal advice,
and I am not representing the OpenStack Foundation in any legal
capacity here.]

TL;DR: You should not be putting "Copyright OpenStack Foundation" on
content in Git repositories, or anywhere else for that matter
(unless you know that you are actually an employee of the OSF or
otherwise performing work-for-hire activities at the behest of the
OSF). The OpenStack Individual Contributor License Agreement (ICLA)
does not require copyright assignment. The foundation does not want,
nor does it even generally accept, copyright assignment from
developers. Your copyrightable contributions are your own, or by
proxy are the copyright of your employer if you have created them as
a part of any work-for-hire arrangement (unless you've negotiated
with your employer to retain copyright of your work).

This topic has been raised multiple times in the past. In the wake
of a somewhat protracted thread on the
legal-disc...@lists.openstack.org mailing list (it actually started
out on the openstack-dev mailing list but was then redirected to a
more appropriate venue) back in April, 2013, we attempted to record
a summary in the wiki article we'd been maintaining regarding
various frequently-asked legal questions:
https://wiki.openstack.org/wiki/LegalIssuesFAQ#OpenStack_Foundation_Copyright_Headers

In the intervening years, we've worked to make sure other important
documentation moves out of the wiki and into more durable
maintenance (mostly Git repositories under code review, rendered and
published to a Web site). I propose that as this particular topic is
germane to contributing to the development of OpenStack software,
the OpenStack Technical Committee should publish a statement on the
governance site similar in nature to or perhaps as an expansion of
the https://governance.openstack.org/tc/reference/licensing.html
page where we detail copyright licensing expectations for official
OpenStack project team deliverables. As I look back through that
wiki article, I see a few other sections which may also be
appropriate to cover on the governance site.

The reason I'm re-raising this age-old discussion is because change
https://review.openstack.org/596619 came to my attention a few
minutes ago, in which some 400+ files within the
openstack/openstack-helm repository were updated to assign copyright
to "OpenStack Foundation" based on this discussion from an
openstack-helm IRC meeting back in March (which seems to have
involved no legal representative of the OSF):
http://eavesdrop.openstack.org/meetings/openstack_helm/2018/openstack_helm.2018-03-20-15.00.log.html#l-101

There are also a couple of similar changes under the same review
topic for the openstack/openstack-helm-infra and
openstack/openstack-helm-addons repositories, one of which I managed
to -1 before it could be approved and merged. I don't recall any
follow-up discussion on the legal-disc...@lists.openstack.org or
even openstack-dev@lists.openstack.org mailing lists, which I would
have expected for any change of this legal significance.

The point of this message is of course not to berate anyone, but to
raise the example which seems to indicate that as a community we've
apparently not done a great job of communicating the legal aspects
of contributing to OpenStack. If there are no objections, I'll push
up a proposed addition to the openstack/governance repository
addressing this semi-frequent misconception and follow up with a
link to the review. I'm also going to post to the legal-discuss ML
so as to make the subscribers there aware of this thread.
-- 
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] [nova] [placement] extraction (technical) update

2018-08-28 Thread Dan Smith

> Grenade already has it's own "resources db" right? So we can shove
> things in there before we upgrade and then verify they are still there
> after the upgrade?

Yep, I'm working on something right now. We create an instance that
survives the upgrade and validate it on the other side. I'll just do
some basic inventory and allocation validation that we'll trip over if
we somehow don't migrate that data from nova to placement.

--Dan

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

Re: [openstack-dev] [nova] [placement] extraction (technical) update

On 8/28/2018 10:57 AM, Dan Smith wrote:

The from-rocky will also need to extract data from the nova-api database
for the placement tables and put it into the new placement database (as
real operators will have to do). It'll need to do this after the split
code has been installed and the schema has been sync'd. Without this,
the pre-upgrade resources won't have allocations known by the split
placement service. I do not think we should cheat by just pointing the
split placement at nova's database.

Yes excellent points.

Also, ISTR you added some allocation/inventory checking to devstack via
hook, maybe after the tempest job ran? We might want to add some stuff
to grenade to verify the pre/post resource allocations before we start
this move so we can make sure they're still good after we roll. I'll see
if I can hack something up to that effect.

It's in nova:

https://github.com/openstack/nova/blob/8b4fcdfdc6c59e024e7639e0d2da6ccbea5c73d3/gate/post_test_hook.sh#L55

And only run in the nova-next job:

https://github.com/openstack/nova/blob/8b4fcdfdc6c59e024e7639e0d2da6ccbea5c73d3/playbooks/legacy/nova-next/run.yaml#L62

Grenade already has it's own "resources db" right? So we can shove
things in there before we upgrade and then verify they are still there
after the upgrade? The post-tempest check I added to nova is looking for
orphaned allocations, meaning we successfully completed some operation,
like resize for example, but failed to cleanup after ourselves (which we
missed quite a bit of that in Pike).

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] [nova] [placement] XenServer CI failed frequently because of placement update

2018-08-28 Thread Bob Ball

> Yeah, the nova.CONF cpu_allocation_ratio is being overridden to 0.0:

The default there is 0.0[1] - and the passing tempest-full from Zuul on 
https://review.openstack.org/#/c/590041/ has the same line when reading the 
config[2]:

We'll have a dig to see if we can figure out why it's not defaulting to 16 in 
the ComputeNode.

Thanks!

Bob

[1] https://git.openstack.org/cgit/openstack/nova/tree/nova/conf/compute.py#n386
[2] 
http://logs.openstack.org/41/590041/17/check/tempest-full/b3f9ddd/controller/logs/screen-n-cpu.txt.gz#_Aug_27_14_18_24_078058
__
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] [nova] [placement] XenServer CI failed frequently because of placement update

2018-08-28 Thread Jay Pipes


Yeah, the nova.CONF cpu_allocation_ratio is being overridden to 0.0:

Aug 27 07:43:02.179927 dsvm-devstack-citrix-lon-nodepool-1379254 
nova-compute[21125]: DEBUG oslo_service.service [None 
req-4bb236c4-54c3-42b7-aa4e-e5c8b1ece0c7 None None] cpu_allocation_ratio 
  = 0.0 {{(pid=21125) log_opt_values 
/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py:3019}}


Best,
-jay

On 08/28/2018 10:01 AM, Bob Ball wrote:

We're not running with [1], however that did also fail the CI in the same way - 
see [2] for the full logs.

The first failing appeared to be around Aug 27 08:32:14:
Aug 27 08:32:14.502788 dsvm-devstack-citrix-lon-nodepool-1379254 
devstack@placement-api.service[13219]: DEBUG nova.api.openstack.placement.requestlog 
[req-94714f18-87f3-4ff5-9b17-f6e50131b3a9 req-fc47376d-cf04-4cd3-b69c-31ef4d5739a4 service 
placement] Starting request: 192.168.33.1 "GET 
/placement/allocation_candidates?limit=1000=MEMORY_MB%3A64%2CVCPU%3A1" 
{{(pid=13222) __call__ /opt/stack/new/nova/nova/api/openstack/placement/requestlog.py:38}}
Aug 27 08:32:14.583676 dsvm-devstack-citrix-lon-nodepool-1379254 
devstack@placement-api.service[13219]: DEBUG 
nova.api.openstack.placement.objects.resource_provider 
[req-94714f18-87f3-4ff5-9b17-f6e50131b3a9 
req-fc47376d-cf04-4cd3-b69c-31ef4d5739a4 service placement] found 0 providers 
with available 1 VCPU {{(pid=13222) _get_provider_ids_matching 
/opt/stack/new/nova/nova/api/openstack/placement/objects/resource_provider.py:2928}}

Just looking at Naichuan's output, I wonder if this is because allocation_ratio 
is registered as 0 in the inventory.

Bob

[2] 
http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/41/590041/17/check/dsvm-tempest-neutron-network/afadfe7/

-Original Message-
From: Eric Fried [mailto:openst...@fried.cc]
Sent: 28 August 2018 14:22
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [nova] [placement] XenServer CI failed frequently 
because of placement update

Naichuan-

Are you running with [1]? If you are, the placement logs (at debug
level) should be giving you some useful info. If you're not... perhaps you 
could pull that in :) Note that it refactors the _get_provider_ids_matching 
method completely, so it's possible your problem will magically go away when 
you do.

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

On 08/28/2018 07:54 AM, Jay Pipes wrote:

On 08/28/2018 04:17 AM, Naichuan Sun wrote:

Hi, experts,

XenServer CI failed frequently with an error "No valid host was found.
" for more than a week. I think it is cause by placement update.


Hi Naichuan,

Can you give us a link to the logs a patchset's Citrix XenServer CI
that has failed? Also, a timestamp for the failure you refer to would
be useful so we can correlate across service logs.

Thanks,
-jay

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


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
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] [nova] [placement] extraction (technical) update


On Tue, 28 Aug 2018, Matt Riedemann wrote:


Are people okay with that and willing to commit to being okay with
that answer in reviews? To some extent we need to have some faith on
the end result: the tests work. If people are not okay with that, we
need the people who are not to determine and prove the alternate
strategy. I've had this one work and work well.


Seems reasonable to me. But to be clear, if there are 70 failed tests, are 
you going to have 70 separate patches? Or this is just one of those things 
where you start with 70, fix something, get down to 50 failed tests, and 
iterate until you're down to all passing. If so, I'm OK with that. It's hard 
to say without knowing how many patches get from 70 failures to 0 and what 
the size/complexity of those changes is, but without knowing I'd default to 
the incremental approach for ease of review.


It's lumpy. But at least at the begining it will be something like:
0 passing, stil 0 passing; still 0 passing; still 0 passing; 150
passing, 700 failing; 295 passing, X failing, etc. Because in the
early stages, test discovery and listing doesn't work at all, for
quite a few different reasons. Based on the discussion here,
resolving those "different reasons" is things people want to see in
different commits.

One way to optimize this (if people preferred) would be to not use
stestr as called by tox, with its built in test discovery, but
instead run testtools or subunit in a non-parallel and failfast
where not all tests need to be discovered first. That would provide a
more visible sense of "it's getting better" to someone who is running
the tests locally using that alternate method, but would not do much
for the jobs run by zuul, so probably not all that useful.

Thanks for the other info on the devstack and grenade stuff. If I
read you right, from your perspective it's a case of "we'll see" and
"we'll figure it out", which sounds good to me.

--
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] [nova] [placement] extraction (technical) update

2018-08-28 Thread Dan Smith

> Grenade uses devstack so once we have devstack on master installing
> (and configuring) placement from the new repo and disable installing
> and configuring it from the nova repo, that's the majority of the
> change I'd think.
>
> Grenade will likely need a from-rocky script to move any config that
> is necessary, but as you already noted below, if the new repo can live
> with an existing nova.conf, then we might not need to do anything in
> grenade since placement from the new repo (in stein) could then run
> with nova.conf created for placement from the nova repo (in rocky).

The from-rocky will also need to extract data from the nova-api database
for the placement tables and put it into the new placement database (as
real operators will have to do). It'll need to do this after the split
code has been installed and the schema has been sync'd. Without this,
the pre-upgrade resources won't have allocations known by the split
placement service. I do not think we should cheat by just pointing the
split placement at nova's database.

Also, ISTR you added some allocation/inventory checking to devstack via
hook, maybe after the tempest job ran? We might want to add some stuff
to grenade to verify the pre/post resource allocations before we start
this move so we can make sure they're still good after we roll. I'll see
if I can hack something up to that effect.

--Dan

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

Re: [openstack-dev] [nova] [placement] extraction (technical) update

2018-08-28 Thread Mohammed Naser

Forgive me for barging into this, but just with my deployer and PTL of
a deployment project hat on..

As part of the split, wouldn't we *not* need to make a devstack change
if this is done correctly because placement will become a nova
dependency, which is pulled out of Git and when using Zuul, will test
the specific commit in question.  From devstack's POV, deploying the
way things are shouldn't change (except for when we decide to deploy
placement separately).. but I believe in the process, both should
technically work? (and if devstack breaks, then maybe we'll be
breaking downstream users?)

Thanks,
Mohammed
On Tue, Aug 28, 2018 at 11:47 AM Matt Riedemann  wrote:
>
> On 8/28/2018 6:20 AM, Chris Dent wrote:
> > On Mon, 27 Aug 2018, melanie witt wrote:
> >
> >> I think we should use the openstack review system (gerrit) for moving
> >> the code. We're moving a critical piece of nova to its own repo and I
> >> think it's worth having the review and history contained in the
> >> openstack review system.
> >
> > This seems a reasonable enough strategy, in broad strokes. I want to
> > be sure that we're all actually in agreement on the details, as
> > we've had a few false starts and I think some of the details are
> > getting confused in the shuffle and the general busy-ness in progress.
> >
> > Is anyone aware of anyone who hasn't commented yet that should? If
> > you are, please poke them so we don't surprise them.
> >
> >> Using smaller changes that make it easy to see import vs content
> >> changes might make review faster than fewer, larger changes.
> >
> > I _think_ we ought to be able to use the existing commits from the
> > runs-throughs-to-passing-tests already done, but if we use the
> > strategy described below it doesn't really matter: the TDD approach
> > (after fixing paths and test config) is pretty fast.
> >
> >> The most important bit of all of this is making sure we don't break
> >> anything in the process for operators and users consuming nova and
> >> placement, and ensure the upgrade path from rocky => stein is tested
> >> in grenade.
> >
> > This is one of the areas where pretty active support from all of
> > nova will be required: getting zuul, upgrade paths, and the like
> > clearly defined and executed.
> >
> >> The steps I think we should take are:
> >>
> >> 1. We copy the placement code into the openstack/placement repo and
> >> have it passing all of its own unit and functional tests.
> >
> > To break that down to more detail, how does this look?
> > (note the ALL CAPS where more than acknowledgement is requested)
> >
> > 1.1 Run the git filter-branch on a copy of nova
> >  1.1.1 Add missing files to the file list:
> >1.1.1.1 .gitignore
> >1.1.1.2 # ANYTHING ELSE?
>
> Unless I were to actually run the git filter-branch tooling to see what
> is excluded from the new repo, I can't really say what is missing at
> this time. I assume it would be clear during review - which is why I'm
> asking that we do this stuff in gerrit where we do reviews.
>
> > 1.2 Push -f that thing, acknowledge to be broken, to a seed repo on github
> >  (ed's repo should be fine)
> > 1.3 Do the repo creation bits described in
> >  https://docs.openstack.org/infra/manual/creators.html
> >  to seed openstack/placement
> >  1.3.1 set zuul jobs. Either to noop-jobs, or non voting basic
> >  func and unit # INPUT DESIRED HERE
>
> Agree. As I said to gibi elsewhere in this thread, I would hold off on
> adding a tempest-full job to the repo until we're at the end.
>
> > 1.4 Once the repo exists with some content, incrementally bring it to
> >  working
> >  1.4.1 Update tox.ini to be placement oriented
> >  1.4.2 Update setup.cfg to be placement oriented
> >  1.4.3 Correct .stesr.conf
> >  1.4.4 Move base of placement to "right" place
> >  1.4.5 Move unit and functionals to right place
> >  1.4.6 Do automated path fixings
> >  1.4.7 Set up translation domain and i18n.py corectly
> >  1.4.8 Trim placement/conf to just the conf settings required
> >(api, base, database, keystone, paths, placement)
> >  1.4.9 Remove database files that are not relevant (the db api is
> >not used by placement)
> >  1.4.10 Fix the Database Fixture to be just one database
> >  1.4.11 Disable migrations that can't work (because of
> > dependencies on nova code, 014 and 030 are examples)
> > # INPUT DESIRED HERE AND ON SCHEMA MIGRATIONS IN GENERAL
> >  1.4.12 Incrementally get tests working
> >  1.4.13 Fix pep8
> > 1.5 Make zuul pep, unit and functional voting
> > 1.6 Create tools for db table sync/create
> > 1.7 Concurrently go to step 2, where the harder magic happens.
> > 1.8 Find and remove dead code (there will be some).
> > 1.9 Tune up and confirm docs
> > 1.10 Grep for remaining "nova" (as string and spirit) and fix
> >
> >
> > Item 1.4.12 may deserve some discussion. When I've done

Re: [openstack-dev] [nova] [placement] extraction (technical) update


On 8/28/2018 6:20 AM, Chris Dent wrote:

On Mon, 27 Aug 2018, melanie witt wrote:

I think we should use the openstack review system (gerrit) for moving 
the code. We're moving a critical piece of nova to its own repo and I 
think it's worth having the review and history contained in the 
openstack review system.


This seems a reasonable enough strategy, in broad strokes. I want to
be sure that we're all actually in agreement on the details, as
we've had a few false starts and I think some of the details are
getting confused in the shuffle and the general busy-ness in progress.

Is anyone aware of anyone who hasn't commented yet that should? If
you are, please poke them so we don't surprise them.

Using smaller changes that make it easy to see import vs content 
changes might make review faster than fewer, larger changes.


I _think_ we ought to be able to use the existing commits from the
runs-throughs-to-passing-tests already done, but if we use the
strategy described below it doesn't really matter: the TDD approach
(after fixing paths and test config) is pretty fast.

The most important bit of all of this is making sure we don't break 
anything in the process for operators and users consuming nova and 
placement, and ensure the upgrade path from rocky => stein is tested 
in grenade.


This is one of the areas where pretty active support from all of
nova will be required: getting zuul, upgrade paths, and the like
clearly defined and executed.


The steps I think we should take are:

1. We copy the placement code into the openstack/placement repo and 
have it passing all of its own unit and functional tests.


To break that down to more detail, how does this look?
(note the ALL CAPS where more than acknowledgement is requested)

1.1 Run the git filter-branch on a copy of nova
     1.1.1 Add missing files to the file list:
   1.1.1.1 .gitignore
   1.1.1.2 # ANYTHING ELSE?


Unless I were to actually run the git filter-branch tooling to see what 
is excluded from the new repo, I can't really say what is missing at 
this time. I assume it would be clear during review - which is why I'm 
asking that we do this stuff in gerrit where we do reviews.



1.2 Push -f that thing, acknowledge to be broken, to a seed repo on github
     (ed's repo should be fine)
1.3 Do the repo creation bits described in
     https://docs.openstack.org/infra/manual/creators.html
     to seed openstack/placement
     1.3.1 set zuul jobs. Either to noop-jobs, or non voting basic
     func and unit # INPUT DESIRED HERE


Agree. As I said to gibi elsewhere in this thread, I would hold off on 
adding a tempest-full job to the repo until we're at the end.



1.4 Once the repo exists with some content, incrementally bring it to
     working
     1.4.1 Update tox.ini to be placement oriented
     1.4.2 Update setup.cfg to be placement oriented
     1.4.3 Correct .stesr.conf
     1.4.4 Move base of placement to "right" place
     1.4.5 Move unit and functionals to right place
     1.4.6 Do automated path fixings
     1.4.7 Set up translation domain and i18n.py corectly
     1.4.8 Trim placement/conf to just the conf settings required
   (api, base, database, keystone, paths, placement)
     1.4.9 Remove database files that are not relevant (the db api is
   not used by placement)
     1.4.10 Fix the Database Fixture to be just one database
     1.4.11 Disable migrations that can't work (because of
    dependencies on nova code, 014 and 030 are examples)
    # INPUT DESIRED HERE AND ON SCHEMA MIGRATIONS IN GENERAL
     1.4.12 Incrementally get tests working
     1.4.13 Fix pep8
1.5 Make zuul pep, unit and functional voting
1.6 Create tools for db table sync/create
1.7 Concurrently go to step 2, where the harder magic happens.
1.8 Find and remove dead code (there will be some).
1.9 Tune up and confirm docs
1.10 Grep for remaining "nova" (as string and spirit) and fix


Item 1.4.12 may deserve some discussion. When I've done this the
several times before, the strategy I've used is to be test driven:
run either functional or unit tests, find and fix one of the errors
revealed, commit, move on.

This strategy has worked very well for me because of the "test
driven" part, but I'm hesitant to do it if reviewers are going to
get to a patch and say "why didn't you also change X?" The answer to
that question is "because this is incremental and test driven and
the tests didn't demand that change (yet)". Sometimes that will mean
that things of the same class of change are in different commits.

Are people okay with that and willing to commit to being okay with
that answer in reviews? To some extent we need to have some faith on
the end result: the tests work. If people are not okay with that, we
need the people who are not to determine and prove the alternate
strategy. I've had this one work and work well.


Seems reasonable to me. But to be clear, if there are 70 failed tests, 
are you going to have 70

Re: [openstack-dev] [nova] [placement] extraction (technical) update


On 8/28/2018 8:11 AM, Balázs Gibizer wrote:
I also think that we can add a non-voting tempest full job as well. 
Making it green depends on how hard to deploy placement from the new 
repo to tempest. I think as soon as placement repo has passing gabbits 
(e.g functional job) and we can deploy placement in tempest then tempest 
will be green soon.


There is likely no point in this until devstack itself is installing and 
using placement from the new repo rather than from nova. Because 
otherwise this job will be using devstack which still installs placement 
from nova and the job will pass but not actually test anything on the 
placement change in question. Even if it did run on the placement change 
from the placement repo, the job will be a time sink known failure until 
we get to the end of the series. It's at the end of the series where we 
declare that placement in the new repo is ready to go and passing all of 
it's own unit/functional tests that I think we add in the tempest-full 
job with a dependency on a devstack change which flips from which repo 
we install.


--

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] [nova] [placement] XenServer CI failed frequently because of placement update


On 8/28/2018 9:07 AM, Chris Dent wrote:

On Tue, 28 Aug 2018, Bob Ball wrote:

Just looking at Naichuan's output, I wonder if this is because 
allocation_ratio is registered as 0 in the inventory.


Yes.

Whatever happened to cause that is the root, that will throw the
math off into zeroness in lots of different places. The default (if
you don't send and allocation_ratio) is 1.0, so maybe there's some
code somewhere that is trying to use the default (by not sending)
but is accidentally sending 0 instead?


If cpu_allocation_ratio isn't in nova.conf, which it's not in this CI 
run, then it should default to 16.0 via the ComputeNode object code:


https://github.com/openstack/nova/blob/6bf864df771edb8c0d0af8a868dde21e3d12481e/nova/objects/compute_node.py#L201

Which is used to set the allocation ratio on the VCPUs inventory here:

https://github.com/openstack/nova/blob/6bf864df771edb8c0d0af8a868dde21e3d12481e/nova/compute/resource_tracker.py#L106

Nothing has changed here recently as far as I know.

--

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] [nova][searchlight][designate][telemetry][mistral][blazar][watcher][masakari]Possible deprecation of Nova's legacy notification interface

Hi gibi,

Thanks for the information. The Searchlight team would love to migrate to
the new version of Nova notification. I apology for this late response
since I just take over the project after your first email sent.

We will discuss this at the next team meeting and figure out the plan.

Bests,

*Trinh Nguyen *| Founder & Chief Architect



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



On Tue, Aug 28, 2018 at 11:31 PM Balázs Gibizer 
wrote:

> Thanks for all the responses. I collected them on the nova ptg
> discussion etherpad [1] (L186 at the moment). The nova team will talk
> about deprecation of the legacy interface on Friday on the PTG. If you
> want participate in the discussion but you are not planning to sit in
> the nova room whole day then let me know and I will try to ping you
> over IRC when we about to start the item.
>
> Cheers,
> gibi
>
> [1] https://etherpad.openstack.org/p/nova-ptg-stein
>
> On Thu, Aug 9, 2018 at 11:41 AM, Balázs Gibizer
>  wrote:
> > Dear Nova notification consumers!
> >
> >
> > The Nova team made progress with the new versioned notification
> > interface [1] and it is almost reached feature parity [2] with the
> > legacy, unversioned one. So Nova team will discuss on the upcoming
> > PTG the deprecation of the legacy interface. There is a list of
> > projects (we know of) consuming the legacy interface and we would
> > like to know if any of these projects plan to switch over to the new
> > interface in the foreseeable future so we can make a well informed
> > decision about the deprecation.
> >
> >
> > * Searchlight [3] - it is in maintenance mode so I guess the answer
> > is no
> > * Designate [4]
> > * Telemetry [5]
> > * Mistral [6]
> > * Blazar [7]
> > * Watcher [8] - it seems Watcher uses both legacy and versioned nova
> > notifications
> > * Masakari - I'm not sure Masakari depends on nova notifications or
> > not
> >
> > Cheers,
> > gibi
> >
> > [1]
> > https://docs.openstack.org/nova/latest/reference/notifications.html
> > [2] http://burndown.peermore.com/nova-notification/
> >
> > [3]
> >
> https://github.com/openstack/searchlight/blob/master/searchlight/elasticsearch/plugins/nova/notification_handler.py
> > [4]
> >
> https://github.com/openstack/designate/blob/master/designate/notification_handler/nova.py
> > [5]
> >
> https://github.com/openstack/ceilometer/blob/master/ceilometer/pipeline/data/event_definitions.yaml#L2
> > [6]
> >
> https://github.com/openstack/mistral/blob/master/etc/event_definitions.yml.sample#L2
> > [7]
> >
> https://github.com/openstack/blazar/blob/5526ed1f9b74d23b5881a5f73b70776ba9732da4/doc/source/user/compute-host-monitor.rst
> > [8]
> >
> https://github.com/openstack/watcher/blob/master/watcher/decision_engine/model/notification/nova.py#L335
> >
> >
>
>
> __
> 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] [oslo] No meeting next two weeks

2018-08-28 Thread Ben Nemec

Next week is a US holiday so a lot of the team will be off, and the week 
after is the PTG.  If you have anything to discuss in the meantime feel 
free to contact us in #openstack-oslo or here on the list.


-Ben

__
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] [nova][searchlight][designate][telemetry][mistral][blazar][watcher][masakari]Possible deprecation of Nova's legacy notification interface

Thanks for all the responses. I collected them on the nova ptg 
discussion etherpad [1] (L186 at the moment). The nova team will talk 
about deprecation of the legacy interface on Friday on the PTG. If you 
want participate in the discussion but you are not planning to sit in 
the nova room whole day then let me know and I will try to ping you 
over IRC when we about to start the item.


Cheers,
gibi

[1] https://etherpad.openstack.org/p/nova-ptg-stein

On Thu, Aug 9, 2018 at 11:41 AM, Balázs Gibizer 
 wrote:

Dear Nova notification consumers!


The Nova team made progress with the new versioned notification 
interface [1] and it is almost reached feature parity [2] with the 
legacy, unversioned one. So Nova team will discuss on the upcoming 
PTG the deprecation of the legacy interface. There is a list of 
projects (we know of) consuming the legacy interface and we would 
like to know if any of these projects plan to switch over to the new 
interface in the foreseeable future so we can make a well informed 
decision about the deprecation.



* Searchlight [3] - it is in maintenance mode so I guess the answer 
is no

* Designate [4]
* Telemetry [5]
* Mistral [6]
* Blazar [7]
* Watcher [8] - it seems Watcher uses both legacy and versioned nova 
notifications
* Masakari - I'm not sure Masakari depends on nova notifications or 
not


Cheers,
gibi

[1] 
https://docs.openstack.org/nova/latest/reference/notifications.html

[2] http://burndown.peermore.com/nova-notification/

[3] 
https://github.com/openstack/searchlight/blob/master/searchlight/elasticsearch/plugins/nova/notification_handler.py
[4] 
https://github.com/openstack/designate/blob/master/designate/notification_handler/nova.py
[5] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/pipeline/data/event_definitions.yaml#L2
[6] 
https://github.com/openstack/mistral/blob/master/etc/event_definitions.yml.sample#L2
[7] 
https://github.com/openstack/blazar/blob/5526ed1f9b74d23b5881a5f73b70776ba9732da4/doc/source/user/compute-host-monitor.rst
[8] 
https://github.com/openstack/watcher/blob/master/watcher/decision_engine/model/notification/nova.py#L335






__
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] [nova][cinder][neutron] Cross-cell cold migration


On 8/27/2018 1:53 PM, Matt Riedemann wrote:

On 8/27/2018 12:11 PM, Miguel Lavalle wrote:
Isn't multiple port binding what we need in the case of ports? In my 
mind, the big motivator for multiple port binding is the ability to 
change a port's backend


Hmm, yes maybe. Nova's usage of multiple port bindings today is 
restricted to live migration which isn't what we're supporting with the 
initial cross-cell (cold) migration support, but it could be a 
dependency if that's what we need.


What I was wondering is if there is a concept like a port spanning or 
migrating across networks? I'm assuming there isn't, and I'm not even 
sure if that would be required here. But it would mean there is an 
implicit requirement that for cross-cell migration to work, neutron 
networks need to span cells (similarly storage backends would need to 
span cells).


In thinking about this again (sleepless at 3am of course), port bindings 
doesn't help us here if we're orchestrating the cross-cell move using 
shelve offload, because in that case the port is unbound from the source 
host - while the instance is shelved offloaded, it has no host. When we 
unshelve in the new cell, we'd update the port binding. So there isn't 
really a use in this flow for multiple port bindings on multiple hosts 
(assuming we stick with using the shelve/unshelve idea here).


--

Thanks,

Matt

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

[openstack-dev] [nova]Notification subteam meeting cancelled


Hi,

There won't be notification subteam meeting this week.

Cheers,
gibi




__
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] [nova] [placement] XenServer CI failed frequently because of placement update


On Tue, 28 Aug 2018, Bob Ball wrote:


Just looking at Naichuan's output, I wonder if this is because allocation_ratio 
is registered as 0 in the inventory.


Yes.

Whatever happened to cause that is the root, that will throw the
math off into zeroness in lots of different places. The default (if
you don't send and allocation_ratio) is 1.0, so maybe there's some
code somewhere that is trying to use the default (by not sending)
but is accidentally sending 0 instead?

--
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] [nova] [placement] XenServer CI failed frequently because of placement update

2018-08-28 Thread Bob Ball

We're not running with [1], however that did also fail the CI in the same way - 
see [2] for the full logs.

The first failing appeared to be around Aug 27 08:32:14:
Aug 27 08:32:14.502788 dsvm-devstack-citrix-lon-nodepool-1379254 
devstack@placement-api.service[13219]: DEBUG 
nova.api.openstack.placement.requestlog 
[req-94714f18-87f3-4ff5-9b17-f6e50131b3a9 
req-fc47376d-cf04-4cd3-b69c-31ef4d5739a4 service placement] Starting request: 
192.168.33.1 "GET 
/placement/allocation_candidates?limit=1000=MEMORY_MB%3A64%2CVCPU%3A1"
 {{(pid=13222) __call__ 
/opt/stack/new/nova/nova/api/openstack/placement/requestlog.py:38}}
Aug 27 08:32:14.583676 dsvm-devstack-citrix-lon-nodepool-1379254 
devstack@placement-api.service[13219]: DEBUG 
nova.api.openstack.placement.objects.resource_provider 
[req-94714f18-87f3-4ff5-9b17-f6e50131b3a9 
req-fc47376d-cf04-4cd3-b69c-31ef4d5739a4 service placement] found 0 providers 
with available 1 VCPU {{(pid=13222) _get_provider_ids_matching 
/opt/stack/new/nova/nova/api/openstack/placement/objects/resource_provider.py:2928}}

Just looking at Naichuan's output, I wonder if this is because allocation_ratio 
is registered as 0 in the inventory.

Bob

[2] 
http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/41/590041/17/check/dsvm-tempest-neutron-network/afadfe7/

-Original Message-
From: Eric Fried [mailto:openst...@fried.cc] 
Sent: 28 August 2018 14:22
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [nova] [placement] XenServer CI failed frequently 
because of placement update

Naichuan-

Are you running with [1]? If you are, the placement logs (at debug
level) should be giving you some useful info. If you're not... perhaps you 
could pull that in :) Note that it refactors the _get_provider_ids_matching 
method completely, so it's possible your problem will magically go away when 
you do.

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

On 08/28/2018 07:54 AM, Jay Pipes wrote:
> On 08/28/2018 04:17 AM, Naichuan Sun wrote:
>> Hi, experts,
>>
>> XenServer CI failed frequently with an error "No valid host was found.
>> " for more than a week. I think it is cause by placement update.
> 
> Hi Naichuan,
> 
> Can you give us a link to the logs a patchset's Citrix XenServer CI 
> that has failed? Also, a timestamp for the failure you refer to would 
> be useful so we can correlate across service logs.
> 
> Thanks,
> -jay
> 
> __
>  OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
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] [nova] [placement] extraction (technical) update

2018-08-28 Thread Dan Smith

>> 2. We have a stack of changes to zuul jobs that show nova working but 
>> deploying placement in devstack from the new repo instead of nova's 
>> repo. This includes the grenade job, ensuring that upgrade works.
>
> I'm guessing there would need to be changes to Devstack itself, outside
> of the zuul jobs?

I think we'll need changes to devstack itself, as well as grenade, as
well as zuul jobs I'd assume.

Otherwise, this sequence of steps is what I've been anticipating.

--Dan

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

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

2018-08-28 Thread Michel Peterson

On Mon, Aug 27, 2018 at 10:37 PM, Doug Hellmann 
wrote:

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

The networking-odl team is willing to volunteer for this.
__
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] [nova] [placement] XenServer CI failed frequently because of placement update

2018-08-28 Thread Eric Fried

Naichuan-

Are you running with [1]? If you are, the placement logs (at debug
level) should be giving you some useful info. If you're not... perhaps
you could pull that in :) Note that it refactors the
_get_provider_ids_matching method completely, so it's possible your
problem will magically go away when you do.

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

On 08/28/2018 07:54 AM, Jay Pipes wrote:
> On 08/28/2018 04:17 AM, Naichuan Sun wrote:
>> Hi, experts,
>>
>> XenServer CI failed frequently with an error "No valid host was found.
>> " for more than a week. I think it is cause by placement update.
> 
> Hi Naichuan,
> 
> Can you give us a link to the logs a patchset's Citrix XenServer CI that
> has failed? Also, a timestamp for the failure you refer to would be
> useful so we can correlate across service logs.
> 
> Thanks,
> -jay
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [nova] [placement] extraction (technical) update




On Tue, Aug 28, 2018 at 1:20 PM, Chris Dent  
wrote:

On Mon, 27 Aug 2018, melanie witt wrote:

I think we should use the openstack review system (gerrit) for 
moving the code. We're moving a critical piece of nova to its own 
repo and I think it's worth having the review and history contained 
in the openstack review system.


This seems a reasonable enough strategy, in broad strokes. I want to
be sure that we're all actually in agreement on the details, as
we've had a few false starts and I think some of the details are
getting confused in the shuffle and the general busy-ness in progress.

Is anyone aware of anyone who hasn't commented yet that should? If
you are, please poke them so we don't surprise them.

Using smaller changes that make it easy to see import vs content 
changes might make review faster than fewer, larger changes.


I _think_ we ought to be able to use the existing commits from the
runs-throughs-to-passing-tests already done, but if we use the
strategy described below it doesn't really matter: the TDD approach
(after fixing paths and test config) is pretty fast.

The most important bit of all of this is making sure we don't break 
anything in the process for operators and users consuming nova and 
placement, and ensure the upgrade path from rocky => stein is 
tested in grenade.


This is one of the areas where pretty active support from all of
nova will be required: getting zuul, upgrade paths, and the like
clearly defined and executed.


The steps I think we should take are:

1. We copy the placement code into the openstack/placement repo and 
have it passing all of its own unit and functional tests.


To break that down to more detail, how does this look?
(note the ALL CAPS where more than acknowledgement is requested)

1.1 Run the git filter-branch on a copy of nova
1.1.1 Add missing files to the file list:
  1.1.1.1 .gitignore
  1.1.1.2 # ANYTHING ELSE?
1.2 Push -f that thing, acknowledge to be broken, to a seed repo on 
github

(ed's repo should be fine)
1.3 Do the repo creation bits described in
https://docs.openstack.org/infra/manual/creators.html
to seed openstack/placement
1.3.1 set zuul jobs. Either to noop-jobs, or non voting basic
func and unit # INPUT DESIRED HERE


I suggest to add a non-voting unit and functional job and iterate on 
the repo to make them green, then turn them to voting.
I also think that we can add a non-voting tempest full job as well. 
Making it green depends on how hard to deploy placement from the new 
repo to tempest. I think as soon as placement repo has passing gabbits 
(e.g functional job) and we can deploy placement in tempest then 
tempest will be green soon.



1.4 Once the repo exists with some content, incrementally bring it to
working
1.4.1 Update tox.ini to be placement oriented
1.4.2 Update setup.cfg to be placement oriented
1.4.3 Correct .stesr.conf
1.4.4 Move base of placement to "right" place
1.4.5 Move unit and functionals to right place
1.4.6 Do automated path fixings
1.4.7 Set up translation domain and i18n.py corectly
1.4.8 Trim placement/conf to just the conf settings required
  (api, base, database, keystone, paths, placement)
1.4.9 Remove database files that are not relevant (the db api is
  not used by placement)
1.4.10 Fix the Database Fixture to be just one database
1.4.11 Disable migrations that can't work (because of
   dependencies on nova code, 014 and 030 are examples)
   # INPUT DESIRED HERE AND ON SCHEMA MIGRATIONS IN GENERAL
1.4.12 Incrementally get tests working
1.4.13 Fix pep8
1.5 Make zuul pep, unit and functional voting
1.6 Create tools for db table sync/create
1.7 Concurrently go to step 2, where the harder magic happens.
1.8 Find and remove dead code (there will be some).
1.9 Tune up and confirm docs
1.10 Grep for remaining "nova" (as string and spirit) and fix


Item 1.4.12 may deserve some discussion. When I've done this the
several times before, the strategy I've used is to be test driven:
run either functional or unit tests, find and fix one of the errors
revealed, commit, move on.

This strategy has worked very well for me because of the "test
driven" part, but I'm hesitant to do it if reviewers are going to
get to a patch and say "why didn't you also change X?" The answer to
that question is "because this is incremental and test driven and
the tests didn't demand that change (yet)". Sometimes that will mean
that things of the same class of change are in different commits.

Are people okay with that and willing to commit to being okay with
that answer in reviews? To some extent we need to have some faith on
the end result: the tests work. If people are not okay with that, we
need the people who are not to determine and prove the alternate
strategy. I've had this one work and work well.


I like this test driven approach. If I start to leave comments like 
"why didn't you

Re: [openstack-dev] [Freezer] Reactivate the team

Hi Saad,

That is the time to migrate Freezer to Storyboard, not the meeting time. :)

Bests,


*Trinh Nguyen *| Founder & Chief Architect



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



On Tue, Aug 28, 2018 at 8:48 PM Saad Zaher  wrote:

> Hello Kendall,
>
> Can we get the old meeting slot which is Thursday @ 14:00 UTC  if this is
> Ok with everyone ?
>
> Thanks,
> Saad!
>
> On Mon, Aug 27, 2018 at 11:46 PM Kendall Nelson 
> wrote:
>
>> Hello,
>>
>> Here is the change that adds Freezer to StoryBoard[1]. If we can get the
>> PTL's +1, we can move forward with the migration. Does Friday work for you
>> all?
>>
>> -Kendall (diablo_rojo)
>>
>> [1] https://review.openstack.org/#/c/596918/
>>
>> On Sun, Aug 26, 2018 at 7:59 PM Trinh Nguyen 
>> wrote:
>>
>>> @Kendall: please help the Freezer team. Thanks.
>>>
>>> @gengchc2: I think you should send an email to TC and ask for help. The
>>> Freezer core seems to inactive.
>>>
>>>
>>> *Trinh Nguyen *| Founder & Chief Architect
>>>
>>> 
>>>
>>> *E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz
>>> *
>>>
>>>
>>>
>>> On Mon, Aug 27, 2018 at 11:26 AM  wrote:
>>>
 Hi,Kendall:

 I agree to migrate freezer project from Launchpad to Storyboard, Thanks.

 By the way, When will grant privileges for gengchc2 on Launchpad and
 Project Gerrit repositories?



 Best regards,

 gengchc2






 __
 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
>>
>
>
> --
> --
> Best Regards,
> Saad!
>
__
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] [nova] [placement] XenServer CI failed frequently because of placement update

2018-08-28 Thread Jay Pipes


On 08/28/2018 04:17 AM, Naichuan Sun wrote:

Hi, experts,

XenServer CI failed frequently with an error "No valid host was found. " 
for more than a week. I think it is cause by placement update.


Hi Naichuan,

Can you give us a link to the logs a patchset's Citrix XenServer CI that 
has failed? Also, a timestamp for the failure you refer to would be 
useful so we can correlate across service logs.


Thanks,
-jay

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

[openstack-dev] [tripleo] PTG topics and agenda

2018-08-28 Thread Juan Antonio Osorio Robles

Hello folks!


With the PTG being quite soon, I just wanted to remind folks to add your
topics on the etherpad: https://etherpad.openstack.org/p/tripleo-ptg-stein

Also, please vote for the topics you're the most interested in, so we
can add them to the agenda. I'll submit a potential agenda by the end of
the week.


Best 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] [nova] [placement] extraction (technical) update




On Mon, Aug 27, 2018 at 5:31 PM, Matt Riedemann  
wrote:

On 8/24/2018 7:36 AM, Chris Dent wrote:


Over the past few days a few of us have been experimenting with
extracting placement to its own repo, as has been discussed at
length on this list, and in some etherpads:

https://etherpad.openstack.org/p/placement-extract-stein
https://etherpad.openstack.org/p/placement-extraction-file-notes

As part of that, I've been doing some exploration to tease out the
issues we're going to hit as we do it. None of this is work that
will be merged, rather it is stuff to figure out what we need to
know to do the eventual merging correctly and efficiently.

Please note that doing that is just the near edge of a large
collection of changes that will cascade in many ways to many
projects, tools, distros, etc. The people doing this are aware of
that, and the relative simplicity (and fairly immediate success) of
these experiments is not misleading people into thinking "hey, no
big deal". It's a big deal.

There's a strategy now (described at the end of the first etherpad
listed above) for trimming the nova history to create a thing which
is placement. From the first run of that Ed created a github repo
and I branched that to eventually create:

https://github.com/EdLeafe/placement/pull/2

In that, all the placement unit and functional tests are now
passing, and my placecat [1] integration suite also passes.

That work has highlighted some gaps in the process for trimming
history which will be refined to create another interim repo. We'll
repeat this until the process is smooth, eventually resulting in an
openstack/placement.


We talked about the github strategy a bit in the placement meeting 
today [1]. Without being involved in this technical extraction work 
for the past few weeks, I came in with a different perspective on the 
end-game, and it was not aligned with what Chris/Ed thought as far as 
how we get to the official openstack/placement repo.


At a high level, Ed's repo [2] is a fork of nova with large changes 
on top using pull requests to do things like remove the non-placement 
nova files, update import paths (because the import structure changes 
from nova.api.openstack.placement to just placement), and then 
changes from Chris [3] to get tests working. Then the idea was to 
just use that to seed the openstack/placement repo and rather than 
review the changes along the way*, people that care about what 
changed (like myself) would see the tests passing and be happy enough.


However, I disagree with this approach since it bypasses our 
community code review system of using Gerrit and relying on a core 
team to approve changes at the sake of expediency.


What I would like to see are the changes that go into making the seed 
repo and what gets it to passing tests done in gerrit like we do for 
everything else. There are a couple of options on how this is done 
though:


1. Seed the openstack/placement repo with the filter_git_history.sh 
script output as Ed has done here [4]. This would include moving the 
placement files to the root of the tree and dropping nova-specific 
files. Then make incremental changes in gerrit like with [5] and the 
individual changes which make up Chris's big pull request [3]. I am 
primarily interested in making sure there are not content changes 
happening, only mechanical tree-restructuring type changes, stuff 
like that. I'm asking for more changes in gerrit so they can be 
sanely reviewed (per normal).


2. Eric took a slightly different tack in that he's OK with just a 
couple of large changes (or even large patch sets within a single 
change) in gerrit rather than ~30 individual changes. So that would 
be more like at most 3 changes in gerrit for [4][5][3].


3. The 3rd option is we just don't use gerrit at all and seed the 
official repo with the results of Chris and Ed's work in Ed's repo in 
github. Clearly this would be the fastest way to get us to a new repo 
(at the expense of bucking community code review and development 
process - is an exception worth it?).




I assumed that the work on github was done to _discover_ what steps 
needs to be done later to populate the new repo and make the tests 
pass. So I more like the #1 approach.


Option 1 would clearly be a drain on at least 2 nova cores to go 
through the changes. I think Eric is on board for reviewing options 1 
or 2 in either case, but he prefers option 2. Since I'm throwing a 
wrench in the works, I also need to stand up and review the changes 
if we go with option 1 or 2. Jay said he'd review them but consider 
these reviews lower priority. I expect we could get some help from 
some other nova cores though, maybe not on all changes, but at least 
some (thinking gibi, alex_xu, sfinucan).


I will spend time reviewing the patches coming for the new placement 
repo.


Cheers,
gibi



Any CI jobs would be non-voting while going through options 1 or 2 
until we get to a point that tests should finally be

Re: [openstack-dev] [Freezer] Reactivate the team

2018-08-28 Thread Saad Zaher

Hello Kendall,

Can we get the old meeting slot which is Thursday @ 14:00 UTC  if this is
Ok with everyone ?

Thanks,
Saad!

On Mon, Aug 27, 2018 at 11:46 PM Kendall Nelson 
wrote:

> Hello,
>
> Here is the change that adds Freezer to StoryBoard[1]. If we can get the
> PTL's +1, we can move forward with the migration. Does Friday work for you
> all?
>
> -Kendall (diablo_rojo)
>
> [1] https://review.openstack.org/#/c/596918/
>
> On Sun, Aug 26, 2018 at 7:59 PM Trinh Nguyen 
> wrote:
>
>> @Kendall: please help the Freezer team. Thanks.
>>
>> @gengchc2: I think you should send an email to TC and ask for help. The
>> Freezer core seems to inactive.
>>
>>
>> *Trinh Nguyen *| Founder & Chief Architect
>>
>> 
>>
>> *E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *
>>
>>
>>
>> On Mon, Aug 27, 2018 at 11:26 AM  wrote:
>>
>>> Hi,Kendall:
>>>
>>> I agree to migrate freezer project from Launchpad to Storyboard, Thanks.
>>>
>>> By the way, When will grant privileges for gengchc2 on Launchpad and
>>> Project Gerrit repositories?
>>>
>>>
>>>
>>> Best regards,
>>>
>>> gengchc2
>>>
>>>
>>>
>>>
>>>
>>>
>>> __
>>> 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
>


-- 
--
Best Regards,
Saad!
__
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] [nova] [placement] extraction (technical) update


On Mon, 27 Aug 2018, melanie witt wrote:

I think we should use the openstack review system (gerrit) for moving the 
code. We're moving a critical piece of nova to its own repo and I think it's 
worth having the review and history contained in the openstack review system.


This seems a reasonable enough strategy, in broad strokes. I want to
be sure that we're all actually in agreement on the details, as
we've had a few false starts and I think some of the details are
getting confused in the shuffle and the general busy-ness in progress.

Is anyone aware of anyone who hasn't commented yet that should? If
you are, please poke them so we don't surprise them.

Using smaller changes that make it easy to see import vs content changes 
might make review faster than fewer, larger changes.


I _think_ we ought to be able to use the existing commits from the
runs-throughs-to-passing-tests already done, but if we use the
strategy described below it doesn't really matter: the TDD approach
(after fixing paths and test config) is pretty fast.

The most important bit of all of this is making sure we don't break anything 
in the process for operators and users consuming nova and placement, and 
ensure the upgrade path from rocky => stein is tested in grenade.


This is one of the areas where pretty active support from all of
nova will be required: getting zuul, upgrade paths, and the like
clearly defined and executed.


The steps I think we should take are:

1. We copy the placement code into the openstack/placement repo and have it 
passing all of its own unit and functional tests.


To break that down to more detail, how does this look?
(note the ALL CAPS where more than acknowledgement is requested)

1.1 Run the git filter-branch on a copy of nova
1.1.1 Add missing files to the file list:
  1.1.1.1 .gitignore
  1.1.1.2 # ANYTHING ELSE?
1.2 Push -f that thing, acknowledge to be broken, to a seed repo on github
(ed's repo should be fine)
1.3 Do the repo creation bits described in
https://docs.openstack.org/infra/manual/creators.html
to seed openstack/placement
1.3.1 set zuul jobs. Either to noop-jobs, or non voting basic
func and unit # INPUT DESIRED HERE
1.4 Once the repo exists with some content, incrementally bring it to
working
1.4.1 Update tox.ini to be placement oriented
1.4.2 Update setup.cfg to be placement oriented
1.4.3 Correct .stesr.conf
1.4.4 Move base of placement to "right" place
1.4.5 Move unit and functionals to right place
1.4.6 Do automated path fixings
1.4.7 Set up translation domain and i18n.py corectly
1.4.8 Trim placement/conf to just the conf settings required
  (api, base, database, keystone, paths, placement)
1.4.9 Remove database files that are not relevant (the db api is
  not used by placement)
1.4.10 Fix the Database Fixture to be just one database
1.4.11 Disable migrations that can't work (because of
   dependencies on nova code, 014 and 030 are examples)
   # INPUT DESIRED HERE AND ON SCHEMA MIGRATIONS IN GENERAL
1.4.12 Incrementally get tests working
1.4.13 Fix pep8
1.5 Make zuul pep, unit and functional voting
1.6 Create tools for db table sync/create
1.7 Concurrently go to step 2, where the harder magic happens.
1.8 Find and remove dead code (there will be some).
1.9 Tune up and confirm docs
1.10 Grep for remaining "nova" (as string and spirit) and fix


Item 1.4.12 may deserve some discussion. When I've done this the
several times before, the strategy I've used is to be test driven:
run either functional or unit tests, find and fix one of the errors
revealed, commit, move on.

This strategy has worked very well for me because of the "test
driven" part, but I'm hesitant to do it if reviewers are going to
get to a patch and say "why didn't you also change X?" The answer to
that question is "because this is incremental and test driven and
the tests didn't demand that change (yet)". Sometimes that will mean
that things of the same class of change are in different commits.

Are people okay with that and willing to commit to being okay with
that answer in reviews? To some extent we need to have some faith on
the end result: the tests work. If people are not okay with that, we
need the people who are not to determine and prove the alternate
strategy. I've had this one work and work well.

Please help to refine the above, thank you.

2. We have a stack of changes to zuul jobs that show nova working but 
deploying placement in devstack from the new repo instead of nova's repo. 
This includes the grenade job, ensuring that upgrade works.


If we can make a list for this (and the subsequent) major items that
is as detailed as I've made for step 1 above, I think that will help
us avoid some of the confusion and frustration that comes up. I'm
neither able nor willing to be responsible for creating those lists
for all these points, but very happy to help.

3. When those

Re: [openstack-dev] [nova] [placement] extraction (technical) update

2018-08-28 Thread Alex Xu

2018-08-27 23:31 GMT+08:00 Matt Riedemann :

> On 8/24/2018 7:36 AM, Chris Dent wrote:
>
>>
>> Over the past few days a few of us have been experimenting with
>> extracting placement to its own repo, as has been discussed at
>> length on this list, and in some etherpads:
>>
>> https://etherpad.openstack.org/p/placement-extract-stein
>> https://etherpad.openstack.org/p/placement-extraction-file-notes
>>
>> As part of that, I've been doing some exploration to tease out the
>> issues we're going to hit as we do it. None of this is work that
>> will be merged, rather it is stuff to figure out what we need to
>> know to do the eventual merging correctly and efficiently.
>>
>> Please note that doing that is just the near edge of a large
>> collection of changes that will cascade in many ways to many
>> projects, tools, distros, etc. The people doing this are aware of
>> that, and the relative simplicity (and fairly immediate success) of
>> these experiments is not misleading people into thinking "hey, no
>> big deal". It's a big deal.
>>
>> There's a strategy now (described at the end of the first etherpad
>> listed above) for trimming the nova history to create a thing which
>> is placement. From the first run of that Ed created a github repo
>> and I branched that to eventually create:
>>
>> https://github.com/EdLeafe/placement/pull/2
>>
>> In that, all the placement unit and functional tests are now
>> passing, and my placecat [1] integration suite also passes.
>>
>> That work has highlighted some gaps in the process for trimming
>> history which will be refined to create another interim repo. We'll
>> repeat this until the process is smooth, eventually resulting in an
>> openstack/placement.
>>
>
> We talked about the github strategy a bit in the placement meeting today
> [1]. Without being involved in this technical extraction work for the past
> few weeks, I came in with a different perspective on the end-game, and it
> was not aligned with what Chris/Ed thought as far as how we get to the
> official openstack/placement repo.
>
> At a high level, Ed's repo [2] is a fork of nova with large changes on top
> using pull requests to do things like remove the non-placement nova files,
> update import paths (because the import structure changes from
> nova.api.openstack.placement to just placement), and then changes from
> Chris [3] to get tests working. Then the idea was to just use that to seed
> the openstack/placement repo and rather than review the changes along the
> way*, people that care about what changed (like myself) would see the tests
> passing and be happy enough.
>
> However, I disagree with this approach since it bypasses our community
> code review system of using Gerrit and relying on a core team to approve
> changes at the sake of expediency.
>
> What I would like to see are the changes that go into making the seed repo
> and what gets it to passing tests done in gerrit like we do for everything
> else. There are a couple of options on how this is done though:
>
> 1. Seed the openstack/placement repo with the filter_git_history.sh script
> output as Ed has done here [4]. This would include moving the placement
> files to the root of the tree and dropping nova-specific files. Then make
> incremental changes in gerrit like with [5] and the individual changes
> which make up Chris's big pull request [3]. I am primarily interested in
> making sure there are not content changes happening, only mechanical
> tree-restructuring type changes, stuff like that. I'm asking for more
> changes in gerrit so they can be sanely reviewed (per normal).
>
> 2. Eric took a slightly different tack in that he's OK with just a couple
> of large changes (or even large patch sets within a single change) in
> gerrit rather than ~30 individual changes. So that would be more like at
> most 3 changes in gerrit for [4][5][3].
>
> 3. The 3rd option is we just don't use gerrit at all and seed the official
> repo with the results of Chris and Ed's work in Ed's repo in github.
> Clearly this would be the fastest way to get us to a new repo (at the
> expense of bucking community code review and development process - is an
> exception worth it?).
>
> Option 1 would clearly be a drain on at least 2 nova cores to go through
> the changes. I think Eric is on board for reviewing options 1 or 2 in
> either case, but he prefers option 2. Since I'm throwing a wrench in the
> works, I also need to stand up and review the changes if we go with option
> 1 or 2. Jay said he'd review them but consider these reviews lower
> priority. I expect we could get some help from some other nova cores
> though, maybe not on all changes, but at least some (thinking gibi,
> alex_xu, sfinucan).
>

I can help some. And yes, small change is good than huge change.


>
> Any CI jobs would be non-voting while going through options 1 or 2 until
> we get to a point that tests should finally be passing and we can make them
> voting (it should be possible to

Re: [openstack-dev] [rpm-packaging] Step down as a reviewer

2018-08-28 Thread Dirk Müller

Hi Alberto,

Am Mo., 13. Aug. 2018 um 11:08 Uhr schrieb Alberto Planas Dominguez
:

> I will change my role at SUSE at the end of the month (August 2018), so
> I request to be removed from the core position on those projects.

Sad to see you go, but I appreciate the heads up and wish you all the
best at the new position.

I've removed you from the list of core's as request.

Greetings,
Dirk

__
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] [nova] [placement] extraction (technical) update

2018-08-28 Thread Stephen Finucane

On Mon, 2018-08-27 at 14:23 -0700, melanie witt wrote:
> On Mon, 27 Aug 2018 10:31:50 -0500, Matt Riedemann wrote:
> > On 8/24/2018 7:36 AM, Chris Dent wrote:
> > > 
> > > Over the past few days a few of us have been experimenting with
> > > extracting placement to its own repo, as has been discussed at
> > > length on this list, and in some etherpads:
> > > 
> > > https://etherpad.openstack.org/p/placement-extract-stein
> > > https://etherpad.openstack.org/p/placement-extraction-file-notes
> > > 
> > > As part of that, I've been doing some exploration to tease out the
> > > issues we're going to hit as we do it. None of this is work that
> > > will be merged, rather it is stuff to figure out what we need to
> > > know to do the eventual merging correctly and efficiently.
> > > 
> > > Please note that doing that is just the near edge of a large
> > > collection of changes that will cascade in many ways to many
> > > projects, tools, distros, etc. The people doing this are aware of
> > > that, and the relative simplicity (and fairly immediate success) of
> > > these experiments is not misleading people into thinking "hey, no
> > > big deal". It's a big deal.
> > > 
> > > There's a strategy now (described at the end of the first etherpad
> > > listed above) for trimming the nova history to create a thing which
> > > is placement. From the first run of that Ed created a github repo
> > > and I branched that to eventually create:
> > > 
> > > https://github.com/EdLeafe/placement/pull/2
> > > 
> > > In that, all the placement unit and functional tests are now
> > > passing, and my placecat [1] integration suite also passes.
> > > 
> > > That work has highlighted some gaps in the process for trimming
> > > history which will be refined to create another interim repo. We'll
> > > repeat this until the process is smooth, eventually resulting in an
> > > openstack/placement.
> > 
> > We talked about the github strategy a bit in the placement meeting today
> > [1]. Without being involved in this technical extraction work for the
> > past few weeks, I came in with a different perspective on the end-game,
> > and it was not aligned with what Chris/Ed thought as far as how we get
> > to the official openstack/placement repo.
> > 
> > At a high level, Ed's repo [2] is a fork of nova with large changes on
> > top using pull requests to do things like remove the non-placement nova
> > files, update import paths (because the import structure changes from
> > nova.api.openstack.placement to just placement), and then changes from
> > Chris [3] to get tests working. Then the idea was to just use that to
> > seed the openstack/placement repo and rather than review the changes
> > along the way*, people that care about what changed (like myself) would
> > see the tests passing and be happy enough.
> > 
> > However, I disagree with this approach since it bypasses our community
> > code review system of using Gerrit and relying on a core team to approve
> > changes at the sake of expediency.
> > 
> > What I would like to see are the changes that go into making the seed
> > repo and what gets it to passing tests done in gerrit like we do for
> > everything else. There are a couple of options on how this is done though:
> > 
> > 1. Seed the openstack/placement repo with the filter_git_history.sh
> > script output as Ed has done here [4]. This would include moving the
> > placement files to the root of the tree and dropping nova-specific
> > files. Then make incremental changes in gerrit like with [5] and the
> > individual changes which make up Chris's big pull request [3]. I am
> > primarily interested in making sure there are not content changes
> > happening, only mechanical tree-restructuring type changes, stuff like
> > that. I'm asking for more changes in gerrit so they can be sanely
> > reviewed (per normal).
> > 
> > 2. Eric took a slightly different tack in that he's OK with just a
> > couple of large changes (or even large patch sets within a single
> > change) in gerrit rather than ~30 individual changes. So that would be
> > more like at most 3 changes in gerrit for [4][5][3].
> > 
> > 3. The 3rd option is we just don't use gerrit at all and seed the
> > official repo with the results of Chris and Ed's work in Ed's repo in
> > github. Clearly this would be the fastest way to get us to a new repo
> > (at the expense of bucking community code review and development process
> > - is an exception worth it?).
> > 
> > Option 1 would clearly be a drain on at least 2 nova cores to go through
> > the changes. I think Eric is on board for reviewing options 1 or 2 in
> > either case, but he prefers option 2. Since I'm throwing a wrench in the
> > works, I also need to stand up and review the changes if we go with
> > option 1 or 2. Jay said he'd review them but consider these reviews
> > lower priority. I expect we could get some help from some other nova
> > cores though, maybe not on all changes, but at least some (thinking
>

Re: [openstack-dev] [Searchlight] Team meeting next week

Hi Manh,

15:00 UTC is 22:00 in your time zone.

Bests,

On Tue, Aug 28, 2018, 17:26 Dinh Manh  wrote:

> Dear All.
> I'm very sorry for my lately reply, but the time of 15:00 UTC is my office
> work time so i'm afraid that i can't join with team in that time.
> Very sorry.
>
> Best regards.
>
>
> *---*
>
> *Đinh Văn Mạnh*
>
> Phone: 0167 6513 816
>
> Mail: *manhdinh1...@gmail.com *
>
>
> Vào Th 2, 27 thg 8, 2018 vào lúc 14:10 Trinh Nguyen <
> dangtrin...@gmail.com> đã viết:
>
>> Hi team,
>>
>> This is a kind reminder of our meeting next Thursday, 15:00 UTC. Please
>> see below for meeting details.
>>
>> Bests,
>>
>> *Trinh Nguyen *| Founder & Chief Architect
>>
>> 
>>
>> *E:* dangtrin...@gmail.com | *W:* *www.edlab.xyz *
>>
>>
>>
>> On Sat, Aug 25, 2018 at 1:11 PM Trinh Nguyen 
>> wrote:
>>
>>> Dear team,
>>>
>>> I would like to organize a team meeting on Thursday next week:
>>>
>>>- Date: 30 August  2018
>>>- Time: 15:00 UTC
>>>- Channel: #openstack-meeting-4
>>>
>>> All existing core members and new contributors are welcome.
>>>
>>> Here is the Searchlight's Etherpad for Stein, all ideas are welcomed:
>>>
>>> https://etherpad.openstack.org/p/searchlight-stein-ptg
>>>
>>> Please reply or ping me on IRC (#openstack-searchlight, dangtrinhnt) if
>>> you want to join.
>>>
>>> Bests,
>>>
>>> *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] [TripleO]Addressing Edge/Multi-site/Multi-cloud deployment use cases (new squad)

2018-08-28 Thread Dmitry Tantsur


On 08/22/2018 03:26 PM, Jiri Tomasek wrote:

Hi,





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


+1, we need to identify how much this affects the existing API and overall user 
experience

for managing deployment plans. Currentl plan management options we support are:
- create plan from default files (/usr/share/tht...)
- create/update plan from local directory
- create/update plan by providing tarball
- create/update plan from remote git repository

Ian has been working on similar efforts towards performance improvements [2], It
would be good to take this a step further and evaluate possibility to eliminate 
Swift entirely.


[2] https://review.openstack.org/#/c/581153/


We need to do something about ironic-inspector then: it currently depends on 
swift for storing collected data. Fortunately, there is a spec to fix it, but it 
hasn't been our team's priority. Reviews are welcome: 
https://review.openstack.org/#/c/587698/


Dmitry



-- Jirka








__
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] [placement] XenServer CI failed frequently because of placement update

2018-08-28 Thread Naichuan Sun

Hi, experts,

XenServer CI failed frequently with an error "No valid host was found. " for 
more than a week. I think it is cause by placement update.
It looks ` _get_provider_ids_matching ` return empty when allocate candidates, 
but filter statements looks good(vcpu/memory/disk):

coalesce(usage_vcpu.used, :coalesce_1) + :coalesce_2 <= (inv_vcpu.total - 
inv_vcpu.reserved) * inv_vcpu.allocation_ratio AND inv_vcpu.min_unit <= 
:min_unit_1 AND inv_vcpu.max_unit >= :max_unit_1 AND :step_size_1 % 
inv_vcpu.step_size = :param_1, coalesce(usage_memory_mb.used, :coalesce_1) + 
:coalesce_2 <= (inv_memory_mb.total - inv_memory_mb.reserved) * 
inv_memory_mb.allocation_ratio AND inv_memory_mb.min_unit <= :min_unit_1 AND 
inv_memory_mb.max_unit >= :max_unit_1 AND :step_size_1 % 
inv_memory_mb.step_size = :param_1, coalesce(usage_disk_gb.used, :coalesce_1) + 
:coalesce_2 <= (inv_disk_gb.total - inv_disk_gb.reserved) * 
inv_disk_gb.allocation_ratio AND inv_disk_gb.min_unit <= :min_unit_1 AND 
inv_disk_gb.max_unit >= :max_unit_1 AND :step_size_1 % inv_disk_gb.step_size = 
:param_1

Also, database looks good:
mysql> select * from inventories;
+-+-++--+---+---+--+--+--+---+--+
| created_at  | updated_at  | id | resource_provider_id | 
resource_class_id | total | reserved | min_unit | max_unit | step_size | 
allocation_ratio |
+-+-++--+---+---+--+--+--+---+--+
| 2018-08-27 10:14:12 | 2018-08-27 10:16:11 |  1 |1 |   
  0 |24 |0 |1 |   24 | 1 |  
  0 |
| 2018-08-27 10:14:12 | 2018-08-27 10:16:11 |  2 |1 |   
  1 | 98293 |  512 |1 |98293 | 1 |  
  0 |
| 2018-08-27 10:14:12 | 2018-08-27 10:16:11 |  3 |1 |   
  2 |   450 |0 |1 |  450 | 1 |  
  2 |
+-+-++--+---+---+--+--+--+---+--+
3 rows in set (0.00 sec)

mysql> select * from resource_providers;
+-+-++--+--++--+--++
| created_at  | updated_at  | id | uuid 
| name | generation | can_host | root_provider_id | 
parent_provider_id |
+-+-++--+--++--+--++
| 2018-08-27 10:14:11 | 2018-08-27 10:16:11 |  1 | 
cb831119-c68f-47ac-92ba-0f19c1a56b31 | xrtmia-03-11 |  2 | NULL |   
 1 |   NULL |
+-+-++--+--++--+--++
1 row in set (0.00 sec)
It is a alo environment deployed by devstack.
Anyone has some suggestions about that?
Thank you very much.

BR.
Naichuan Sun

__
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] Team meeting next week