February 2020 - openstack-discuss

[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