- openstack-discuss - lists.openstack.org

[heat] Presence at OpenDev Vancouver in June
by Rico Lin 25 Feb '20

25 Feb '20

Hi all, As the deadline for OpenDev Vancouver team survey is near (before this weekend). We need to decide if we would like to reserved a room or not. And since I'm not that positively sure I will get the budget to travel this time. We need to make sure if anyone is going so we can have people to be the moderator. Note that I will not occupy a room if no others are able to be there. Or at least *might* be there. -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[Watcher]We will have IRC meeting at 8:00 UTC tomorrow
by licanwei 25 Feb '20

25 Feb '20

please update the meeting agenda if you have something want to discuss. Thanks | | licanwei_cn | | 邮箱：licanwei_cn(a)163.com | 签名由网易邮箱大师定制 On 02/13/2020 17:01, licanwei wrote: Hi, next time i will send the mail one day in advance. hope to meet you next time! Thanks licanwei | | licanwei_cn | | 邮箱：licanwei_cn(a)163.com | 签名由网易邮箱大师定制 On 02/12/2020 17:58, info(a)dantalion.nl wrote: Hello Lican, Sorry but I am unable to attend at such short notice as in my timezone I won't be awake unless it is for the Watcher meeting. To be able to adjust my transit schedule I will have to know a day in advance. Hope to be there next time. Kind regards, Corne Lukken On 2/12/20 3:31 AM, licanwei wrote: > > > > > licanwei_cn > 邮箱：licanwei_cn(a)163.com > 签名由网易邮箱大师定制 > > | | > licanwei_cn > | > | > 邮箱：licanwei_cn(a)163.com > | > > 签名由网易邮箱大师定制 >

1 0

[neutron] Team meeting 25.02.2020 cancellee
by Slawek Kaplonski 24 Feb '20

24 Feb '20

Hi, I’m on PTO tomorrow and I will not be able to chair our team meeting. So lets cancel it. See You all on the meeting next week. One reminder, if You are planning to attend Vancouver PTG in June, please add Your name to the list in [1]. I need to give number of rough number of attendees by Sunday, March 2nd. Please add Your name there even if it’s not yet confirmed. [1] https://etherpad.openstack.org/p/neutron-victoria-ptg — Slawek Kaplonski Senior software engineer Red Hat

1 0

Neutron metadata service not responding due to rabbitmq dropping messages
by Grant Morley 24 Feb '20

24 Feb '20

Hi all, We have recently come across an issue where our metadata service stops responding. If you try to curl the service from within an instance you get: % curl http://169.254.169.254 <html><body><h1>504 Gateway Time-out</h1> The server didn't respond in time. </body></html> After doing some digging around on our neutron nodes I noticed we were getting loads of RabbitMQ timeout errors whilst trying to process message requests: 2020-02-24 07:28:09.747 26378 ERROR neutron.common.rpc [-] Timeout in RPC method get_ports. Waiting for 26 seconds before next attempt. If the server is not down, consider increasing the rpc_response_timeout option as Neutron server(s) may be overloaded and unable to respond quickly enough.: MessagingTimeout: Timed out waiting for a reply to message ID a14c4a1395864cd980c1ec563a5c48aa The servers are fairly busy, however we do not have a massive installation >1500 instances and roughly 850 routers. However if I restart the "neutron-metadata-agent" service and the "neutron-server" service it seems to fix the issue for a while but ultimately it comes back. I did increase the "rpc_timeout" on the netutron nodes to 120 seconds but that seems quite long to me. Likewise the RabbitMQ servers are not overly busy, we seem to get a constant stream of only 40+ messages in the queue at one time and that can spike depending on workload. Does anyone know of any tuning or tweaking we can do to the metadata service in either Neutron or Nova that might help? We are running OpenStack Queens if that helps. Many thanks, Grant

1 0

RHOSP-like installation
by Volodymyr Litovka 24 Feb '20

24 Feb '20

Dear colleagues, while having a good experience with Openstack on Ubuntu, we're facing a plenty of questions re RHOSP installation. The primary requirement for our team re RHOSP is to get a knowledge on RHOSP - how to install it and maintain. As far as I understand, RDO is the closest way to reach this target but which kind of installation it's better to use? - * plain RDO installation as described in generic Openstack guide at https://docs.openstack.org/install-guide/index.html (specifics in RHEL/CentOS sections) * or TripleO installation as described in http://tripleo.org/install/ * or, may be, it is possible to use RHOSP in kind of trial mode to get enough knowledge on this platform? Our lab consists of four servers (64G RAM, 16 cores@2GHz) which we're going to use in "ultraconverged" mode - as both controller and agent (compute/network/storage) nodes (controllers, though, can be in virsh-controlled VMs). In case of TripleO scenario, 4th server can be used for undercloud role. This installation is intended not for production use, but rather for learning purposes, so no special requirements for productivity. The only special requirement - to be functionally as much as close to canonical RHOSP platform. I will highly appreciate your suggestions on this issue. Thank you. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

2 1

[oslo] Meeting Time Poll
by Ben Nemec 24 Feb '20

24 Feb '20

Hello again, We have a few regular attendees of the Oslo meeting who have conflicts with the current meeting time. As a result, we would like to find a new time to hold the meeting. I've created a Doodle poll[0] for everyone to give their input on times. It's mostly limited to times that reasonably overlap the working day in the US and Europe since that's where most of our attendees are located (yes, I know, that's a self-fulfilling prophecy). If you attend the Oslo meeting, please fill out the poll so we can hopefully find a time that works better for everyone. Thanks! -Ben /me finally checks this one off the action items for next week :-) 0: https://doodle.com/poll/zmyhrhewtes6x9ty

1 1

[ironic][neutron][ops] Ironic multi-tenant networking with VXLAN Overlay
by Austin Cormier 24 Feb '20

24 Feb '20

We are using Openstack + Ironic to test routing software which requires the use of VLANs. Using VXLan overlays allows the VM's to have nested VLANs without issue as they are encapsulated into a VXLAN and sent across. However, we are struggling to find a path forward in extending the VXLAN overlay out to the hardware device. Unfortunately, the networking-generic-switch driver does not support VXLAN but this seems to fairly easy to extend (given the right switch). The challenge I'm facing is that with Neutron OVS + L2Pop, there seems to be no easy way to extend the L2 population to include an external device. The only path forward that I can see is to use the Linux Bridge driver + VXLAN multicast and find a switch that also supports VXLAN multicast so it can participate in the overlay dynamically. The HPE FlexFabric seems to do this from the documentation: https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c04567545 Can anyone help confirm that the switch above will work and or give alternative suggestions on approaching this problem? -Austin

1 0

[openstack-helm][stein]Cinder pods stuck in init state after deployed in k8s cluster
by Sanjay K 24 Feb '20

24 Feb '20

Hello openstack-helm team, I am trying to deploy stein cinder service in my k8s cluster using persistent volume and persistent volume claim for local storage or NFS storage. However after deploying cinder in my cluster, the cinder pods remains in Init state even though the PV and PVC are created. Please look at my below post on openstack forum and guide me how to resolve this issue. https://ask.openstack.org/en/question/126191/cinder-pods-in-init-state-when… thank you for your help and support on this. best regards, Sanjay

2 3

[largescale-sig] Next meeting: Feb 26, 9utc
by Thierry Carrez 24 Feb '20

24 Feb '20

Hi everyone, The Large Scale SIG will have a meeting this week on Wednesday, Feb 26 at 9 UTC[1] in #openstack-meeting on IRC: [1] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200226T09 As always, the agenda for our meeting is available at: https://etherpad.openstack.org/p/large-scale-sig-meeting Feel free to add topics to it! A quick reminder of the TODOs from our last meeting: - masahito to update spec based on initial feedback - everyone to review and comment on https://review.opendev.org/#/c/704733/ Talk to you all on Wednesday, -- Thierry Carrez

1 0

[neutron] Bug deputy report (week starting on 2020-02-17)
by Bernard Cafarelli 24 Feb '20

24 Feb '20

Picking up after amotoki's report [0], here is last week's report. This includes all bugs reported up to 1864374 (included) Some gate issues (python2 is still fighting us back, etc), new "interesting" bugs on different topics. Bugs marked with "***" do not have current assignee Critical * socket.timeout error in dvr CI jobs cause SSH issues - https://bugs.launchpad.net/neutron/+bug/1863858 Under investigation by slaweq - neutron-tempest-plugin-designate-scenario fails on stable branches with "SyntaxError: invalid syntax" installing dnspython - https://bugs.launchpad.net/neutron/+bug/1864015 Patch merged to pin designate plugin - https://review.opendev.org/708825 - "ping" prepended to ip netns commands - https://bugs.launchpad.net/neutron/+bug/1864186 Patch merged: https://review.opendev.org/709100 High * When updating the network segment ID, the project_id should be provided - https://bugs.launchpad.net/neutron/+bug/1863619 Needed parameter to get private ranges belonging to the project, fix in progress: https://review.opendev.org/708196/ * [OVN] Provider driver IPv6 traffic doesn't work - https://bugs.launchpad.net/neutron/+bug/1863892 IPv6 load balancers with OVN provider do not work, in progress by maciejjozefczyk * [OVN] DHCP doesn't work while instance has disabled port security - https://bugs.launchpad.net/neutron/+bug/1864027 Behaviour introduced by a recent fix, root cause may be in core OVN *** IP allocation for stateless IPv6 does not filter on segment when fixed-ips contain a subnet_id - https://bugs.launchpad.net/neutron/+bug/1864225 Title sums it up nicely, stateless IPv6 + segments issue *** When adding another stateless subnet, implicit address allocation happen for port with deferred ip allocation - https://bugs.launchpad.net/neutron/+bug/1864333 IPv6 allocation happens for deffered allocation port Medium *** Unhandled error - WSREP has not yet prepared node for application use - https://bugs.launchpad.net/neutron/+bug/1863579 Unassigned. Transient startup error seen in kolla-ansible upgrade CI when database is not ready, we can probably add a retry here * [neutron-tempest-plugin] test_trunk.TrunkTestInheritJSONBase.test_add_subport fails if unordered - https://bugs.launchpad.net/neutron/+bug/1863707 Results order failure in test, fix in progress: https://review.opendev.org/708305/ * [OVN]Could not support more than one qos rule in one policy - https://bugs.launchpad.net/neutron/+bug/1863852 Fix in progress: https://review.opendev.org/708586 * Missing information in log message for Invalid tunnel type - https://bugs.launchpad.net/neutron/+bug/1863888 Add some log extra information, fix in progress: https://review.opendev.org/708634 * [OVN] OVN LoadBalancer VIP shouldn't have addresses set - https://bugs.launchpad.net/neutron/+bug/1863893 Regression fix, in progress by maciejjozefczyk * [OVN] Remove dependency on port_object - https://bugs.launchpad.net/neutron/+bug/1863987 Suggested fix: https://review.opendev.org/708806/ Low * Default security group rules not created during list of SG rules - https://bugs.launchpad.net/neutron/+bug/1864171 Fix in progress: https://review.opendev.org/709070 *** BGP dynamic routing in neutron - No Info about capability to receiv/learn dynamic routes - https://bugs.launchpad.net/neutron/+bug/1864219 Doc enhancement request on BGP limitations *** ml2 ovs does not flush iptables switching to FW ovs - https://bugs.launchpad.net/neutron/+bug/1864374 Switching from iptables to ovs firewall is not a trivial task, this may end up being documentation bug too Related to neutron * Upgrade from Rocky to Stein, router namespace disappear - https://bugs.launchpad.net/neutron/+bug/1863982 Issue in kolla-ansible upgrade Rocky->Stein, failing to restore iptables rules. It does not seem to be neutron-specific, but opinions welcome [0] http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012610… -- Bernard Cafarelli

1 0

[neutron] Network segment ranges feature
by Rodolfo Alonso 24 Feb '20

24 Feb '20

Hello Neutrinos: First of all, a reference: https://bugs.launchpad.net/neutron/+bug/1863423 I detected some problems with this feature. The service plugin, when enabled and according to the spec [1], should segregate the segmentation range in several ranges. Each one (or many) of those ranges could be assigned to a project. When a network is created in a specific project, should receive a segmentation ID from the project network segment ranges. In case of not having any range assigned, a segmentation ID from a default range will be provided. How the current implementation actually works: When a driver is loaded (VLAN, VXLAN, GRE or Geneve), it creates a default network segment range, based on the static configuration provided in the plugin ("network_vlan_ranges", "vni_ranges", etc). Then the admin can create project specific network segment ranges (remember: always per driver type). Those project specific ranges cannot overlap but the project specific ranges CAN overlap the default one. A valid state could be: VLAN: - Default: 100:1000 - Project1: 100:200 - Project2: 200:300 When assigning segmentation IDs to new networks, the driver will query [2]: - The existing ranges per project. - The default range (always present). The result is that, if the project network segment range runs out of segment IDs, it will retrieve those ones from the default range. That will lead, eventually, to a clash between ranges. Project 1 will be able to allocate a network with a segmentation ID from Project 2 range. E.g.: [3] The problem is how the queries are done: [4] --> select one of each commented line to reproduce "query_project_id" and "query_shared" in [2]. Now we know the feature is not properly working, my question is what the proper behaviour should be. Some alternatives: 1) If a project has one or more network segment ranges, the segmentation ID should be retrieved ONLY from those ranges. If a project does not have any range, then it will retrieve from the shared pool BUT NEVER selecting a segment ID belonging to other project ID (ufff this query is going to be complex). --> IMO, the best solution. 2) If a project has one or more network segment ranges, the segmentation ID should be retrieved first from those ranges and then from the shared one, BUT NEVER selecting a segment ID belonging to other project ID. Same for range-less projects. --> IMO, if the administrator has assigned a range for a project, the project should ONLY use this pool. This is not a good solution. Can I have your feedback? Regards. [1] https://specs.openstack.org/openstack/neutron-specs/specs/stein/network-seg… [2]https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/driv… [3]http://paste.openstack.org/show/789872/ [4]http://paste.openstack.org/show/789873/

3 3

[openstack-discuss][neutron] is neutron-openvswitch-agent needed for network connection on provider network?
by Chen CH Ji 24 Feb '20

24 Feb '20

2 2

[neutron][dhcp] "additional" dhcp port in state "reserved_dhcp_port", non existing namespace on network node
by Nicolas Ghirlanda 24 Feb '20

24 Feb '20

Dear mailinglist, We have the following behavour, which occured in about 3% of our networks. We have a default configured of 3 dhcp servers per subnet, but in about 3% of all networks, we have unexpectedly 4, from which one is in state "reserved_dhcp_port", also there is NO namespace on that control/network node. Setup: Openstack Rocky, Networkmode legacy # openstack port list --device-owner network:dhcp --network a2d4605d-997e-4807-9250-c0c80af3183e +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ | ID | Name | MAC Address | Fixed IP Addresses | Status | +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ | 40237ca8-aed6-49ee-xxxx-49acf97797e4 | | fa:16:3e:e1:33:83 | ip_address='172.16.0.4', subnet_id='e4380af7-13b4-xxxx-90ff-6b0a2818052b' | ACTIVE | | 6a3898c6-6520-43e7-xxxx-e6b2639f2600 | | fa:16:3e:ff:f0:7b | ip_address='172.16.0.2', subnet_id='e4380af7-13b4-xxxx-90ff-6b0a2818052b' | ACTIVE | | 89479d32-881d-45b9-xxxx-1b41ed8fd703 | | fa:16:3e:ef:7d:dc | ip_address='172.16.0.6', subnet_id='e4380af7-13b4-xxxx-90ff-6b0a2818052b' | ACTIVE | | eaeb0ef7-48c6-43ea-xxxx-8615ed704e48 | | fa:16:3e:66:7c:96 | ip_address='172.16.0.3', subnet_id='e4380af7-13b4-xxxx-90ff-6b0a2818052b' | ACTIVE | +--------------------------------------+------+-------------------+---------------------------------------------------------------------------+--------+ full output of one of that port: # openstack port show 89479d32-881d-45b9-xxxx-1b41ed8fd703 +-------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Field | Value | +-------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | admin_state_up | UP | | allowed_address_pairs | | | binding_host_id | ctl5 | | binding_profile | | | binding_vif_details | datapath_type='system', ovs_hybrid_plug='True', port_filter='True' | | binding_vif_type | ovs | | binding_vnic_type | normal | | created_at | 2020-01-16T11:22:14Z | | data_plane_status | None | | description | | | device_id | reserved_dhcp_port | | device_owner | network:dhcp | | dns_assignment | None | | dns_domain | None | | dns_name | None | | extra_dhcp_opts | | | fixed_ips | ip_address='172.16.0.6', subnet_id='e4380af7-13b4-40f9-xxxx-xxxx' | | id | 89479d32-881d-45b9-xxxx-1b41ed8fd703 | | location | Munch({'project': Munch({'domain_id': None, 'id': u'a772e4ab888e4fxxxx', 'name': 'admin', 'domain_name': 'Default'}), 'cloud': '', 'region_name': 'ch-zh1', 'zone': None}) | | mac_address | fa:16:3e:ef:7d:xx | | name | | | network_id | a2d4605d-997e-4807-xxxx-xxx | | port_security_enabled | False | | project_id | 232ecbeb96fd4663xxxx | | propagate_uplink_status | None | | qos_policy_id | None | | resource_request | None | | revision_number | 8 | | security_group_ids | | | status | ACTIVE | | tags | | | trunk_details | None | | updated_at | 2020-02-14T09:16:57Z | +-------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ ctl5:~# ip netns |grep a2d4605d ctl5:~# *Workaround:* I can easily delete those ports manually and everything seems to be ok (openstack delete port <portid>) When I tried figuring out, what happens, when I disable dhcp in an affected subnet, the following happens (different example): The 6f34 is a reserved port (last line) # openstack port list --device-owner network:dhcp --network 8589eb04-228f-4ae1-af71-a0bc5335f9c5 +--------------------------------------+------+-------------------+-----------------------------------------------------------------------------+--------+ | ID | Name | MAC Address | Fixed IP Addresses | Status | +--------------------------------------+------+-------------------+-----------------------------------------------------------------------------+--------+ | 23f9e5d7-75a2-440a-xxxx-d82000286fbe | | fa:16:3e:8b:e2:a8 | ip_address='192.168.50.3', subnet_id='882b360a-eae1-4736-xxxx-af752f552440' | ACTIVE | | 352bc1a4-e002-440b-xxxx-0383cfb1632b | | fa:16:3e:29:46:6b | ip_address='192.168.50.5', subnet_id='882b360a-eae1-4736-xxxx-af752f552440' | ACTIVE | | 6ee79608-7834-4015-xxxx-fda3f47b5e59 | | fa:16:3e:0c:b6:60 | ip_address='192.168.50.4', subnet_id='882b360a-eae1-4736-xxxx-af752f552440' | ACTIVE | | 6f3435f8-23c0-427c-xxxx-fca1a6910aff | | fa:16:3e:2d:35:b6 | ip_address='192.168.50.2', subnet_id='882b360a-eae1-4736-xxxx-af752f552440' | ACTIVE | +--------------------------------------+------+-------------------+-----------------------------------------------------------------------------+--------+ - I disable dhcp (openstack subnet set --no-dhcp <subnetid>), expected to remove all dhcp ports, but the what happens is that all "healthy" dhcp ports will be removed, the reserved port remains # openstack port list --device-owner network:dhcp --network 8589eb04-228f-4ae1-af71-a0bc5335f9c5 +--------------------------------------+------+-------------------+-----------------------------------------------------------------------------+--------+ | ID | Name | MAC Address | Fixed IP Addresses | Status | +--------------------------------------+------+-------------------+-----------------------------------------------------------------------------+--------+ | 6f3435f8-23c0-427c-xxxx-fca1a6910aff | | fa:16:3e:2d:35:b6 | ip_address='192.168.50.2', subnet_id='882b360a-eae1-4736-xxxx-af752f552440' | ACTIVE | +--------------------------------------+------+-------------------+-----------------------------------------------------------------------------+--------+ - when I now reenable dhcp, nothing happens, still the single, reserved port is existing, no new ports are created. Just the state went from ACTIVE to DOWN to ACTIVE # openstack subnet set --dhcp 882b360a-eae1-4736-a276-af752f552440 # openstack port list --device-owner network:dhcp --network 8589eb04-228f-4ae1-xxxx-a0bc5335f9c5 +--------------------------------------+------+-------------------+-----------------------------------------------------------------------------+--------+ | ID | Name | MAC Address | Fixed IP Addresses | Status | +--------------------------------------+------+-------------------+-----------------------------------------------------------------------------+--------+ | 6f3435f8-23c0-427c-xxxx-fca1a6910aff | | fa:16:3e:2d:35:b6 | ip_address='192.168.50.2', subnet_id='882b360a-eae1-4736-xxxx-af752f552440' | DOWN | +--------------------------------------+------+-------------------+-----------------------------------------------------------------------------+--------+ s# openstack port list --device-owner network:dhcp --network 8589eb04-228f-4ae1-xxxx-a0bc5335f9c5 +--------------------------------------+------+-------------------+-----------------------------------------------------------------------------+--------+ | ID | Name | MAC Address | Fixed IP Addresses | Status | +--------------------------------------+------+-------------------+-----------------------------------------------------------------------------+--------+ | 6f3435f8-23c0-427c-xxxx-fca1a6910aff | | fa:16:3e:2d:35:b6 | ip_address='192.168.50.2', subnet_id='882b360a-eae1-4736-xxxx-af752f552440' | ACTIVE | +--------------------------------------+------+-------------------+-----------------------------------------------------------------------------+--------+ - after deleting the port manually and disable/enable dhcp, 3 new working ports are created # openstack port delete 6f3435f8-23c0-427c-xxxx-fca1a6910aff # openstack port list --device-owner network:dhcp --network 8589eb04-228f-4ae1-xxxx-a0bc5335f9c5 # openstack subnet set --no-dhcp 882b360a-eae1-4736-xxxx-af752f552440 # openstack subnet set --dhcp 882b360a-eae1-4736-xxxx-af752f552440 # openstack port list --device-owner network:dhcp --network 8589eb04-228f-4ae1-xxxx-a0bc5335f9c5 # openstack port list --device-owner network:dhcp --network 8589eb04-228f-4ae1-xxxx-a0bc5335f9c5 +--------------------------------------+------+-------------------+-----------------------------------------------------------------------------+--------+ | ID | Name | MAC Address | Fixed IP Addresses | Status | +--------------------------------------+------+-------------------+-----------------------------------------------------------------------------+--------+ | 9fd63011-2b1f-410a-xxxx-40d42779c637 | | fa:16:3e:15:be:fd | ip_address='192.168.50.4', subnet_id='882b360a-eae1-4736-xxxx-af752f552440' | ACTIVE | | cdd32840-7899-47b2-xxxx-7d36eae515a2 | | fa:16:3e:4c:40:5c | ip_address='192.168.50.3', subnet_id='882b360a-eae1-4736-xxxx-af752f552440' | ACTIVE | | dc1eeba2-4afd-4502-xxxx-7370d086e553 | | fa:16:3e:29:29:5d | ip_address='192.168.50.2', subnet_id='882b360a-eae1-4736-xxxx-af752f552440' | ACTIVE | +--------------------------------------+------+-------------------+-----------------------------------------------------------------------------+--------+ Any ideas where those are coming from? thanks a lot Nicolas --

1 0

[CINDER] Distributed storage alternatives
by Alfredo De Luca 24 Feb '20

24 Feb '20

Hi all. we 'd like to explore storage back end alternatives to CEPH for Openstack I am aware of GlusterFS but what would you recommend for distributed storage like Ceph and specifically for block device provisioning? Of course must be: 1. *Reliable* 2. *Fast* 3. *Capable of good performance over WAN given a good network back end* Both open source and commercial technologies and ideas are welcome. Cheers -- *Alfredo*

3 2

[neutron] do we need neutron-openvswitch-agent running in order to make VMs spawned with provider network?
by Chen CH Ji 24 Feb '20

24 Feb '20

3 2

[TC] W release naming
by Sean McGinnis 23 Feb '20

23 Feb '20

Hello TC (and other interested parties), This is a reminder that we have this week set aside for the 'W' release naming for any necessary discussion, campaigning, or other activities before the official polling starts. https://governance.openstack.org/tc/reference/release-naming.html#polls We have a set of names collected from the community. There may be some trademark concerns, but I think we can leave that for the Foundation review after the election polling completes unless anyone has a strong reason to exclude any now. If so, please state so here before I create the poll for next week. https://wiki.openstack.org/wiki/Release_Naming/W_Proposals As a reminder for everyone, this naming poll is the first that follows our new process of having the electorate being members of the Technical Committee. More details can be found in the governance documentation for release naming: https://governance.openstack.org/tc/reference/release-naming.html#release-n… I will prepare the poll to send out next Monday. Since we have a limited electorate this time, if we collect all votes ahead of the published deadline I will check in with the TC if there is any need to wait, and if not close the poll early and get the results ready to publish. We can then move ahead with the legal review that is required before we can officially declare a winner. Thanks! Sean

8 9

[cloud-provider-openstack] [kubernetes] Migrating from in-tree provider to external openstack-cloud-controller-manager
by Lingxian Kong 23 Feb '20

23 Feb '20

For those who still haven't heard of cloud-provider-openstack[1], cloud-provider-openstack is an implementation of Kubernetes Cloud Controller Manager[2], it's a sub-project under Kubernetes, which provides a couple of binaries/services relevant to OpenStack and Kubernetes integration, more documentation could be found here[3]. The demo below shows how to migrate from in-tree openstack cloud provider to external openstack-cloud-controller-manager. The Kubernetes cluster in the demo was set up using kubeadm. https://asciinema.org/a/303399?speed=2 [1]: https://github.com/kubernetes/cloud-provider-openstack [2]: https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controlle… [3]: https://github.com/kubernetes/cloud-provider-openstack/tree/master/docs - Best regards, Lingxian Kong Catalyst Cloud

1 0

[tripleo] RDO image server migration
by Daniel Pawlik 23 Feb '20

23 Feb '20

Hello, Todays migration of images server to the new cloud provider was not finished. We are planning to continue tomorrow (18th Feb), on 10 AM UTC. What was done today: - moved rhel-8 build base image to new image server What will be done tomorrow: - change DNS record - disable upload images to old host - sync old images (if some are available) Migration should be transparent to the end user. However, you have to keep in mind the unforeseen events that may occur. Write access to the old server will be disabled and until DNS propagation is not done, you could have read-only access. If you have any doubts or concerns, please do not hesitate to contact: - Daniel Pawlik <dpawlik(a)redhat.com> - Javier Pena <jpena(a)redhat.com> Regards, Daniel

3 3

[all][nova][ptl] Another one bites the dust
by Eric Fried 23 Feb '20

23 Feb '20

Dear OpenStack- Due to circumstances beyond my control, my job responsibilities will be changing shortly and I will be leaving the community. I have enjoyed my time here immensely; I have never loved a job, my colleagues, or the tools of the trade more than I have here. My last official day will be March 31st (though some portion of my remaining time will be vacation -- TBD). Unfortunately this means I will need to abdicate my position as Nova PTL mid-cycle. As noted in the last meeting [1], I'm calling for a volunteer to take over for the remainder of Ussuri. Feel free to approach me privately if you prefer. Thanks, efried [1] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-02-13-21.00.log…

9 8

[kolla]: Openstack kolla
by Mohammed, Moiz 23 Feb '20

23 Feb '20

Hello, I am installing Openstack Kolla on CentOs 7 with multimode configuration and facing some issues during pre-checks.I am using openstack stein release and master built. Command: ./kolla-ansible -i ../../multinode prechecks Error: TASK [haproxy : Checking if kolla_internal_vip_address is in the same network as api_interface on all nodes] ************************************************************************************************** fatal: [moiz-kolla-controller-01]: FAILED! => {"changed": false, "cmd": ["ip", "-o", "addr", "show", "dev", "eth0"], "delta": "0:00:00.002984", "end": "2020-02-21 18:11:42.365444", "failed_when_result": true, "rc": 0, "start": "2020-02-21 18:11:42.362460", "stderr": "", "stderr_lines": [], "stdout": "2: eth0 inet 192.168.130.203/24 brd 192.168.130.255 scope global noprefixroute dynamic eth0\\ valid_lft 81807sec preferred_lft 81807sec\n2: eth0 inet6 fe80::f816:3eff:fe7f:4d2/64 scope link \\ valid_lft forever preferred_lft forever", "stdout_lines": ["2: eth0 inet 192.168.130.203/24 brd 192.168.130.255 scope global noprefixroute dynamic eth0\\ valid_lft 81807sec preferred_lft 81807sec", "2: eth0 inet6 fe80::f816:3eff:fe7f:4d2/64 scope link \\ valid_lft forever preferred_lft forever"]} [cid:image003.png@01D5E8CF.EC6EB410] Moiz Mohammed | Systems Engineer - NSM Compute (704)-378-2934 O | (415) 866-3183 M | Oncall Phone: 1-866-577-0007 Ext 802 7815 Cresent Executive Dr, Floor#2 | Charlotte, NC 28217 [cid:image002.png@01D3AA4F.EFCE7660] E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

2 1

[tripleo] proposal to make Kevin Carter core
by Wesley Hayutin 23 Feb '20

23 Feb '20

Greetings, I'm sure by now you have all seen the contributions from Kevin to the tripleo-ansible project, transformation, mistral to ansible etc. In his short tenure in TripleO Kevin has accomplished a lot and is the number #3 contributor to tripleo for the ussuri cycle! First of all very well done, and thank you for all the contributions! Secondly, I'd like to propose Kevin to core.. Please vote by replying to this email. Thank you +1

17 16

[tripleo] Turning off Paunch by default
by Emilien Macchi 22 Feb '20

22 Feb '20

Hi folks, In the long-term effort of simplification and convergence to Ansible, the replacement of Paunch has passed a big milestone where it has proven to be stable enough to be the default. A lot of testing has happened, including updates and upgrades; all positive so far. The role itself is documented here: https://docs.openstack.org/tripleo-ansible/latest/roles/role-tripleo-contai… It has functional testing (Molecule), testing things like container config updates, idempotency, and many more use cases. You can take a look: https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ans… The role itself is using custom filters; which are all unit tested. Some modules were created as well. More testing has to happen on these modules but they have proven to work and even improve the operator experience to cover more scenarios and improve the logging and debugging process. The role doesn't support Docker, and won't at this point; it doesn't fit with our roadmap. With that patch, any new deployment (not using Docker) will now use the new role and not Paunch anymore: https://review.opendev.org/#/c/700738/ Which means: standalone, undercloud, overcloud. If you already have a running deployment, you can either run a minor update which will update THT and roll your cloud; or you can also set EnablePaunch: False and the containers will be restarted with the new config. If for some reason, you need to disable it, here's how: - undercloud.conf: undercloud_enable_paunch = false - standalone/overcloud: EnablePaunch: False It is not supported to roll back to a Paunch deployment once your containers are managed by Ansible; if you try it, an error will raise and the deployment/update/upgrade will stop. If you find any problem, bug or have any feedback for improvement, please let me know and we'll make it better. During the following weeks, we'll watch for performances and see if it degraded or if it's better. Paunch's replacement shouldn't make it faster because Ansible has a lot of overhead; however we want to make sure that it doesn't cause issues at scale. Which is why we're going to observe that now and do more testing at scale now it's the default. I want to thank all the reviewers involved in that effort, and specially Sagi, Kevin and Alex for their great feedback. Thanks, -- Emilien Macchi

2 1

[openstack-helm][neutron] neutron-dhcp-agent stuck in Init state
by Sanjay K 22 Feb '20

22 Feb '20

Hi All, I am trying to deploy openstack services using helm charts in my k8s cluster. My cluster is having 4 nodes - 1 k8s master, 1 controller and 2 compute nodes. I am using helm v3.0.3 for openstack stein. I have already deployed the below charts in my cluster successfully in the respective order - ingress, mariadb, rabbitmq, memcached, keystone, glance and then neutron. For mariadb, rabbitmq and glance, I am using PV and PVC in my local storage while deploying. All are ok until I deploy neutron. After deployment, all neutron pods works well except *neutron-dhcp-agent-default pod *which remains in Init:0/2 state. The pod description shows it has dependencies shown as - DEPENDENCY_SERVICE: openstack:rabbitmq,openstack:neutron-server,openstack:nova-api DEPENDENCY_JOBS: neutron-rabbit-init pods state- NAME READY STATUS RESTARTS AGE glance-api-b575ff7c-qp7wt 1/1 Running 0 132m glance-bootstrap-zjtw9 0/1 Completed 0 132m glance-db-init-86xgk 0/1 Completed 0 132m glance-db-sync-z9p9l 0/1 Completed 0 132m glance-ks-endpoints-wwm59 0/3 Completed 0 132m glance-ks-service-vs92t 0/1 Completed 0 132m glance-ks-user-znn88 0/1 Completed 0 132m glance-metadefs-load-g685b 0/1 Completed 0 132m glance-rabbit-init-648w8 0/1 Completed 0 132m glance-storage-init-jdlx2 0/1 Completed 0 132m ingress-8f98f7d96-llkwl 1/1 Running 0 3h42m ingress-error-pages-84647d8fcb-6j6bz 1/1 Running 0 3h42m keystone-api-5785f4787-lz296 1/1 Running 0 154m keystone-bootstrap-6tcdx 0/1 Completed 0 154m keystone-credential-setup-d9js5 0/1 Completed 0 154m keystone-db-init-zsgbj 0/1 Completed 0 154m keystone-db-sync-z8hfk 0/1 Completed 0 154m keystone-domain-manage-nk48h 0/1 Completed 0 154m keystone-fernet-setup-4pzlj 0/1 Completed 0 154m keystone-rabbit-init-mlpsn 0/1 Completed 0 154m mariadb-ingress-669c67b6b5-w8jxb 1/1 Running 0 3h32m mariadb-ingress-error-pages-d77467d69-9njgt 1/1 Running 0 3h32m mariadb-server-0 1/1 Running 0 3h32m memcached-memcached-7b49f48865-tf6xc 1/1 Running 0 3h11m neutron-db-init-zpl87 0/1 Completed 0 109m neutron-db-sync-plsnc 0/1 Completed 0 109m neutron-dhcp-agent-default-sf76z 0/1 Init:0/2 0 109m neutron-ks-endpoints-jgmdv 0/3 Completed 0 109m neutron-ks-service-nr5w2 0/1 Completed 0 109m neutron-ks-user-lw4p4 0/1 Completed 0 109m neutron-l3-agent-default-lnzk8 1/1 Running 0 109m neutron-lb-agent-default-44v9x 1/1 Running 0 109m neutron-lb-agent-default-94xw4 1/1 Running 0 109m neutron-lb-agent-default-whms2 1/1 Running 0 109m neutron-metadata-agent-default-7rbrh 1/1 Running 0 109m neutron-rabbit-init-qkhqm 0/1 Completed 0 109m neutron-server-964fcffcb-gvv4k 1/1 Running 0 109m rabbitmq-cluster-wait-vjbzq 0/1 Completed 0 3h18m rabbitmq-rabbitmq-0 1/1 Running 0 3h18m Please guide me how to resolve this neutron-dhcp-agent pod so that I can deploy other services after that. I have plan to deploy libvirt, nova, cinder, horizon and ceilometer charts into my cluster. thank you for your help and support. best regards, Sanjay

3 2

[all][dev] reno linting anyone?
by Radosław Piliszek 21 Feb '20

21 Feb '20

Hello fellow OpenStackers! I wonder whether any project applies any linting to release notes? How do you maintain quality of release notes? -yoctozepto

2 1

Re: [infra][neutron] Removing networking-calico from OpenStack governance
by David Comay 21 Feb '20

21 Feb '20

Neil, > networking-calico is the code that integrates Project Calico [1] with > Neutron. It has been an OpenStack project for several years, but we, i.e. > its developers [2], would like now to remove it from OpenStack governance > and instead manage it like the other Project Calico projects under > https://github.com/projectcalico/. My primary concern which isn't really governance would be around making sure the components in `networking-calico` are kept in-sync with the parent classes it inherits from Neutron itself. Is there a plan to keep these in-sync together going forward?

5 8