Re: [openstack-dev] [requirements][heat][congress] gabbi<1.42.1 causing error in queens dsvm

[Tony Breeds]

On Mon, Aug 13, 2018 at 04:10:30PM -0700, Eric K wrote:
> It appears that gabbi<1.42.1 is causing on error with heat tempest
> plugin in congress stable/queens dsvm job [1][2][3]. The issue was
> addressed in heat tempest plugin [4], but the problem remains for
> stable/queens jobs because the queens upper-constraint is still at
> 1.40.0 [5].
> 
> Any suggestions on how to proceed? Thank you!

https://review.openstack.org/591561 Should fix it.  You can create a
no-op test that:

Depends-On: https://review.openstack.org/591561 

to verify it works.  Doing so and reporting the change ID would be
really helpful.

Yours Tony.


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

Re: [openstack-dev] [requirements][release][osc] FFE osc-lib 1.11.1 release

[Tony Breeds]

On Tue, Aug 14, 2018 at 12:11:53AM -0500, Matthew Thode wrote:

> Maybe it'd be better to figure out what's using that removed method and
> those would need the update?

Given we have per-project deps in rocky only those that *need* the
exclusion will need to apply it.

I think it's fair to accept the U-c bump and block 0.11.0 in
global-requirements.  Then any project that find they're broken next
week can just add the exclusion themselves and move on.


Yours Tony.


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

Re: [openstack-dev] [requirements][release][osc] FFE osc-lib 1.11.1 release

[Matthew Thode]

On 18-08-14 13:56:28, Akihiro Motoki wrote:
> 2018年8月14日(火) 13:38 Matthew Thode :
> >
> > On 18-08-14 13:19:27, Akihiro Motoki wrote:
> > > Hi,
> > >
> > > I would like to request FFE for osc-lib 1.11.1 release.
> > >
> > > https://review.openstack.org/591556
> > >
> > > osc-iib commit e3d772050f3f4de6369b3dd1ba1269e2903666f7 replaced
> > > issubclass() with isinstance() unexpectedly.
> > > As a result, osc-lib 1.11.0 breaks existing OSC plugins and
> > > the neutronclient OSC plugin gate is now broken.
> > > To fix the gate, osc-lib 1.11.1 release would be appreciated.
> > >
> > > upper-constraints is bumped to osc-lib 1.11.1.
> > > It is better to block osc-lib 1.11.0 but I am familiar whether we need
> > > to block it or not.
> > >
> >
> > What libs (further down the dep tree) would need the exclusion?  They'd
> > likely also need a FFE for at least a UC bump.
> > You have my (and requirements) ack for a UC only bump at least.
> 
> AFAIK all OSC plugins and OSC directly consume osc-lib and there is no
> libs to consume osc-lib.
> In this case, we don't need to block a specific version of osc-lib, right?
> Perhaps it is just because I don't understand the current policy well.
> 
> From neutronclient and other OSC plugin perspective, it is fine to bump UC 
> only.
> 

The current list is the following.

++-+--+---+
| Repository | Filename 
   | Line | Text
  |
++-+--+---+
| openstack-zuul-jobs| 
playbooks/legacy/requirements-integration-dsvm/run.yaml 
|   76 | export PROJECTS="openstack/osc-lib $PROJECTS" |
| openstack-zuul-jobs| 
playbooks/legacy/requirements-integration-dsvm-ubuntu-trusty/run.yaml   
|   77 | export PROJECTS="openstack/osc-lib $PROJECTS" |
| osc-placement  | requirements.txt 
   |8 | osc-lib>=1.2.0  
# Apache-2.0  |
| osops-tools-contrib| ansible_requirements.txt 
   |   31 | osc-lib==1.1.0  
  |
| python-adjutantclient  | requirements.txt 
   |9 | osc-lib>=1.5.1 
# Apache-2.0   |
| python-aodhclient  | requirements.txt 
   |7 | osc-lib>=1.0.1 
# Apache-2.0   |
| python-cyborgclient| requirements.txt 
   |   16 | osc-lib>=1.8.0 
# Apache-2.0   |
| python-designateclient | requirements.txt 
   |6 | osc-lib>=1.8.0 
# Apache-2.0   |
| python-distilclient| requirements.txt 
   |4 | osc-lib>=1.7.0 
# Apache-2.0   |
| python-glareclient | requirements.txt 
   |   13 | osc-lib>=1.7.0 
# Apache-2.0   |
| python-heatclient  | requirements.txt 
   |9 | osc-lib>=1.8.0 
# Apache-2.0   |
| python-iotronicclient  | requirements.txt 
   |9 | osc-lib>=1.2.0 
# Apache-2.0   |
| python-ironic-inspector-client | requirements.txt 
   |5 | osc-lib>=1.8.0 
# Apache-2.0   |
| python-ironicclient| requirements.txt 
   |9 | osc-lib>=1.10.0 
# Apache-2.0  |
| python-karborclient| requirements.txt 
   |   11 | osc-lib>=1.8.0 
# Apache-2.0   |
| python-kingbirdclient  | requirements.txt 
   |5 | osc-lib>=1.2.0 
# Apache-2.0

Re: [openstack-dev] [requirements][heat][congress] gabbi<1.42.1 causing error in queens dsvm

[Rabi Mishra]

On Tue, Aug 14, 2018 at 4:40 AM, Eric K  wrote:

> It appears that gabbi<1.42.1 is causing on error with heat tempest
> plugin in congress stable/queens dsvm job [1][2][3].

I wonder why you're enabling heat-tempest-plugin in the first place? I see
a number of tempest plugins enabled. However, you don't seem to gate on the
tests in those plugins[1].

[1]
https://github.com/openstack/congress/blob/master/playbooks/legacy/congress-devstack-api-base/run.yaml#L61


> The issue was
> addressed in heat tempest plugin [4], but the problem remains for
> stable/queens jobs because the queens upper-constraint is still at
> 1.40.0 [5].
>
>
Yeah, a uc bump to 1.42.1 is required if you're enabling it.


> Any suggestions on how to proceed? Thank you!
>
> [1] https://bugs.launchpad.net/heat-tempest-plugin/+bug/1749218
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1609361
> [3] http://logs.openstack.org/41/567941/2/check/congress-
> devstack-api-mysql/c232d8a/job-output.txt.gz#_2018-08-13_11_46_28_441837
> [4] https://review.openstack.org/#/c/544025/
> [5] https://github.com/openstack/requirements/blob/stable/
> queens/upper-constraints.txt#L245
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Rabi Mishra
__
OpenStack Development Mailing 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] [requirements][release][osc] FFE osc-lib 1.11.1 release

[Akihiro Motoki]

2018年8月14日(火) 13:38 Matthew Thode :
>
> On 18-08-14 13:19:27, Akihiro Motoki wrote:
> > Hi,
> >
> > I would like to request FFE for osc-lib 1.11.1 release.
> >
> > https://review.openstack.org/591556
> >
> > osc-iib commit e3d772050f3f4de6369b3dd1ba1269e2903666f7 replaced
> > issubclass() with isinstance() unexpectedly.
> > As a result, osc-lib 1.11.0 breaks existing OSC plugins and
> > the neutronclient OSC plugin gate is now broken.
> > To fix the gate, osc-lib 1.11.1 release would be appreciated.
> >
> > upper-constraints is bumped to osc-lib 1.11.1.
> > It is better to block osc-lib 1.11.0 but I am familiar whether we need
> > to block it or not.
> >
>
> What libs (further down the dep tree) would need the exclusion?  They'd
> likely also need a FFE for at least a UC bump.
> You have my (and requirements) ack for a UC only bump at least.

AFAIK all OSC plugins and OSC directly consume osc-lib and there is no
libs to consume osc-lib.
In this case, we don't need to block a specific version of osc-lib, right?
Perhaps it is just because I don't understand the current policy well.

From neutronclient and other OSC plugin perspective, it is fine to bump UC only.

Thanks,
Akihiro Motoki (amotoki)

>
> --
> Matthew Thode (prometheanfire)
> __
> OpenStack Development Mailing 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] [requirements][release][osc] FFE osc-lib 1.11.1 release

[Matthew Thode]

On 18-08-14 13:19:27, Akihiro Motoki wrote:
> Hi,
> 
> I would like to request FFE for osc-lib 1.11.1 release.
> 
> https://review.openstack.org/591556
> 
> osc-iib commit e3d772050f3f4de6369b3dd1ba1269e2903666f7 replaced
> issubclass() with isinstance() unexpectedly.
> As a result, osc-lib 1.11.0 breaks existing OSC plugins and
> the neutronclient OSC plugin gate is now broken.
> To fix the gate, osc-lib 1.11.1 release would be appreciated.
> 
> upper-constraints is bumped to osc-lib 1.11.1.
> It is better to block osc-lib 1.11.0 but I am familiar whether we need
> to block it or not.
> 

What libs (further down the dep tree) would need the exclusion?  They'd
likely also need a FFE for at least a UC bump.
You have my (and requirements) ack for a UC only bump at least.

-- 
Matthew Thode (prometheanfire)


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

[openstack-dev] [requirements][release][osc] FFE osc-lib 1.11.1 release

[Akihiro Motoki]

Hi,

I would like to request FFE for osc-lib 1.11.1 release.

https://review.openstack.org/591556

osc-iib commit e3d772050f3f4de6369b3dd1ba1269e2903666f7 replaced
issubclass() with isinstance() unexpectedly.
As a result, osc-lib 1.11.0 breaks existing OSC plugins and
the neutronclient OSC plugin gate is now broken.
To fix the gate, osc-lib 1.11.1 release would be appreciated.

upper-constraints is bumped to osc-lib 1.11.1.
It is better to block osc-lib 1.11.0 but I am familiar whether we need
to block it or not.

Thanks,
Akihiro Motoki (amotoki)

__
OpenStack Development Mailing 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] [requirements][heat][congress] gabbi<1.42.1 causing error in queens dsvm

[Matthew Thode]

On 18-08-13 16:10:30, Eric K wrote:
> It appears that gabbi<1.42.1 is causing on error with heat tempest
> plugin in congress stable/queens dsvm job [1][2][3]. The issue was
> addressed in heat tempest plugin [4], but the problem remains for
> stable/queens jobs because the queens upper-constraint is still at
> 1.40.0 [5].
> 
> Any suggestions on how to proceed? Thank you!
> 
> [1] https://bugs.launchpad.net/heat-tempest-plugin/+bug/1749218
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1609361
> [3] 
> http://logs.openstack.org/41/567941/2/check/congress-devstack-api-mysql/c232d8a/job-output.txt.gz#_2018-08-13_11_46_28_441837
> [4] https://review.openstack.org/#/c/544025/
> [5] 
> https://github.com/openstack/requirements/blob/stable/queens/upper-constraints.txt#L245
> 

iirc, a UC bump is allowed if it fixes gating, so that's alright by me
(reqs)

-- 
Matthew Thode (prometheanfire)


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

[openstack-dev] [requirements][heat][congress] gabbi<1.42.1 causing error in queens dsvm

[Eric K]

It appears that gabbi<1.42.1 is causing on error with heat tempest
plugin in congress stable/queens dsvm job [1][2][3]. The issue was
addressed in heat tempest plugin [4], but the problem remains for
stable/queens jobs because the queens upper-constraint is still at
1.40.0 [5].

Any suggestions on how to proceed? Thank you!

[1] https://bugs.launchpad.net/heat-tempest-plugin/+bug/1749218
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1609361
[3] 
http://logs.openstack.org/41/567941/2/check/congress-devstack-api-mysql/c232d8a/job-output.txt.gz#_2018-08-13_11_46_28_441837
[4] https://review.openstack.org/#/c/544025/
[5] 
https://github.com/openstack/requirements/blob/stable/queens/upper-constraints.txt#L245

__
OpenStack Development Mailing 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] (no subject)

[Amy Marrich]

Hi everyone,

If you’re running OpenStack, please participate in the User Survey
 to share more about the technology
you are using and provide feedback for the community by *August 21 - hurry,
it’s next week!!* By completing a deployment, you will qualify as an AUC
and receive a $300 USD ticket to the two upcoming Summits.

Please help us spread the word. a we're trying to gather as much real-world
deployment data as possible to share back with both the operator and
developer communities.

We are only conducting one survey this year, and the report will be
published at the Berlin Summit
.  II you would like
OpenStack user data in the meantime, check out the analytics dashboard
 updates in real time, throughout the
year.

The information provided is confidential and will only be presented in
aggregate unless you consent to make it public.

The deadline to complete the survey and be part of the next report is
next *Tuesday,
August 21** at 23:59 UTC.*

   - You can login and complete the OpenStack User Survey here:
   http://www.openstack.org/user-survey
   
   - If you’re interested in joining the OpenStack User Survey Working
   Group to help with the survey analysis, please complete this form:
   https://openstackfoundation.formstack.com/forms/user_survey_working_group
   

   - Help us promote the User Survey: https://twitter.com/Op
   enStack/status/993589356312088577
   


Please let me know if you have any questions.

Thanks,
Amy

Amy Marrich (spotz)
OpenStack User Committee
__
OpenStack Development Mailing 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] OVS-DPDK with NetVirt

[d.lake]

I'm really getting nowhere fast with this.

The latest in set of issues appears to be related to the "Permission denied" on 
the socket for qemu.

Just to reprise - this is OVS with DPDK, All-In-One with Intel NICs and ODL 
NetVirt.

Can ANYONE shed any light on this please - I can't believe that this isn't a 
very standard deployment and given that it works without DPDK on OVS I can't 
believe that it hasn't been seen hundreds of times beore.

Thanks

David

From: Lake D Mr (PG/R - Elec Electronic Eng)
Sent: 13 August 2018 16:35
To: 'Venkatrangan G - ERS, HCL Tech' ; 
dayavanti.gopal.kam...@ericsson.com; netvirt-...@lists.opendaylight.org
Subject: RE: OVS-DPDK with NetVirt

Hi

OK - I found some more guides which told me I needed to add:

[ovs]
datapath_type=netdev


to ML2_conf which I have done with an extra line in local.conf.

Now I am seeing the ports trying to be added as vhost-user ports.

BUT.  I am seeing this issue in the log:

qemu-kvm: -chardev socket,id=charnet0,path=/var/run/openvswitch/vhuab608c58-ae: 
Failed to connect socket /var/run/openvswitch/vhuab608c58-ae: Permission 
denied\n']#033[00m

Any ideas?   This is on an all-in-one system using CentOS 7.5

Thanks

David

From: Venkatrangan G - ERS, HCL Tech 
mailto:venkatrang...@hcl.com>>
Sent: 13 August 2018 10:36
To: Lake D Mr (PG/R - Elec Electronic Eng) 
mailto:d.l...@surrey.ac.uk>>; 
dayavanti.gopal.kam...@ericsson.com;
 netvirt-...@lists.opendaylight.org
Subject: RE: OVS-DPDK with NetVirt

Hi David,

I think you can run this ommand on your control node



 sudo neutron-odl-ovs-hostconfig --config-file=/etc/neutron/neutron.conf 
--debug --ovs_dpdk --bridge_mappings=physnet1:br-physnet1


(Not exactly sure of all the arguments, Please run this command in the control 
node with dpdk option, I think that should help)



Regards,
Venkat G
(When there is no windrow!!!)

From: 
netvirt-dev-boun...@lists.opendaylight.org
 
mailto:netvirt-dev-boun...@lists.opendaylight.org>>
 On Behalf Of d.l...@surrey.ac.uk
Sent: 13 August 2018 14:01
To: 
dayavanti.gopal.kam...@ericsson.com;
 netvirt-...@lists.opendaylight.org
Subject: Re: [netvirt-dev] OVS-DPDK with NetVirt

Good morning all

I wonder if someone could help with this please.

I don't know whether I need to add anything into ML2 to have the br-int 
installed in netdev mode or whether something else is wrong.

Thank you in advance

David

Sent from my iPhone

From: Lake D Mr (PG/R - Elec Electronic Eng)
Sent: Friday, August 10, 2018 10:57:02 PM
To: Dayavanti Gopal Kamath; 
netvirt-...@lists.opendaylight.org
Subject: RE: OVS-DPDK with NetVirt

Hi

The first link you sent doesn't work?

I've no idea what a pseudoagent binding driver is

All I've done is to follow the instructions for moving to DPDK on my existing 
ODL+OpenStack system which uses Devstack to install.

My understanding is that I needed to enable DPDK in OVS.  I do that with the 
following command:

ovs-vsctl --no-wait set Open_vSwitch . 
other_config:dpdk-init=true

I then unbound the DPDK NICs from the kernel mode driver and bound them to 
vfio-pci using "dpdk-devbind."

Once that is done, I created 4 bridges in OVS which all use the netdev datapath:

ovs-vsctl add-br br-dpdk1 -- set bridge br-dpdk1 
datapath_type=netdev
ovs-vsctl add-br br-dpdk2 -- set bridge br-dpdk2 datapath_type=netdev
ovs-vsctl add-br br-dpdk3 -- set bridge br-dpdk3 datapath_type=netdev
ovs-vsctl add-br br-dpdk4 -- set bridge br-dpdk4 datapath_type=netdev


Then I added the ports for the NICs to each bridge:

sudo ovs-vsctl add-port br-dpdk1 dpdk-p1 -- set Interface dpdk-p1 type=dpdk 
options:dpdk-devargs=:04:00.0
sudo ovs-vsctl add-port br-dpdk2 dpdk-p2 -- set Interface dpdk-p2 type=dpdk 
options:dpdk-devargs=:04:00.1
sudo ovs-vsctl add-port br-dpdk3 dpdk-p3 -- set Interface dpdk-p3 type=dpdk 
options:dpdk-devargs=:05:00.0
sudo ovs-vsctl add-port br-dpdk4 dpdk-p4 -- set Interface dpdk-p4 type=dpdk 
options:dpdk-devargs=:05:00.1

Having done that, I can verify that I can see traffic in the bridge using 
ovs-tcpdump so I know that the data is reaching OVS from the wire.

Then I run Devstack stack.sh and I get a working system with four physical 
networks.

However, this blog - 
https://joshhershberg.wordpress.com/2017/03/07/opendaylight-netvirt-dpdk-plumbing-how-it-all-works-together/

Re: [openstack-dev] [cinder] Reminder about the weekly Cinder meeting ...

[Jeremy Stanley]

On 2018-08-13 16:29:27 -0500 (-0500), Amy Marrich wrote:
> I know we did a ping last week in #openstack-ansible for our meeting no
> issue. I wonder if it's a length of names thing or a channel setting.
[...]

Freenode's Sigyn bot may not have been invited to
#openstack-ansible. We might want to consider kicking it from
channels while they have nick registration enforced.
-- 
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] [oslo] proposing Moisés Guimarães for oslo.config core

[Ben Nemec]

On 08/08/2018 08:18 AM, Doug Hellmann wrote:

Excerpts from Doug Hellmann's message of 2018-08-01 09:27:09 -0400:

Moisés Guimarães (moguimar) did quite a bit of work on oslo.config
during the Rocky cycle to add driver support. Based on that work,
and a discussion we have had since then about general cleanup needed
in oslo.config, I think he would make a good addition to the
oslo.config review team.

Please indicate your approval or concerns with +1/-1.

Doug


Normally I would have added moguimar to the oslo-config-core team
today, after a week's wait. Funny story, though. There is no
oslo-config-core team.

oslo.config is one of a few of our libraries that we never set up with a
separate review team. It is managed by oslo-core. We could set up a new
review team for that library, but after giving it some thought I
realized that *most* of the libraries are fairly stable, our team is
pretty small, and Moisés is a good guy so maybe we don't need to worry
about that.

I spoke with Moisés, and he agreed to be part of the larger core team.
He pointed out that the next phase of the driver work is going to happen
in castellan, so it would be useful to have another reviewer there. And
I'm sure we can trust him to be careful with reviews in other repos
until he learns his way around.

So, I would like to amend my original proposal and suggest that we add
Moisés to the oslo-core team.

Please indicate support with +1 or present any concerns you have. I
apologize for the confusion on my part.


I'm good with this reasoning, so +1 from me.

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

Re: [openstack-dev] [barbican][ara][helm][tempest] Removal of fedora-27 nodes

[Paul Belanger]

On Mon, Aug 13, 2018 at 09:56:44AM -0400, Paul Belanger wrote:
> On Thu, Aug 02, 2018 at 08:01:46PM -0400, Paul Belanger wrote:
> > Greetings,
> > 
> > We've had fedora-28 nodes online for some time in openstack-infra, I'd like 
> > to
> > finish the migration process and remove fedora-27 images.
> > 
> > Please take a moment to review and approve the following patches[1]. We'll 
> > be
> > using the fedora-latest nodeset now, which make is a little easier for
> > openstack-infra to migrate to newer versions of fedora.  Next time around, 
> > we'll
> > send out an email to the ML once fedora-29 is online to give projects some 
> > time
> > to test before we make the change.
> > 
> > Thanks
> > - Paul
> > 
> > [1] https://review.openstack.org/#/q/topic:fedora-latest
> > 
> Thanks for the approval of the patches above, today we are blocked by the
> following backport for barbican[2]. If we can land this today, we can proceed
> with the removal from nodepool.
> 
> Thanks
> - Paul
> 
> [2] https://review.openstack.org/590420/
> 
Thanks to the fast approvals today, we've been able to fully remove
fedora-27 from nodepool.  All jobs will now use fedora-latest, which is
currently fedora-28.

We'll send out an enail once we are ready to bring fedora-29 online, and
promote it to fedora-latest.

Thanks
- Paul

__
OpenStack Development Mailing 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] about live-resize down the instance

[melanie witt]

On Mon, 13 Aug 2018 09:46:41 -0600, Chris Friesen wrote:

On 08/13/2018 02:07 AM, Rambo wrote:

Hi,all

I find it is important that live-resize the instance in production
environment,especially live downsize the disk.And we have talked it many
years.But I don't know why the bp[1] didn't approved.Can you tell me more about
this ?Thank you very much.

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



It's been reviewed a number of times...I thought it was going to get approved
for Rocky, but I think it didn't quite make it in...you'd have to ask the nova
cores why not.

It should be noted though that the above live-resize spec explicitly did not
cover resizing smaller, only larger.


From what I find in the PTG notes [1] and the spec, it looks like this 
didn't go forward for lack of general interest. We have a lot of work to 
review every cycle and we generally focus on functionality that impact 
operators the most and look for +1s on specs from operators who are 
interested in the features. From what I can tell from the 
comments/votes, there isn't much/any operator interest about live-resize.


As has been mentioned, resize down is hypervisor-specific whether or not 
it's supported. For example, in the libvirt driver, resize down of 
ephemeral disk is not allowed at all and resize down of root disk is 
only allowed if the instance is boot-from-volume [2]. The xenapi driver 
disallows resize down of ephemeral disk [3], the vmware driver disallows 
resize down of root disk [4], the hyperv driver disallows resize down of 
root disk [5].


So, allowing only live-resize up would be a way to behave consistently 
across virt drivers.


-melanie

[1] https://etherpad.openstack.org/p/nova-ptg-rocky L690
[2] 
https://github.com/openstack/nova/blob/afe4512bf66c89a061b1a7ccd3e7ac8e3b1b284d/nova/virt/libvirt/driver.py#L8243-L8246
[3] 
https://github.com/openstack/nova/blob/afe4512bf66c89a061b1a7ccd3e7ac8e3b1b284d/nova/virt/xenapi/vmops.py#L1357-L1359
[4] 
https://github.com/openstack/nova/blob/afe4512bf66c89a061b1a7ccd3e7ac8e3b1b284d/nova/virt/vmwareapi/vmops.py#L1421-L1427
[5] 
https://github.com/openstack/nova/blob/afe4512bf66c89a061b1a7ccd3e7ac8e3b1b284d/nova/virt/hyperv/migrationops.py#L107-L114




















__
OpenStack Development Mailing 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] [cinder] Reminder about the weekly Cinder meeting ...

[Amy Marrich]

I know we did a ping last week in #openstack-ansible for our meeting no
issue. I wonder if it's a length of names thing or a channel setting.

Amy (spotz)

On Mon, Aug 13, 2018 at 4:25 PM, Eric Fried  wrote:

> Are you talking about the nastygram from "Sigyn" saying:
>
> "Your actions in # tripped automated anti-spam measures
> (nicks/hilight spam), but were ignored based on your time in channel;
> stop now, or automated action will still be taken. If you have any
> questions, please don't hesitate to contact a member of staff"
>
> I'm getting this too, and (despite the implication to the contrary) it
> sometimes cuts off my messages in an unpredictable spot.
>
> I'm contacting "a member of staff" to see if there's any way to get
> "whitelisted" for big messages. In the meantime, the only solution I'm
> aware of is to chop your pasteypaste up into smaller chunks, and wait a
> couple seconds between pastes.
>
> -efried
>
> On 08/13/2018 04:06 PM, Ben Nemec wrote:
> >
> >
> > On 08/08/2018 12:04 PM, Jay S Bryant wrote:
> >> Team,
> >>
> >> A reminder that we have our weekly Cinder meeting on Wednesdays at
> >> 16:00 UTC.  I bring this up as I can no longer send the courtesy pings
> >> without being kicked from IRC.  So, if you wish to join the meeting
> >> please add a reminder to your calendar of choice.
> >
> > Do you have any idea why you're being kicked?  I'm wondering how to
> > avoid getting into this situation with the Oslo pings.
> >
> > 
> __
> > OpenStack Development Mailing 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] [cinder] Reminder about the weekly Cinder meeting ...

[Eric Fried]

Are you talking about the nastygram from "Sigyn" saying:

"Your actions in # tripped automated anti-spam measures
(nicks/hilight spam), but were ignored based on your time in channel;
stop now, or automated action will still be taken. If you have any
questions, please don't hesitate to contact a member of staff"

I'm getting this too, and (despite the implication to the contrary) it
sometimes cuts off my messages in an unpredictable spot.

I'm contacting "a member of staff" to see if there's any way to get
"whitelisted" for big messages. In the meantime, the only solution I'm
aware of is to chop your pasteypaste up into smaller chunks, and wait a
couple seconds between pastes.

-efried

On 08/13/2018 04:06 PM, Ben Nemec wrote:
> 
> 
> On 08/08/2018 12:04 PM, Jay S Bryant wrote:
>> Team,
>>
>> A reminder that we have our weekly Cinder meeting on Wednesdays at
>> 16:00 UTC.  I bring this up as I can no longer send the courtesy pings
>> without being kicked from IRC.  So, if you wish to join the meeting
>> please add a reminder to your calendar of choice.
> 
> Do you have any idea why you're being kicked?  I'm wondering how to
> avoid getting into this situation with the Oslo pings.
> 
> __
> OpenStack Development Mailing 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] [requirements][release][docs] FFE for openstackdocstheme 1.21.2

[Matthew Thode]

On 18-08-13 20:28:23, Andreas Jaeger wrote:
> On 2018-08-13 19:16, Andreas Jaeger wrote:
> > On 2018-08-13 18:40, Petr Kovar wrote:
> > > Hi all,
> > > 
> > > This is a request for an FFE to release openstackdocstheme 1.21.2.
> > 
> > 
> > > This mostly fixes usability issues in rendering docs content, so we would
> > > like to update the theme across all project team docs on docs.o.o.
> > 
> > I suggest to release quickly a 1.21.3 with
> > https://review.openstack.org/#/c/585517/ - and use that one instead.
> 
> Release request:
> https://review.openstack.org/591485
> 

Would this be a upper-constraint only bump?

If so reqs acks it

-- 
Matthew Thode (prometheanfire)


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

Re: [openstack-dev] [cinder] Reminder about the weekly Cinder meeting ...

[Ben Nemec]

On 08/08/2018 12:04 PM, Jay S Bryant wrote:

Team,

A reminder that we have our weekly Cinder meeting on Wednesdays at 16:00 
UTC.  I bring this up as I can no longer send the courtesy pings without 
being kicked from IRC.  So, if you wish to join the meeting please add a 
reminder to your calendar of choice.


Do you have any idea why you're being kicked?  I'm wondering how to 
avoid getting into this situation with the Oslo pings.


__
OpenStack Development Mailing 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] barbican 7.0.0.0rc1 (rocky)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/barbican/

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

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

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

Release notes for barbican can be found at:

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




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

Re: [openstack-dev] [oslo][tooz][etcd] need help debugging tooz test failure

[Doug Hellmann]

Excerpts from Davanum Srinivas (dims)'s message of 2018-08-14 04:05:23 +0800:
> Jay, Doug,
> 
> We need to blacklist 0.2.2 and 0.2.3 (looking at changelog in)
> https://github.com/dims/etcd3-gateway/releases

Done in https://review.openstack.org/591517

Thanks,
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] [oslo][tooz][etcd] need help debugging tooz test failure

[Davanum Srinivas]

Jay, Doug,

We need to blacklist 0.2.2 and 0.2.3 (looking at changelog in)
https://github.com/dims/etcd3-gateway/releases

Thanks!
-- Dims

On Tue, Aug 14, 2018 at 4:03 AM Jay Pipes  wrote:

> On 08/13/2018 03:52 PM, Doug Hellmann wrote:
> > Excerpts from Jay Pipes's message of 2018-08-13 13:21:56 -0400:
> >> On 08/12/2018 04:11 PM, Doug Hellmann wrote:
> >>> The tooz tests on master and stable/rocky are failing with an error:
> >>>
> >>>   UnicodeDecodeError: 'utf8' codec can't decode byte 0xc4 in
> position 0:
> >>>   invalid continuation byte
> >>>
> >>> This is unrelated to the change, which is simply importing test job
> >>> settings or updating the .gitreview file. I need someone familiar with
> >>> the library to help debug the issue.
> >>>
> >>> Can we get a volunteer?
> >>
> >> Looking into it. Seems to be related to this upstream patch to
> >> python-etcd3gw:
> >>
> >>
> https://github.com/dims/etcd3-gateway/commit/224f40972b42c4ff16234c0e78ea765e3fe1af95
> >>
> >> Best,
> >> -jay
> >>
> >
> > Thanks, Jay!
> >
> > I see that Dims says he pushed a release. Is that something we need to
> > update in the constraints list, then?
>
> Yeah, likely. We'll need to blacklist the 0.2.3 release of etcd3-gateway
> library in the openstack/tooz requirements file.
>
> I think? :)
>
> -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
>


-- 
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] [oslo][tooz][etcd] need help debugging tooz test failure

[Jay Pipes]

On 08/13/2018 03:52 PM, Doug Hellmann wrote:

Excerpts from Jay Pipes's message of 2018-08-13 13:21:56 -0400:

On 08/12/2018 04:11 PM, Doug Hellmann wrote:

The tooz tests on master and stable/rocky are failing with an error:

  UnicodeDecodeError: 'utf8' codec can't decode byte 0xc4 in position 0:
  invalid continuation byte

This is unrelated to the change, which is simply importing test job
settings or updating the .gitreview file. I need someone familiar with
the library to help debug the issue.

Can we get a volunteer?


Looking into it. Seems to be related to this upstream patch to
python-etcd3gw:

https://github.com/dims/etcd3-gateway/commit/224f40972b42c4ff16234c0e78ea765e3fe1af95

Best,
-jay



Thanks, Jay!

I see that Dims says he pushed a release. Is that something we need to
update in the constraints list, then?


Yeah, likely. We'll need to blacklist the 0.2.3 release of etcd3-gateway 
library in the openstack/tooz requirements file.


I think? :)

-jay

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

Re: [openstack-dev] [oslo][tooz][etcd] need help debugging tooz test failure

[Doug Hellmann]

Excerpts from Davanum Srinivas (dims)'s message of 2018-08-14 03:50:54 +0800:
> Thanks Jay. Pushed out a 0.2.4 with a revert to the offending PR
> 
> On Tue, Aug 14, 2018 at 1:22 AM Jay Pipes  wrote:
> 
> > On 08/12/2018 04:11 PM, Doug Hellmann wrote:
> > > The tooz tests on master and stable/rocky are failing with an error:
> > >
> > >  UnicodeDecodeError: 'utf8' codec can't decode byte 0xc4 in position
> > 0:
> > >  invalid continuation byte
> > >
> > > This is unrelated to the change, which is simply importing test job
> > > settings or updating the .gitreview file. I need someone familiar with
> > > the library to help debug the issue.
> > >
> > > Can we get a volunteer?
> >
> > Looking into it. Seems to be related to this upstream patch to
> > python-etcd3gw:
> >
> >
> > https://github.com/dims/etcd3-gateway/commit/224f40972b42c4ff16234c0e78ea765e3fe1af95
> >
> > Best,
> > -jay
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> 

I filed the constraint update: https://review.openstack.org/591498

I also set the tooz patches to depend on that as a test:
https://review.openstack.org/588720

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] [oslo][tooz][etcd] need help debugging tooz test failure

[Doug Hellmann]

Excerpts from Jay Pipes's message of 2018-08-13 13:21:56 -0400:
> On 08/12/2018 04:11 PM, Doug Hellmann wrote:
> > The tooz tests on master and stable/rocky are failing with an error:
> > 
> >  UnicodeDecodeError: 'utf8' codec can't decode byte 0xc4 in position 0:
> >  invalid continuation byte
> > 
> > This is unrelated to the change, which is simply importing test job
> > settings or updating the .gitreview file. I need someone familiar with
> > the library to help debug the issue.
> > 
> > Can we get a volunteer?
> 
> Looking into it. Seems to be related to this upstream patch to 
> python-etcd3gw:
> 
> https://github.com/dims/etcd3-gateway/commit/224f40972b42c4ff16234c0e78ea765e3fe1af95
> 
> Best,
> -jay
> 

Thanks, Jay!

I see that Dims says he pushed a release. Is that something we need to
update in the constraints list, then?

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] [oslo][tooz][etcd] need help debugging tooz test failure

[Davanum Srinivas]

Thanks Jay. Pushed out a 0.2.4 with a revert to the offending PR

On Tue, Aug 14, 2018 at 1:22 AM Jay Pipes  wrote:

> On 08/12/2018 04:11 PM, Doug Hellmann wrote:
> > The tooz tests on master and stable/rocky are failing with an error:
> >
> >  UnicodeDecodeError: 'utf8' codec can't decode byte 0xc4 in position
> 0:
> >  invalid continuation byte
> >
> > This is unrelated to the change, which is simply importing test job
> > settings or updating the .gitreview file. I need someone familiar with
> > the library to help debug the issue.
> >
> > Can we get a volunteer?
>
> Looking into it. Seems to be related to this upstream patch to
> python-etcd3gw:
>
>
> https://github.com/dims/etcd3-gateway/commit/224f40972b42c4ff16234c0e78ea765e3fe1af95
>
> Best,
> -jay
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

[openstack-dev] [tripleo] Edge clouds and controlplane updates

[Giulio Fidente]

Hello,

I'd like to get some feedback regarding the remaining
work for the split controlplane spec implementation [1]

Specifically, while for some services like nova-compute it is not
necessary to update the controlplane nodes after an edge cloud is
deployed, for other services, like cinder (or glance, probably
others), it is necessary to do an update of the config files on the
controlplane when a new edge cloud is deployed.

In fact for services like cinder or glance, which are hosted in the
controlplane, we need to pull data from the edge clouds (for example
the newly deployed ceph cluster keyrings and fsid) to configure cinder
(or glance) with a new backend.

It looks like this demands for some architectural changes to solve the
following two:

- how do we trigger/drive updates of the controlplane nodes after the
edge cloud is deployed?

- how do we scale the controlplane parameters to accomodate for N
backends of the same type?

A very rough approach to the latter could be to use jinja to scale up
the CephClient service so that we can have multiple copies of it in the
controlplane.

Each instance of CephClient should provide the ceph config file and
keyring necessary for each cinder (or glance) backend.

Also note that Ceph is only a particular example but we'd need a similar
workflow for any backend type.

The etherpad for the PTG session [2] touches this, but it'd be good to
start this conversation before then.

1.
https://specs.openstack.org/openstack/tripleo-specs/specs/rocky/split-controlplane.html

2. https://etherpad.openstack.org/p/tripleo-ptg-queens-split-controlplane

-- 
Giulio Fidente
GPG KEY: 08D733BA

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

Re: [openstack-dev] [Openstack-operators] [nova] StarlingX diff analysis

[Chris Friesen]

On 08/07/2018 07:29 AM, Matt Riedemann wrote:

On 8/7/2018 1:10 AM, Flint WALRUS wrote:

I didn’t had time to check StarlingX code quality, how did you feel it while
you were doing your analysis?


I didn't dig into the test diffs themselves, but it was my impression that from
what I was poking around in the local git repo, there were several changes which
didn't have any test coverage.


Full disclosure, I'm on the StarlingX team.

Certainly some changes didn't have unit/functional test coverage, generally due 
to the perceived cost of writing useful tests.  (And when you don't have a lot 
of experience writing tests this becomes a self-fulfilling prophecy.)  On the 
other hand, we had fairly robust periodic integration testing including 
multi-node testing with physical hardware.



For the really big full stack changes (L3 CAT, CPU scaling and shared/pinned
CPUs on same host), toward the end I just started glossing over a lot of that
because it's so much code in so many places, so I can't really speak very well
to how it was written or how well it is tested (maybe WindRiver had a more
robust CI system running integration tests, I don't know).


We didn't have a per-commit CI system, though that's starting to change.  We do 
have a QA team running regression and targeted tests.



There were also some things which would have been caught in code review
upstream. For example, they ignore the "force" parameter for live migration so
that live migration requests always go through the scheduler. However, the
"force" parameter is only on newer microversions. Before that, if you specified
a host at all it would bypass the scheduler, but the change didn't take that
into account, so they still have gaps in some of the things they were trying to
essentially disable in the API.


Agreed, that's not up to upstream quality.  In this case we made some 
simplifying assumptions because our customers were expected to use the matching 
modified clients and to use the "current" microversion rather than explicitly 
specifying older microversions.


Chris


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

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

[Julia Kreger]

Greetings fellow ironicans!

As many of you might know an openstack/ironic-staging-drivers[1]
repository exists. What most might not know is that it was
intentionally created outside of ironic's governance[2].

At the time it was created ironic was moving towards removing drivers
that did not meet our third-party CI requirement[3] to be in-tree. The
repository was an attempt to give a home to what some might find
useful or where third party CI is impractical or cost-prohibitive and
thus could not be officially part of Ironic the service. There was
hope that drivers could land in ironic-staging-drivers and possibly
graduate to being moved in-tree with third-party CI. As our community
has evolved we've not stopped and revisited the questions.

With our most recent release over, I believe we need to ask ourselves
if we should consider moving ironic-staging-drivers into our
governance.

Over the last couple of releases several contributors have found
themselves trying to seek out two available reviewers to merge even
trivial fixes[4]. Due to the team being so small this was no easy
task. As a result, I'm wondering why not move the repository into
governance, grant ironic-core review privileges upon the repository,
and maintain the purpose and meaning of the repository. This would
also result in the repository's release becoming managed via the
release management process which is a plus.

We could then propose an actual graduation process and help alleviate
some of the issues where driver code is iterated upon for long periods
of time before landing. At the same time I can see at least one issue
which is if we were to do that, then we would also need to manage
removal through the same path.

I know there are concerns over responsibility in terms of code
ownership and quality, but I feel like we already hit such issues[5],
like those encountered when Dmitry removed classic drivers[6] from the
repository and also encountered issues just prior to the latest
release[7][8].

This topic has come up in passing at PTGs and most recently on IRC[9],
and I think we ought to discuss it during our next weekly meeting[10].
I've gone ahead and added an item to the agenda, but we can also
discuss via email.

-Julia

[1]: 
http://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/projects.yaml#n4571
[2]: 
http://git.openstack.org/cgit/openstack/ironic-staging-drivers/tree/README.rst#n16
[3]: 
https://specs.openstack.org/openstack/ironic-specs/specs/approved/third-party-ci.html
[4]: https://review.openstack.org/#/c/548943/
[5]: https://review.openstack.org/#/c/541916/
[6]: https://review.openstack.org/567902
[7]: https://review.openstack.org/590352
[8]: https://review.openstack.org/590401
[9]: 
http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-ironic.2018-08-09.log.html#t2018-08-09T11:55:27
[10]: https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting

__
OpenStack Development Mailing 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] [requirements][release][docs] FFE for openstackdocstheme 1.21.2

[Andreas Jaeger]

On 2018-08-13 19:16, Andreas Jaeger wrote:

On 2018-08-13 18:40, Petr Kovar wrote:

Hi all,

This is a request for an FFE to release openstackdocstheme 1.21.2.




This mostly fixes usability issues in rendering docs content, so we would
like to update the theme across all project team docs on docs.o.o.


I suggest to release quickly a 1.21.3 with 
https://review.openstack.org/#/c/585517/ - and use that one instead.


Release request:
https://review.openstack.org/591485

Andreas




See also the update constraint request at
https://review.openstack.org/#/c/591020/.


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] [PTL][TC] Stein Cycle Goals

[Sean McGinnis]

On Mon, Aug 13, 2018 at 04:50:40PM +, Fox, Kevin M wrote:
> Since the upgrade checking has not been written yet, now would be a good time 
> to unify them, so you upgrade check your openstack upgrade, not status check 
> nova, status check neutron, status check glance, status check cinder . ad 
> nauseam.
> 
> Thanks,
> Kevin
> 

That would be a good outcome of this. I think before we can have an overall
upgrade check, each service in use needs to have that mechanism in place to
perform their specific checks.

As long as the pattern is followed as $project-status check upgrade, then it
should be very feasible to write a higher level tool that iterates through all
services and runs the checks.


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

Re: [openstack-dev] [oslo][tooz][etcd] need help debugging tooz test failure

[Jay Pipes]

On 08/12/2018 04:11 PM, Doug Hellmann wrote:

The tooz tests on master and stable/rocky are failing with an error:

 UnicodeDecodeError: 'utf8' codec can't decode byte 0xc4 in position 0:
 invalid continuation byte

This is unrelated to the change, which is simply importing test job
settings or updating the .gitreview file. I need someone familiar with
the library to help debug the issue.

Can we get a volunteer?


Looking into it. Seems to be related to this upstream patch to 
python-etcd3gw:


https://github.com/dims/etcd3-gateway/commit/224f40972b42c4ff16234c0e78ea765e3fe1af95

Best,
-jay

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

Re: [openstack-dev] [requirements][release][docs] FFE for openstackdocstheme 1.21.2

[Andreas Jaeger]

On 2018-08-13 18:40, Petr Kovar wrote:

Hi all,

This is a request for an FFE to release openstackdocstheme 1.21.2.




This mostly fixes usability issues in rendering docs content, so we would
like to update the theme across all project team docs on docs.o.o.


I suggest to release quickly a 1.21.3 with 
https://review.openstack.org/#/c/585517/ - and use that one instead.



See also the update constraint request at
https://review.openstack.org/#/c/591020/.


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] [PTL][TC] Stein Cycle Goals

[Fox, Kevin M]

Since the upgrade checking has not been written yet, now would be a good time 
to unify them, so you upgrade check your openstack upgrade, not status check 
nova, status check neutron, status check glance, status check cinder . ad 
nauseam.

Thanks,
Kevin

From: Sean McGinnis [sean.mcgin...@gmx.com]
Sent: Monday, August 13, 2018 8:22 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [PTL][TC] Stein Cycle Goals

We now have two cycle goals accepted for the Stein cycle. I think both are very
beneficial goals to work towards, so personally I am very happy with where we
landed on this.

The two goals, with links to their full descriptions and nitty gritty details,
can be found here:

https://governance.openstack.org/tc/goals/stein/index.html

Goals
=
Here are some high level details on the goals.

Run under Python 3 by default (python3-first)
-
In Pike we had a goal for all projects to support Python 3.5. As a continuation
of that effort, and in preparation for the EOL of Python 2, we now want to look
at all of the ancillary things around projects and make sure that we are using
Python 3 everywhere except those jobs explicitly intended for testing Python 2
support.

This means all docs, linters, and other tools and utility jobs we use should be
run using Python 3.

https://governance.openstack.org/tc/goals/stein/python3-first.html

Thanks to Doug Hellmann, Nguyễn Trí Hải, Ma Lei, and Huang Zhiping for
championing this goal.

Support Pre Upgrade Checks (upgrade-checkers)
-
One of the hot topics we've been discussing for some time at Forum and PTG
events has been making upgrades better. To that end, we want to add tooling for
each service to provide an "upgrade checker" tool that can check for various
known issues so we can either give operators some assurance that they are ready
to upgrade, or to let them know if some step was overlooked that will need to
be done before attempting the upgrade.

This goal follows the Nova `nova-status upgrade check` command precendent to
make it a consistent capability for each service. The checks should look for
things like missing or changed configuration options, incompatible object
states, or other conditions that could lead to failures upgrading that project.

More details can be found in the goal:

https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html

Thanks to Matt Riedemann for championing this goal.

Schedule

We hope to have all projects complete this goal by the week of March 4, 2019:

https://releases.openstack.org/stein/schedule.html

This is the same week as the Stein-3 milestone, as well as Feature Freeze and
client lib freeze.

Future Goals

We welcome any ideas for future cycle goals. Ideally these should be things
that can actually be accomplished within one development cycle and would have a
positive, and hopefully visible, impact for users and operators.

Feel free to pitch any ideas here on the mailing list or drop by the
#openstack-tc channel at any point.

Thanks!

--
Sean (smcginnis)

__
OpenStack Development Mailing 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] [requirements][release][docs] FFE for openstackdocstheme 1.21.2

[Petr Kovar]

Hi all,

This is a request for an FFE to release openstackdocstheme 1.21.2.

This mostly fixes usability issues in rendering docs content, so we would
like to update the theme across all project team docs on docs.o.o. 

See also the update constraint request at
https://review.openstack.org/#/c/591020/.

Thanks,
pk

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

Re: [openstack-dev] [nova] Do we still want to lowercase metadata keys?

[Matthew Booth]

On Mon, 13 Aug 2018 at 16:56, Chris Friesen  wrote:
>
> On 08/13/2018 08:26 AM, Jay Pipes wrote:
> > On 08/13/2018 10:10 AM, Matthew Booth wrote:
>
> >> I suspect I've misunderstood, but I was arguing this is an anti-goal.
> >> There's no reason to do this if the db is working correctly, and it
> >> would violate the principal of least surprise in dbs with legacy
> >> datasets (being all current dbs). These values have always been mixed
> >> case, lets just leave them be and fix the db.
> >
> > Do you want case-insensitive keys or do you not want case-insensitive keys?
> >
> > It seems to me that people complain that MySQL is case-insensitive by 
> > default
> > but actually *like* the concept that a metadata key of "abc" should be 
> > "equal
> > to" a metadata key of "ABC".
>
> How do we behave on PostgreSQL?  (I realize it's unsupported, but it still has
> users.)  It's case-sensitive by default, do we override that?
>
> Personally, I've worked on case-sensitive systems long enough that I'd 
> actually
> be surprised if "abc" matched "ABC". :)

To the best of my knowledge, the hypothetical PostgreSQL db works
exactly how you, me, and pretty much any developer would expect :)
Honestly, though, SQLite is probably more interesting as it's at least
used for testing. SQLite's default collation is binary, which is
obviously case sensitive as you'd expect.

As a developer I'm heavily biased in favour of implementing the
simplest fix with the simplest and most obvious behaviour, which is to
change the default collation to do what everybody expected it did in
the first place (which is what Rajesh's patch does). As Jay points
out, though, I do concede that those pesky users may be impacted by
fixing this bug if they've come to rely on accidental buggy behaviour.

The question really comes down to how we can determine what the user
impact is for each solution. And here I'm talking about all the
various forms of metadata, assuming that whatever solution we picked
we'd apply to all. So:

- What API calls allow a user to query a thing by metadata key?

I believe these API calls would be the only things affected by fixing
the collation of metadata keys. If we know what they are we can ask
what the impact of changing the behaviour would be. Setting metadata
keys isn't subject to regression, as this was previously broken.

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

Phone: +442070094448 (UK)

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

Re: [openstack-dev] [nova] Do we still want to lowercase metadata keys?

[Jay Pipes]

On 08/13/2018 11:56 AM, Chris Friesen wrote:

On 08/13/2018 08:26 AM, Jay Pipes wrote:

On 08/13/2018 10:10 AM, Matthew Booth wrote:



I suspect I've misunderstood, but I was arguing this is an anti-goal.
There's no reason to do this if the db is working correctly, and it
would violate the principal of least surprise in dbs with legacy
datasets (being all current dbs). These values have always been mixed
case, lets just leave them be and fix the db.


Do you want case-insensitive keys or do you not want case-insensitive 
keys?


It seems to me that people complain that MySQL is case-insensitive by 
default
but actually *like* the concept that a metadata key of "abc" should be 
"equal

to" a metadata key of "ABC".


How do we behave on PostgreSQL?  (I realize it's unsupported, but it 
still has users.)  It's case-sensitive by default, do we override that?


Personally, I've worked on case-sensitive systems long enough that I'd 
actually be surprised if "abc" matched "ABC". :)


You have worked with case-insensitive systems for as long or longer, 
maybe without realizing it: All URLs are case-insensitive.


If a user types in http://google.com they go to the same place as 
http://Google.com because DNS is case-insensitive [1] and has been since 
its beginning. Users -- of HTTP APIs in particular -- have tended to 
become accustomed to case-insensitivity in their HTTP API calls.


This case is no different, IMHO.

Best,
-jay

[1] https://tools.ietf.org/html/rfc4343#section-4

__
OpenStack Development Mailing 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] CI job running functional against a mysql DB

[Clark Boylan]

On Mon, Aug 13, 2018, at 1:50 AM, Matthew Booth wrote:
> I was reviewing https://review.openstack.org/#/c/504885/ . The change
> looks good to me and I believe the test included exercises the root
> cause of the problem. However, I'd like to be certain that the test
> has been executed against MySQL rather than, eg, SQLite.
> 
> Zuul has voted +1 on the change. Can anybody tell me if any of those
> jobs ran the included functional test against a MySQL DB?,

Both functional jobs configured a MySQL and PostgeSQL database for use by the 
test suite [0][1]. Looking at Nova's tests, the migration tests 
(nova/tests/functional/db/api/test_migrations.py and 
nova/tests/unit/db/test_migrations.py) use the oslo.db ModelsMigrationsSync 
class which should use these real databases. I'm not finding evidence that any 
other tests classes will use the real databases.

[0] 
http://logs.openstack.org/85/504885/9/check/nova-tox-functional/fa3327b/job-output.txt.gz#_2018-08-13_10_32_09_943951
[1] 
http://logs.openstack.org/85/504885/9/check/nova-tox-functional-py35/1f04657/job-output.txt.gz#_2018-08-13_10_31_00_289802

Hope this helps,
Clark

__
OpenStack Development Mailing 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] Do we still want to lowercase metadata keys?

[Chris Friesen]

On 08/13/2018 08:26 AM, Jay Pipes wrote:

On 08/13/2018 10:10 AM, Matthew Booth wrote:



I suspect I've misunderstood, but I was arguing this is an anti-goal.
There's no reason to do this if the db is working correctly, and it
would violate the principal of least surprise in dbs with legacy
datasets (being all current dbs). These values have always been mixed
case, lets just leave them be and fix the db.


Do you want case-insensitive keys or do you not want case-insensitive keys?

It seems to me that people complain that MySQL is case-insensitive by default
but actually *like* the concept that a metadata key of "abc" should be "equal
to" a metadata key of "ABC".


How do we behave on PostgreSQL?  (I realize it's unsupported, but it still has 
users.)  It's case-sensitive by default, do we override that?


Personally, I've worked on case-sensitive systems long enough that I'd actually 
be surprised if "abc" matched "ABC". :)


Chris

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

Re: [openstack-dev] [Openstack-sigs] [self-healing][heat][vitrage][mistral] Self-Healing with Vitrage, Heat, and Mistral

[Adam Spiers]

Hi Rico,

Firstly sorry for the slow reply!  I am finally catching up on my
backlog.

Rico Lin  wrote:

Dear all

Back to Vancouver Summit, Ifat brings out the idea of integrating Heat,
Vitrage, and Mistral to bring better self-healing scenario.
For previous works, There already works cross Heat, Mistral, and Zaqar for
self-healing [1].
And there is works cross Vitrage, and Mistral [2].
Now we plan to start working on integrating two works (as much as it
can/should be) and to make sure the scenario works and keep it working.
The integrated scenario flow will look something like this:
An existing monitor detect host/network failure and send an alarm to
Vitrage -> Vitrage deduces that the instance is down (based on the topology
and based on Vitrage templates [2]) -> Vitrage triggers Mistral to fix the
instance -> application is recovered
We created an Etherpad [3] to document all discussion/feedbacks/plans (and
will add more detail through time)
Also, create a story in self-healing SIG to track all task.

The current plans are:

  - A spec for Vitrage resources in Heat [5]
  - Create Vitrage resources in Heat
  - Write Heat Template and Vitrage Template for this scenario
  - A tempest task for above scenario
  - Add periodic job for this scenario (with above task). The best place
  to host this job (IMO) is under self-healing SIG


This is great!  It's a perfect example of the kind of cross-project
collaboration which I always hoped the SIG would host.  And I really
love the idea of Heat making it even easier to deploy Vitrage
templates automatically.

Originally I thought that this would be too hard and that the SIG
would initially need to focus on documenting how to manually deploy
self-healing configurations, but supporting automation early on is a
very nice bonus :-)  So I expect that implementing this can make lives
a lot easier for operators (and users) who need self-healing :-)

And yes, I agree that the SIG would be the best place to host this
job.


To create a periodic job for self-healing sig means we might also need a
place to manage those self-healing tempest test. For this scenario, I think
it will make sense if we use heat-tempest-plugin to store that scenario
test (since it will wrap as a Heat template) or use vitrage-tempest-plugin
(since most of the test scenario are actually already there).


Sounds good.


Not sure what will happen if we create a new tempest plugin for
self-healing and no manager for it.


Sorry for my ignorance - do you mean manager objects here[0], or some
other kind of manager?

[0] https://docs.openstack.org/tempest/latest/write_tests.html#manager-objects


We still got some uncertainty to clear during working on it, but the big
picture looks like all will works(if we doing all well on above tasks).
Please provide your feedback or question if you have any.
We do needs feedbacks and reviews on patches or any works.
If you're interested in this, please join us (we need users/ops/devs!).

[1] https://github.com/openstack/heat-templates/tree/master/hot/autohealing
[2]
https://github.com/openstack/self-healing-sig/blob/master/specs/vitrage-mistral-integration.rst
[3] https://etherpad.openstack.org/p/self-healing-with-vitrage-mistral-heat
[4] https://storyboard.openstack.org/#!/story/2002684
[5] https://review.openstack.org/#/c/578786


Thanks a lot for creating the story in Storyboard - this is really
helpful :-)

I'll try to help with reviews etc. and maybe even testing if I can
find some extra time for it over the next few months.  I can also try
to help "market" this initiative in the community by promoting
awareness and trying to get operators more involved.

Thanks again!  Excited about the direction this is heading in :-)

Adam

__
OpenStack Development Mailing 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] about live-resize down the instance

[Chris Friesen]

On 08/13/2018 02:07 AM, Rambo wrote:

Hi,all

   I find it is important that live-resize the instance in production
environment,especially live downsize the disk.And we have talked it many
years.But I don't know why the bp[1] didn't approved.Can you tell me more about
this ?Thank you very much.

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



It's been reviewed a number of times...I thought it was going to get approved 
for Rocky, but I think it didn't quite make it in...you'd have to ask the nova 
cores why not.


It should be noted though that the above live-resize spec explicitly did not 
cover resizing smaller, only larger.


Chris

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

[openstack-dev] openstack-cyborg 1.0.0.0rc1 (rocky)

[no-reply]

Hello everyone,

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

https://tarballs.openstack.org/cyborg/

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

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


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

Release notes for openstack-cyborg can be found at:

https://docs.openstack.org/releasenotes/openstack-cyborg/

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

https://bugs.launchpad.net/openstack-cyborg

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


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

[openstack-dev] [goal][python3] week 1 update: here we go!

[Doug Hellmann]

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

I intend to send a summary message like this roughly weekly to
report progress on the Zuul setting migrations, because that portion
of the goal needs to be coordinated.

I will also be watching for changes to
https://wiki.openstack.org/wiki/Python3 and will try to report on
progress with functional or unit test jobs as teams log the information
there.

This email is a bit longer than I hope they will usually be, because
it is the first and has some planning information.

== The Plan ==

The completion criteria from the goal are:

1. The Zuul settings to attach jobs have been moved from the
   openstack-infra/project-config repository into each project
   repository.
2. Documentation build and publish jobs use python 3.
3. Release notes build and publish jobs use python 3.
4. Source code linter jobs (pep8, pylint, bandit, etc.) should use
   python 3.
5. Release artifact build and publish jobs use python 3 and publish to
   PyPI.
6. There are functional test jobs running under python 3.
7. The wiki tracking page is up to date for the project.
8. Projects are running python 3.6 unit test jobs.

The goal champions will start by preparing the patches for steps
1-5, and 8. That will give project teams more time to focus on
reviewing and on completing steps 6 and 7, which will need the
expertise of someone on the team.

PLEASE do not write the Zuul configuration migration patches
yourselves.  The rules for which things need to move ended up a bit
complicated, it's all automated, and we do not want to start them
before all of the stable/rocky branches are created for a team
(otherwise we risk misconfiguring the stable branch). Sit tight
and be ready to review the patches when we send them your way.

We are waiting to start most teams until the final releases for
Rocky are done, but we're going to start some of the teams less
affected by that deadline early (like Oslo, Infra, and possibly
Documentation).  Project teams should be prepared to assist if there
are any issues or questions about jobs with branch-specifiers.

While the job migration is under way, changes to project-config for
the team's repositories will be locked. As soon as the patches to
import the job settings are landed for *all* of the repositories
owned by a team we will update the project-config repo to remove
those settings and then the job settings for the team will be
unfrozen again. So, please review zuul configuration changes quickly,
but carefully. :-)

Step 6 involves adding more test jobs and may also require code
changes or tox settings updates, so that work will be left to the
project team.

Step 7, updating the wiki tracking page to indicate what level of
testing is being done and where any gaps might be, is the responsibility
of the project team.

Step 8 starts with a simple patch to add the unit test jobs, which
will come as part of the rest of the zuul migration patches. If the
tests do not immediately work, We will need the project teams to
fix things up in the code or tox.ini files so the tests pass.

== Tracking Progress ==

Because teams potentially need to do something in each repository,
I have created separate stories for each team in storyboard, with
one task per repo. Those stories are all tagged with 'goal-python3-first'
and appear on the tracking board at
https://storyboard.openstack.org/#!/board/104 The tasks on these
stories are for teams to track their work. Feel free to add more
tasks or otherwise elaborate on the stories as needed. If you add
more stories, please use the same tag so they will show up on the
board.

Because not all teams have migrated to storyboard, some of the tasks
are associated with the openstack/governance repo instead of a team
repository. If your team wants to track work using a different tool,
please come back and update the storyboard tasks as part of completing
your goal so anyone tracking progress can find it all in one place.
PTLs should update the stories based on the instructions in the
goal procedures
(https://governance.openstack.org/tc/goals/index.html#team-acknowledgment-of-goals
). If you include the story and task information in commit messages,
some of that updating will happen for free (this is one of the
reasons we're using storyboard).

The goal champions will use a separate story, with one task per
team, to track the work we are going to do with the zuul configuration
migration. See https://storyboard.openstack.org/#!/story/2002586
for details.

== Ongoing work ==

We are making good progress with migrating the zuul settings for
the Oslo team as a final test of the full process. We will start
with other regular teams after the final release candidates for
Rocky are done (after 24 Aug), and the cycle-trailing projects after
their release deadline has passed (after 31 Aug).

== Next Steps ==

If your team is interested in being one of 

Re: [openstack-dev] [nova] Do we still want to lowercase metadata keys?

[Matthew Booth]

On Mon, 13 Aug 2018 at 15:27, Jay Pipes  wrote:
> Do you want case-insensitive keys or do you not want case-insensitive keys?
>
> It seems to me that people complain that MySQL is case-insensitive by
> default but actually *like* the concept that a metadata key of "abc"
> should be "equal to" a metadata key of "ABC".
>
> In other words, it seems to me that users actually expect that:
>
>  > nova aggregate-create agg1
>  > nova aggregate-set-metadata agg1 abc=1
>  > nova aggregate-set-metadata agg1 ABC=2
>
> should result in the original "abc" metadata item getting its value set
> to "2".

Incidentally, this particular example won't work today: it will just
throw an error. I believe the same would apply to user metadata on an
instance. IOW this particular example doesn't regress if you fix the
bug. The regression would be anything user-facing which queries by
metadata key. What does that?

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

Phone: +442070094448 (UK)

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

Re: [openstack-dev] [nova] Do we still want to lowercase metadata keys?

[Matthew Booth]

On Mon, 13 Aug 2018 at 15:27, Jay Pipes  wrote:
>
> On 08/13/2018 10:10 AM, Matthew Booth wrote:
> > On Mon, 13 Aug 2018 at 14:05, Jay Pipes  wrote:
> >>
> >> On 08/13/2018 06:06 AM, Matthew Booth wrote:
> >>> Thanks mriedem for answering my previous question, and also pointing
> >>> out the related previous spec around just forcing all metadata to be
> >>> lowercase:
> >>>
> >>> (Spec: approved in Newton) https://review.openstack.org/#/c/311529/
> >>> (Online migration: not merged, abandoned)
> >>> https://review.openstack.org/#/c/329737/
> >>>
> >>> There are other code patches, but the above is representative. What I
> >>> had read was the original bug:
> >>>
> >>> https://bugs.launchpad.net/nova/+bug/1538011
> >>>
> >>> The tl;dr is that the default collation used by MySQL results in a bug
> >>> when creating 2 metadata keys which differ only in case. The proposal
> >>> was obviously to simply make all metadata keys lower case. However, as
> >>> melwitt pointed out in the bug at the time that's a potentially user
> >>> hostile change. After some lost IRC discussion it seems that folks
> >>> believed at the time that to fix this properly would seriously
> >>> compromise the performance of these queries. The agreed way forward
> >>> was to allow existing keys to keep their case, but force new keys to
> >>> be lower case (so I wonder how the above online migration came
> >>> about?).
> >>>
> >>> Anyway, as Rajesh's patch shows, it's actually very easy just to fix
> >>> the MySQL misconfiguration:
> >>>
> >>> https://review.openstack.org/#/c/504885/
> >>>
> >>> So my question is, given that the previous series remains potentially
> >>> user hostile, the fix isn't as complex as previously believed, and it
> >>> doesn't involve a performance penalty, are there any other reasons why
> >>> we might want to resurrect it rather than just go with Rajesh's patch?
> >>> Or should we ask Rajesh to expand his patch into a series covering
> >>> other metadata?
> >>
> >> Keep in mind this patch is only related to *aggregate* metadata, AFAICT.
> >
> > Right, but the original bug pointed out that the same problem applies
> > equally to a bunch of different metadata stores. I haven't verified,
> > but the provenance was good ;) There would have to be other patches
> > for the other metadata stores.
>
> Yes, it is quite unfortunate that OpenStack has about 15 different ways
> of storing metadata key/value information.
>
> >>
> >> Any patch series that tries to "fix" this issue needs to include all of
> >> the following:
> >>
> >> * input automatically lower-cased [1]
> >> * inline (note: not online, inline) data migration inside the
> >> InstanceMeta object's _from_db_object() method for existing
> >> non-lowercased keys
> >
> > I suspect I've misunderstood, but I was arguing this is an anti-goal.
> > There's no reason to do this if the db is working correctly, and it
> > would violate the principal of least surprise in dbs with legacy
> > datasets (being all current dbs). These values have always been mixed
> > case, lets just leave them be and fix the db.
>
> Do you want case-insensitive keys or do you not want case-insensitive keys?
>
> It seems to me that people complain that MySQL is case-insensitive by
> default but actually *like* the concept that a metadata key of "abc"
> should be "equal to" a metadata key of "ABC".
>
> In other words, it seems to me that users actually expect that:
>
>  > nova aggregate-create agg1
>  > nova aggregate-set-metadata agg1 abc=1
>  > nova aggregate-set-metadata agg1 ABC=2
>
> should result in the original "abc" metadata item getting its value set
> to "2".
>
> If that isn't the case -- and I have a very different impression of what
> users *actually* expect from the CLI/UI -- then let me know.

I don't know what users want, tbh, I was simply coming from the POV of
not breaking the current behaviour. Although I think you're pointing
out that either solution breaks the current behaviour:

1. You lower case everything. This breaks users who query user
metadata and don't expect keys to be modified.

2. You fix the case sensitivity. This breaks users who add 'Foo' and
now expect to query 'foo'.

You're saying that although (2) is an artifact of a bug, there could
equally be people relying on it.

Eurgh. Yeah, that sucks.

Objectively though, I think I still like Rajesh's patch better because:

* It's vastly simpler to implement correctly and verifiably, and
therefore also less prone to future bugs.
* It's how it was originally intended to work.
* It's simpler to document.

Of these, the first is by far the most persuasive.

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

Phone: +442070094448 (UK)

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

[openstack-dev] [PTL][TC] Stein Cycle Goals

[Sean McGinnis]

We now have two cycle goals accepted for the Stein cycle. I think both are very
beneficial goals to work towards, so personally I am very happy with where we
landed on this.

The two goals, with links to their full descriptions and nitty gritty details,
can be found here:

https://governance.openstack.org/tc/goals/stein/index.html

Goals
=
Here are some high level details on the goals.

Run under Python 3 by default (python3-first)
-
In Pike we had a goal for all projects to support Python 3.5. As a continuation
of that effort, and in preparation for the EOL of Python 2, we now want to look
at all of the ancillary things around projects and make sure that we are using
Python 3 everywhere except those jobs explicitly intended for testing Python 2
support.

This means all docs, linters, and other tools and utility jobs we use should be
run using Python 3.

https://governance.openstack.org/tc/goals/stein/python3-first.html

Thanks to Doug Hellmann, Nguyễn Trí Hải, Ma Lei, and Huang Zhiping for
championing this goal.

Support Pre Upgrade Checks (upgrade-checkers)
-
One of the hot topics we've been discussing for some time at Forum and PTG
events has been making upgrades better. To that end, we want to add tooling for
each service to provide an "upgrade checker" tool that can check for various
known issues so we can either give operators some assurance that they are ready
to upgrade, or to let them know if some step was overlooked that will need to
be done before attempting the upgrade.

This goal follows the Nova `nova-status upgrade check` command precendent to
make it a consistent capability for each service. The checks should look for
things like missing or changed configuration options, incompatible object
states, or other conditions that could lead to failures upgrading that project.

More details can be found in the goal:

https://governance.openstack.org/tc/goals/stein/upgrade-checkers.html

Thanks to Matt Riedemann for championing this goal.

Schedule

We hope to have all projects complete this goal by the week of March 4, 2019:

https://releases.openstack.org/stein/schedule.html

This is the same week as the Stein-3 milestone, as well as Feature Freeze and
client lib freeze.

Future Goals

We welcome any ideas for future cycle goals. Ideally these should be things
that can actually be accomplished within one development cycle and would have a
positive, and hopefully visible, impact for users and operators.

Feel free to pitch any ideas here on the mailing list or drop by the
#openstack-tc channel at any point.

Thanks!

--
Sean (smcginnis)

__
OpenStack Development Mailing 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] [releases][rocky][tempest-plugins][ptl] Reminder to tag the Tempest plugins for Rocky release

[Doug Hellmann]

Excerpts from Ghanshyam Mann's message of 2018-08-13 23:12:51 +0900:
> 
> 
> 
>   On Mon, 13 Aug 2018 23:01:33 +0900 Doug Hellmann 
>  wrote  
>  > Excerpts from Dmitry Tantsur's message of 2018-08-13 15:51:56 +0200:
>  > > On 08/13/2018 03:46 PM, Doug Hellmann wrote:
>  > > > Excerpts from Dmitry Tantsur's message of 2018-08-13 15:35:23 +0200:
>  > > >> Hi,
>  > > >>
>  > > >> The plugins are branchless and should stay so. Let us not dive into 
> this madness
>  > > >> again please.
>  > > > 
>  > > > You are correct that we do not want to branch, because we want the
>  > > > same tests running against all branches of services in our CI system
>  > > > to help us avoid (or at least recognize) API-breaking changes across
>  > > > release boundaries.
>  > > 
>  > > Okay, thank you for clarification. I stand corrected and apologize if my 
>  > > frustration was expressed too loudly or harshly :)
>  > 
>  > Not at all. This is new territory, and we made a decision somewhat
>  > quickly, so I am not surprised that we need to do a little more work to
>  > communicate the results.
>  > 
>  > > 
>  > > > 
>  > > > We *do* need to tag so that people consuming the plugins to certify
>  > > > their clouds know which version of the plugin works with the version
>  > > > of the software they are installing. Newer versions of plugins may
>  > > > rely on features or changes in newer versions of tempest, or other
>  > > > dependencies, that are not available in an environment that is
>  > > > running an older cloud.
>  > > 
>  > > ++
>  > > 
>  > > > 
>  > > > We will apply those tags in the series-specific deliverable files in
>  > > > openstack/releases so that the version numbers appear together on
>  > > > releases.openstack.org on the relevant release page so that users
>  > > > looking for the "rocky" version of a plugin can find it easily.
>  > > 
>  > > Okay, this makes sense now.
>  > 
>  > Good.
>  > 
>  > Now, we just need someone to figure out where to write all of that down
>  > so we don't have to have the same conversation next cycle. :-)
> 
> +1, this is very imp. I was discussing the same with amotoki today on QA 
> channel. I have added a TODO for me to write the 1. "How Plugins should cover 
> the stable branch testing with branchless repo" now i can add 2nd TODO also 
> 2. "Release model & tagging clarification of Tempest  Plugins". I do not know 
> the best common place to add those doc but as start i can write those in 
> Tempest doc and later we can refer/move the same on Plugins side too. 
> 
> I have added this TODO on qa stein ptg etherpad also for reminder/feedback- 
> https://etherpad.openstack.org/p/qa-stein-ptg

We have a reference page for deliverable types in the releases
repository
(https://releases.openstack.org/reference/deliverable_types.html). That
could be a place to talk about the tagging and branching expectations.
It doesn't cover tempest-plugins at all, yet.

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

[openstack-dev] [tc] Technical Committee update for 13 Aug

[Doug Hellmann]

This is the weekly summary of work being done by the Technical
Committee members. The full list of active items is managed in the
wiki: https://wiki.openstack.org/wiki/Technical_Committee_Tracker

We also track TC objectives for the cycle using StoryBoard at:
https://storyboard.openstack.org/#!/project/923

== Recent Activity ==

Project updates:

- add tripleo ansible repo: https://review.openstack.org/#/c/583416/
- add openstack-chef repo: https://review.openstack.org/#/c/585473/

Other changes:

- Stein goal for upgrade check automation: 
https://review.openstack.org/#/c/585491/
- confirm the Stein election results: https://review.openstack.org/#/c/589691/
- confirm Darisz Krol PTL for Trove: https://review.openstack.org/#/c/588510/
- confirm Dirk Mueller PTL for rpm-packaging project: 
https://review.openstack.org/#/c/588617/
- remove expired extra ATCs: https://review.openstack.org/#/c/588586/

== Leaderless teams after PTL elections ==

As part of the discussion of how to deal with re-appointments of
PTLs where no governance patch would be needed and hence we would
have no place to vote, Chris has proposed a schema change that will
let us handle the changes in the governance repo instead of updating
the election repository after the election is over.

- https://review.openstack.org/#/c/590790/

The RefStack team is being dissolved and the repositories moved to
the interop working group.

- https://review.openstack.org/#/c/590179/

Claudiu Belu volunteered to serve as PTL for the Winstackers team
again for Stein.

- https://review.openstack.org/#/c/590386/

We now have volunteers to serve as PTL for both Freezer and
Searchlight, so we need to decide what action to take with those
teams.

- removing both from the rocky release: 
https://review.openstack.org/#/c/588605/ 
- removing freezer from governance: 
http://lists.openstack.org/pipermail/openstack-dev/2018-August/132873.html and 
https://review.openstack.org/#/c/588645/
- removing searchlight from governance: 
http://lists.openstack.org/pipermail/openstack-dev/2018-August/132874.html and 
https://review.openstack.org/#/c/588644/
- Trinh Nguyen has volunteered to be PTL for Searchlight: 
https://review.openstack.org/#/c/590601/
- Changcai Geng has volunteered to be PTL for Freezer: 
https://review.openstack.org/#/c/590071/

== Ongoing Discussions ==

Ian has updated his proposals to change the project testing interface
to support PDF generation and documentation translation. These need
to be reviewed by folks familiar with the tools and processes.

- https://review.openstack.org/#/c/572559/
- https://review.openstack.org/#/c/588110/

The TC is planning 2 meetings during the week of the PTG. The
proposed agendas are up for comment.

- https://etherpad.openstack.org/p/tc-stein-ptg

== TC member actions/focus/discussions for the coming week(s) ==

The PTG is approaching quickly. Please complete any remaining team
health checks.

Besides the items listed above as ongoing discussions, we have
several other governance reviews open without sufficient votes to
be approved. Please review.

- https://review.openstack.org/#/q/project:openstack/governance+is:open

== Contacting the TC ==

The Technical Committee uses a series of weekly "office hour" time
slots for synchronous communication. We hope that by having several
such times scheduled, we will have more opportunities to engage
with members of the community from different timezones.

Office hour times in #openstack-tc:

- 09:00 UTC on Tuesdays
- 01:00 UTC on Wednesdays
- 15:00 UTC on Thursdays

If you have something you would like the TC to discuss, you can add
it to our office hour conversation starter etherpad at:
https://etherpad.openstack.org/p/tc-office-hour-conversation-starters

Many of us also run IRC bouncers which stay in #openstack-tc most
of the time, so please do not feel that you need to wait for an
office hour time to pose a question or offer a suggestion. You can
use the string "tc-members" to alert the members to your question.

You will find channel logs with past conversations at
http://eavesdrop.openstack.org/irclogs/%23openstack-tc/

If you expect your topic to require significant discussion or to
need input from members of the community other than the TC, please
start a mailing list discussion on openstack-dev at lists.openstack.org
and use the subject tag "[tc]" to bring it to the attention of TC
members.



__
OpenStack Development Mailing 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] User Committee Election Nominations Reminder

[Amy Marrich]

Just wanted to remind everyone that the nomination period for the User
Committee elections are open until August 17, 05:59 UTC. If you are an AUC
and thinking about running what's stopping you? If you know of someone who
would make a great committee member nominate them! Help make a difference
for Operators, Users and the Community!

Thanks,

Amy Marrich (spotz)
User Committee
__
OpenStack Development Mailing 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] Do we still want to lowercase metadata keys?

[Jay Pipes]

On 08/13/2018 10:10 AM, Matthew Booth wrote:

On Mon, 13 Aug 2018 at 14:05, Jay Pipes  wrote:


On 08/13/2018 06:06 AM, Matthew Booth wrote:

Thanks mriedem for answering my previous question, and also pointing
out the related previous spec around just forcing all metadata to be
lowercase:

(Spec: approved in Newton) https://review.openstack.org/#/c/311529/
(Online migration: not merged, abandoned)
https://review.openstack.org/#/c/329737/

There are other code patches, but the above is representative. What I
had read was the original bug:

https://bugs.launchpad.net/nova/+bug/1538011

The tl;dr is that the default collation used by MySQL results in a bug
when creating 2 metadata keys which differ only in case. The proposal
was obviously to simply make all metadata keys lower case. However, as
melwitt pointed out in the bug at the time that's a potentially user
hostile change. After some lost IRC discussion it seems that folks
believed at the time that to fix this properly would seriously
compromise the performance of these queries. The agreed way forward
was to allow existing keys to keep their case, but force new keys to
be lower case (so I wonder how the above online migration came
about?).

Anyway, as Rajesh's patch shows, it's actually very easy just to fix
the MySQL misconfiguration:

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

So my question is, given that the previous series remains potentially
user hostile, the fix isn't as complex as previously believed, and it
doesn't involve a performance penalty, are there any other reasons why
we might want to resurrect it rather than just go with Rajesh's patch?
Or should we ask Rajesh to expand his patch into a series covering
other metadata?


Keep in mind this patch is only related to *aggregate* metadata, AFAICT.


Right, but the original bug pointed out that the same problem applies
equally to a bunch of different metadata stores. I haven't verified,
but the provenance was good ;) There would have to be other patches
for the other metadata stores.


Yes, it is quite unfortunate that OpenStack has about 15 different ways 
of storing metadata key/value information.




Any patch series that tries to "fix" this issue needs to include all of
the following:

* input automatically lower-cased [1]
* inline (note: not online, inline) data migration inside the
InstanceMeta object's _from_db_object() method for existing
non-lowercased keys


I suspect I've misunderstood, but I was arguing this is an anti-goal.
There's no reason to do this if the db is working correctly, and it
would violate the principal of least surprise in dbs with legacy
datasets (being all current dbs). These values have always been mixed
case, lets just leave them be and fix the db.


Do you want case-insensitive keys or do you not want case-insensitive keys?

It seems to me that people complain that MySQL is case-insensitive by 
default but actually *like* the concept that a metadata key of "abc" 
should be "equal to" a metadata key of "ABC".


In other words, it seems to me that users actually expect that:

> nova aggregate-create agg1
> nova aggregate-set-metadata agg1 abc=1
> nova aggregate-set-metadata agg1 ABC=2

should result in the original "abc" metadata item getting its value set 
to "2".


If that isn't the case -- and I have a very different impression of what 
users *actually* expect from the CLI/UI -- then let me know.


-jay

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

Re: [openstack-dev] [Openstack-operators] Speaker Selection Process: OpenStack Summit Berlin

[Matt Joyce]

CFP work is hard as hell.  Much respect to the review panel members.  It's
a thankless difficult job.

So, in lieu of being thankless,  THANK YOU

-Matt

On Mon, Aug 13, 2018 at 9:59 AM, Allison Price 
wrote:

> Hi everyone,
>
> One quick clarification. The speakers will be announced on* August 14 at
> 1300 UTC / 4:00 AM PDT.*
>
> Cheers,
> Allison
>
>
> On Aug 13, 2018, at 8:53 AM, Jimmy McArthur  wrote:
>
> Greetings!
>
> The speakers for the OpenStack Summit Berlin will be announced August 14,
> at 4:00 AM UTC. Ahead of that, we want to take this opportunity to thank
> our Programming Committee!  They have once again taken time out of their
> busy schedules to help create another round of outstanding content for the
> OpenStack Summit.
>
> The OpenStack Foundation relies on the community-nominated Programming
> Committee, along with your Community Votes to select the content of the
> summit.  If you're curious about this process, you can read more about it
> here
> 
> where we have also listed the Programming Committee members.
>
> If you'd like to nominate yourself or someone you know for the OpenStack
> Summit Denver Programming Committee, you can do so here:
> https://openstackfoundation.formstack.com/forms/openstackdenver2019_
> programmingcommitteenom
>
> Thanks a bunch and we look forward to seeing everyone in Berlin!
>
> Cheers,
> Jimmy
>
>
>
>
> *
> *
> __
> OpenStack Development Mailing 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-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
__
OpenStack Development Mailing 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] [releases][rocky][tempest-plugins][ptl] Reminder to tag the Tempest plugins for Rocky release

[Ghanshyam Mann]

  On Mon, 13 Aug 2018 23:01:33 +0900 Doug Hellmann  
wrote  
 > Excerpts from Dmitry Tantsur's message of 2018-08-13 15:51:56 +0200:
 > > On 08/13/2018 03:46 PM, Doug Hellmann wrote:
 > > > Excerpts from Dmitry Tantsur's message of 2018-08-13 15:35:23 +0200:
 > > >> Hi,
 > > >>
 > > >> The plugins are branchless and should stay so. Let us not dive into 
 > > >> this madness
 > > >> again please.
 > > > 
 > > > You are correct that we do not want to branch, because we want the
 > > > same tests running against all branches of services in our CI system
 > > > to help us avoid (or at least recognize) API-breaking changes across
 > > > release boundaries.
 > > 
 > > Okay, thank you for clarification. I stand corrected and apologize if my 
 > > frustration was expressed too loudly or harshly :)
 > 
 > Not at all. This is new territory, and we made a decision somewhat
 > quickly, so I am not surprised that we need to do a little more work to
 > communicate the results.
 > 
 > > 
 > > > 
 > > > We *do* need to tag so that people consuming the plugins to certify
 > > > their clouds know which version of the plugin works with the version
 > > > of the software they are installing. Newer versions of plugins may
 > > > rely on features or changes in newer versions of tempest, or other
 > > > dependencies, that are not available in an environment that is
 > > > running an older cloud.
 > > 
 > > ++
 > > 
 > > > 
 > > > We will apply those tags in the series-specific deliverable files in
 > > > openstack/releases so that the version numbers appear together on
 > > > releases.openstack.org on the relevant release page so that users
 > > > looking for the "rocky" version of a plugin can find it easily.
 > > 
 > > Okay, this makes sense now.
 > 
 > Good.
 > 
 > Now, we just need someone to figure out where to write all of that down
 > so we don't have to have the same conversation next cycle. :-)

+1, this is very imp. I was discussing the same with amotoki today on QA 
channel. I have added a TODO for me to write the 1. "How Plugins should cover 
the stable branch testing with branchless repo" now i can add 2nd TODO also 2. 
"Release model & tagging clarification of Tempest  Plugins". I do not know the 
best common place to add those doc but as start i can write those in Tempest 
doc and later we can refer/move the same on Plugins side too. 

I have added this TODO on qa stein ptg etherpad also for reminder/feedback- 
https://etherpad.openstack.org/p/qa-stein-ptg

-gmann

 > 
 > Doug
 > 
 > > 
 > > > 
 > > > Doug
 > > > 
 > > >>
 > > >> Dmitry
 > > >>
 > > >> On 08/12/2018 10:41 AM, Ghanshyam Mann wrote:
 > > >>> Hi All,
 > > >>>
 > > >>> Rocky release is few weeks away and we all agreed to release Tempest 
 > > >>> plugin with cycle-with-intermediary. Detail discussion are in ML [1] 
 > > >>> in case you missed.
 > > >>>
 > > >>> This is reminder to tag your project tempest plugins for Rocky 
 > > >>> release. You should be able to find your plugins deliverable file 
 > > >>> under rocky folder in releases repo[3].  You can refer 
 > > >>> cinder-tempest-plugin release as example.
 > > >>>
 > > >>> Feel free to reach to release/QA team for any help/query.
 > > >>
 > > >> Please make up your mind. Please. Please. Please.
 > > >>
 > > >>>
 > > >>> [1] 
 > > >>> http://lists.openstack.org/pipermail/openstack-dev/2018-June/131810.html
 > > >>> [2] https://review.openstack.org/#/c/590025/
 > > >>> [3] 
 > > >>> https://github.com/openstack/releases/tree/master/deliverables/rocky
 > > >>>
 > > >>> -gmann
 > > >>>
 > > >>>
 > > >>>
 > > >>> __
 > > >>> OpenStack Development Mailing 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] Do we still want to lowercase metadata keys?

[Matthew Booth]

On Mon, 13 Aug 2018 at 14:05, Jay Pipes  wrote:
>
> On 08/13/2018 06:06 AM, Matthew Booth wrote:
> > Thanks mriedem for answering my previous question, and also pointing
> > out the related previous spec around just forcing all metadata to be
> > lowercase:
> >
> > (Spec: approved in Newton) https://review.openstack.org/#/c/311529/
> > (Online migration: not merged, abandoned)
> > https://review.openstack.org/#/c/329737/
> >
> > There are other code patches, but the above is representative. What I
> > had read was the original bug:
> >
> > https://bugs.launchpad.net/nova/+bug/1538011
> >
> > The tl;dr is that the default collation used by MySQL results in a bug
> > when creating 2 metadata keys which differ only in case. The proposal
> > was obviously to simply make all metadata keys lower case. However, as
> > melwitt pointed out in the bug at the time that's a potentially user
> > hostile change. After some lost IRC discussion it seems that folks
> > believed at the time that to fix this properly would seriously
> > compromise the performance of these queries. The agreed way forward
> > was to allow existing keys to keep their case, but force new keys to
> > be lower case (so I wonder how the above online migration came
> > about?).
> >
> > Anyway, as Rajesh's patch shows, it's actually very easy just to fix
> > the MySQL misconfiguration:
> >
> > https://review.openstack.org/#/c/504885/
> >
> > So my question is, given that the previous series remains potentially
> > user hostile, the fix isn't as complex as previously believed, and it
> > doesn't involve a performance penalty, are there any other reasons why
> > we might want to resurrect it rather than just go with Rajesh's patch?
> > Or should we ask Rajesh to expand his patch into a series covering
> > other metadata?
>
> Keep in mind this patch is only related to *aggregate* metadata, AFAICT.

Right, but the original bug pointed out that the same problem applies
equally to a bunch of different metadata stores. I haven't verified,
but the provenance was good ;) There would have to be other patches
for the other metadata stores.

>
> Any patch series that tries to "fix" this issue needs to include all of
> the following:
>
> * input automatically lower-cased [1]
> * inline (note: not online, inline) data migration inside the
> InstanceMeta object's _from_db_object() method for existing
> non-lowercased keys

I suspect I've misunderstood, but I was arguing this is an anti-goal.
There's no reason to do this if the db is working correctly, and it
would violate the principal of least surprise in dbs with legacy
datasets (being all current dbs). These values have always been mixed
case, lets just leave them be and fix the db.

> * change the collation of the aggregate_metadata.key column (note: this
> will require an entire rebuild of the table, since this column is part
> of a unique constraint [3]

Rajesh's patch changes the collation of the table, which I would
assume applies to its columns? I assume this is going to be a
moderately expensive, but one-off, operation similar in cost to adding
a new unique constraint.

> * online data migration for migrating non-lowercased keys to their
> lowercased counterpars (essentially doing `UPDATE key = LOWER(key) WHERE
> LOWER(key) != key` once the collation has been changed)

> None of the above touches the API layer. I suppose some might argue that
> the REST API should be microversion-bumped since the expected behaviour
> of the API will change (data will be transparently changed in one
> version of the API and not another). I don't personally think that's
> something I would require a microversion for, but who knows what others
> may say.

Again, I was considering this is an anti-goal. As I understand,
Rajesh's patch removes the requirement to make this api change. What
did I miss?

Thanks,

Matt

>
> Best,
> -jay
>
> [1]
> https://github.com/openstack/nova/blob/16f89fd093217d22530570e8277b561ea79f46ff/nova/objects/aggregate.py#L295
> and
> https://github.com/openstack/nova/blob/16f89fd093217d22530570e8277b561ea79f46ff/nova/objects/aggregate.py#L331
> and
> https://github.com/openstack/nova/blob/16f89fd093217d22530570e8277b561ea79f46ff/nova/objects/aggregate.py#L356
>
>
> [2]
> https://github.com/openstack/nova/blob/16f89fd093217d22530570e8277b561ea79f46ff/nova/objects/aggregate.py#L248
>
> [3]
> https://github.com/openstack/nova/blob/16f89fd093217d22530570e8277b561ea79f46ff/nova/db/sqlalchemy/api_models.py#L64
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Matthew Booth
Red Hat OpenStack Engineer, Compute DFG

Phone: +442070094448 (UK)

__
OpenStack Development Mailing List (not for usage questi

Re: [openstack-dev] [releases][rocky][tempest-plugins][ptl] Reminder to tag the Tempest plugins for Rocky release

[Ghanshyam Mann]

  On Mon, 13 Aug 2018 22:46:42 +0900 Doug Hellmann  
wrote  
 > Excerpts from Dmitry Tantsur's message of 2018-08-13 15:35:23 +0200:
 > > Hi,
 > > 
 > > The plugins are branchless and should stay so. Let us not dive into this 
 > > madness 
 > > again please.
 > 
 > You are correct that we do not want to branch, because we want the
 > same tests running against all branches of services in our CI system
 > to help us avoid (or at least recognize) API-breaking changes across
 > release boundaries.
 > 
 > We *do* need to tag so that people consuming the plugins to certify
 > their clouds know which version of the plugin works with the version
 > of the software they are installing. Newer versions of plugins may
 > rely on features or changes in newer versions of tempest, or other
 > dependencies, that are not available in an environment that is
 > running an older cloud.
 > 
 > We will apply those tags in the series-specific deliverable files in
 > openstack/releases so that the version numbers appear together on
 > releases.openstack.org on the relevant release page so that users
 > looking for the "rocky" version of a plugin can find it easily.

Thanks Doug for clarifying it again :). Details can be found on original ML[1] 
also about goal behind tagging the plugins. Next item pending on branchless 
testing is to setup the Plugin CI jobs for stable branches also like Tempest 
does. That is one item for QA team to help plugins in stein. 

[1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131810.html

-gmann
> 
 > Doug
 > 
 > > 
 > > Dmitry
 > > 
 > > On 08/12/2018 10:41 AM, Ghanshyam Mann wrote:
 > > > Hi All,
 > > > 
 > > > Rocky release is few weeks away and we all agreed to release Tempest 
 > > > plugin with cycle-with-intermediary. Detail discussion are in ML [1] in 
 > > > case you missed.
 > > > 
 > > > This is reminder to tag your project tempest plugins for Rocky release. 
 > > > You should be able to find your plugins deliverable file under rocky 
 > > > folder in releases repo[3].  You can refer cinder-tempest-plugin release 
 > > > as example.
 > > > 
 > > > Feel free to reach to release/QA team for any help/query.
 > > 
 > > Please make up your mind. Please. Please. Please.
 > > 
 > > > 
 > > > [1] 
 > > > http://lists.openstack.org/pipermail/openstack-dev/2018-June/131810.html
 > > > [2] https://review.openstack.org/#/c/590025/
 > > > [3] https://github.com/openstack/releases/tree/master/deliverables/rocky
 > > > 
 > > > -gmann
 > > > 
 > > > 
 > > > 
 > > > __
 > > > OpenStack Development Mailing 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] [releases][rocky][tempest-plugins][ptl] Reminder to tag the Tempest plugins for Rocky release

[Doug Hellmann]

Excerpts from Dmitry Tantsur's message of 2018-08-13 15:51:56 +0200:
> On 08/13/2018 03:46 PM, Doug Hellmann wrote:
> > Excerpts from Dmitry Tantsur's message of 2018-08-13 15:35:23 +0200:
> >> Hi,
> >>
> >> The plugins are branchless and should stay so. Let us not dive into this 
> >> madness
> >> again please.
> > 
> > You are correct that we do not want to branch, because we want the
> > same tests running against all branches of services in our CI system
> > to help us avoid (or at least recognize) API-breaking changes across
> > release boundaries.
> 
> Okay, thank you for clarification. I stand corrected and apologize if my 
> frustration was expressed too loudly or harshly :)

Not at all. This is new territory, and we made a decision somewhat
quickly, so I am not surprised that we need to do a little more work to
communicate the results.

> 
> > 
> > We *do* need to tag so that people consuming the plugins to certify
> > their clouds know which version of the plugin works with the version
> > of the software they are installing. Newer versions of plugins may
> > rely on features or changes in newer versions of tempest, or other
> > dependencies, that are not available in an environment that is
> > running an older cloud.
> 
> ++
> 
> > 
> > We will apply those tags in the series-specific deliverable files in
> > openstack/releases so that the version numbers appear together on
> > releases.openstack.org on the relevant release page so that users
> > looking for the "rocky" version of a plugin can find it easily.
> 
> Okay, this makes sense now.

Good.

Now, we just need someone to figure out where to write all of that down
so we don't have to have the same conversation next cycle. :-)

Doug

> 
> > 
> > Doug
> > 
> >>
> >> Dmitry
> >>
> >> On 08/12/2018 10:41 AM, Ghanshyam Mann wrote:
> >>> Hi All,
> >>>
> >>> Rocky release is few weeks away and we all agreed to release Tempest 
> >>> plugin with cycle-with-intermediary. Detail discussion are in ML [1] in 
> >>> case you missed.
> >>>
> >>> This is reminder to tag your project tempest plugins for Rocky release. 
> >>> You should be able to find your plugins deliverable file under rocky 
> >>> folder in releases repo[3].  You can refer cinder-tempest-plugin release 
> >>> as example.
> >>>
> >>> Feel free to reach to release/QA team for any help/query.
> >>
> >> Please make up your mind. Please. Please. Please.
> >>
> >>>
> >>> [1] 
> >>> http://lists.openstack.org/pipermail/openstack-dev/2018-June/131810.html
> >>> [2] https://review.openstack.org/#/c/590025/
> >>> [3] https://github.com/openstack/releases/tree/master/deliverables/rocky
> >>>
> >>> -gmann
> >>>
> >>>
> >>>
> >>> __
> >>> OpenStack Development Mailing 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] [releases][rocky][tempest-plugins][ptl] Reminder to tag the Tempest plugins for Rocky release

[Doug Hellmann]

Excerpts from Jim Rollenhagen's message of 2018-08-13 09:50:34 -0400:
> // jim
> 
> On Mon, Aug 13, 2018 at 9:46 AM, Doug Hellmann 
> wrote:
> 
> > Excerpts from Dmitry Tantsur's message of 2018-08-13 15:35:23 +0200:
> > > Hi,
> > >
> > > The plugins are branchless and should stay so. Let us not dive into this
> > madness
> > > again please.
> >
> > You are correct that we do not want to branch, because we want the
> > same tests running against all branches of services in our CI system
> > to help us avoid (or at least recognize) API-breaking changes across
> > release boundaries.
> >
> > We *do* need to tag so that people consuming the plugins to certify
> > their clouds know which version of the plugin works with the version
> > of the software they are installing. Newer versions of plugins may
> > rely on features or changes in newer versions of tempest, or other
> > dependencies, that are not available in an environment that is
> > running an older cloud.
> >
> > We will apply those tags in the series-specific deliverable files in
> > openstack/releases so that the version numbers appear together on
> > releases.openstack.org on the relevant release page so that users
> > looking for the "rocky" version of a plugin can find it easily.
> >
> 
> Thanks Doug. My confusion was around the cycle-with-intermediary model,
> which I thought implied a stable branch. Tagging at end of cycle seems
> fine to me. :)
> 
> // jim

Normally cycle-with-intermediary would imply a branch, but it's really
focused more around the releases than the branching. There's a separate
flag that most deliverables don't need to use that controls the
branching policy, and in this case we treat these repos as branchless.

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] Speaker Selection Process: OpenStack Summit Berlin

[Allison Price]

Hi everyone, 

One quick clarification. The speakers will be announced on August 14 at 1300 
UTC / 4:00 AM PDT.

Cheers,
Allison


> On Aug 13, 2018, at 8:53 AM, Jimmy McArthur  wrote:
> 
> Greetings!
> 
> The speakers for the OpenStack Summit Berlin will be announced August 14, at 
> 4:00 AM UTC. Ahead of that, we want to take this opportunity to thank our 
> Programming Committee!  They have once again taken time out of their busy 
> schedules to help create another round of outstanding content for the 
> OpenStack Summit.  
> 
> The OpenStack Foundation relies on the community-nominated Programming 
> Committee, along with your Community Votes to select the content of the 
> summit.  If you're curious about this process, you can read more about it 
> here 
> 
>  where we have also listed the Programming Committee members.  
> 
> If you'd like to nominate yourself or someone you know for the OpenStack 
> Summit Denver Programming Committee, you can do so here: 
> https://openstackfoundation.formstack.com/forms/openstackdenver2019_programmingcommitteenom
>  
> 
> 
> Thanks a bunch and we look forward to seeing everyone in Berlin!
> 
> Cheers,
> Jimmy
> 
> 
> 
> 
>  
> __
> OpenStack Development Mailing 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] [releases][rocky][tempest-plugins][ptl] Reminder to tag the Tempest plugins for Rocky release

[Ghanshyam Mann]

  On Mon, 13 Aug 2018 22:35:23 +0900 Dmitry Tantsur  
wrote  
 > Hi,
 > 
 > The plugins are branchless and should stay so. Let us not dive into this 
 > madness 
 > again please.
 > 
 > Dmitry
 > 
 > On 08/12/2018 10:41 AM, Ghanshyam Mann wrote:
 > > Hi All,
 > > 
 > > Rocky release is few weeks away and we all agreed to release Tempest 
 > > plugin with cycle-with-intermediary. Detail discussion are in ML [1] in 
 > > case you missed.
 > > 
 > > This is reminder to tag your project tempest plugins for Rocky release. 
 > > You should be able to find your plugins deliverable file under rocky 
 > > folder in releases repo[3].  You can refer cinder-tempest-plugin release 
 > > as example.
 > > 
 > > Feel free to reach to release/QA team for any help/query.
 > 
 > Please make up your mind. Please. Please. Please.

Not sure why it is being understood as to cut the branch for plugins. This 
thread is just to remind plugins owner to tag the plugins for Rocky release.  
'cycle-with-intermediary' does not need to be cut the branch always, for 
plugins and tempest it is just to release a tag for current OpenStack release. 

-gmann

 > 
 > > 
 > > [1] 
 > > http://lists.openstack.org/pipermail/openstack-dev/2018-June/131810.html
 > > [2] https://review.openstack.org/#/c/590025/
 > > [3] https://github.com/openstack/releases/tree/master/deliverables/rocky
 > > 
 > > -gmann
 > > 
 > > 
 > > 
 > > __
 > > OpenStack Development Mailing 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] [barbican][ara][helm][tempest] Removal of fedora-27 nodes

[Paul Belanger]

On Thu, Aug 02, 2018 at 08:01:46PM -0400, Paul Belanger wrote:
> Greetings,
> 
> We've had fedora-28 nodes online for some time in openstack-infra, I'd like to
> finish the migration process and remove fedora-27 images.
> 
> Please take a moment to review and approve the following patches[1]. We'll be
> using the fedora-latest nodeset now, which make is a little easier for
> openstack-infra to migrate to newer versions of fedora.  Next time around, 
> we'll
> send out an email to the ML once fedora-29 is online to give projects some 
> time
> to test before we make the change.
> 
> Thanks
> - Paul
> 
> [1] https://review.openstack.org/#/q/topic:fedora-latest
> 
Thanks for the approval of the patches above, today we are blocked by the
following backport for barbican[2]. If we can land this today, we can proceed
with the removal from nodepool.

Thanks
- Paul

[2] https://review.openstack.org/590420/

__
OpenStack Development Mailing 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] Speaker Selection Process: OpenStack Summit Berlin

[Jimmy McArthur]

Greetings!

The speakers for the OpenStack Summit Berlin will be announced August 
14, at 4:00 AM UTC. Ahead of that, we want to take this opportunity to 
thank our Programming Committee!  They have once again taken time out of 
their busy schedules to help create another round of outstanding content 
for the OpenStack Summit.


The OpenStack Foundation relies on the community-nominated Programming 
Committee, along with your Community Votes to select the content of the 
summit.  If you're curious about this process, you can read more about 
it here 
 
where we have also listed the Programming Committee members.


If you'd like to nominate yourself or someone you know for the OpenStack 
Summit Denver Programming Committee, you can do so here: *

*https://openstackfoundation.formstack.com/forms/openstackdenver2019_programmingcommitteenom

Thanks a bunch and we look forward to seeing everyone in Berlin!

Cheers,
Jimmy
*



* 

__
OpenStack Development Mailing 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] [releases][rocky][tempest-plugins][ptl] Reminder to tag the Tempest plugins for Rocky release

[Dmitry Tantsur]

On 08/13/2018 03:46 PM, Doug Hellmann wrote:

Excerpts from Dmitry Tantsur's message of 2018-08-13 15:35:23 +0200:

Hi,

The plugins are branchless and should stay so. Let us not dive into this madness
again please.


You are correct that we do not want to branch, because we want the
same tests running against all branches of services in our CI system
to help us avoid (or at least recognize) API-breaking changes across
release boundaries.


Okay, thank you for clarification. I stand corrected and apologize if my 
frustration was expressed too loudly or harshly :)




We *do* need to tag so that people consuming the plugins to certify
their clouds know which version of the plugin works with the version
of the software they are installing. Newer versions of plugins may
rely on features or changes in newer versions of tempest, or other
dependencies, that are not available in an environment that is
running an older cloud.


++



We will apply those tags in the series-specific deliverable files in
openstack/releases so that the version numbers appear together on
releases.openstack.org on the relevant release page so that users
looking for the "rocky" version of a plugin can find it easily.


Okay, this makes sense now.



Doug



Dmitry

On 08/12/2018 10:41 AM, Ghanshyam Mann wrote:

Hi All,

Rocky release is few weeks away and we all agreed to release Tempest plugin 
with cycle-with-intermediary. Detail discussion are in ML [1] in case you 
missed.

This is reminder to tag your project tempest plugins for Rocky release. You 
should be able to find your plugins deliverable file under rocky folder in 
releases repo[3].  You can refer cinder-tempest-plugin release as example.

Feel free to reach to release/QA team for any help/query.


Please make up your mind. Please. Please. Please.



[1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131810.html
[2] https://review.openstack.org/#/c/590025/
[3] https://github.com/openstack/releases/tree/master/deliverables/rocky

-gmann



__
OpenStack Development Mailing 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] [releases][rocky][tempest-plugins][ptl] Reminder to tag the Tempest plugins for Rocky release

[Jim Rollenhagen]

// jim

On Mon, Aug 13, 2018 at 9:46 AM, Doug Hellmann 
wrote:

> Excerpts from Dmitry Tantsur's message of 2018-08-13 15:35:23 +0200:
> > Hi,
> >
> > The plugins are branchless and should stay so. Let us not dive into this
> madness
> > again please.
>
> You are correct that we do not want to branch, because we want the
> same tests running against all branches of services in our CI system
> to help us avoid (or at least recognize) API-breaking changes across
> release boundaries.
>
> We *do* need to tag so that people consuming the plugins to certify
> their clouds know which version of the plugin works with the version
> of the software they are installing. Newer versions of plugins may
> rely on features or changes in newer versions of tempest, or other
> dependencies, that are not available in an environment that is
> running an older cloud.
>
> We will apply those tags in the series-specific deliverable files in
> openstack/releases so that the version numbers appear together on
> releases.openstack.org on the relevant release page so that users
> looking for the "rocky" version of a plugin can find it easily.
>

Thanks Doug. My confusion was around the cycle-with-intermediary model,
which I thought implied a stable branch. Tagging at end of cycle seems
fine to me. :)

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

Re: [openstack-dev] [releases][rocky][tempest-plugins][ptl] Reminder to tag the Tempest plugins for Rocky release

[Doug Hellmann]

Excerpts from Dmitry Tantsur's message of 2018-08-13 15:35:23 +0200:
> Hi,
> 
> The plugins are branchless and should stay so. Let us not dive into this 
> madness 
> again please.

You are correct that we do not want to branch, because we want the
same tests running against all branches of services in our CI system
to help us avoid (or at least recognize) API-breaking changes across
release boundaries.

We *do* need to tag so that people consuming the plugins to certify
their clouds know which version of the plugin works with the version
of the software they are installing. Newer versions of plugins may
rely on features or changes in newer versions of tempest, or other
dependencies, that are not available in an environment that is
running an older cloud.

We will apply those tags in the series-specific deliverable files in
openstack/releases so that the version numbers appear together on
releases.openstack.org on the relevant release page so that users
looking for the "rocky" version of a plugin can find it easily.

Doug

> 
> Dmitry
> 
> On 08/12/2018 10:41 AM, Ghanshyam Mann wrote:
> > Hi All,
> > 
> > Rocky release is few weeks away and we all agreed to release Tempest plugin 
> > with cycle-with-intermediary. Detail discussion are in ML [1] in case you 
> > missed.
> > 
> > This is reminder to tag your project tempest plugins for Rocky release. You 
> > should be able to find your plugins deliverable file under rocky folder in 
> > releases repo[3].  You can refer cinder-tempest-plugin release as example.
> > 
> > Feel free to reach to release/QA team for any help/query.
> 
> Please make up your mind. Please. Please. Please.
> 
> > 
> > [1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131810.html
> > [2] https://review.openstack.org/#/c/590025/
> > [3] https://github.com/openstack/releases/tree/master/deliverables/rocky
> > 
> > -gmann
> > 
> > 
> > 
> > __
> > OpenStack Development Mailing 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] [releases][rocky][tempest-plugins][ptl] Reminder to tag the Tempest plugins for Rocky release

[Dmitry Tantsur]

Hi,

The plugins are branchless and should stay so. Let us not dive into this madness 
again please.


Dmitry

On 08/12/2018 10:41 AM, Ghanshyam Mann wrote:

Hi All,

Rocky release is few weeks away and we all agreed to release Tempest plugin 
with cycle-with-intermediary. Detail discussion are in ML [1] in case you 
missed.

This is reminder to tag your project tempest plugins for Rocky release. You 
should be able to find your plugins deliverable file under rocky folder in 
releases repo[3].  You can refer cinder-tempest-plugin release as example.

Feel free to reach to release/QA team for any help/query.


Please make up your mind. Please. Please. Please.



[1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131810.html
[2] https://review.openstack.org/#/c/590025/
[3] https://github.com/openstack/releases/tree/master/deliverables/rocky

-gmann



__
OpenStack Development Mailing 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] [Openstack-operators][nova] deployment question consultation

[Rambo]

Hi,all
   I have some questions about deploy the large scale openstack cloud.Such 
as 
   1.Only in one region situation,what will happen in the cloud as 
expansion of cluster size?Then how solve it?If have the limit physical node 
number under the one region situation?How many nodes would be the best in one 
regione?
   2.When to use cellV2 is most suitable in cloud?
   3.How to shorten the time of batch creation of instance?
   Can you tell me more about these combined with own practice? Would you 
give me some methods to learn it?Such as the website,blog and so on. Thank you 
very much!Looking forward to hearing from you.
















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

Re: [openstack-dev] [Openstack-operators][nova]about live-resize down the instance

[Claudiu Belu]

Hi,

That's quite an old spec. :)

It has quite a bit of history, and the general nova core opinions were "No, 
we're probably not going to do that" in the beginning, to "We should probably 
add that, if people are asking for it" during the last OpenStack PTG. It even 
had 2x +2s and ~11 +1s at one point.

I'll repropose the blueprint again for Stein and rebase everything, if people 
want it. Implementation-wise, it's pretty much done, last time I was still 
doing some functional and unit tests for it. I had a tempest test for it too. I 
had some issues regarding notifications, but gibi helped me sort them out 
(thanks!).

As far as functionality goes, I'm afraid that at the moment we're only going to 
add live-resize to a larger flavor (live-upsizing). There are a few concerns 
regarding live-downsizing, especially when it comes to the hypevisor support 
for something like this (not all of them supports this). Additionally, when it 
comes to live-downsizing the disk, AFAIK, there's also a data loss concern 
associated with it, if the disk was not freed and / or if the partition table 
wasn't shrunk beforehandm, etc. Additionally, some nova drivers don't support 
downsizing the disks at all, not even cold resize.

There are a lot of discussions and debates on the spec you've linked, and you 
can also read the arguments regarding the question you've asked too.

tl;dr version. During the last PTG, we've agreed to "approve" the blueprint 
with only live-upsizing the instance in-place as the first iteration of the 
feature, which any new additions to be discussed afterwards.

Best regards,

Claudiu Belu



From: Rambo [li...@unitedstack.com]
Sent: Monday, August 13, 2018 2:36 PM
To: OpenStack Developmen
Subject: [openstack-dev] [Openstack-operators][nova]about live-resize down the 
instance

Hi,all

  I find it is important that live-resize the instance in production 
environment,especially live downsize the disk.And we have talked it many 
years.But I don't know why the bp[1] didn't approved.Can you tell me more about 
this ?Thank you very much.

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








Best Regards
Rambo
__
OpenStack Development Mailing 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] Do we still want to lowercase metadata keys?

[Jay Pipes]

On 08/13/2018 06:06 AM, Matthew Booth wrote:

Thanks mriedem for answering my previous question, and also pointing
out the related previous spec around just forcing all metadata to be
lowercase:

(Spec: approved in Newton) https://review.openstack.org/#/c/311529/
(Online migration: not merged, abandoned)
https://review.openstack.org/#/c/329737/

There are other code patches, but the above is representative. What I
had read was the original bug:

https://bugs.launchpad.net/nova/+bug/1538011

The tl;dr is that the default collation used by MySQL results in a bug
when creating 2 metadata keys which differ only in case. The proposal
was obviously to simply make all metadata keys lower case. However, as
melwitt pointed out in the bug at the time that's a potentially user
hostile change. After some lost IRC discussion it seems that folks
believed at the time that to fix this properly would seriously
compromise the performance of these queries. The agreed way forward
was to allow existing keys to keep their case, but force new keys to
be lower case (so I wonder how the above online migration came
about?).

Anyway, as Rajesh's patch shows, it's actually very easy just to fix
the MySQL misconfiguration:

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

So my question is, given that the previous series remains potentially
user hostile, the fix isn't as complex as previously believed, and it
doesn't involve a performance penalty, are there any other reasons why
we might want to resurrect it rather than just go with Rajesh's patch?
Or should we ask Rajesh to expand his patch into a series covering
other metadata?


Keep in mind this patch is only related to *aggregate* metadata, AFAICT.

Any patch series that tries to "fix" this issue needs to include all of 
the following:


* input automatically lower-cased [1]
* inline (note: not online, inline) data migration inside the 
InstanceMeta object's _from_db_object() method for existing 
non-lowercased keys
* change the collation of the aggregate_metadata.key column (note: this 
will require an entire rebuild of the table, since this column is part 
of a unique constraint [3]
* online data migration for migrating non-lowercased keys to their 
lowercased counterpars (essentially doing `UPDATE key = LOWER(key) WHERE 
LOWER(key) != key` once the collation has been changed)


None of the above touches the API layer. I suppose some might argue that 
the REST API should be microversion-bumped since the expected behaviour 
of the API will change (data will be transparently changed in one 
version of the API and not another). I don't personally think that's 
something I would require a microversion for, but who knows what others 
may say.


Best,
-jay

[1] 
https://github.com/openstack/nova/blob/16f89fd093217d22530570e8277b561ea79f46ff/nova/objects/aggregate.py#L295 
and 
https://github.com/openstack/nova/blob/16f89fd093217d22530570e8277b561ea79f46ff/nova/objects/aggregate.py#L331 
and 
https://github.com/openstack/nova/blob/16f89fd093217d22530570e8277b561ea79f46ff/nova/objects/aggregate.py#L356 



[2] 
https://github.com/openstack/nova/blob/16f89fd093217d22530570e8277b561ea79f46ff/nova/objects/aggregate.py#L248


[3] 
https://github.com/openstack/nova/blob/16f89fd093217d22530570e8277b561ea79f46ff/nova/db/sqlalchemy/api_models.py#L64


__
OpenStack Development Mailing 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] [sahara] Sahara PTG Etherpad

[Telles Nobrega]

Hi folks,

I have started working on the planning etherpad for the Stein PTG[1].

Please review it and add more topics so we can review and select what we
can discuss in Denver.

Thanks all,

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

TELLES NOBREGA

SOFTWARE ENGINEER

Red Hat Brasil  

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

tenob...@redhat.com

TRIED. TESTED. TRUSTED. 
 Red Hat é reconhecida entre as melhores empresas para trabalhar no Brasil
pelo Great Place to Work.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Openstack-operators][nova]about live-resize down the instance

[Rambo]

Hi,all


  I find it is important that live-resize the instance in production 
environment,especially live downsize the disk.And we have talked it many 
years.But I don't know why the bp[1] didn't approved.Can you tell me more about 
this ?Thank you very much.


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
















Best Regards
Rambo__
OpenStack Development Mailing 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] Pycharm license

[Swapnil Kulkarni]

On Mon 13 Aug, 2018, 15:41 Gary Kotton,  wrote:

> Hi,
>
> I understand that the community has an option to get licenses. Anyone have
> any information regarding this.
>
> Thanks
>
> Gary
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Hi Gary,

I can give you one. Please follow https://wiki.openstack.org/wiki/Pycharm

Best Regards,
Swapnil


>
__
OpenStack Development Mailing 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] Pycharm license

[Gary Kotton]

Hi,
I understand that the community has an option to get licenses. Anyone have any 
information regarding this.
Thanks
Gary
__
OpenStack Development Mailing 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] Do we still want to lowercase metadata keys?

[Matthew Booth]

Thanks mriedem for answering my previous question, and also pointing
out the related previous spec around just forcing all metadata to be
lowercase:

(Spec: approved in Newton) https://review.openstack.org/#/c/311529/
(Online migration: not merged, abandoned)
https://review.openstack.org/#/c/329737/

There are other code patches, but the above is representative. What I
had read was the original bug:

https://bugs.launchpad.net/nova/+bug/1538011

The tl;dr is that the default collation used by MySQL results in a bug
when creating 2 metadata keys which differ only in case. The proposal
was obviously to simply make all metadata keys lower case. However, as
melwitt pointed out in the bug at the time that's a potentially user
hostile change. After some lost IRC discussion it seems that folks
believed at the time that to fix this properly would seriously
compromise the performance of these queries. The agreed way forward
was to allow existing keys to keep their case, but force new keys to
be lower case (so I wonder how the above online migration came
about?).

Anyway, as Rajesh's patch shows, it's actually very easy just to fix
the MySQL misconfiguration:

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

So my question is, given that the previous series remains potentially
user hostile, the fix isn't as complex as previously believed, and it
doesn't involve a performance penalty, are there any other reasons why
we might want to resurrect it rather than just go with Rajesh's patch?
Or should we ask Rajesh to expand his patch into a series covering
other metadata?

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

Phone: +442070094448 (UK)

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

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

[Alberto Planas Dominguez]

Dear rpm-packaging team,

I was lucky to help doing reviews for the rpm-packaging OpenStack
project for the last couple of release cycles. I learned a lot during
this time.

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.

Also, a big thank to the team for the provided help during this time.

Saludos!

-- 
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
Maxfeldstraße 5, 90409 Nürnberg, Germany


__
OpenStack Development Mailing 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 CI meeting on 14.08 cancelled

[Slawomir Kaplonski]

Hi,

As few of Neutron core reviewers are not available this week, Tuesday’s CI 
meeting on 14.08 is cancelled.
Next meeting will be at 21.08.2018

— 
Slawek Kaplonski
Senior software engineer
Red Hat


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

[openstack-dev] Neutron team meeting cancelled

[Slawomir Kaplonski]

Hi,

As Miguel is not available this week, Tuesday’s Neutron team meeting is 
cancelled.
Next meeting should be normally on Monday, 20.08

— 
Slawek Kaplonski
Senior software engineer
Red Hat


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

[openstack-dev] [nova] CI job running functional against a mysql DB

[Matthew Booth]

I was reviewing https://review.openstack.org/#/c/504885/ . The change
looks good to me and I believe the test included exercises the root
cause of the problem. However, I'd like to be certain that the test
has been executed against MySQL rather than, eg, SQLite.

Zuul has voted +1 on the change. Can anybody tell me if any of those
jobs ran the included functional test against a MySQL DB?,

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

Phone: +442070094448 (UK)

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

Re: [openstack-dev] [tripleo] Proposing Lukas Bezdicka core on TripleO

[Jose Luis Franco Arza]

+1 of course!

On Mon, Aug 6, 2018 at 5:50 PM, Dougal Matthews  wrote:

> +1
>
> On 6 August 2018 at 16:28, Alex Schultz  wrote:
>
>> +1
>>
>> On Mon, Aug 6, 2018 at 7:19 AM, Bogdan Dobrelya 
>> wrote:
>> > +1
>> >
>> > On 8/1/18 1:31 PM, Giulio Fidente wrote:
>> >>
>> >> Hi,
>> >>
>> >> I would like to propose Lukas Bezdicka core on TripleO.
>> >>
>> >> Lukas did a lot work in our tripleoclient, tripleo-common and
>> >> tripleo-heat-templates repos to make FFU possible.
>> >>
>> >> FFU, which is meant to permit upgrades from Newton to Queens, requires
>> >> in depth understanding of many TripleO components (for example Heat,
>> >> Mistral and the TripleO client) but also of specific TripleO features
>> >> which were added during the course of the three releases (for example
>> >> config-download and upgrade tasks). I believe his FFU work to have been
>> >> very challenging.
>> >>
>> >> Given his broad understanding, more recently Lukas started helping
>> doing
>> >> reviews in other areas.
>> >>
>> >> I am so sure he'll be a great addition to our group that I am not even
>> >> looking for comments, just votes :D
>> >>
>> >
>> >
>> > --
>> > Best regards,
>> > Bogdan Dobrelya,
>> > Irc #bogdando
>> >
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.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:unsubscrib
>> e
>> 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] Bug deputy report, week August 5th - August 12th

[Bernard Cafarelli]

I was the bug deputy for the August 6th - August 12th week (6th exclusive,
it was handled by Miguel, thanks to him).

A mostly quiet week, most issues came with related fix (and some already
merged).
Interesting topics: API performance improvement (1786226), a few fixes for
metering agent, a DVR bug/discussion (1786169), API performance improvement
(1786226), some test fixes

High:
https://bugs.launchpad.net/neutron/+bug/1785848 - Neutron server producing
tracebacks with 'L3RouterPlugin' object has no attribute
'is_distributed_router' when DVR is enabled - Fix merged
https://review.openstack.org/#/c/589573
https://bugs.launchpad.net/neutron/+bug/1786213 - Metering agent: failed to
run ip netns command - Fix merged https://review.openstack.org/#/c/590215/


Medium:
https://bugs.launchpad.net/neutron/+bug/1786347 - Incorrect entry point of
metering iptables driver - Fix merged
https://review.openstack.org/#/c/590479
https://bugs.launchpad.net/neutron/+bug/1786169 - DVR: Missing fixed_ips
info for IPv6 subnets - Proposed fix at
https://review.openstack.org/#/c/590157
https://bugs.launchpad.net/neutron/+bug/1786413 - Cannot load
neutron_fwaas.conf by neutron-api - Proposed fix at
https://review.openstack.org/590656
https://bugs.launchpad.net/neutron/+bug/1786272 - Connection between two
virtual routers does not work with DVR - In discussion (limitation or real
issue)

Low:
https://bugs.launchpad.net/neutron/+bug/1786472 - Scenario
test_connectivity_min_max_mtu fails when cirros is used - Fix merged
https://review.openstack.org/#/c/590763

Wishlist:
https://bugs.launchpad.net/neutron/+bug/1786226 - Use sqlalchemy baked
query - Sample baked query at https://review.openstack.org/#/c/430973/2
already shows impressive performance improvements

Incomplete:
https://bugs.launchpad.net/neutron/+bug/1786047 - neutron-dhcp-agent is
unable to set network namespaces - Issue happens on an openstack-ansible
deployment with manual agent install on top. Additional details asked, but
this is probably more a deployment issue than a real neutron bug
https://bugs.launchpad.net/neutron/+bug/1786408 - IPsec shutdown and re-up
the external-interface ,routing missing - a vpnaas bug, but on Kilo
release. To confirm on a supported release?

-- 
Bernard Cafarelli
__
OpenStack Development Mailing 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] about live-resize down the instance

[Rambo]

Hi,all


  I find it is important that live-resize the instance in production 
environment,especially live downsize the disk.And we have talked it many 
years.But I don't know why the bp[1] didn't approved.Can you tell me more about 
this ?Thank you very much.


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
















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