- openstack-discuss - lists.openstack.org

[neutron] Bug deputy report week of February 11th
by Brian Haley 18 Feb '19

18 Feb '19

Hi, I was Neutron bug deputy last week. Below is a short summary about reported bugs. -Brian Critical bugs ------------- None High bugs --------- * https://bugs.launchpad.net/neutron/+bug/1815585 - Floating IP status failed to transition to DOWN in neutron-tempest-plugin-scenario-linuxbridge - intermittent gate failure * https://bugs.launchpad.net/neutron/+bug/1815618 - cannot update qos rule - Bence took ownership, triaging * https://bugs.launchpad.net/neutron/+bug/1815629 - api and rpc worker defaults are problematic - Fix proposed - https://review.openstack.org/636363 * https://bugs.launchpad.net/neutron/+bug/1815758 - Error in ip_lib.get_devices_info() retrieving veth interface info - Fix proposed - https://review.openstack.org/#/c/636652/ * https://bugs.launchpad.net/neutron/+bug/1815797 - rpc_response_max_timeout" configuration variable not present in fullstack tests - Fix proposed - https://review.openstack.org/#/c/636719/ - Duplicate - https://bugs.launchpad.net/neutron/+bug/1816443 * https://bugs.launchpad.net/neutron/+bug/1815912 - [OVS] exception message when retrieving bridge-id is not present - Fix proposed - https://review.openstack.org/#/c/636963/ * https://bugs.launchpad.net/neutron/+bug/1815913 - DVR can not work with multiple routers on single network. - Fix proposed - https://review.openstack.org/#/c/636953/ * https://bugs.launchpad.net/bugs/1816239 - Functional test test_router_processing_pool_size failing - Fix proposed - https://review.openstack.org/#/c/637544/ Medium bugs ----------- * https://bugs.launchpad.net/neutron/+bug/1815609 - [fwaas] devstack plugin fails if ML2/OVS is not use - Fix proposed - https://review.openstack.org/#/c/636340/ * https://bugs.launchpad.net/neutron/+bug/1815871 - neutron-server api don't shutdown gracefully - Fix proposed - https://review.openstack.org/#/c/636855/ Low bugs -------- * https://bugs.launchpad.net/neutron/+bug/1815600 - "tags" listed in POST in api-ref - bug in docs * https://bugs.launchpad.net/neutron/+bug/1816395 - L2 Networking with SR-IOV enabled NICs in neutron - bug in docs Wishlist bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1815498 - Use pyroute2 to check vlan/vxlan in use - Fix proposed - https://review.openstack.org/#/c/636296/ * https://bugs.launchpad.net/neutron/+bug/1815933 - [RFE] Allow bulk-tagging of resources - Discussed at drivers meeting 2/15 Invalid bugs ------------ None Further triage required ----------------------- * https://bugs.launchpad.net/neutron/+bug/1815728 - Can delete port attached to VM without Nova noticing - The nova_notifier code should have done this, asked for more info, no answer yet * https://bugs.launchpad.net/neutron/+bug/1815989 - OVS drops RARP packets by QEMU upon live-migration causes up to 40s ping pause in Rocky - Asked for clarification on issue, Sean Mooney indicated it was os-vif related so added the component.

1 0

[nova] boot from volume with root_gb=0 flavors is not allowed now
by Mohammed Naser 18 Feb '19

18 Feb '19

Hi everyone, Just wanted to give a heads up about the change that recently merged in Nova which will affect Train (and current master, for deployment projects). https://review.openstack.org/#/c/603910/ As of that change, Nova will no longer allow you to to create a VM when the root_gb of a flavor is set to 0. This is to avoid a reported security issue which we've found a while ago: https://launchpad.net/bugs/1739646 If you're using devstack, you'll probably be okay as the following change has already fixed it: https://review.openstack.org/#/c/619319/ However, deployment projects will need to make that adjustment as well as deployers need to plan accordingly (everyone is going to upgrade to Train the day we release, right?) -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

2 1

[manila] Fw: [nova] boot from volume with root_gb=0 flavors is not allowed now
by Tom Barron 18 Feb '19

18 Feb '19

Some of the jobs in manila gate were booting service VMs with root_gb=0 and got caught by this but were fixed here [1]. That's a devstack plugin fix, so as Mohammed warns, your distribution tests downstream may require their own adjustment. [1] https://review.openstack.org/#/c/637176

1 0

[keystone][service-catalog] Region "*" for identity in service catalog
by Artem Goncharov 18 Feb '19

18 Feb '19

Hi all, In a public cloud I am using there is currently one region, but should be multiple in future. Endpoint for each service has a region set. However the only exception is identity, which has an empty region (actually "*"). If I do not specify region_name during connection (with diverse tools) everything works fine. Some "admin" operations, however, really require region to be set. But if I set in (i.e. in clouds.yaml) I can't connect to cloud, since identity in this region has no explicit endpoint (keystoneauth1 is not ok with that, gophercloud as well) I was not able to find any requirements/conventions, how such setup should be really treated. On https://wiki.openstack.org/wiki/API_Special_Interest_Group/Current_Design/S… there are service catalogs for diverse clouds, and in case where a cloud has multiple region, there are multiple entries for keystone pointing to the same endpoint. Basically each time there is region properly set. In Keystone.v2 region was mandatory, but in v3 it is not anymore ( https://docs.openstack.org/python-openstackclient/pike/cli/command-objects/…) I guess in a normal way you would not be even able to configure region "*", but it was somehow done. While there is only one region the problem is not that big, but as soon as second region is added it becomes problem. Does anyone knows if that is an "allowed" setup (but then tools should be adapted to treat it properly), or this is not an "allowed" configuration (in this case I would like to see some docs to refer properly). I would personally prefer second way of fixing catalog to avoid fixes in diverse tools, but I really need a weightful reference for that. Thanks a lot in advance, Artem

2 1

[ironic] Ironic Stein Mid-Cycle Notes
by Michael Turek 18 Feb '19

18 Feb '19

Ironic had it's virtual mid-cycle call on January 21st and 22nd. Discussions were around how far along we were with priorities this cycle, making the project more container friendly, Smart NIC support, bug triaging, and more. If you are interested in seeing more about these discussions, we suggest that you check out the etherpad where we kept notes. https://etherpad.openstack.org/p/ironic-stein-midcycle If you have anything you'd like to bring up about the notes or the mid-cycle, please reach out here or on #openstack-ironic Thanks!

1 0

Help Needed - Mirantis - All Services Down in 2 Controllers
by Raja T 18 Feb '19

18 Feb '19

Hello All, Using Mirantis - Mitaka on Ubuntu 14.04 Currently I'm facing this issue: almost all services are down on 2 controllers, and are up only in one node. Pl find below pcs status output. Any help to recover this is highly appreciated. root@node-11:/var/log# pcs status Cluster name: WARNING: corosync and pacemaker node names do not match (IPs used in setup?) Last updated: Sun Feb 17 02:12:59 2019 Last change: Sat Feb 16 08:56:52 2019 by root via crm_attribute on node-1.mydomain.com Stack: corosync Current DC: node-10.mydomain.com (version 1.1.14-70404b0) - partition with quorum 3 nodes and 46 resources configured Online: [ node-1.mydomain.com node-10.mydomain.com node-11.mydomain.com ] Full list of resources: Clone Set: clone_p_vrouter [p_vrouter] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] vip__management (ocf::fuel:ns_IPaddr2): Started node-1.mydomain.com vip__vrouter_pub (ocf::fuel:ns_IPaddr2): Started node-1.mydomain.com vip__vrouter (ocf::fuel:ns_IPaddr2): Started node-1.mydomain.com vip__public (ocf::fuel:ns_IPaddr2): Started node-1.mydomain.com Clone Set: clone_p_haproxy [p_haproxy] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Clone Set: clone_p_mysqld [p_mysqld] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Master/Slave Set: master_p_rabbitmq-server [p_rabbitmq-server] Masters: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Clone Set: clone_neutron-openvswitch-agent [neutron-openvswitch-agent] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Clone Set: clone_neutron-l3-agent [neutron-l3-agent] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Clone Set: clone_neutron-metadata-agent [neutron-metadata-agent] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Clone Set: clone_neutron-dhcp-agent [neutron-dhcp-agent] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Clone Set: clone_p_heat-engine [p_heat-engine] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] sysinfo_node-1.mydomain.com (ocf::pacemaker:SysInfo): Started node-1.mydomain.com Clone Set: clone_p_dns [p_dns] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Master/Slave Set: master_p_conntrackd [p_conntrackd] Masters: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Clone Set: clone_p_ntp [p_ntp] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] Clone Set: clone_ping_vip__public [ping_vip__public] Started: [ node-1.mydomain.com ] Stopped: [ node-10.mydomain.com node-11.mydomain.com ] sysinfo_node-10.mydomain.com (ocf::pacemaker:SysInfo): Stopped sysinfo_node-11.mydomain.com (ocf::pacemaker:SysInfo): Stopped PCSD Status: node-1.mydomain.com member (172.17.6.24): Offline node-10.mydomain.com member (172.17.6.32): Offline node-11.mydomain.com member (172.17.6.33): Offline Thanks! Raja. -- :^)

2 1

Rocky undercloud/director installation getting stuck -- keepalived container issue
by Shyam Biradar 18 Feb '19

18 Feb '19

Hi, Undercloud installation getting stuck due to following issue. In short, keepalived container is not starting, hence installation going in loop. https://bugs.launchpad.net/tripleo/+bug/1816349 Any comments/ideas are welcome. Thanks & Regards, Shyam Biradar, Email: shyambiradarsggsit(a)gmail.com, Contact: +91 8600266938.

1 0

[kolla][tripleo] python3 support for RHEL based systems
by Alex Schultz 18 Feb '19

18 Feb '19

Ahoy Kolla folks, In TripleO/RDO we've been working towards getting python3 support ready when the next CentOS is released. We've been working towards getting the packaging all ready and have a basic setup working on fedora 28. We would like to get a head start in Kolla and I've proposed two possible solutions to support the python2/python3 transition in the container builds. I am looking for input from the Kolla folks on which of the two methods would be preferred so we can move forward. The first method is to handle the package names in the Dockerfiles themselves. https://review.openstack.org/#/c/632156/ (kolla python3 packages) https://review.openstack.org/#/c/624838/ (kolla WIP for fedora support (not expected to merge)) https://review.openstack.org/#/c/629679/ (tripleo specific overrides) IMHO think this method allows for a better transition between the python2 and python3 packages as it just keys off the distro_python3 setting that we added as part of https://review.openstack.org/#/c/631091/. It was mentioned that this might be more complex to follow and verbose due to the if/elses being added into the Docker files. I think the if/else complexity goes away once CentOS7 support is dropped so it's a minor transition (as I believe the target is Train for full python3 support). The second method is to add in a new configuration option that allows for package names to be overrideable/replaced. See https://review.openstack.org/#/c/636403/ (kolla package-replace option) https://review.openstack.org/#/c/636457/ (kolla python3 specifics) https://review.openstack.org/#/c/624838/ (kolla WIP for fedora support would need to be supplied to test) https://review.openstack.org/#/c/636472/ (tripleo specific overrides) IMHO I actually like the package-replace option for a few package overrides. I don't think this is a cleaner implementation for replacing all the packages because it becomes less obvious what packages would actually be used and it becomes more complex to manage. This one feels more like it's pushing the complexity to the end user and would still be problematic when CentOS8 comes out all the packages would still need to be replaced in all the Docker files (in the next cycle?). My personal preference would be to proceed with the first method and maybe merge the package-replace functionality if other would find it beneficial. I would be interested to hear if other think that the second option would be better in the long term. Thanks, -Alex

2 1

[tc][election] TC candidacy
by Thierry Carrez 18 Feb '19

18 Feb '19

Hi everyone, I've been on the OpenStack Technical Committee forever, and my original plan was to not run for re-election this cycle. Thanks to name recognition, incumbents have traditionally easily been reelected. Stepping down is the only way to make room for new leaders to emerge, a process that is necessary to keep alignment between the Technical Committee members and the active contributors that are their constituency. So, having room for new members to be elected is necessary. At the same time, there is value in historical perspective, and experienced members are useful to help newcomers into their role. We also need to be careful about the message that too many people stepping down would send. So, it's a mixed bag -- we need enough, but not too many people stepping down. Over the past cycles, we introduced about 3 new people at every election. I think renewing 3 or 4 people every 6 months in a committee of 13 members is the right balance. We already have three experienced members who announced they would not be running again this cycle, so I feel like it might not be the best moment for me to step down. With the OSF shifting from being solely about OpenStack to more generally tackling the open infrastructure space, my focus has certainly expanded lately. But I don't want to feed the trolls arguing that we are leaving OpenStack behind. I'm not done with the OpenStack TC yet, and would like to advance two more things before stepping down. OpenStack is in the middle of a transition -- from hyped project driven by startups and big service providers to a more stable project led by people running it or having a business depending on it. A lot of the systems and processes that I helped put in place to cope with explosive growth are now holding us back. We need to adapt them to a new era, and I feel like I can help bringing the original perspective of why those systems were put in place, so hopefully we do not end up throwing the baby with the bath water. I feel like there is also a lot of work to do to better present what we produce. The work on the OpenStack map and the "software" pages on the openstack.org website is far from complete. OpenStack is still much harder to navigate and understand for a newcomer than it should be. I want to continue that work for one more year. So I am announcing my candidacy for a position on the OpenStack Technical Committee in the upcoming election. Thank you for your consideration ! -- Thierry Carrez (ttx)

1 0

[tc][election] TC Candidacy
by Zane Bitter 18 Feb '19

18 Feb '19

Hello again friends, I'm running again for a second term on the Technical Committee. (For the record, I don't plan to seek a third term next year.) I've been part of the OpenStack community since 2012, and as well as a TC member I am also a core reviewer for Heat and (since very recently) Oslo. I think of the TC as effectively the 'core reviewer' team for a larger group of folks who participate in the governance of OpenStack (a group that I think we should be aiming to expand even further). I'm deeply grateful to the community for giving me the opportunity to work with what is a fantastic team of people. Here's what I've been up to in the past year on the TC: - I supported Julia's initiative to spread constructive code-review techniques by distilling some of our annual endless threads on code-review etiquette into a linkable page in the Project Teams Guide.[1] A number of people, in one case an entire team, told me that they'd tweaked their approach to code review after getting ideas from this document. (This feedback is *much* appreciated by the way, because from the TC perspective it can be very hard to tell the difference between achieving lazy consensus and shouting into the void.) - I wrote the draft of and edited contributions to what became the Vision for OpenStack Clouds,[2] contacted every affected team to explain what it meant for them individually, and presented it to the OSF Board in Berlin for their feedback as well. - I helped drive the definition of a process for determining which versions of Python3 should be tested in a release.[3] That should help us make the transitions smoothly in future, though it unfortunately started too late for Stein. - I've been actively engaged with members of the OSF Board on the topic of the process for adding new Open Infrastructure projects to the Foundation, by passing on feedback from foundation members and from the TC's own experience with evaluating project applications, and trying to publicise the board's position in the community.[4] It's hard to imagine being able to get any of those done without being a TC member. As I've written elsewhere,[5] because the TC is the only project-wide elected body, leading the community to all move in the same direction is something that cannot happen without the TC. I plan to continue trying to do that, and encouraging others to do the same. Thanks for your consideration. cheers, Zane. [1] https://docs.openstack.org/project-team-guide/review-the-openstack-way.html [2] https://governance.openstack.org/tc/reference/technical-vision.html [3] https://governance.openstack.org/tc/resolutions/20181024-python-update-proc… [4] https://www.zerobanana.com/archive/2018/06/14#osf-expansion [5] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001841.…

2 2