- openstack-discuss - lists.openstack.org

[openstackclient] Consistency between OSC commands >>> consistency with legacy clients
by Stephen Finucane 25 Nov '22

25 Nov '22

👋 tl;dr: $subject I reviewed a patch against openstackclient (OSC) today [1] and left a rather lengthy comment that I thought worthy of bringing up to a wider audience. The patch itself doesn't matter so much as what is was trying to achieve, namely modifying an existing OSC command to better match the structure of the equivalent legacy client command. The review provides more detail than I do here but the tl;dr: is that this is a big no-no and OSC will and must maintain consistency between OSC commands over consistency with legacy clients. As I noted in the review, consistency is one of the biggest advantages of OSC over the legacy clients: if you know the name of the resource type you wish to work with, you can pretty accurately guess the command and its structure. This is a thing that operators have consistently said they love about OSC and its one of the key reasons we're trying to get every command to provide full current API implementations in OSC (and SDK). Now I get that the way some of these consistent commands have been implemented has been the cause of contention in the past. I don't imagine it remains any less contentious today. However, these patterns are well-understood, well-known patterns that have for the most part worked just fine for close to a decade now. The kind of patterns I'm thinking about include: * The command to create a new resource should always take the format '<resource> create <human-readable identifer> * The command to modify some property of a resource should always take the format '<resource> set --property=value <name-or-identifier>' * The command to list, fetch or delete resources should always take the format '<resource> list', '<resource> get <name-or-identifier>', and '<resource> delete <name-or-identifier>', respectively. * Boolean options should always take the form of flags with an alternate negative option like '--flag' and '--no-flag', rather than '-- flag=<true|false>' * And a couple of other things that we tend to highlight in reviews. We want to preserve this behavior, lest OSC lose this huge USP and devolve into a muddle mess of different ideas and various individuals'/teams' preferences. I'm more than happy to discuss and debate this stuff with anyone who's interested and we'll continue reviewing each patch on its merit and providing exceptions to these rules where they make sense, but it will remain an ongoing goal and it's something we'd like people to consider when working on OSC itself or any of its plugins. I will now get off my pedestal/ivory tower 🗼 Thanks! Stephen PS: I'm talking here about the command themselves, not their implementations. We do somethings extra in OSC that are user helpful, like allowing users to identify resources by their name in addition to by their UUIDs. We also currently do things that no so user helpful, like crashing and burning if the name lookups fail (I'm thinking about the various Glance-related commands that error out if a project name/ID is passed to a command and the user can't look up that project). These are things we're more than willing to fix and will happily accept patches for :) [1] https://review.opendev.org/c/openstack/python-openstackclient/+/865377

6 13

[neutron] Neutron drivers meeting cancelled
by Rodolfo Alonso Hernandez 25 Nov '22

25 Nov '22

Hello Neutrinos: Due to the lack of agenda and quorum this week, the Neutron drivers meeting is cancelled today. Have a nice weekend and see you next week!

1 0

[tacker] Tacker's Legacy API deprecation
by Ayumu Ueha (Fujitsu) 25 Nov '22

25 Nov '22

Hi Tacker users, Tacker team is going to mark the Tacker's Legacy APIs [1] (excluding VIM feature) to "deprecated" in Antelope cycle. Please see etherpad [2] about list of target APIs. We follow deprecation guideline [3] of OpenStack, and need to know how many users use Tacker's Legacy API. Please let me know if anyone still uses the Legacy API that will be marked "deprecated" via Rest-API or CLI(python-tackerclient) or GUI(tacker-horizon). If no one is using it, we will obsolete it in C cycle as planned. Thanks. [1] https://docs.openstack.org/api-ref/nfv-orchestration/v1/legacy.html [2] https://etherpad.opendev.org/p/tacker-legacy-deprecation [3] https://docs.openstack.org/project-team-guide/deprecation.html#guidelines Best Regards, Ueha

1 0

[neutron] networking-midonet mantainers
by Rodolfo Alonso Hernandez 25 Nov '22

25 Nov '22

Hello Neutrinos: We have recently found some zuul errors related to networking-midonet. In order to fix them, we have pushed [1]. However, the CI status of this project is not in good shape. This mail is a kind request for maintainers of this project. We need to ensure that the stable branches are still accepting patches and the CI jobs are passing. Thank you in advance. [1] https://review.opendev.org/q/project:openstack%252Fnetworking-midonet+statu…

2 1

[Openstack-Magnum] Health Check without Floating IP
by Nguyễn Hữu Khôi 24 Nov '22

24 Nov '22

Hello guys. I have used Magnum to setup k8s cluster and I dont use floating ip then my cluster show as below: [image: image.png] I used provider network only. Could you tell me if there is any way to have a health check? And Is there any way to setup k8s multi master without loadbalancer? Many thanks Nguyen Huu Khoi

1 0

[swift] Periodically crashes of proxy-server
by Ришат Азизов 24 Nov '22

24 Nov '22

Hello! Periodically we get "UNCAUGHT EXCEPTION#012Traceback" errors on swift-proxy, log attached to this email. After that the swift-proxy process crashes, clients get 502 errors. Could you please help with this? Swift version - yoga 2.29.1. Thank you. Regards.

1 1

[CloudKitty] use of Monasca
by Rafael Weingärtner 24 Nov '22

24 Nov '22

Hello guys, As discussed in the PTG [1], in October, we wanted to check with the community if there are people using CloudKitty with Monasca. This discussion was brought up during the PTG that Kolla-ansible is deprecating support to Monasca, and we wanted to check if others are using CloudKitty with Monasca. This integration is not being actively tested and maintained; therefore, we are considering the issue of a deprecation notice and further removal of the integration. What do you guys think? Are there people using CloudKitty with Monasca? [1] https://etherpad.opendev.org/p/oct2022-ptg-cloudkitty -- Rafael Weingärtner

1 1

“Can not allocate kernel buffer” when I use officail ubuntu image to create instance
by 韩光宇 24 Nov '22

24 Nov '22

Hi, all I download ubuntu focal-server-cloudimg-amd64.img from officail website[1]. And when I use it to creae instance, I can access the grub interface in horizon vnc. But if I choose "Ubuntu", I get: error: cannot allocate kernel buffer. error: you need to load the kernel first. Can I get some advice on how I should use it properly to create instances [1] https://cloud-images.ubuntu.com/focal/20221121/focal-server-cloudimg-amd64.…

1 1

[manila] Weekly meeting cancelled (Nov 24th 2022)
by Carlos Silva 23 Nov '22

23 Nov '22

Hello, Zorillas! Since there are some holidays in the US in the next few days, and some of our usual crowd will be offline, we are cancelling tomorrow's weekly meeting. The next Manila weekly meeting will be on December 1st. If you would like to chat about something urgent, please ping me on IRC. Sorry for the late notice. Thanks, carloss

1 0

[largescale-sig] Next meeting: Nov 23, 15utc
by Thierry Carrez 23 Nov '22

23 Nov '22

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 15UTC. You can doublecheck how that UTC time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20221123T15 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 1