November 2021 - openstack-discuss

[keystone] No weekly meeting next week
by Douglas Mendizabal 19 Nov '21

19 Nov '21

Hi Keystone friends, I'll be out on PTO next week, so I'm canceling the Keystone weekly meeting for November 23. Meetings will resume the following week on November 30. Thanks, - Douglas Mendizábal (redrobot)

1 0

[requirements][keystone] pysaml2 and oslo.policy not able to be updated due to keystone test failures
by Matthew Thode 19 Nov '21

19 Nov '21

more or less as the title states the following reviews show the failures pysaml2: https://review.opendev.org/818612 oslo.policy: https://review.opendev.org/815820 -- Matthew Thode

2 1

[sdk][tc] A new home for Gophercloud
by Emilien Macchi 19 Nov '21

19 Nov '21

Hi everyone, The Gophercloud project is a stable OpenStack SDK in Golang, which has been widely used by many communities now, including Terraform and all the Kubernetes on OpenStack projects. The project was initiated by Rackspace in 2013 and has already successfully managed their departure as a principal contributor. Fast forward to 2021, Joe Topjian (major maintainer) who used to be an active contributor in Puppet modules and also a voice in the OpenStack operators space, has reached out to me so we can discuss a transition for maintenance: https://github.com/gophercloud/gophercloud/issues/2246 We have discussed this internally and here are our notes: https://github.com/gophercloud/gophercloud/issues/2246#issuecomment-9575894… . To make it short, we are figuring out whether it would make sense to find a new home for the project and if yes, where. The main reason we're reaching out to the opendev community first is because we think this is the most logical place to host the project, alongside OpenStack: Some ideas: - The project would potentially have more visibility in the community, it’s a SDK therefore strongly relying on OpenStack APIs stability. - Use (some) opendev tools, mainly Zuul & nodepool resources - integrate with other projects. - Governance: - Gerrit / not Gerrit: we don’t think we would move to Gerrit yet, as the existing contributors are probably more used to the Github workflow, and we clearly don’t want to lose anyone in the process). - IRC: we could have an IRC channel, potentially Slack as well. Many things to figure out and before we answer these questions, we would like to poll the community: what do you think? Have you contributed to the project? What's your feeling about the ideas here? We welcome any feedback and will take it in consideration in our discussions. Thanks everyone, -- Emilien Macchi, on behalf of the Gophercloud contributors

8 13

[nova][all] Adding /healthcheck support in Nova, and better healthcheck in every projects
by Thomas Goirand 19 Nov '21

19 Nov '21

Hi, About a year and a half ago, I attempted to add /healthcheck support by default in all projects. For Nova, this resulted in this patch: https://review.opendev.org/c/openstack/nova/+/724684 For other projects, it's been merged almost everywhere (I'd have to survey all project to see if that's the case, or if I still have debian specific patches somewhere). Though for Nova, this sparked a discussion where it's been said that the current implementation of /healthcheck wasn't good enough. This resulted in threads about how to better do it. Unfortunately, this blocked my patch from being merged in Nova. It is my point of view to recognize a failure here. The /healthcheck URL was added in oslo.middleware so one can use it with something like haproxy to verify that the API is up, and responds. It was never designed to check, for example, if nova-api has a valid connectivity to MySQL and RabbitMQ. Yes, this is welcome, but in the mean time, operators must tweak the default file to have a valid, useable /etc/nova/api-paste.ini. So I am hereby asking the nova team: Can we please move forward and agree that 1.5 years waiting for such a minor patch is too long, and that such patch should be approved, prior to having a better healtcheck mechanism? I don't think it's a good idea to ask Nova users to wait potentially more development cycles to have a good-by-default api-paste.ini file. At the same time, I am wondering: is anyone even working on a better healthcheck system? I haven't heard that anyone is working on this. Though it would be more than welcome. Currently, to check that a daemon is alive and well, operators are stuck with: - checking with ss if the daemon is correctly connected to a given port - check the logs for rabbitmq and mysql errors (with something like filebeat + elastic search and alarming) Clearly, this doesn't scale. When running many large OpenStack clusters, it is not trivial to have a monitoring system that works and scales. The effort to deploy such a monitoring system is also not trivial at all. So what's been discussed at the time for improving the monitoring would be very much welcome, though not only for the API service: something to check the health of other daemons would be very much welcome. I'd very much would like to participate in a Yoga effort to improve the current situation, and contribute the best I can, though I'm not sure I'd be the best person to drive this... Is there anyone else willing to work on this? Hoping this message is helpful, Cheers, Thomas Goirand (zigo)

6 9

[neutron] Drivers meeting - Friday 18.11.2021 - cancelled
by Lajos Katona 18 Nov '21

18 Nov '21

Hi Neutron Drivers! Due to the lack of agenda, let's cancel tomorrow's drivers meeting. See You on the meeting next week. Lajos Katona (lajoskatona)

1 0

[all] tempest-integrated-compute-centos-8-stream job is failing
by Balazs Gibizer 18 Nov '21

18 Nov '21

Hi, The centos 8 stream job is failing in 100% of the cases with mirror issues [2]. You probably need to hold you recheck until it is resolved. cheers, gibi [1] https://zuul.opendev.org/t/openstack/builds?job_name=tempest-integrated-com… [2] https://zuul.opendev.org/t/openstack/build/67dc088859d1435c9a5097e7469e5c12…

3 5

[all][sdk][neutronclient][neutron] List of projects that use python-neutronclient as "client"
by Lajos Katona 18 Nov '21

18 Nov '21

Hi, During the Yoga PTG we discussed the possibility of deprecating python-neutronclient (see [0]). The CLI part of python-neutronclient is already deprecated (see [1]), but we have python bindings for Neutron both in python-neutronclient and in openstacksdk. As python-neutronclient's binding code is widely used as "client" code (i.e.: Heat, Horizon, Nova), but python-openstackclient uses openstacksdk's binding code for "client" this means duplicated work and maintenance for all the bindings. If we have a new API feature the binding code must go both to python-neutronclient to make it available in Heat, and to openstacksdk to have openstackclient support for it. The best would be to have the binding code in openstacksdk and deprecate python-neutronclient, but before we plan anything we would like to have a list of projects that depend on python-neutronclient. We identified a few but for sure with python-neutronclient's long history there are a lot more: * Heat * Horizon * Nova * various Networking projects * ...... Please share Your thoughts about this topic and the projects which use python-neutronclient, it would be really helpful to see how we can move forward. [0]: https://etherpad.opendev.org/p/neutron-yoga-ptg#L372 [1]: https://review.opendev.org/c/openstack/python-neutronclient/+/795475 Regards Lajos Katona (lajoskatona)

1 0

[sdk]: Check instance error message
by dmeng 18 Nov '21

18 Nov '21

Hello there, Hope everything is going well. I'm wondering if there is any method that could check the error message of an instance whose status is "ERROR"? Like from openstack cli, "openstack server show server_name", if the server is in "ERROR" status, this will return a field "fault" with a message shows the error. I tried the compute service get_server and find_server, but neither of them show the error messages of an instance. Thanks and have a great day! Catherine

3 3

[cinder] yoga R-17 virtual midcycle on 1 december
by Brian Rosmaita 17 Nov '21

17 Nov '21

As decided at today's weekly meeting, the Cinder Yoga R-17 virtual midcycle will be held: DATE: Wednesday 1 December 2021 TIME: 1400-1600 UTC LOCATION: https://bluejeans.com/3228528973 The meeting will be recorded. Please add topics to the midcycle etherpad: https://etherpad.opendev.org/p/cinder-yoga-midcycles cheers, brian

1 0

[tacker] Skip next IRC meeting
by Yasufumi Ogawa 17 Nov '21

17 Nov '21

Hi team, Due to my absence from work, I would like to skip the next IRC meeting on November 23. Thanks, Yasufumi

1 0