March 2019 - openstack-discuss - lists.openstack.org

zun 3.0.0.0rc2 (stein)
by no-reply＠openstack.org 31 Mar '19

31 Mar '19

Hello everyone, A new release candidate for zun for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/zun/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/zun/log/?h=stable/stein Release notes for zun can be found at: https://docs.openstack.org/releasenotes/zun/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/zun/+bugs and tag it *stein-rc-potential* to bring it to the zun release crew's attention.

1 0

[charms] Enabling Neutron DVR & ovs
by Emil Larsson 30 Mar '19

30 Mar '19

Hi guys, I have been experimenting with the enable-dvr option in neutron-api. I cannot find a clear guide on how to configure this. However I have ran into some issues trying to figure out the configuration to enable dvr. This is where juju stops: unit-neutron-openvswitch-1: 11:45:35 INFO unit.neutron-openvswitch/1.juju-log Creating bridge br-int unit-neutron-openvswitch-1: 11:45:35 INFO unit.neutron-openvswitch/1.juju-log Creating bridge br-ex unit-neutron-openvswitch-1: 11:45:36 DEBUG unit.neutron-openvswitch/1.juju-log Replacing iface 'eno1' with bond master 'os' unit-neutron-openvswitch-1: 11:45:36 DEBUG unit.neutron-openvswitch/1.juju-log Replacing iface 'eno2' with bond master 'os' unit-neutron-openvswitch-1: 11:45:36 DEBUG unit.neutron-openvswitch/1.juju-log Replacing iface 'eno3' with bond master 'stor' unit-neutron-openvswitch-1: 11:45:36 DEBUG unit.neutron-openvswitch/1.juju-log Replacing iface 'eno4' with bond master 'stor' unit-neutron-openvswitch-1: 11:45:37 INFO unit.neutron-openvswitch/1.juju-log Creating bridge br-data unit-neutron-openvswitch-1: 11:45:37 DEBUG unit.neutron-openvswitch/1.juju-log Interface os.392 is not a Linux bridge unit-neutron-openvswitch-1: 11:45:37 INFO unit.neutron-openvswitch/1.juju-log Adding port os.392 to bridge br-data unit-neutron-openvswitch-1: 11:45:37 DEBUG unit.neutron-openvswitch/1.config-changed Failed to restart os-charm-phy-nic-mtu.service: Unit os-charm-phy-nic-mtu.service not found. Does this mean i need to have a relation to my Neutron-gateway charm aswell? I found a reference to that service in the code for charm-neutron-gateway. Here is a simplified juju bundle configuration of my setup: neutron-openvswitch: annotations: gui-x: '250' gui-y: '500' charm: cs:neutron-openvswitch-255 num_units: 0 options: data-port: br-data:os.392 bridge-mappings: physnet1:br-data firewall-driver: openvswitch instance-mtu: 1458 security-group-log-output-base: "/var/log/openvswitch/security.log" security-group-log-burst-limit: 25 bindings: data: os-private neutron-gateway: annotations: gui-x: '0' gui-y: '0' charm: cs:neutron-gateway-256 num_units: 1 options: openstack-origin: cloud:bionic-rocky worker-multiplier: 0.25 ### Network configuration ### flat-network-providers: physnet1 data-port: br-data:os.392 bridge-mappings: physnet1:br-data plugin: ovs enable-l3-agent: true enable-metadata-network: true enable-isolated-metadata: false run-internal-router: all instance-mtu: 1458 use-syslog: true verbose: true extra-bindings: data: os-private to: - '0' neutron-api: annotations: gui-x: '500' gui-y: '500' charm: cs:neutron-api-269 num_units: 1 options: openstack-origin: cloud:bionic-rocky worker-multiplier: 0.25 use-internal-endpoints: true global-physnet-mtu: 1500 flat-network-providers: physnet1 dhcp-agents-per-network: 2 neutron-security-groups: true enable-security-group-logging: true overlay-network-type: "gre" default-tenant-network-type: "gre" neutron-external-network: ext_net enable-dvr: true bindings: public: os-private admin: os-private internal: os-private shared-db: os-private to: - lxd:0 Any help appreciated :) -- Emil Larsson

1 0

Re: [infra] [Gerrit-CI] Debian Jessie is no longer supported
by Adam Spiers 29 Mar '19

29 Mar '19

Luca Milanesio <luca.milanesio(a)gmail.com> wrote: >>On 27 Mar 2019, at 15:46, Luca Milanesio <Luca.Milanesio(a)gmail.com> wrote: >>>On 27 Mar 2019, at 15:44, Thomas Dräbing <thomas.draebing(a)gmail.com <mailto:thomas.draebing@gmail.com>> wrote: >>> >>>I suggested that some time ago, when reviewing this change: https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/184730 <https://gerrit-review.googlesource.com/c/gerrit-ci-scripts/+/184730> . >>>The question just is, whether the openjdk 7 from the experimental repository is stable enough to be used by the CI. >> >>Agreed. Best to just "tag" the current images for now than risking to have an unstable Java 7 build. >> >>> >>>Since we still have a year until jessy loses its LTS-status, I would rather try to use this year to try to move everybody to a newer Gerrit version, if possible. >> >>That would be ideal, Java 7 is largely deprecated and unsupported. > >$ curl https://review.openstack.org/config/server/version >)]}' >"2.13.12-11-g1707fec" > >Are the OpenStack guys happy to upgrade their Gerrit setup or move to GerritHub? > >If we drop support for Gerrit v2.13, they'll lose any support from >the community for their setup. I can't "officially" represent the views of the folks in charge of the OpenStack infrastructure. However I've spoken to them several times about Gerrit and to the best of my knowledge there is every intention to upgrade - I think it has been blocked by a lack of time, or (IIRC) perhaps by some difficulties encountered when testing the migration, or maybe a combination of both. I'll dare to cross-post this sub-thread to openstack-discuss, although I might be risking the wrath of the mailing list gods by doing so, so please don't take for granted that the cross-posting will work correctly :-) I can also highly recommend joining #openstack-infra on Freenode IRC and chatting with the very helpful and friendly folks there. >OpenStack is a pretty big OpenSource project Yes, IIRC it's top 3 in terms of commit velocity these days, and possibly higher than the Linux kernel. >not supporting them anymore would be a problem I believe. Good to hear - thanks a lot for thinking of us ;-)

1 0

[first contact] Meeting Time Moving!
by Kendall Nelson 29 Mar '19

29 Mar '19

Hello :) Since two of our regular meeting attendees are moving/have moved to very different timezones, here is a poll to pick a new time to meet! We also won't actually enact the new time until April-ish but if you have a preference on if we want to move it for the first meeting in April or the second, please voice your opinions here :) -Kendall (diablo_rojo) [1] https://doodle.com/poll/h5m5n6za9hbiv9pr

3 5

Unsubscription from mailing list
by Namrata Jha 29 Mar '19

29 Mar '19

Hello all, It's been a great time here, but lately the mails from this mailing list have spammed my inbox too much, and I would like to unsubcribe. Could I receive some help on how to do that? Thanks. Regards, Namrata.

2 1

[TripleO] flattening perf improvements
by Dan Prince 29 Mar '19

29 Mar '19

I ran a few tests yesterday to see how much the latest flattening [1] efforts effect performance on the TripleO Heat templates. I only ran a few of each type but the results looked towards a minor but positive improvement in the speed with which the flattened templates get processed via Heat. Using an all-in-one standalone TripleO deployment I timed how long it took for 'openstack tripleo deploy --standalone --output-only' to run using the latest Heat binaries. I then compared the results switching between t-h-t from master and rocky. On my laptop the results pointed to about a 30-45 second improvement in wall time of 5 minutes or so. A reasonably minor improvement but it is definately in the right direction. The more complex number of services and roles you have the greater this number is likely to be. I don't think performance was the primary reason we undertook this restructuring but I had several people ask about potential performance improvements so I wanted to provide some feedback here. Disclosure: In order to test rocky I had to make a few minor changes to t-h-t in order to get the latest all-in-one to run that similarly. Basically just backporting tools/process_templates.py and removing a few invalid network variable references. Here is the branch [2] if you are interested. Dan [1] https://blueprints.launchpad.net/tripleo/+spec/services-yaml-flattening [2] https://github.com/dprince/tripleo-heat-templates/tree/rocky_test

1 0

[release] Release countdown for week R-1, April 1-5
by Sean McGinnis 29 Mar '19

29 Mar '19

Hey everyone. We're getting close to the end of Stein. Please read through for important release information as we get close to wrapping this cycle up. Development Focus ----------------- Teams should be working on release critical bugs in preparation of the final release candidate deadline this Thursday the 4th. Teams attending the PTG should also be preparing for those discussions and capturing information in the etherpads: https://wiki.openstack.org/wiki/PTG/Train/Etherpads General Information ------------------- Thursday, April 4th is the deadline for final Stein release candidates as well as any last cycle-with-intermediary deliverables. We will then enter a quiet period until we tag the final release on April 10 Actions --------- Watch for any translation patches coming through and merge them quickly. If your project has a stable/stein branch created, please make sure critical bugfix patches are also getting merged there. (Do not backport the translations from master) Liaisons for projects with independent deliverables should import the release history by preparing patches to openstack/releases. Projects following the cycle-trailing model should be getting ready for the cycle-trailing final deadline coming up on July 11. Please drop by #openstack-release with any questions or concerns about the upcoming release. Upcoming Deadlines & Dates -------------------------- Final RC deadline: April 1 Final Stein release: April 10 -- Sean McGinnis (smcginnis)

3 2

[dev][keystone] Keystone Team Update - Week of 25 March 2019
by Colleen Murphy 29 Mar '19

29 Mar '19

# Keystone Team Update - Week of 25 March 2019 ## News ### RC2 Status We still have some open changes[1] that need to merge to master before we can backport them to stable/stein. Please help review these so we can cut RC2 with time to spare before the deadline. [1] https://etherpad.openstack.org/p/keystone-stein-rc2-tracking ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 49 changes this week, which included several system scope and default roles changes and backports to stable/stein. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 26 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. These include several that are needed for RC2, so please review ASAP. ## Bugs This week we opened 2 new bugs and closed 5. Bugs opened (2) Bug #1822135 (keystone:Undecided) opened by XiaojueGuan https://bugs.launchpad.net/keystone/+bug/1822135 Bug #1822251 (keystone:Undecided) opened by Slawek Kaplonski https://bugs.launchpad.net/keystone/+bug/1822251 Bugs closed (2) Bug #1819957 (keystone:High) https://bugs.launchpad.net/keystone/+bug/1819957 Bug #1822251 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1822251 Bugs fixed (3) Bug #1748027 (keystone:High) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1748027 Bug #1750673 (keystone:High) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1750673 Bug #1817047 (keystone:Low) fixed by Edgar Magana https://bugs.launchpad.net/keystone/+bug/1817047 ## Milestone Outlook https://releases.openstack.org/stein/schedule.html Next week is the final RC deadline. We need to have everything critical for Stein merged to stable/stein ASAP so we can request a new release. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[tc] Project repository namespaces
by Jim Rollenhagen 29 Mar '19

29 Mar '19

Hi all, With OpenDev needing to change git URLs for all projects, we have an opportunity to change how we namespace projects that are currently under the "openstack" namespace.[0] I've heard a few options thrown out: 1) Keep everything the same. This is the easiest option for everybody, but keeps our current confusion of what is officially OpenStack, and what is not. 2) Move unofficial projects to "stackforge" or some other namespace, which is only a small amount of work to list the repositories, but probably a large amount of bikeshedding^Wdiscussion to come up with a name. 3) Do (2), but also namespace the OpenStack projects in a more fine-grained manner, by project team. For example: nova/nova, ironic/bifrost, etc. This is a larger chunk of work, but looks a bit nicer. Also makes it easier to move a project out of OpenStack later, as we don't have to move namespaces. This has an open question of whether we use one large namespace for unofficial projects, or give them each their own. It also has a downside of making more effort to move a repository between project teams, though I think that's fairly rare. 4) ?? I personally like (2) or (3), but would like to hear from the rest of the community. I'll propose a governance resolution after the discussion here, and we can follow from there with whatever else needs to be done. // jim [0] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.ht…

17 29

[oslo][cinder] Lots of leftover files in /var/lib/cinder
by Herve Beraud 29 Mar '19

29 Mar '19

Hello, By starting this thread I want to discuss about a knowed issue who impact several openstack projects. Projects who use oslo.concurrency lockutils to lock process have several leftover files who was not automatically removed. You can find a related issue on the Red Hat Bugzilla[1]. It's not really an oslo.concurrency issue it's a knowed fasteners issue[2] not fixed yet on the fasteners side but with some related changes[3] under review currently. oslo.concurrency already provide a work around[4] that all projects can use to fix that temporarely by waiting that the official fasteners fix will be released. I'm voluntary to help peoples and projects to use the oslo.concurrency cleaning method but I'm not sure where I need to put the changes (refer to [1]) outside the oslo scope. Also I guess other projects (nova, etc...) have the same issue. I need help from the expert of these projects to really know where we need to put changes (using oslo.concurrency remove_external_lock_file_with_prefix). Else if projects want to intodruces these changes I can help them by double checking with my oslo hat. Also I guess some projects reimplement the same approach that the oslo.concurrency module to lock process by using directly fasteners, in that case I thing they need to use oslo.concurrency to avoid the problem too. Do not hesitate to reply on this thread to trace useful informations and to add me on project reviews if you decide to introduce these changes on your side. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1647469 [2] https://github.com/harlowja/fasteners/issues/26 [3] https://github.com/harlowja/fasteners/pull/10 [4] https://docs.openstack.org/oslo.concurrency/latest/reference/lockutils.html… Thank you for your attention. -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

3 2