July 2020 - openstack-discuss - lists.openstack.org

Re: [neutron][networking-midonet] Maintainers needed
by Sebastian Saemann 11 Sep '20

11 Sep '20

Hi Slawek, we at NETWAYS are running most of our neutron networking on top of midonet and wouldn't be too happy if it gets deprecated and removed. So we would like to take over the maintainer role for this part. Please let me know how to proceed and how we can be onboarded easily. Best regards, Sebastian -- Sebastian Saemann Head of Managed Services NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg Tel: +49 911 92885-0 | Fax: +49 911 92885-77 CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB25207 https://netways.de | sebastian.saemann(a)netways.de ** NETWAYS Web Services - https://nws.netways.de **

6 17

[cinder][stable] branch freeze for ocata, pike
by Brian Rosmaita 10 Sep '20

10 Sep '20

tl;dr - do not approve any backports to stable/ocata or stable/pike in any Cinder project deliverable stable/ocata has been tagged with ocata-eol in cinder, os-brick, python-cinderclient, and python-brick-cinderclient-ext. Nothing should be merged into stable/ocata in any of these repositories during the interim period before the branches are deleted. stable/pike: the changes discussed in [0] have merged, and I've proposed the pike-eol tags [1]. Nothing should be merged into stable/pike in any of our code repositories from now until the branches are deleted. [0] http://lists.openstack.org/pipermail/openstack-discuss/2020-July/016076.html [1] https://review.opendev.org/#/c/742523/

4 6

[tc] [all] Topics for Cross Community Discussion with Kubernetes ...
by Jay Bryant 10 Sep '20

10 Sep '20

All, Recently, the OpenStack TC has reached out to the Kubernetes Steering Committee for input as we have proposed adding a starter-kit:kubernetes-in-virt tag for projects in OpenStack. This request was received positively and as a result the TC has started brainstorming other topics that we could approach with the k8s community in this [1] etherpad. If you have topics that may be appropriate for this discussion please see the etherpad and add your ideas. Thanks! Jay IRC: jungleboyj [1] https://etherpad.opendev.org/p/kubernetes-cross-community-topics

3 3

Setuptools 48 and Devstack Failures
by Clark Boylan 31 Aug '20

31 Aug '20

Hello, Setuptools has made a new version 48 release. This appears to be causing problems for devstack because `pip install -e $PACKAGE_PATH` installs commands to /usr/bin and not /usr/local/bin on Ubuntu as it did in the past. `pip install $PACKAGE_PATH` continues to install to /usr/local/bin as expected. Devstack is failing because keystone-manage cannot currently be found at the specific /usr/local/bin/ path. Potential workarounds for this include not using `pip install -e` or relying on $PATH to find the commands rather than specifying rooted paths to them. I'll defer to the QA team on how they want to address this. While we can have devstack install an older setuptools version as well, generally this is not considered to be a good idea because anyone doing pip installs outside of devstack may get the newer behavior. It is actually important for us to try and keep up with setuptools changes as a result. Fungi indicated that setuptools expected this to be a bumpy upgrade. I'm not sure if they would consider `pip install -e` and `pip install` installing to different paths as a bug, and if they did which behavior is correct. It would probably be a good idea to file a bug upstream if we debug this further. Clark

5 6

Re: [cyborg] Temporary treatment plan for the 3rd-party driver
by yumeng bao 27 Aug '20

27 Aug '20

Brin, thanks for bringing this up! > Hi all： > This release we want to introduce some 3rd party drivers (e.g. Intel QAT, Inspur FPGA, and Inspur SSD etc.) in Cyborg, and we discussed the handling of 3rd-party driver CI in Cyborg IRC meeting [1]. > Due to the lack of CI test environment supported by hardware, we reached a temporary solution in two ways, as follows: > 1. Provide a CI environment and provide a tempest test for Cyborg, this method is recommended; > 2. If there is no CI environment, please provide the test results of this driver in the master branch or in the designated branch, which should be as complete as possible, sent to the Cyborg team, or pasted in the implementation of the commit. Providing test result can be our option. The test result can be part of the driver documentation[0] as this is public to users. And from my understanding, the test result should work as the role of tempest case and clarify at least: necessary configuration,test operations and test results. [0] https://docs.openstack.org/cyborg/latest/reference/support-matrix.html#driv… > [1] http://eavesdrop.openstack.org/meetings/openstack_cyborg/2020/openstack_cyb… Regards， Yumeng

4 4

[largescale-sig] RPC ping
by Arnaud Morin 21 Aug '20

21 Aug '20

Hey all, TLDR: I propose a change to oslo_messaging to allow doing a ping over RPC, this is useful to monitor liveness of agents. Few weeks ago, I proposed a patch to oslo_messaging [1], which is adding a ping endpoint to RPC dispatcher. It means that every openstack service which is using oslo_messaging RPC endpoints (almosts all OpenStack services and agents - e.g. neutron server + agents, nova + computes, etc.) will then be able to answer to a specific "ping" call over RPC. I decided to propose this patch in my company mainly for 2 reasons: 1 - we are struggling monitoring our nova compute and neutron agents in a correct way: 1.1 - sometimes our agents are disconnected from RPC, but the python process is still running. 1.2 - sometimes the agent is still connected, but the queue / binding on rabbit cluster is not working anymore (after a rabbit split for example). This one is very hard to debug, because the agent is still reporting health correctly on neutron server, but it's not able to receive messages anymore. 2 - we are trying to monitor agents running in k8s pods: when running a python agent (neutron l3-agent for example) in a k8s pod, we wanted to find a way to monitor if it is still live of not. Adding a RPC ping endpoint could help us solve both these issues. Note that we still need an external mechanism (out of OpenStack) to do this ping. We also think it could be nice for other OpenStackers, and especially large scale ops. Feel free to comment. [1] https://review.opendev.org/#/c/735385/ -- Arnaud Morin

10 31

[tripleo][ci] container pulls failing
by Wesley Hayutin 19 Aug '20

19 Aug '20

FYI... If you find your jobs are failing with an error similar to [1], you have been rate limited by docker.io via the upstream mirror system and have hit [2]. I've been discussing the issue w/ upstream infra, rdo-infra and a few CI engineers. There are a few ways to mitigate the issue however I don't see any of the options being completed very quickly so I'm asking for your patience while this issue is socialized and resolved. For full transparency we're considering the following options. 1. move off of docker.io to quay.io 2. local container builds for each job in master, possibly ussuri 3. parent child jobs upstream where rpms and containers will be build and host artifacts for the child jobs 4. remove some portion of the upstream jobs to lower the impact we have on 3rd party infrastructure. If you have thoughts please don't hesitate to share on this thread. Very sorry we're hitting these failures and I really appreciate your patience. I would expect major delays in getting patches merged at this point until things are resolved. Thank you! [1] HTTPError: 429 Client Error: Too Many Requests for url: http://mirror.ca-ymq-1.vexxhost.opendev.org:8082/v2/tripleotrain/centos-bin… [2] https://bugs.launchpad.net/tripleo/+bug/1889122

8 20

[cloudkitty][tc] Cloudkitty abandoned?
by Sean McGinnis 19 Aug '20

19 Aug '20

Posting here to raise awareness, and start discussion about next steps. It appears there is no one working on Cloudkitty anymore. No patches have been merged for several months now, including simple bot proposed patches. It would appear no one is maintaining this project anymore. I know there is a need out there for this type of functionality, so maybe this will raise awareness and get some attention to it. But barring that, I am wondering if we should start the process to retire this project. From a Victoria release perspective, it is milestone-2 week, so we should make a decision if any of the Cloudkitty deliverables should be included in this release or not. We can certainly force releases of whatever is the latest, but I think that is a bit risky since these repos have never merged the job template change for victoria and therefore are not even testing with Python 3.8. That is an official runtime for Victoria, so we run the risk of having issues with the code if someone runs under 3.8 but we have not tested to make sure there are no problems doing so. I am hoping this at least starts the discussion. I will not propose any release patches to remove anything until we have had a chance to discuss the situation. Sean

11 20

[masakari] Meetings
by Radosław Piliszek 14 Aug '20

14 Aug '20

Hello Fellow cloud-HA-seekers, I wanted to attend Masakari meetings but I found the current schedule unfit. Is there a chance to change the schedule? The day is fine but a shift by +3 hours would be nice. Anyhow, I wanted to discuss [1]. I've already proposed a change implementing it and looking forward to positive reviews. :-) That said, please reply on the change directly, or mail me or catch me on IRC, whichever option sounds best to you. [1] https://blueprints.launchpad.net/masakari/+spec/customisable-ha-enabled-ins… -yoctozepto

2 2

[Ocata][Heat] Strange error returned after stack creation failure -r aw template with id xxx not found
by Laurent Dumont 14 Aug '20

14 Aug '20

Hi! We are currently troubleshooting a Heat stack issue where one of the stack (one of 25 or so) is failing to be created properly (seemingly randomly). The actual error returned by Heat is quite strange and Google has been quite sparse in terms of references. The actual error looks like the following (I've sanitized some of the names): Resource CREATE failed: resources.potato: Resource CREATE failed: resources[0]: raw template with id 22273 not found heat resource-list STACK_NAME_HERE -n 50 > > +------------------+--------------------------------------+-------------------------+-----------------+----------------------+--------------------------------------------------------------------------+ > | resource_name | physical_resource_id | resource_type > | resource_status | updated_time | stack_name > | > > +------------------+--------------------------------------+-------------------------+-----------------+----------------------+--------------------------------------------------------------------------+ > | potato | RESOURCE_ID_HERE | OS::Heat::ResourceGroup | > CREATE_FAILED | 2020-07-18 T19:52:10Z | nested_stack_1_STACK_NAME_HERE > | > | potato_server_group | RESOURCE_ID_HERE | OS::Nova::ServerGroup | > CREATE_COMPLETE | 2020-07-21T19:52:10Z | nested_stack_1_STACK_NAME_HERE > | > | 0 | | potato1.yaml > | CREATE_FAILED | 2020-07-18T19:52:12Z | nested_stack_2_STACK_NAME_HERE > | > | 1 | | potato1.yaml > | INIT_COMPLETE | 2020-07- 18 T19:52:12Z | > nested_stack_2_STACK_NAME_HERE | > > +------------------+--------------------------------------+-------------------------+-----------------+----------------------+--------------------------------------------------------------------------+ > The template itself is pretty simple and attempts to create a ServerGroup and 2 VMs (as part of the ResourceGroup). My feeling is that one the creation of those machines fails and Heat get's a little cooky and returns an error that might not be the actual root cause. I would have expected the VM to show up in the resource list but I just see the source "yaml". Has anyone seen something similar in the past? Thanks!

2 3