From satish.txt at gmail.com Thu Sep 1 01:58:02 2022 From: satish.txt at gmail.com (Satish Patel) Date: Wed, 31 Aug 2022 21:58:02 -0400 Subject: [election][openstack-ansible] PTL candidacy for Antelope cycle In-Reply-To: References: Message-ID: +1 On Wed, Aug 31, 2022 at 2:08 PM Dmitriy Rabotyagov wrote: > Hello. > > I want to self-nominate for the role of OpenStack-Ansible PTL for the > Antelope > release cycle. > > As always, my goal will be to constantly improve existing code, make > deployments and further operations as reliable as possible. > > For the previous cycle we have reached some of previously defined goals, > like adding a `service` role, finally implementing service_token_roles > and support > of CentOS 9 Stream, but there is still room for improvement for role > testing. > > With the return of live events I will do my best to ensure project > presence on > them and get in touch with operators to gain feedback for project future > improvement. > > -- > Kind regards, > Dmitriy Rabotyagov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.rohmann at inovex.de Thu Sep 1 12:35:55 2022 From: christian.rohmann at inovex.de (Christian Rohmann) Date: Thu, 1 Sep 2022 14:35:55 +0200 Subject: [cinder] experiences with S3 cinder-backup driver // client-side encryption feature Message-ID: <95aca8da-ac14-5caf-950c-ddccf65d50a0@inovex.de> Hello openstack-discuss and cinder-backup users! There is an S3 driver available for cinder-backup since the Wallaby release already, see https://docs.openstack.org/releasenotes/cinder/wallaby.html#relnotes-18-0-0-stable-wallaby-new-features. ?1) I was wondering if anybody already used that on a somewhat larger scale and what you experiences are about performance, stability and compatibility? ?2) What object storage implementation or external service were / are you using? ?3) While there are options like "backup_s3_sse_customer_algorithm" and "backup_s3_sse_customer_key" make use of server-side-encryption (SSE), ?there seems to be no way to encrypt the data before actually sending it to the remote S3 (read: client-side encryption). ?Since the boto3 Python SDK by AWS is used, which does not actually implement CSE, like other language SDKs do (see my issue: https://github.com/boto/boto3/issues/3395), ?it seems obvious why that is not a totally low-hanging fruit. But there are ways to add this, check out the references to e.g. https://github.com/StephenSorriaux/s3-encryption ?in the mentioned boto3 issue. ?Encrypting data before sending it off to a potentially externally operated service seems like a nice feature. ?Even a single encryption key would then protect that data from having to trust a 3rd party. ?I know encrypted cinder volumes would also work, but they are not as commonly used. ?*? Is CSE something that others would also like to see for the S3 driver? ?*? Cinder devs, would this maybe be worth a spec for the next cycle? Regards Christian From challengingway at hotmail.com Thu Sep 1 06:48:54 2022 From: challengingway at hotmail.com (=?utf-8?B?6ZmIIOiWhw==?=) Date: Thu, 1 Sep 2022 06:48:54 +0000 Subject: =?utf-8?B?5Zue5aSNOiBoZWxwOiBzZXQgaXJvbmljIGluc3BlY3QgYXV0b2Rpc2NvdmVy?= =?utf-8?Q?y_failed?= In-Reply-To: References: Message-ID: I've successfully run this function. It's my fault that miss configure the ironic api url and inspect call back url. Regards, Wei ________________________________ ???: ? ? ????: 2022?8?30? 17:57 ???: openstack-discuss at lists.openstack.org ??: help: set ironic inspect autodiscovery failed Hi All, I'm trying the ironic inspect autodiscovery but failed. What I did: ?????Set the inspector.conf 1. [discovery] enroll_node_driver = ipmi [processing] permit_active_introspection = true processing_hooks = $default_processing_hooks,extra_hardware,lldp_basic Configure the python agent: inspection_callback_url: There's no node automatically added. I enter the host and read the log of python agent, no inspect related log. Could anybody give any advice about how to triage or setup correctly? Thanks & Regards, Wei -------------- next part -------------- An HTML attachment was scrubbed... URL: From ltomasbo at redhat.com Thu Sep 1 06:54:57 2022 From: ltomasbo at redhat.com (Luis Tomas Bolivar) Date: Thu, 1 Sep 2022 08:54:57 +0200 Subject: [ovn-bgp-agent][neutron] - expose_tenant_networks bug In-Reply-To: References: <693D46D4-3DD7-4B93-BC90-571FEC2B6F4C@gmail.com> Message-ID: On Wed, Aug 31, 2022 at 9:09 PM Satish Patel wrote: > Hi Luis, > > Here are the requested things which you asked for. > > ### Versions > > pyroute2 = 0.7.2 > openvswitch-switch = 2.17.0-0ubuntu1~cloud0 > ovn = 22.03.0-0ubuntu1~cloud0 > devstack master branch > > ### Rack-1-host-2 > > vagrant at rack-1-host-2:~$ ip rule > 0: from all lookup local > 1000: from all lookup [l3mdev-table] > 32000: from all to 10.0.0.1/26 lookup br-ex > 32000: from all to 172.16.1.144 lookup br-ex > 32000: from all to 172.16.1.148 lookup br-ex > 32766: from all lookup main > 32767: from all lookup default > > > vagrant at rack-1-host-2:~$ ip route show table br-ex > default dev br-ex scope link > 10.0.0.0/26 via 172.16.1.144 dev br-ex > 172.16.1.144 dev br-ex scope link > 172.16.1.148 dev br-ex scope link > > This above looks like it has worked, it exposed the network properly in there, so it seems it is just missing the IP addition for some reason. > ### Rack-2-host-1 > > vagrant at rack-2-host-1:~$ ip rule > 0: from all lookup local > 1000: from all lookup [l3mdev-table] > 32000: from all to 172.16.1.143 lookup br-ex > 32766: from all lookup main > 32767: from all lookup default > > > vagrant at rack-2-host-1:~$ ip route show table br-ex > default dev br-ex scope link > 172.16.1.143 dev br-ex scope link > > > #### I have quickly cloned the latest branch of ovn-bgp-agent and ran and > found the following error. Assuming your patch is part of that master > branch. > Yes, it is, it got merged yesterday. > > rack-1-host-2: https://paste.opendev.org/show/bWbhmbzbi8YHGZsbhUAb/ > Umm, same error... I'll need to check that locally to see if I'm able to reproduce it. Perhaps worth to rewrite this: extra_routes.append( ndb.routes[{'table': ovn_routing_tables[bridge], 'dst': dst, 'family': AF_INET}] As this to better see where the problem is: ovn_table = ovn_routing_tables[bridge] found_route = ndb.routes[{'table': ovn_table, 'dst': dst, 'family': AF_INET}] extra_routes.append(round_route) > > > Notes: This is bug or something else - > https://opendev.org/x/ovn-bgp-agent/src/branch/master/ovn_bgp_agent/privileged/vtysh.py#L27 > > I have to replace the above Line:27 code of vtysh to the following to fix > the vtysh error. > > > @ovn_bgp_agent.privileged.vtysh_cmd.entrypoint > > def run_vtysh_config(frr_config_file): > > vtysh_command = "copy {} running-config".format(frr_config_file) > > full_args = ['/usr/bin/vtysh', '--vty_socket', > constants.FRR_SOCKET_PATH, 'c'] > > full_args.extend(vtysh_command.split(' ')) > Umm, weird, what exception was being raised? BTW, feel free to send any patch with fixes to the project! > On Wed, Aug 31, 2022 at 3:51 AM Luis Tomas Bolivar > wrote: > >> >> >> On Wed, Aug 31, 2022 at 9:12 AM Luis Tomas Bolivar >> wrote: >> >>> See below >>> >>> >>> On Tue, Aug 30, 2022 at 10:14 PM Satish Patel >>> wrote: >>> >>>> Hi Luis, >>>> >>>> I have redeploy my lab and i have following components >>>> >>>> rack-1-host-1 - controller >>>> rack-1-host-2 - compute1 >>>> rack-2-host-1 - compute2 >>>> >>>> >>>> # I am running ovn-bgp-agent on only two compute nodes compute1 and >>>> compute2 >>>> [DEFAULT] >>>> debug=False >>>> expose_tenant_networks=True >>>> driver=ovn_bgp_driver >>>> reconcile_interval=120 >>>> ovsdb_connection=unix:/var/run/openvswitch/db.sock >>>> >>>> ### without any VM at present i can see only router gateway IP on >>>> rack1-host-2 >>>> >>> >>> Yep, this is what is expected at this point. >>> >>> >>>> >>>> vagrant at rack-1-host-2:~$ ip a show ovn >>>> 37: ovn: mtu 1500 qdisc noqueue master >>>> ovn-bgp-vrf state UNKNOWN group default qlen 1000 >>>> link/ether 0a:f7:6e:e0:19:69 brd ff:ff:ff:ff:ff:ff >>>> inet 172.16.1.144/32 scope global ovn >>>> valid_lft forever preferred_lft forever >>>> inet6 fe80::8f7:6eff:fee0:1969/64 scope link >>>> valid_lft forever preferred_lft forever >>>> >>>> >>>> vagrant at rack-2-host-1:~$ ip a show ovn >>>> 15: ovn: mtu 1500 qdisc noqueue master >>>> ovn-bgp-vrf state UNKNOWN group default qlen 1000 >>>> link/ether 56:61:6b:29:ac:29 brd ff:ff:ff:ff:ff:ff >>>> inet6 fe80::5461:6bff:fe29:ac29/64 scope link >>>> valid_lft forever preferred_lft forever >>>> >>>> >>>> ### Lets create vm1 which is endup on rack1-host-2 but it didn't expose >>>> vm1 ip (tenant ip) same with rack-2-host-1 >>>> >>>> vagrant at rack-1-host-2:~$ ip a show ovn >>>> 37: ovn: mtu 1500 qdisc noqueue master >>>> ovn-bgp-vrf state UNKNOWN group default qlen 1000 >>>> link/ether 0a:f7:6e:e0:19:69 brd ff:ff:ff:ff:ff:ff >>>> inet 172.16.1.144/32 scope global ovn >>>> valid_lft forever preferred_lft forever >>>> inet6 fe80::8f7:6eff:fee0:1969/64 scope link >>>> valid_lft forever preferred_lft forever >>>> >>> >>> It should be exposed here, what about the output of "ip rule" and "ip >>> route show table br-ex"? >>> >>> >>>> >>>> vagrant at rack-2-host-1:~$ ip a show ovn >>>> 15: ovn: mtu 1500 qdisc noqueue master >>>> ovn-bgp-vrf state UNKNOWN group default qlen 1000 >>>> link/ether 56:61:6b:29:ac:29 brd ff:ff:ff:ff:ff:ff >>>> inet6 fe80::5461:6bff:fe29:ac29/64 scope link >>>> valid_lft forever preferred_lft forever >>>> >>>> >>>> ### Lets attach a floating ip to vm1 and see. now i can see 10.0.0.17 >>>> vm1 ip got expose on rack-1-host-2 same time nothing on rack-2-host-1 ( ofc >>>> because no vm running on it) >>>> >>>> vagrant at rack-1-host-2:~$ ip a show ovn >>>> 37: ovn: mtu 1500 qdisc noqueue master >>>> ovn-bgp-vrf state UNKNOWN group default qlen 1000 >>>> link/ether 0a:f7:6e:e0:19:69 brd ff:ff:ff:ff:ff:ff >>>> inet 172.16.1.144/32 scope global ovn >>>> valid_lft forever preferred_lft forever >>>> inet 10.0.0.17/32 scope global ovn >>>> valid_lft forever preferred_lft forever >>>> inet 172.16.1.148/32 scope global ovn >>>> valid_lft forever preferred_lft forever >>>> inet6 fe80::8f7:6eff:fee0:1969/64 scope link >>>> valid_lft forever preferred_lft forever >>>> >>> >>> There is also a resync action happening every 120 seconds... Perhaps for >>> some reason the initial addition of 10.0.0.17 failed and then the sync >>> discovered it and added it (and it matched with the time you added the FIP >>> more or less). >>> >>> But events are managed one by one and those 2 are different, so adding >>> the FIP is not adding the internal IP. It was probably a sync action. >>> >>> >>>> >>>> vagrant at rack-2-host-1:~$ ip a show ovn >>>> 15: ovn: mtu 1500 qdisc noqueue master >>>> ovn-bgp-vrf state UNKNOWN group default qlen 1000 >>>> link/ether 56:61:6b:29:ac:29 brd ff:ff:ff:ff:ff:ff >>>> inet6 fe80::5461:6bff:fe29:ac29/64 scope link >>>> valid_lft forever preferred_lft forever >>>> >>>> >>>> #### Lets spin up vm2 which should end up on other compute node which >>>> is rack-2-host-1 ( no change yet.. vm2 ip wasn't exposed anywhere yet. ) >>>> >>>> vagrant at rack-1-host-2:~$ ip a show ovn >>>> 37: ovn: mtu 1500 qdisc noqueue master >>>> ovn-bgp-vrf state UNKNOWN group default qlen 1000 >>>> link/ether 0a:f7:6e:e0:19:69 brd ff:ff:ff:ff:ff:ff >>>> inet 172.16.1.144/32 scope global ovn >>>> valid_lft forever preferred_lft forever >>>> inet 10.0.0.17/32 scope global ovn >>>> valid_lft forever preferred_lft forever >>>> inet 172.16.1.148/32 scope global ovn >>>> valid_lft forever preferred_lft forever >>>> inet6 fe80::8f7:6eff:fee0:1969/64 scope link >>>> valid_lft forever preferred_lft forever >>>> >>>> >>>> vagrant at rack-2-host-1:~$ ip a show ovn >>>> 15: ovn: mtu 1500 qdisc noqueue master >>>> ovn-bgp-vrf state UNKNOWN group default qlen 1000 >>>> link/ether 56:61:6b:29:ac:29 brd ff:ff:ff:ff:ff:ff >>>> inet6 fe80::5461:6bff:fe29:ac29/64 scope link >>>> valid_lft forever preferred_lft forever >>>> >>>> >>>> #### Lets again attach floating ip to vm2 ( so far nothing changed, >>>> technically it should expose IP on rack-1-host-2 ) >>>> >>>> vagrant at rack-1-host-2:~$ ip a show ovn >>>> 37: ovn: mtu 1500 qdisc noqueue master >>>> ovn-bgp-vrf state UNKNOWN group default qlen 1000 >>>> link/ether 0a:f7:6e:e0:19:69 brd ff:ff:ff:ff:ff:ff >>>> inet 172.16.1.144/32 scope global ovn >>>> valid_lft forever preferred_lft forever >>>> inet 10.0.0.17/32 scope global ovn >>>> valid_lft forever preferred_lft forever >>>> inet 172.16.1.148/32 scope global ovn >>>> valid_lft forever preferred_lft forever >>>> inet6 fe80::8f7:6eff:fee0:1969/64 scope link >>>> valid_lft forever preferred_lft forever >>>> >>>> The IP of the second VM should be exposed here ^, in rack-1-host-2, >>>> while the FIP in the other compute (rack-2-host-1) >>>> >>> >>> >>>> vagrant at rack-2-host-1:~$ ip a show ovn >>>> 15: ovn: mtu 1500 qdisc noqueue master >>>> ovn-bgp-vrf state UNKNOWN group default qlen 1000 >>>> link/ether 56:61:6b:29:ac:29 brd ff:ff:ff:ff:ff:ff >>>> inet 172.16.1.143/32 scope global ovn >>>> valid_lft forever preferred_lft forever >>>> inet6 fe80::5461:6bff:fe29:ac29/64 scope link >>>> valid_lft forever preferred_lft forever >>>> >>>> >>>> Here is the logs - https://paste.opendev.org/show/bRThivJE4wvEN92DXJUo/ >>>> >>>> >>> >>> What node these logs belong to? rack-1-host-2? >>> >>> And are you running with the latest code? Looks the problem is on the >>> sync function when trying to ensure the routing table entry for br-ex. It >>> prints this: >>> >>> 2022-08-30 20:12:54.541 8318 DEBUG ovn_bgp_agent.utils.linux_net [-] Found routing table for br-ex with: ['200', 'br-ex'] >>> >>> So definitely ovn_routing_tables should be initialized with {'br-ex': >>> 200}, so I don't really get where the KeyError comes from... >>> >>> Unless it is not accessing the dict, but accessing the ndb.routes... >>> perhaps with the pyroute2 version you have, the family parameter is needed >>> there. Let me send a patch that you can try with >>> >> >> This is the patch https://review.opendev.org/c/x/ovn-bgp-agent/+/855062. >> Give it a try and let me know if the error you are seeing in the logs goes >> away with it >> >> >>> >>>> On Thu, Aug 25, 2022 at 6:25 AM Luis Tomas Bolivar >>>> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Aug 25, 2022 at 11:31 AM Satish Patel >>>>> wrote: >>>>> >>>>>> Hi Luis, >>>>>> >>>>>> Very interesting, you are saying it will only expose tenant ip on >>>>>> gateway port node? Even we have DVR setup in cluster correct? >>>>>> >>>>> >>>>> Almost. The path is the same as in a DVR setup without BGP (with the >>>>> difference you can reach the internal IP). In a DVR setup, when the VM is >>>>> in a tenant network, without a FIP, the traffic goes out through the cr-lrp >>>>> (ovn router gateway port), i.e., the node hosting that port which is >>>>> connecting the router where the subnet where the VM is to the provider >>>>> network. >>>>> >>>>> Note this is a limitation due to how ovn is used in openstack neutron, >>>>> where traffic needs to be injected into OVN overlay in the node holding the >>>>> cr-lrp. We are investigating possible ways to overcome this limitation and >>>>> expose the IP right away in the node hosting the VM. >>>>> >>>>> >>>>>> Does gateway node going to expose ip for all other compute nodes? >>>>>> >>>>> >>>>>> What if I have multiple gateway node? >>>>>> >>>>> >>>>> No, each router connected to the provider network will have its own >>>>> ovn router gateway port, and that can be allocated in any node which has >>>>> "enable-chassis-as-gw". What is true is that all VMs in a tenant networks >>>>> connected to the same router, will be exposed in the same location . >>>>> >>>>> >>>>>> Did you configure that flag on all node or just gateway node? >>>>>> >>>>> >>>>> I usually deploy with 3 controllers which are also my "networker" >>>>> nodes, so those are the ones having the enable-chassis-as-gw flag. >>>>> >>>>> >>>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>> On Aug 25, 2022, at 4:14 AM, Luis Tomas Bolivar >>>>>> wrote: >>>>>> >>>>>> ? >>>>>> I tested it locally and it is exposing the IP properly in the node >>>>>> where the ovn router gateway port is allocated. Could you double check if >>>>>> that is the case in your setup too? >>>>>> >>>>>> On Wed, Aug 24, 2022 at 8:58 AM Luis Tomas Bolivar < >>>>>> ltomasbo at redhat.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Aug 23, 2022 at 6:04 PM Satish Patel >>>>>>> wrote: >>>>>>> >>>>>>>> Folks, >>>>>>>> >>>>>>>> I am setting up ovn-bgp-agent lab in "BGP mode" and i found >>>>>>>> everything working great except expose tenant network >>>>>>>> https://ltomasbo.wordpress.com/2021/02/04/ovn-bgp-agent-testing-setup/ >>>>>>>> >>>>>>>> >>>>>>>> Lab Summary: >>>>>>>> >>>>>>>> 1 controller node >>>>>>>> 3 compute node >>>>>>>> >>>>>>>> ovn-bgp-agent running on all compute node because i am using >>>>>>>> "enable_distributed_floating_ip=True" >>>>>>>> >>>>>>> >>>>>>>> ovn-bgp-agent config: >>>>>>>> >>>>>>>> [DEFAULT] >>>>>>>> debug=False >>>>>>>> expose_tenant_networks=True >>>>>>>> driver=ovn_bgp_driver >>>>>>>> reconcile_interval=120 >>>>>>>> ovsdb_connection=unix:/var/run/openvswitch/db.sock >>>>>>>> >>>>>>>> I am not seeing my vm on tenant ip getting exposed but when i >>>>>>>> attach FIP which gets exposed in loopback address. here is the full trace >>>>>>>> of debug logs: https://paste.opendev.org/show/buHiJ90nFgC1JkQxZwVk/ >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> It is not exposed in any node, right? Note when >>>>>>> expose_tenant_network is enabled, the traffic to the tenant VM is exposed >>>>>>> in the node holding the cr-lrp (ovn router gateway port) for the router >>>>>>> connecting the tenant network to the provider one. >>>>>>> >>>>>>> The FIP will be exposed in the node where the VM is. >>>>>>> >>>>>>> On the other hand, the error you see there should not happen, so >>>>>>> I'll investigate why that is and also double check if the >>>>>>> expose_tenant_network flag is broken somehow. >>>>>>> >>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> LUIS TOM?S BOL?VAR >>>>>>> Principal Software Engineer >>>>>>> Red Hat >>>>>>> Madrid, Spain >>>>>>> ltomasbo at redhat.com >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> LUIS TOM?S BOL?VAR >>>>>> Principal Software Engineer >>>>>> Red Hat >>>>>> Madrid, Spain >>>>>> ltomasbo at redhat.com >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> LUIS TOM?S BOL?VAR >>>>> Principal Software Engineer >>>>> Red Hat >>>>> Madrid, Spain >>>>> ltomasbo at redhat.com >>>>> >>>>> >>>> >>> >>> -- >>> LUIS TOM?S BOL?VAR >>> Principal Software Engineer >>> Red Hat >>> Madrid, Spain >>> ltomasbo at redhat.com >>> >>> >> >> >> -- >> LUIS TOM?S BOL?VAR >> Principal Software Engineer >> Red Hat >> Madrid, Spain >> ltomasbo at redhat.com >> >> > -- LUIS TOM?S BOL?VAR Principal Software Engineer Red Hat Madrid, Spain ltomasbo at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.urdin at binero.com Thu Sep 1 13:48:48 2022 From: tobias.urdin at binero.com (Tobias Urdin) Date: Thu, 1 Sep 2022 13:48:48 +0000 Subject: =?utf-8?B?UmU6IFthbGxdwqBbb3Nsby5tZXNzYWdpbmddIEludGVyZXN0IGluIGNvbGxh?= =?utf-8?Q?boration_on_a_NATS_driver?= In-Reply-To: References: <52AA12A0-AE67-4EF7-B924-DE1F2873B909@binero.com> Message-ID: Hello Kai, Great to hear that you?re interested! I?m currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first). Best regards Tobias > On 30 Aug 2022, at 18:32, Kai Bojens wrote: > > Am 29.08.22 um 15:46 schrieb Tobias Urdin: > >> If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to >> reach out. I?m hoping somebody will bite but atleast I?ve put it out there for all of you. > > Hi, > I am very much interested to take a closer look at your work and maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack. > > As I'm pretty new to the messaging topic and had just heard of NATS and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ. > > This brings me to the most important question: Where do you run and test your code? > > Greetings, > Kai From sbauza at redhat.com Thu Sep 1 13:54:35 2022 From: sbauza at redhat.com (Sylvain Bauza) Date: Thu, 1 Sep 2022 15:54:35 +0200 Subject: [PTL][release] Zed Cycle Highlights In-Reply-To: References: Message-ID: Le mar. 30 ao?t 2022 ? 17:45, El?d Ill?s a ?crit : > Hi, > > This is a reminder, that *this week* is the week for Cycle highlights > [1][2]! They need to be added to deliverable yamls so that they can be > included in release marketing preparations. (See the details about how > to add them at the project team guide [3].) > > I'm confused. If I read correctly [3] it says that cycle highlights can be delivered at RC1 which makes sense to me as it's post-FeatureFreeze. Asking for cycle highlights the week of the FeatureFreeze is both counterproductive and non-logic : While some changes are still on debate and while we're not yet done with merging features, we need to write a document saying what we'll get. Couldn't we officially accept the projects to provide their highlights only at RC1 ? Is it a marketing problem because RC1 is closer to the GA ? -Sylvain > [1] https://releases.openstack.org/zed/schedule.html > [2] https://releases.openstack.org/zed/schedule.html#z-cycle-highlights > [3] https://docs.openstack.org/project-team-guide/release-management.html#cycle-highlights > > Thanks, > > El?d Ill?s > irc: elodilles > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From katonalala at gmail.com Thu Sep 1 14:10:28 2022 From: katonalala at gmail.com (Lajos Katona) Date: Thu, 1 Sep 2022 16:10:28 +0200 Subject: [neutron] Drivers meeting - Friday 02.09.2022 - cancelled Message-ID: 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Thu Sep 1 14:10:32 2022 From: hberaud at redhat.com (Herve Beraud) Date: Thu, 1 Sep 2022 16:10:32 +0200 Subject: [all] [oslo.messaging] Interest in collaboration on a NATS driver In-Reply-To: References: <52AA12A0-AE67-4EF7-B924-DE1F2873B909@binero.com> Message-ID: +1, I'm also interested in this topic. I did some tests with nats-py to see how it works and I'm volunteering to go further with this technology. Let me know if you need reviews, help etc... Le jeu. 1 sept. 2022 ? 15:50, Tobias Urdin a ?crit : > Hello Kai, > > Great to hear that you?re interested! > I?m currently just testing this as a POC directly in devstack so there is > real-world testing (not should it yet I think, needs more development > first). > > Best regards > Tobias > > > On 30 Aug 2022, at 18:32, Kai Bojens wrote: > > > > Am 29.08.22 um 15:46 schrieb Tobias Urdin: > > > >> If anybody, or any company, out there would be interested in > collaborating in a project to bring this support and maintain it feel free > to > >> reach out. I?m hoping somebody will bite but atleast I?ve put it out > there for all of you. > > > > Hi, > > I am very much interested to take a closer look at your work and maybe > contribute to it. Although I'm working with OpenStack for my employer at > the moment, I'd do this in my spare time as I'm not sure that I can > convince him to add another staging system with a full OpenStack > installation just for developing a RabbitMQ replacement. That's not on our > agenda as we are mostly users and not developers of OpenStack. > > > > As I'm pretty new to the messaging topic and had just heard of NATS and > your idea, I'll first would have to dive into NATS and then I would take a > closer look at your code and maybe try to create some documentation or > tests. So, I can't promise anything but as I said I'm very interested in > your approach as I also see the massive load from RabbitMQ. > > > > This brings me to the most important question: Where do you run and test > your code? > > > > Greetings, > > Kai > > -- Herv? Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From elod.illes at est.tech Thu Sep 1 14:21:29 2022 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Thu, 1 Sep 2022 16:21:29 +0200 Subject: [PTL][release] Zed Cycle Highlights In-Reply-To: References: Message-ID: <59b540d3-f41f-b8c7-1574-d08dcdf3974d@est.tech> I think the deadline is more like something to connected to Feature Freeze. ~After Feature Freeze we know what's in the cycle. If a project requests a Feature Freeze Exception, then of course, the FF will happen somewhere between official FF date (Milestone 3) and RC1, and hopefully closer to Milestone 3 date than RC1 date. I understand that PTLs are busy with reviewing the last feature patches, but I think this is more like a best effort, too, to prepare it as soon as possible, after the Feature Freeze. I don't know when exactly the Marketing team is processing the cycle highlights, but I guess they also handles these a bit flexible way. Probably to generally state that highlights are only needed by RC1 would give them much less time, more postponed / missing docs handling / more hurry. So while I think we have a bit of a flexibility with the deadline (1-2 working days don't really count), the best is to try to prepare it as soon as possible. Anyone from the Marketing team or from Release team, correct me if i'm wrong. El?d On 2022. 09. 01. 15:54, Sylvain Bauza wrote: > > > Le?mar. 30 ao?t 2022 ??17:45, El?d Ill?s a ?crit?: > > Hi, > > This is a reminder, that *this week* is the week for Cycle highlights > [1][2]! They need to be added to deliverable yamls so that they can be > included in release marketing preparations. (See the details about how > to add them at the project team guide [3].) > > > I'm confused. If I read correctly [3] it says that cycle highlights > can be delivered at RC1 which makes sense to me as it's > post-FeatureFreeze. > Asking for cycle highlights the week of the FeatureFreeze is both > counterproductive and non-logic : While some changes are still on > debate and while we're not yet done with merging features, we need to > write a document saying what we'll get. > > Couldn't we officially accept the projects to provide their highlights > only at RC1 ? Is it a marketing problem because RC1 is closer to the GA ? > -Sylvain > > > [1]https://releases.openstack.org/zed/schedule.html > [2]https://releases.openstack.org/zed/schedule.html#z-cycle-highlights > [3] > https://docs.openstack.org/project-team-guide/release-management.html#cycle-highlights > > Thanks, > > El?d Ill?s > irc: elodilles > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdhasman at redhat.com Thu Sep 1 14:38:43 2022 From: rdhasman at redhat.com (Rajat Dhasmana) Date: Thu, 1 Sep 2022 20:08:43 +0530 Subject: [PTL][release] Zed Cycle Highlights In-Reply-To: <59b540d3-f41f-b8c7-1574-d08dcdf3974d@est.tech> References: <59b540d3-f41f-b8c7-1574-d08dcdf3974d@est.tech> Message-ID: Hi Elod, I share the same concern as Sylvain. In cinder, we have provided an extension of 1 week after the FF to features so we are really not sure which changes are going to get in. I can prepare the highlights with the features we already have merged but that won't include the whole list. On Thu, Sep 1, 2022 at 7:56 PM El?d Ill?s wrote: > I think the deadline is more like something to connected to Feature > Freeze. ~After Feature Freeze we know what's in the cycle. If a project > requests a Feature Freeze Exception, then of course, the FF will happen > somewhere between official FF date (Milestone 3) and RC1, and hopefully > closer to Milestone 3 date than RC1 date. > > I understand that PTLs are busy with reviewing the last feature patches, > but I think this is more like a best effort, too, to prepare it as soon as > possible, after the Feature Freeze. > > I don't know when exactly the Marketing team is processing the cycle > highlights, but I guess they also handles these a bit flexible way. > Probably to generally state that highlights are only needed by RC1 would > give them much less time, more postponed / missing docs handling / more > hurry. So while I think we have a bit of a flexibility with the deadline > (1-2 working days don't really count), the best is to try to prepare it as > soon as possible. Anyone from the Marketing team or from Release team, > correct me if i'm wrong. > > El?d > > On 2022. 09. 01. 15:54, Sylvain Bauza wrote: > > > > Le mar. 30 ao?t 2022 ? 17:45, El?d Ill?s > a ?crit : > >> Hi, >> >> This is a reminder, that *this week* is the week for Cycle highlights >> [1][2]! They need to be added to deliverable yamls so that they can be >> included in release marketing preparations. (See the details about how >> to add them at the project team guide [3].) >> >> > I'm confused. If I read correctly [3] it says that cycle highlights can be > delivered at RC1 which makes sense to me as it's post-FeatureFreeze. > Asking for cycle highlights the week of the FeatureFreeze is both > counterproductive and non-logic : While some changes are still on debate > and while we're not yet done with merging features, we need to write a > document saying what we'll get. > > Couldn't we officially accept the projects to provide their highlights > only at RC1 ? Is it a marketing problem because RC1 is closer to the GA ? > -Sylvain > > > >> [1] https://releases.openstack.org/zed/schedule.html >> [2] https://releases.openstack.org/zed/schedule.html#z-cycle-highlights >> [3] https://docs.openstack.org/project-team-guide/release-management.html#cycle-highlights >> >> Thanks, >> >> El?d Ill?s >> irc: elodilles >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jungleboyj at gmail.com Thu Sep 1 14:41:02 2022 From: jungleboyj at gmail.com (Jay Bryant) Date: Thu, 1 Sep 2022 09:41:02 -0500 Subject: [all][elections][tc] TC Election Non-Candidacy ... Message-ID: <95656b9d-7b2a-d2a5-8d67-f5bd1ee98a0e@gmail.com> All, I wanted to take a moment to let everyone know that I am not going to be running for the TC, this time around. The last two years on the TC have been a great experience and I am grateful for the trust the community put in me. At this point, however, I think it is best to let others who may want to join the TC have the opportunity to do so. Again, thank you for this opportunity to support the community over the last couple of years! Sincerely, Jay Bryant (jungleboyj) From radoslaw.piliszek at gmail.com Thu Sep 1 15:05:45 2022 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 1 Sep 2022 17:05:45 +0200 Subject: [all] [oslo.messaging] Interest in collaboration on a NATS driver In-Reply-To: References: <52AA12A0-AE67-4EF7-B924-DE1F2873B909@binero.com> Message-ID: I have just got to read the documentation of NATS and I think it's the right choice for doing RPC in OpenStack. Let's do this. Count me in as well. For RPC, I think we should base ourselves off the Request-Reply [1] and Queue Groups [2] functionalities of NATS. Regarding tradeoffs, it seems the ones NATS took are favorable in our use case (specifically, having a simple protocol with simple semantics). As I commented on the new NATS WIP changes, we need to revive the old NATS spec (probably as a new change though). I suggest following the (old) advice of Sean to focus on RPC, especially since NATS Core is more suitable for RPC than notifications. [1] https://docs.nats.io/nats-concepts/core-nats/reqreply [2] https://docs.nats.io/nats-concepts/core-nats/queue Cheers, Radek -yoctozepto On Thu, 1 Sept 2022 at 16:11, Herve Beraud wrote: > > +1, I'm also interested in this topic. I did some tests with nats-py to see how it works and I'm volunteering to go further with this technology. > Let me know if you need reviews, help etc... > > Le jeu. 1 sept. 2022 ? 15:50, Tobias Urdin a ?crit : >> >> Hello Kai, >> >> Great to hear that you?re interested! >> I?m currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first). >> >> Best regards >> Tobias >> >> > On 30 Aug 2022, at 18:32, Kai Bojens wrote: >> > >> > Am 29.08.22 um 15:46 schrieb Tobias Urdin: >> > >> >> If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to >> >> reach out. I?m hoping somebody will bite but atleast I?ve put it out there for all of you. >> > >> > Hi, >> > I am very much interested to take a closer look at your work and maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack. >> > >> > As I'm pretty new to the messaging topic and had just heard of NATS and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ. >> > >> > This brings me to the most important question: Where do you run and test your code? >> > >> > Greetings, >> > Kai >> > > > -- > Herv? Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > From allison at openinfra.dev Thu Sep 1 16:02:46 2022 From: allison at openinfra.dev (Allison Price) Date: Thu, 1 Sep 2022 09:02:46 -0700 Subject: [PTL][release] Zed Cycle Highlights In-Reply-To: References: <59b540d3-f41f-b8c7-1574-d08dcdf3974d@est.tech> Message-ID: I can jump in from a release marketing perspective. I think that we have some flexibility while still ensuring we have a cohesive plan for October 5. It would be great if cycle highlights can start rolling in now so we can review them incrementally, but I think we can give teams until the end of next week (September 9) or even early the following week (September 13 at the latest) and still meet all of our deadlines. That said, the September 14 deadline would ideally be a hard deadline, so I would like to not push it past that. If we think that makes more sense from a release perspective, we can make it work from a marketing one. Let me know if that helps. Thanks, Allison > On Sep 1, 2022, at 7:38 AM, Rajat Dhasmana wrote: > > Hi Elod, > > I share the same concern as Sylvain. In cinder, we have provided an extension of 1 week after the FF to features so we are really > not sure which changes are going to get in. I can prepare the highlights with the features we already have merged but that won't > include the whole list. > > > On Thu, Sep 1, 2022 at 7:56 PM El?d Ill?s wrote: > I think the deadline is more like something to connected to Feature Freeze. ~After Feature Freeze we know what's in the cycle. If a project requests a Feature Freeze Exception, then of course, the FF will happen somewhere between official FF date (Milestone 3) and RC1, and hopefully closer to Milestone 3 date than RC1 date. > > I understand that PTLs are busy with reviewing the last feature patches, but I think this is more like a best effort, too, to prepare it as soon as possible, after the Feature Freeze. > > I don't know when exactly the Marketing team is processing the cycle highlights, but I guess they also handles these a bit flexible way. Probably to generally state that highlights are only needed by RC1 would give them much less time, more postponed / missing docs handling / more hurry. So while I think we have a bit of a flexibility with the deadline (1-2 working days don't really count), the best is to try to prepare it as soon as possible. Anyone from the Marketing team or from Release team, correct me if i'm wrong. > > El?d > > > On 2022. 09. 01. 15:54, Sylvain Bauza wrote: >> >> >> Le mar. 30 ao?t 2022 ? 17:45, El?d Ill?s a ?crit : >> Hi, >> >> This is a reminder, that *this week* is the week for Cycle highlights >> [1][2]! They need to be added to deliverable yamls so that they can be >> included in release marketing preparations. (See the details about how >> to add them at the project team guide [3].) >> >> I'm confused. If I read correctly [3] it says that cycle highlights can be delivered at RC1 which makes sense to me as it's post-FeatureFreeze. >> Asking for cycle highlights the week of the FeatureFreeze is both counterproductive and non-logic : While some changes are still on debate and while we're not yet done with merging features, we need to write a document saying what we'll get. >> >> Couldn't we officially accept the projects to provide their highlights only at RC1 ? Is it a marketing problem because RC1 is closer to the GA ? >> -Sylvain >> >> >> [1] https://releases.openstack.org/zed/schedule.html >> [2] https://releases.openstack.org/zed/schedule.html#z-cycle-highlights >> [3] >> https://docs.openstack.org/project-team-guide/release-management.html#cycle-highlights >> >> Thanks, >> >> El?d Ill?s >> irc: elodilles -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Thu Sep 1 16:04:08 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 01 Sep 2022 21:34:08 +0530 Subject: [all][elections][tc] TC Election Non-Candidacy ... In-Reply-To: <95656b9d-7b2a-d2a5-8d67-f5bd1ee98a0e@gmail.com> References: <95656b9d-7b2a-d2a5-8d67-f5bd1ee98a0e@gmail.com> Message-ID: <182f9cba1aa.11f01871f525407.1350651696991063905@ghanshyammann.com> Thank you Jay for all your contribution to TC. -gmann ---- On Thu, 01 Sep 2022 20:11:02 +0530 Jay Bryant wrote --- > All, > > I wanted to take a moment to let everyone know that I am not going to be > running for the TC, this time around. > > The last two years on the TC have been a great experience and I am > grateful for the trust the community put in me. > > At this point, however, I think it is best to let others who may want to > join the TC have the opportunity to do so. > > Again, thank you for this opportunity to support the community over the > last couple of years! > > Sincerely, > > Jay Bryant > > (jungleboyj) > > > From openstack at nemebean.com Thu Sep 1 17:10:35 2022 From: openstack at nemebean.com (Ben Nemec) Date: Thu, 1 Sep 2022 12:10:35 -0500 Subject: [all] [oslo.messaging] Interest in collaboration on a NATS driver In-Reply-To: References: <52AA12A0-AE67-4EF7-B924-DE1F2873B909@binero.com> <6997e750b0ca41a4ac610575dda0531a85581f6b.camel@redhat.com> Message-ID: <47ec60f5-fd7c-a5c9-215a-9367a90f61b5@nemebean.com> On 8/29/22 13:20, Rados?aw Piliszek wrote: > On Mon, 29 Aug 2022 at 20:03, Sean Mooney wrote: >>> Finally, have you considered just trying out ZeroMQ? >> ZeroMQ used to be supported in the past but then it was remvoed >> if i understand correctly it only supprot notificaiton or RPC but not both >> i dont recall which but perhapse im miss rememebrign on that point. > > I believe it would be better suited for RPC than notifications, at > least in the simplest form. I believe it was the opposite. ZeroMQ could handle fire-and-forget notifications fine, but when you started trying to coordinate with the receivers the way oslo.messaging does it was missing features that had to be implemented in the o.m driver. Once you added everything needed for a fully functional OpenStack messaging driver you ended up negating a lot of the benefits of ZeroMQ. It just wasn't a good fit for the messaging model we use. Caveat: I am not a messaging expert so I'm just regurgitating the things I've heard from the messaging experts I've discussed this with. > >>> I mean, NATS is probably an overkill for OpenStack services since the >>> majority of them stay static on the hosts they control (think >>> nova-compute, neutron agents - and these are also the pain points that >>> operators want to ease). >> its not any more overkill then rabbitmq is > > True that. Probably. > >> i also dont know waht you mean when you say >> "majority of them stay static on the hosts they control" >> >> NATS is intended a s a cloud native horrizontally scaleable message bus. >> which is exactly what openstack need IMO. > > NATS seems to be tweaked for "come and go" situations which is an > exception in the OpenStack world, not the rule (at least in my view). > I mean, one normally expects to have a preset number of hypervisors > and not them coming and going (which, I agree, is a nice vision, could > be a proper NATS driver, with more awareness in the client projects I > believe, would be an enabler for more dynamic clouds). > > Cheers, > Radek > -yoctozepto > From openstack at nemebean.com Thu Sep 1 17:14:41 2022 From: openstack at nemebean.com (Ben Nemec) Date: Thu, 1 Sep 2022 12:14:41 -0500 Subject: =?UTF-8?B?UmU6IFthbGxdwqBbb3Nsby5tZXNzYWdpbmddIEludGVyZXN0IGluIGNv?= =?UTF-8?Q?llaboration_on_a_NATS_driver?= In-Reply-To: <52AA12A0-AE67-4EF7-B924-DE1F2873B909@binero.com> References: <52AA12A0-AE67-4EF7-B924-DE1F2873B909@binero.com> Message-ID: <3e68ca5a-b1ed-f52f-7870-c00d50e01dbf@nemebean.com> Note that the is an existing spec related to this: https://review.opendev.org/c/openstack/oslo-specs/+/692784 In general I think we were in agreement on adding a NATS driver, but there were some roadblocks. I don't think any implementation work was really done as a result of that. I'm also not sure how much of that discussion is still relevant - for example, would we still require a forked library? On 8/29/22 08:46, Tobias Urdin wrote: > Hello everyone, > > Before continuing on, yes this kind of is a massive effort but it doesn?t have to be, it would be very cool to get a replacement for RabbitMQ > as I?m probably not the only one not satisfied with it. I've proposed a very bare POC in [1] but it's long way from being finished, but atleast some basic devstack is passing. > > NATS [2] is a cloud-native scalable messaging system that supports the one-to-many and pub-sub methods that we can use to implement it as a oslo.messaging driver. > > This would make OpenStack easier to deploy in a highly available fashion, reduce outages related to RabbitMQ, free up memory and CPU usage by RabbitMQ (it?s insane when > using clustering) and embrace a more cloud-native approach for our software that runs the cloud, alternatives is also welcome :) > > The POC has a lot of things that could be improved for example: > ? Do retries and acknowledgements in the library (since NATS does NOT persist messages like RabbitMQ could) > ? Handle reconnects or interruptions (for example resubscribe to topics etc) > ? Timeouts need to be implemented and handled > ? Investigate maximum message payload size > ? Find or maintain a NATS python library that doesn't use async like the official one does > ? Add a lot of testing > ? Cleanup everything noted as TODO in the POC code > > Now I couldn?t possibly pull this off myself without some collaboration with all of you, even though I?m very motivated to just dig in and do > this for the rest of the year and migrate our test fleet there I unfortunately (like everyone else) is juggeling a lot of balls at the same time. > > If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to > reach out. I?m hoping somebody will bite but atleast I?ve put it out there for all of you. > > Best regards > Tobias > > [1] https://review.opendev.org/c/openstack/oslo.messaging/+/848338 > [2] https://nats.io > From radoslaw.piliszek at gmail.com Thu Sep 1 17:21:34 2022 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 1 Sep 2022 19:21:34 +0200 Subject: [all] [oslo.messaging] Interest in collaboration on a NATS driver In-Reply-To: <3e68ca5a-b1ed-f52f-7870-c00d50e01dbf@nemebean.com> References: <52AA12A0-AE67-4EF7-B924-DE1F2873B909@binero.com> <3e68ca5a-b1ed-f52f-7870-c00d50e01dbf@nemebean.com> Message-ID: On Thu, 1 Sept 2022 at 19:15, Ben Nemec wrote: > > Note that the is an existing spec related to this: > https://review.opendev.org/c/openstack/oslo-specs/+/692784 > > In general I think we were in agreement on adding a NATS driver, but > there were some roadblocks. I don't think any implementation work was > really done as a result of that. I'm also not sure how much of that > discussion is still relevant - for example, would we still require a > forked library? There was, but using a long-gone lib: https://review.opendev.org/c/openstack/oslo.messaging/+/680629 I summarised it all in comments to: https://review.opendev.org/c/openstack/oslo.messaging/+/848338 Anyways, as I mentioned in the other part of this thread, the next step would be to revive the spec - I guess this is best done as a new change by Tobias (? well, as he started this). We could borrow some insight from the old spec though. Radek -yoctozepto From sbauza at redhat.com Thu Sep 1 19:52:59 2022 From: sbauza at redhat.com (Sylvain Bauza) Date: Thu, 1 Sep 2022 21:52:59 +0200 Subject: [PTL][release] Zed Cycle Highlights In-Reply-To: References: <59b540d3-f41f-b8c7-1574-d08dcdf3974d@est.tech> Message-ID: Le jeu. 1 sept. 2022 ? 18:02, Allison Price a ?crit : > I can jump in from a release marketing perspective. I think that we have > some flexibility while still ensuring we have a cohesive plan for October > 5. It would be great if cycle highlights can start rolling in now so we can > review them incrementally, but I think we can give teams until the end of > next week (September 9) or even early the following week (September 13 at > the latest) and still meet all of our deadlines. > > That said, the September 14 deadline would ideally be a hard deadline, so > I would like to not push it past that. If we think that makes more sense > from a release perspective, we can make it work from a marketing one. > > Thanks Allison for replying by clarifying your needs, it helps a lot. Honestly, I wasn't asking for a two-week delay (matching with RC1), I was just pointing out the difficulties to provide a release document as the exact same time we were rushing into the feature deadline. To be clear, shall we accept to punt by one week the cycle highlights delivery deadline, I'd be more than happy with it as personnally I'd target my duty to be done this Monday. -Sylvain > Let me know if that helps. > > Thanks, > Allison > > > > On Sep 1, 2022, at 7:38 AM, Rajat Dhasmana wrote: > > Hi Elod, > > I share the same concern as Sylvain. In cinder, we have provided an > extension of 1 week after the FF to features so we are really > not sure which changes are going to get in. I can prepare the highlights > with the features we already have merged but that won't > include the whole list. > > > On Thu, Sep 1, 2022 at 7:56 PM El?d Ill?s wrote: > >> I think the deadline is more like something to connected to Feature >> Freeze. ~After Feature Freeze we know what's in the cycle. If a project >> requests a Feature Freeze Exception, then of course, the FF will happen >> somewhere between official FF date (Milestone 3) and RC1, and hopefully >> closer to Milestone 3 date than RC1 date. >> >> I understand that PTLs are busy with reviewing the last feature patches, >> but I think this is more like a best effort, too, to prepare it as soon as >> possible, after the Feature Freeze. >> >> I don't know when exactly the Marketing team is processing the cycle >> highlights, but I guess they also handles these a bit flexible way. >> Probably to generally state that highlights are only needed by RC1 would >> give them much less time, more postponed / missing docs handling / more >> hurry. So while I think we have a bit of a flexibility with the deadline >> (1-2 working days don't really count), the best is to try to prepare it as >> soon as possible. Anyone from the Marketing team or from Release team, >> correct me if i'm wrong. >> >> El?d >> >> On 2022. 09. 01. 15:54, Sylvain Bauza wrote: >> >> >> >> Le mar. 30 ao?t 2022 ? 17:45, El?d Ill?s >> a ?crit : >> >>> Hi, >>> >>> This is a reminder, that *this week* is the week for Cycle highlights >>> [1][2]! They need to be added to deliverable yamls so that they can be >>> included in release marketing preparations. (See the details about how >>> to add them at the project team guide [3].) >>> >>> >> I'm confused. If I read correctly [3] it says that cycle highlights can >> be delivered at RC1 which makes sense to me as it's post-FeatureFreeze. >> Asking for cycle highlights the week of the FeatureFreeze is both >> counterproductive and non-logic : While some changes are still on debate >> and while we're not yet done with merging features, we need to write a >> document saying what we'll get. >> >> Couldn't we officially accept the projects to provide their highlights >> only at RC1 ? Is it a marketing problem because RC1 is closer to the GA ? >> -Sylvain >> >> >> >>> [1] https://releases.openstack.org/zed/schedule.html >>> [2] https://releases.openstack.org/zed/schedule.html#z-cycle-highlights >>> [3] https://docs.openstack.org/project-team-guide/release-management.html#cycle-highlights >>> >>> Thanks, >>> >>> El?d Ill?s >>> irc: elodilles >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjensas at redhat.com Thu Sep 1 20:14:48 2022 From: hjensas at redhat.com (Harald Jensas) Date: Thu, 1 Sep 2022 22:14:48 +0200 Subject: [election][tripleo] PTL Candidacy for Antelope cycle In-Reply-To: References: Message-ID: <83c91e28-7d62-5ea5-56ce-04b0b2f44135@redhat.com> On 8/30/22 16:29, Rabi Mishra wrote: > Hi All, > > I would like to nominate myself for Antelope cycle TripleO PTL. > > As some of you would know, I have been part of the OpenStack community > for a long time and have been a core contributor for TripleO and Heat. > I have also served as Heat PTL for Ocata cycle. > > James has done a great job as PTL for the last few cycles. I would like > totake the opportunity to thank him for all his effort and we all would > agree that he needs a well deserved break. > > I am looking forward to take the opportunity to help the community to > achieve some of the already planned goals and in-progress workstreams > like standalone roles, multi-rhel and other challenges that come along > the way. > > Also, as before, our focus would continue to be on review prioritization, > in progress work streams and collaboration on common priorities. > +1 Thank you for stepping up Rabi! Thanks to James for the past cycles! -- Harald Jens?s From ces.eduardo98 at gmail.com Thu Sep 1 22:46:55 2022 From: ces.eduardo98 at gmail.com (Carlos Silva) Date: Thu, 1 Sep 2022 19:46:55 -0300 Subject: [manila] Feature freeze exceptions Message-ID: Hello, Zorillas and interested stackers! During today's Manila weekly meeting we went over the status of our open changes that are eligible for feature freeze. Some candidates for the deadline were successfully merged over the course of this week, but there are also a few other changes that are receiving feedback from reviewers. Those changes will need some extra time to get in. We are in a shortage of reviewers to take care of all of the changes at once, and we are extending the deadline by one week. The changes yet to be merged and receiving the feature freeze exception are: *Metadata for share snapshots [1]* During the Yoga cycle, Manila metadata APIs were changed to be more generic and be able to accommodate metadata for other resources. For Zed, we planned to have metadatas being added to the snapshot resources. This change has received some reviews and seems to be quite close to being merged. During the tests, the manipulation of metadata for share snapshots seems to work just fine, and we are only getting some final tweaks to the implementation. *Refactor the Ceph NFS driver to use Cephadm NFS [2]* This is a driver-only change and it does not impact the Manila core itself. It is important for people consuming the Ceph drivers, and does not impact the current driver implementation. *Support share transfer between project [3]* This change is currently under review and is a good addition to the Manila core. Due to the shortage of reviewers, we only got more people looking at the change and testing the functionality late in the cycle. The three changes aforementioned should be merged by next Thursday (08 september 2022). [1] https://review.opendev.org/c/openstack/manila/+/825008 [2] https://review.opendev.org/c/openstack/manila/+/848987 [3] https://review.opendev.org/c/openstack/manila/+/843832 In case you have questions or concerns, please let me know. Thank you, carloss -------------- next part -------------- An HTML attachment was scrubbed... URL: From chkumar at redhat.com Fri Sep 2 06:47:25 2022 From: chkumar at redhat.com (Chandan Kumar) Date: Fri, 2 Sep 2022 12:17:25 +0530 Subject: [tripleo] gate blocker tripleo-ci-centos-9-content-provider Message-ID: Hello tripleo, Please hold your recheck on master tripleo branch, we have a gate blocker for tripleo-ci-centos-9-content-provider. https://bugs.launchpad.net/tripleo/+bug/1988514 The team is currently working on fixing it. With Regards, Chandan Kumar From skaplons at redhat.com Fri Sep 2 07:05:04 2022 From: skaplons at redhat.com (Slawek Kaplonski) Date: Fri, 02 Sep 2022 09:05:04 +0200 Subject: [all][elections][tc] TC Election Non-Candidacy ... In-Reply-To: <95656b9d-7b2a-d2a5-8d67-f5bd1ee98a0e@gmail.com> References: <95656b9d-7b2a-d2a5-8d67-f5bd1ee98a0e@gmail.com> Message-ID: <4750444.tdWV9SEqCh@p1> Hi, Dnia czwartek, 1 wrze?nia 2022 16:41:02 CEST Jay Bryant pisze: > All, > > I wanted to take a moment to let everyone know that I am not going to be > running for the TC, this time around. > > The last two years on the TC have been a great experience and I am > grateful for the trust the community put in me. > > At this point, however, I think it is best to let others who may want to > join the TC have the opportunity to do so. > > Again, thank you for this opportunity to support the community over the > last couple of years! > > Sincerely, > > Jay Bryant > > (jungleboyj) > > > Thx Jay for all Your work in the TC. It's really great to work with You :) -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From kkchn.in at gmail.com Fri Sep 2 07:32:31 2022 From: kkchn.in at gmail.com (KK CHN) Date: Fri, 2 Sep 2022 13:02:31 +0530 Subject: Kolla-ansible Openstack : Queries on Metering and Rating Module Message-ID: I have installed all-in-one using Kolla-ansible wallaby on a Virtual Machine (Debian 10) By default configurations up and running are able to create VMs .. with the default Cirros image. I want the Metering and Billing modules for a deployment scenario. So I used this setup as a PILOT and use ceilometer with cloudkitty and gnocchi.. I have enabled ( correct me If I am wrong or missing any other directives for metering and rating other than this if required => enable_ceilometer : "yes" enable_cloudkitty : "yes" enable_gnocchi : "yes" , enable_horizon_cloudkitty : "{{ enable_cloudkitty |bool }}" cloudkitty_collector_backend: "gnocchi" in /etc/kolla/globals.yml Then re deployed the all in one $ ( (venvopenstack) cloud at wallaby:~$ kolla-ansible -i ./all-in-one bootstrap-servers , (venvopenstack) cloud at Xena:~$ kolla-ansible -i ./all-in-one prechecks, (venvopenstack) cloud at Xena:~$ kolla-ansible -i ./all-in-one deploy ) .. All went well up and able to access horizon dashboard. How to view the metrics and ratings :: I am able to get Admin => Rating tab Enabled the three Rating Modules there. (Hashmap, noop, pyscripts) .. Rating Summary : I am getting as below All CloudTotal 0 LL Cloud Total 0 Hashmap and pyscrips tab nothing to view , its empty. How can I use this Rating module and how to get useful values there ? Or is there any other configurations I have to make to get a better metering and billing utility using these tools. Kindly share your tips and expertise with these tools. What / where to refer to get a nice Rating/metering configurations using these tools.( Or do I need to enable / configure more directives or resources ??) I have not seen a highly populated Rating Module interface in Horizon so it should be. Any reference images and configurations are most welcome. Thank you, Krish -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre at stackhpc.com Fri Sep 2 08:08:58 2022 From: pierre at stackhpc.com (Pierre Riteau) Date: Fri, 2 Sep 2022 10:08:58 +0200 Subject: Kolla-ansible Openstack : Queries on Metering and Rating Module In-Reply-To: References: Message-ID: You have to create rating rules for CloudKitty to perform rating. Otherwise it won't produce any results. See the CloudKitty documentation about hashmaps for more details: https://docs.openstack.org/cloudkitty/latest/user/rating/hashmap.html On Fri, 2 Sept 2022 at 09:33, KK CHN wrote: > I have installed all-in-one using Kolla-ansible wallaby on a Virtual > Machine (Debian 10) > > By default configurations up and running are able to create VMs .. with > the default Cirros image. > > I want the Metering and Billing modules for a deployment scenario. So I > used this setup as a PILOT and use ceilometer with cloudkitty and > gnocchi.. > > I have enabled ( correct me If I am wrong or missing any other directives > for metering and rating other than this if required => > enable_ceilometer : "yes" enable_cloudkitty : "yes" enable_gnocchi : > "yes" , enable_horizon_cloudkitty : "{{ enable_cloudkitty |bool }}" > cloudkitty_collector_backend: "gnocchi" > > in /etc/kolla/globals.yml > > Then re deployed the all in one $ ( (venvopenstack) cloud at wallaby:~$ > kolla-ansible -i ./all-in-one bootstrap-servers , (venvopenstack) > cloud at Xena:~$ kolla-ansible -i ./all-in-one prechecks, (venvopenstack) > cloud at Xena:~$ kolla-ansible -i ./all-in-one deploy ) .. All went well up > and able to access horizon dashboard. > > How to view the metrics and ratings :: > > I am able to get Admin => Rating tab > Enabled the three Rating Modules there. (Hashmap, noop, pyscripts) .. > > Rating Summary : I am getting as below > All CloudTotal 0 > LL Cloud Total > 0 > > Hashmap and pyscrips tab nothing to view , its empty. > > How can I use this Rating module and how to get useful values there ? > Or is there any other configurations I have to make to get a better > metering and billing utility using these tools. > > Kindly share your tips and expertise with these tools. > > What / where to refer to get a nice Rating/metering configurations using > these tools.( Or do I need to enable / configure more directives or > resources ??) > > I have not seen a highly populated Rating Module interface in Horizon so > it should be. Any reference images and configurations are most welcome. > > Thank you, > Krish > -------------- next part -------------- An HTML attachment was scrubbed... URL: From felix.huettner at mail.schwarz Fri Sep 2 08:19:38 2022 From: felix.huettner at mail.schwarz (=?iso-8859-1?Q?Felix_H=FCttner?=) Date: Fri, 2 Sep 2022 08:19:38 +0000 Subject: [ops][largescale-sig] rabbitmq and the durability of reply_ queues Message-ID: Hi everyone, the largescale-sig currently recommends the following rabbitmq policy [1]: '^(?!(amq\.)|(.*_fanout_)|(reply_)).*'. If I found the history of this setting correctly, it resulted from this mailinglist thread [2] which came to the conclusion: > * use durable-queue and replication for long-running queues/exchanges > * use non-durable-queue without replication for short (fanout, reply_) queues However I am unsure if reply_ queues are actually shorted lived than the "long-running" ones. If we take the example of the cinder-scheduler we have the following queues: * cinder-scheduler: Tied to the lifetime of the whole cinder-scheduler cluster; currently durable + replicated * cinder-scheduler.myhostname: Tied to the lifetime of the cinder-scheduler service, but not removed when the service stops; currently durable + replicated * cinder-scheduler_fanout_somerandomid: Tied to the lifetime of the cinder-scheduler service, but removed when the service stops; currently neither durable nor replicated * reply_somerandomid: Tied to the lifetime of the cinder-scheduler service, but removed when the service stops; currently neither durable nor replicated If I read got all of the above correctly then reply_ and fanout queues are actually not shorter lived than the normal queue to send requests to that service. The only difference is that we remove them when the service itself stops. Therefor I want to propose the question if we should not also make these queues durable and replicated. Thank you [1]: https://docs.openstack.org/large-scale/other/rabbitmq.html#pattern [2]: https://lists.openstack.org/pipermail/openstack-discuss/2020-August/016562.html -- Felix Huettner Diese E Mail enth?lt m?glicherweise vertrauliche Inhalte und ist nur f?r die Verwertung durch den vorgesehenen Empf?nger bestimmt. Sollten Sie nicht der vorgesehene Empf?nger sein, setzen Sie den Absender bitte unverz?glich in Kenntnis und l?schen diese E Mail. Hinweise zum Datenschutz finden Sie hier. From felix.huettner at mail.schwarz Fri Sep 2 08:35:13 2022 From: felix.huettner at mail.schwarz (=?iso-8859-1?Q?Felix_H=FCttner?=) Date: Fri, 2 Sep 2022 08:35:13 +0000 Subject: [all] [oslo.messaging] Interest in collaboration on a NATS driver In-Reply-To: References: <52AA12A0-AE67-4EF7-B924-DE1F2873B909@binero.com> Message-ID: +1, we would also be interested in helping out. Let me know where we can help out with reviews, writing code, testing, etc. -- Felix Huettner >+1, I'm also interested in this topic. I did some tests with nats-py to see how it works and I'm volunteering to go further with this technology. >Let me know if you need reviews, help etc... > >Le jeu. 1 sept. 2022 ? 15:50, Tobias Urdin a ?crit : >Hello Kai, > >Great to hear that you're interested! >I'm currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first). > >Best regards >Tobias > >> On 30 Aug 2022, at 18:32, Kai Bojens wrote: >> >> Am 29.08.22 um 15:46 schrieb Tobias Urdin: >> >>> If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to >>> reach out. I'm hoping somebody will bite but atleast I've put it out there for all of you. >> >> Hi, >> I am very much interested to take a closer look at your work and maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack. >> >> As I'm pretty new to the messaging topic and had just heard of NATS and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ. >> >> This brings me to the most important question: Where do you run and test your code? >> >> Greetings, >> Kai Diese E Mail enth?lt m?glicherweise vertrauliche Inhalte und ist nur f?r die Verwertung durch den vorgesehenen Empf?nger bestimmt. Sollten Sie nicht der vorgesehene Empf?nger sein, setzen Sie den Absender bitte unverz?glich in Kenntnis und l?schen diese E Mail. Hinweise zum Datenschutz finden Sie hier. From login.rohitsingh at gmail.com Fri Sep 2 10:45:07 2022 From: login.rohitsingh at gmail.com (Rohit Singh) Date: Fri, 2 Sep 2022 16:15:07 +0530 Subject: Unable to change the app-name / programname for barbican-api service Message-ID: Hi guys, I am facing issues with barbican-api logging with syslog. I have configured rsyslog for barbican service and want to write the logs on remote host based on %programname properties, But I observed that the barbican-api app-name is not set ,so by default it's logging into loadwsgi.py.log . Is there any way to set the app-name for barbican-api service ? Regards Rohit Singh Mob : +91- 88824 68891 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver.weinmann at me.com Fri Sep 2 11:29:47 2022 From: oliver.weinmann at me.com (Oliver Weinmann) Date: Fri, 2 Sep 2022 13:29:47 +0200 Subject: http proxy support Message-ID: <5654b70a-3a0f-691e-0fdb-ec0c5bb75b20@me.com> Hi, I was wondering if there is a way to set a http proxy in kolla-ansible during deployment / update etc. Today I wanted to pull new containers and this saturates our internet connection. What we usually do is have machine that massively download stuff from the internet use a squid proxy that throttles their bandwidth. I found the following feature request: https://bugs.launchpad.net/kolla-ansible/+bug/1829586 And it seems some work had been done, but I can't seem to find any info if the change really made it into production: https://review.opendev.org/c/openstack/kolla-ansible/+/692006/ Any help or hints are highly appreciated. Cheers, Oliver From pierre at stackhpc.com Fri Sep 2 12:19:44 2022 From: pierre at stackhpc.com (Pierre Riteau) Date: Fri, 2 Sep 2022 14:19:44 +0200 Subject: http proxy support In-Reply-To: <5654b70a-3a0f-691e-0fdb-ec0c5bb75b20@me.com> References: <5654b70a-3a0f-691e-0fdb-ec0c5bb75b20@me.com> Message-ID: Hi Oliver, The Kolla Ansible documentation describes how to configure Docker to use a proxy: https://docs.openstack.org/kolla-ansible/latest/reference/deployment-and-bootstrapping/bootstrap-servers.html#configuration This feature was introduced in Wallaby. Additionally, I suggest you configure a local Docker registry and use it to fetch container images. The same documentation page describes related variables. Cheers, Pierre Riteau (priteau) On Fri, 2 Sept 2022 at 13:33, Oliver Weinmann wrote: > Hi, > > I was wondering if there is a way to set a http proxy in kolla-ansible > during deployment / update etc. Today I wanted to pull new containers > and this saturates our internet connection. What we usually do is have > machine that massively download stuff from the internet use a squid > proxy that throttles their bandwidth. > > I found the following feature request: > > https://bugs.launchpad.net/kolla-ansible/+bug/1829586 > > And it seems some work had been done, but I can't seem to find any info > if the change really made it into production: > > https://review.opendev.org/c/openstack/kolla-ansible/+/692006/ > > Any help or hints are highly appreciated. > > Cheers, > > Oliver > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkchn.in at gmail.com Fri Sep 2 12:26:04 2022 From: kkchn.in at gmail.com (KK CHN) Date: Fri, 2 Sep 2022 17:56:04 +0530 Subject: Kolla-ansible Openstack : Queries on Metering and Rating Module In-Reply-To: References: Message-ID: I am going to add the hashmap service to cloud kitty conf files by defining (venvopenstack) cloud at Xena:~$ sudo vi /etc/kolla/cloudkitty-processor/cloudkitty.conf [collect] collector = gnocchi metrics_conf = /etc/kolla/cloudkitty-processor/metrics.yml And in metric.yml defined the services and fields as in https://docs.openstack.org/cloudkitty/latest/user/rating/hashmap.html But when I tried to $ cloudkitty hashmap group create instance_uptime_flavor_id There is no cloudkitty CLI option only I have (venvopenstack) cloud at wallaby:~$ cloud- cloud-id cloud-init cloud-init-per cloud-localds (venvopenstack) cloud at wallaby:~$ No cloudkitty command line option. Why ?? anything I made wrong ? This was in my globals.yml which enabled for this deployment. (venvopenstack) cloud at wallaby:~$ grep ^[^#] /etc/kolla/globals.yml --- kolla_base_distro: "debian" kolla_install_type: "source" kolla_internal_vip_address: "10.184.48.250" network_interface: "ens3" neutron_external_interface: "ens4" enable_ceilometer: "yes" enable_cloudkitty: "yes" enable_gnocchi: "yes" enable_horizon_cloudkitty: "{{ enable_cloudkitty | bool }}" cloudkitty_collector_backend: "gnocchi" nova_compute_virt_type: "qemu" (venvopenstack) cloud at wallaby:~$ What I am missing : Any hints most welcome. Thank you, Krish On Fri, Sep 2, 2022 at 1:39 PM Pierre Riteau wrote: > You have to create rating rules for CloudKitty to perform rating. > Otherwise it won't produce any results. See the CloudKitty documentation > about hashmaps for more details: > https://docs.openstack.org/cloudkitty/latest/user/rating/hashmap.html > > On Fri, 2 Sept 2022 at 09:33, KK CHN wrote: > >> I have installed all-in-one using Kolla-ansible wallaby on a Virtual >> Machine (Debian 10) >> >> By default configurations up and running are able to create VMs .. with >> the default Cirros image. >> >> I want the Metering and Billing modules for a deployment scenario. So I >> used this setup as a PILOT and use ceilometer with cloudkitty and >> gnocchi.. >> >> I have enabled ( correct me If I am wrong or missing any other >> directives for metering and rating other than this if required => >> enable_ceilometer : "yes" enable_cloudkitty : "yes" enable_gnocchi : >> "yes" , enable_horizon_cloudkitty : "{{ enable_cloudkitty |bool }}" >> cloudkitty_collector_backend: "gnocchi" >> >> in /etc/kolla/globals.yml >> >> Then re deployed the all in one $ ( (venvopenstack) cloud at wallaby:~$ >> kolla-ansible -i ./all-in-one bootstrap-servers , (venvopenstack) >> cloud at Xena:~$ kolla-ansible -i ./all-in-one prechecks, (venvopenstack) >> cloud at Xena:~$ kolla-ansible -i ./all-in-one deploy ) .. All went well >> up and able to access horizon dashboard. >> >> How to view the metrics and ratings :: >> >> I am able to get Admin => Rating tab >> Enabled the three Rating Modules there. (Hashmap, noop, pyscripts) .. >> >> Rating Summary : I am getting as below >> All CloudTotal 0 >> LL Cloud Total >> 0 >> >> Hashmap and pyscrips tab nothing to view , its empty. >> >> How can I use this Rating module and how to get useful values there ? >> Or is there any other configurations I have to make to get a better >> metering and billing utility using these tools. >> >> Kindly share your tips and expertise with these tools. >> >> What / where to refer to get a nice Rating/metering configurations using >> these tools.( Or do I need to enable / configure more directives or >> resources ??) >> >> I have not seen a highly populated Rating Module interface in Horizon so >> it should be. Any reference images and configurations are most welcome. >> >> Thank you, >> Krish >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre at stackhpc.com Fri Sep 2 12:24:49 2022 From: pierre at stackhpc.com (Pierre Riteau) Date: Fri, 2 Sep 2022 14:24:49 +0200 Subject: Kolla-ansible Openstack : Queries on Metering and Rating Module In-Reply-To: References: Message-ID: The cloudkitty client is not installed by default when you install the openstack client. See its documentation for installation instructions: https://docs.openstack.org/python-cloudkittyclient/latest/index.html On Fri, 2 Sept 2022 at 14:22, KK CHN wrote: > I am going to add the hashmap service to cloud kitty conf files by > defining (venvopenstack) cloud at Xena:~$ sudo vi > /etc/kolla/cloudkitty-processor/cloudkitty.conf > > [collect] > collector = gnocchi > metrics_conf = /etc/kolla/cloudkitty-processor/metrics.yml > > And in metric.yml defined the services and fields as in > https://docs.openstack.org/cloudkitty/latest/user/rating/hashmap.html > > But when I tried to > > $ cloudkitty hashmap group create instance_uptime_flavor_id > > There is no cloudkitty CLI option > > only I have > (venvopenstack) cloud at wallaby:~$ cloud- > cloud-id cloud-init cloud-init-per cloud-localds > (venvopenstack) cloud at wallaby:~$ > > > No cloudkitty command line option. Why ?? anything I made wrong ? > > This was in my globals.yml which enabled for this deployment. > > (venvopenstack) cloud at wallaby:~$ grep ^[^#] /etc/kolla/globals.yml > --- > kolla_base_distro: "debian" > kolla_install_type: "source" > kolla_internal_vip_address: "10.184.48.250" > network_interface: "ens3" > neutron_external_interface: "ens4" > enable_ceilometer: "yes" > enable_cloudkitty: "yes" > enable_gnocchi: "yes" > enable_horizon_cloudkitty: "{{ enable_cloudkitty | bool }}" > cloudkitty_collector_backend: "gnocchi" > nova_compute_virt_type: "qemu" > (venvopenstack) cloud at wallaby:~$ > > What I am missing : Any hints most welcome. > > Thank you, > Krish > > > > On Fri, Sep 2, 2022 at 1:39 PM Pierre Riteau wrote: > >> You have to create rating rules for CloudKitty to perform rating. >> Otherwise it won't produce any results. See the CloudKitty documentation >> about hashmaps for more details: >> https://docs.openstack.org/cloudkitty/latest/user/rating/hashmap.html >> >> On Fri, 2 Sept 2022 at 09:33, KK CHN wrote: >> >>> I have installed all-in-one using Kolla-ansible wallaby on a >>> Virtual Machine (Debian 10) >>> >>> By default configurations up and running are able to create VMs .. with >>> the default Cirros image. >>> >>> I want the Metering and Billing modules for a deployment scenario. So >>> I used this setup as a PILOT and use ceilometer with cloudkitty and >>> gnocchi.. >>> >>> I have enabled ( correct me If I am wrong or missing any other >>> directives for metering and rating other than this if required => >>> enable_ceilometer : "yes" enable_cloudkitty : "yes" enable_gnocchi : >>> "yes" , enable_horizon_cloudkitty : "{{ enable_cloudkitty |bool }}" >>> cloudkitty_collector_backend: "gnocchi" >>> >>> in /etc/kolla/globals.yml >>> >>> Then re deployed the all in one $ ( (venvopenstack) cloud at wallaby:~$ >>> kolla-ansible -i ./all-in-one bootstrap-servers , (venvopenstack) >>> cloud at Xena:~$ kolla-ansible -i ./all-in-one prechecks, (venvopenstack) >>> cloud at Xena:~$ kolla-ansible -i ./all-in-one deploy ) .. All went well >>> up and able to access horizon dashboard. >>> >>> How to view the metrics and ratings :: >>> >>> I am able to get Admin => Rating tab >>> Enabled the three Rating Modules there. (Hashmap, noop, pyscripts) .. >>> >>> Rating Summary : I am getting as below >>> All CloudTotal 0 >>> LL Cloud Total >>> 0 >>> >>> Hashmap and pyscrips tab nothing to view , its empty. >>> >>> How can I use this Rating module and how to get useful values there ? >>> Or is there any other configurations I have to make to get a better >>> metering and billing utility using these tools. >>> >>> Kindly share your tips and expertise with these tools. >>> >>> What / where to refer to get a nice Rating/metering configurations using >>> these tools.( Or do I need to enable / configure more directives or >>> resources ??) >>> >>> I have not seen a highly populated Rating Module interface in Horizon >>> so it should be. Any reference images and configurations are most welcome. >>> >>> Thank you, >>> Krish >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From zigo at debian.org Fri Sep 2 14:20:39 2022 From: zigo at debian.org (Thomas Goirand) Date: Fri, 2 Sep 2022 16:20:39 +0200 Subject: Kolla-ansible Openstack : Queries on Metering and Rating Module In-Reply-To: References: Message-ID: On 9/2/22 14:24, Pierre Riteau wrote: > The cloudkitty client is not installed by default when?you install the > openstack client. See its documentation for installation instructions: > https://docs.openstack.org/python-cloudkittyclient/latest/index.html > Well, in Debian, the python3-cloudkittyclient installs /usr/bin/cloudkitty. I'm not sure what Kolla does though... Anyway, Krish should try: openstack rating hashmap group create instance_uptime_flavor_id to see if that works... Cheers, Thomas Goirand (zigo) From rohitkumar.s at acldigital.com Fri Sep 2 10:32:34 2022 From: rohitkumar.s at acldigital.com (Rohit Kumar Singh) Date: Fri, 2 Sep 2022 16:02:34 +0530 Subject: Unable to change the app-name / programname for barbican-api service Message-ID: <000301d8beb7$5b792bf0$126b83d0$@acldigital.com> Hi guys, I am facing issues with barbican-api logging with syslog. I have configured rsyslog for barbican service and want to write the logs on remote host based on %programname properties, but i observed barbican-api app-name is not set ,so by default it's logging into loadwsgi.py.log . I s there any way to set the app-name for barbican-api service ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjensas at redhat.com Fri Sep 2 14:51:49 2022 From: hjensas at redhat.com (Harald Jensas) Date: Fri, 2 Sep 2022 16:51:49 +0200 Subject: [heat][elections] PTL Candidacy for Antelope Cycle In-Reply-To: References: Message-ID: <817a8538-0b79-b86c-dceb-e272b5c598d9@redhat.com> On 8/30/22 08:19, Brendan Shephard wrote: > Hi all, > > I first wanted to thank Rico for his ongoing commitment to the project over the last cycles. He has provided lots of guidance and help to the Heat project for a long time and his contribution deserves recognition. > > I am proposing my candidacy for Heat PTL during the Antelope cycle. > > I have worked with the Heat project for several years both as a user and more > recently over the last 2 years as a contributor. I see great potential in the > project for our users and look forward to continuing work in order to > support features and functionality of the project. > > Some of my objectives for the next few cycles are: > > > Remove the dependencies on legacy python-*client libraries and instead > shift to the openstacksdk client library. > > While the legacy libraries have served us well, they are starting to > show their limitations and the delta in servicibilty will only increase > as each project moves towards leveraging the openstacksdk. So this change, > while quite extensive will ensure future compatibility with the other > OpenStack project teams. > > > Continue ensuring Heat supports the most up-to-date and recent features > provided by each project. > > To ensure Heat is the default and best choice for our users, we need to > ensure we are able to leverage the latest available features from the > complimentary OpenStack projects. This is an ongoing challenge to stay > up-to-date with the changes each cycle and work towards implementing them > in Heat. > > Thank you all for you consideration, and I look forward to the next cycle > and continuing to work with you all. > > > Regards, > Brendan > > +1, thanks Brendan. -- Harald Jens?s From pierre at stackhpc.com Fri Sep 2 15:06:41 2022 From: pierre at stackhpc.com (Pierre Riteau) Date: Fri, 2 Sep 2022 17:06:41 +0200 Subject: Kolla-ansible Openstack : Queries on Metering and Rating Module In-Reply-To: References: Message-ID: Kolla doesn?t install any client outside of container images, unless you run some tests scripts. And the rating commands are added to OSC by the same python-cloudkittyclient package. Le ven. 2 sept. 2022 ? 16:20, Thomas Goirand a ?crit : > On 9/2/22 14:24, Pierre Riteau wrote: > > The cloudkitty client is not installed by default when you install the > > openstack client. See its documentation for installation instructions: > > https://docs.openstack.org/python-cloudkittyclient/latest/index.html > > > > Well, in Debian, the python3-cloudkittyclient installs > /usr/bin/cloudkitty. I'm not sure what Kolla does though... > > Anyway, Krish should try: > openstack rating hashmap group create instance_uptime_flavor_id > > to see if that works... > > Cheers, > > Thomas Goirand (zigo) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elod.illes at est.tech Fri Sep 2 15:29:46 2022 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Fri, 2 Sep 2022 17:29:46 +0200 Subject: [release] Release countdown for week R-4, Sep 05 - 09 Message-ID: <0c802895-2649-1538-76bb-2da2e8e28cf0@est.tech> Development Focus ----------------- We just passed feature freeze! Until release branches are cut, you should stop accepting featureful changes to deliverables following the cycle-with-rc release model, or to libraries. Exceptions should be discussed on separate threads on the mailing-list, and feature freeze exceptions approved by the team's PTL. Focus should be on finding and fixing release-critical bugs, so that release candidates and final versions of the Zed deliverables can be proposed, well ahead of the final Zed release date. General Information ------------------- We are still finishing up processing a few release requests, but the Zed release requirements are now frozen. If new library releases are needed to fix release-critical bugs in Zed, you must request a Requirements Freeze Exception (RFE) from the requirements team before we can do a new release to avoid having something released in Zed that is not actually usable. This is done by posting to the openstack-discuss mailing list with a subject line similar to: ??????? [$PROJECT][requirements] RFE requested for $PROJECT_LIB Include justification/reasoning for why a RFE is needed for this lib. If/when the requirements team OKs the post-freeze update, we can then process a new release. A soft String freeze is now in effect, in order to let the I18N team do the translation work in good conditions. In Horizon and the various dashboard plugins, you should stop accepting changes that modify user-visible strings. Exceptions should be discussed on the mailing-list. By September 15th, 2022 this will become a hard string freeze, with no changes in user-visible strings allowed. Actions ------- stable/zed branches should be created soon for all not-already-branched libraries. You should expect 2-3 changes to be proposed for each: a .gitreview update, a reno update (skipped for projects not using reno), and a tox.ini constraints URL update. Please review those in priority so that the branch can be functional ASAP. The Prelude section of reno release notes is rendered as the top level overview for the release. Any important overall messaging for Zed changes should be added there to make sure the consumers of your release notes see them. Finally, if you haven't proposed Zed cycle-highlights yet, then it's time to do that as soon as possible. Please see the email for details: https://lists.openstack.org/pipermail/openstack-discuss/2022-August/030223.html Upcoming Deadlines & Dates -------------------------- RC1 deadline: September 15th, 2022 (R-3 week) Final RC deadline: September 29th, 2022 (R-1 week) Final Zed release: October 5th, 2022 PTG: October 17-21, 2022 (Virtual!) El?d Ill?s irc: elodilles From oliver.weinmann at me.com Fri Sep 2 15:49:47 2022 From: oliver.weinmann at me.com (Oliver Weinmann) Date: Fri, 2 Sep 2022 17:49:47 +0200 Subject: http proxy support In-Reply-To: References: <5654b70a-3a0f-691e-0fdb-ec0c5bb75b20@me.com> Message-ID: <3e2d48a3-283e-0f47-44b7-d81a6915eeca@me.com> Hi Pierre, thanks for the quick reply and pointing me in the right direction. I used a central local docker registry in the past. Is this still the latest documentation: https://docs.openstack.org/kolla-ansible/latest/user/multinode.html I stopped using it, because I always came across problems where it was no longer possible to pull any container images. Just today I had this issue without using a local registry: TASK [service-images-pull : common | Pull images] *********************************************************************************************************************************************************************************************************************************************************************************************************************************************************** FAILED - RETRYING: common | Pull images (3 retries left). FAILED - RETRYING: common | Pull images (3 retries left). FAILED - RETRYING: common | Pull images (3 retries left). FAILED - RETRYING: common | Pull images (3 retries left). FAILED - RETRYING: common | Pull images (3 retries left). FAILED - RETRYING: common | Pull images (2 retries left). FAILED - RETRYING: common | Pull images (2 retries left). FAILED - RETRYING: common | Pull images (2 retries left). FAILED - RETRYING: common | Pull images (2 retries left). FAILED - RETRYING: common | Pull images (2 retries left). FAILED - RETRYING: common | Pull images (1 retries left). FAILED - RETRYING: common | Pull images (1 retries left). FAILED - RETRYING: common | Pull images (1 retries left). FAILED - RETRYING: common | Pull images (1 retries left). FAILED - RETRYING: common | Pull images (1 retries left). failed: [gedaopl09] (item=fluentd) => {"ansible_loop_var": "item", "attempts": 3, "changed": true, "item": {"key": "fluentd", "value": {"container_name": "fluentd", "dimensions": {}, "enabled": true, "environment": {"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS"}, "group": "fluentd", "image": "quay.io/openstack.kolla/fluentd:yoga-centos-stream8", "volumes": ["/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro", "/etc/localtime:/etc/localtime:ro", "", "kolla_logs:/var/log/kolla/", "fluentd_data:/var/lib/fluentd/data/"]}}, "msg": "'Traceback (most recent call last):\\n? File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, in _raise_for_status\\n response.raise_for_status()\\n? File \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in raise_for_status\\n??? raise HTTPError(http_error_msg, response=self)\\nrequests.exceptions.HTTPError: 404 Client Error: Not Found for url: http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd\\n\\nDuring handling of the above exception, another exception occurred:\\n\\nTraceback (most recent call last):\\n? File \"/tmp/ansible_kolla_docker_payload_w20pu6xy/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 381, in main\\n? File \"/tmp/ansible_kolla_docker_payload_w20pu6xy/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", line 451, in pull_image\\n??? repository=image, tag=tag, stream=True\\n? File \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line 430, in pull\\n??? self._raise_for_status(response)\\n? File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, in _raise_for_status\\n??? raise create_api_error_from_http_exception(e)\\n? File \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, in create_api_error_from_http_exception\\n??? raise cls(e, response=response, explanation=explanation)\\ndocker.errors.NotFound: 404 Client Error for http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd: Not Found (\"manifest for quay.io/openstack.kolla/fluentd:yoga-centos-stream8 not found: manifest unknown: manifest unknown\")\\n'"} failed: [gedaopl11] (item=fluentd) => {"ansible_loop_var": "item", "attempts": 3, "changed": true, "item": {"key": "fluentd", "value": {"container_name": "fluentd", "dimensions": {}, "enabled": true, "environment": {"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS"}, "group": "fluentd", "image": "quay.io/openstack.kolla/fluentd:yoga-centos-stream8", "volumes": ["/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro", "/etc/localtime:/etc/localtime:ro", "", "kolla_logs:/var/log/kolla/", "fluentd_data:/var/lib/fluentd/data/"]}}, "msg": "'Traceback (most recent call last):\\n? File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, in _raise_for_status\\n response.raise_for_status()\\n? File \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in raise_for_status\\n??? raise HTTPError(http_error_msg, response=self)\\nrequests.exceptions.HTTPError: 404 Client Error: Not Found for url: http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd\\n\\nDuring handling of the above exception, another exception occurred:\\n\\nTraceback (most recent call last):\\n? File \"/tmp/ansible_kolla_docker_payload_xgz79c_7/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 381, in main\\n? File \"/tmp/ansible_kolla_docker_payload_xgz79c_7/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", line 451, in pull_image\\n??? repository=image, tag=tag, stream=True\\n? File \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line 430, in pull\\n??? self._raise_for_status(response)\\n? File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, in _raise_for_status\\n??? raise create_api_error_from_http_exception(e)\\n? File \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, in create_api_error_from_http_exception\\n??? raise cls(e, response=response, explanation=explanation)\\ndocker.errors.NotFound: 404 Client Error for http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd: Not Found (\"manifest for quay.io/openstack.kolla/fluentd:yoga-centos-stream8 not found: manifest unknown: manifest unknown\")\\n'"} failed: [gedaopl04] (item=fluentd) => {"ansible_loop_var": "item", "attempts": 3, "changed": true, "item": {"key": "fluentd", "value": {"container_name": "fluentd", "dimensions": {}, "enabled": true, "environment": {"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS"}, "group": "fluentd", "image": "quay.io/openstack.kolla/fluentd:yoga-centos-stream8", "volumes": ["/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro", "/etc/localtime:/etc/localtime:ro", "", "kolla_logs:/var/log/kolla/", "fluentd_data:/var/lib/fluentd/data/"]}}, "msg": "'Traceback (most recent call last):\\n? File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, in _raise_for_status\\n response.raise_for_status()\\n? File \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in raise_for_status\\n??? raise HTTPError(http_error_msg, response=self)\\nrequests.exceptions.HTTPError: 404 Client Error: Not Found for url: http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd\\n\\nDuring handling of the above exception, another exception occurred:\\n\\nTraceback (most recent call last):\\n? File \"/tmp/ansible_kolla_docker_payload_1petvtop/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 381, in main\\n? File \"/tmp/ansible_kolla_docker_payload_1petvtop/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", line 451, in pull_image\\n??? repository=image, tag=tag, stream=True\\n? File \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line 430, in pull\\n??? self._raise_for_status(response)\\n? File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, in _raise_for_status\\n??? raise create_api_error_from_http_exception(e)\\n? File \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, in create_api_error_from_http_exception\\n??? raise cls(e, response=response, explanation=explanation)\\ndocker.errors.NotFound: 404 Client Error for http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd: Not Found (\"manifest for quay.io/openstack.kolla/fluentd:yoga-centos-stream8 not found: manifest unknown: manifest unknown\")\\n'"} failed: [gedaopl07] (item=fluentd) => {"ansible_loop_var": "item", "attempts": 3, "changed": true, "item": {"key": "fluentd", "value": {"container_name": "fluentd", "dimensions": {}, "enabled": true, "environment": {"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS"}, "group": "fluentd", "image": "quay.io/openstack.kolla/fluentd:yoga-centos-stream8", "volumes": ["/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro", "/etc/localtime:/etc/localtime:ro", "", "kolla_logs:/var/log/kolla/", "fluentd_data:/var/lib/fluentd/data/"]}}, "msg": "'Traceback (most recent call last):\\n? File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, in _raise_for_status\\n response.raise_for_status()\\n? File \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in raise_for_status\\n??? raise HTTPError(http_error_msg, response=self)\\nrequests.exceptions.HTTPError: 404 Client Error: Not Found for url: http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd\\n\\nDuring handling of the above exception, another exception occurred:\\n\\nTraceback (most recent call last):\\n? File \"/tmp/ansible_kolla_docker_payload_uzj0wg5e/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 381, in main\\n? File \"/tmp/ansible_kolla_docker_payload_uzj0wg5e/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", line 451, in pull_image\\n??? repository=image, tag=tag, stream=True\\n? File \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line 430, in pull\\n??? self._raise_for_status(response)\\n? File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, in _raise_for_status\\n??? raise create_api_error_from_http_exception(e)\\n? File \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, in create_api_error_from_http_exception\\n??? raise cls(e, response=response, explanation=explanation)\\ndocker.errors.NotFound: 404 Client Error for http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd: Not Found (\"manifest for quay.io/openstack.kolla/fluentd:yoga-centos-stream8 not found: manifest unknown: manifest unknown\")\\n'"} failed: [gedaopl10] (item=fluentd) => {"ansible_loop_var": "item", "attempts": 3, "changed": true, "item": {"key": "fluentd", "value": {"container_name": "fluentd", "dimensions": {}, "enabled": true, "environment": {"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS"}, "group": "fluentd", "image": "quay.io/openstack.kolla/fluentd:yoga-centos-stream8", "volumes": ["/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro", "/etc/localtime:/etc/localtime:ro", "", "kolla_logs:/var/log/kolla/", "fluentd_data:/var/lib/fluentd/data/"]}}, "msg": "'Traceback (most recent call last):\\n? File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, in _raise_for_status\\n response.raise_for_status()\\n? File \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in raise_for_status\\n??? raise HTTPError(http_error_msg, response=self)\\nrequests.exceptions.HTTPError: 404 Client Error: Not Found for url: http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd\\n\\nDuring handling of the above exception, another exception occurred:\\n\\nTraceback (most recent call last):\\n? File \"/tmp/ansible_kolla_docker_payload_a6kiyuhn/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 381, in main\\n? File \"/tmp/ansible_kolla_docker_payload_a6kiyuhn/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", line 451, in pull_image\\n??? repository=image, tag=tag, stream=True\\n? File \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line 430, in pull\\n??? self._raise_for_status(response)\\n? File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, in _raise_for_status\\n??? raise create_api_error_from_http_exception(e)\\n? File \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, in create_api_error_from_http_exception\\n??? raise cls(e, response=response, explanation=explanation)\\ndocker.errors.NotFound: 404 Client Error for http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd: Not Found (\"manifest for quay.io/openstack.kolla/fluentd:yoga-centos-stream8 not found: manifest unknown: manifest unknown\")\\n'"} FAILED - RETRYING: common | Pull images (3 retries left). FAILED - RETRYING: common | Pull images (3 retries left). FAILED - RETRYING: common | Pull images (3 retries left). FAILED - RETRYING: common | Pull images (3 retries left). FAILED - RETRYING: common | Pull images (3 retries left). FAILED - RETRYING: common | Pull images (2 retries left). FAILED - RETRYING: common | Pull images (2 retries left). FAILED - RETRYING: common | Pull images (2 retries left). FAILED - RETRYING: common | Pull images (2 retries left). FAILED - RETRYING: common | Pull images (2 retries left). I'm on release Yoga and for some weird reason, I found the suggestion to change release yoga to master in /etc/kolla/globals.yaml. And this works. Any ideas why? Am 02.09.2022 um 14:19 schrieb Pierre Riteau: > Hi Oliver, > > The Kolla Ansible documentation describes how to configure Docker to > use a proxy: > https://docs.openstack.org/kolla-ansible/latest/reference/deployment-and-bootstrapping/bootstrap-servers.html#configuration > This feature was introduced in Wallaby. > > Additionally, I suggest you configure a local Docker registry and use > it to fetch container images. The same documentation page describes > related variables. > > Cheers, > Pierre Riteau (priteau) > > On Fri, 2 Sept 2022 at 13:33, Oliver Weinmann > wrote: > > Hi, > > I was wondering if there is a way to set a http proxy in > kolla-ansible > during deployment / update etc. Today I wanted to pull new containers > and this saturates our internet connection. What we usually do is > have > machine that massively download stuff from the internet use a squid > proxy that throttles their bandwidth. > > I found the following feature request: > > https://bugs.launchpad.net/kolla-ansible/+bug/1829586 > > And it seems some work had been done, but I can't seem to find any > info > if the change really made it into production: > > https://review.opendev.org/c/openstack/kolla-ansible/+/692006/ > > Any help or hints are highly appreciated. > > Cheers, > > Oliver > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elod.illes at est.tech Fri Sep 2 16:11:37 2022 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Fri, 2 Sep 2022 18:11:37 +0200 Subject: [PTL][release] Zed Cycle Highlights In-Reply-To: References: <59b540d3-f41f-b8c7-1574-d08dcdf3974d@est.tech> Message-ID: <73edffcd-ec52-e6e8-f5b4-7067866a9e73@est.tech> Hi, Thanks everyone for the responses, based on them I've proposed a patch [1] that moves the cycle highlights task from R-5 week to R-4 week. [1] https://review.opendev.org/c/openstack/releases/+/855682 Cheers, El?d On 2022. 09. 01. 21:52, Sylvain Bauza wrote: > > > Le?jeu. 1 sept. 2022 ??18:02, Allison Price a > ?crit?: > > I can jump in from a release marketing perspective. I think that > we have some flexibility while still ensuring we have a cohesive > plan for October 5. It would be great if cycle highlights can > start rolling in now so we can review them incrementally, but I > think we can give teams until the end of next week (September 9) > or even early the following week (September 13 at the latest) and > still meet all of our deadlines. > > That said, the September 14 deadline would ideally be a hard > deadline, so I would like to not push it past that. If we think > that makes more sense from a release perspective, we can make it > work from a marketing one. > > > Thanks Allison for replying by clarifying your needs, it helps a lot. > > Honestly, I wasn't asking for a two-week delay (matching with RC1), I > was just pointing out the difficulties to provide a release document > as the exact same time we were rushing into the feature deadline. > To be clear, shall we accept to punt by one week the cycle highlights > delivery deadline, I'd be more than happy with it as personnally I'd > target my duty to be done this Monday. > > -Sylvain > > Let me know if that helps. > > Thanks, > Allison > > > >> On Sep 1, 2022, at 7:38 AM, Rajat Dhasmana >> wrote: >> >> Hi Elod, >> >> I share the same concern as Sylvain. In cinder, we have provided >> an extension of 1 week after the FF to features so we are really >> not sure which changes are going to get in. I can prepare the >> highlights with the features we already have merged but that won't >> include the whole list. >> >> >> On Thu, Sep 1, 2022 at 7:56 PM El?d Ill?s >> wrote: >> >> I think the deadline is more like something to connected to >> Feature Freeze. ~After Feature Freeze we know what's in the >> cycle. If a project requests a Feature Freeze Exception, then >> of course, the FF will happen somewhere between official FF >> date (Milestone 3) and RC1, and hopefully closer to Milestone >> 3 date than RC1 date. >> >> I understand that PTLs are busy with reviewing the last >> feature patches, but I think this is more like a best effort, >> too, to prepare it as soon as possible, after the Feature Freeze. >> >> I don't know when exactly the Marketing team is processing >> the cycle highlights, but I guess they also handles these a >> bit flexible way. Probably to generally state that highlights >> are only needed by RC1 would give them much less time, more >> postponed / missing docs handling / more hurry. So while I >> think we have a bit of a flexibility with the deadline (1-2 >> working days don't really count), the best is to try to >> prepare it as soon as possible. Anyone from the Marketing >> team or from Release team, correct me if i'm wrong. >> >> El?d >> >> >> On 2022. 09. 01. 15:54, Sylvain Bauza wrote: >>> >>> >>> Le?mar. 30 ao?t 2022 ??17:45, El?d Ill?s >>> a ?crit?: >>> >>> Hi, >>> >>> This is a reminder, that *this week* is the week for Cycle highlights >>> [1][2]! They need to be added to deliverable yamls so that they can be >>> included in release marketing preparations. (See the details about how >>> to add them at the project team guide [3].) >>> >>> >>> I'm confused. If I read correctly [3] it says that cycle >>> highlights can be delivered at RC1 which makes sense to me >>> as it's post-FeatureFreeze. >>> Asking for cycle highlights the week of the FeatureFreeze is >>> both counterproductive and non-logic : While some changes >>> are still on debate and while we're not yet done with >>> merging features, we need to write a document saying what >>> we'll get. >>> >>> Couldn't we officially accept the projects to provide their >>> highlights only at RC1 ? Is it a marketing problem because >>> RC1 is closer to the GA ? >>> -Sylvain >>> >>> >>> [1]https://releases.openstack.org/zed/schedule.html >>> [2]https://releases.openstack.org/zed/schedule.html#z-cycle-highlights >>> [3] >>> https://docs.openstack.org/project-team-guide/release-management.html#cycle-highlights >>> >>> Thanks, >>> >>> El?d Ill?s >>> irc: elodilles >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arxcruz at redhat.com Fri Sep 2 16:17:42 2022 From: arxcruz at redhat.com (Arx Cruz) Date: Fri, 2 Sep 2022 18:17:42 +0200 Subject: [tripleo] gate blocker tripleo-ci-centos-9-content-provider In-Reply-To: References: Message-ID: Hello, Chandan's patch https://review.opendev.org/c/openstack/tripleo-quickstart/+/855587 that fix the bug was just merged. You may continue with your rechecks. Kind regards, Arx Cruz On Fri, Sep 2, 2022 at 8:53 AM Chandan Kumar wrote: > Hello tripleo, > > Please hold your recheck on master tripleo branch, we have a gate blocker > for tripleo-ci-centos-9-content-provider. > > https://bugs.launchpad.net/tripleo/+bug/1988514 > > The team is currently working on fixing it. > > With Regards, > > Chandan Kumar > > > -- Arx Cruz Software Engineer Red Hat EMEA arxcruz at redhat.com @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Fri Sep 2 16:31:41 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 02 Sep 2022 22:01:41 +0530 Subject: [ptl][tc][ops][ptg] Operator + Developers interaction (operator-hours) slots in 2023.1 Antelope PTG Message-ID: <182ff0b3957.11971b8a0597684.4259447734459743811@ghanshyammann.com> Hello Everyone/PTL, As you know, one of the challenges we are facing nowadays is less interaction/feedback from operators. To solve that, OpenStack TC has been discussing it in various forum/places (Board, TC meetings). One of the ideas that came from those discussions was to bring operator and developer together in events like summit, PTG etc. On that idea, we are trying to invite more operators (especially form ops meetup attendees) in next virtual PTG. Idea is to have operators join the project PTG slots. To make it easy for operators and less conflict among projects, TC has booked a few slots as 'operator hours' in different time/day. Currently those are booked as 'operator-hour-placeholder'[1]. Project can convert/reserve them to their project operator-hour, for example 'operator-hour-nova'. How project can reserve/book these 'operator hour' (Action item for projects PTL/PTG planner): ----------------------------------------------------------------------------------------------------------------- 1. Request Kendal or Fungi (in #openinfra-events IRC channel) to register the new track 'operator-hour-' for example, 'operator-hour-nova' 2. Once track is registered, pick one of the available 'operator-hour-placeholder' slot and book it with newly registered track 'operator-hour-'. For example #operator-hour-nova book essex-WedB1 * Idea to book these slots as 'operator-hour-' is to give operators a easy way to find and join. Otherwise it will be difficult for them to find such slot/time from etherpads. We request every projects to book at least one 'operator hours' slot for operators to join your PTG slot. Ping me in #openstack-tc or #openinfra-events IRC channel for any query. [1] https://ptg.opendev.org/ptg.html -gmann From pierre at stackhpc.com Fri Sep 2 16:36:38 2022 From: pierre at stackhpc.com (Pierre Riteau) Date: Fri, 2 Sep 2022 18:36:38 +0200 Subject: http proxy support In-Reply-To: <3e2d48a3-283e-0f47-44b7-d81a6915eeca@me.com> References: <5654b70a-3a0f-691e-0fdb-ec0c5bb75b20@me.com> <3e2d48a3-283e-0f47-44b7-d81a6915eeca@me.com> Message-ID: Hi Oliver, I think you have a mismatch of your kolla-ansible version here. If you look at the fluent image that it is trying to pull, you will see that it has only master-* tags: https://quay.io/repository/openstack.kolla/fluentd?tab=tags&tag=latest This is because in the development version of kolla-ansible (currently the master branch, which will be released as zed later this year) a new image naming scheme is used. You need to switch your kolla-ansible checkout to the stable/yoga branch and reinstall it to fetch the right image, which will be something like centos-source-fluentd:yoga as seen here: https://quay.io/repository/openstack.kolla/centos-source-fluentd?tab=tags&tag=latest Cheers, Pierre Riteau (priteau) On Fri, 2 Sept 2022 at 17:49, Oliver Weinmann wrote: > Hi Pierre, > > thanks for the quick reply and pointing me in the right direction. I used > a central local docker registry in the past. Is this still the latest > documentation: > > https://docs.openstack.org/kolla-ansible/latest/user/multinode.html > > I stopped using it, because I always came across problems where it was no > longer possible to pull any container images. Just today I had this issue > without using a local registry: > > TASK [service-images-pull : common | Pull images] > *********************************************************************************************************************************************************************************************************************************************************************************************************************************************************** > FAILED - RETRYING: common | Pull images (3 retries left). > FAILED - RETRYING: common | Pull images (3 retries left). > FAILED - RETRYING: common | Pull images (3 retries left). > FAILED - RETRYING: common | Pull images (3 retries left). > FAILED - RETRYING: common | Pull images (3 retries left). > FAILED - RETRYING: common | Pull images (2 retries left). > FAILED - RETRYING: common | Pull images (2 retries left). > FAILED - RETRYING: common | Pull images (2 retries left). > FAILED - RETRYING: common | Pull images (2 retries left). > FAILED - RETRYING: common | Pull images (2 retries left). > FAILED - RETRYING: common | Pull images (1 retries left). > FAILED - RETRYING: common | Pull images (1 retries left). > FAILED - RETRYING: common | Pull images (1 retries left). > FAILED - RETRYING: common | Pull images (1 retries left). > FAILED - RETRYING: common | Pull images (1 retries left). > failed: [gedaopl09] (item=fluentd) => {"ansible_loop_var": "item", > "attempts": 3, "changed": true, "item": {"key": "fluentd", "value": > {"container_name": "fluentd", "dimensions": {}, "enabled": true, > "environment": {"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS"}, "group": > "fluentd", "image": "quay.io/openstack.kolla/fluentd:yoga-centos-stream8", > "volumes": ["/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro", > "/etc/localtime:/etc/localtime:ro", "", "kolla_logs:/var/log/kolla/", > "fluentd_data:/var/lib/fluentd/data/"]}}, "msg": "'Traceback (most recent > call last):\\n File > \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, > in _raise_for_status\\n response.raise_for_status()\\n File > \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in > raise_for_status\\n raise HTTPError(http_error_msg, > response=self)\\nrequests.exceptions.HTTPError: 404 Client Error: Not Found > for url: > http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage= > quay.io%2Fopenstack.kolla%2Ffluentd\\n\\nDuring handling of the above > exception, another exception occurred:\\n\\nTraceback (most recent call > last):\\n File > \"/tmp/ansible_kolla_docker_payload_w20pu6xy/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", > line 381, in main\\n File > \"/tmp/ansible_kolla_docker_payload_w20pu6xy/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", > line 451, in pull_image\\n repository=image, tag=tag, stream=True\\n > File \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line > 430, in pull\\n self._raise_for_status(response)\\n File > \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, > in _raise_for_status\\n raise > create_api_error_from_http_exception(e)\\n File > \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, in > create_api_error_from_http_exception\\n raise cls(e, response=response, > explanation=explanation)\\ndocker.errors.NotFound: 404 Client Error for > http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage= > quay.io%2Fopenstack.kolla%2Ffluentd: Not Found (\"manifest for > quay.io/openstack.kolla/fluentd:yoga-centos-stream8 not found: manifest > unknown: manifest unknown\")\\n'"} > failed: [gedaopl11] (item=fluentd) => {"ansible_loop_var": "item", > "attempts": 3, "changed": true, "item": {"key": "fluentd", "value": > {"container_name": "fluentd", "dimensions": {}, "enabled": true, > "environment": {"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS"}, "group": > "fluentd", "image": "quay.io/openstack.kolla/fluentd:yoga-centos-stream8", > "volumes": ["/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro", > "/etc/localtime:/etc/localtime:ro", "", "kolla_logs:/var/log/kolla/", > "fluentd_data:/var/lib/fluentd/data/"]}}, "msg": "'Traceback (most recent > call last):\\n File > \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, > in _raise_for_status\\n response.raise_for_status()\\n File > \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in > raise_for_status\\n raise HTTPError(http_error_msg, > response=self)\\nrequests.exceptions.HTTPError: 404 Client Error: Not Found > for url: > http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage= > quay.io%2Fopenstack.kolla%2Ffluentd\\n\\nDuring handling of the above > exception, another exception occurred:\\n\\nTraceback (most recent call > last):\\n File > \"/tmp/ansible_kolla_docker_payload_xgz79c_7/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", > line 381, in main\\n File > \"/tmp/ansible_kolla_docker_payload_xgz79c_7/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", > line 451, in pull_image\\n repository=image, tag=tag, stream=True\\n > File \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line > 430, in pull\\n self._raise_for_status(response)\\n File > \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, > in _raise_for_status\\n raise > create_api_error_from_http_exception(e)\\n File > \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, in > create_api_error_from_http_exception\\n raise cls(e, response=response, > explanation=explanation)\\ndocker.errors.NotFound: 404 Client Error for > http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage= > quay.io%2Fopenstack.kolla%2Ffluentd: Not Found (\"manifest for > quay.io/openstack.kolla/fluentd:yoga-centos-stream8 not found: manifest > unknown: manifest unknown\")\\n'"} > failed: [gedaopl04] (item=fluentd) => {"ansible_loop_var": "item", > "attempts": 3, "changed": true, "item": {"key": "fluentd", "value": > {"container_name": "fluentd", "dimensions": {}, "enabled": true, > "environment": {"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS"}, "group": > "fluentd", "image": "quay.io/openstack.kolla/fluentd:yoga-centos-stream8", > "volumes": ["/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro", > "/etc/localtime:/etc/localtime:ro", "", "kolla_logs:/var/log/kolla/", > "fluentd_data:/var/lib/fluentd/data/"]}}, "msg": "'Traceback (most recent > call last):\\n File > \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, > in _raise_for_status\\n response.raise_for_status()\\n File > \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in > raise_for_status\\n raise HTTPError(http_error_msg, > response=self)\\nrequests.exceptions.HTTPError: 404 Client Error: Not Found > for url: > http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage= > quay.io%2Fopenstack.kolla%2Ffluentd\\n\\nDuring handling of the above > exception, another exception occurred:\\n\\nTraceback (most recent call > last):\\n File > \"/tmp/ansible_kolla_docker_payload_1petvtop/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", > line 381, in main\\n File > \"/tmp/ansible_kolla_docker_payload_1petvtop/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", > line 451, in pull_image\\n repository=image, tag=tag, stream=True\\n > File \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line > 430, in pull\\n self._raise_for_status(response)\\n File > \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, > in _raise_for_status\\n raise > create_api_error_from_http_exception(e)\\n File > \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, in > create_api_error_from_http_exception\\n raise cls(e, response=response, > explanation=explanation)\\ndocker.errors.NotFound: 404 Client Error for > http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage= > quay.io%2Fopenstack.kolla%2Ffluentd: Not Found (\"manifest for > quay.io/openstack.kolla/fluentd:yoga-centos-stream8 not found: manifest > unknown: manifest unknown\")\\n'"} > failed: [gedaopl07] (item=fluentd) => {"ansible_loop_var": "item", > "attempts": 3, "changed": true, "item": {"key": "fluentd", "value": > {"container_name": "fluentd", "dimensions": {}, "enabled": true, > "environment": {"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS"}, "group": > "fluentd", "image": "quay.io/openstack.kolla/fluentd:yoga-centos-stream8", > "volumes": ["/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro", > "/etc/localtime:/etc/localtime:ro", "", "kolla_logs:/var/log/kolla/", > "fluentd_data:/var/lib/fluentd/data/"]}}, "msg": "'Traceback (most recent > call last):\\n File > \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, > in _raise_for_status\\n response.raise_for_status()\\n File > \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in > raise_for_status\\n raise HTTPError(http_error_msg, > response=self)\\nrequests.exceptions.HTTPError: 404 Client Error: Not Found > for url: > http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage= > quay.io%2Fopenstack.kolla%2Ffluentd\\n\\nDuring handling of the above > exception, another exception occurred:\\n\\nTraceback (most recent call > last):\\n File > \"/tmp/ansible_kolla_docker_payload_uzj0wg5e/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", > line 381, in main\\n File > \"/tmp/ansible_kolla_docker_payload_uzj0wg5e/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", > line 451, in pull_image\\n repository=image, tag=tag, stream=True\\n > File \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line > 430, in pull\\n self._raise_for_status(response)\\n File > \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, > in _raise_for_status\\n raise > create_api_error_from_http_exception(e)\\n File > \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, in > create_api_error_from_http_exception\\n raise cls(e, response=response, > explanation=explanation)\\ndocker.errors.NotFound: 404 Client Error for > http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage= > quay.io%2Fopenstack.kolla%2Ffluentd: Not Found (\"manifest for > quay.io/openstack.kolla/fluentd:yoga-centos-stream8 not found: manifest > unknown: manifest unknown\")\\n'"} > failed: [gedaopl10] (item=fluentd) => {"ansible_loop_var": "item", > "attempts": 3, "changed": true, "item": {"key": "fluentd", "value": > {"container_name": "fluentd", "dimensions": {}, "enabled": true, > "environment": {"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS"}, "group": > "fluentd", "image": "quay.io/openstack.kolla/fluentd:yoga-centos-stream8", > "volumes": ["/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro", > "/etc/localtime:/etc/localtime:ro", "", "kolla_logs:/var/log/kolla/", > "fluentd_data:/var/lib/fluentd/data/"]}}, "msg": "'Traceback (most recent > call last):\\n File > \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, > in _raise_for_status\\n response.raise_for_status()\\n File > \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in > raise_for_status\\n raise HTTPError(http_error_msg, > response=self)\\nrequests.exceptions.HTTPError: 404 Client Error: Not Found > for url: > http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage= > quay.io%2Fopenstack.kolla%2Ffluentd\\n\\nDuring handling of the above > exception, another exception occurred:\\n\\nTraceback (most recent call > last):\\n File > \"/tmp/ansible_kolla_docker_payload_a6kiyuhn/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", > line 381, in main\\n File > \"/tmp/ansible_kolla_docker_payload_a6kiyuhn/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", > line 451, in pull_image\\n repository=image, tag=tag, stream=True\\n > File \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line > 430, in pull\\n self._raise_for_status(response)\\n File > \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, > in _raise_for_status\\n raise > create_api_error_from_http_exception(e)\\n File > \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, in > create_api_error_from_http_exception\\n raise cls(e, response=response, > explanation=explanation)\\ndocker.errors.NotFound: 404 Client Error for > http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage= > quay.io%2Fopenstack.kolla%2Ffluentd: Not Found (\"manifest for > quay.io/openstack.kolla/fluentd:yoga-centos-stream8 not found: manifest > unknown: manifest unknown\")\\n'"} > FAILED - RETRYING: common | Pull images (3 retries left). > FAILED - RETRYING: common | Pull images (3 retries left). > FAILED - RETRYING: common | Pull images (3 retries left). > FAILED - RETRYING: common | Pull images (3 retries left). > FAILED - RETRYING: common | Pull images (3 retries left). > FAILED - RETRYING: common | Pull images (2 retries left). > FAILED - RETRYING: common | Pull images (2 retries left). > FAILED - RETRYING: common | Pull images (2 retries left). > FAILED - RETRYING: common | Pull images (2 retries left). > FAILED - RETRYING: common | Pull images (2 retries left). > > I'm on release Yoga and for some weird reason, I found the suggestion to > change release yoga to master in /etc/kolla/globals.yaml. And this works. > Any ideas why? > Am 02.09.2022 um 14:19 schrieb Pierre Riteau: > > Hi Oliver, > > The Kolla Ansible documentation describes how to configure Docker to use a > proxy: > https://docs.openstack.org/kolla-ansible/latest/reference/deployment-and-bootstrapping/bootstrap-servers.html#configuration > This feature was introduced in Wallaby. > > Additionally, I suggest you configure a local Docker registry and use it > to fetch container images. The same documentation page describes related > variables. > > Cheers, > Pierre Riteau (priteau) > > On Fri, 2 Sept 2022 at 13:33, Oliver Weinmann > wrote: > >> Hi, >> >> I was wondering if there is a way to set a http proxy in kolla-ansible >> during deployment / update etc. Today I wanted to pull new containers >> and this saturates our internet connection. What we usually do is have >> machine that massively download stuff from the internet use a squid >> proxy that throttles their bandwidth. >> >> I found the following feature request: >> >> https://bugs.launchpad.net/kolla-ansible/+bug/1829586 >> >> And it seems some work had been done, but I can't seem to find any info >> if the change really made it into production: >> >> https://review.opendev.org/c/openstack/kolla-ansible/+/692006/ >> >> Any help or hints are highly appreciated. >> >> Cheers, >> >> Oliver >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Fri Sep 2 16:41:52 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 02 Sep 2022 22:11:52 +0530 Subject: [tc][ptl] TC + Community Leaders interaction in 2023.1 Antelope Virtual PTG In-Reply-To: <182d57d0aad.bf056e04140280.2087630437258918780@ghanshyammann.com> References: <182d57d0aad.bf056e04140280.2087630437258918780@ghanshyammann.com> Message-ID: <182ff148930.f2078e69598027.4645920823703892531@ghanshyammann.com> Updates: I have booked the Monday 15-17 UTC (2 hours) for TC+leaders interaction discussion. Details are there in below etherpad, please add the topic you would like to discuss: - https://etherpad.opendev.org/p/tc-leaders-interaction-2023-1 -gmann ---- On Thu, 25 Aug 2022 20:21:57 +0530 Ghanshyam Mann wrote --- > Hello Everyone, > > We had successful TC+Community leaders interaction sessions in the last couple of PTG, and we will > continue the same for 2023.1 cycle PTG also. > > I have created the poll to select the best suitable time. It will be for two hours > (single or two sessions) either on Monday or Tuesday. Please add your preference in the below > doodle poll (including TC members): > > - https://framadate.org/zsOqRxfVcmtjaPBC > > Also, I have created the below etherpad with the draft agenda, If you as PTL or project representatives > or SIG Chair and would like to attend this session, please add your name: > > - https://etherpad.opendev.org/p/tc-leaders-interaction-2023-1 > > -gmann > > > From ignaziocassano at gmail.com Fri Sep 2 17:06:33 2022 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Fri, 2 Sep 2022 19:06:33 +0200 Subject: [openstack][quuens][cinder] consistency groups bug ? Message-ID: Hi everyone, in my openstack installation, for performance reasons, I use a cinder type to address different storage virtual machines on the same device. Balancing takes place via the scheduler. Below is an example of my configuration in cinder.conf: https://paste.openstack.org/show/b0hCTsdniLhinoQiVT7A/ As you can see nfsgold1 to nfsgold8 are all part of the volume type nfsgold. Unfortunately if I create a consistency group with volume type nfsgold, it can only contain volumes on the same backend, even though they are of the same type. For example, if in my consistency group there is a volume on nfsgold1 and I add a volume present on nfsgold8 I get the following: https://paste.openstack.org/show/b4XnUeGDF5wYlCBLTcuc/ Any help, please ? Ignazio -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Fri Sep 2 18:09:44 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 02 Sep 2022 23:39:44 +0530 Subject: [all][tc] What's happening in Technical Committee: summary 2022 Sept 2: Reading: 5 min Message-ID: <182ff64fd0c.e6387fe6600475.8995582836540372219@ghanshyammann.com> Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week's meeting on Sept 01. Most of the meeting discussions are summarized in this email. Meeting full recording is available @ https://www.youtube.com/watch?v=WDfOx1m-wog and summary logs are available @https://meetings.opendev.org/meetings/tc/2022/tc.2022-09-01-15.01.log.html * Next TC weekly meeting will be on Sept 08 Thursday at 15:00 UTC, feel free to add the topic on the agenda[1] by Sept 07. 2. What we completed this week: ========================= * Appointed Dale Smith as Adjutant PTL for Zed cycle[2] * Switched requirements to distributed leadership [3] * Added Exception for the combined 2023.1(Antelope) elections [4] 3. Activities In progress: ================== TC Tracker for Zed cycle ------------------------------ * Zed tracker etherpad includes the TC working items[5], four are completed and others items are in-progress. Open Reviews ----------------- * Four open reviews for ongoing activities[6]. 2023.1 cycle Technical Election (TC + PTL) planning ------------------------------------------------------------- By considering the holiday weeks, we decided to extend the nomination by a week[7]. The new deadline for nomination is Sept 7 [8]. We request you not to delay your nomination for PTL or TC. Define 2023.1 cycle testing runtime ------------------------------------------- Testing runtime for the 2023.1 cycle is up for review [9]. 2023.1 cycle TC PTG planning ------------------------------------ Updates on PTG planning: * "TC + Leader interaction" sessions is scheduled for Oct 17 Monday 15-17 UTC[10], * I have created the TC PTG etherpad to collect the topic[11]. * I sent email about the 'Operator Hours' slots in this PTG, please check and reserve the operator hour slot for your project[12] 2021 User Survey TC Question Analysis ----------------------------------------------- No update on this. The survey summary is up for review[13]. Feel free to check and provide feedback. Fixing Zuul config error ---------------------------- Requesting projects with zuul config error to look into those and fix them which should not take much time[14]15]. Project updates ------------------- * Switch release management to distributed leadership[16] 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[17]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [18] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://review.opendev.org/c/openstack/governance/+/849606 [3] https://review.opendev.org/c/openstack/governance/+/854685 [4] https://review.opendev.org/c/openstack/governance/+/854624 [5] https://etherpad.opendev.org/p/tc-zed-tracker [6] https://review.opendev.org/q/projects:openstack/governance+status:open [7] https://lists.openstack.org/pipermail/openstack-discuss/2022-August/030241.html [8] https://governance.openstack.org/election/ [9] https://review.opendev.org/c/openstack/governance/+/854375 [10] https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030303.html [11] https://etherpad.opendev.org/p/tc-2023-1-ptg [12] https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030301.html [13] https://review.opendev.org/c/openstack/governance/+/836888 [14] https://etherpad.opendev.org/p/zuul-config-error-openstack [15] http://lists.openstack.org/pipermail/openstack-discuss/2022-May/028603.html [16] https://review.opendev.org/c/openstack/governance/+/855276 [17] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [18] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann From oliver.weinmann at me.com Fri Sep 2 18:34:40 2022 From: oliver.weinmann at me.com (Oliver Weinmann) Date: Fri, 2 Sep 2022 20:34:40 +0200 Subject: http proxy support In-Reply-To: References: Message-ID: Hi Pierre, Right I messed it up just today. Copy pasted the command from a kolla page about updating and this refers to master. One more question about the variables for http proxy. They have to be in /etc/kolla/globals.yml? In case I want to go with the central local docker repo. I have run the steps to install a local docker repo on my seed node. The node from where I run kolla-ansible to deploy Openstack. Do I need to run a bootstrap for all-in-one so that the proxy setting is configured? Von meinem iPhone gesendet > Am 02.09.2022 um 18:52 schrieb Pierre Riteau : > > ? > Hi Oliver, > > I think you have a mismatch of your kolla-ansible version here. If you look at the fluent image that it is trying to pull, you will see that it has only master-* tags: https://quay.io/repository/openstack.kolla/fluentd?tab=tags&tag=latest > > This is because in the development version of kolla-ansible (currently the master branch, which will be released as zed later this year) a new image naming scheme is used. > > You need to switch your kolla-ansible checkout to the stable/yoga branch and reinstall it to fetch the right image, which will be something like centos-source-fluentd:yoga as seen here: https://quay.io/repository/openstack.kolla/centos-source-fluentd?tab=tags&tag=latest > > Cheers, > Pierre Riteau (priteau) > >> On Fri, 2 Sept 2022 at 17:49, Oliver Weinmann wrote: >> Hi Pierre, >> >> thanks for the quick reply and pointing me in the right direction. I used a central local docker registry in the past. Is this still the latest documentation: >> >> https://docs.openstack.org/kolla-ansible/latest/user/multinode.html >> >> I stopped using it, because I always came across problems where it was no longer possible to pull any container images. Just today I had this issue without using a local registry: >> >> TASK [service-images-pull : common | Pull images] *********************************************************************************************************************************************************************************************************************************************************************************************************************************************************** >> FAILED - RETRYING: common | Pull images (3 retries left). >> FAILED - RETRYING: common | Pull images (3 retries left). >> FAILED - RETRYING: common | Pull images (3 retries left). >> FAILED - RETRYING: common | Pull images (3 retries left). >> FAILED - RETRYING: common | Pull images (3 retries left). >> FAILED - RETRYING: common | Pull images (2 retries left). >> FAILED - RETRYING: common | Pull images (2 retries left). >> FAILED - RETRYING: common | Pull images (2 retries left). >> FAILED - RETRYING: common | Pull images (2 retries left). >> FAILED - RETRYING: common | Pull images (2 retries left). >> FAILED - RETRYING: common | Pull images (1 retries left). >> FAILED - RETRYING: common | Pull images (1 retries left). >> FAILED - RETRYING: common | Pull images (1 retries left). >> FAILED - RETRYING: common | Pull images (1 retries left). >> FAILED - RETRYING: common | Pull images (1 retries left). >> failed: [gedaopl09] (item=fluentd) => {"ansible_loop_var": "item", "attempts": 3, "changed": true, "item": {"key": "fluentd", "value": {"container_name": "fluentd", "dimensions": {}, "enabled": true, "environment": {"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS"}, "group": "fluentd", "image": "quay.io/openstack.kolla/fluentd:yoga-centos-stream8", "volumes": ["/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro", "/etc/localtime:/etc/localtime:ro", "", "kolla_logs:/var/log/kolla/", "fluentd_data:/var/lib/fluentd/data/"]}}, "msg": "'Traceback (most recent call last):\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, in _raise_for_status\\n response.raise_for_status()\\n File \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in raise_for_status\\n raise HTTPError(http_error_msg, response=self)\\nrequests.exceptions.HTTPError: 404 Client Error: Not Found for url: http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd\\n\\nDuring handling of the above exception, another exception occurred:\\n\\nTraceback (most recent call last):\\n File \"/tmp/ansible_kolla_docker_payload_w20pu6xy/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 381, in main\\n File \"/tmp/ansible_kolla_docker_payload_w20pu6xy/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", line 451, in pull_image\\n repository=image, tag=tag, stream=True\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line 430, in pull\\n self._raise_for_status(response)\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, in _raise_for_status\\n raise create_api_error_from_http_exception(e)\\n File \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, in create_api_error_from_http_exception\\n raise cls(e, response=response, explanation=explanation)\\ndocker.errors.NotFound: 404 Client Error for http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd: Not Found (\"manifest for quay.io/openstack.kolla/fluentd:yoga-centos-stream8 not found: manifest unknown: manifest unknown\")\\n'"} >> failed: [gedaopl11] (item=fluentd) => {"ansible_loop_var": "item", "attempts": 3, "changed": true, "item": {"key": "fluentd", "value": {"container_name": "fluentd", "dimensions": {}, "enabled": true, "environment": {"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS"}, "group": "fluentd", "image": "quay.io/openstack.kolla/fluentd:yoga-centos-stream8", "volumes": ["/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro", "/etc/localtime:/etc/localtime:ro", "", "kolla_logs:/var/log/kolla/", "fluentd_data:/var/lib/fluentd/data/"]}}, "msg": "'Traceback (most recent call last):\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, in _raise_for_status\\n response.raise_for_status()\\n File \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in raise_for_status\\n raise HTTPError(http_error_msg, response=self)\\nrequests.exceptions.HTTPError: 404 Client Error: Not Found for url: http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd\\n\\nDuring handling of the above exception, another exception occurred:\\n\\nTraceback (most recent call last):\\n File \"/tmp/ansible_kolla_docker_payload_xgz79c_7/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 381, in main\\n File \"/tmp/ansible_kolla_docker_payload_xgz79c_7/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", line 451, in pull_image\\n repository=image, tag=tag, stream=True\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line 430, in pull\\n self._raise_for_status(response)\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, in _raise_for_status\\n raise create_api_error_from_http_exception(e)\\n File \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, in create_api_error_from_http_exception\\n raise cls(e, response=response, explanation=explanation)\\ndocker.errors.NotFound: 404 Client Error for http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd: Not Found (\"manifest for quay.io/openstack.kolla/fluentd:yoga-centos-stream8 not found: manifest unknown: manifest unknown\")\\n'"} >> failed: [gedaopl04] (item=fluentd) => {"ansible_loop_var": "item", "attempts": 3, "changed": true, "item": {"key": "fluentd", "value": {"container_name": "fluentd", "dimensions": {}, "enabled": true, "environment": {"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS"}, "group": "fluentd", "image": "quay.io/openstack.kolla/fluentd:yoga-centos-stream8", "volumes": ["/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro", "/etc/localtime:/etc/localtime:ro", "", "kolla_logs:/var/log/kolla/", "fluentd_data:/var/lib/fluentd/data/"]}}, "msg": "'Traceback (most recent call last):\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, in _raise_for_status\\n response.raise_for_status()\\n File \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in raise_for_status\\n raise HTTPError(http_error_msg, response=self)\\nrequests.exceptions.HTTPError: 404 Client Error: Not Found for url: http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd\\n\\nDuring handling of the above exception, another exception occurred:\\n\\nTraceback (most recent call last):\\n File \"/tmp/ansible_kolla_docker_payload_1petvtop/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 381, in main\\n File \"/tmp/ansible_kolla_docker_payload_1petvtop/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", line 451, in pull_image\\n repository=image, tag=tag, stream=True\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line 430, in pull\\n self._raise_for_status(response)\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, in _raise_for_status\\n raise create_api_error_from_http_exception(e)\\n File \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, in create_api_error_from_http_exception\\n raise cls(e, response=response, explanation=explanation)\\ndocker.errors.NotFound: 404 Client Error for http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd: Not Found (\"manifest for quay.io/openstack.kolla/fluentd:yoga-centos-stream8 not found: manifest unknown: manifest unknown\")\\n'"} >> failed: [gedaopl07] (item=fluentd) => {"ansible_loop_var": "item", "attempts": 3, "changed": true, "item": {"key": "fluentd", "value": {"container_name": "fluentd", "dimensions": {}, "enabled": true, "environment": {"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS"}, "group": "fluentd", "image": "quay.io/openstack.kolla/fluentd:yoga-centos-stream8", "volumes": ["/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro", "/etc/localtime:/etc/localtime:ro", "", "kolla_logs:/var/log/kolla/", "fluentd_data:/var/lib/fluentd/data/"]}}, "msg": "'Traceback (most recent call last):\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, in _raise_for_status\\n response.raise_for_status()\\n File \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in raise_for_status\\n raise HTTPError(http_error_msg, response=self)\\nrequests.exceptions.HTTPError: 404 Client Error: Not Found for url: http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd\\n\\nDuring handling of the above exception, another exception occurred:\\n\\nTraceback (most recent call last):\\n File \"/tmp/ansible_kolla_docker_payload_uzj0wg5e/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 381, in main\\n File \"/tmp/ansible_kolla_docker_payload_uzj0wg5e/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", line 451, in pull_image\\n repository=image, tag=tag, stream=True\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line 430, in pull\\n self._raise_for_status(response)\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, in _raise_for_status\\n raise create_api_error_from_http_exception(e)\\n File \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, in create_api_error_from_http_exception\\n raise cls(e, response=response, explanation=explanation)\\ndocker.errors.NotFound: 404 Client Error for http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd: Not Found (\"manifest for quay.io/openstack.kolla/fluentd:yoga-centos-stream8 not found: manifest unknown: manifest unknown\")\\n'"} >> failed: [gedaopl10] (item=fluentd) => {"ansible_loop_var": "item", "attempts": 3, "changed": true, "item": {"key": "fluentd", "value": {"container_name": "fluentd", "dimensions": {}, "enabled": true, "environment": {"KOLLA_CONFIG_STRATEGY": "COPY_ALWAYS"}, "group": "fluentd", "image": "quay.io/openstack.kolla/fluentd:yoga-centos-stream8", "volumes": ["/etc/kolla/fluentd/:/var/lib/kolla/config_files/:ro", "/etc/localtime:/etc/localtime:ro", "", "kolla_logs:/var/log/kolla/", "fluentd_data:/var/lib/fluentd/data/"]}}, "msg": "'Traceback (most recent call last):\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 268, in _raise_for_status\\n response.raise_for_status()\\n File \"/usr/lib/python3.6/site-packages/requests/models.py\", line 940, in raise_for_status\\n raise HTTPError(http_error_msg, response=self)\\nrequests.exceptions.HTTPError: 404 Client Error: Not Found for url: http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd\\n\\nDuring handling of the above exception, another exception occurred:\\n\\nTraceback (most recent call last):\\n File \"/tmp/ansible_kolla_docker_payload_a6kiyuhn/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", line 381, in main\\n File \"/tmp/ansible_kolla_docker_payload_a6kiyuhn/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", line 451, in pull_image\\n repository=image, tag=tag, stream=True\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line 430, in pull\\n self._raise_for_status(response)\\n File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line 270, in _raise_for_status\\n raise create_api_error_from_http_exception(e)\\n File \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", line 31, in create_api_error_from_http_exception\\n raise cls(e, response=response, explanation=explanation)\\ndocker.errors.NotFound: 404 Client Error for http+docker://localhost/v1.41/images/create?tag=yoga-centos-stream8&fromImage=quay.io%2Fopenstack.kolla%2Ffluentd: Not Found (\"manifest for quay.io/openstack.kolla/fluentd:yoga-centos-stream8 not found: manifest unknown: manifest unknown\")\\n'"} >> FAILED - RETRYING: common | Pull images (3 retries left). >> FAILED - RETRYING: common | Pull images (3 retries left). >> FAILED - RETRYING: common | Pull images (3 retries left). >> FAILED - RETRYING: common | Pull images (3 retries left). >> FAILED - RETRYING: common | Pull images (3 retries left). >> FAILED - RETRYING: common | Pull images (2 retries left). >> FAILED - RETRYING: common | Pull images (2 retries left). >> FAILED - RETRYING: common | Pull images (2 retries left). >> FAILED - RETRYING: common | Pull images (2 retries left). >> FAILED - RETRYING: common | Pull images (2 retries left). >> >> I'm on release Yoga and for some weird reason, I found the suggestion to change release yoga to master in /etc/kolla/globals.yaml. And this works. Any ideas why? >> >> Am 02.09.2022 um 14:19 schrieb Pierre Riteau: >>> Hi Oliver, >>> >>> The Kolla Ansible documentation describes how to configure Docker to use a proxy: https://docs.openstack.org/kolla-ansible/latest/reference/deployment-and-bootstrapping/bootstrap-servers.html#configuration >>> This feature was introduced in Wallaby. >>> >>> Additionally, I suggest you configure a local Docker registry and use it to fetch container images. The same documentation page describes related variables. >>> >>> Cheers, >>> Pierre Riteau (priteau) >>> >>> On Fri, 2 Sept 2022 at 13:33, Oliver Weinmann wrote: >>>> Hi, >>>> >>>> I was wondering if there is a way to set a http proxy in kolla-ansible >>>> during deployment / update etc. Today I wanted to pull new containers >>>> and this saturates our internet connection. What we usually do is have >>>> machine that massively download stuff from the internet use a squid >>>> proxy that throttles their bandwidth. >>>> >>>> I found the following feature request: >>>> >>>> https://bugs.launchpad.net/kolla-ansible/+bug/1829586 >>>> >>>> And it seems some work had been done, but I can't seem to find any info >>>> if the change really made it into production: >>>> >>>> https://review.opendev.org/c/openstack/kolla-ansible/+/692006/ >>>> >>>> Any help or hints are highly appreciated. >>>> >>>> Cheers, >>>> >>>> Oliver >>>> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ignaziocassano at gmail.com Sat Sep 3 10:21:20 2022 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Sat, 3 Sep 2022 12:21:20 +0200 Subject: [openstack][quuens][cinder] consistency groups bug ? In-Reply-To: References: Message-ID: Hello, some updates. The issue appears also using volume group instead of consistency groups. Ignazio Il giorno ven 2 set 2022 alle ore 19:06 Ignazio Cassano < ignaziocassano at gmail.com> ha scritto: > Hi everyone, in my openstack installation, for performance reasons, I use > a cinder type to address different storage virtual machines on the same > device. Balancing takes place via the scheduler. Below is an example of > my configuration in cinder.conf: > > https://paste.openstack.org/show/b0hCTsdniLhinoQiVT7A/ > > As you can see nfsgold1 to nfsgold8 are all part of the volume type > nfsgold. > Unfortunately if I create a consistency group with volume type nfsgold, it > can only contain volumes on the same backend, even though they are of the > same type. For example, if in my consistency group there is a volume on > nfsgold1 and I add a volume present on nfsgold8 I get the following: > > https://paste.openstack.org/show/b4XnUeGDF5wYlCBLTcuc/ > > > Any help, please ? > Ignazio > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkajinam at redhat.com Sat Sep 3 14:13:03 2022 From: tkajinam at redhat.com (Takashi Kajinami) Date: Sat, 3 Sep 2022 23:13:03 +0900 Subject: [puppet] Gate blocker: enabling neutron-ovn-metadata-agent consistently fails in CentOS Stream 9 Message-ID: Hello, Currently we are facing a problem with integration jobs with ml2+ovn in CentOS Stream 9 ( puppet-openstack-integration-7-scenario00[35]-tempest-centos-9-stream ) and these jobs are consistently failing. Details can be found in https://launchpad.net/bugs/1988552 . I've already reported the issue to RDO and CentOS Stream to get their help while I'm also implementing a temporary workaround. https://review.opendev.org/c/openstack/puppet-openstack-integration/+/855617 Please avoid rechecking/approving patches until these jobs are fixed. Thank you, Takashi -------------- next part -------------- An HTML attachment was scrubbed... URL: From marios at redhat.com Mon Sep 5 05:44:25 2022 From: marios at redhat.com (Marios Andreou) Date: Mon, 5 Sep 2022 08:44:25 +0300 Subject: [election][tripleo] PTL Candidacy for Antelope cycle In-Reply-To: References: Message-ID: +1 thank you Rabi On Tue, Aug 30, 2022 at 5:35 PM Rabi Mishra wrote: > > Hi All, > > I would like to nominate myself for Antelope cycle TripleO PTL. > > As some of you would know, I have been part of the OpenStack community > for a long time and have been a core contributor for TripleO and Heat. > I have also served as Heat PTL for Ocata cycle. > > James has done a great job as PTL for the last few cycles. I would like > to take the opportunity to thank him for all his effort and we all would > agree that he needs a well deserved break. > > I am looking forward to take the opportunity to help the community to > achieve some of the already planned goals and in-progress workstreams > like standalone roles, multi-rhel and other challenges that come along > the way. > > Also, as before, our focus would continue to be on review prioritization, > in progress work streams and collaboration on common priorities. > > Regards, > Rabi Mishra > From kkchn.in at gmail.com Mon Sep 5 06:42:40 2022 From: kkchn.in at gmail.com (KK CHN) Date: Mon, 5 Sep 2022 12:12:40 +0530 Subject: Kolla-ansible all-in-one and Hyper Converged solution Message-ID: Hi, [1 ] I am aiming for a prototype of HCI on a DELL ( R650 2 CPU and 40 cores . 2.4 TB) server machine. The Operating System choice is Debian 10. [2] Right now I am successful in Kolla-ansible all-in-one installation of Wallaby/stable on a Debian 10 Virtual machine with the default configs enabled as in the documentation " https://docs.openstack.org/project-deploy-guide/kolla-ansible/wallaby/uickstart.html " in Virtualenv setup. Able to get the horizon dashboard with the default services enabled and created and tested the cirros VM launching .. working fine. [3 ] I have to repeat the same all-in-one deployment on the physical machine as in [1] with the default configs and then convert it as an HCI node. What all features do I need to configure / enable in all-in-on / globals.yml to convert this box as a working HCI node ? Any hints / directives for the essential configurations needed for this server box to convert it as an HCI node are most welcome. kindly shed some light on this and any reference documents/URLs to do this ? Thank you, Krish -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.juszkiewicz at linaro.org Mon Sep 5 07:09:10 2022 From: marcin.juszkiewicz at linaro.org (Marcin Juszkiewicz) Date: Mon, 5 Sep 2022 09:09:10 +0200 Subject: Kolla-ansible all-in-one and Hyper Converged solution In-Reply-To: References: Message-ID: <47c2db9b-222d-aa47-accc-fabc13a895f1@linaro.org> W dniu 5.09.2022 o?08:42, KK CHN pisze: > > [1 ]?? I am aiming for a prototype of HCI? on a DELL ( R650? 2 CPU and 40 > ?cores . 2.4 TB) server machine.? The Operating System choice is Debian 10. > > [2]? Right now I am successful in > > ? Kolla-ansible all-in-one? installation of Wallaby/stable on a? Debian > 10 Virtual machine with the default configs enabled as in the documentation Debian 10 'buster' is not supported in Wallaby. Upgrade to Debian 11 'bullseye' first. Victoria was the last release supporting Debian 10 and is not supported. From elod.illes at est.tech Mon Sep 5 07:24:07 2022 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Mon, 5 Sep 2022 09:24:07 +0200 Subject: [adjutant][magnum][mistral][sahara][watcher][zaqar][tc] broken gate for deliverables Message-ID: Hi, Now that we have passed Zed-3 milestone, Release team starts to check the health of deliverables via their gate healthiness. The 1st round of checks showed that the following deliverables seem to have blocked gates: python-adjutantclient [1] python-magnumclient [2] python-mistralclient [3] python-saharaclient [4] python-watcherclient [5] python-zaqarclient [6] We are asking the teams to fix their gates and propose a release after it is fixed as soon as possible, otherwise these deliverables might not be part of the official Zed release. [1] https://review.opendev.org/c/openstack/python-adjutantclient/+/855763 [2] https://review.opendev.org/c/openstack/python-magnumclient/+/855778 [3] https://review.opendev.org/c/openstack/python-mistralclient/+/855781 [4] https://review.opendev.org/c/openstack/python-zaqarclient/+/855796 [5] https://review.opendev.org/c/openstack/python-watcherclient/+/855795 [6] https://review.opendev.org/c/openstack/python-saharaclient/+/855787 Thanks, El?d Ill?s irc: elodilles From tobias.urdin at binero.com Mon Sep 5 07:51:57 2022 From: tobias.urdin at binero.com (Tobias Urdin) Date: Mon, 5 Sep 2022 07:51:57 +0000 Subject: [all] [oslo.messaging] Interest in collaboration on a NATS driver In-Reply-To: References: <52AA12A0-AE67-4EF7-B924-DE1F2873B909@binero.com> Message-ID: <0E347D5A-967D-42E3-AC00-56034907053B@binero.com> Thanks! It seems that we have some traction here to get started in a more structured manner. I?m on PTO today but back tomorrow, what do people feel about scheduling a recurring meeting about this topic? I still need to read through the old spec and old implementation of NATS, and I am a bit restricted on time currently but we could brainstorm in that meeting and get us started on a new/updated the other spec. Should also note that, to anybody interested, that the topic is a little bit more broader than just a new messaging driver as it includes planning and/or working around the usage of eventlet etc, if you are interested in that topic please also reach out to us! Best regards Tobias > On 2 Sept 2022, at 10:35, Felix H?ttner wrote: > > +1, we would also be interested in helping out. Let me know where we can help out with reviews, writing code, testing, etc. > > -- > Felix Huettner > >> +1, I'm also interested in this topic. I did some tests with nats-py to see how it works and I'm volunteering to go further with this technology. >> Let me know if you need reviews, help etc... >> >> Le jeu. 1 sept. 2022 ? 15:50, Tobias Urdin a ?crit : >> Hello Kai, >> >> Great to hear that you're interested! >> I'm currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first). >> >> Best regards >> Tobias >> >>> On 30 Aug 2022, at 18:32, Kai Bojens wrote: >>> >>> Am 29.08.22 um 15:46 schrieb Tobias Urdin: >>> >>>> If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to >>>> reach out. I'm hoping somebody will bite but atleast I've put it out there for all of you. >>> >>> Hi, >>> I am very much interested to take a closer look at your work and maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack. >>> >>> As I'm pretty new to the messaging topic and had just heard of NATS and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ. >>> >>> This brings me to the most important question: Where do you run and test your code? >>> >>> Greetings, >>> Kai > > Diese E Mail enth?lt m?glicherweise vertrauliche Inhalte und ist nur f?r die Verwertung durch den vorgesehenen Empf?nger bestimmt. Sollten Sie nicht der vorgesehene Empf?nger sein, setzen Sie den Absender bitte unverz?glich in Kenntnis und l?schen diese E Mail. Hinweise zum Datenschutz finden Sie hier. From mnasiadka at gmail.com Mon Sep 5 07:57:13 2022 From: mnasiadka at gmail.com (=?utf-8?Q?Micha=C5=82_Nasiadka?=) Date: Mon, 5 Sep 2022 09:57:13 +0200 Subject: [adjutant][magnum][mistral][sahara][watcher][zaqar][tc] broken gate for deliverables In-Reply-To: References: Message-ID: Hi there, python-magnumclient getting fixed in https://review.opendev.org/c/openstack/python-magnumclient/+/844050 Thanks, Michal > On 5 Sep 2022, at 09:24, El?d Ill?s wrote: > > Hi, > > Now that we have passed Zed-3 milestone, Release team starts to check the health of deliverables via their gate healthiness. The 1st round of checks showed that the following deliverables seem to have blocked gates: > > python-adjutantclient [1] > python-magnumclient [2] > python-mistralclient [3] > python-saharaclient [4] > python-watcherclient [5] > python-zaqarclient [6] > > We are asking the teams to fix their gates and propose a release after it is fixed as soon as possible, otherwise these deliverables might not be part of the official Zed release. > > [1] https://review.opendev.org/c/openstack/python-adjutantclient/+/855763 > [2] https://review.opendev.org/c/openstack/python-magnumclient/+/855778 > [3] https://review.opendev.org/c/openstack/python-mistralclient/+/855781 > [4] https://review.opendev.org/c/openstack/python-zaqarclient/+/855796 > [5] https://review.opendev.org/c/openstack/python-watcherclient/+/855795 > [6] https://review.opendev.org/c/openstack/python-saharaclient/+/855787 > > Thanks, > > El?d Ill?s > irc: elodilles > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Mon Sep 5 10:48:32 2022 From: hberaud at redhat.com (Herve Beraud) Date: Mon, 5 Sep 2022 12:48:32 +0200 Subject: [all] [oslo.messaging] Interest in collaboration on a NATS driver In-Reply-To: <0E347D5A-967D-42E3-AC00-56034907053B@binero.com> References: <52AA12A0-AE67-4EF7-B924-DE1F2873B909@binero.com> <0E347D5A-967D-42E3-AC00-56034907053B@binero.com> Message-ID: Le lun. 5 sept. 2022 ? 10:00, Tobias Urdin a ?crit : > Thanks! It seems that we have some traction here to get started in a more > structured manner. > > I?m on PTO today but back tomorrow, what do people feel about scheduling a > recurring meeting about this topic? The weekly Oslo meeting could host the conversation through a dedicated topic. https://wiki.openstack.org/wiki/Meetings/Oslo You could modify the meeting agenda to add this topic. Daniel Bengtsson (damani) is our meeting facilitator. Do not hesitate to ping him to discuss the meeting management. > I still > need to read through the old spec and old implementation of NATS, and I am > a bit restricted on time currently but we > could brainstorm in that meeting and get us started on a new/updated the > other spec. > > Should also note that, to anybody interested, that the topic is a little > bit more broader than just a new messaging driver > as it includes planning and/or working around the usage of eventlet etc, > if you are interested in that topic please also > reach out to us! > > Best regards > Tobias > > > On 2 Sept 2022, at 10:35, Felix H?ttner > wrote: > > > > +1, we would also be interested in helping out. Let me know where we can > help out with reviews, writing code, testing, etc. > > > > -- > > Felix Huettner > > > >> +1, I'm also interested in this topic. I did some tests with nats-py to > see how it works and I'm volunteering to go further with this technology. > >> Let me know if you need reviews, help etc... > >> > >> Le jeu. 1 sept. 2022 ? 15:50, Tobias Urdin tobias.urdin at binero.com> a ?crit : > >> Hello Kai, > >> > >> Great to hear that you're interested! > >> I'm currently just testing this as a POC directly in devstack so there > is real-world testing (not should it yet I think, needs more development > first). > >> > >> Best regards > >> Tobias > >> > >>> On 30 Aug 2022, at 18:32, Kai Bojens wrote: > >>> > >>> Am 29.08.22 um 15:46 schrieb Tobias Urdin: > >>> > >>>> If anybody, or any company, out there would be interested in > collaborating in a project to bring this support and maintain it feel free > to > >>>> reach out. I'm hoping somebody will bite but atleast I've put it out > there for all of you. > >>> > >>> Hi, > >>> I am very much interested to take a closer look at your work and maybe > contribute to it. Although I'm working with OpenStack for my employer at > the moment, I'd do this in my spare time as I'm not sure that I can > convince him to add another staging system with a full OpenStack > installation just for developing a RabbitMQ replacement. That's not on our > agenda as we are mostly users and not developers of OpenStack. > >>> > >>> As I'm pretty new to the messaging topic and had just heard of NATS > and your idea, I'll first would have to dive into NATS and then I would > take a closer look at your code and maybe try to create some documentation > or tests. So, I can't promise anything but as I said I'm very interested in > your approach as I also see the massive load from RabbitMQ. > >>> > >>> This brings me to the most important question: Where do you run and > test your code? > >>> > >>> Greetings, > >>> Kai > > > > Diese E Mail enth?lt m?glicherweise vertrauliche Inhalte und ist nur f?r > die Verwertung durch den vorgesehenen Empf?nger bestimmt. Sollten Sie nicht > der vorgesehene Empf?nger sein, setzen Sie den Absender bitte unverz?glich > in Kenntnis und l?schen diese E Mail. Hinweise zum Datenschutz finden Sie > hier. > > -- Herv? Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkchn.in at gmail.com Mon Sep 5 11:59:00 2022 From: kkchn.in at gmail.com (KK CHN) Date: Mon, 5 Sep 2022 17:29:00 +0530 Subject: Kolla-ansible all-in-one and Hyper Converged solution In-Reply-To: <47c2db9b-222d-aa47-accc-fabc13a895f1@linaro.org> References: <47c2db9b-222d-aa47-accc-fabc13a895f1@linaro.org> Message-ID: As the server box is available with me, I have installed debian 11 on this box as suggested. So to go ahead with this machine to act as an HCI node, What all configs I have to make, when using the kolla-ansible all-in-one inventory file(Wallaby or any latest supported OOstack I can go ahead with this OS version). and additional configs required, what all need to be performed for an HCI solution? Any help or hints are highly appreciated. Thank you, On Mon, Sep 5, 2022 at 12:49 PM Marcin Juszkiewicz < marcin.juszkiewicz at linaro.org> wrote: > W dniu 5.09.2022 o 08:42, KK CHN pisze: > > > > [1 ] I am aiming for a prototype of HCI on a DELL ( R650 2 CPU and 40 > > cores . 2.4 TB) server machine. The Operating System choice is Debian > 10. > > > > [2] Right now I am successful in > > > > Kolla-ansible all-in-one installation of Wallaby/stable on a Debian > > 10 Virtual machine with the default configs enabled as in the > documentation > > Debian 10 'buster' is not supported in Wallaby. Upgrade to Debian 11 > 'bullseye' first. > > Victoria was the last release supporting Debian 10 and is not supported. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elod.illes at est.tech Mon Sep 5 14:19:30 2022 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Mon, 5 Sep 2022 16:19:30 +0200 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 Message-ID: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> Hi, With the latest oslo.db 12.1.0 release it seems multiple repositories are broken (see the corresponding requirements patch [1] for details, and probably there are more, that are not tested within requirements repository). The patch that introduces the break [2] "is necessary for oslo.db and openstack applications in general to be able to run on SQLAlchemy 2.0" according to patch author. Since we are after the 3rd milestone of Zed, we have very limited time to figure out what to do. The 2 options are: 1) fix every broken repository to work with oslo.db 12.1.0 ??? as far as we know this is quite impossible as for some repositories the already existing fixes took almost a cycle to be implemented and there are still undiscovered bugs around this. (we don't know if this is really true, or probably there are cases where it's easy to fix) 2) revert the breaking change [2] and do another release in oslo.db now without it (and add it back after Zed release & release oslo.db with it as soon as possible in Antelope cycle) ??? as far as we understand this does not cause any issue for those who already adapted to oslo.db 12.1.0, so this should not be painful Based on the above Release team is opting toward the 2nd option. Please let us know your opinion! [1] https://review.opendev.org/c/openstack/requirements/+/855153/ [2] https://review.opendev.org/c/openstack/oslo.db/+/804775 Thanks, El?d -------------- next part -------------- An HTML attachment was scrubbed... URL: From m73hdi at gmail.com Fri Sep 2 20:00:28 2022 From: m73hdi at gmail.com (mahdi n) Date: Sat, 3 Sep 2022 00:30:28 +0430 Subject: Error During installation devstack ModuleNotFoundError: No module named 'neutron' Message-ID: I was installing DevStack on Ubuntu 20.04 when I encountered this error It says that the Neutron module was not found while neutron is installed ++lib/neutron_plugins/ovn_agent:filter_network_api_extensions:439 > /usr/local/bin/python3.8 -c 'from neutron.common.ovn import extensions ;\ > > print(",".join(extensions.ML2_SUPPORTED_API_EXTENSIONS)) > ' > Traceback (most recent call last): > > File "", line 1, in > > ModuleNotFoundError: No module named 'neutron' > > +lib/neutron_plugins/ovn_agent:filter_network_api_extensions:439 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincet at iastate.edu Sun Sep 4 04:38:00 2022 From: vincet at iastate.edu (Lee, Vincent Z) Date: Sun, 4 Sep 2022 04:38:00 +0000 Subject: Container not appearing Message-ID: Hi all, I am facing issues with making containers to appear on my gui. I have managed to run a container, however, it is not showing it on horizon dashboard. [cid:3761763c-eed0-4912-af5f-4a4e91d7da1f] When I tried to create a container, it will be successfully [cid:067852ef-34b3-40c5-a590-757a192eb556] [cid:56d30ba1-c65b-4dfa-ab91-41e872332e29] Best, Vincent -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 530678 bytes Desc: image.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 304252 bytes Desc: image.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 431379 bytes Desc: image.png URL: From sbauza at redhat.com Mon Sep 5 15:20:16 2022 From: sbauza at redhat.com (Sylvain Bauza) Date: Mon, 5 Sep 2022 17:20:16 +0200 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 In-Reply-To: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> References: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> Message-ID: Le lun. 5 sept. 2022 ? 16:37, El?d Ill?s a ?crit : > Hi, > > With the latest oslo.db 12.1.0 release it seems multiple repositories are > broken (see the corresponding requirements patch [1] for details, and > probably there are more, that are not tested within requirements > repository). The patch that introduces the break [2] "is necessary for > oslo.db and openstack applications in general to be able to run on > SQLAlchemy 2.0" according to patch author. > > Since we are after the 3rd milestone of Zed, we have very limited time to > figure out what to do. The 2 options are: > > 1) fix every broken repository to work with oslo.db 12.1.0 > as far as we know this is quite impossible as for some repositories > the already existing fixes took almost a cycle to be implemented and there > are still undiscovered bugs around this. (we don't know if this is really > true, or probably there are cases where it's easy to fix) > > 2) revert the breaking change [2] and do another release in oslo.db now > without it (and add it back after Zed release & release oslo.db with it as > soon as possible in Antelope cycle) > as far as we understand this does not cause any issue for those who > already adapted to oslo.db 12.1.0, so this should not be painful > >From a personal point of view, I'm on board with option 2, which closes the race as soon as we revert and gives us more time to find the root cause and fix it correctly. >From a Nova/Placement PoV, they're not impacted, as we only raise warnings, so feel free to pick any other project to discuss about option 1. -Sylvain > Based on the above Release team is opting toward the 2nd option. > > Please let us know your opinion! > > [1] https://review.opendev.org/c/openstack/requirements/+/855153/ > [2] https://review.opendev.org/c/openstack/oslo.db/+/804775 > > Thanks, > > El?d > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjoen at dds.nl Mon Sep 5 16:03:42 2022 From: tjoen at dds.nl (tjoen) Date: Mon, 5 Sep 2022 18:03:42 +0200 Subject: Error During installation devstack ModuleNotFoundError: No module named 'neutron' In-Reply-To: References: Message-ID: <1837c641-e96e-58ca-8ba3-2f41ec62cd9b@dds.nl> On 9/2/22 22:00, mahdi n wrote: > I was installing DevStack on Ubuntu 20.04 when I encountered this error It > says that the Neutron module was not found while neutron is installed .. >> ModuleNotFoundError: No module named 'neutron' PYTHONHOME needed? From tsrini.alr at gmail.com Mon Sep 5 16:03:58 2022 From: tsrini.alr at gmail.com (Srinivasan T) Date: Mon, 5 Sep 2022 21:33:58 +0530 Subject: Secret getPayload() openstack4j Message-ID: Hi, I'm unable to get the secret's payload from openstack4j, it always returns null. Secret secret = os.barbican().secrets().get("19cbc4e8-cd06-450b-aa5d-2a4d20bf7d60"); secret.getPayload(); //Always returns null The same works when using the OpenStack CLI, openstack secret get --payload_content_type 'application/octet-stream' --file secret-payload http://x.x.x.x:9311/v1/secrets/19cbc4e8-cd06-450b-aa5d-2a4d20bf7d60 I'm using the below OpenStack4j version, Bundle-Name: OpenStack4j Core Bundle-Version: 3.6.0 OpenStack is in Queens version. Let me know if someone can help on this. Regards, Srini -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephenfin at redhat.com Mon Sep 5 16:14:27 2022 From: stephenfin at redhat.com (Stephen Finucane) Date: Mon, 05 Sep 2022 17:14:27 +0100 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 In-Reply-To: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> References: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> Message-ID: On Mon, 2022-09-05 at 16:19 +0200, El?d Ill?s wrote: > Hi, > With the latest oslo.db 12.1.0 release it seems multiple repositories are > broken (see the corresponding requirements patch [1] for details, and probably > there are more, that are not tested within requirements repository). The patch > that introduces the break [2] "is necessary for oslo.db and openstack > applications in general to be able to run on SQLAlchemy 2.0" according to > patch author. > Since we are after the 3rd milestone of Zed, we have very limited time to > figure out what to do. The 2 options are: > > 1) fix every broken repository to work with oslo.db 12.1.0 > ???? as far as we know this is quite impossible as for some repositories the > already existing fixes took almost a cycle to be implemented and there are > still undiscovered bugs around this. (we don't know if this is really true, or > probably there are cases where it's easy to fix) I don't think this is True. To fully prepare for SQLAlchemy 2.0 you would need to do this work, yes, however the issue here is that oslo.db no longer *defaults* to enabling one of the SQLAlchemy features that's being removed in 2.0, autocommit, and not that it no longer supports it. There's nothing to stop the affected projects from manually enabling autocommit behavior and to prove this I just put together a patch for aodh to do just that [1]. Manually enabling this feature would be my preferred approach since it means we're kicking a slightly smaller can down the road and we'll have a better understanding of the projects that still need to do work for SQLAlchemy 2.0, but I don't know how likely it is that we can land all of these in the next week. > 2) revert the breaking change [2] and do another release in oslo.db now > without it (and add it back after Zed release & release oslo.db with it as > soon as possible in Antelope cycle) > ???? as far as we understand this does not cause any issue for those who > already adapted to oslo.db 12.1.0, so this should not be painful This is all true, but it doesn't actually fix anything and delays the necessary work to get us moving in the right direction. I've been harping on about the fact that SQLAlchemy 2.0 is coming and will affect many projects for over a year now [2] so perhaps a small but firm nudge like this would be beneficial and get things rolling moving into Antelope? > Based on the above Release team is opting toward the 2nd option. > Please let us know your opinion! > [1] https://review.opendev.org/c/openstack/requirements/+/855153/ > ?[2] https://review.opendev.org/c/openstack/oslo.db/+/804775 > Thanks, > > ?El?d? Cheers, Stephen [1] https://review.opendev.org/c/openstack/aodh/+/855962 [2] https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.html From artem.goncharov at gmail.com Mon Sep 5 16:18:17 2022 From: artem.goncharov at gmail.com (Artem Goncharov) Date: Mon, 5 Sep 2022 18:18:17 +0200 Subject: Secret getPayload() openstack4j In-Reply-To: References: Message-ID: <6CFE66F8-BD28-41F4-91C8-5207954FD658@gmail.com> Hi, The library is not an official OpenStack delivery. I guess nobody here would be able to give you proper suggestion. Moreover it does not look like being actively maintained. Regards, Artem > On 5. Sep 2022, at 18:03, Srinivasan T wrote: > > Hi, > > I'm unable to get the secret's payload from openstack4j, it always returns null. > > Secret secret = os.barbican().secrets().get("19cbc4e8-cd06-450b-aa5d-2a4d20bf7d60"); > secret.getPayload(); //Always returns null > The same works when using the OpenStack CLI, > > openstack secret get --payload_content_type 'application/octet-stream' --file secret-payload http://x.x.x.x:9311/v1/secrets/19cbc4e8-cd06-450b-aa5d-2a4d20bf7d60 > I'm using the below OpenStack4j version, > > Bundle-Name: OpenStack4j Core > > Bundle-Version: 3.6.0 > > OpenStack is in Queens version. > > Let me know if someone can help on this. > > Regards, > Srini -------------- next part -------------- An HTML attachment was scrubbed... URL: From gibi at redhat.com Mon Sep 5 16:20:23 2022 From: gibi at redhat.com (Balazs Gibizer) Date: Mon, 05 Sep 2022 18:20:23 +0200 Subject: [oslo][relmgmt][taskflow][nova] fasteners.ReaderWriterLock and oslo.concurrency's fair lock is broken if used in eventlet Message-ID: Hi, It is hard to properly figure out which OpenStack project is affected exactly. But I want to give a heads up. If the following is true for your project then you are affected: * using eventlet and * using oslo.concurrency fair internal lock (external lock or non fair locks are not affected) or using fasteners.ReaderWriterLock directly. I know that nova is affected and based on code search taskflow is affected at least. The oslo.concurrency's fair lock uses fasteners.ReaderWriterLock[1]. The fasteners.ReaderWriterLock relies on threading.current_thread to identify a thread and decide if a thread already has a lock and therefore can reenter the lock. However in an eventlet monkey patched environment, a thread that is created with eventlet.spawn_n() or the patched threading.Thread() the threading.current_thread call does not return an eventlet unique ID. This causes that the lock can be reentered from multiple eventlets at the same time. We have 4 ways forward: 0) Fix eventlet. There is an open issue in eventlet[3] for this open since October 2021. Based on the ticket this direction does not seems to feasible. 1) Sean recently opened an issue[4] on fasteners to restore a previously existing workaround that could fix our issues. If an new fasteners lib is released with the workaround[5] then at least oslo.concurrency requirements needs to be bumped and a new oslo release is pushed. 2) If the fasteners' maintainer does not accept [4][5] in time then I have an oslo.concurrency patch[6] that implements a workaround in oslo. This also requires a new olso.concurrency release. Also this means that projects that are using fasteners.ReaderWriterLock directly need to re-implement the fix locally. 3) If all odds fails I have a nova only patch[7] that implements the workaround locally in nova. Note that this issue is present in stable/yoga and on master. On stable/xena we uses fasteners < 0.15.0 which is not affected. Cheers, gibi [1] https://github.com/openstack/oslo.concurrency/blob/052b2f23572900601b0f41387dbbb07153d88982/oslo_concurrency/lockutils.py#L287-L288 [2] https://bugs.launchpad.net/oslo.concurrency/+bug/1988311 [3] https://github.com/eventlet/eventlet/issues/731 [4] https://github.com/harlowja/fasteners/issues/96 [5] https://github.com/harlowja/fasteners/pull/97 [6] https://review.opendev.org/q/topic:bug/1988311+project:openstack/oslo.concurrency [7] https://review.opendev.org/q/topic:bug/1988311+project:openstack/nova From thierry at openstack.org Mon Sep 5 17:00:40 2022 From: thierry at openstack.org (Thierry Carrez) Date: Mon, 5 Sep 2022 19:00:40 +0200 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 In-Reply-To: References: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> Message-ID: Stephen Finucane wrote: > On Mon, 2022-09-05 at 16:19 +0200, El?d Ill?s wrote: >> [...] The 2 options are: >> >> 1) fix every broken repository to work with oslo.db 12.1.0 >> ???? as far as we know this is quite impossible as for some repositories the >> already existing fixes took almost a cycle to be implemented and there are >> still undiscovered bugs around this. (we don't know if this is really true, or >> probably there are cases where it's easy to fix) > > I don't think this is True. To fully prepare for SQLAlchemy 2.0 you would need > to do this work, yes, however the issue here is that oslo.db no longer > *defaults* to enabling one of the SQLAlchemy features that's being removed in > 2.0, autocommit, and not that it no longer supports it. There's nothing to stop > the affected projects from manually enabling autocommit behavior and to prove > this I just put together a patch for aodh to do just that [1]. Manually enabling > this feature would be my preferred approach since it means we're kicking a > slightly smaller can down the road and we'll have a better understanding of the > projects that still need to do work for SQLAlchemy 2.0, but I don't know how > likely it is that we can land all of these in the next week. I agree this is the preferable option... and if we had a couple extra weeks to make it happen I would pick it without hesitation... Here I feel to make it happen in time for the Zed release we'll need to get someone to post all the autocommit option patches and potentially the TC stepping in to authorize the TaCT team to force-approve the ones that would not get attention from their core teams in time. >> 2) revert the breaking change [2] and do another release in oslo.db now >> without it (and add it back after Zed release & release oslo.db with it as >> soon as possible in Antelope cycle) >> ???? as far as we understand this does not cause any issue for those who >> already adapted to oslo.db 12.1.0, so this should not be painful > > This is all true, but it doesn't actually fix anything and delays the necessary > work to get us moving in the right direction. I've been harping on about the > fact that SQLAlchemy 2.0 is coming and will affect many projects for over a year > now [2] so perhaps a small but firm nudge like this would be beneficial and get > things rolling moving into Antelope? I agree it's a step back without guarantee that things would go a lot better in the Antelope redo... but it is a more controlled path. I'd say we should see if we can get critical attention on this in the next couple of days, and if not we can use option (2) as a plan B ? -- Thierry Carrez (ttx) From fungi at yuggoth.org Mon Sep 5 17:36:36 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 5 Sep 2022 17:36:36 +0000 Subject: [all][election][tc] TC election at risk of single-employer majority Message-ID: <20220905173635.xutovyid3lpudmkq@yuggoth.org> The extended nomination period for the upcoming TC election closes in just over two days. We need to elect people to fill 4 of the 9 seats on the TC during this round. We currently have just enough candidates to fill the open seats, but in so doing we would end up with a majority of the TC members employed by the same company. Appendix 4 of the bylaws of the Open Infrastructure Foundation, the Technical Committee Member Policy[*], states: > In the event of a Technical Committee election that would result > in half or more of the members of the Technical Committee being > Affiliated, the Board of Directors may defer the effective date of > office of the newly elected Technical Committee members who are > Affiliated for a period not to exceed thirty (30) days after a > resolution by the Board of Directors approving such deferral. The > Board of Directors must pass such resolution within thirty (30) > days of the notice of election results from the Technical > Committee. During such period of deferral, the Technical Committee > and the Board of Directors shall work to resolve the issue by > agreement among themselves, such as by a resignation of one or > more Technical Committee members or having the Individual Member > with the next highest number of votes become a member of the > Technical Committee. If the Technical Committee and the Board of > Directors are not able to agree on a resolution within such thirty > (30) day period, the Board of Directors may require another > election for such positions. In order to avoid this outcome, we need additional nominees with a variety of affiliations immediately. If you've considered running for a seat on the OpenStack TC before, now is definitely the time. Please see earlier announcements[**] from the election officials for details on how to submit your nomination. Thanks! [*] https://openinfra.dev/legal/openstack-technical-committee-member-policy [**] https://lists.openstack.org/pipermail/openstack-discuss/2022-August/030094.html https://lists.openstack.org/pipermail/openstack-discuss/2022-August/030241.html -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From arnaud.morin at gmail.com Mon Sep 5 18:04:15 2022 From: arnaud.morin at gmail.com (Arnaud Morin) Date: Mon, 5 Sep 2022 18:04:15 +0000 Subject: [ops][largescale-sig] rabbitmq and the durability of reply_ queues In-Reply-To: References: Message-ID: Hello, Thank you for bringing that up. I was thinking (but it seems I was wrong) that the fanout/reply queues were used for a one shot message/reply. Besides that, I am also wondering how much cpu power we will need to replicate such queues? I guess I can can do the math from what we are currently running in production :) Have you tried on a big cluster on your side? Cheers, Arnaud On 02.09.22 - 08:19, Felix H?ttner wrote: > Hi everyone, > > the largescale-sig currently recommends the following rabbitmq policy [1]: '^(?!(amq\.)|(.*_fanout_)|(reply_)).*'. > > If I found the history of this setting correctly, it resulted from this mailinglist thread [2] which came to the conclusion: > > > * use durable-queue and replication for long-running queues/exchanges > > * use non-durable-queue without replication for short (fanout, reply_) queues > > However I am unsure if reply_ queues are actually shorted lived than the "long-running" ones. > If we take the example of the cinder-scheduler we have the following queues: > > * cinder-scheduler: Tied to the lifetime of the whole cinder-scheduler cluster; currently durable + replicated > * cinder-scheduler.myhostname: Tied to the lifetime of the cinder-scheduler service, but not removed when the service stops; currently durable + replicated > * cinder-scheduler_fanout_somerandomid: Tied to the lifetime of the cinder-scheduler service, but removed when the service stops; currently neither durable nor replicated > * reply_somerandomid: Tied to the lifetime of the cinder-scheduler service, but removed when the service stops; currently neither durable nor replicated > > If I read got all of the above correctly then reply_ and fanout queues are actually not shorter lived than the normal queue to send requests to that service. > The only difference is that we remove them when the service itself stops. > > Therefor I want to propose the question if we should not also make these queues durable and replicated. > > Thank you > > [1]: https://docs.openstack.org/large-scale/other/rabbitmq.html#pattern > [2]: https://lists.openstack.org/pipermail/openstack-discuss/2020-August/016562.html > > -- > Felix Huettner > > Diese E Mail enth?lt m?glicherweise vertrauliche Inhalte und ist nur f?r die Verwertung durch den vorgesehenen Empf?nger bestimmt. Sollten Sie nicht der vorgesehene Empf?nger sein, setzen Sie den Absender bitte unverz?glich in Kenntnis und l?schen diese E Mail. Hinweise zum Datenschutz finden Sie hier. > From katonalala at gmail.com Mon Sep 5 19:21:49 2022 From: katonalala at gmail.com (Lajos Katona) Date: Mon, 5 Sep 2022 21:21:49 +0200 Subject: Error During installation devstack ModuleNotFoundError: No module named 'neutron' In-Reply-To: References: Message-ID: Hi, By the traceback you are quite close to master. The issue you see is really strange. I would try to debug it manually, like starting a python shell and doing the same import and playing with the pythonhome for example as it was suggested. I usually use Ubuntu20 for my test envs and never seen such issue with devstack. Regards Lajos mahdi n ezt ?rta (id?pont: 2022. szept. 5., H, 17:32): > I was installing DevStack on Ubuntu 20.04 when I encountered this error It > says that the Neutron module was not found while neutron is installed > > > ++lib/neutron_plugins/ovn_agent:filter_network_api_extensions:439 >> /usr/local/bin/python3.8 -c 'from neutron.common.ovn import extensions ;\ >> >> print(",".join(extensions.ML2_SUPPORTED_API_EXTENSIONS)) >> ' >> Traceback (most recent call last): >> >> File "", line 1, in >> >> ModuleNotFoundError: No module named 'neutron' >> >> +lib/neutron_plugins/ovn_agent:filter_network_api_extensions:439 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From katonalala at gmail.com Mon Sep 5 19:29:44 2022 From: katonalala at gmail.com (Lajos Katona) Date: Mon, 5 Sep 2022 21:29:44 +0200 Subject: [neutron] Team meeting on Sept. 6 cancelled Message-ID: Hi, Sorry for late mail, but tomorrow I can't drive the team meeting, so I have to cancel it. I will be otherwise available tomorrow (except around the meeting time), so you can reach me on neutron channel for example. Lajos Katona (lajoskatona) -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy at demarco.com Mon Sep 5 19:35:00 2022 From: amy at demarco.com (Amy Marrich) Date: Mon, 5 Sep 2022 14:35:00 -0500 Subject: [all][elections][ptl][tc] Combined PTL/TC antelope cycle Election Nominations Last Days - FINAL REMINDER Message-ID: This is your last reminder for the election, I know the US , CA, and a few other countries are on holiday today. Please also read Jeremy's early email about the TC seats and governance. Thank, Amy\ ----------------------------------------------- A quick reminder that we are in the last hours for declaring PTL and TC candidacies. Nominations are open until Sep 07, 2022 23:45 UTC. If you want to stand for election, don't delay, follow the instructions at [1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. Election statistics[2]: Nominations started @ 2022-08-24 23:45:00 UTC Nominations end @ 2022-09-07 23:45:00 UTC Nominations duration : 14 days, 0:00:00 Nominations remaining : 2 days, 4:16:33 Nominations progress : 84.44% --------------------------------------------------- Projects[1] : 52 Projects with candidates : 35 ( 67.31%) Projects with election : 0 ( 0.00%) --------------------------------------------------- Need election : 0 () Need appointment : 17 (Adjutant Barbican Keystone Masakari Mistral OpenStackSDK OpenStack_Charms Openstack_Chef Oslo Release_Management Requirements Sahara Senlin Skyline Swift Venus Zun) =================================================== Stats gathered @ 2022-09-05 19:28:27 UTC This means that with approximately 2 days left, 17 projects will be deemed leaderless. In this case the TC will oversee PTL selection as described by [3]. Thank you, [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] Any open reviews at https://review.openstack.org/#/q/is:open+project:openstack/election have not been factored into these stats. [3] https://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From mthode at mthode.org Mon Sep 5 21:21:43 2022 From: mthode at mthode.org (Matthew Thode) Date: Mon, 5 Sep 2022 16:21:43 -0500 Subject: [election][Requirements] PTL candidacy Message-ID: <20220905212143.ennkg62brej4ork2@mthode.org> I would like to announce my candidacy for PTL of the Requirements project. The project was recently updated to allow multiple PTLs this cycle and I imagine tony will be my better half. The following will be my goals for the cycle, in order of importance: 1. The primary goal is to keep a tight rein on global-requirements and upper-constraints updates. (Keep things working well) 2. Un-cap requirements where possible. 3. Fix some automation of generate contstraints (pkg-resources being added and setuptools being dropped) 4. Audit global-requirements and upper-constraints for redundancies. One of the rules we have for new entrants to global-requirements and/or upper-constraints is that they be non-redundant. Keeping that rule in mind, audit the list of requirements for possible redundancies and if possible, reduce the number of requirements we manage. 5. introduce better python version range support into constraints. An image with all the python versions we want is likely needed. I look forward to continue working with you in this cycle, as your PTL or not. Thanks for your time, -- Matthew Thode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ces.eduardo98 at gmail.com Mon Sep 5 21:21:42 2022 From: ces.eduardo98 at gmail.com (Carlos Silva) Date: Mon, 5 Sep 2022 18:21:42 -0300 Subject: [manila] LVM shares are unmounted on reboot In-Reply-To: References: Message-ID: Hello! I believe there is not an automated way to do this using Manila itself, or a config thing you could set, considering that the controller will have no visibility over all mounts consuming the volume. So the consumers will need to re-mount, and even if scripted or automated, it should be triggered on each client consuming the share, which is painful. There might be more users that faced this issue in the past and could have a way to work it around, so getting some more input from other people would be appreciated. Regards, carloss Em ter., 30 de ago. de 2022 ?s 02:01, Vaibhav escreveu: > Dear All, > > One of the host running Manila-share service has rebooted. > After the reboot the LVMs are not mounted on the Manila mount points. > > I use LVM Driver with DHSS=False. > > default_share_type = default_share_type > share_name_template = manila-%s > rootwrap_config = /etc/manila/rootwrap.conf > api_paste_config = /etc/manila/api-paste.ini > > auth_strategy = keystone > my_ip=192.168.82.2 > enabled_share_backends = lvm > enabled_share_protocols = NFS > state_path=/var/lib/manila > > [lvm] > share_backend_name = LVM > share_driver = manila.share.drivers.lvm.LVMShareDriver > driver_handles_share_servers = False > lvm_share_volume_group = VGZunManila > lvm_share_export_ips = 192.168.82.2 > lvm_share_export_root = $state_path/mnt > > After the reboot LVMs are there but they are mounted on their respective > share location. > > Any way to solve this and this to be done automatically? > > Regards, > Vaibhav > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Mon Sep 5 21:33:55 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 5 Sep 2022 21:33:55 +0000 Subject: [election][Requirements] PTL candidacy In-Reply-To: <20220905212143.ennkg62brej4ork2@mthode.org> References: <20220905212143.ennkg62brej4ork2@mthode.org> Message-ID: <20220905213355.doauyoh5v2itn657@yuggoth.org> On 2022-09-05 16:21:43 -0500 (-0500), Matthew Thode wrote: [...] > The project was recently updated to allow multiple PTLs this > cycle and I imagine tony will be my better half. [...] Just to be clear, the Requirements project team is now under a distributed project leadership, so there are technically no elected PTLs for it. Instead, the project is led by role-specific liaisons chosen through team consensus, as listed here: https://governance.openstack.org/tc/reference/projects/requirements.html But also, thanks for taking care of requirements! -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From ces.eduardo98 at gmail.com Mon Sep 5 22:34:22 2022 From: ces.eduardo98 at gmail.com (Carlos Silva) Date: Mon, 5 Sep 2022 19:34:22 -0300 Subject: [manila] LVM shares are unmounted on reboot In-Reply-To: References: Message-ID: There is a chance that I have misinterpreted the email. > After the reboot LVMs are there but they are mounted on their respective share location. They are or they are not? What I am getting now is: you rebooted the system and the Manila export locations are not matching the share location anymore. Is this correct? If so, Manila should be taking care of this. When the driver starts up, it runs a routine to fetch all shares and ensure the export location for all of them. Em seg., 5 de set. de 2022 ?s 18:21, Carlos Silva escreveu: > Hello! > > I believe there is not an automated way to do this using Manila itself, or > a config thing you could set, > considering that the controller will have no visibility over all mounts > consuming the volume. > > So the consumers will need to re-mount, and even if scripted or automated, > it should be > triggered on each client consuming the share, which is painful. There > might be more users that > faced this issue in the past and could have a way to work it around, so > getting some more input > from other people would be appreciated. > > Regards, > carloss > > Em ter., 30 de ago. de 2022 ?s 02:01, Vaibhav > escreveu: > >> Dear All, >> >> One of the host running Manila-share service has rebooted. >> After the reboot the LVMs are not mounted on the Manila mount points. >> >> I use LVM Driver with DHSS=False. >> >> default_share_type = default_share_type >> share_name_template = manila-%s >> rootwrap_config = /etc/manila/rootwrap.conf >> api_paste_config = /etc/manila/api-paste.ini >> >> auth_strategy = keystone >> my_ip=192.168.82.2 >> enabled_share_backends = lvm >> enabled_share_protocols = NFS >> state_path=/var/lib/manila >> >> [lvm] >> share_backend_name = LVM >> share_driver = manila.share.drivers.lvm.LVMShareDriver >> driver_handles_share_servers = False >> lvm_share_volume_group = VGZunManila >> lvm_share_export_ips = 192.168.82.2 >> lvm_share_export_root = $state_path/mnt >> >> After the reboot LVMs are there but they are mounted on their respective >> share location. >> >> Any way to solve this and this to be done automatically? >> >> Regards, >> Vaibhav >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mthode at mthode.org Mon Sep 5 22:39:48 2022 From: mthode at mthode.org (Matthew Thode) Date: Mon, 5 Sep 2022 17:39:48 -0500 Subject: [election][Requirements] PTL candidacy In-Reply-To: <20220905213355.doauyoh5v2itn657@yuggoth.org> References: <20220905212143.ennkg62brej4ork2@mthode.org> <20220905213355.doauyoh5v2itn657@yuggoth.org> Message-ID: <20220905223948.747dah7efj4osov3@mthode.org> On 22-09-05 21:33:55, Jeremy Stanley wrote: > On 2022-09-05 16:21:43 -0500 (-0500), Matthew Thode wrote: > [...] > > The project was recently updated to allow multiple PTLs this > > cycle and I imagine tony will be my better half. > [...] > > Just to be clear, the Requirements project team is now under a > distributed project leadership, so there are technically no elected > PTLs for it. Instead, the project is led by role-specific liaisons > chosen through team consensus, as listed here: > > https://governance.openstack.org/tc/reference/projects/requirements.html > > But also, thanks for taking care of requirements! > -- > Jeremy Stanley yep :D I'm only sending this because of the email earlier saying that ptls would be appointed. we are probably on that list because we changed the leadership to distributed very recently. (after nominations started I think). -- Matthew Thode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tim.kahlke at audiotax.is Mon Sep 5 23:39:38 2022 From: tim.kahlke at audiotax.is (Tim Kahlke) Date: Tue, 06 Sep 2022 09:39:38 +1000 Subject: Microstack - VM networking & installation probs Message-ID: Hi, I tried to install microstack 245 via Canonical and am running into the ?old? VM-can?t-connect-external-network problem. OS: Ubuntu 20.04 Microstack v245 Install seems to have worked ok using sudo snap install microstack --beta. However, journalctl -xe shows ovsdb-server[83528]: ovs|26322|socket_util|ERR|6642:0.0.0.0: bind: Address already in use But not sure if that?s related or not. Network setup is the default, i.e., external 10.20.20.0/24 and internal 192.168.1.0/24. From the host machine I can ping the VMs and vice versa, but I can?t get past the host from the VM. I tried to apply some of the solutions I found on the web, so far without success. This one seems to work for people but my microstack doesn?t seem to have the ovs-vsctl command anywhere. Any suggestions would be much appreciated. Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Mon Sep 5 23:58:19 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 5 Sep 2022 23:58:19 +0000 Subject: Microstack - VM networking & installation probs In-Reply-To: References: Message-ID: <20220905235818.i3q3tld4oxyzsjvx@yuggoth.org> On 2022-09-06 09:39:38 +1000 (+1000), Tim Kahlke wrote: > I tried to install microstack [...] Not to be dismissive, but this is the first time I've heard of "microstack" and it seems to be an installer developed outside of OpenStack itself. Their website indicates you can file bug reports on Launchpad here: https://bugs.launchpad.net/microstack/+filebug And their community also maintains a Discourse server here for help and general discussion: https://discourse.charmhub.io/search?q=microstack Hope that helps! -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From lists at optimcloud.com Tue Sep 6 00:02:14 2022 From: lists at optimcloud.com (Embedded Devel) Date: Tue, 06 Sep 2022 00:02:14 +0000 Subject: Kolla-ansible all-in-one and Hyper Converged solution In-Reply-To: References: Message-ID: <1662422509227.3627119861.181687323@optimcloud.com> Just install StarlingX and be done. On Monday 05 September 2022 13:42:40 PM (+07:00), KK CHN wrote: Hi, [1 ] I am aiming for a prototype of HCI on a DELL ( R650 2 CPU and 40 cores . 2.4 TB) server machine. The Operating System choice is Debian 10. [2] Right now I am successful in Kolla-ansible all-in-one installation of Wallaby/stable on a Debian 10 Virtual machine with the default configs enabled as in the documentation " https://docs.openstack.org/project-deploy-guide/kolla-ansible/wallaby/uickstart.html " in Virtualenv setup. Able to get the horizon dashboard with the default services enabled and created and tested the cirros VM launching .. working fine. [3 ] I have to repeat the same all-in-one deployment on the physical machine as in [1] with the default configs and then convert it as an HCI node. What all features do I need to configure / enable in all-in-on / globals.yml to convert this box as a working HCI node ? Any hints / directives for the essential configurations needed for this server box to convert it as an HCI node are most welcome. kindly shed some light on this and any reference documents/URLs to do this ? Thank you, Krish -- Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregory.orange at pawsey.org.au Tue Sep 6 00:31:40 2022 From: gregory.orange at pawsey.org.au (Gregory Orange) Date: Tue, 6 Sep 2022 08:31:40 +0800 Subject: Kolla-ansible all-in-one and Hyper Converged solution In-Reply-To: <1662422509227.3627119861.181687323@optimcloud.com> References: <1662422509227.3627119861.181687323@optimcloud.com> Message-ID: <7c124915-809c-2bae-734c-0e5ec4c77270@pawsey.org.au> On 6/9/22 08:02, Embedded Devel wrote: > Just install StarlingX and be done. Wow, this was a perfect time for me to read this, and go exploring. Just one more reason to use libre open source community software - corporate lockins would tend not to recommend 'competitors' before a lot of effort to maintain their own solution. If https://blogs.windriver.com/wind_river_blog/2018/10/introducing-starlingx/ has some grains of truth and it has some project maturity, then StarlingX looks very interesting for a range of purposes. From fungi at yuggoth.org Tue Sep 6 00:56:19 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 6 Sep 2022 00:56:19 +0000 Subject: Kolla-ansible all-in-one and Hyper Converged solution In-Reply-To: <7c124915-809c-2bae-734c-0e5ec4c77270@pawsey.org.au> References: <1662422509227.3627119861.181687323@optimcloud.com> <7c124915-809c-2bae-734c-0e5ec4c77270@pawsey.org.au> Message-ID: <20220906005618.wsk56p2o2bhlf3al@yuggoth.org> On 2022-09-06 08:31:40 +0800 (+0800), Gregory Orange wrote: [...] > Wow, this was a perfect time for me to read this, and go > exploring. Just one more reason to use libre open source community > software - corporate lockins would tend not to recommend > 'competitors' before a lot of effort to maintain their own > solution. [...] StarlingX and OpenStack are hardly competitors. StarlingX is an edge-focused GNU/Linux distribution which provides an opinionated installation of OpenStack (as well as plenty of other related software). Both are represented by the same nonprofit foundation: https://openinfra.dev/projects/ -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From tony at bakeyournoodle.com Tue Sep 6 01:26:10 2022 From: tony at bakeyournoodle.com (Tony Breeds) Date: Tue, 6 Sep 2022 11:26:10 +1000 Subject: [election][Requirements] PTL candidacy In-Reply-To: <20220905223948.747dah7efj4osov3@mthode.org> References: <20220905212143.ennkg62brej4ork2@mthode.org> <20220905213355.doauyoh5v2itn657@yuggoth.org> <20220905223948.747dah7efj4osov3@mthode.org> Message-ID: Yeah we need to update the election code to handle teams that are under distributed leadership. Something for the next cycle. On Tue, 6 Sept 2022 at 08:48, Matthew Thode wrote: > > On 22-09-05 21:33:55, Jeremy Stanley wrote: > > On 2022-09-05 16:21:43 -0500 (-0500), Matthew Thode wrote: > > [...] > > > The project was recently updated to allow multiple PTLs this > > > cycle and I imagine tony will be my better half. > > [...] > > > > Just to be clear, the Requirements project team is now under a > > distributed project leadership, so there are technically no elected > > PTLs for it. Instead, the project is led by role-specific liaisons > > chosen through team consensus, as listed here: > > > > https://governance.openstack.org/tc/reference/projects/requirements.html > > > > But also, thanks for taking care of requirements! > > -- > > Jeremy Stanley > > yep :D > > I'm only sending this because of the email earlier saying that ptls > would be appointed. we are probably on that list because we changed the > leadership to distributed very recently. (after nominations started I > think). > > -- > Matthew Thode -- Yours Tony. From tsrini.alr at gmail.com Tue Sep 6 04:31:45 2022 From: tsrini.alr at gmail.com (Srinivasan T) Date: Tue, 6 Sep 2022 10:01:45 +0530 Subject: Secret getPayload() openstack4j In-Reply-To: References: <6CFE66F8-BD28-41F4-91C8-5207954FD658@gmail.com> Message-ID: Hi, Does anyone have any idea on this? >From the REST API documentation, it seems GET /v1/secret/{uuid} may not fetch the payload and we need to use a different endpoint GET /v1/secret/{uuid}/payload . Is there any equivalent Java API (openstack4j) for this? Regards, Srini On Mon, Sep 5, 2022 at 11:08 PM Srinivasan T wrote: > Thanks Artem for the response. > > I face the same issue when using the below version as well (snippet from > pom.xml), > > 4.0.0 > openstack4j-core > OpenStack4j Core > OpenStack Java API > http://github.com/openstack4j/openstack4j/ > > Regards, > Srini > > On Mon, Sep 5, 2022 at 9:48 PM Artem Goncharov > wrote: > >> Hi, >> >> The library is not an official OpenStack delivery. I guess nobody here >> would be able to give you proper suggestion. Moreover it does not look like >> being actively maintained. >> >> Regards, >> Artem >> >> On 5. Sep 2022, at 18:03, Srinivasan T wrote: >> >> Hi, >> >> I'm unable to get the secret's payload from openstack4j, it always >> returns null. >> >> Secret secret = os.barbican().secrets().get("19cbc4e8-cd06-450b-aa5d-2a4d20bf7d60"); >> secret.getPayload(); //Always returns null >> >> The same works when using the OpenStack CLI, >> >> openstack secret get --payload_content_type 'application/octet-stream' --file secret-payload http://x.x.x.x:9311/v1/secrets/19cbc4e8-cd06-450b-aa5d-2a4d20bf7d60 >> >> I'm using the below OpenStack4j version, >> >> Bundle-Name: OpenStack4j Core >> >> Bundle-Version: 3.6.0 >> >> OpenStack is in Queens version. >> >> Let me know if someone can help on this. >> Regards, >> Srini >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkajinam at redhat.com Tue Sep 6 07:06:54 2022 From: tkajinam at redhat.com (Takashi Kajinami) Date: Tue, 6 Sep 2022 16:06:54 +0900 Subject: [puppet] Gate blocker: enabling neutron-ovn-metadata-agent consistently fails in CentOS Stream 9 In-Reply-To: References: Message-ID: Hello, We found that the issue is caused by the problematic Alias line in the systemd service file. We fixed the service file and I confirmed now integration jobs are passing. In case you still face the same problem then please let me know. Thank you, Takashi On Sat, Sep 3, 2022 at 11:13 PM Takashi Kajinami wrote: > Hello, > > > Currently we are facing a problem with integration jobs with ml2+ovn in > CentOS Stream 9 > ( puppet-openstack-integration-7-scenario00[35]-tempest-centos-9-stream ) > and > these jobs are consistently failing. > > Details can be found in https://launchpad.net/bugs/1988552 . > > I've already reported the issue to RDO and CentOS Stream to get their help > while > I'm also implementing a temporary workaround. > > https://review.opendev.org/c/openstack/puppet-openstack-integration/+/855617 > > Please avoid rechecking/approving patches until these jobs are fixed. > > Thank you, > Takashi > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Tue Sep 6 07:20:48 2022 From: skaplons at redhat.com (Slawek Kaplonski) Date: Tue, 06 Sep 2022 09:20:48 +0200 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 In-Reply-To: References: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> Message-ID: <2015881.Su3ONiSAvn@p1> Hi, Dnia poniedzia?ek, 5 wrze?nia 2022 18:14:27 CEST Stephen Finucane pisze: > On Mon, 2022-09-05 at 16:19 +0200, El?d Ill?s wrote: > > Hi, > > With the latest oslo.db 12.1.0 release it seems multiple repositories are > > broken (see the corresponding requirements patch [1] for details, and probably > > there are more, that are not tested within requirements repository). The patch > > that introduces the break [2] "is necessary for oslo.db and openstack > > applications in general to be able to run on SQLAlchemy 2.0" according to > > patch author. > > Since we are after the 3rd milestone of Zed, we have very limited time to > > figure out what to do. The 2 options are: > > > > 1) fix every broken repository to work with oslo.db 12.1.0 > > as far as we know this is quite impossible as for some repositories the > > already existing fixes took almost a cycle to be implemented and there are > > still undiscovered bugs around this. (we don't know if this is really true, or > > probably there are cases where it's easy to fix) > > I don't think this is True. To fully prepare for SQLAlchemy 2.0 you would need > to do this work, yes, however the issue here is that oslo.db no longer > *defaults* to enabling one of the SQLAlchemy features that's being removed in > 2.0, autocommit, and not that it no longer supports it. There's nothing to stop > the affected projects from manually enabling autocommit behavior and to prove > this I just put together a patch for aodh to do just that [1]. Manually enabling > this feature would be my preferred approach since it means we're kicking a > slightly smaller can down the road and we'll have a better understanding of the > projects that still need to do work for SQLAlchemy 2.0, but I don't know how > likely it is that we can land all of these in the next week. > > > 2) revert the breaking change [2] and do another release in oslo.db now > > without it (and add it back after Zed release & release oslo.db with it as > > soon as possible in Antelope cycle) > > as far as we understand this does not cause any issue for those who > > already adapted to oslo.db 12.1.0, so this should not be painful > > This is all true, but it doesn't actually fix anything and delays the necessary > work to get us moving in the right direction. I've been harping on about the > fact that SQLAlchemy 2.0 is coming and will affect many projects for over a year > now [2] so perhaps a small but firm nudge like this would be beneficial and get > things rolling moving into Antelope? I would vote for reverting it now as we are close to the Zed release deadline and then reverting this revert very early in the Antelope cycle to give projects chance to adopt to the change or enable autocommit feature on their own and start slower adoption later. > > > Based on the above Release team is opting toward the 2nd option. > > Please let us know your opinion! > > [1] https://review.opendev.org/c/openstack/requirements/+/855153/ > > [2] https://review.opendev.org/c/openstack/oslo.db/+/804775 > > Thanks, > > > > El?d > > Cheers, > Stephen > > [1] https://review.opendev.org/c/openstack/aodh/+/855962 > [2] https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.html > > > -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From hberaud at redhat.com Tue Sep 6 07:41:38 2022 From: hberaud at redhat.com (Herve Beraud) Date: Tue, 6 Sep 2022 09:41:38 +0200 Subject: [oslo][relmgmt][taskflow][nova] fasteners.ReaderWriterLock and oslo.concurrency's fair lock is broken if used in eventlet In-Reply-To: References: Message-ID: The oslo patches have been approved, I'll propose a new release, in a couple of hours, when they will be merged. Le lun. 5 sept. 2022 ? 18:27, Balazs Gibizer a ?crit : > Hi, > > It is hard to properly figure out which OpenStack project is affected > exactly. But I want to give a heads up. If the following is true for > your project then you are affected: > * using eventlet and > * using oslo.concurrency fair internal lock (external lock or non fair > locks are not affected) or using fasteners.ReaderWriterLock directly. > > I know that nova is affected and based on code search taskflow is > affected at least. > > The oslo.concurrency's fair lock uses fasteners.ReaderWriterLock[1]. > The fasteners.ReaderWriterLock relies on threading.current_thread to > identify a thread and decide if a thread already has a lock and > therefore can reenter the lock. However in an eventlet monkey patched > environment, a thread that is created with eventlet.spawn_n() or the > patched threading.Thread() the threading.current_thread call does not > return an eventlet unique ID. This causes that the lock can be > reentered from multiple eventlets at the same time. > > We have 4 ways forward: > > 0) Fix eventlet. There is an open issue in eventlet[3] for this open > since October 2021. Based on the ticket this direction does not seems > to feasible. > > 1) Sean recently opened an issue[4] on fasteners to restore a > previously existing workaround that could fix our issues. If an new > fasteners lib is released with the workaround[5] then at least > oslo.concurrency requirements needs to be bumped and a new oslo release > is pushed. > > 2) If the fasteners' maintainer does not accept [4][5] in time then I > have an oslo.concurrency patch[6] that implements a workaround in oslo. > This also requires a new olso.concurrency release. Also this means that > projects that are using fasteners.ReaderWriterLock directly need to > re-implement the fix locally. > > 3) If all odds fails I have a nova only patch[7] that implements the > workaround locally in nova. > > > Note that this issue is present in stable/yoga and on master. On > stable/xena we uses fasteners < 0.15.0 which is not affected. > > Cheers, > gibi > > [1] > > https://github.com/openstack/oslo.concurrency/blob/052b2f23572900601b0f41387dbbb07153d88982/oslo_concurrency/lockutils.py#L287-L288 > [2] https://bugs.launchpad.net/oslo.concurrency/+bug/1988311 > [3] https://github.com/eventlet/eventlet/issues/731 > [4] https://github.com/harlowja/fasteners/issues/96 > [5] https://github.com/harlowja/fasteners/pull/97 > [6] > > https://review.opendev.org/q/topic:bug/1988311+project:openstack/oslo.concurrency > [7] > https://review.opendev.org/q/topic:bug/1988311+project:openstack/nova > > > > > -- Herv? Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From felix.huettner at mail.schwarz Tue Sep 6 07:45:47 2022 From: felix.huettner at mail.schwarz (=?iso-8859-1?Q?Felix_H=FCttner?=) Date: Tue, 6 Sep 2022 07:45:47 +0000 Subject: [ops][largescale-sig] rabbitmq and the durability of reply_ queues In-Reply-To: References: Message-ID: Hi everyone, yes we also thought that, but it seems to be different. I'm unsure about the performance needs, but I think with quorum queues they might actually be possible. We did not yet try this out on our side, since we first wanted to gather ideas why it is implemented the current way. -- Felix Huettner > -----Original Message----- > From: Arnaud Morin > Sent: Monday, September 5, 2022 8:04 PM > To: Felix H?ttner > Cc: openstack-discuss > Subject: Re: [ops][largescale-sig] rabbitmq and the durability of reply_ > queues > > Hello, > > Thank you for bringing that up. > I was thinking (but it seems I was wrong) that the fanout/reply queues were > used for a one shot message/reply. > > Besides that, I am also wondering how much cpu power we will need to > replicate such queues? > > I guess I can can do the math from what we are currently running in > production :) > > Have you tried on a big cluster on your side? > > Cheers, > > Arnaud > > > On 02.09.22 - 08:19, Felix H?ttner wrote: > > Hi everyone, > > > > the largescale-sig currently recommends the following rabbitmq policy [1]: > '^(?!(amq\.)|(.*_fanout_)|(reply_)).*'. > > > > If I found the history of this setting correctly, it resulted from this mailinglist > thread [2] which came to the conclusion: > > > > > * use durable-queue and replication for long-running > > > queues/exchanges > > > * use non-durable-queue without replication for short (fanout, > > > reply_) queues > > > > However I am unsure if reply_ queues are actually shorted lived than the > "long-running" ones. > > If we take the example of the cinder-scheduler we have the following > queues: > > > > * cinder-scheduler: Tied to the lifetime of the whole cinder-scheduler > > cluster; currently durable + replicated > > * cinder-scheduler.myhostname: Tied to the lifetime of the > > cinder-scheduler service, but not removed when the service stops; > > currently durable + replicated > > * cinder-scheduler_fanout_somerandomid: Tied to the lifetime of the > > cinder-scheduler service, but removed when the service stops; > > currently neither durable nor replicated > > * reply_somerandomid: Tied to the lifetime of the cinder-scheduler > > service, but removed when the service stops; currently neither durable > > nor replicated > > > > If I read got all of the above correctly then reply_ and fanout queues are > actually not shorter lived than the normal queue to send requests to that > service. > > The only difference is that we remove them when the service itself stops. > > > > Therefor I want to propose the question if we should not also make these > queues durable and replicated. > > > > Thank you > > > > [1]: > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs > > .openstack.org%2Flarge- > scale%2Fother%2Frabbitmq.html%23pattern&dat > > > a=05%7C01%7C%7C1ae015a4eafb4646f9c108da8f690c71%7Cd04f47175a6e4b > 98b3f9 > > > 6918e0385f4c%7C0%7C0%7C637979978586225879%7CUnknown%7CTWFpbG > Zsb3d8eyJW > > > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C > 3000% > > > 7C%7C%7C&sdata=FjBYOdVXeQABeSUxpg%2B0a6YkXJWN%2B0dBebbh > 4CPwuok%3D& > > amp;reserved=0 > > [2]: > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist > > s.openstack.org%2Fpipermail%2Fopenstack-discuss%2F2020- > August%2F016562 > > > .html&data=05%7C01%7C%7C1ae015a4eafb4646f9c108da8f690c71%7Cd > 04f471 > > > 75a6e4b98b3f96918e0385f4c%7C0%7C0%7C637979978586225879%7CUnknow > n%7CTWF > > > pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV > CI6M > > > n0%3D%7C3000%7C%7C%7C&sdata=%2FrJpfgfuTTyglQS1AH3pz8mZF3IT > cetAv78% > > 2BQ1%2BORNk%3D&reserved=0 > > > > -- > > Felix Huettner > > > > Diese E Mail enth?lt m?glicherweise vertrauliche Inhalte und ist nur f?r die > Verwertung durch den vorgesehenen Empf?nger bestimmt. Sollten Sie nicht > der vorgesehene Empf?nger sein, setzen Sie den Absender bitte > unverz?glich in Kenntnis und l?schen diese E Mail. Hinweise zum > Datenschutz finden Sie > hier www.datenschutz.schwarz%2F&data=05%7C01%7C%7C1ae015a4eafb4 > 646f9c108da8f690c71%7Cd04f47175a6e4b98b3f96918e0385f4c%7C0%7C0%7C > 637979978586225879%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7 > C&sdata=%2BTyQF5u6KtsGThSfYJEHV333WFxgnXXZjDD0dIAo%2B4E%3 > D&reserved=0>. > > Diese E Mail enth?lt m?glicherweise vertrauliche Inhalte und ist nur f?r die Verwertung durch den vorgesehenen Empf?nger bestimmt. Sollten Sie nicht der vorgesehene Empf?nger sein, setzen Sie den Absender bitte unverz?glich in Kenntnis und l?schen diese E Mail. Hinweise zum Datenschutz finden Sie hier. From katonalala at gmail.com Tue Sep 6 08:23:45 2022 From: katonalala at gmail.com (Lajos Katona) Date: Tue, 6 Sep 2022 10:23:45 +0200 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 In-Reply-To: <2015881.Su3ONiSAvn@p1> References: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> <2015881.Su3ONiSAvn@p1> Message-ID: Hi, Revert sounds the rational solution, even if it is a hard decision as a lot of people/projects already put a lot of efforts to work on it. As I see if we revert it now and rever the revert and do a quick release of oslo.db in 2023.1 (aka Antelope) we can force projects to act, and give time to TC to force-approve it for understaffed projects. Lajos Slawek Kaplonski ezt ?rta (id?pont: 2022. szept. 6., K, 9:35): > Hi, > > Dnia poniedzia?ek, 5 wrze?nia 2022 18:14:27 CEST Stephen Finucane pisze: > > On Mon, 2022-09-05 at 16:19 +0200, El?d Ill?s wrote: > > > Hi, > > > With the latest oslo.db 12.1.0 release it seems multiple repositories > are > > > broken (see the corresponding requirements patch [1] for details, and > probably > > > there are more, that are not tested within requirements repository). > The patch > > > that introduces the break [2] "is necessary for oslo.db and openstack > > > applications in general to be able to run on SQLAlchemy 2.0" according > to > > > patch author. > > > Since we are after the 3rd milestone of Zed, we have very limited time > to > > > figure out what to do. The 2 options are: > > > > > > 1) fix every broken repository to work with oslo.db 12.1.0 > > > as far as we know this is quite impossible as for some > repositories the > > > already existing fixes took almost a cycle to be implemented and there > are > > > still undiscovered bugs around this. (we don't know if this is really > true, or > > > probably there are cases where it's easy to fix) > > > > I don't think this is True. To fully prepare for SQLAlchemy 2.0 you > would need > > to do this work, yes, however the issue here is that oslo.db no longer > > *defaults* to enabling one of the SQLAlchemy features that's being > removed in > > 2.0, autocommit, and not that it no longer supports it. There's nothing > to stop > > the affected projects from manually enabling autocommit behavior and to > prove > > this I just put together a patch for aodh to do just that [1]. Manually > enabling > > this feature would be my preferred approach since it means we're kicking > a > > slightly smaller can down the road and we'll have a better understanding > of the > > projects that still need to do work for SQLAlchemy 2.0, but I don't know > how > > likely it is that we can land all of these in the next week. > > > > > 2) revert the breaking change [2] and do another release in oslo.db now > > > without it (and add it back after Zed release & release oslo.db with > it as > > > soon as possible in Antelope cycle) > > > as far as we understand this does not cause any issue for those > who > > > already adapted to oslo.db 12.1.0, so this should not be painful > > > > This is all true, but it doesn't actually fix anything and delays the > necessary > > work to get us moving in the right direction. I've been harping on about > the > > fact that SQLAlchemy 2.0 is coming and will affect many projects for > over a year > > now [2] so perhaps a small but firm nudge like this would be beneficial > and get > > things rolling moving into Antelope? > > I would vote for reverting it now as we are close to the Zed release > deadline and then reverting this revert very early in the Antelope cycle to > give projects chance to adopt to the change or enable autocommit feature on > their own and start slower adoption later. > > > > > > Based on the above Release team is opting toward the 2nd option. > > > Please let us know your opinion! > > > [1] https://review.opendev.org/c/openstack/requirements/+/855153/ > > > [2] https://review.opendev.org/c/openstack/oslo.db/+/804775 > > > Thanks, > > > > > > El?d > > > > Cheers, > > Stephen > > > > [1] https://review.opendev.org/c/openstack/aodh/+/855962 > > [2] > https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.html > > > > > > > > > -- > Slawek Kaplonski > Principal Software Engineer > Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdeore at redhat.com Tue Sep 6 08:35:36 2022 From: pdeore at redhat.com (Pranali Deore) Date: Tue, 6 Sep 2022 14:05:36 +0530 Subject: [election][Glance] PTL Candidacy for Antelope Message-ID: Hello everyone, I would like to let you know that I will be PTL of Glance project for the Antelope cycle. I have been working closely with the previous PTL, Abhishek, since last cycle and I am hoping to contribute back to the community as a PTL while following his excellent example. The following will be my goals for Antelope cycle: 1. Bridge gap between python-glanceclient and openstackclient The CLI support for all glance APIS is already there in GlanceClient and the similar CLI support we need to have in OpenstackClient for the missing Glance APIs in this upcoming cycle. 2. Default Glance to configure multiple stores Glance has deprecated single stores configuration since Stein cycle and will remove the support of the same in the upcoming cycle. 3. Secure RBAC In Xena we have managed to move all policy checks to API layer and implemented project scope of metadef APIs. As per the revised community goal, in zed cycle we have made all policy rules set scope_types=['project'] for all project resources that have already implemented scope. Now we need to have manager role support once it's fully implemented in Keystone. 4. Community priorities Whatever community goals put forward by TC, as a PTL of Glance project will want to adopt these as a priority for the Antelope cycle. 5. Other As we are very short team at this moment, I would like to put some efforts in attracting some contributors, help them to understand how Glance functions and encourage them to contribute for Glance. Looking at how Abhishek, Erno and Brian have steadied the ship, I know it's a big task and with their help I will do my best not to fail the expectations. Thank you for consideration, Pranali Deore (pdeore) -------------- next part -------------- An HTML attachment was scrubbed... URL: From fpantano at redhat.com Tue Sep 6 09:16:02 2022 From: fpantano at redhat.com (Francesco Pantano) Date: Tue, 6 Sep 2022 11:16:02 +0200 Subject: [election][Glance] PTL Candidacy for Antelope In-Reply-To: References: Message-ID: +1, thanks Pranali! On Tue, Sep 6, 2022 at 11:01 AM Pranali Deore wrote: > Hello everyone, > > I would like to let you know that I will be PTL of Glance project for the > Antelope cycle. > > I have been working closely with the previous PTL, Abhishek, since last > cycle and I am hoping to contribute back to the community as a PTL while > following his excellent example. > > The following will be my goals for Antelope cycle: > > 1. Bridge gap between python-glanceclient and openstackclient > The CLI support for all glance APIS is already there in GlanceClient > and the similar CLI > support we need to have in OpenstackClient for the missing Glance APIs > in this > upcoming cycle. > > 2. Default Glance to configure multiple stores > Glance has deprecated single stores configuration since Stein cycle > and will remove the > support of the same in the upcoming cycle. > > 3. Secure RBAC > In Xena we have managed to move all policy checks to API layer and > implemented > project scope of metadef APIs. As per the revised community goal, in > zed cycle we have made all policy rules set > scope_types=['project'] for all project resources that have already > implemented scope. Now we need to have manager role support once it's > fully implemented in Keystone. > > 4. Community priorities > Whatever community goals put forward by TC, as a PTL of Glance > project will > want to adopt these as a priority for the Antelope cycle. > > 5. Other > As we are very short team at this moment, I would like to put some > efforts > in attracting some contributors, help them to understand how Glance > functions and encourage them to contribute for Glance. > > Looking at how Abhishek, Erno and Brian have steadied the ship, I know it's > a big task and with their help I will do my best not to fail the > expectations. > > > Thank you for consideration, > > Pranali Deore (pdeore) > -- Francesco Pantano GPG KEY: F41BD75C -------------- next part -------------- An HTML attachment was scrubbed... URL: From gthiemonge at redhat.com Tue Sep 6 09:28:59 2022 From: gthiemonge at redhat.com (Gregory Thiemonge) Date: Tue, 6 Sep 2022 11:28:59 +0200 Subject: [Octavia][release] Requesting exception for python-octaviaclient Message-ID: Hi Folks, I am requesting a Feature Freeze Exception for the release of python-octaviaclient for Zed. One patch [0] was merged at the end of last week in python-octaviaclient (we were waiting for the related feature to get merged in the octavia repo) and a new release (3.1.0) was proposed for Zed in the release repo [1], but it wasn't merged in time. We would like to get the approval for this new release so we could base the stable/zed branch on this new tag (we would need to update [2]). Thanks, Gregory [0] https://review.opendev.org/c/openstack/python-octaviaclient/+/664473 [1] https://review.opendev.org/c/openstack/releases/+/855675 [2] https://review.opendev.org/c/openstack/releases/+/855912 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Tue Sep 6 10:12:52 2022 From: hberaud at redhat.com (Herve Beraud) Date: Tue, 6 Sep 2022 12:12:52 +0200 Subject: [oslo][relmgmt][taskflow][nova] fasteners.ReaderWriterLock and oslo.concurrency's fair lock is broken if used in eventlet In-Reply-To: References: Message-ID: The patches are now merged and a new release is on the way https://review.opendev.org/c/openstack/releases/+/856037 Once the release patch is merged I'll request a RFE for an UC bump for oslo.concurrency which is an independent deliverable. Le mar. 6 sept. 2022 ? 09:41, Herve Beraud a ?crit : > The oslo patches have been approved, I'll propose a new release, in a > couple of hours, when they will be merged. > > Le lun. 5 sept. 2022 ? 18:27, Balazs Gibizer a ?crit : > >> Hi, >> >> It is hard to properly figure out which OpenStack project is affected >> exactly. But I want to give a heads up. If the following is true for >> your project then you are affected: >> * using eventlet and >> * using oslo.concurrency fair internal lock (external lock or non fair >> locks are not affected) or using fasteners.ReaderWriterLock directly. >> >> I know that nova is affected and based on code search taskflow is >> affected at least. >> >> The oslo.concurrency's fair lock uses fasteners.ReaderWriterLock[1]. >> The fasteners.ReaderWriterLock relies on threading.current_thread to >> identify a thread and decide if a thread already has a lock and >> therefore can reenter the lock. However in an eventlet monkey patched >> environment, a thread that is created with eventlet.spawn_n() or the >> patched threading.Thread() the threading.current_thread call does not >> return an eventlet unique ID. This causes that the lock can be >> reentered from multiple eventlets at the same time. >> >> We have 4 ways forward: >> >> 0) Fix eventlet. There is an open issue in eventlet[3] for this open >> since October 2021. Based on the ticket this direction does not seems >> to feasible. >> >> 1) Sean recently opened an issue[4] on fasteners to restore a >> previously existing workaround that could fix our issues. If an new >> fasteners lib is released with the workaround[5] then at least >> oslo.concurrency requirements needs to be bumped and a new oslo release >> is pushed. >> >> 2) If the fasteners' maintainer does not accept [4][5] in time then I >> have an oslo.concurrency patch[6] that implements a workaround in oslo. >> This also requires a new olso.concurrency release. Also this means that >> projects that are using fasteners.ReaderWriterLock directly need to >> re-implement the fix locally. >> >> 3) If all odds fails I have a nova only patch[7] that implements the >> workaround locally in nova. >> >> >> Note that this issue is present in stable/yoga and on master. On >> stable/xena we uses fasteners < 0.15.0 which is not affected. >> >> Cheers, >> gibi >> >> [1] >> >> https://github.com/openstack/oslo.concurrency/blob/052b2f23572900601b0f41387dbbb07153d88982/oslo_concurrency/lockutils.py#L287-L288 >> [2] https://bugs.launchpad.net/oslo.concurrency/+bug/1988311 >> [3] https://github.com/eventlet/eventlet/issues/731 >> [4] https://github.com/harlowja/fasteners/issues/96 >> [5] https://github.com/harlowja/fasteners/pull/97 >> [6] >> >> https://review.opendev.org/q/topic:bug/1988311+project:openstack/oslo.concurrency >> [7] >> https://review.opendev.org/q/topic:bug/1988311+project:openstack/nova >> >> >> >> >> > > -- > Herv? Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > > -- Herv? Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephenfin at redhat.com Tue Sep 6 10:22:30 2022 From: stephenfin at redhat.com (Stephen Finucane) Date: Tue, 06 Sep 2022 11:22:30 +0100 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 In-Reply-To: References: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> Message-ID: On Mon, 2022-09-05 at 19:00 +0200, Thierry Carrez wrote: > Stephen Finucane wrote: > > On Mon, 2022-09-05 at 16:19 +0200, El?d Ill?s wrote: > > > [...] The 2 options are: > > > > > > 1) fix every broken repository to work with oslo.db 12.1.0 > > > ???? as far as we know this is quite impossible as for some repositories the > > > already existing fixes took almost a cycle to be implemented and there are > > > still undiscovered bugs around this. (we don't know if this is really true, or > > > probably there are cases where it's easy to fix) > > > > I don't think this is True. To fully prepare for SQLAlchemy 2.0 you would need > > to do this work, yes, however the issue here is that oslo.db no longer > > *defaults* to enabling one of the SQLAlchemy features that's being removed in > > 2.0, autocommit, and not that it no longer supports it. There's nothing to stop > > the affected projects from manually enabling autocommit behavior and to prove > > this I just put together a patch for aodh to do just that [1]. Manually enabling > > this feature would be my preferred approach since it means we're kicking a > > slightly smaller can down the road and we'll have a better understanding of the > > projects that still need to do work for SQLAlchemy 2.0, but I don't know how > > likely it is that we can land all of these in the next week. > > I agree this is the preferable option... and if we had a couple extra > weeks to make it happen I would pick it without hesitation... > > Here I feel to make it happen in time for the Zed release we'll need to > get someone to post all the autocommit option patches and potentially > the TC stepping in to authorize the TaCT team to force-approve the ones > that would not get attention from their core teams in time. I did those yesterday. Aodh: https://review.opendev.org/c/openstack/aodh/+/855962 Designate: https://review.opendev.org/c/openstack/designate/+/855965 Manila: https://review.opendev.org/c/openstack/manila/+/855967 Ironic: https://review.opendev.org/c/openstack/ironic/+/855969 Heat: https://review.opendev.org/c/openstack/heat/+/855970 Barbican: https://review.opendev.org/c/openstack/barbican/+/855972 The barbican one isn't correct and I need to respin it. The rest are working as expected though, as proven at [1]. Stephen [1] https://review.opendev.org/c/openstack/requirements/+/855973/ > > > > 2) revert the breaking change [2] and do another release in oslo.db now > > > without it (and add it back after Zed release & release oslo.db with it as > > > soon as possible in Antelope cycle) > > > ???? as far as we understand this does not cause any issue for those who > > > already adapted to oslo.db 12.1.0, so this should not be painful > > > > This is all true, but it doesn't actually fix anything and delays the necessary > > work to get us moving in the right direction. I've been harping on about the > > fact that SQLAlchemy 2.0 is coming and will affect many projects for over a year > > now [2] so perhaps a small but firm nudge like this would be beneficial and get > > things rolling moving into Antelope? > > I agree it's a step back without guarantee that things would go a lot > better in the Antelope redo... but it is a more controlled path. > > I'd say we should see if we can get critical attention on this in the > next couple of days, and if not we can use option (2) as a plan B ? > From hanguangyu2 at gmail.com Tue Sep 6 10:32:41 2022 From: hanguangyu2 at gmail.com (=?UTF-8?B?6Z+p5YWJ5a6H?=) Date: Tue, 6 Sep 2022 18:32:41 +0800 Subject: [nova]How to confirm whether a arm64 node supports hardware acceleration for virtual machines Message-ID: Hello, I see `egrep -c '(vmx|svm)' /proc/cpuinfo` in nova install documentation[1]. It can be used to confirm whether a node supports hardware acceleration for virtual machines on x86 architecture. But it is not applicable in the ARM architecture. Do we have an officially recommended method to confirm in ARM architecture? Thanks, Han Guangyu [1]https://docs.openstack.org/nova/latest/install/compute-install-rdo.html#finalize-installation From stephenfin at redhat.com Tue Sep 6 10:38:16 2022 From: stephenfin at redhat.com (Stephen Finucane) Date: Tue, 06 Sep 2022 11:38:16 +0100 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 In-Reply-To: References: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> Message-ID: On Tue, 2022-09-06 at 11:22 +0100, Stephen Finucane wrote: > On Mon, 2022-09-05 at 19:00 +0200, Thierry Carrez wrote: > > Stephen Finucane wrote: > > > On Mon, 2022-09-05 at 16:19 +0200, El?d Ill?s wrote: > > > > [...] The 2 options are: > > > > > > > > 1) fix every broken repository to work with oslo.db 12.1.0 > > > > ???? as far as we know this is quite impossible as for some repositories the > > > > already existing fixes took almost a cycle to be implemented and there are > > > > still undiscovered bugs around this. (we don't know if this is really true, or > > > > probably there are cases where it's easy to fix) > > > > > > I don't think this is True. To fully prepare for SQLAlchemy 2.0 you would need > > > to do this work, yes, however the issue here is that oslo.db no longer > > > *defaults* to enabling one of the SQLAlchemy features that's being removed in > > > 2.0, autocommit, and not that it no longer supports it. There's nothing to stop > > > the affected projects from manually enabling autocommit behavior and to prove > > > this I just put together a patch for aodh to do just that [1]. Manually enabling > > > this feature would be my preferred approach since it means we're kicking a > > > slightly smaller can down the road and we'll have a better understanding of the > > > projects that still need to do work for SQLAlchemy 2.0, but I don't know how > > > likely it is that we can land all of these in the next week. > > > > I agree this is the preferable option... and if we had a couple extra > > weeks to make it happen I would pick it without hesitation... > > > > Here I feel to make it happen in time for the Zed release we'll need to > > get someone to post all the autocommit option patches and potentially > > the TC stepping in to authorize the TaCT team to force-approve the ones > > that would not get attention from their core teams in time. > > I did those yesterday. > > Aodh: https://review.opendev.org/c/openstack/aodh/+/855962 > Designate: https://review.opendev.org/c/openstack/designate/+/855965 > Manila: https://review.opendev.org/c/openstack/manila/+/855967 > Ironic: https://review.opendev.org/c/openstack/ironic/+/855969 > Heat: https://review.opendev.org/c/openstack/heat/+/855970 > Barbican: https://review.opendev.org/c/openstack/barbican/+/855972 > > The barbican one isn't correct and I need to respin it. The rest are working as > expected though, as proven at [1]. Actually, the barbican change isn't working because it isn't needed: Barbican (helpfully) doesn't rely on autocommit. If we can get those other 5 patches merged + the placement patch from gibi, we should have no issues with oslo.db 12.1.0. They're not long-term fixes and more bandaid solutions but they'll tide us over until these projects can rework their DB layers to be SQLAlchemy 2.0 compatible in Antelope. Stephen > > Stephen > > [1] https://review.opendev.org/c/openstack/requirements/+/855973/ > > > > > > > 2) revert the breaking change [2] and do another release in oslo.db now > > > > without it (and add it back after Zed release & release oslo.db with it as > > > > soon as possible in Antelope cycle) > > > > ???? as far as we understand this does not cause any issue for those who > > > > already adapted to oslo.db 12.1.0, so this should not be painful > > > > > > This is all true, but it doesn't actually fix anything and delays the necessary > > > work to get us moving in the right direction. I've been harping on about the > > > fact that SQLAlchemy 2.0 is coming and will affect many projects for over a year > > > now [2] so perhaps a small but firm nudge like this would be beneficial and get > > > things rolling moving into Antelope? > > > > I agree it's a step back without guarantee that things would go a lot > > better in the Antelope redo... but it is a more controlled path. > > > > I'd say we should see if we can get critical attention on this in the > > next couple of days, and if not we can use option (2) as a plan B ? > > > From derekokeeffe85 at yahoo.ie Tue Sep 6 11:20:07 2022 From: derekokeeffe85 at yahoo.ie (Derek O keeffe) Date: Tue, 6 Sep 2022 11:20:07 +0000 (UTC) Subject: Two containers fail References: <1620203509.7191320.1662463207826.ref@mail.yahoo.com> Message-ID: <1620203509.7191320.1662463207826@mail.yahoo.com> Hi,? I recently successfully installed OSA and I am now trying to install it again from scratch with all the configuration changes I needed in place. Unfortunately this time around it is failing on setup_hosts.yml here: TASK [lxc_container_create : Create container (dir)] ******************************************************************ok: [infra1_memcached_container-b92f4db7 -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_rabbit_mq_container-d286a482 -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_utility_container-05f756fc -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_galera_container-5beef059 -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_aodh_container-639f5ad8 -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_neutron_server_container-f67e972d -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_horizon_container-dfeaa0dc -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_placement_container-350e4ede -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_heat_api_container-82cbd764 -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_nova_api_container-b30c38d1 -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_repo_container-f16e50a9 -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_ceilometer_central_container-910a888f -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_keystone_container-32dcd68b -> infra1(CONTROLLER_IP_ADDRESS)]ok: [infra1_gnocchi_container-30ccb451 -> infra1(CONTROLLER_IP_ADDRESS)]fatal: [infra1_cinder_api_container-840a18bb -> infra1(CONTROLLER_IP_ADDRESS)]: FAILED! => {"changed": false, "error": "Failed to start container [ infra1_cinder_api_container-840a18bb ]", "lxc_container": {"init_pid": -1, "interfaces": [], "ips": [], "name": "infra1_cinder_api_container-840a18bb", "state": "stopped"}, "msg": "The container [ infra1_cinder_api_container-840a18bb ] failed to start. Check to lxc is available and that the container is in a functional state.", "rc": 1}fatal: [infra1_glance_container-b50e16a6 -> infra1(CONTROLLER_IP_ADDRESS)]: FAILED! => {"changed": false, "error": "Failed to start container [ infra1_glance_container-b50e16a6 ]", "lxc_container": {"init_pid": -1, "interfaces": [], "ips": [], "name": "infra1_glance_container-b50e16a6", "state": "stopped"}, "msg": "The container [ infra1_glance_container-b50e16a6 ] failed to start. Check to lxc is available and that the container is in a functional state.", "rc": 1} I don't understand how 14 containers are fine (can be attached to and commands run through lxc-attach) and 2 containers are failing. I have a deploy host, controller and two computes all with a fresh install of Ubuntu 20.04. The bootstrap_ansible script ran fine on the deploy host and the setup_hosts playbook ran through fully as after the above it skipped cinder and glance containers every where else.? Can anybody please point me in the direction of getting more info or a possible cause. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From smooney at redhat.com Tue Sep 6 11:24:19 2022 From: smooney at redhat.com (Sean Mooney) Date: Tue, 06 Sep 2022 12:24:19 +0100 Subject: [nova]How to confirm whether a arm64 node supports hardware acceleration for virtual machines In-Reply-To: References: Message-ID: On Tue, 2022-09-06 at 18:32 +0800, ??? wrote: > Hello, > > I see `egrep -c '(vmx|svm)' /proc/cpuinfo` in nova install > documentation[1]. It can be used to confirm whether a node supports > hardware acceleration for virtual machines on x86 architecture. But it > is not applicable in the ARM architecture. > > Do we have an officially recommended method to confirm in ARM architecture? on arm like x86 there are several extions that allow virutalistion the most basic is called VHE(Virtualization Host Extension) https://lwn.net/Articles/674533/ https://developer.arm.com/documentation/102142/0100/Virtualization-host-extensions they really only started to be a thing in armv8.1-a onwords https://en.wikipedia.org/wiki/AArch64 im not really sure fither is a prefered way to detect those. i would hope lscpu or /proc/cpuinfo would be an option looking on m1 macbook air under debian virt-host-valdiate show that kvm is aviable and acceible but lscpu does not show any cpu flags that looked virtualistion related. your milage might vary on a more standard arm plathform. virt-host-validate is gerneally provided as part of the libvirt installation so that would be my starting point. > > Thanks, > Han Guangyu > > [1]https://docs.openstack.org/nova/latest/install/compute-install-rdo.html#finalize-installation > From marcin.juszkiewicz at linaro.org Tue Sep 6 11:41:53 2022 From: marcin.juszkiewicz at linaro.org (Marcin Juszkiewicz) Date: Tue, 6 Sep 2022 13:41:53 +0200 Subject: [nova]How to confirm whether a arm64 node supports hardware acceleration for virtual machines In-Reply-To: References: Message-ID: <9b483b5f-1324-53cd-97fc-a45f131e55f2@linaro.org> W dniu 6.09.2022 o?13:24, Sean Mooney pisze: > On Tue, 2022-09-06 at 18:32 +0800, ??? wrote: >> I see `egrep -c '(vmx|svm)' /proc/cpuinfo` in nova install >> documentation[1]. It can be used to confirm whether a node supports >> hardware acceleration for virtual machines on x86 architecture. But it >> is not applicable in the ARM architecture. >> >> Do we have an officially recommended method to confirm in ARM architecture? > on arm like x86 there are several extions that allow virutalistion the most basic is called VHE(Virtualization Host Extension) > https://lwn.net/Articles/674533/ > https://developer.arm.com/documentation/102142/0100/Virtualization-host-extensions > > they really only started to be a thing in armv8.1-a onwords > https://en.wikipedia.org/wiki/AArch64 > > im not really sure fither is a prefered way to detect those. > i would hope lscpu or /proc/cpuinfo would be an option > > looking on m1 macbook air under debian virt-host-valdiate show that kvm is aviable and acceible > but lscpu does not show any cpu flags that looked virtualistion related. > your milage might vary on a more standard arm plathform. Each AArch64 system should support virtualization. Nested virtualization requires v8.3/v8.4 cpu. > virt-host-validate is gerneally provided as part of the libvirt installation > so that would be my starting point. From rlandy at redhat.com Tue Sep 6 11:42:52 2022 From: rlandy at redhat.com (Ronelle Landy) Date: Tue, 6 Sep 2022 07:42:52 -0400 Subject: [election][tripleo] PTL Candidacy for Antelope cycle In-Reply-To: References: Message-ID: On Mon, Sep 5, 2022 at 2:10 AM Marios Andreou wrote: > +1 thank you Rabi > > On Tue, Aug 30, 2022 at 5:35 PM Rabi Mishra wrote: > > > > Hi All, > > > > I would like to nominate myself for Antelope cycle TripleO PTL. > > > > As some of you would know, I have been part of the OpenStack community > > for a long time and have been a core contributor for TripleO and Heat. > > I have also served as Heat PTL for Ocata cycle. > > > > James has done a great job as PTL for the last few cycles. I would like > > to take the opportunity to thank him for all his effort and we all would > > agree that he needs a well deserved break. > > > > I am looking forward to take the opportunity to help the community to > > achieve some of the already planned goals and in-progress workstreams > > like standalone roles, multi-rhel and other challenges that come along > > the way. > +1 Absolutely - thanks for stepping up here. Thanks to James for his work last cycle > > > > Also, as before, our focus would continue to be on review prioritization, > > in progress work streams and collaboration on common priorities. > > > > Regards, > > Rabi Mishra > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Tue Sep 6 12:12:06 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 6 Sep 2022 12:12:06 +0000 Subject: [election][Requirements] PTL candidacy In-Reply-To: References: <20220905212143.ennkg62brej4ork2@mthode.org> <20220905213355.doauyoh5v2itn657@yuggoth.org> <20220905223948.747dah7efj4osov3@mthode.org> Message-ID: <20220906121205.wsvmsfwj6aq5t7mh@yuggoth.org> On 2022-09-06 11:26:10 +1000 (+1000), Tony Breeds wrote: > Yeah we need to update the election code to handle teams that are > under distributed leadership. > > Something for the next cycle. [...] https://review.opendev.org/855981 looks like an attempt at a workaround. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From mthode at mthode.org Tue Sep 6 13:24:37 2022 From: mthode at mthode.org (Matthew Thode) Date: Tue, 6 Sep 2022 08:24:37 -0500 Subject: [Octavia][release] Requesting exception for python-octaviaclient In-Reply-To: References: Message-ID: <20220906132437.mafsogcmuri66qja@mthode.org> On 22-09-06 11:28:59, Gregory Thiemonge wrote: > Hi Folks, > > I am requesting a Feature Freeze Exception for the release of > python-octaviaclient for Zed. > > One patch [0] was merged at the end of last week in python-octaviaclient (we > were waiting for the related feature to get merged in the octavia repo) and > a > new release (3.1.0) was proposed for Zed in the release repo [1], but it > wasn't > merged in time. > > We would like to get the approval for this new release so we could base the > stable/zed branch on this new tag (we would need to update [2]). > > Thanks, > > Gregory > > [0] https://review.opendev.org/c/openstack/python-octaviaclient/+/664473 > [1] https://review.opendev.org/c/openstack/releases/+/855675 > [2] https://review.opendev.org/c/openstack/releases/+/855912 Yep, we are good to merge this -- Matthew Thode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From noonedeadpunk at gmail.com Tue Sep 6 13:37:55 2022 From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov) Date: Tue, 6 Sep 2022 15:37:55 +0200 Subject: Two containers fail In-Reply-To: <1620203509.7191320.1662463207826@mail.yahoo.com> References: <1620203509.7191320.1662463207826.ref@mail.yahoo.com> <1620203509.7191320.1662463207826@mail.yahoo.com> Message-ID: Hi, These 2 containers are the only ones that should have a storage network in them. So I would assume that failure to start containers is related to the storage net. Please, kindly check that br-stor is configured correctly on hosts and defined in openstack-user-config.yml ??, 6 ????. 2022 ?. ? 13:25, Derek O keeffe : > > Hi, > > I recently successfully installed OSA and I am now trying to install it again from scratch with all the configuration changes I needed in place. > > Unfortunately this time around it is failing on setup_hosts.yml here: > > TASK [lxc_container_create : Create container (dir)] ****************************************************************** > ok: [infra1_memcached_container-b92f4db7 -> infra1(CONTROLLER_IP_ADDRESS)] > ok: [infra1_rabbit_mq_container-d286a482 -> infra1(CONTROLLER_IP_ADDRESS)] > ok: [infra1_utility_container-05f756fc -> infra1(CONTROLLER_IP_ADDRESS)] > ok: [infra1_galera_container-5beef059 -> infra1(CONTROLLER_IP_ADDRESS)] > ok: [infra1_aodh_container-639f5ad8 -> infra1(CONTROLLER_IP_ADDRESS)] > ok: [infra1_neutron_server_container-f67e972d -> infra1(CONTROLLER_IP_ADDRESS)] > ok: [infra1_horizon_container-dfeaa0dc -> infra1(CONTROLLER_IP_ADDRESS)] > ok: [infra1_placement_container-350e4ede -> infra1(CONTROLLER_IP_ADDRESS)] > ok: [infra1_heat_api_container-82cbd764 -> infra1(CONTROLLER_IP_ADDRESS)] > ok: [infra1_nova_api_container-b30c38d1 -> infra1(CONTROLLER_IP_ADDRESS)] > ok: [infra1_repo_container-f16e50a9 -> infra1(CONTROLLER_IP_ADDRESS)] > ok: [infra1_ceilometer_central_container-910a888f -> infra1(CONTROLLER_IP_ADDRESS)] > ok: [infra1_keystone_container-32dcd68b -> infra1(CONTROLLER_IP_ADDRESS)] > ok: [infra1_gnocchi_container-30ccb451 -> infra1(CONTROLLER_IP_ADDRESS)] > fatal: [infra1_cinder_api_container-840a18bb -> infra1(CONTROLLER_IP_ADDRESS)]: FAILED! => {"changed": false, "error": "Failed to start container [ infra1_cinder_api_container-840a18bb ]", "lxc_container": {"init_pid": -1, "interfaces": [], "ips": [], "name": "infra1_cinder_api_container-840a18bb", "state": "stopped"}, "msg": "The container [ infra1_cinder_api_container-840a18bb ] failed to start. Check to lxc is available and that the container is in a functional state.", "rc": 1} > fatal: [infra1_glance_container-b50e16a6 -> infra1(CONTROLLER_IP_ADDRESS)]: FAILED! => {"changed": false, "error": "Failed to start container [ infra1_glance_container-b50e16a6 ]", "lxc_container": {"init_pid": -1, "interfaces": [], "ips": [], "name": "infra1_glance_container-b50e16a6", "state": "stopped"}, "msg": "The container [ infra1_glance_container-b50e16a6 ] failed to start. Check to lxc is available and that the container is in a functional state.", "rc": 1} > > I don't understand how 14 containers are fine (can be attached to and commands run through lxc-attach) and 2 containers are failing. I have a deploy host, controller and two computes all with a fresh install of Ubuntu 20.04. The bootstrap_ansible script ran fine on the deploy host and the setup_hosts playbook ran through fully as after the above it skipped cinder and glance containers every where else. Can anybody please point me in the direction of getting more info or a possible cause. Thanks in advance. > From derekokeeffe85 at yahoo.ie Tue Sep 6 13:50:57 2022 From: derekokeeffe85 at yahoo.ie (Derek O keeffe) Date: Tue, 6 Sep 2022 14:50:57 +0100 Subject: Two containers fail In-Reply-To: References: Message-ID: <806A08C5-57AF-44FB-B0ED-D18DC241542C@yahoo.ie> Hi Dmitriy, Yes I just spotted that myself as well. Thanks Regards, Derek > On 6 Sep 2022, at 14:41, Dmitriy Rabotyagov wrote: > > ?Hi, > > These 2 containers are the only ones that should have a storage > network in them. So I would assume that failure to start containers is > related to the storage net. Please, kindly check that br-stor is > configured correctly on hosts and defined in openstack-user-config.yml > > ??, 6 ????. 2022 ?. ? 13:25, Derek O keeffe : >> >> Hi, >> >> I recently successfully installed OSA and I am now trying to install it again from scratch with all the configuration changes I needed in place. >> >> Unfortunately this time around it is failing on setup_hosts.yml here: >> >> TASK [lxc_container_create : Create container (dir)] ****************************************************************** >> ok: [infra1_memcached_container-b92f4db7 -> infra1(CONTROLLER_IP_ADDRESS)] >> ok: [infra1_rabbit_mq_container-d286a482 -> infra1(CONTROLLER_IP_ADDRESS)] >> ok: [infra1_utility_container-05f756fc -> infra1(CONTROLLER_IP_ADDRESS)] >> ok: [infra1_galera_container-5beef059 -> infra1(CONTROLLER_IP_ADDRESS)] >> ok: [infra1_aodh_container-639f5ad8 -> infra1(CONTROLLER_IP_ADDRESS)] >> ok: [infra1_neutron_server_container-f67e972d -> infra1(CONTROLLER_IP_ADDRESS)] >> ok: [infra1_horizon_container-dfeaa0dc -> infra1(CONTROLLER_IP_ADDRESS)] >> ok: [infra1_placement_container-350e4ede -> infra1(CONTROLLER_IP_ADDRESS)] >> ok: [infra1_heat_api_container-82cbd764 -> infra1(CONTROLLER_IP_ADDRESS)] >> ok: [infra1_nova_api_container-b30c38d1 -> infra1(CONTROLLER_IP_ADDRESS)] >> ok: [infra1_repo_container-f16e50a9 -> infra1(CONTROLLER_IP_ADDRESS)] >> ok: [infra1_ceilometer_central_container-910a888f -> infra1(CONTROLLER_IP_ADDRESS)] >> ok: [infra1_keystone_container-32dcd68b -> infra1(CONTROLLER_IP_ADDRESS)] >> ok: [infra1_gnocchi_container-30ccb451 -> infra1(CONTROLLER_IP_ADDRESS)] >> fatal: [infra1_cinder_api_container-840a18bb -> infra1(CONTROLLER_IP_ADDRESS)]: FAILED! => {"changed": false, "error": "Failed to start container [ infra1_cinder_api_container-840a18bb ]", "lxc_container": {"init_pid": -1, "interfaces": [], "ips": [], "name": "infra1_cinder_api_container-840a18bb", "state": "stopped"}, "msg": "The container [ infra1_cinder_api_container-840a18bb ] failed to start. Check to lxc is available and that the container is in a functional state.", "rc": 1} >> fatal: [infra1_glance_container-b50e16a6 -> infra1(CONTROLLER_IP_ADDRESS)]: FAILED! => {"changed": false, "error": "Failed to start container [ infra1_glance_container-b50e16a6 ]", "lxc_container": {"init_pid": -1, "interfaces": [], "ips": [], "name": "infra1_glance_container-b50e16a6", "state": "stopped"}, "msg": "The container [ infra1_glance_container-b50e16a6 ] failed to start. Check to lxc is available and that the container is in a functional state.", "rc": 1} >> >> I don't understand how 14 containers are fine (can be attached to and commands run through lxc-attach) and 2 containers are failing. I have a deploy host, controller and two computes all with a fresh install of Ubuntu 20.04. The bootstrap_ansible script ran fine on the deploy host and the setup_hosts playbook ran through fully as after the above it skipped cinder and glance containers every where else. Can anybody please point me in the direction of getting more info or a possible cause. Thanks in advance. >> > From haleyb.dev at gmail.com Tue Sep 6 14:27:22 2022 From: haleyb.dev at gmail.com (Brian Haley) Date: Tue, 6 Sep 2022 10:27:22 -0400 Subject: [neutron] Bug deputy report for week of August 29th Message-ID: <8b30d353-af0f-628c-e7be-8dd4de2ffa15@gmail.com> Hi, I was Neutron bug deputy last week. Below is a short summary about the reported bugs. BTW, you don't have to wait for me to be deputy to file all your bugs :) -Brian Critical bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1988026 - Neutron should not create security group with project==None - Talked to Security Response Team and they decided to add a tracker to it since the quota system doesn't seem to limit how many random default security groups one can create. - https://review.opendev.org/c/openstack/neutron/+/855580 High bugs --------- * https://bugs.launchpad.net/neutron/+bug/1988037 - Neutron does not find an existing route - https://review.opendev.org/c/openstack/neutron/+/854986 * https://bugs.launchpad.net/neutron/+bug/1988296 - neutron-lib pep8 CI failing with pylint==2.15.0 - https://review.opendev.org/c/openstack/neutron-lib/+/855061 Medium bugs ----------- * https://bugs.launchpad.net/neutron/+bug/1988069 - neutron-dhcp-agent fails when small tenant network mtu is set - Could not reproduce issue reported with MTU as 70 for network, only saw that instances could not do DHCP with it so small. Looks like a potential kernel bug since this works on later versions. * https://bugs.launchpad.net/neutron/+bug/1988199 - https://review.opendev.org/c/openstack/neutron/+/855257 * https://bugs.launchpad.net/neutron/+bug/1988220 - large unused dependency ncclient + paramiko in os-ken - Assigned to Rodolfo since he made change to remove nose https://review.opendev.org/c/openstack/os-ken/+/850631 - closed (won't-fix) as ncclient is required for os-ken, just wasn't explicitly called-out in requirements. * https://bugs.launchpad.net/neutron/+bug/1988549 - Trunk status is down after a live-migration - Arnau Verdaguer took ownership Low bugs -------- * https://bugs.launchpad.net/neutron/+bug/1988298 - [neutron-lib] "registry.has_resource_extenders" is the same as "resource_extend.has_resource_extenders" - Needs owner * https://bugs.launchpad.net/neutron/+bug/1586731 - restart neutron ovs agent will leave the fanout queue behind - Old bug re-opened - Partial patch posted, asked commenter to submit to master Misc bugs --------- * https://bugs.launchpad.net/neutron/+bug/1988281 - neutron dhcp agent state not consistent with real status - After a restart, the agent status is UP even though it is still doing a full-sync operation, is there a way to signify this status? See bug for further discussion. * https://bugs.launchpad.net/neutron/+bug/1988382 - L3 agent(agent_mode=dvr_snat) restart, fip namespace removed rfp-port, resulting in fip not connecting - Failure is seen in code from 2019, asked submitter to try tip of stable/victoria and reproduce since there have been fixed in this area since then. Wishlist bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1988077 - Noisy neutron-openvswitch-agent service - There are some deployments that wanted more logging which is why the agent is more verbose. Will have to have a further discussion to see if there is a way to address concern of log being noisy, besides using more aggressive log rotation as suggested. * https://bugs.launchpad.net/neutron/+bug/1988188 - Create an automated tool to retrieve the needed OVS version depending on the OVN one - Suggested by Rodolfo to help improve gate dependencies. * https://bugs.launchpad.net/neutron/+bug/1988542 - [RFE] OVN support for vnic type virtio-forwarder - Will need to add to Drivers meeting agenda From elod.illes at est.tech Tue Sep 6 15:13:23 2022 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Tue, 6 Sep 2022 17:13:23 +0200 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 In-Reply-To: References: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> Message-ID: <0f3c8ad2-e07b-b2ec-16e9-9fc215f8f493@est.tech> Thanks Stephen for working on this! If those patches get merged *and* nothing else is needed, then Option 1 seems to be the better solution. Anyone aware of other place where a fix is needed, or have uncertainties about Option 1? Thanks, El?d On 2022. 09. 06. 12:38, Stephen Finucane wrote: > On Tue, 2022-09-06 at 11:22 +0100, Stephen Finucane wrote: >> On Mon, 2022-09-05 at 19:00 +0200, Thierry Carrez wrote: >>> Stephen Finucane wrote: >>>> On Mon, 2022-09-05 at 16:19 +0200, El?d Ill?s wrote: >>>>> [...] The 2 options are: >>>>> >>>>> 1) fix every broken repository to work with oslo.db 12.1.0 >>>>> ???? as far as we know this is quite impossible as for some repositories the >>>>> already existing fixes took almost a cycle to be implemented and there are >>>>> still undiscovered bugs around this. (we don't know if this is really true, or >>>>> probably there are cases where it's easy to fix) >>>> I don't think this is True. To fully prepare for SQLAlchemy 2.0 you would need >>>> to do this work, yes, however the issue here is that oslo.db no longer >>>> *defaults* to enabling one of the SQLAlchemy features that's being removed in >>>> 2.0, autocommit, and not that it no longer supports it. There's nothing to stop >>>> the affected projects from manually enabling autocommit behavior and to prove >>>> this I just put together a patch for aodh to do just that [1]. Manually enabling >>>> this feature would be my preferred approach since it means we're kicking a >>>> slightly smaller can down the road and we'll have a better understanding of the >>>> projects that still need to do work for SQLAlchemy 2.0, but I don't know how >>>> likely it is that we can land all of these in the next week. >>> I agree this is the preferable option... and if we had a couple extra >>> weeks to make it happen I would pick it without hesitation... >>> >>> Here I feel to make it happen in time for the Zed release we'll need to >>> get someone to post all the autocommit option patches and potentially >>> the TC stepping in to authorize the TaCT team to force-approve the ones >>> that would not get attention from their core teams in time. >> I did those yesterday. >> >> Aodh: https://review.opendev.org/c/openstack/aodh/+/855962 >> Designate: https://review.opendev.org/c/openstack/designate/+/855965 >> Manila: https://review.opendev.org/c/openstack/manila/+/855967 >> Ironic: https://review.opendev.org/c/openstack/ironic/+/855969 >> Heat: https://review.opendev.org/c/openstack/heat/+/855970 >> Barbican: https://review.opendev.org/c/openstack/barbican/+/855972 >> >> The barbican one isn't correct and I need to respin it. The rest are working as >> expected though, as proven at [1]. > Actually, the barbican change isn't working because it isn't needed: Barbican > (helpfully) doesn't rely on autocommit. If we can get those other 5 patches > merged + the placement patch from gibi, we should have no issues with oslo.db > 12.1.0. They're not long-term fixes and more bandaid solutions but they'll tide > us over until these projects can rework their DB layers to be SQLAlchemy 2.0 > compatible in Antelope. > > Stephen > >> Stephen >> >> [1] https://review.opendev.org/c/openstack/requirements/+/855973/ >> >>>>> 2) revert the breaking change [2] and do another release in oslo.db now >>>>> without it (and add it back after Zed release & release oslo.db with it as >>>>> soon as possible in Antelope cycle) >>>>> ???? as far as we understand this does not cause any issue for those who >>>>> already adapted to oslo.db 12.1.0, so this should not be painful >>>> This is all true, but it doesn't actually fix anything and delays the necessary >>>> work to get us moving in the right direction. I've been harping on about the >>>> fact that SQLAlchemy 2.0 is coming and will affect many projects for over a year >>>> now [2] so perhaps a small but firm nudge like this would be beneficial and get >>>> things rolling moving into Antelope? >>> I agree it's a step back without guarantee that things would go a lot >>> better in the Antelope redo... but it is a more controlled path. >>> >>> I'd say we should see if we can get critical attention on this in the >>> next couple of days, and if not we can use option (2) as a plan B ? >>> > From thierry at openstack.org Tue Sep 6 15:31:59 2022 From: thierry at openstack.org (Thierry Carrez) Date: Tue, 6 Sep 2022 17:31:59 +0200 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 In-Reply-To: <0f3c8ad2-e07b-b2ec-16e9-9fc215f8f493@est.tech> References: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> <0f3c8ad2-e07b-b2ec-16e9-9fc215f8f493@est.tech> Message-ID: El?d Ill?s wrote: > Thanks Stephen for working on this! If those patches get merged *and* > nothing else is needed, then Option 1 seems to be the better solution. It looks like they are all getting good review traction, so this is looking good. -- Thierry Carrez (ttx) From ces.eduardo98 at gmail.com Tue Sep 6 16:09:02 2022 From: ces.eduardo98 at gmail.com (Carlos Silva) Date: Tue, 6 Sep 2022 13:09:02 -0300 Subject: [manila] Bugsquash postponed by one week Message-ID: Hello, Zorillas! I'm sending this email to inform you that the bugsquash we planned for this week will be postponed by one week. We currently have some FFEs and we could use the change owners and reviewers energy to get those changes moving forward. We hope to have the FFE changes merged by the end of this week, so next week we could use some focus time on the bugsquash. Regards, carloss -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.urdin at binero.com Tue Sep 6 16:28:42 2022 From: tobias.urdin at binero.com (Tobias Urdin) Date: Tue, 6 Sep 2022 16:28:42 +0000 Subject: [all] [oslo.messaging] Interest in collaboration on a NATS driver In-Reply-To: References: <52AA12A0-AE67-4EF7-B924-DE1F2873B909@binero.com> <0E347D5A-967D-42E3-AC00-56034907053B@binero.com> Message-ID: <8F7F790F-0F5C-4257-845A-1BCE671AF844@binero.com> Great! I?ve updated the agenda with NATS driver and eventlet future topic https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting See you in the next meeting on 12th of September 15:00 UTC hopefully that will give us all some time to read through the following material: - Current POC code https://review.opendev.org/c/openstack/oslo.messaging/+/848338 - Devstack plugin https://github.com/tobias-urdin/devstack-plugin-nats - Discussion on IRC on 2nd September about below links https://meetings.opendev.org/irclogs/%23openstack-oslo/%23openstack-oslo.2022-09-02.log.html Links to old material: - The old spec that we can work upon https://review.opendev.org/c/openstack/oslo-specs/+/692784 - Old driver implementation for above old spec https://review.opendev.org/c/openstack/oslo.messaging/+/680629 - Old asyncio planning https://wiki.openstack.org/wiki/Oslo/blueprints/asyncio - Old asyncio executor in oslo.messaging https://blueprints.launchpad.net/oslo.messaging/+spec/asyncio-executor - Old messaging API mail thread https://lists.openstack.org/pipermail/openstack-dev/2013-May/009784.html Looking forward to talk to you all next monday! Best regards Tobias On 5 Sept 2022, at 12:48, Herve Beraud > wrote: Le lun. 5 sept. 2022 ? 10:00, Tobias Urdin > a ?crit : Thanks! It seems that we have some traction here to get started in a more structured manner. I?m on PTO today but back tomorrow, what do people feel about scheduling a recurring meeting about this topic? The weekly Oslo meeting could host the conversation through a dedicated topic. https://wiki.openstack.org/wiki/Meetings/Oslo You could modify the meeting agenda to add this topic. Daniel Bengtsson (damani) is our meeting facilitator. Do not hesitate to ping him to discuss the meeting management. I still need to read through the old spec and old implementation of NATS, and I am a bit restricted on time currently but we could brainstorm in that meeting and get us started on a new/updated the other spec. Should also note that, to anybody interested, that the topic is a little bit more broader than just a new messaging driver as it includes planning and/or working around the usage of eventlet etc, if you are interested in that topic please also reach out to us! Best regards Tobias > On 2 Sept 2022, at 10:35, Felix H?ttner > wrote: > > +1, we would also be interested in helping out. Let me know where we can help out with reviews, writing code, testing, etc. > > -- > Felix Huettner > >> +1, I'm also interested in this topic. I did some tests with nats-py to see how it works and I'm volunteering to go further with this technology. >> Let me know if you need reviews, help etc... >> >> Le jeu. 1 sept. 2022 ? 15:50, Tobias Urdin > a ?crit : >> Hello Kai, >> >> Great to hear that you're interested! >> I'm currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first). >> >> Best regards >> Tobias >> >>> On 30 Aug 2022, at 18:32, Kai Bojens > wrote: >>> >>> Am 29.08.22 um 15:46 schrieb Tobias Urdin: >>> >>>> If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to >>>> reach out. I'm hoping somebody will bite but atleast I've put it out there for all of you. >>> >>> Hi, >>> I am very much interested to take a closer look at your work and maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack. >>> >>> As I'm pretty new to the messaging topic and had just heard of NATS and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ. >>> >>> This brings me to the most important question: Where do you run and test your code? >>> >>> Greetings, >>> Kai > > Diese E Mail enth?lt m?glicherweise vertrauliche Inhalte und ist nur f?r die Verwertung durch den vorgesehenen Empf?nger bestimmt. Sollten Sie nicht der vorgesehene Empf?nger sein, setzen Sie den Absender bitte unverz?glich in Kenntnis und l?schen diese E Mail. Hinweise zum Datenschutz finden Sie hier>. -- Herv? Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From atharvadhanvate at gmail.com Tue Sep 6 16:58:57 2022 From: atharvadhanvate at gmail.com (Atharva Dhanwate) Date: Tue, 6 Sep 2022 22:28:57 +0530 Subject: Horizon Message-ID: <28525294-20AC-400C-B4C0-E0BFDE8B74A6@hxcore.ol> An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Tue Sep 6 18:03:32 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 6 Sep 2022 18:03:32 +0000 Subject: [horizon] New contributor In-Reply-To: <28525294-20AC-400C-B4C0-E0BFDE8B74A6@hxcore.ol> References: <28525294-20AC-400C-B4C0-E0BFDE8B74A6@hxcore.ol> Message-ID: <20220906180331.g5aifdc663vxp56p@yuggoth.org> [I'm keeping you in Cc since it appears you're not subscribed to this mailing list, but please remember to always reply to the list.] On 2022-09-06 22:28:57 +0530 (+0530), Atharva Dhanwate wrote: > My name is Atharva Dhanwate. I am currently a university student. > I would love to contribute to the Horizon component of OpenStack > as part of my Open-Source Cloud computing project, particularly on > enhancement features such as #1864996. Welcome! It looks like you're referring to https://launchpad.net/bugs/1864996 "Notification about approaching session timeout" specifically? > My GitHub id is https://github.com/anonymous-baaka. I seek your > approval to be a part of the OpenStack developer community by > providing contributions to the repository. Be aware that OpenStack development happens in the OpenDev Collaboratory (not on GitHub), and nobody needs permission to propose changes which implement new features or bug fixes. Anyone can contribute to OpenStack projects. Please see The OpenStack Contributor Guide for detailed information on the workflow and how our community interacts to deliver the software, and feel free to ask questions here on the openstack-discuss mailing list: https://docs.openstack.org/contributors/ -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From manchandavishal143 at gmail.com Tue Sep 6 18:10:46 2022 From: manchandavishal143 at gmail.com (vishal manchanda) Date: Tue, 6 Sep 2022 23:40:46 +0530 Subject: Horizon In-Reply-To: <28525294-20AC-400C-B4C0-E0BFDE8B74A6@hxcore.ol> References: <28525294-20AC-400C-B4C0-E0BFDE8B74A6@hxcore.ol> Message-ID: Hi Atharva, Thanks for showing interest in the horizon project. You can go through the horizon contribution guide [1], and [2] to know the basic code structure and how to contribute. For any further help, you can reach out to me and the horizon team on the openstack-horizon channel on IRC at OFTC n/w. Thanks & Regards, Vishal Manchanda [1] https://docs.openstack.org/horizon/latest/contributor/index.html [2] https://docs.openstack.org/contributors/ On Tue, Sep 6, 2022 at 11:24 PM Atharva Dhanwate wrote: > Dear Moderator, > > My name is Atharva Dhanwate. I am currently a university student. I would > love to contribute to the Horizon component of OpenStack as part of my > Open-Source Cloud computing project, particularly on enhancement features > such as #1864996 . My > GitHub id is https://github.com/anonymous-baaka > . > > > > I seek your approval to be a part of the OpenStack developer community by > providing contributions to the repository. > > > > Thank you. Regards. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy at demarco.com Tue Sep 6 18:16:14 2022 From: amy at demarco.com (Amy Marrich) Date: Tue, 6 Sep 2022 13:16:14 -0500 Subject: Horizon In-Reply-To: <28525294-20AC-400C-B4C0-E0BFDE8B74A6@hxcore.ol> References: <28525294-20AC-400C-B4C0-E0BFDE8B74A6@hxcore.ol> Message-ID: Hi and welcome! We host our code on opendev.org and you can find the Horizon repo here - https://opendev.org/openstack/horizon The following are links to the onboarding guide for new contributors as well as a link to the Horizon project which contains more specific information. https://docs.openstack.org/contributors/ https://docs.openstack.org/horizon/latest/ Welcome to the community! Amy On Tue, Sep 6, 2022 at 1:08 PM Atharva Dhanwate wrote: > Dear Moderator, > > My name is Atharva Dhanwate. I am currently a university student. I would > love to contribute to the Horizon component of OpenStack as part of my > Open-Source Cloud computing project, particularly on enhancement features > such as #1864996 . My > GitHub id is https://github.com/anonymous-baaka > . > > > > I seek your approval to be a part of the OpenStack developer community by > providing contributions to the repository. > > > > Thank you. Regards. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdratlif at globalnoc.iu.edu Tue Sep 6 20:57:18 2022 From: jdratlif at globalnoc.iu.edu (John Ratliff) Date: Tue, 06 Sep 2022 16:57:18 -0400 Subject: [horizon] instance filtering dropdown default Message-ID: When I load certain pages in horizon, like the compute instances page, the default filter is "Instance ID". How can I change the default to "Instance Name" instead? Thanks. --John Ratliff -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5598 bytes Desc: not available URL: From jay at gr-oss.io Tue Sep 6 21:11:54 2022 From: jay at gr-oss.io (Jay Faulkner) Date: Tue, 6 Sep 2022 14:11:54 -0700 Subject: [election][Ironic] PTL Candidacy Message-ID: Hi all, I wanted to let you know I'm running for PTL of Ironic for the Antelope cycle. You can read my candidate statement[1] for full information, but feel free to ask me any questions you'd like here if you have them. Thanks, Jay Faulkner [1] - https://governance.openstack.org/election/#antelope-ptl-candidates -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at bakeyournoodle.com Tue Sep 6 23:04:53 2022 From: tony at bakeyournoodle.com (Tony Breeds) Date: Wed, 7 Sep 2022 09:04:53 +1000 Subject: [election][Requirements] PTL candidacy In-Reply-To: <20220906121205.wsvmsfwj6aq5t7mh@yuggoth.org> References: <20220905212143.ennkg62brej4ork2@mthode.org> <20220905213355.doauyoh5v2itn657@yuggoth.org> <20220905223948.747dah7efj4osov3@mthode.org> <20220906121205.wsvmsfwj6aq5t7mh@yuggoth.org> Message-ID: Yup It's a solution for this election. Nice work On Tue, 6 Sept 2022 at 22:17, Jeremy Stanley wrote: > > On 2022-09-06 11:26:10 +1000 (+1000), Tony Breeds wrote: > > Yeah we need to update the election code to handle teams that are > > under distributed leadership. > > > > Something for the next cycle. > [...] > > https://review.opendev.org/855981 looks like an attempt at a > workaround. > -- > Jeremy Stanley -- Yours Tony. From katonalala at gmail.com Wed Sep 7 07:25:46 2022 From: katonalala at gmail.com (Lajos Katona) Date: Wed, 7 Sep 2022 09:25:46 +0200 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 In-Reply-To: References: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> <0f3c8ad2-e07b-b2ec-16e9-9fc215f8f493@est.tech> Message-ID: Hi, Thanks for working on this, we discussed this topic yesterday on Neutron CI meeting (see [0]). For the flapping oslo-master job in Neutron we have a fix thanks to Miguel, and we are waiting for the experimental results (we plan a few runs to see if it is stable enough). So I hope we are close to saying a definite answer from Neutron perspective. Lajos [0]: https://meetings.opendev.org/meetings/neutron_ci/2022/neutron_ci.2022-09-06-15.00.log.html#l-109 Thierry Carrez ezt ?rta (id?pont: 2022. szept. 6., K, 17:56): > El?d Ill?s wrote: > > Thanks Stephen for working on this! If those patches get merged *and* > > nothing else is needed, then Option 1 seems to be the better solution. > > It looks like they are all getting good review traction, so this is > looking good. > > -- > Thierry Carrez (ttx) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will at stackhpc.com Wed Sep 7 08:58:36 2022 From: will at stackhpc.com (William Szumski) Date: Wed, 7 Sep 2022 09:58:36 +0100 Subject: [DIB][diskimage-builder] Rocky Linux image build method In-Reply-To: <20220802115553.wdjf2exi7ve7yq6t@yuggoth.org> References: <20220802115553.wdjf2exi7ve7yq6t@yuggoth.org> Message-ID: I've proposed a change to make a more feature complete rocky element here: https://review.opendev.org/c/openstack/diskimage-builder/+/855521. I was trying to make an image that is compatible with the officially distributed generic cloud images. It is essentially just layering on some additional packages on top of the rocky-container element. Would love to have some more feedback. On Tue, 2 Aug 2022 at 13:08, Jeremy Stanley wrote: > On 2022-08-02 12:17:58 +1000 (+1000), Ian Wienand wrote: > [...] > > In terms of having your dependencies available in final images, > > nothing really beats specifying them explicitly. Something like [1]. > > I think I'd encourage this rather than trying to add another platform > > to support in dib. > [...] > > And, just to be clear, in OpenDev our goal is to have only the > things necessary to start the VM and connect with Ansible. We do > also cache some expensive-to-retrieve things like Git repositories > and files nearly every job is otherwise going to try to fetch over > the network into these images, in order to improve job startup times > and stability, but job-specific or project-specific dependencies > should be explicitly installed by the jobs themselves. > -- > Jeremy Stanley > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Wed Sep 7 09:35:44 2022 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Wed, 7 Sep 2022 11:35:44 +0200 Subject: [DIB][diskimage-builder] Rocky Linux image build method In-Reply-To: References: <20220802115553.wdjf2exi7ve7yq6t@yuggoth.org> Message-ID: One thing to note is that Rocky cloud images are unofficial or, as they phrase it, "not officially supported" [1] which boils down to the same thing IMHO... I agree with Ian that it is probably enough that downstreams support their customised flavours as there is no set-in-stone guideline how a cloud image should look like. [1] https://rockylinux.org/alternative-images Cheers, Radek On Wed, 7 Sept 2022 at 11:05, William Szumski wrote: > > I've proposed a change to make a more feature complete rocky element here: https://review.opendev.org/c/openstack/diskimage-builder/+/855521. I was trying to make an image that is compatible with the officially distributed generic cloud images. It is essentially just layering on some additional packages on top of the rocky-container element. Would love to have some more feedback. > > On Tue, 2 Aug 2022 at 13:08, Jeremy Stanley wrote: >> >> On 2022-08-02 12:17:58 +1000 (+1000), Ian Wienand wrote: >> [...] >> > In terms of having your dependencies available in final images, >> > nothing really beats specifying them explicitly. Something like [1]. >> > I think I'd encourage this rather than trying to add another platform >> > to support in dib. >> [...] >> >> And, just to be clear, in OpenDev our goal is to have only the >> things necessary to start the VM and connect with Ansible. We do >> also cache some expensive-to-retrieve things like Git repositories >> and files nearly every job is otherwise going to try to fetch over >> the network into these images, in order to improve job startup times >> and stability, but job-specific or project-specific dependencies >> should be explicitly installed by the jobs themselves. >> -- >> Jeremy Stanley From stephenfin at redhat.com Wed Sep 7 10:11:29 2022 From: stephenfin at redhat.com (Stephen Finucane) Date: Wed, 07 Sep 2022 11:11:29 +0100 Subject: [election][Glance] PTL Candidacy for Antelope In-Reply-To: References: Message-ID: On Tue, 2022-09-06 at 14:05 +0530, Pranali Deore wrote: > Hello everyone, > > I would like to let you know that?I will be PTL?of Glance project for the > Antelope cycle. > > I have been working closely with the previous PTL, Abhishek, since last cycle > and I am hoping to contribute back to the community as a PTL while following > his excellent example. > > The following will be my goals for Antelope cycle: > > 1. Bridge gap between python-glanceclient and openstackclient > ? ? The CLI support for all glance APIS is already there in GlanceClient and > the similar CLI? > ? ? support we need to have in OpenstackClient for the missing Glance APIs in > this? > ? ? upcoming cycle. It would be great to see this as a goal. I know that CERN (hi Arne o/) are interested in contributing to this effort and it would be great to have you working together on this. Stephen > > 2. Default Glance to configure multiple stores? ?? > ? ? Glance has deprecated single stores configuration since Stein cycle and > will remove the? > ? ? support of the same in the upcoming cycle. > > 3. Secure RBAC? ? ? > ? ? ?In Xena we have managed to move all policy checks to API layer and > implemented > ? ? ?project scope of metadef APIs. As per the revised community goal, in zed > cycle we have? ? ? ? ? ? ?made all policy rules set scope_types=['project'] > for all project resources?that have already? ? ? ? ?implemented scope. Now we > need to have manager role support once it's fully implemented? ? ? ?in > Keystone. > > 4. Community priorities? ? ? > ? ? ?Whatever community goals put forward by TC, as a PTL of Glance project > will > ? ? ?want to adopt these as a priority for the Antelope cycle. > > 5. Other > ? ? As we are very short team at this moment, I would like to put some efforts > ? ? in attracting some contributors, help them to understand how Glance > ? ? functions and encourage them to contribute for Glance. > > Looking at how Abhishek, Erno and Brian have steadied the ship, I know it's > a big task and with their help I will do my best not to fail the expectations. > > > Thank you for consideration, > > Pranali Deore (pdeore) From senrique at redhat.com Wed Sep 7 11:00:00 2022 From: senrique at redhat.com (Sofia Enriquez) Date: Wed, 7 Sep 2022 08:00:00 -0300 Subject: [cinder] Bug Report - 08-31-2022 - 09-07-2022 Message-ID: This is a bug report from 08-31-2022 to 09-07-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Low - https://bugs.launchpad.net/cinder/+bug/1988317 "Remove IET iSCSI target." Unassigned. Wishlist - https://bugs.launchpad.net/cinder/+bug/1988803 "With image-volume cache enabled backend, volume creation for a smaller volume than image-volume cache has the same size of the image-volume cache." Unassigned. Cheers, Sofia -- Sof?a Enriquez she/her Software Engineer Red Hat PnT IRC: @enriquetaso @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From arne.wiebalck at cern.ch Wed Sep 7 12:01:47 2022 From: arne.wiebalck at cern.ch (Arne Wiebalck) Date: Wed, 7 Sep 2022 14:01:47 +0200 Subject: [election][Glance] PTL Candidacy for Antelope In-Reply-To: Message-ID: <6f35491e-f7fc-497f-b4eb-27f3b2b9deea@email.android.com> An HTML attachment was scrubbed... URL: From stephenfin at redhat.com Wed Sep 7 12:13:31 2022 From: stephenfin at redhat.com (Stephen Finucane) Date: Wed, 07 Sep 2022 13:13:31 +0100 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 In-Reply-To: References: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> <0f3c8ad2-e07b-b2ec-16e9-9fc215f8f493@est.tech> Message-ID: <414b69df992ce67768b9612dbec94ec366d675e3.camel@redhat.com> On Tue, 2022-09-06 at 17:31 +0200, Thierry Carrez wrote: > El?d Ill?s wrote: > > Thanks Stephen for working on this! If those patches get merged *and* > > nothing else is needed, then Option 1 seems to be the better solution. > > It looks like they are all getting good review traction, so this is > looking good. Yeah, these are all merged now. I just rechecked the requirements patch. That should be green soon. Stephen From adivya1.singh at gmail.com Wed Sep 7 12:20:35 2022 From: adivya1.singh at gmail.com (Adivya Singh) Date: Wed, 7 Sep 2022 17:50:35 +0530 Subject: Designate Installation in Openstack Message-ID: Hi Team, Any idea, what user variables we need to create in user_variables, for it to pick in Openstack Configuration using ansible. Regards Adivya Singh -------------- next part -------------- An HTML attachment was scrubbed... URL: From elod.illes at est.tech Wed Sep 7 12:57:24 2022 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Wed, 7 Sep 2022 14:57:24 +0200 Subject: [horizon][QA][release] Cycle With Intermediary without recent deliverables Message-ID: Hi, Quick reminder that for deliverables following the cycle-with-intermediary model, the release team will use the latest Zed release available on release week. The following deliverables have done a Zed release, but it was not refreshed in the last two months: ?horizon ?tempest You should consider making a new one very soon, so that we don't use an outdated version for the final release. El?d Ill?s irc: elodilles From abishop at redhat.com Wed Sep 7 12:59:01 2022 From: abishop at redhat.com (Alan Bishop) Date: Wed, 7 Sep 2022 05:59:01 -0700 Subject: [oslo][tooz] Feature Freeze exception request Message-ID: I'd like to request an exception for https://review.opendev.org/c/openstack/releases/+/856128. This patch proposes a new tooz release for the purpose of picking up [1], which fixes a bug [2] (it's not a feature, per se) that otherwise prevents tooz's etcd3gw driver from working with recent versions of etcd. The issue was initially observed back in 2020 [3]. [1] https://review.opendev.org/c/openstack/tooz/+/827492 [2] https://bugs.launchpad.net/python-tooz/+bug/1983668 [3] https://github.com/dims/etcd3-gateway/issues/41#issuecomment-673558108 Thank you for your consideration, Alan Bishop (abishop) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hberaud at redhat.com Wed Sep 7 13:15:38 2022 From: hberaud at redhat.com (Herve Beraud) Date: Wed, 7 Sep 2022 15:15:38 +0200 Subject: [oslo][tooz][requirements][release] Feature Freeze exception request and RFE request In-Reply-To: References: Message-ID: WFM Let me add the releases and the requirements teams in the topic of this thread to also request the RFE. Le mer. 7 sept. 2022 ? 15:05, Alan Bishop a ?crit : > I'd like to request an exception for > https://review.opendev.org/c/openstack/releases/+/856128. > > This patch proposes a new tooz release for the purpose of picking up [1], > which fixes a bug [2] (it's not a feature, per se) that otherwise prevents > tooz's etcd3gw driver from working with recent versions of etcd. The issue > was initially observed back in 2020 [3]. > > [1] https://review.opendev.org/c/openstack/tooz/+/827492 > [2] https://bugs.launchpad.net/python-tooz/+bug/1983668 > [3] https://github.com/dims/etcd3-gateway/issues/41#issuecomment-673558108 > > Thank you for your consideration, > > Alan Bishop (abishop) > -- Herv? Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From manchandavishal143 at gmail.com Wed Sep 7 14:00:49 2022 From: manchandavishal143 at gmail.com (vishal manchanda) Date: Wed, 7 Sep 2022 19:30:49 +0530 Subject: [horizon][QA][release] Cycle With Intermediary without recent deliverables In-Reply-To: References: Message-ID: Hi El?d, ack, thanks for the reminder. I am planning to do a final release of the horizon around R-2 week(Sep 19 - Sep 23). Regards, Vishal Manchanda On Wed, Sep 7, 2022 at 6:32 PM El?d Ill?s wrote: > Hi, > > Quick reminder that for deliverables following the cycle-with-intermediary > model, the release team will use the latest Zed release available on > release week. > > The following deliverables have done a Zed release, but it was not > refreshed in the last two months: > > horizon > tempest > > You should consider making a new one very soon, so that we don't use an > outdated version for the final release. > > > El?d Ill?s > irc: elodilles > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erkki at peurat.net Wed Sep 7 14:08:51 2022 From: erkki at peurat.net (ETP) Date: Wed, 07 Sep 2022 17:08:51 +0300 Subject: [neutron] [openvswich-agent] Driver for security groups Message-ID: <91A6B3A6-F0B5-4118-ADAA-4D84A6170D3A@peurat.net> Hi, what is the recommended openvswich agent driver for security groups?? Two options on my table are now OVS native firewall driver vs. OVSHybridIptablesFirewall driver Br, ? ? - Eki - -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay at gr-oss.io Wed Sep 7 14:31:08 2022 From: jay at gr-oss.io (Jay Faulkner) Date: Wed, 7 Sep 2022 07:31:08 -0700 Subject: [elections][tc] I'm running for TC Message-ID: Hello, I wanted to announce I'm running for TC in the upcoming election. Please take a look at my candidate statement if you want some insight into my motivations and how I'd approach the position: https://opendev.org/openstack/election/raw/branch/master/candidates/antelope/TC/jay%40jvf.cc . If you have any questions for me, feel free to ask them here. Thanks, Jay Faulkner -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephenfin at redhat.com Wed Sep 7 14:38:37 2022 From: stephenfin at redhat.com (Stephen Finucane) Date: Wed, 07 Sep 2022 15:38:37 +0100 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 In-Reply-To: <414b69df992ce67768b9612dbec94ec366d675e3.camel@redhat.com> References: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> <0f3c8ad2-e07b-b2ec-16e9-9fc215f8f493@est.tech> <414b69df992ce67768b9612dbec94ec366d675e3.camel@redhat.com> Message-ID: On Wed, 2022-09-07 at 13:13 +0100, Stephen Finucane wrote: > On Tue, 2022-09-06 at 17:31 +0200, Thierry Carrez wrote: > > El?d Ill?s wrote: > > > Thanks Stephen for working on this! If those patches get merged *and* > > > nothing else is needed, then Option 1 seems to be the better solution. > > > > It looks like they are all getting good review traction, so this is > > looking good. > > Yeah, these are all merged now. I just rechecked the requirements patch. That > should be green soon. This is now green. https://review.opendev.org/c/openstack/requirements/+/855153 Stephen From james.denton at rackspace.com Wed Sep 7 14:43:12 2022 From: james.denton at rackspace.com (James Denton) Date: Wed, 7 Sep 2022 14:43:12 +0000 Subject: Designate Installation in Openstack In-Reply-To: References: Message-ID: Hi Adivya, Designate can be one of the more complicated services to deploy, since there are some external dependencies (ie. an external DNS server). To simply *deploy* Designate within OpenStack-Ansible, you?ll need to define a ?dnsaas_hosts? group within the openstack_user_config.yml file, like so: ````` dnsaas_hosts: controller01: ip: 172.29.236.22 controller02: ip: 172.29.236.23 controller03: ip: 172.29.236.24 ````` Satish Patel (spatel on OFTC IRC - #openstack-ansible) has written a great guide geared towards Designate with OSA and PowerDNS: https://satishdotpatel.github.io/designate-integration-with-powerdns/ Hope that helps! James -- James Denton Principal Architect Rackspace Private Cloud - OpenStack james.denton at rackspace.com From: Adivya Singh Date: Wednesday, September 7, 2022 at 7:46 AM To: OpenStack Discuss Subject: Designate Installation in Openstack CAUTION: This message originated externally, please use caution when clicking on links or opening attachments! Hi Team, Any idea, what user variables we need to create in user_variables, for it to pick in Openstack Configuration using ansible. Regards Adivya Singh -------------- next part -------------- An HTML attachment was scrubbed... URL: From helena at openstack.org Wed Sep 7 15:33:07 2022 From: helena at openstack.org (Helena Spease) Date: Wed, 7 Sep 2022 10:33:07 -0500 Subject: Join the OpenStack Community in Vancouver for the OpenInfra Summit! Message-ID: <75B524EB-B7AE-4515-ABE0-AE017CD435A0@openstack.org> Hi Everyone, Registration and sponsorships for the OpenInfra Summit Vancouver [1] are now open! This is your chance to collaborate directly with the people building and running OpenStack. Mark your calendars for June 13-15, 2023 and register early [2] to save your seat! Find information on sponsorships[3], the Summit travel support program[4], visa requirements[5], and track chair nominations[6]. Stay tuned for November when the Call for Presentations opens! Cheers, Helena [1] https://openinfra.dev/summit/vancouver-2023 [2] https://openinfrasummit2023.eventbrite.com/ [3] http://openinfra.dev/summit/vancouver-2023/summit-sponsor/ [4] https://openinfrafoundation.formstack.com/forms/openinfra_tsp [5] https://openinfrafoundation.formstack.com/forms/visa_yvrsummit2023 [6] https://openinfrafoundation.formstack.com/forms/trackchairnominations2023 From dwilde at redhat.com Wed Sep 7 16:00:45 2022 From: dwilde at redhat.com (Dave Wilde) Date: Wed, 7 Sep 2022 11:00:45 -0500 Subject: [elections][Keystone] PTL Candidacy for Antelope Message-ID: Hello all, I would like to let you know that I will be running for the PTL of the Keystone project for the Antelope cycle. I have been working closely with the current PTL and core reviewers on our initiatives to improve the speed at which we review code submissions and get things merged. I would like to continue focusing on this and continue to build momentum. I look forward to contributing back to the community and Keystone in general and would like to thank Douglas Mendiz?bal for his work and leadership. Thank you, -- /Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafaelweingartner at gmail.com Wed Sep 7 17:23:14 2022 From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=) Date: Wed, 7 Sep 2022 14:23:14 -0300 Subject: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number In-Reply-To: References: <2aa77e24a33d48a69032f30b86e9cad8@elca.ch> <1b17c23f8982480db73cf50d04d51af7@elca.ch> <86f048d7931c4cc482f6785437c9b5ea@elca.ch> Message-ID: Jean, there are two problems with the Ceilometer. I just opened the patches to resolve it: - https://review.opendev.org/c/openstack/ceilometer/+/856305 - https://review.opendev.org/c/openstack/ceilometer/+/856304 Without these patches, you might have problems to use Ceilometer with Non-OpenStack dynamic pollsters and barbican credentials. On Wed, Aug 31, 2022 at 3:55 PM Rafael Weing?rtner < rafaelweingartner at gmail.com> wrote: > It is the RGW user that you have. This user must have the role that is > needed to access the usage feature in RGW. If I am not mistaken, it > required an admin user. > > On Wed, Aug 31, 2022 at 1:54 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > >> Thanks to your help, I am close to the goal. Dynamic pollster is loaded >> and triggered. >> >> >> >> But I get a ?Status[403] and reason [Forbidden]? in ceilometer logs while >> requesting admin/usage. >> >> >> >> I?m not sure to understand well the auth mechanism. Are we talking about >> keystone credentials, ec2 credentials, Rados GW user ?... >> >> >> >> For now, in testing phase, I use ?authentication_parameters?, not >> barbican. >> >> >> >> -JF >> >> >> >> *From:* Rafael Weing?rtner >> *Sent:* mardi, 30 ao?t 2022 14:17 >> *To:* Taltavull Jean-Fran?ois >> *Cc:* openstack-discuss >> *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API >> endpoints are based on URL instead of port number >> >> >> >> >> >> *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. >> >> Yes, you will need to enable the metric/pollster to be processed. That is >> done via "polling.yml" file. Also, do not forget that you will need to >> configure Ceilometer to push this new metric. If you use Gnocchi as the >> backend, you will need to change/update the gnocchi resource YML file. That >> file maps resources and metrics in the Gnocchi backend. The configuration >> resides in Ceilometer. You can create/define new resource types and map >> them to specific metrics. It depends on how you structure your solution. >> >> P.S. You do not need to use "authentication_parameters". You can use the >> barbican integration to avoid setting your credentials in a file. >> >> >> >> On Tue, Aug 30, 2022 at 9:11 AM Taltavull Jean-Fran?ois < >> jean-francois.taltavull at elca.ch> wrote: >> >> Hello, >> >> >> >> I tried to define a Rados GW dynamic pollster and I can see, in >> Ceilometer logs, that it?s actually loaded. But it looks like it was not >> triggered, I see no trace of ceilometer connection in Rados GW logs. >> >> >> >> My definition: >> >> >> >> - name: "dynamic.radosgw.usage" >> >> sample_type: "gauge" >> >> unit: "B" >> >> value_attribute: "total.size" >> >> url_path: http:///object-store/swift/v1/admin/usage >> >> module: "awsauth" >> >> authentication_object: "S3Auth" >> >> authentication_parameters: xxxxxxxxxxxxx,yyyyyyyyyyyyy, >> >> user_id_attribute: "admin" >> >> project_id_attribute: "admin" >> >> resource_id_attribute: "admin" >> >> response_entries_key: "summary" >> >> >> >> Do I have to set an option in ceilometer.conf, or elsewhere, to get my >> Rados GW dynamic pollster triggered ? >> >> >> >> -JF >> >> >> >> *From:* Taltavull Jean-Fran?ois >> *Sent:* lundi, 29 ao?t 2022 18:41 >> *To:* 'Rafael Weing?rtner' >> *Cc:* openstack-discuss >> *Subject:* RE: [Ceilometer] Pollster cannot get RadosGW metrics when API >> endpoints are based on URL instead of port number >> >> >> >> Thanks a lot for your quick answer, Rafael ! >> >> I will explore this approach. >> >> >> >> Jean-Francois >> >> >> >> *From:* Rafael Weing?rtner >> *Sent:* lundi, 29 ao?t 2022 17:54 >> *To:* Taltavull Jean-Fran?ois >> *Cc:* openstack-discuss >> *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API >> endpoints are based on URL instead of port number >> >> >> >> >> >> *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. >> >> You could use a different approach. You can use Dynamic pollster [1], and >> create your own mechanism to collect data, without needing to change >> Ceilometer code. Basically all hard-coded pollsters can be converted to a >> dynamic pollster that is defined in YML. >> >> >> >> [1] >> https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollster.html#the-dynamic-pollsters-system-configuration-for-non-openstack-apis >> >> >> >> >> >> On Mon, Aug 29, 2022 at 12:51 PM Taltavull Jean-Fran?ois < >> jean-francois.taltavull at elca.ch> wrote: >> >> Hi All, >> >> In our OpenStack deployment, API endpoints are defined by using URLs >> instead of port numbers and HAProxy forwards requests to the right bakend >> after having ACLed the URL. >> >> In the case of our object-store service, based on RadosGW, the internal >> API endpoint is "https:///object-store/swift/v1/AUTH_" >> >> When Ceilometer RadosGW pollster tries to connect to the RadosGW admin >> API with the object-store internal endpoint, the URL becomes >> https:///admin, as shown by HAProxy logs. This URL does not match >> any API endpoint from HAProxy point of view. The line of code that rewrites >> the URL is this one: >> https://opendev.org/openstack/ceilometer/src/branch/stable/wallaby/ceilometer/objectstore/rgw.py#L81 >> >> What would you think of adding a mechanism based on new Ceilometer >> configuration option(s) to control the URL rewriting ? >> >> Our deployment characteristics: >> - OpenStack release: Wallaby >> - Ceph and RadosGW version: 15.2.16 >> - deployment tool: OSA 23.2.1 and ceph-ansible >> >> >> Best regards, >> Jean-Francois >> >> >> >> -- >> >> Rafael Weing?rtner >> >> >> >> -- >> >> Rafael Weing?rtner >> > > > -- > Rafael Weing?rtner > -- Rafael Weing?rtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy at demarco.com Thu Sep 8 00:14:16 2022 From: amy at demarco.com (Amy Marrich) Date: Wed, 7 Sep 2022 19:14:16 -0500 Subject: [all][elections][ptl][tc] Combined PTL/TC antelope cycle Election Nominations End Message-ID: Please note we are in the process of adding a standalone TC Campaigning period before opening the TC election for voting. This will allow the candidates to answer any questions and also people to opt-in to the CIVS system before we start the voting process. Pending a patch being added and merged we are looking at starting the voting early to mid next week. Thanks, Amy +++++++++++++++++++++++++++++++++++++++++++++++++++ The PTL and TC Nomination period is now over. The official candidate lists for PTLs [0] and TC seats [1] are available on the election website. -- PTL Election Details -- There are 11 projects without candidates, so according to this resolution[2], the TC will have to decide how the following projects will proceed: Adjutant, Barbican, Keystone, Masakari, OpenStackSDK, OpenStack_Charms, Sahara, Senlin, Swift, Venus, Zun -- TC Election Details -- There are 1 projects that will have elections: Ironic. Now begins the campaigning period where candidates and electorate may debate their statements. Polling will start Sep 07, 2022 23:45 UTC. Thank you, [0] https://governance.openstack.org/election/#antelope-ptl-candidates [1] https://governance.openstack.org/election/#antelope-tc-candidates [2] https://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Thu Sep 8 06:41:54 2022 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 8 Sep 2022 08:41:54 +0200 Subject: [all] [oslo.messaging] Interest in collaboration on a NATS driver In-Reply-To: <8F7F790F-0F5C-4257-845A-1BCE671AF844@binero.com> References: <52AA12A0-AE67-4EF7-B924-DE1F2873B909@binero.com> <0E347D5A-967D-42E3-AC00-56034907053B@binero.com> <8F7F790F-0F5C-4257-845A-1BCE671AF844@binero.com> Message-ID: Hi Tobias et al, That Monday I cannot attend due to other work commitments. Could we schedule it for the following week? Cheers, Radek On Tue, Sep 6, 2022, 18:33 Tobias Urdin wrote: > Great! I?ve updated the agenda with NATS driver and eventlet future topic > https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting > > See you in the next meeting on 12th of September 15:00 UTC hopefully that > will give us all some time to read through the following material: > > - Current POC code > https://review.opendev.org/c/openstack/oslo.messaging/+/848338 > - Devstack plugin https://github.com/tobias-urdin/devstack-plugin-nats > - Discussion on IRC on 2nd September about below links > https://meetings.opendev.org/irclogs/%23openstack-oslo/%23openstack-oslo.2022-09-02.log.html > > > Links to old material: > - The old spec that we can work upon > https://review.opendev.org/c/openstack/oslo-specs/+/692784 > - Old driver implementation for above old spec > https://review.opendev.org/c/openstack/oslo.messaging/+/680629 > - Old asyncio planning > https://wiki.openstack.org/wiki/Oslo/blueprints/asyncio > - Old asyncio executor in oslo.messaging > https://blueprints.launchpad.net/oslo.messaging/+spec/asyncio-executor > - Old messaging API mail thread > https://lists.openstack.org/pipermail/openstack-dev/2013-May/009784.html > > Looking forward to talk to you all next monday! > > Best regards > Tobias > > On 5 Sept 2022, at 12:48, Herve Beraud wrote: > > > > Le lun. 5 sept. 2022 ? 10:00, Tobias Urdin a > ?crit : > >> Thanks! It seems that we have some traction here to get started in a more >> structured manner. >> >> I?m on PTO today but back tomorrow, what do people feel about scheduling >> a recurring meeting about this topic? > > > The weekly Oslo meeting could host the conversation through a dedicated > topic. > https://wiki.openstack.org/wiki/Meetings/Oslo > > You could modify the meeting agenda to add this topic. > Daniel Bengtsson (damani) is our meeting facilitator. Do not hesitate to > ping him to discuss the meeting management. > > >> I still >> need to read through the old spec and old implementation of NATS, and I >> am a bit restricted on time currently but we >> could brainstorm in that meeting and get us started on a new/updated the >> other spec. >> >> Should also note that, to anybody interested, that the topic is a little >> bit more broader than just a new messaging driver >> as it includes planning and/or working around the usage of eventlet etc, >> if you are interested in that topic please also >> reach out to us! >> >> Best regards >> Tobias >> >> > On 2 Sept 2022, at 10:35, Felix H?ttner >> wrote: >> > >> > +1, we would also be interested in helping out. Let me know where we >> can help out with reviews, writing code, testing, etc. >> > >> > -- >> > Felix Huettner >> > >> >> +1, I'm also interested in this topic. I did some tests with nats-py >> to see how it works and I'm volunteering to go further with this technology. >> >> Let me know if you need reviews, help etc... >> >> >> >> Le jeu. 1 sept. 2022 ? 15:50, Tobias Urdin > tobias.urdin at binero.com> a ?crit : >> >> Hello Kai, >> >> >> >> Great to hear that you're interested! >> >> I'm currently just testing this as a POC directly in devstack so there >> is real-world testing (not should it yet I think, needs more development >> first). >> >> >> >> Best regards >> >> Tobias >> >> >> >>> On 30 Aug 2022, at 18:32, Kai Bojens wrote: >> >>> >> >>> Am 29.08.22 um 15:46 schrieb Tobias Urdin: >> >>> >> >>>> If anybody, or any company, out there would be interested in >> collaborating in a project to bring this support and maintain it feel free >> to >> >>>> reach out. I'm hoping somebody will bite but atleast I've put it out >> there for all of you. >> >>> >> >>> Hi, >> >>> I am very much interested to take a closer look at your work and >> maybe contribute to it. Although I'm working with OpenStack for my employer >> at the moment, I'd do this in my spare time as I'm not sure that I can >> convince him to add another staging system with a full OpenStack >> installation just for developing a RabbitMQ replacement. That's not on our >> agenda as we are mostly users and not developers of OpenStack. >> >>> >> >>> As I'm pretty new to the messaging topic and had just heard of NATS >> and your idea, I'll first would have to dive into NATS and then I would >> take a closer look at your code and maybe try to create some documentation >> or tests. So, I can't promise anything but as I said I'm very interested in >> your approach as I also see the massive load from RabbitMQ. >> >>> >> >>> This brings me to the most important question: Where do you run and >> test your code? >> >>> >> >>> Greetings, >> >>> Kai >> > >> > Diese E Mail enth?lt m?glicherweise vertrauliche Inhalte und ist nur >> f?r die Verwertung durch den vorgesehenen Empf?nger bestimmt. Sollten Sie >> nicht der vorgesehene Empf?nger sein, setzen Sie den Absender bitte >> unverz?glich in Kenntnis und l?schen diese E Mail. Hinweise zum Datenschutz >> finden Sie hier. >> >> > > -- > Herv? Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > https://twitter.com/4383hberaud > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From katonalala at gmail.com Thu Sep 8 07:05:33 2022 From: katonalala at gmail.com (Lajos Katona) Date: Thu, 8 Sep 2022 09:05:33 +0200 Subject: [neutron] [openvswich-agent] Driver for security groups In-Reply-To: <91A6B3A6-F0B5-4118-ADAA-4D84A6170D3A@peurat.net> References: <91A6B3A6-F0B5-4118-ADAA-4D84A6170D3A@peurat.net> Message-ID: Hi, You have to consider your needs for selection. For example the hybrid driver has the extra iptables/nftables in the traffic loop, and for that you need an extra linuxbrdge between the instance port and the firewall (nftables or in the past iptables). The extra components give performance and scalability cost (see [0]) The OVS driver installs flows to br-int and that will do the filtering based on the security group rules defined on the API, so everything is done on OVS ports/bridges. No extra component in the traffic no extra cost. The bad things is that for first debugging and understanding ovs flows based rules not easy at first. [0]: https://docs.openstack.org/neutron/latest/admin/config-ovsfwdriver.html Best wishes Lajos Katona ETP ezt ?rta (id?pont: 2022. szept. 7., Sze, 16:28): > Hi, > > what is the recommended openvswich agent driver for security groups? > > Two options on my table are now OVS native firewall driver vs. > OVSHybridIptablesFirewall driver > > Br, > > - Eki - > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Thu Sep 8 07:27:46 2022 From: skaplons at redhat.com (Slawek Kaplonski) Date: Thu, 08 Sep 2022 09:27:46 +0200 Subject: [neutron] [openvswich-agent] Driver for security groups In-Reply-To: References: <91A6B3A6-F0B5-4118-ADAA-4D84A6170D3A@peurat.net> Message-ID: <2436925.ZP9T1jWYpz@p1> Hi, Dnia czwartek, 8 wrze?nia 2022 09:05:33 CEST Lajos Katona pisze: > Hi, > You have to consider your needs for selection. > For example the hybrid driver has the extra iptables/nftables in the > traffic loop, and for that you need an extra linuxbrdge between the > instance port and the firewall (nftables or in the past iptables). > The extra components give performance and scalability cost (see [0]) > The OVS driver installs flows to br-int and that will do the filtering > based on the security group rules defined on the API, so everything is done > on OVS ports/bridges. No extra component in the traffic no extra cost. > The bad things is that for first debugging and understanding ovs flows > based rules not easy at first. Additionally, there are some differences in the behavior of those 2 drivers - they are documented in [0]. Also, please note that e.g. security groups for the trunk ports and subports are only supported with openvswitch fw driver so if You want to use trunks with security groups, You have to choose openvswitch fw driver. > > [0]: https://docs.openstack.org/neutron/latest/admin/config-ovsfwdriver.html > > Best wishes > Lajos Katona > > ETP ezt ?rta (id?pont: 2022. szept. 7., Sze, 16:28): > > > Hi, > > > > what is the recommended openvswich agent driver for security groups? > > > > Two options on my table are now OVS native firewall driver vs. > > OVSHybridIptablesFirewall driver > > > > Br, > > > > - Eki - > > > > > -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From katonalala at gmail.com Thu Sep 8 09:15:05 2022 From: katonalala at gmail.com (Lajos Katona) Date: Thu, 8 Sep 2022 11:15:05 +0200 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 In-Reply-To: References: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> <0f3c8ad2-e07b-b2ec-16e9-9fc215f8f493@est.tech> <414b69df992ce67768b9612dbec94ec366d675e3.camel@redhat.com> Message-ID: Hi, For Neutron we still have 2 hanging patches to fix failing jobs: https://review.opendev.org/c/openstack/neutron/+/856444 https://review.opendev.org/c/openstack/neutron/+/855703 Lajos Katona (lajoskatona) Stephen Finucane ezt ?rta (id?pont: 2022. szept. 7., Sze, 17:00): > On Wed, 2022-09-07 at 13:13 +0100, Stephen Finucane wrote: > > On Tue, 2022-09-06 at 17:31 +0200, Thierry Carrez wrote: > > > El?d Ill?s wrote: > > > > Thanks Stephen for working on this! If those patches get merged > *and* > > > > nothing else is needed, then Option 1 seems to be the better > solution. > > > > > > It looks like they are all getting good review traction, so this is > > > looking good. > > > > Yeah, these are all merged now. I just rechecked the requirements patch. > That > > should be green soon. > > This is now green. > > https://review.opendev.org/c/openstack/requirements/+/855153 > > Stephen > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Thu Sep 8 09:24:14 2022 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 8 Sep 2022 11:24:14 +0200 Subject: [tc][ptl][election][masakari] I volunteer to become Masakari PTL again Message-ID: As in the topic - I saw Masakari did not receive a candidate and I don't want to see this project disappear so I volunteer to be the PTL. I don't have any major plans regarding Masakari except for keeping it afloat and working where it works already. Cheers, Radek -yoctozepto From tobias.urdin at binero.com Thu Sep 8 13:10:02 2022 From: tobias.urdin at binero.com (Tobias Urdin) Date: Thu, 8 Sep 2022 13:10:02 +0000 Subject: [all] [oslo.messaging] Interest in collaboration on a NATS driver In-Reply-To: References: <52AA12A0-AE67-4EF7-B924-DE1F2873B909@binero.com> <0E347D5A-967D-42E3-AC00-56034907053B@binero.com> <8F7F790F-0F5C-4257-845A-1BCE671AF844@binero.com> Message-ID: Hello, I don?t have anything against moving to the 19th of September meeting if that?s OK with everybody else, I propose we do that. Let?s see if we get some feedback against the proposed new date otherwise we?ll move it. Best regards On 8 Sept 2022, at 08:41, Rados?aw Piliszek > wrote: Hi Tobias et al, That Monday I cannot attend due to other work commitments. Could we schedule it for the following week? Cheers, Radek On Tue, Sep 6, 2022, 18:33 Tobias Urdin > wrote: Great! I?ve updated the agenda with NATS driver and eventlet future topic https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting See you in the next meeting on 12th of September 15:00 UTC hopefully that will give us all some time to read through the following material: - Current POC code https://review.opendev.org/c/openstack/oslo.messaging/+/848338 - Devstack plugin https://github.com/tobias-urdin/devstack-plugin-nats - Discussion on IRC on 2nd September about below links https://meetings.opendev.org/irclogs/%23openstack-oslo/%23openstack-oslo.2022-09-02.log.html Links to old material: - The old spec that we can work upon https://review.opendev.org/c/openstack/oslo-specs/+/692784 - Old driver implementation for above old spec https://review.opendev.org/c/openstack/oslo.messaging/+/680629 - Old asyncio planning https://wiki.openstack.org/wiki/Oslo/blueprints/asyncio - Old asyncio executor in oslo.messaging https://blueprints.launchpad.net/oslo.messaging/+spec/asyncio-executor - Old messaging API mail thread https://lists.openstack.org/pipermail/openstack-dev/2013-May/009784.html Looking forward to talk to you all next monday! Best regards Tobias On 5 Sept 2022, at 12:48, Herve Beraud > wrote: Le lun. 5 sept. 2022 ? 10:00, Tobias Urdin > a ?crit : Thanks! It seems that we have some traction here to get started in a more structured manner. I?m on PTO today but back tomorrow, what do people feel about scheduling a recurring meeting about this topic? The weekly Oslo meeting could host the conversation through a dedicated topic. https://wiki.openstack.org/wiki/Meetings/Oslo You could modify the meeting agenda to add this topic. Daniel Bengtsson (damani) is our meeting facilitator. Do not hesitate to ping him to discuss the meeting management. I still need to read through the old spec and old implementation of NATS, and I am a bit restricted on time currently but we could brainstorm in that meeting and get us started on a new/updated the other spec. Should also note that, to anybody interested, that the topic is a little bit more broader than just a new messaging driver as it includes planning and/or working around the usage of eventlet etc, if you are interested in that topic please also reach out to us! Best regards Tobias > On 2 Sept 2022, at 10:35, Felix H?ttner > wrote: > > +1, we would also be interested in helping out. Let me know where we can help out with reviews, writing code, testing, etc. > > -- > Felix Huettner > >> +1, I'm also interested in this topic. I did some tests with nats-py to see how it works and I'm volunteering to go further with this technology. >> Let me know if you need reviews, help etc... >> >> Le jeu. 1 sept. 2022 ? 15:50, Tobias Urdin > a ?crit : >> Hello Kai, >> >> Great to hear that you're interested! >> I'm currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first). >> >> Best regards >> Tobias >> >>> On 30 Aug 2022, at 18:32, Kai Bojens > wrote: >>> >>> Am 29.08.22 um 15:46 schrieb Tobias Urdin: >>> >>>> If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to >>>> reach out. I'm hoping somebody will bite but atleast I've put it out there for all of you. >>> >>> Hi, >>> I am very much interested to take a closer look at your work and maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack. >>> >>> As I'm pretty new to the messaging topic and had just heard of NATS and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ. >>> >>> This brings me to the most important question: Where do you run and test your code? >>> >>> Greetings, >>> Kai > > Diese E Mail enth?lt m?glicherweise vertrauliche Inhalte und ist nur f?r die Verwertung durch den vorgesehenen Empf?nger bestimmt. Sollten Sie nicht der vorgesehene Empf?nger sein, setzen Sie den Absender bitte unverz?glich in Kenntnis und l?schen diese E Mail. Hinweise zum Datenschutz finden Sie hier>. -- Herv? Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From gaspard.varennes at epitech.eu Thu Sep 8 08:21:49 2022 From: gaspard.varennes at epitech.eu (gaspard varennes) Date: Thu, 8 Sep 2022 08:21:49 +0000 Subject: Retirement process openstack/training-labs Message-ID: Hello, I found on https://lists.openstack.org/pipermail/openstack-discuss/2021-October/025586.html an email saying "If you are using it for your training please reply to this email pr ping us on #openstack-tc IRC OFTC channel otherwise we will start the retirement process." We (a digital school in France) are still using your training labs, so we write you this email. But we think the retirement process is already done because last commit of the repo https://opendev.org/openstack/training-labs.git is almost empty. I presume (but I'm not sure because I'm not a tech guy) that we still can use the previous version of the repo https://opendev.org/openstack/training-labs/src/commit/2585b12b879bae4c3fe48a846d1ba9d3de1e4b77 to train on the labs, am I right? Thank you very much for your time and consideration. Gaspard VARENNES Pedagogical Engineer Content Excellency Department Epitech LILLE 5/9 rue du palais Rihour 59000 LILLE 06 69 33 83 30 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Thu Sep 8 13:33:31 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 8 Sep 2022 13:33:31 +0000 Subject: Retirement process openstack/training-labs In-Reply-To: References: Message-ID: <20220908133330.cwp5mxjoetm5arhu@yuggoth.org> [I'm keeping you in Cc since you don't seem to be subscribed to the mailing list, but when replying please do so to the list address.] On 2022-09-08 08:21:49 +0000 (+0000), gaspard varennes wrote: [...] > I presume (but I'm not sure because I'm not a tech guy) that we > still can use the previous version of the repo > https://opendev.org/openstack/training-labs/src/commit/2585b12b879bae4c3fe48a846d1ba9d3de1e4b77 > to train on the labs, am I right? [...] Yes, that's correct, just be aware that it's increasingly out of date compared to the current state of OpenStack development: it was last refreshed in March 2020, and covers the OpenStack Train release from October 2019. Next month we're releasing Zed, which will be the 6th coordinated release since Train. It's also worth pointing out that repository retirement isn't permanent, and if there are contributors with sufficient interest and time to get the content back into shape and keep it maintained then it's possible to bring it back out of retirement fairly easily. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From hberaud at redhat.com Thu Sep 8 13:54:25 2022 From: hberaud at redhat.com (Herve Beraud) Date: Thu, 8 Sep 2022 15:54:25 +0200 Subject: [all] [oslo.messaging] Interest in collaboration on a NATS driver In-Reply-To: References: <52AA12A0-AE67-4EF7-B924-DE1F2873B909@binero.com> <0E347D5A-967D-42E3-AC00-56034907053B@binero.com> <8F7F790F-0F5C-4257-845A-1BCE671AF844@binero.com> Message-ID: WFM Le jeu. 8 sept. 2022 ? 15:16, Tobias Urdin a ?crit : > Hello, > > I don?t have anything against moving to the 19th of September meeting if > that?s OK > with everybody else, I propose we do that. > > Let?s see if we get some feedback against the proposed new date otherwise > we?ll move it. > > Best regards > > On 8 Sept 2022, at 08:41, Rados?aw Piliszek > wrote: > > Hi Tobias et al, > > That Monday I cannot attend due to other work commitments. Could we > schedule it for the following week? > > Cheers, > Radek > > On Tue, Sep 6, 2022, 18:33 Tobias Urdin wrote: > >> Great! I?ve updated the agenda with NATS driver and eventlet future topic >> https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting >> >> See you in the next meeting on 12th of September 15:00 UTC hopefully that >> will give us all some time to read through the following material: >> >> - Current POC code >> https://review.opendev.org/c/openstack/oslo.messaging/+/848338 >> - Devstack plugin https://github.com/tobias-urdin/devstack-plugin-nats >> - Discussion on IRC on 2nd September about below links >> https://meetings.opendev.org/irclogs/%23openstack-oslo/%23openstack-oslo.2022-09-02.log.html >> >> >> Links to old material: >> - The old spec that we can work upon >> https://review.opendev.org/c/openstack/oslo-specs/+/692784 >> - Old driver implementation for above old spec >> https://review.opendev.org/c/openstack/oslo.messaging/+/680629 >> - Old asyncio planning >> https://wiki.openstack.org/wiki/Oslo/blueprints/asyncio >> - Old asyncio executor in oslo.messaging >> https://blueprints.launchpad.net/oslo.messaging/+spec/asyncio-executor >> - Old messaging API mail thread >> https://lists.openstack.org/pipermail/openstack-dev/2013-May/009784.html >> >> Looking forward to talk to you all next monday! >> >> Best regards >> Tobias >> >> On 5 Sept 2022, at 12:48, Herve Beraud wrote: >> >> >> >> Le lun. 5 sept. 2022 ? 10:00, Tobias Urdin a >> ?crit : >> >>> Thanks! It seems that we have some traction here to get started in a >>> more structured manner. >>> >>> I?m on PTO today but back tomorrow, what do people feel about scheduling >>> a recurring meeting about this topic? >> >> >> The weekly Oslo meeting could host the conversation through a dedicated >> topic. >> https://wiki.openstack.org/wiki/Meetings/Oslo >> >> You could modify the meeting agenda to add this topic. >> Daniel Bengtsson (damani) is our meeting facilitator. Do not hesitate to >> ping him to discuss the meeting management. >> >> >>> I still >>> need to read through the old spec and old implementation of NATS, and I >>> am a bit restricted on time currently but we >>> could brainstorm in that meeting and get us started on a new/updated the >>> other spec. >>> >>> Should also note that, to anybody interested, that the topic is a little >>> bit more broader than just a new messaging driver >>> as it includes planning and/or working around the usage of eventlet etc, >>> if you are interested in that topic please also >>> reach out to us! >>> >>> Best regards >>> Tobias >>> >>> > On 2 Sept 2022, at 10:35, Felix H?ttner >>> wrote: >>> > >>> > +1, we would also be interested in helping out. Let me know where we >>> can help out with reviews, writing code, testing, etc. >>> > >>> > -- >>> > Felix Huettner >>> > >>> >> +1, I'm also interested in this topic. I did some tests with nats-py >>> to see how it works and I'm volunteering to go further with this technology. >>> >> Let me know if you need reviews, help etc... >>> >> >>> >> Le jeu. 1 sept. 2022 ? 15:50, Tobias Urdin >> tobias.urdin at binero.com> a ?crit : >>> >> Hello Kai, >>> >> >>> >> Great to hear that you're interested! >>> >> I'm currently just testing this as a POC directly in devstack so >>> there is real-world testing (not should it yet I think, needs more >>> development first). >>> >> >>> >> Best regards >>> >> Tobias >>> >> >>> >>> On 30 Aug 2022, at 18:32, Kai Bojens wrote: >>> >>> >>> >>> Am 29.08.22 um 15:46 schrieb Tobias Urdin: >>> >>> >>> >>>> If anybody, or any company, out there would be interested in >>> collaborating in a project to bring this support and maintain it feel free >>> to >>> >>>> reach out. I'm hoping somebody will bite but atleast I've put it >>> out there for all of you. >>> >>> >>> >>> Hi, >>> >>> I am very much interested to take a closer look at your work and >>> maybe contribute to it. Although I'm working with OpenStack for my employer >>> at the moment, I'd do this in my spare time as I'm not sure that I can >>> convince him to add another staging system with a full OpenStack >>> installation just for developing a RabbitMQ replacement. That's not on our >>> agenda as we are mostly users and not developers of OpenStack. >>> >>> >>> >>> As I'm pretty new to the messaging topic and had just heard of NATS >>> and your idea, I'll first would have to dive into NATS and then I would >>> take a closer look at your code and maybe try to create some documentation >>> or tests. So, I can't promise anything but as I said I'm very interested in >>> your approach as I also see the massive load from RabbitMQ. >>> >>> >>> >>> This brings me to the most important question: Where do you run and >>> test your code? >>> >>> >>> >>> Greetings, >>> >>> Kai >>> > >>> > Diese E Mail enth?lt m?glicherweise vertrauliche Inhalte und ist nur >>> f?r die Verwertung durch den vorgesehenen Empf?nger bestimmt. Sollten Sie >>> nicht der vorgesehene Empf?nger sein, setzen Sie den Absender bitte >>> unverz?glich in Kenntnis und l?schen diese E Mail. Hinweise zum Datenschutz >>> finden Sie hier. >>> >>> >> >> -- >> Herv? Beraud >> Senior Software Engineer at Red Hat >> irc: hberaud >> https://github.com/4383/ >> https://twitter.com/4383hberaud >> >> >> > -- Herv? Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From knikolla at bu.edu Thu Sep 8 15:33:48 2022 From: knikolla at bu.edu (Nikolla, Kristi) Date: Thu, 8 Sep 2022 15:33:48 +0000 Subject: [all][elections][ptl][tc] Combined PTL/TC antelope cycle Election Nominations End In-Reply-To: References: Message-ID: <678D3ABD-38E5-40D7-8EA3-643DDC4E1E48@bu.edu> Please note that there is an ACTION REQUIRED to receive the voting ballot from CIVS: opting in to receiving email communications from CIVS. More information and the form to do so can be found at https://civs1.civs.us/cgi-bin/opt_in.pl Polling will start on Monday and this operation needs to be completed before then. Apologies for the late notice and thank you, Kristi Nikolla Il giorno 7 set 2022, alle ore 8:14 PM, Amy Marrich > ha scritto: Please note we are in the process of adding a standalone TC Campaigning period before opening the TC election for voting. This will allow the candidates to answer any questions and also people to opt-in to the CIVS system before we start the voting process. Pending a patch being added and merged we are looking at starting the voting early to mid next week. Thanks, Amy +++++++++++++++++++++++++++++++++++++++++++++++++++ The PTL and TC Nomination period is now over. The official candidate lists for PTLs [0] and TC seats [1] are available on the election website. -- PTL Election Details -- There are 11 projects without candidates, so according to this resolution[2], the TC will have to decide how the following projects will proceed: Adjutant, Barbican, Keystone, Masakari, OpenStackSDK, OpenStack_Charms, Sahara, Senlin, Swift, Venus, Zun -- TC Election Details -- There are 1 projects that will have elections: Ironic. Now begins the campaigning period where candidates and electorate may debate their statements. Polling will start Sep 07, 2022 23:45 UTC. Thank you, [0] https://governance.openstack.org/election/#antelope-ptl-candidates [1] https://governance.openstack.org/election/#antelope-tc-candidates [2] https://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From iurygregory at gmail.com Thu Sep 8 17:54:33 2022 From: iurygregory at gmail.com (Iury Gregory) Date: Thu, 8 Sep 2022 14:54:33 -0300 Subject: [ironic] Check PTG topics Message-ID: Hello ironicers, The Antelope PTG is in a a few weeks, we had the idea to check the PTG topics (so we can group some before setting the final schedule) Please vote in the doodle [1] for a time where we can discuss a bit o/ Feel free to add topics to our etherpad! [2] Thanks! [1] https://doodle.com/meeting/participate/id/dBL8ZZXa [2] https://etherpad.opendev.org/p/ironic-antelope-ptg -- *Att[]'s* *Iury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Ironic PTL * *Senior Software Engineer at Red Hat Brazil* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From iurygregory at gmail.com Thu Sep 8 17:54:38 2022 From: iurygregory at gmail.com (Iury Gregory) Date: Thu, 8 Sep 2022 14:54:38 -0300 Subject: [baremetal-sig][ironic] No meeting in September Message-ID: Hello everyone, This email is just to let you know that we won't have any presentation/meeting for the Baremetal-sig this month. -- *Att[]'s* *Iury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Ironic PTL * *Senior Software Engineer at Red Hat Brazil* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.bredar at gmail.com Thu Sep 8 22:48:34 2022 From: tomas.bredar at gmail.com (=?UTF-8?B?VG9tw6HFoSBCcmVkw6Fy?=) Date: Fri, 9 Sep 2022 00:48:34 +0200 Subject: [designate] zone sharing between projects and how to create classless PTR Message-ID: Hi Folks, I have a few questions: 1. Is there a possibility to share DNS zones between tenants? I've found this [1] patchset, but it's not merged yet. 2. Is there a way to create a classless reverse zone? According to [2], it should work. Creating a zone is ok: openstack zone create --email tomas.bredar at gmail.com \ --ttl 3600 --description "in-addr.arpa. zone for reverse lookups for e-devel subnet 10.254.226.0/26" \ 0-26.226.254.10.in-addr.arpa. But when I try to add a recordset, I get an error: openstack recordset create --record testvm.bredytest.abc.com. --type PTR --ttl 600 0-26.226.254.10.in-addr.arpa. 1.226.254.10.in-addr.arpa. RecordSet is not contained within it's parent zone I'm using OpenStack Wallaby If this won't work, I'm considering using the neutron integration with external DNS. Thanks for your help Tomas [1] https://review.opendev.org/c/openstack/designate/+/726334 [2] https://docs.openstack.org/designate/latest/user/manage-ptr-records.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnsomor at gmail.com Fri Sep 9 01:18:13 2022 From: johnsomor at gmail.com (Michael Johnson) Date: Thu, 8 Sep 2022 18:18:13 -0700 Subject: [designate] zone sharing between projects and how to create classless PTR In-Reply-To: References: Message-ID: Hi Tom??, Shared zones was a goal to get merged in Zed, but unfortunately no one found time to fix the open issues on the patch. This is a topic on the PTG agenda and hopefully we can add that feature in the Antelope release. As for classless reverse zones, this feature should work (I remember someone using it in 2020). I do however remember someone else struggling with this in the past given the complicated setup required for classless zones in DNS. I will refresh my memory on how those zones work tomorrow and see if I can improve the documentation (I only found that one mention as well). Michael On Thu, Sep 8, 2022 at 4:11 PM Tom?? Bred?r wrote: > > Hi Folks, > > I have a few questions: > 1. Is there a possibility to share DNS zones between tenants? I've found this [1] patchset, but it's not merged yet. > 2. Is there a way to create a classless reverse zone? According to [2], it should work. Creating a zone is ok: > openstack zone create --email tomas.bredar at gmail.com \ > --ttl 3600 --description "in-addr.arpa. zone for reverse lookups for e-devel subnet 10.254.226.0/26" \ > 0-26.226.254.10.in-addr.arpa. > > But when I try to add a recordset, I get an error: > openstack recordset create --record testvm.bredytest.abc.com. --type PTR --ttl 600 0-26.226.254.10.in-addr.arpa. 1.226.254.10.in-addr.arpa. > RecordSet is not contained within it's parent zone > > I'm using OpenStack Wallaby > If this won't work, I'm considering using the neutron integration with external DNS. > > Thanks for your help > > Tomas > > [1] https://review.opendev.org/c/openstack/designate/+/726334 > [2] https://docs.openstack.org/designate/latest/user/manage-ptr-records.html From bkslash at poczta.onet.pl Fri Sep 9 06:05:52 2022 From: bkslash at poczta.onet.pl (A Tom) Date: Fri, 9 Sep 2022 08:05:52 +0200 Subject: [rabbitmq][kolla-ansible] How to enable rabbitmq plugin via configuration file? Message-ID: <943BFFFF-F5F5-45D2-B119-998D53083522@poczta.onet.pl> Hi, I?m trying to enable rabbitmq_tracing plugin in my kolla-ansible. In ?typical? installation you have to enable plugin via rabbitmq-plugins enable and (in case of this particular plugin) add directory,username and password to rabbitmq.conf. These changes (adding username,password and directory) are obvious, but how do I enable particular plugin by kolla-ansible configuration file? Should I put something in globals.yaml? Best regards Adam Tomas From katonalala at gmail.com Fri Sep 9 06:22:44 2022 From: katonalala at gmail.com (Lajos Katona) Date: Fri, 9 Sep 2022 08:22:44 +0200 Subject: [neutron] Drivers meeting agenda - 9.09.2022. Message-ID: Hi Neutron Drivers, The agenda for tomorrow's drivers meeting is at [1]. We have the following RFE to discuss: [RFE] OVN support for vnic type virtio-forwarder (#link https://bugs.launchpad.net/neutron/+bug/1988542 ) [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda See you at the meeting tomorrow. Lajos Katona (lajoskatona) -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Fri Sep 9 07:45:51 2022 From: skaplons at redhat.com (Slawek Kaplonski) Date: Fri, 09 Sep 2022 09:45:51 +0200 Subject: [all][tc] What's happening in Technical Committee: summary 2022 Sept 9 Message-ID: <3131584.9U5gcgIR4J@p1> Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week's meeting on Sept 08. Most of the meeting discussions are summarized in this email. Meeting logs are available @https://meetings.opendev.org/meetings/tc/2022/tc.2022-09-08-15.00.log.html * Next TC weekly meeting will be on Sept 15 Thursday at 15:00 UTC, feel free to add the topic on the agenda[1] by Sept 14. 2. Activities In progress: ================== TC Tracker for Zed cycle ------------------------------ * Zed tracker etherpad includes the TC working items[2], four are completed and others items are in-progress. Open Reviews ----------------- * Five open reviews for ongoing activities[3]. 2023.1 cycle Technical Election (TC + PTL) ------------------------------------------------------------- Nomination period is now over. We are currently in the campaign time. Please remember that there is an action required if You want to receive ballot from CIVS. Please check [4] for more details. Define 2023.1 cycle testing runtime ------------------------------------------- Testing runtime for the 2023.1 cycle is up for review [5]. 2023.1 cycle TC PTG planning ------------------------------------ Updates on PTG planning: * "TC + Leader interaction" sessions is scheduled for Oct 17 Monday 15-17 UTC[6], * gmann created the TC PTG etherpad to collect the topic[7]. * gmann sent an email about the 'Operator Hours' slots in this PTG, please check and reserve the operator hour slot for your project[8]. 2021 User Survey TC Question Analysis ----------------------------------------------- No update on this. The survey summary is up for review[9]. Feel free to check and provide feedback. Fixing Zuul config error ---------------------------- Requesting projects with zuul config error to look into those and fix them which should not take much time[10][11]. Project updates ------------------- * Switch release management to distributed leadership[12] 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[13]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [14] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://etherpad.opendev.org/p/tc-zed-tracker [3] https://review.opendev.org/q/projects:openstack/governance+status:open [4] https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030405.html [5] https://review.opendev.org/c/openstack/governance/+/854375 [6] https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030303.html [7] https://etherpad.opendev.org/p/tc-2023-1-ptg [8] https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030301.html [9] https://review.opendev.org/c/openstack/governance/+/836888 [10] https://etherpad.opendev.org/p/zuul-config-error-openstack [11] http://lists.openstack.org/pipermail/openstack-discuss/2022-May/028603.html [12] https://review.opendev.org/c/openstack/governance/+/855276 [13] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [14] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From sergey.drozdov.dev at gmail.com Fri Sep 9 11:10:53 2022 From: sergey.drozdov.dev at gmail.com (Sergey Drozdov) Date: Fri, 9 Sep 2022 12:10:53 +0100 Subject: [designate] zone sharing between projects and how to create classless PTR In-Reply-To: References: Message-ID: Hi everyone, I am currently working on the aforementioned patchset [1]; I have finished rebasing and am making my way through the comments. I believe it will be ready for review by early next week, probably Monday. Best Regards, Sergey [1] https://review.opendev.org/c/openstack/designate/+/726334 > On 9 Sep 2022, at 02:18, Michael Johnson wrote: > > Hi Tom??, > > Shared zones was a goal to get merged in Zed, but unfortunately no one > found time to fix the open issues on the patch. This is a topic on the > PTG agenda and hopefully we can add that feature in the Antelope > release. > > As for classless reverse zones, this feature should work (I remember > someone using it in 2020). I do however remember someone else > struggling with this in the past given the complicated setup required > for classless zones in DNS. I will refresh my memory on how those > zones work tomorrow and see if I can improve the documentation (I only > found that one mention as well). > > Michael > > On Thu, Sep 8, 2022 at 4:11 PM Tom?? Bred?r wrote: >> >> Hi Folks, >> >> I have a few questions: >> 1. Is there a possibility to share DNS zones between tenants? I've found this [1] patchset, but it's not merged yet. >> 2. Is there a way to create a classless reverse zone? According to [2], it should work. Creating a zone is ok: >> openstack zone create --email tomas.bredar at gmail.com \ >> --ttl 3600 --description "in-addr.arpa. zone for reverse lookups for e-devel subnet 10.254.226.0/26" \ >> 0-26.226.254.10.in-addr.arpa. >> >> But when I try to add a recordset, I get an error: >> openstack recordset create --record testvm.bredytest.abc.com. --type PTR --ttl 600 0-26.226.254.10.in-addr.arpa. 1.226.254.10.in-addr.arpa. >> RecordSet is not contained within it's parent zone >> >> I'm using OpenStack Wallaby >> If this won't work, I'm considering using the neutron integration with external DNS. >> >> Thanks for your help >> >> Tomas >> >> [1] https://review.opendev.org/c/openstack/designate/+/726334 >> [2] https://docs.openstack.org/designate/latest/user/manage-ptr-records.html > From ozzzo at yahoo.com Fri Sep 9 13:30:05 2022 From: ozzzo at yahoo.com (Albert Braden) Date: Fri, 9 Sep 2022 13:30:05 +0000 (UTC) Subject: [kolla] [train] Horizon port security group management fails References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> Message-ID: <24994302.1451585.1662730205554@mail.yahoo.com> We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port ". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong? From pierre at stackhpc.com Fri Sep 9 14:14:24 2022 From: pierre at stackhpc.com (Pierre Riteau) Date: Fri, 9 Sep 2022 16:14:24 +0200 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 In-Reply-To: References: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> Message-ID: On Tue, 6 Sept 2022 at 12:40, Stephen Finucane wrote: > I did those yesterday. > > Aodh: https://review.opendev.org/c/openstack/aodh/+/855962 > Designate: https://review.opendev.org/c/openstack/designate/+/855965 > Manila: https://review.opendev.org/c/openstack/manila/+/855967 > Ironic: https://review.opendev.org/c/openstack/ironic/+/855969 > Heat: https://review.opendev.org/c/openstack/heat/+/855970 > Barbican: https://review.opendev.org/c/openstack/barbican/+/855972 > > The barbican one isn't correct and I need to respin it. The rest are > working as > expected though, as proven at [1]. > > Stephen > > [1] https://review.opendev.org/c/openstack/requirements/+/855973/ Hi, Rados?aw Piliszek (yoctozepto) and I have discovered that Blazar is also broken by the release of oslo.db 12.1.0: CI jobs are failing CI jobs in [1]. I will try to fix it like Stephen did for other projects, but I would like to flag that it is possible other projects are impacted: in particular we should check any smaller project that doesn't run CI jobs regularly. This reminds me of the breakage we had at the end of the last cycle with oslo.context 4.0.0 [2]. Cheers, Pierre Riteau (priteau) [1] https://review.opendev.org/c/openstack/blazar/+/856527 [2] https://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre at stackhpc.com Fri Sep 9 14:34:14 2022 From: pierre at stackhpc.com (Pierre Riteau) Date: Fri, 9 Sep 2022 16:34:14 +0200 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 In-Reply-To: References: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> Message-ID: On Fri, 9 Sept 2022 at 16:14, Pierre Riteau wrote: > On Tue, 6 Sept 2022 at 12:40, Stephen Finucane > wrote: > >> I did those yesterday. >> >> Aodh: https://review.opendev.org/c/openstack/aodh/+/855962 >> Designate: https://review.opendev.org/c/openstack/designate/+/855965 >> Manila: https://review.opendev.org/c/openstack/manila/+/855967 >> Ironic: https://review.opendev.org/c/openstack/ironic/+/855969 >> Heat: https://review.opendev.org/c/openstack/heat/+/855970 >> Barbican: https://review.opendev.org/c/openstack/barbican/+/855972 >> >> The barbican one isn't correct and I need to respin it. The rest are >> working as >> expected though, as proven at [1]. >> >> Stephen >> >> [1] https://review.opendev.org/c/openstack/requirements/+/855973/ > > > Hi, > > Rados?aw Piliszek (yoctozepto) and I have discovered that Blazar is also > broken by the release of oslo.db 12.1.0: CI jobs are failing CI jobs in [1]. > I will try to fix it like Stephen did for other projects, but I would like > to flag that it is possible other projects are impacted: in particular we > should check any smaller project that doesn't run CI jobs regularly. > > This reminds me of the breakage we had at the end of the last cycle with > oslo.context 4.0.0 [2]. > > Cheers, > Pierre Riteau (priteau) > > [1] https://review.opendev.org/c/openstack/blazar/+/856527 > [2] > https://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.html > Thank you Stephen for your code, this made it an easy fix [1]. [1] https://review.opendev.org/c/openstack/blazar/+/856768 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre at stackhpc.com Fri Sep 9 14:39:23 2022 From: pierre at stackhpc.com (Pierre Riteau) Date: Fri, 9 Sep 2022 16:39:23 +0200 Subject: [kolla] [train] Horizon port security group management fails In-Reply-To: <24994302.1451585.1662730205554@mail.yahoo.com> References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> Message-ID: Hello, This is more likely to be a Horizon bug than an issue with Kolla itself, since Kolla doesn't change much from the default configuration. You should check Horizon logs in /var/log/kolla/horizon to find the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently. Cheers, Pierre Riteau (priteau) On Fri, 9 Sept 2022 at 15:41, Albert Braden wrote: > We're running kolla train and we're seeing an apparent bug when we try to > add or remove security groups on a port. We see error "Failed to update > port ". It works fine in CLI; we only see this in Horizon. Is this a > known bug, or are we doing something wrong? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elod.illes at est.tech Fri Sep 9 15:16:26 2022 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Fri, 9 Sep 2022 17:16:26 +0200 Subject: [release] Release countdown for week R-3, Sep 12 - 16 Message-ID: <381e5b4c-fd35-0aeb-6e8f-c872657a932d@est.tech> Development Focus ----------------- The Release Candidate (RC) deadline is next Thursday, September 15th, 2022. Work should be focused on fixing any release-critical bugs. General Information ------------------- All deliverables released under a cycle-with-rc model should have a first release candidate by the end of the week, from which a stable/zed branch will be cut. This branch will track the Zed release. Once stable/zed has been created, the master branch will be ready to switch to 2023.1 Antelope development. While the master branch will no longer be feature-frozen, please prioritize any work necessary for completing Zed plans. Release-critical bugfixes will need to be merged in the master branch first, then backported to the stable/zed branch before a new release candidate can be proposed. Actions ------- Early in the week, the release team will be proposing RC1 patches for all cycle-with-rc projects, using the latest commit from the master branch. If your team is ready to go for cutting RC1, please let us know by leaving a +1 on these patches. If there are still a few more patches needed before RC1, you can -1 the patch and update it later in the week with the new commit hash you would like to use. Remember, stable/zed branches will be created with this, so you will want to make sure you have what you need included to avoid needing to backport changes from the master branch (which will technically then be 2023.1 Antelope) to this stable branch for any additional RCs before the final release. The release team will also be proposing releases for any deliverable following a cycle-with-intermediary model that has not produced any Zed release so far. Finally, now is a good time to finalize release highlights. Release highlights help shape the messaging around the release and make sure that your work is properly represented. Upcoming Deadlines & Dates -------------------------- RC1 deadline: September 15th, 2022 (R-3 week) Final RC deadline: September 29th, 2022 (R-1 week) Final Zed release: October 5th, 2022 Virtual PTG: October 17-21, 2022 El?d Ill?s irc: elodilles From johnsomor at gmail.com Fri Sep 9 20:29:06 2022 From: johnsomor at gmail.com (Michael Johnson) Date: Fri, 9 Sep 2022 13:29:06 -0700 Subject: [designate] zone sharing between projects and how to create classless PTR In-Reply-To: References: Message-ID: Hi Tom??, I have tested this out and it appears to be working correctly. See this pastebin: https://paste.openstack.org/show/816672/ Looking at your email, it appears the record name was not under the correct zone. "1.226.254.10.in-addr.arpa." should have been "1.0-26.226.254.10.in-addr.arpa." I hope this example helps. In follow up, I will be adding a section to the docs for this and adding a scenario test as I don't see one. Michael On Fri, Sep 9, 2022 at 4:10 AM Sergey Drozdov wrote: > > Hi everyone, > > I am currently working on the aforementioned patchset [1]; I have finished rebasing and am making my way through the comments. > I believe it will be ready for review by early next week, probably Monday. > > Best Regards, > Sergey > > [1] https://review.opendev.org/c/openstack/designate/+/726334 > > > On 9 Sep 2022, at 02:18, Michael Johnson wrote: > > > > Hi Tom??, > > > > Shared zones was a goal to get merged in Zed, but unfortunately no one > > found time to fix the open issues on the patch. This is a topic on the > > PTG agenda and hopefully we can add that feature in the Antelope > > release. > > > > As for classless reverse zones, this feature should work (I remember > > someone using it in 2020). I do however remember someone else > > struggling with this in the past given the complicated setup required > > for classless zones in DNS. I will refresh my memory on how those > > zones work tomorrow and see if I can improve the documentation (I only > > found that one mention as well). > > > > Michael > > > > On Thu, Sep 8, 2022 at 4:11 PM Tom?? Bred?r wrote: > >> > >> Hi Folks, > >> > >> I have a few questions: > >> 1. Is there a possibility to share DNS zones between tenants? I've found this [1] patchset, but it's not merged yet. > >> 2. Is there a way to create a classless reverse zone? According to [2], it should work. Creating a zone is ok: > >> openstack zone create --email tomas.bredar at gmail.com \ > >> --ttl 3600 --description "in-addr.arpa. zone for reverse lookups for e-devel subnet 10.254.226.0/26" \ > >> 0-26.226.254.10.in-addr.arpa. > >> > >> But when I try to add a recordset, I get an error: > >> openstack recordset create --record testvm.bredytest.abc.com. --type PTR --ttl 600 0-26.226.254.10.in-addr.arpa. 1.226.254.10.in-addr.arpa. > >> RecordSet is not contained within it's parent zone > >> > >> I'm using OpenStack Wallaby > >> If this won't work, I'm considering using the neutron integration with external DNS. > >> > >> Thanks for your help > >> > >> Tomas > >> > >> [1] https://review.opendev.org/c/openstack/designate/+/726334 > >> [2] https://docs.openstack.org/designate/latest/user/manage-ptr-records.html > > > From ces.eduardo98 at gmail.com Fri Sep 9 22:34:19 2022 From: ces.eduardo98 at gmail.com (Carlos Silva) Date: Fri, 9 Sep 2022 19:34:19 -0300 Subject: [manila] Bugsquash postponed by one week In-Reply-To: References: Message-ID: Hello! Circling back to share more details on next week's bugsquash: Tuesday: 16:00 UTC (30 minutes kickoff on Bluejeans bridge [1]) Wednesday: 15:00 UTC (Mid point check on IRC #openstack-manila channel) Thursday: 15:00 UTC (Session to close out the bugsquash event on Bluejeans bridge [1]) Please take a look at the bugs list [2], and if over the next week you do not intend to work on a bug that is assigned to you, kindly remove it from the list. Looking forward to seeing you next week! Thanks, carloss [1] https://bluejeans.com/371190441 [2] https://ethercalc.net/urx9rn9z6lnb Em ter., 6 de set. de 2022 ?s 13:09, Carlos Silva escreveu: > Hello, Zorillas! > > I'm sending this email to inform you that the bugsquash we planned for > this week will be postponed by one week. We currently have some FFEs and we > could use the change owners and reviewers energy to get those changes > moving forward. > > We hope to have the FFE changes merged by the end of this week, so next > week we could use some focus time on the bugsquash. > > Regards, > carloss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas.bredar at gmail.com Sat Sep 10 20:15:40 2022 From: tomas.bredar at gmail.com (=?UTF-8?B?VG9tw6HFoSBCcmVkw6Fy?=) Date: Sat, 10 Sep 2022 22:15:40 +0200 Subject: [designate] zone sharing between projects and how to create classless PTR In-Reply-To: References: Message-ID: Hi Michael, indeed this worked. Thanks. @Sergey or Michael, if the zone sharing would work, would it be something that I could use in Wallaby in the near future? Thanks Tomas pi 9. 9. 2022 o 22:29 Michael Johnson nap?sal(a): > Hi Tom??, > > I have tested this out and it appears to be working correctly. See > this pastebin: https://paste.openstack.org/show/816672/ > > Looking at your email, it appears the record name was not under the > correct zone. > "1.226.254.10.in-addr.arpa." should have been > "1.0-26.226.254.10.in-addr.arpa." > > I hope this example helps. In follow up, I will be adding a section to > the docs for this and adding a scenario test as I don't see one. > > Michael > > On Fri, Sep 9, 2022 at 4:10 AM Sergey Drozdov > wrote: > > > > Hi everyone, > > > > I am currently working on the aforementioned patchset [1]; I have > finished rebasing and am making my way through the comments. > > I believe it will be ready for review by early next week, probably > Monday. > > > > Best Regards, > > Sergey > > > > [1] https://review.opendev.org/c/openstack/designate/+/726334 > > > > > On 9 Sep 2022, at 02:18, Michael Johnson wrote: > > > > > > Hi Tom??, > > > > > > Shared zones was a goal to get merged in Zed, but unfortunately no one > > > found time to fix the open issues on the patch. This is a topic on the > > > PTG agenda and hopefully we can add that feature in the Antelope > > > release. > > > > > > As for classless reverse zones, this feature should work (I remember > > > someone using it in 2020). I do however remember someone else > > > struggling with this in the past given the complicated setup required > > > for classless zones in DNS. I will refresh my memory on how those > > > zones work tomorrow and see if I can improve the documentation (I only > > > found that one mention as well). > > > > > > Michael > > > > > > On Thu, Sep 8, 2022 at 4:11 PM Tom?? Bred?r > wrote: > > >> > > >> Hi Folks, > > >> > > >> I have a few questions: > > >> 1. Is there a possibility to share DNS zones between tenants? I've > found this [1] patchset, but it's not merged yet. > > >> 2. Is there a way to create a classless reverse zone? According to > [2], it should work. Creating a zone is ok: > > >> openstack zone create --email tomas.bredar at gmail.com \ > > >> --ttl 3600 --description "in-addr.arpa. zone for reverse lookups > for e-devel subnet 10.254.226.0/26" \ > > >> 0-26.226.254.10.in-addr.arpa. > > >> > > >> But when I try to add a recordset, I get an error: > > >> openstack recordset create --record testvm.bredytest.abc.com. --type > PTR --ttl 600 0-26.226.254.10.in-addr.arpa. 1.226.254.10.in-addr.arpa. > > >> RecordSet is not contained within it's parent zone > > >> > > >> I'm using OpenStack Wallaby > > >> If this won't work, I'm considering using the neutron integration > with external DNS. > > >> > > >> Thanks for your help > > >> > > >> Tomas > > >> > > >> [1] https://review.opendev.org/c/openstack/designate/+/726334 > > >> [2] > https://docs.openstack.org/designate/latest/user/manage-ptr-records.html > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkchn.in at gmail.com Sun Sep 11 04:02:21 2022 From: kkchn.in at gmail.com (KK CHN) Date: Sun, 11 Sep 2022 09:32:21 +0530 Subject: [all] GovStack community seeking for infrastructure expertise In-Reply-To: <39b7d738-5336-b9d3-de5b-dfc3ea098e62@garloff.de> References: <39b7d738-5336-b9d3-de5b-dfc3ea098e62@garloff.de> Message-ID: Interesting .. appreciate the initiative.. Is this a Cloud Native Stack concept to build a Govstack, So the potential users/customers can come and develop the applications using the cloud native app development framework/stack ?.. Is there any reference documents to make a Cloud Native Stack using/leveraging existing standards of Openstack OR [ Containers(Docker/Kubernetes or LXCs) etc ] . We are a non-profit government organization working with the Government in an Asian country and would like to know the design/ architecture principles and use cases of developing a Cloud Native- GovStack. Any documentation / reference most appreciated. Thank you, Krish. On Tue, Aug 16, 2022 at 5:22 PM Kurt Garloff wrote: > Hi Nico, > > Sounds like a great initiative. > > I believe there is a significant overlap between our Sovereign Cloud > Stack (SCS) [1] initiative and what you are trying to achieve. > There was some contact between GIZ and us at some point although this > may not have reached you, unfortuantely. > > Let's ensure we work together and join forces where it makes sense. > > [1] https://scs.community/ > > -- > Kurt Garloff > Cologne, Germany > > On 16.08.22 10:41, Lueck, Nico GIZ wrote: > > Do you believe in the potential of digital public goods for positive > impact? Ever wished for more digitally-enabled government services? > > > > GovStack [1] is a community-driven initiative on a mission to accelerate > the digital transformation of government services in order to better serve > citizens - and we want you to join us! > > > > We create and maintain an openly licenced blueprint for a modular > architecture based on reusable building blocks [2]. Our various working > groups work to define the (non-)functional and API specifications for > building blocks, leveraging existing standards such as OpenStack. These > specifications are then used for implementations in our partner countries > across the world, to facilitate the delivery of foundational, > life-enhancing services. > > > > Learn more about the call for contributions here [3]. We are > specifically looking for experts with experience in infrastructure and > security. > > > > The initiative is founded by the German Federal Ministry for Economic > Cooperation and Development, Deutsche Gesellschaft fuer Internationale > Zusammenarbeit (GIZ), the Ministry of Foreign Affairs of the Republic of > Estonia, the International Telecommunication Union (ITU) and the Digital > Impact Alliance. > > > > Thank you to the team of the Open Infrastructure Foundation for their > support. > > > > Also, thank you to the whole community and please feel free to directly > contact us. > > Nico (Lueck) > > > > > > [1] https://www.govstack.global/ > > [2] https://govstack.gitbook.io/ > > [3] https://www.govstack.global/call-for-expression-of-interest/ > > > > ________________________________ > > Deutsche Gesellschaft fuer Internationale Zusammenarbeit (GIZ) GmbH; > > Sitz der Gesellschaft Bonn und Eschborn/Registered offices Bonn and > Eschborn, Germany; > > Registergericht/Registered at Amtsgericht Bonn, Germany; > Eintragungs-Nr./Registration no. HRB 18384 und/and Amtsgericht Frankfurt am > Main, Germany; Eintragungs-Nr./Registration no. HRB 12394; > > USt-IdNr./VAT ID no. DE 113891176; > > Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Jochen > Flasbarth; > > Vorstand/Management Board: Tanja Goenner (Vorstandssprecherin/Chair of > the Management Board), Ingrid-Gabriela Hoven, Thorsten Schaefer-Guembel > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From refugee at last-refuge.net Sun Sep 11 13:12:19 2022 From: refugee at last-refuge.net (Christian Stelter) Date: Sun, 11 Sep 2022 15:12:19 +0200 Subject: [monasca][kolla-ansible] Help for a monasca newbie to get metrics for instances needed Message-ID: Hi! I'm trying to explore monasca, but I'm bit lost in how to get metrics from a project/tenant collected. I'm using kolla-ansible in my test setup running ubuntu-source images. Ubuntu release is Yoga. Monasca seems to be up and running. I can see the default metrics with a appropriate user in the monasca_control_plane project. cpu.* disk.* io.* load.* mem.* monasca.* net.* ntp.* And I find measurements in the influxdb, but only metrics/measurements for the openstack hypervisor nodes yet. What I'm missing after searching the existing documentation is how I can enable a plugin as for libvirt for example or whatever the recommendation for monitoring the instances is. As I have found the plugins directory on the hypervisors under /etc/kolla/monasca-agent-collector/plugins I thought putting a config file like in the documentation [1] for the libvirt plugin and restart the monasca-agent-collector would be sufficient. But all I got was an error message: 2022-09-11 12:22:26,412 | ERROR | collector | monasca_agent.common.util(util.py:529) | Unable to import check module libvirt.py from checks_d Traceback (most recent call last): File "/var/lib/kolla/venv/lib/python3.8/site-packages/monasca_agent/common/util.py", line 520, in load_check_directory check_module = load_module('checksd_%s' % check_name, check) File "/var/lib/kolla/venv/lib/python3.8/site-packages/monasca_agent/common/util.py", line 470, in load_module module_spec.loader.exec_module(module) File "", line 848, in exec_module File "", line 219, in _call_with_frames_removed File "/var/lib/kolla/venv/lib/python3.8/site-packages/monasca_agent/common/../collector/checks_d/libvirt.py", line 20, in import libvirt ModuleNotFoundError: No module named 'libvirt' As it seems the plugin system dependencies like libvirt-dev are missing. So I assume I have to rebuild the container myself and/or open an issue on opendev.org. Or is there another way to get metrics for instances? Next question: even if I had a running libvirt plugin. What has to be done to enable another user in a normal tenant project to use these metrics? Just add the monasca-read-only-user to user(s) which shall be enabled to manage alarm definitions, alarms and notifications? Will the tenant then see or at least use the metrics for his (and only his) project? I found a lot of high level documentation, (base) installation instructions, hints for developers on how to extend monasca, but nothing beyond the initial setup for monasca newbies like me. I queried the all-knowing, all-seeing trash heap, mailing lists, and the YT academy already. May be I just missed something. So hints are welcome! BTW. Is the kolla-ansible part of monasca still in active maintenance and development? I stumpled upon the same error as in [2] and I'm getting an HTTP 500 error when trying to open the monitoring overview and is still unassigned. Thanks in advance! Kind regards, Christian Stelter [1] https://github.com/openstack/monasca-agent/blob/master/docs/Libvirt.md#configuration [2] https://bugs.launchpad.net/kolla-ansible/+bug/1967278 From radoslaw.piliszek at gmail.com Sun Sep 11 19:14:08 2022 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Sun, 11 Sep 2022 21:14:08 +0200 Subject: [monasca][kolla-ansible] Help for a monasca newbie to get metrics for instances needed In-Reply-To: References: Message-ID: On Sun, 11 Sept 2022 at 15:15, Christian Stelter wrote: > BTW. Is the kolla-ansible part of monasca still in active maintenance > and development? I stumpled upon the same error as in [2] and I'm > getting an HTTP 500 error when trying to open the monitoring overview > and is still unassigned. I have little to no knowledge of the innerworkings of Monasca but I can answer this question as one of the maintainers of Kolla and Kolla Ansible. There is currently no member of the team working on the Monasca integration and the situation is caused by the low maintenance of the upstream, i.e. Monasca itself. We are open to collaboration on fixing the situation but we don't have the bandwidth to do it ourselves. Cheers, Radek -yoctozepto From tobias.urdin at binero.com Mon Sep 12 07:05:53 2022 From: tobias.urdin at binero.com (Tobias Urdin) Date: Mon, 12 Sep 2022 07:05:53 +0000 Subject: [all] [oslo.messaging] Interest in collaboration on a NATS driver In-Reply-To: References: <52AA12A0-AE67-4EF7-B924-DE1F2873B909@binero.com> <0E347D5A-967D-42E3-AC00-56034907053B@binero.com> <8F7F790F-0F5C-4257-845A-1BCE671AF844@binero.com> Message-ID: Hello, Since I haven?t heard any objections we?ll move the meeting to the Oslo meeting on the 19th of September. See you there! [1] [1] https://wiki.openstack.org/wiki/Meetings/Oslo Best regards Tobias On 8 Sept 2022, at 15:54, Herve Beraud > wrote: WFM Le jeu. 8 sept. 2022 ? 15:16, Tobias Urdin > a ?crit : Hello, I don?t have anything against moving to the 19th of September meeting if that?s OK with everybody else, I propose we do that. Let?s see if we get some feedback against the proposed new date otherwise we?ll move it. Best regards On 8 Sept 2022, at 08:41, Rados?aw Piliszek > wrote: Hi Tobias et al, That Monday I cannot attend due to other work commitments. Could we schedule it for the following week? Cheers, Radek On Tue, Sep 6, 2022, 18:33 Tobias Urdin > wrote: Great! I?ve updated the agenda with NATS driver and eventlet future topic https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting See you in the next meeting on 12th of September 15:00 UTC hopefully that will give us all some time to read through the following material: - Current POC code https://review.opendev.org/c/openstack/oslo.messaging/+/848338 - Devstack plugin https://github.com/tobias-urdin/devstack-plugin-nats - Discussion on IRC on 2nd September about below links https://meetings.opendev.org/irclogs/%23openstack-oslo/%23openstack-oslo.2022-09-02.log.html Links to old material: - The old spec that we can work upon https://review.opendev.org/c/openstack/oslo-specs/+/692784 - Old driver implementation for above old spec https://review.opendev.org/c/openstack/oslo.messaging/+/680629 - Old asyncio planning https://wiki.openstack.org/wiki/Oslo/blueprints/asyncio - Old asyncio executor in oslo.messaging https://blueprints.launchpad.net/oslo.messaging/+spec/asyncio-executor - Old messaging API mail thread https://lists.openstack.org/pipermail/openstack-dev/2013-May/009784.html Looking forward to talk to you all next monday! Best regards Tobias On 5 Sept 2022, at 12:48, Herve Beraud > wrote: Le lun. 5 sept. 2022 ? 10:00, Tobias Urdin > a ?crit : Thanks! It seems that we have some traction here to get started in a more structured manner. I?m on PTO today but back tomorrow, what do people feel about scheduling a recurring meeting about this topic? The weekly Oslo meeting could host the conversation through a dedicated topic. https://wiki.openstack.org/wiki/Meetings/Oslo You could modify the meeting agenda to add this topic. Daniel Bengtsson (damani) is our meeting facilitator. Do not hesitate to ping him to discuss the meeting management. I still need to read through the old spec and old implementation of NATS, and I am a bit restricted on time currently but we could brainstorm in that meeting and get us started on a new/updated the other spec. Should also note that, to anybody interested, that the topic is a little bit more broader than just a new messaging driver as it includes planning and/or working around the usage of eventlet etc, if you are interested in that topic please also reach out to us! Best regards Tobias > On 2 Sept 2022, at 10:35, Felix H?ttner > wrote: > > +1, we would also be interested in helping out. Let me know where we can help out with reviews, writing code, testing, etc. > > -- > Felix Huettner > >> +1, I'm also interested in this topic. I did some tests with nats-py to see how it works and I'm volunteering to go further with this technology. >> Let me know if you need reviews, help etc... >> >> Le jeu. 1 sept. 2022 ? 15:50, Tobias Urdin > a ?crit : >> Hello Kai, >> >> Great to hear that you're interested! >> I'm currently just testing this as a POC directly in devstack so there is real-world testing (not should it yet I think, needs more development first). >> >> Best regards >> Tobias >> >>> On 30 Aug 2022, at 18:32, Kai Bojens > wrote: >>> >>> Am 29.08.22 um 15:46 schrieb Tobias Urdin: >>> >>>> If anybody, or any company, out there would be interested in collaborating in a project to bring this support and maintain it feel free to >>>> reach out. I'm hoping somebody will bite but atleast I've put it out there for all of you. >>> >>> Hi, >>> I am very much interested to take a closer look at your work and maybe contribute to it. Although I'm working with OpenStack for my employer at the moment, I'd do this in my spare time as I'm not sure that I can convince him to add another staging system with a full OpenStack installation just for developing a RabbitMQ replacement. That's not on our agenda as we are mostly users and not developers of OpenStack. >>> >>> As I'm pretty new to the messaging topic and had just heard of NATS and your idea, I'll first would have to dive into NATS and then I would take a closer look at your code and maybe try to create some documentation or tests. So, I can't promise anything but as I said I'm very interested in your approach as I also see the massive load from RabbitMQ. >>> >>> This brings me to the most important question: Where do you run and test your code? >>> >>> Greetings, >>> Kai > > Diese E Mail enth?lt m?glicherweise vertrauliche Inhalte und ist nur f?r die Verwertung durch den vorgesehenen Empf?nger bestimmt. Sollten Sie nicht der vorgesehene Empf?nger sein, setzen Sie den Absender bitte unverz?glich in Kenntnis und l?schen diese E Mail. Hinweise zum Datenschutz finden Sie hier>. -- Herv? Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -- Herv? Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Mon Sep 12 07:28:39 2022 From: thierry at openstack.org (Thierry Carrez) Date: Mon, 12 Sep 2022 09:28:39 +0200 Subject: [largescale-sig] Next meeting: Sept 14th, 15utc Message-ID: <4cd237c1-6335-944d-0ebc-793d6d918cd3@openstack.org> Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 15UTC. You can check how that time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20220914T15 Feel free to add topics to the agenda: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez From kennelson11 at gmail.com Mon Sep 12 07:48:11 2022 From: kennelson11 at gmail.com (Kendall Nelson) Date: Mon, 12 Sep 2022 02:48:11 -0500 Subject: [First Contact][SIG][PTG] Planning October 2022 Message-ID: Hello Party People, I started putting together the etherpad[1] for planning our time at the PTG! Add your topics and your name if you plan on attending :) If the time I selected doesn't work for folks, we can book other time (instead or in addition to), I just know historically we have been a mix of Americas/ APAC and so this time block should work for folks. Also, gentle reminder to register if you haven't already - it is free afterall [2]. -Kendall Nelson (diablo_rojo) [1] https://etherpad.opendev.org/p/oct2022-ptg-first-contact [2] https://openinfra-ptg.eventbrite.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From egarciar at redhat.com Mon Sep 12 08:33:29 2022 From: egarciar at redhat.com (Elvira Garcia Ruiz) Date: Mon, 12 Sep 2022 10:33:29 +0200 Subject: Openstack.io is down Message-ID: Hi everyone! I noticed that stackalytics.io has been down for several days now. As far as I know this was widely used by the community, although it is not part of OpenInfra as a project. I'm not sure who was maintaining this, but I just wanted to make them aware of the problem, and also thank them for keeping it up and running. Kind regards! Elvira Garc?a (irc:elvira) -------------- next part -------------- An HTML attachment was scrubbed... URL: From egarciar at redhat.com Mon Sep 12 08:37:10 2022 From: egarciar at redhat.com (Elvira Garcia Ruiz) Date: Mon, 12 Sep 2022 10:37:10 +0200 Subject: Stackalytics.io is down In-Reply-To: References: Message-ID: Sorry, I obviously meant stackalytics.io in the subject line, not openstack.io. :-) On Mon, Sep 12, 2022 at 10:33 AM Elvira Garcia Ruiz wrote: > Hi everyone! > I noticed that stackalytics.io has been down for several days now. > As far as I know this was widely used by the community, although it is not > part of OpenInfra as a project. > > I'm not sure who was maintaining this, but I just wanted to make them > aware of the problem, and also thank them for keeping it up and running. > > Kind regards! > Elvira Garc?a > (irc:elvira) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From refugee at last-refuge.net Mon Sep 12 09:06:09 2022 From: refugee at last-refuge.net (Christian Stelter) Date: Mon, 12 Sep 2022 11:06:09 +0200 Subject: [monasca][kolla-ansible] Help for a monasca newbie to get metrics for instances needed In-Reply-To: References: Message-ID: Hi, Radek! On Sun, Sep 11, 2022 at 9:14 PM Rados?aw Piliszek wrote: > > On Sun, 11 Sept 2022 at 15:15, Christian Stelter > wrote: > > BTW. Is the kolla-ansible part of monasca still in active maintenance > > and development? I stumpled upon the same error as in [2] and I'm > > getting an HTTP 500 error when trying to open the monitoring overview > > and is still unassigned. > > I have little to no knowledge of the innerworkings of Monasca but I > can answer this question as one of the maintainers of Kolla and Kolla > Ansible. > There is currently no member of the team working on the Monasca > integration and the situation is caused by the low maintenance of the > upstream, i.e. Monasca itself. > We are open to collaboration on fixing the situation but we don't have > the bandwidth to do it ourselves. > > Cheers, > Radek > -yoctozepto Thanks for your feedback on the maintenance part! So I will try then to dig into it further myself. May be someone else can answer the rest. Ceilometer seems to be more popular. But I'm still curious on get monasca running. ;-) Best regards, Christian From pierre at stackhpc.com Mon Sep 12 12:26:29 2022 From: pierre at stackhpc.com (Pierre Riteau) Date: Mon, 12 Sep 2022 14:26:29 +0200 Subject: Stackalytics.io is down In-Reply-To: References: Message-ID: It was originally set up by Andrii Ostapenko, who I added to the thread. On Mon, 12 Sept 2022 at 10:42, Elvira Garcia Ruiz wrote: > Sorry, I obviously meant stackalytics.io in the subject line, not > openstack.io. :-) > > On Mon, Sep 12, 2022 at 10:33 AM Elvira Garcia Ruiz > wrote: > >> Hi everyone! >> I noticed that stackalytics.io has been down for several days now. >> As far as I know this was widely used by the community, although it is >> not part of OpenInfra as a project. >> >> I'm not sure who was maintaining this, but I just wanted to make them >> aware of the problem, and also thank them for keeping it up and running. >> >> Kind regards! >> Elvira Garc?a >> (irc:elvira) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noonedeadpunk at gmail.com Mon Sep 12 12:42:27 2022 From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov) Date: Mon, 12 Sep 2022 14:42:27 +0200 Subject: Stackalytics.io is down In-Reply-To: References: Message-ID: Looking at the amount of requested changes to the information of contributors [1], I'd say it's hardly maintained nowadays as well :( [1] https://review.opendev.org/q/project:x%252Fstackalytics+status:open ??, 12 ????. 2022 ?. ? 14:30, Pierre Riteau : > > It was originally set up by Andrii Ostapenko, who I added to the thread. > > On Mon, 12 Sept 2022 at 10:42, Elvira Garcia Ruiz wrote: >> >> Sorry, I obviously meant stackalytics.io in the subject line, not openstack.io. :-) >> >> On Mon, Sep 12, 2022 at 10:33 AM Elvira Garcia Ruiz wrote: >>> >>> Hi everyone! >>> I noticed that stackalytics.io has been down for several days now. >>> As far as I know this was widely used by the community, although it is not part of OpenInfra as a project. >>> >>> I'm not sure who was maintaining this, but I just wanted to make them aware of the problem, and also thank them for keeping it up and running. >>> >>> Kind regards! >>> Elvira Garc?a >>> (irc:elvira) From jungleboyj at gmail.com Mon Sep 12 12:54:27 2022 From: jungleboyj at gmail.com (Jay Bryant) Date: Mon, 12 Sep 2022 07:54:27 -0500 Subject: [all][elections][ptl][tc] Reminder to opt-in to CIVS polling Message-ID: <446ecabb-803a-a4fc-7efe-45cabd1d1c02@gmail.com> All, Apologies for the additional e-mail in your in-box, but wanted to make sure that everyone saw the reminder to opt-in to voting with CIVS. ACTION IS REQUIRED to receive the voting ballot from CIVS: you must opt-in to receiving email communications from CIVS. More information and the form to do so can be found at https://civs1.civs.us/cgi-bin/opt_in.pl Polling will start TODAY and this operation needs to be completed before then. Happy Voting! - Jay Bryant (jungleboyj) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkopec at redhat.com Mon Sep 12 12:57:03 2022 From: mkopec at redhat.com (Martin Kopec) Date: Mon, 12 Sep 2022 14:57:03 +0200 Subject: [horizon][QA][release] Cycle With Intermediary without recent deliverables In-Reply-To: References: Message-ID: Thanks for the reminder El?d, I've just come back from PTO, we'll take a look soon. On Wed, 7 Sept 2022 at 16:17, vishal manchanda wrote: > Hi El?d, > > ack, thanks for the reminder. > I am planning to do a final release of the horizon around R-2 week(Sep 19 > - Sep 23). > > Regards, > Vishal Manchanda > > On Wed, Sep 7, 2022 at 6:32 PM El?d Ill?s wrote: > >> Hi, >> >> Quick reminder that for deliverables following the cycle-with-intermediary >> model, the release team will use the latest Zed release available on >> release week. >> >> The following deliverables have done a Zed release, but it was not >> refreshed in the last two months: >> >> horizon >> tempest >> >> You should consider making a new one very soon, so that we don't use an >> outdated version for the final release. >> >> >> El?d Ill?s >> irc: elodilles >> >> -- Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at rpomazanov.com Mon Sep 12 10:28:36 2022 From: mail at rpomazanov.com (Roman Pomazanov) Date: Mon, 12 Sep 2022 13:28:36 +0300 (EEST) Subject: [neutron] [ovn] Distributed routing ingress traffic flow Message-ID: <1034882517.1347558.1662978516097@privateemail.com> An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Mon Sep 12 15:27:05 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 12 Sep 2022 20:57:05 +0530 Subject: [tc][ptl][election][masakari] I volunteer to become Masakari PTL again In-Reply-To: References: Message-ID: <183324fabb6.e8f5cb5d1206320.1140721478491865053@ghanshyammann.com> Thanks yoctozepto for your help. I have noted it in below etherpad: https://etherpad.opendev.org/p/2023.1-leaderless -gmann ---- On Thu, 08 Sep 2022 14:54:14 +0530 Rados?aw Piliszek wrote --- > As in the topic - I saw Masakari did not receive a candidate and I > don't want to see this project disappear so I volunteer to be the PTL. > > I don't have any major plans regarding Masakari except for keeping it > afloat and working where it works already. > > Cheers, > Radek > -yoctozepto > > From gmann at ghanshyammann.com Mon Sep 12 15:40:23 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 12 Sep 2022 21:10:23 +0530 Subject: [ptl][tc][election][adjutant][barbican][OpenStackSDK][OpenStack_Charms][sahara][swift][venus] Leaderless project for 2023.1 cycle Message-ID: <183325bd8cc.cccddafd1207362.5111479954134225007@ghanshyammann.com> Hello, As you know, 2023.1 cycle election nomination is ended and we end up with 11 leaderless projects. List is in the etherpad: https://etherpad.opendev.org/p/2023.1-leaderless Out of 11, we have found 4 projects leaders but 7 (in the subject list) projects still need some leaders to volunteer: 1. Adjutant 2. Barbican 3. OpenStackSDK 3. OpenStack_Charms 4. Sahara 5. Swift 6. Venus Please reply here or ping us in #openstack-tc channel if you would like to lead these projects. -gmann From gmann at ghanshyammann.com Mon Sep 12 15:54:55 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 12 Sep 2022 21:24:55 +0530 Subject: [ptl][tc][election][adjutant][barbican][OpenStackSDK][OpenStack_Charms][sahara][swift][venus] Leaderless project for 2023.1 cycle In-Reply-To: <183325bd8cc.cccddafd1207362.5111479954134225007@ghanshyammann.com> References: <183325bd8cc.cccddafd1207362.5111479954134225007@ghanshyammann.com> Message-ID: <183326925ff.10cb19afc1208593.8882731507357282265@ghanshyammann.com> @Barbican team/PTL, Please ignore, dmendiza[m] updated about Grzegorz nomination - https://review.opendev.org/c/openstack/election/+/856295 I have updated the data in etherpad. -gmann ---- On Mon, 12 Sep 2022 21:10:23 +0530 Ghanshyam Mann wrote --- > Hello, > > As you know, 2023.1 cycle election nomination is ended and we end up with 11 leaderless > projects. List is in the etherpad: https://etherpad.opendev.org/p/2023.1-leaderless > > Out of 11, we have found 4 projects leaders but 7 (in the subject list) projects still need some > leaders to volunteer: > > 1. Adjutant > 2. Barbican > 3. OpenStackSDK > 3. OpenStack_Charms > 4. Sahara > 5. Swift > 6. Venus > > Please reply here or ping us in #openstack-tc channel if you would like to lead > these projects. > > -gmann > > > > From gmann at ghanshyammann.com Mon Sep 12 16:13:17 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 12 Sep 2022 21:43:17 +0530 Subject: [ptl][tc][election][adjutant][barbican][OpenStackSDK][OpenStack_Charms][sahara][swift][venus] Leaderless project for 2023.1 cycle In-Reply-To: <183326925ff.10cb19afc1208593.8882731507357282265@ghanshyammann.com> References: <183325bd8cc.cccddafd1207362.5111479954134225007@ghanshyammann.com> <183326925ff.10cb19afc1208593.8882731507357282265@ghanshyammann.com> Message-ID: <1833279f667.eb15a2b41210205.7836618726154260041@ghanshyammann.com> Ditto for OpenStackSDK. - https://review.opendev.org/c/openstack/election/+/856526 Sorry about it, seems the election email has some old data about leaderless project[1]. I have removed OpenStackSDK from leaderless list. [1] https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030395.html -gmann ---- On Mon, 12 Sep 2022 21:24:55 +0530 Ghanshyam Mann wrote --- > @Barbican team/PTL, > > Please ignore, dmendiza[m] updated about Grzegorz nomination > - https://review.opendev.org/c/openstack/election/+/856295 > > I have updated the data in etherpad. > > -gmann > > ---- On Mon, 12 Sep 2022 21:10:23 +0530 Ghanshyam Mann wrote --- > > Hello, > > > > As you know, 2023.1 cycle election nomination is ended and we end up with 11 leaderless > > projects. List is in the etherpad: https://etherpad.opendev.org/p/2023.1-leaderless > > > > Out of 11, we have found 4 projects leaders but 7 (in the subject list) projects still need some > > leaders to volunteer: > > > > 1. Adjutant > > 2. Barbican > > 3. OpenStackSDK > > 3. OpenStack_Charms > > 4. Sahara > > 5. Swift > > 6. Venus > > > > Please reply here or ping us in #openstack-tc channel if you would like to lead > > these projects. > > > > -gmann > > > > > > > > > > From gmann at ghanshyammann.com Mon Sep 12 16:58:14 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Mon, 12 Sep 2022 22:28:14 +0530 Subject: [all][tc] Technical Committee next weekly meeting on 2022 Sept 15 at 1500 UTC Message-ID: <18332a31e6d.dc448c791212721.2391709796688411288@ghanshyammann.com> Hello Everyone, The technical Committee's next weekly meeting is scheduled for 2022 Sept 15, at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, Sept 14 at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann From helena at openstack.org Mon Sep 12 18:10:05 2022 From: helena at openstack.org (Helena Spease) Date: Mon, 12 Sep 2022 13:10:05 -0500 Subject: OpenInfra Summit Vancouver 2023 Track Chair Nominations Now Open Message-ID: <9D39DE45-A159-4C65-B5EA-6C2A989B3B28@openstack.org> Hey everyone! Track Chair nominations > for the 2023 OpenInfra Summit in Vancouver (June 13-15, 2023) are now open! Track Chairs for each Track will help build the Summit schedule, and are made up of individuals working in open infrastructure. Responsibilities include: Help the Summit team put together the best possible content based on your subject matter expertise Promote the individual Tracks within your networks Review the submissions and Community voting results in your particular Track Determine if there are any major content gaps in your Track, and if so, potentially solicit additional speakers directly to submit Ensure diversity of speakers and companies represented in your Track Avoid vendor sales pitches, focusing more on real-world user stories and technical, in-the-trenches experiences Identify which submissions would make good content for OpenInfra Live, the virtual show hosted by the OpenInfra Foundation that encourages live questions from a global audience 2023 Summit Tracks: 5G/NFV & Edge AI/Machine Learning/HPC CI/CD Container Infrastructure Getting Started Hardware Enablement Open Development Private & Hybrid Cloud Public Cloud Security Hands On Workshops Full track descriptions are available here >. If you?re interested in nominating yourself or someone else to be a member of the Summit Track Chairs for a specific Track, please fill out the nomination form >. Nominations will close on October 28th, 2022. Track Chairs selections will occur before we close the Call for Presentations (CFP) so that the Chairs can host office hours to consult on submissions, and help promote the event. CFP will be opening in November, registration > and sponsorship > information are already available. Please email speakersupport at openinfra.dev with any questions or feedback. Cheers, Helena Spease -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.kavanagh at canonical.com Mon Sep 12 20:21:02 2022 From: alex.kavanagh at canonical.com (Alex Kavanagh) Date: Mon, 12 Sep 2022 21:21:02 +0100 Subject: [ptl][tc][election][adjutant][barbican][OpenStackSDK][OpenStack_Charms][sahara][swift][venus] Leaderless project for 2023.1 cycle In-Reply-To: <183325bd8cc.cccddafd1207362.5111479954134225007@ghanshyammann.com> References: <183325bd8cc.cccddafd1207362.5111479954134225007@ghanshyammann.com> Message-ID: Hi On Mon, 12 Sept 2022 at 16:46, Ghanshyam Mann wrote: > Hello, > > As you know, 2023.1 cycle election nomination is ended and we end up with > 11 leaderless > projects. List is in the etherpad: > https://etherpad.opendev.org/p/2023.1-leaderless > > Out of 11, we have found 4 projects leaders but 7 (in the subject list) > projects still need some > leaders to volunteer: > > 1. Adjutant > 2. Barbican > 3. OpenStackSDK > 3. OpenStack_Charms > 4. Sahara > 5. Swift > 6. Venus > > Please reply here or ping us in #openstack-tc channel if you would like to > lead > these projects. > I put my nomination in for OpenStack_Charms on the mailing list, but didn't do the review; it completely slipped my mind that I needed to; sorry! I'd like to be the PTL for the OpenStack charms project again, please, and I believe have the blessing of the team. Thanks Alex (tinwood). > > -gmann > > > > -- Alex Kavanagh - Software Engineer OpenStack Engineering - Data Centre Development - Canonical Ltd -------------- next part -------------- An HTML attachment was scrubbed... URL: From allison at openinfra.dev Mon Sep 12 21:20:55 2022 From: allison at openinfra.dev (Allison Price) Date: Mon, 12 Sep 2022 16:20:55 -0500 Subject: [ptls][zed] OpenInfra Live: OpenStack Zed Message-ID: <6900286A-BE8F-44AD-93F7-6A1838EE0F36@openinfra.dev> Hi everyone, As we get closer to the OpenStack release, I wanted to reach out to see if any PTLs were interested in providing their Zed cycle highlights in an OpenInfra Live[1] episode on Thursday, October 6 at 1400 UTC. Ideally, we would get 4-6 projects represented. Previous examples of OpenStack release episodes can be found here[2] and here[3]. Please let me know if you?re interested and I can provide next steps. If you would like to provide a project update but that time doesn?t work for you, please share a recording with me and I can get it added to the project navigator. Thanks, Allison [1] https://openinfra.dev/live/ [2] https://www.youtube.com/watch?v=hwPfjvshxOM [3] https://www.youtube.com/watch?v=aqilhEmkEBw -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay at gr-oss.io Mon Sep 12 22:06:42 2022 From: jay at gr-oss.io (Jay Faulkner) Date: Mon, 12 Sep 2022 15:06:42 -0700 Subject: [baremetal-sig][ironic] Future of baremetal-sig Message-ID: Stackers, An item came up in the Ironic meeting today regarding the future of the baremetal sig. Essentially, Arne was doing great work sourcing talks for it, but now he's going to be unable to continue hosting it and proactively sourcing talks. (A seriously big thanks is owed to Arne for doing a great job on this!) This led us to wonder if BM SIG in its current form remains sustainable. Some options we can consider include: - Keep the BM SIG as-is, cancel it months where there's not a talk available. - Change the BM SIG meetings to more of a meetup style for operators to talk about Ironic - Something else entirely we haven't thought about yet. What do you all think? - Jay Faulkner -------------- next part -------------- An HTML attachment was scrubbed... URL: From ianyrchoi at gmail.com Tue Sep 13 00:08:34 2022 From: ianyrchoi at gmail.com (Ian Y. Choi) Date: Tue, 13 Sep 2022 09:08:34 +0900 Subject: [all][elections][ptl][tc] Conbined PTL/TC antelope cycle Election Voting Kickoff Message-ID: Polls for PTL and TC elections are now open and will remain open for you to cast your vote until Sep 19, 2022 23:45 UTC. We are selecting 4 TC members, and are having PTL elections for Ironic. Please rank all candidates in your order of preference. You are eligible to vote in the TC election if you are a Foundation individual member[0] that also has committed to any official project team's deliverable repositories[1] over the Sep 17, 2021 00:00 UTC - Sep 07, 2022 00:00 UTC timeframe (Yoga to Zed) or if you are in the list of extra-atcs[2] for any official project team. You are eligible to vote in a PTL election if you are a Foundation individual member[0] and had a commit in one of that team's deliverable repositories[1] over the Sep 17, 2021 00:00 UTC - Sep 07, 2022 00:00 UTC timeframe (Yoga to Zed) or if you are in that team's list of extra-atcs[2]. If you are eligible to vote in an election, you should find your email with a link to the Condorcet page to cast your vote in the inbox of your Gerrit preferred email[3]. What to do if you don't see the email and have a commit in at least one of the projects having an election: * check the trash or spam folders of your gerrit Preferred Email address, in case it went into trash or spam * wait a bit and check again, in case your email server is a bit slow * find the sha of at least one commit from the project's deliverable repos[0] and email the election officials [4] * requires opt-in to CIVS polling to receive email communications from the voting system [5]. If we can confirm that you are entitled to vote, we will add you to the voters list for the appropriate election. Our democratic process is important to the health of OpenStack, please exercise your right to vote! Candidate statements/platforms can be found linked to Candidate names on this page: https://governance.openstack.org/election/ Happy voting, /Ian, as one of OpenStack Election Officials [0] https://www.openstack.org/community/members/ [1] The list of the repositories eligible for electoral status: https://opendev.org/openstack/governance/src/tag/oct-2022-elections/reference/projects.yaml [2] Look for the extra-atcs element in [1] [3] Sign into review.openstack.org: Go to Settings > Contact Information. Look at the email listed as your preferred email. That is where the ballot has been sent. [4] https://governance.openstack.org/election/#election-officials [5] https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030433.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdhasman at redhat.com Tue Sep 13 06:12:11 2022 From: rdhasman at redhat.com (Rajat Dhasmana) Date: Tue, 13 Sep 2022 11:42:11 +0530 Subject: [cinder][stable] cinder-stable-core additions Message-ID: Hi All, After discussing with the current members of the cinder stable core team, I've decided to add the following members to the cinder stable core team. 1) Walter Boring - (Currently cinder core) 2) Sofia Enriquez - (Currently cinder core) Sofia and Walt have been long term contributors in the Cinder project and I'm happy to have them as part of the stable core team. I will proceed with making changes to the stable core team[1]. [1] https://review.opendev.org/admin/groups/1b3ca2faf07b15efff426901a387eb7c914695df,members Thanks and Regards Rajat Dhasmana -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Tue Sep 13 06:30:08 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Tue, 13 Sep 2022 12:00:08 +0530 Subject: [ptl][tc][election][adjutant][barbican][OpenStackSDK][OpenStack_Charms][sahara][swift][venus] Leaderless project for 2023.1 cycle In-Reply-To: References: <183325bd8cc.cccddafd1207362.5111479954134225007@ghanshyammann.com> Message-ID: <183358a70ad.115b351a91229313.6401238469888468375@ghanshyammann.com> ---- On Tue, 13 Sep 2022 01:51:02 +0530 Alex Kavanagh wrote --- > Hi > On Mon, 12 Sept 2022 at 16:46, Ghanshyam Mann gmann at ghanshyammann.com> wrote: > Hello, > > As you know, 2023.1 cycle election nomination is ended and we end up with 11 leaderless > projects. List is in the etherpad: https://etherpad.opendev.org/p/2023.1-leaderless > > Out of 11, we have found 4 projects leaders but 7 (in the subject list) projects still need some > leaders to volunteer: > > 1. Adjutant > 2. Barbican > 3. OpenStackSDK > 3. OpenStack_Charms > 4. Sahara > 5. Swift > 6. Venus > > Please reply here or ping us in #openstack-tc channel if you would like to lead > these projects. > > I put my nomination in for OpenStack_Charms on the mailing list, but didn't do the review; it completely slipped my mind that I needed to; sorry!? I'd like to be the PTL for the OpenStack charms project again, please, and I believe have the blessing of the team. > Thanks Thanks Alex, no issue. I have noted your volunteering for PTL in etherpad for TC to discuss it. - https://etherpad.opendev.org/p/2023.1-leaderless > Alex (tinwood).? > -gmann > > > > > > -- > Alex Kavanagh - Software EngineerOpenStack Engineering - Data Centre Development - Canonical Ltd > From tobias.rydberg at cleura.com Tue Sep 13 06:58:58 2022 From: tobias.rydberg at cleura.com (Tobias Rydberg) Date: Tue, 13 Sep 2022 08:58:58 +0200 Subject: [publiccloud-sig] Bi-weekly meeting reminder Message-ID: <9e152cbc-aeb4-c52f-3b0a-b41c9b03f042@cleura.com> Hi all, Tomorrow we will have our bi-weekly meeting at 0800 UTC in #openstack-operators. Notes from previous meeting can be found here [0]. Please go in prior to the meeting and vote for for the naming conventions suggested, which you believe are the most important or if you think some of them should not be considered at all. Hope to chat with you tomorrow! [0] https://etherpad.opendev.org/p/publiccloud-sig-meeting BR, Tobias Rydberg -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3626 bytes Desc: S/MIME Cryptographic Signature URL: From cjeanner at redhat.com Tue Sep 13 07:20:05 2022 From: cjeanner at redhat.com (=?UTF-8?Q?C=c3=a9dric_Jeanneret?=) Date: Tue, 13 Sep 2022 09:20:05 +0200 Subject: [tripleo] Switching to nftables - it's coming soon! Message-ID: <31cf9e93-2ac0-015e-8ab2-059f24c21c0e@redhat.com> Hello there, TLDR; we're about to switch to nftables[1], there are some changes described in the up-to-date doc. Reason is: faster, more modern interface, close to no possibility to get locked out of the system. Also, once it's switched, please use `nft list ruleset' instead of `iptables -L'. [1] https://review.opendev.org/c/openstack/tripleo-heat-templates/+/852808 Longer version: I've been working a good amount of time in order to get rid of the current tripleo_iptables custom action. On of the reasons here was the fact we could get locked out the overcloud if, for any reason, a network reset happens in ansible during the application of the rules. For the records, tripleo_iptables is calling the native "iptables" module from ansible, just doing a batching of the ruleset in an attempt to apply everything faster. It has some weird things, such as reversing the rule order before applying them using the "insert" action, meaning it will lock everything first, then open one by one the accesses. Knowing "ssh" is like 003 rule, you can imagine how things can go wrong. So, I took the opportunity to make some changes. While doing so, I saw `iptables' was just a compatibility wrapper for nftables - basically, `iptables' is a symlink to `iptables-nft', so I also took the opportunity to bypass it, and go straight for `nft'. Doing so, I created a new tripleo_nftables role in tripleo-ansible project; it's "just" creating files based on templates, then validates the whole lot of files, and applies all the rules in one single transaction. Compared to tripleo_iptables, it's really more robust, while being faster, and less prone to lock out and other unwanted things. The current state is: we're close, really close to switch things up. We're missing 2 patches in the CI to make the infra properly supported, and then, there's "the" switch itself. What will change: almost nothing: the way we create rules in tripleo-heat-templates and the different parameters therein doesn't change at all; the thing that will really change is the way to list the rules: instead of calling `iptables -vnL' or the like, you'll need to call `nft list ruleset'. Now, in order to make things easier, the doc is already up-to-date: https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/security_hardening.html#firewall-management As you will see, there will be some differences in the actual layout: all of the tripleo rules will be in dedicated chains, prefixed by TRIPLEO_ - for instance, TRIPLEO_INPUT, TRIPLEO_OUTPUT, TRIPLEO_FORWARD, and so on. This allows to get a cleaner layout, cleaner way to filter the output and, really important thing, to ensure we're cleaning dangling rules - the TRIPLEO_* chains will be flushed before the ruleset are added. All in one single transaction. Some more information/content: tripleo_nftables role: https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ansible/roles/tripleo_nftables Doc: https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/features/security_hardening.html#firewall-management Debug files available in the CI: log of dropped packets: https://logserver.rdoproject.org/54/31954/87/check/periodic-tripleo-ci-centos-9-ovb-3ctlr_1comp_1supp-featureset039-master/f14d78e/logs/undercloud/var/log/extra/dropped-packets.txt.gz nftables configuration dump: https://logserver.rdoproject.org/54/31954/87/check/periodic-tripleo-ci-centos-9-ovb-3ctlr_1comp_1supp-featureset039-master/f14d78e/logs/undercloud/var/log/extra/nftables.txt.gz nftables configuration: https://logserver.rdoproject.org/54/31954/87/check/periodic-tripleo-ci-centos-9-ovb-3ctlr_1comp_1supp-featureset039-master/f14d78e/logs/undercloud/etc/nftables/ All of that can help understanding the potential issues you may encounter. As a side note, we've been testing the whole thing for about a month now, correcting issues, updating the doc and making sure at least all of the current CI jobs (yes: ALL) are green without any weird behavior. A doc has been created in order to list the current state, with what we've seen, what we've done: https://hackmd.io/F0W2gYw_SiaiWkowjFU9cw?view#NFTABLES-testing-results Brace yourself, the change is coming :). But it should be transparent ;). -- C?dric Jeanneret (He/Him/His) Sr. Software Engineer - OpenStack Platform Deployment Framework TC Red Hat EMEA https://www.redhat.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From cjeanner at redhat.com Tue Sep 13 07:27:57 2022 From: cjeanner at redhat.com (=?UTF-8?Q?C=c3=a9dric_Jeanneret?=) Date: Tue, 13 Sep 2022 09:27:57 +0200 Subject: [tripleo] puppetlabs-apache: soon a just a bad memory? Message-ID: Hello Community! TLDR; puppetlabs-apache broke us so many times, I'm proposing a way to get rid of it, using plain ansible. Some work is needed, but it's "easy", and will allow us to keep a hand on the whole configuration code. Longer version: You probably saw mails about issues with puppetlabs-apache releases breaking the CI (and, by extension, TripleO). Over and over and over again. Well, good news: this may be just a bad memory - though it will require some work :). I've been working on a couple of ansible roles[1] in order to just get the needed pieces we really need in TripleO: file generation. Once we get those 2 roles in, we'll be able to switch, service by service, away from puppet management for apache/httpd. There's already an on-going example[2] with ironic. Of course, as you can see, there's some work to do, even on the puppet side. But it's not really complicated, and can be done quickly. I'll do my best to move things, but be prepared to get pings from time to time if help is needed. I can't do all by myself, can I? ;) And if anyone wants to jump in and work on the transition, please do, and don't hesitate to reach to me, either by mail, or on #tripleo - I go there as Tengu. Cheers, C. [1] https://review.opendev.org/c/openstack/tripleo-ansible/+/853481 [2] https://review.opendev.org/q/topic:standalone%252Fapache -- C?dric Jeanneret (He/Him/His) Sr. Software Engineer - OpenStack Platform Deployment Framework TC Red Hat EMEA https://www.redhat.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From katonalala at gmail.com Tue Sep 13 08:03:00 2022 From: katonalala at gmail.com (Lajos Katona) Date: Tue, 13 Sep 2022 10:03:00 +0200 Subject: Openstack.io is down In-Reply-To: References: Message-ID: Hi, I checked this morning and stackalitics.io seems now back, perhaps it was only a glitch of the service. Lajos Elvira Garcia Ruiz ezt ?rta (id?pont: 2022. szept. 12., H, 10:45): > Hi everyone! > I noticed that stackalytics.io has been down for several days now. > As far as I know this was widely used by the community, although it is not > part of OpenInfra as a project. > > I'm not sure who was maintaining this, but I just wanted to make them > aware of the problem, and also thank them for keeping it up and running. > > Kind regards! > Elvira Garc?a > (irc:elvira) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From park0kyung0won at dgist.ac.kr Tue Sep 13 09:06:44 2022 From: park0kyung0won at dgist.ac.kr (=?UTF-8?B?67CV6rK97JuQ?=) Date: Tue, 13 Sep 2022 18:06:44 +0900 (KST) Subject: [openstack yova][nova-spiceproxy] Spice proxy behind SSL termination: protocol mismatch error in horizon web UI Message-ID: <2027573781.66320.1663060004844.JavaMail.root@mailwas2> An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Tue Sep 13 09:15:06 2022 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Tue, 13 Sep 2022 11:15:06 +0200 Subject: [openstack yova][nova-spiceproxy] Spice proxy behind SSL termination: protocol mismatch error in horizon web UI In-Reply-To: <2027573781.66320.1663060004844.JavaMail.root@mailwas2> References: <2027573781.66320.1663060004844.JavaMail.root@mailwas2> Message-ID: Hi! This is because you need to proxy the websocket protocol. You may want to read up on it in [1] and [2]. [2] being the reference point and [1] being an introductory blog post with a simple app example to try out if your config is all right. [1] https://www.nginx.com/blog/websocket-nginx/ [2] http://nginx.org/en/docs/http/websocket.html Kind regards, Radek -yoctozepto On Tue, 13 Sept 2022 at 11:11, ??? wrote: > Hello > > > I'm trying to deploy openstack services behind the NGINX reverse proxy > > NGINX is in charge of SSL termination, and communicates with openstack > services unencrypted > > > When I set "html5proxy_base_url" option in [spice] section of nova.conf > file to "http://my-domain-name:6082/spice_auto.html", > > spice console in web UI works(by manually typing > http://my-domain-name:6082/spice_auto.html in browser address tab), but chrome > refuses to load spice console because its http > > > If I change html5proxy_base_url to " > https://my-domain-name:6082/spice_auto.html", > > spice console page(spice_auto.html) loads in chrome, but console itself is > blank > > And I get following errors from chrome developer tools console: > > > >> disconnect spice_auto.html?toke?8-3a537f56f5b0):144 > > << disconnect spice_auto.html?toke?8-3a537f56f5b0):157 > > ERROR: Error: Unexpected protocol mismatch. > > > Seems like spice-html5 uses different protocol based on > "html5proxy_base_url" option in /etc/nova/nova.conf (whether its https:// > or http://) > > How can I deploy nova-spiceproxy behind the NGINX reverse proxy, while > NGINX is acting as SSL termination point? > > > Thanks > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Tue Sep 13 10:19:29 2022 From: skaplons at redhat.com (Slawek Kaplonski) Date: Tue, 13 Sep 2022 12:19:29 +0200 Subject: Openstack.io is down In-Reply-To: References: Message-ID: <26827498.VBux9s3cu7@p1> Hi, Dnia wtorek, 13 wrze?nia 2022 10:03:00 CEST Lajos Katona pisze: > Hi, > I checked this morning and stackalitics.io seems now back, perhaps it was > only a glitch of the service. It was down for last few days I think but indeed it's back now. Thx a lot for whoever fixed it :) > > Lajos > > Elvira Garcia Ruiz ezt ?rta (id?pont: 2022. szept. > 12., H, 10:45): > > > Hi everyone! > > I noticed that stackalytics.io has been down for several days now. > > As far as I know this was widely used by the community, although it is not > > part of OpenInfra as a project. > > > > I'm not sure who was maintaining this, but I just wanted to make them > > aware of the problem, and also thank them for keeping it up and running. > > > > Kind regards! > > Elvira Garc?a > > (irc:elvira) > > > -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From ramishra at redhat.com Tue Sep 13 11:58:11 2022 From: ramishra at redhat.com (Rabi Mishra) Date: Tue, 13 Sep 2022 17:28:11 +0530 Subject: [TripleO] TripleO Antelope PTG Topics Message-ID: Hi All, Please add your session proposals to this etherpad[1]. We'll reserve time allocation based on proposed topics and work out a schedule in the coming weeks. [1] https://etherpad.opendev.org/p/tripleo-antelope-topics -- Regards, Rabi Mishra -------------- next part -------------- An HTML attachment was scrubbed... URL: From amotoki at gmail.com Tue Sep 13 12:22:13 2022 From: amotoki at gmail.com (Akihiro Motoki) Date: Tue, 13 Sep 2022 21:22:13 +0900 Subject: [neutron] bug deputy report (week of Sep 5) Message-ID: Hi, I was a bug deputy last week. It was a quiet week and only two new bugs are unassigned. ## Unassigned * https://bugs.launchpad.net/neutron/+bug/1988793 OVN as a Provider Driver for Octavia in ovn-octavia-provider This is a request to add a limitation corresponding to bug 1901936 (manual failure over is not supported) to the document. Hopefully ovn-octavia-driver folks can update the limitations section in the doc. * Neutron 20.2 Unknown Chassis Issue https://bugs.launchpad.net/neutron/+bug/1989155 ralonso suggested to file a bug on this to OVN upstream. It seems an issue in OVN core and perhaps we can mark it as invalid in neutron. ## In Progress * https://bugs.launchpad.net/neutron/+bug/1989391 [OVN] Allowed Address Pairs which is netmask doesn't work Thanks, Akihiro Motoki (amotoki) From ozzzo at yahoo.com Tue Sep 13 15:37:59 2022 From: ozzzo at yahoo.com (Albert Braden) Date: Tue, 13 Sep 2022 15:37:59 +0000 (UTC) Subject: [Horizon] [train] Horizon port security group management fails In-Reply-To: References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> Message-ID: <1541763085.3101109.1663083479831@mail.yahoo.com> Unfortunately we are running RHOSP in which Train is the latest and greatest. This is what we see in horizon.log: [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid 139683266553600] [remote 10.232.233.11:57498] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau wrote: Hello, This is more likely to be a Horizon bug than an issue with Kolla itself, since Kolla doesn't change much from the default configuration. You should check Horizon logs in /var/log/kolla/horizon to find the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently. Cheers,Pierre Riteau (priteau) On Fri, 9 Sept 2022 at 15:41, Albert Braden wrote: We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port ". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From senrique at redhat.com Tue Sep 13 17:27:47 2022 From: senrique at redhat.com (Sofia Enriquez) Date: Tue, 13 Sep 2022 14:27:47 -0300 Subject: Outreachy 2022 - 2023? Message-ID: Hello, I'd like to propose myself as a mentor for this Outreachy round. However, I haven't seen any email on the mailing list announcing that OpenStack is joining this round. Please let me know if Openstack is going to sponsor the next rounds. Thanks in advance, Best, Sofia -- Sof?a Enriquez she/her Software Engineer Red Hat PnT IRC: @enriquetaso @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From senrique at redhat.com Tue Sep 13 18:01:14 2022 From: senrique at redhat.com (Sofia Enriquez) Date: Tue, 13 Sep 2022 15:01:14 -0300 Subject: Outreachy 2022 - 2023? In-Reply-To: References: Message-ID: Great, thanks for the update! ? On Tue, Sep 13, 2022 at 2:40 PM Dmitry Tantsur wrote: > Hi! > > While Mahati and I are still finalizing some details, OpenStack will > definitely participate in the upcoming round. > > Dmitry > > On Tue, Sep 13, 2022 at 7:28 PM Sofia Enriquez > wrote: > >> Hello, >> >> I'd like to propose myself as a mentor for this Outreachy round. However, >> I haven't seen any email on the mailing list announcing that OpenStack is >> joining this round. Please let me know if Openstack is going to sponsor the >> next rounds. >> >> Thanks in advance, >> Best, >> Sofia >> >> -- >> >> Sof?a Enriquez >> >> she/her >> >> Software Engineer >> >> Red Hat PnT >> >> IRC: @enriquetaso >> @RedHat Red Hat >> Red Hat >> >> >> >> -- Sof?a Enriquez she/her Software Engineer Red Hat PnT IRC: @enriquetaso @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurentfdumont at gmail.com Tue Sep 13 22:02:47 2022 From: laurentfdumont at gmail.com (Laurent Dumont) Date: Tue, 13 Sep 2022 18:02:47 -0400 Subject: [Horizon] [train] Horizon port security group management fails In-Reply-To: <1541763085.3101109.1663083479831@mail.yahoo.com> References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> <1541763085.3101109.1663083479831@mail.yahoo.com> Message-ID: If you are running RHOSP, you might have a support contract with Red Hat? Are you trying to remove all the security groups from a port that has port_security enabled? On Tue, Sep 13, 2022 at 11:53 AM Albert Braden wrote: > Unfortunately we are running RHOSP in which Train is the latest and > greatest. This is what we see in horizon.log: > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid > 139683266553600] [remote 10.232.233.11:57498] Failed to update port > 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and > rule:update_port:binding:vnic_type) and > rule:update_port:port_security_enabled) is disallowed by policy > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < > pierre at stackhpc.com> wrote: > > > Hello, > > This is more likely to be a Horizon bug than an issue with Kolla itself, > since Kolla doesn't change much from the default configuration. > > You should check Horizon logs in /var/log/kolla/horizon to find the error. > I would also encourage you to upgrade to a more recent release, since Train > has been marked as End of Life in Kolla recently. > > Cheers, > Pierre Riteau (priteau) > > On Fri, 9 Sept 2022 at 15:41, Albert Braden wrote: > > We're running kolla train and we're seeing an apparent bug when we try to > add or remove security groups on a port. We see error "Failed to update > port ". It works fine in CLI; we only see this in Horizon. Is this a > known bug, or are we doing something wrong? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From park0kyung0won at dgist.ac.kr Wed Sep 14 01:24:56 2022 From: park0kyung0won at dgist.ac.kr (=?UTF-8?B?67CV6rK97JuQ?=) Date: Wed, 14 Sep 2022 10:24:56 +0900 (KST) Subject: [openstack yova][nova-spiceproxy] Spice proxy behind SSL termination: protocol mismatch error in horizon web UI Message-ID: <715680211.77302.1663118698371.JavaMail.root@mailwas2> An HTML attachment was scrubbed... URL: From pierre at stackhpc.com Wed Sep 14 07:54:25 2022 From: pierre at stackhpc.com (Pierre Riteau) Date: Wed, 14 Sep 2022 09:54:25 +0200 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 In-Reply-To: References: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> Message-ID: Following the tagging of RC1 for CloudKitty, I have discovered that it is also impacted by this issue. I have prepared a patch [1]. We will need to tag RC2. [1] https://review.opendev.org/c/openstack/cloudkitty/+/857579 On Fri, 9 Sept 2022 at 16:34, Pierre Riteau wrote: > On Fri, 9 Sept 2022 at 16:14, Pierre Riteau wrote: > >> On Tue, 6 Sept 2022 at 12:40, Stephen Finucane >> wrote: >> >>> I did those yesterday. >>> >>> Aodh: https://review.opendev.org/c/openstack/aodh/+/855962 >>> Designate: https://review.opendev.org/c/openstack/designate/+/855965 >>> Manila: https://review.opendev.org/c/openstack/manila/+/855967 >>> Ironic: https://review.opendev.org/c/openstack/ironic/+/855969 >>> Heat: https://review.opendev.org/c/openstack/heat/+/855970 >>> Barbican: https://review.opendev.org/c/openstack/barbican/+/855972 >>> >>> The barbican one isn't correct and I need to respin it. The rest are >>> working as >>> expected though, as proven at [1]. >>> >>> Stephen >>> >>> [1] https://review.opendev.org/c/openstack/requirements/+/855973/ >> >> >> Hi, >> >> Rados?aw Piliszek (yoctozepto) and I have discovered that Blazar is also >> broken by the release of oslo.db 12.1.0: CI jobs are failing CI jobs in [1]. >> I will try to fix it like Stephen did for other projects, but I would >> like to flag that it is possible other projects are impacted: in particular >> we should check any smaller project that doesn't run CI jobs regularly. >> >> This reminds me of the breakage we had at the end of the last cycle with >> oslo.context 4.0.0 [2]. >> >> Cheers, >> Pierre Riteau (priteau) >> >> [1] https://review.opendev.org/c/openstack/blazar/+/856527 >> [2] >> https://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.html >> > > Thank you Stephen for your code, this made it an easy fix [1]. > > [1] https://review.opendev.org/c/openstack/blazar/+/856768 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From senrique at redhat.com Wed Sep 14 11:00:00 2022 From: senrique at redhat.com (Sofia Enriquez) Date: Wed, 14 Sep 2022 08:00:00 -0300 Subject: [cinder] Bug Report 09-14-2022 Message-ID: This is a bug report from 09-07-2022 to 09-14-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Medium - https://bugs.launchpad.net/cinder/+bug/1989271 " revert_snapshot_will_destory_attachment_with_lvm_backend." Fix proposed to master but Zuul voted -1. - https://bugs.launchpad.net/cinder/+bug/1989281 "IPV6 with lightos driver won't work." Unassigned. Low - https://bugs.launchpad.net/cinder/+bug/1988942 "Failed to set image property. Invalid input for field/attribute simplestreams_metadata. Value: ... is too long (HTTP 400)." Unassigned. - https://bugs.launchpad.net/cinder/+bug/1989280 "Wrong assertion methods in unit tests." Fix proposed to master. - https://bugs.launchpad.net/cinder/+bug/1989280 "Wrong assertion methods in unit tests." Fix proposed to master. - https://bugs.launchpad.net/cinder/+bug/1989176 "Hitachi driver: no message for resource lock." Fix proposed to master. Cheers, -- Sof?a Enriquez she/her Software Engineer Red Hat PnT IRC: @enriquetaso @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From ozzzo at yahoo.com Wed Sep 14 12:36:24 2022 From: ozzzo at yahoo.com (Albert Braden) Date: Wed, 14 Sep 2022 12:36:24 +0000 (UTC) Subject: [Horizon] [train] Horizon port security group management fails In-Reply-To: References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> <1541763085.3101109.1663083479831@mail.yahoo.com> Message-ID: <84891126.3588046.1663158984067@mail.yahoo.com> On CLI I can type "openstack port set --no-security-group " to remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group ". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups. I can successfully add security groups to a port via CLI, or I can remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon. Regarding RHOSP support; I assume that you are joking, or maybe haven't experienced the support that they offer. On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont wrote: If you are running RHOSP, you might have a support contract with Red Hat? Are you trying to remove all the security groups from a port that has port_security enabled? On Tue, Sep 13, 2022 at 11:53 AM Albert Braden wrote: Unfortunately we are running RHOSP in which Train is the latest and greatest. This is what we see in horizon.log: [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid 139683266553600] [remote 10.232.233.11:57498] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau wrote: Hello, This is more likely to be a Horizon bug than an issue with Kolla itself, since Kolla doesn't change much from the default configuration. You should check Horizon logs in /var/log/kolla/horizon to find the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently. Cheers,Pierre Riteau (priteau) On Fri, 9 Sept 2022 at 15:41, Albert Braden wrote: We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port ". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From swogatpradhan22 at gmail.com Wed Sep 14 13:13:26 2022 From: swogatpradhan22 at gmail.com (Swogat Pradhan) Date: Wed, 14 Sep 2022 18:43:26 +0530 Subject: cpu metric not getting created for resource instance Message-ID: Hi, I am trying out the heat autoscalling and i am facing an issue where the instance created doesn't have cpu metric (enabled in ceilometer polling.yaml file) (overcloud) [stack at hkg2director ~]$ gnocchi resource show 130a0dfd-4e43-4373-ad0c-b5ffd4fcca95 +-----------------------+---------------------------------------------------------------------+ | Field | Value | +-----------------------+---------------------------------------------------------------------+ | created_by_project_id | 7c9659572662449da4906cc77b33f21b | | created_by_user_id | 4cb066d9701440dea941c5157186d06d | | creator | 4cb066d9701440dea941c5157186d06d:7c9659572662449da4906cc77b33f21b | | ended_at | None | | id | 130a0dfd-4e43-4373-ad0c-b5ffd4fcca95 | | metrics | compute.instance.booting.time: c0f77048-a85d-48a3-92cd-cdca50b341e8 | | | disk.ephemeral.size: 46d77e5d-aba1-4b93-92eb-3a97f9512a3c | | | disk.root.size: 3f60cb9f-9c06-4ccc-b47d-d2ca899fe5ea | | | memory: 97f796ed-c26c-4625-8670-64cf004a7b26 | | | vcpus: 513908f9-1bba-429e-8106-3bf933f04a76 | | original_resource_id | 130a0dfd-4e43-4373-ad0c-b5ffd4fcca95 | | project_id | 5d922243077045c48fe4b075e386551b | | revision_end | None | | revision_start | 2022-09-14T13:00:53.216445+00:00 | | started_at | 2022-09-14T12:57:21.846635+00:00 | | type | instance | | user_id | c1905e3c5a374924980e851840e7f028 | +-----------------------+---------------------------------------------------------------------+ For other instances also i do not see any cpu metric. Now the issue is as cpu metric is not getting created the alarm is not getting any data from the VM in terms of cpu usage and my autoscaling feature is failing. Please suggest how to fix this issue. With regards, Swogat Pradhan -------------- next part -------------- An HTML attachment was scrubbed... URL: From swogatpradhan22 at gmail.com Wed Sep 14 13:14:28 2022 From: swogatpradhan22 at gmail.com (Swogat Pradhan) Date: Wed, 14 Sep 2022 18:44:28 +0530 Subject: cpu metric not getting created for resource instance | Openstack wallaby | Centos In-Reply-To: References: Message-ID: edited subject On Wed, Sep 14, 2022 at 6:43 PM Swogat Pradhan wrote: > Hi, > I am trying out the heat autoscalling and i am facing an issue where the > instance created doesn't have cpu metric (enabled in ceilometer > polling.yaml file) > (overcloud) [stack at hkg2director ~]$ gnocchi resource show > 130a0dfd-4e43-4373-ad0c-b5ffd4fcca95 > > +-----------------------+---------------------------------------------------------------------+ > | Field | Value > | > > +-----------------------+---------------------------------------------------------------------+ > | created_by_project_id | 7c9659572662449da4906cc77b33f21b > | > | created_by_user_id | 4cb066d9701440dea941c5157186d06d > | > | creator | > 4cb066d9701440dea941c5157186d06d:7c9659572662449da4906cc77b33f21b | > | ended_at | None > | > | id | 130a0dfd-4e43-4373-ad0c-b5ffd4fcca95 > | > | metrics | compute.instance.booting.time: > c0f77048-a85d-48a3-92cd-cdca50b341e8 | > | | disk.ephemeral.size: > 46d77e5d-aba1-4b93-92eb-3a97f9512a3c | > | | disk.root.size: > 3f60cb9f-9c06-4ccc-b47d-d2ca899fe5ea | > | | memory: 97f796ed-c26c-4625-8670-64cf004a7b26 > | > | | vcpus: 513908f9-1bba-429e-8106-3bf933f04a76 > | > | original_resource_id | 130a0dfd-4e43-4373-ad0c-b5ffd4fcca95 > | > | project_id | 5d922243077045c48fe4b075e386551b > | > | revision_end | None > | > | revision_start | 2022-09-14T13:00:53.216445+00:00 > | > | started_at | 2022-09-14T12:57:21.846635+00:00 > | > | type | instance > | > | user_id | c1905e3c5a374924980e851840e7f028 > | > > +-----------------------+---------------------------------------------------------------------+ > > For other instances also i do not see any cpu metric. > Now the issue is as cpu metric is not getting created the alarm is not > getting any data from the VM in terms of cpu usage and my autoscaling > feature is failing. > > Please suggest how to fix this issue. > > With regards, > Swogat Pradhan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrunge at matthias-runge.de Wed Sep 14 13:58:51 2022 From: mrunge at matthias-runge.de (Matthias Runge) Date: Wed, 14 Sep 2022 15:58:51 +0200 Subject: cpu metric not getting created for resource instance | Openstack wallaby | Centos In-Reply-To: References: Message-ID: On 14/09/2022 15:14, Swogat Pradhan wrote: > edited subject > > On Wed, Sep 14, 2022 at 6:43 PM Swogat Pradhan > > wrote: > Hi, I believe you are running into an issue in tripleo, fixed by this commit (or the corresponding backports). Matthias > Hi, > I am trying out the heat autoscalling?and i am facing an issue where > the instance created doesn't have cpu metric (enabled in ceilometer > polling.yaml file) > (overcloud) [stack at hkg2director ~]$ gnocchi resource show > 130a0dfd-4e43-4373-ad0c-b5ffd4fcca95 > +-----------------------+---------------------------------------------------------------------+ > | Field ? ? ? ? ? ? ? ? | Value > ? ? ? ? ? ? ? ? ? ? ? ? ? | > +-----------------------+---------------------------------------------------------------------+ > | created_by_project_id | 7c9659572662449da4906cc77b33f21b > ? ? ? ? ? ? ? ? ? ? ? ? ?| > | created_by_user_id ? ?| 4cb066d9701440dea941c5157186d06d > ? ? ? ? ? ? ? ? ? ? ? ? ?| > | creator ? ? ? ? ? ? ? | > 4cb066d9701440dea941c5157186d06d:7c9659572662449da4906cc77b33f21b ? | > | ended_at ? ? ? ? ? ? ?| None > ? ? ? ? ? ? ? ? ? ? ? ? ?| > | id ? ? ? ? ? ? ? ? ? ?| 130a0dfd-4e43-4373-ad0c-b5ffd4fcca95 > ? ? ? ? ? ? ? ? ? ? ? ? ?| > | metrics ? ? ? ? ? ? ? | compute.instance.booting.time: > c0f77048-a85d-48a3-92cd-cdca50b341e8 | > | ? ? ? ? ? ? ? ? ? ? ? | disk.ephemeral.size: > 46d77e5d-aba1-4b93-92eb-3a97f9512a3c ? ? ? ? ? | > | ? ? ? ? ? ? ? ? ? ? ? | disk.root.size: > 3f60cb9f-9c06-4ccc-b47d-d2ca899fe5ea ? ? ? ? ? ? ? ?| > | ? ? ? ? ? ? ? ? ? ? ? | memory: > 97f796ed-c26c-4625-8670-64cf004a7b26 ? ? ? ? ? ? ? ? ? ? ? ?| > | ? ? ? ? ? ? ? ? ? ? ? | vcpus: > 513908f9-1bba-429e-8106-3bf933f04a76 ? ? ? ? ? ? ? ? ? ? ? ? | > | original_resource_id ?| 130a0dfd-4e43-4373-ad0c-b5ffd4fcca95 > ? ? ? ? ? ? ? ? ? ? ? ? ?| > | project_id ? ? ? ? ? ?| 5d922243077045c48fe4b075e386551b > ? ? ? ? ? ? ? ? ? ? ? ? ?| > | revision_end ? ? ? ? ?| None > ? ? ? ? ? ? ? ? ? ? ? ? ?| > | revision_start ? ? ? ?| 2022-09-14T13:00:53.216445+00:00 > ? ? ? ? ? ? ? ? ? ? ? ? ?| > | started_at ? ? ? ? ? ?| 2022-09-14T12:57:21.846635+00:00 > ? ? ? ? ? ? ? ? ? ? ? ? ?| > | type ? ? ? ? ? ? ? ? ?| instance > ? ? ? ? ? ? ? ? ? ? ? ? ?| > | user_id ? ? ? ? ? ? ? | c1905e3c5a374924980e851840e7f028 > ? ? ? ? ? ? ? ? ? ? ? ? ?| > +-----------------------+---------------------------------------------------------------------+ > > For other instances also i do not see any cpu metric. > Now the issue is as cpu metric is not getting created the alarm is > not getting any data from the VM in terms of cpu usage and my > autoscaling feature is failing. > > Please suggest how to fix this issue. > > With regards, > Swogat Pradhan > From bshephar at redhat.com Wed Sep 14 14:41:12 2022 From: bshephar at redhat.com (Brendan Shephard) Date: Thu, 15 Sep 2022 00:41:12 +1000 Subject: [Horizon] [train] Horizon port security group management fails In-Reply-To: <84891126.3588046.1663158984067@mail.yahoo.com> References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> <1541763085.3101109.1663083479831@mail.yahoo.com> <84891126.3588046.1663158984067@mail.yahoo.com> Message-ID: <92876DF2-AAF8-44AF-BFCE-725E2A3AB393@redhat.com> Hi Albert, While I may not be the best person to address your Horizon concern. I can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell. Looking at your Horizon issue though. It seems the default policy file is what prevents you from updating that port. We can see the default policy like this for example: [root at controller-2 ~]# podman exec -it neutron_api oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled" "update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner" When you execute the command via the CLI, which user are you using? Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that?s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon. I too would suggest opening a support case. It sounds like you have previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I?m confident we can right whatever wrong may have occurred there. Let me know if I can help in any way. Regards, Brendan Shephard Senior Software Engineer Brisbane, Australia > On 14 Sep 2022, at 10:36 pm, Albert Braden wrote: > > On CLI I can type "openstack port set --no-security-group " to remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group ". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups. > > I can successfully add security groups to a port via CLI, or I can remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon. > > Regarding RHOSP support; I assume that you are joking, or maybe haven't experienced the support that they offer. > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont wrote: > > > If you are running RHOSP, you might have a support contract with Red Hat? > > Are you trying to remove all the security groups from a port that has port_security enabled? > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden > wrote: > Unfortunately we are running RHOSP in which Train is the latest and greatest. This is what we see in horizon.log: > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid 139683266553600] [remote 10.232.233.11:57498 ] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau > wrote: > > > Hello, > > This is more likely to be a Horizon bug than an issue with Kolla itself, since Kolla doesn't change much from the default configuration. > > You should check Horizon logs in /var/log/kolla/horizon to find the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently. > > Cheers, > Pierre Riteau (priteau) > > On Fri, 9 Sept 2022 at 15:41, Albert Braden > wrote: > We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port ". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From divius.inside at gmail.com Tue Sep 13 17:40:37 2022 From: divius.inside at gmail.com (Dmitry Tantsur) Date: Tue, 13 Sep 2022 19:40:37 +0200 Subject: Outreachy 2022 - 2023? In-Reply-To: References: Message-ID: Hi! While Mahati and I are still finalizing some details, OpenStack will definitely participate in the upcoming round. Dmitry On Tue, Sep 13, 2022 at 7:28 PM Sofia Enriquez wrote: > Hello, > > I'd like to propose myself as a mentor for this Outreachy round. However, > I haven't seen any email on the mailing list announcing that OpenStack is > joining this round. Please let me know if Openstack is going to sponsor the > next rounds. > > Thanks in advance, > Best, > Sofia > > -- > > Sof?a Enriquez > > she/her > > Software Engineer > > Red Hat PnT > > IRC: @enriquetaso > @RedHat Red Hat > Red Hat > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahati.chamarthy at gmail.com Tue Sep 13 18:03:02 2022 From: mahati.chamarthy at gmail.com (Mahati Chamarthy) Date: Tue, 13 Sep 2022 19:03:02 +0100 Subject: Outreachy 2022 - 2023? In-Reply-To: References: Message-ID: Hi Sofia, Thanks for reaching out! As Dmitry said, OpenStack is indeed participating in the upcoming round. Please submit your projects: https://www.outreachy.org/communities/cfp/openstack/ Feel free to let me know if you have any questions. Best, Mahati On Tue, Sep 13, 2022, 6:40 PM Dmitry Tantsur wrote: > Hi! > > While Mahati and I are still finalizing some details, OpenStack will > definitely participate in the upcoming round. > > Dmitry > > On Tue, Sep 13, 2022 at 7:28 PM Sofia Enriquez > wrote: > >> Hello, >> >> I'd like to propose myself as a mentor for this Outreachy round. However, >> I haven't seen any email on the mailing list announcing that OpenStack is >> joining this round. Please let me know if Openstack is going to sponsor the >> next rounds. >> >> Thanks in advance, >> Best, >> Sofia >> >> -- >> >> Sof?a Enriquez >> >> she/her >> >> Software Engineer >> >> Red Hat PnT >> >> IRC: @enriquetaso >> @RedHat Red Hat >> Red Hat >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From crodriguez at whitestack.com Tue Sep 13 21:53:58 2022 From: crodriguez at whitestack.com (=?UTF-8?Q?Carlos_Rodr=C3=ADguez?=) Date: Tue, 13 Sep 2022 17:53:58 -0400 Subject: [vitrage] RCA not showing on dashboard Message-ID: Hi, I hope find very well, We are using vitrage-dashboard, but right we are presenting problems displaying the RCA alarm graph. [image: vitrageerror.png] When clicking RCA button in any alarm, the graph is not displayed and the following error is shown in inspector: Error: layers[node.rank] is undefined Downgrading to vitrage-dashboard stable/train seems to solve the issue. For the latest releases, the issue is solved when the following commit is reverted: d181623f22 Replace embedded static files with XStatic-* It seems that there is some problem with the XStatic libraries. Tested in Chrome, Firefox, Edge. Openstack release: Victoria Are you working to solve this problem? Or do you have any solution to display the graph. Thanks for your time, kind regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vitrageerror.png Type: image/png Size: 1172560 bytes Desc: not available URL: From thierry at openstack.org Wed Sep 14 15:38:59 2022 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 14 Sep 2022 17:38:59 +0200 Subject: [largescale-sig] Next meeting: Sept 14th, 15utc In-Reply-To: <4cd237c1-6335-944d-0ebc-793d6d918cd3@openstack.org> References: <4cd237c1-6335-944d-0ebc-793d6d918cd3@openstack.org> Message-ID: <0831a0df-8a97-d1ac-761c-aa8553cc2ea2@openstack.org> Hi everyone, Here is the summary of our SIG meeting today. We discussed the contents of our Sept 29 OpenInfra Live episode (featuring a Deep Dive on Schwarz Gruppe). You can read the detailed meeting logs at: https://meetings.opendev.org/meetings/large_scale_sig/2022/large_scale_sig.2022-09-14-15.00.html Our next regular IRC meeting will be October 12, at 1500utc on #openstack-operators on OFTC. Regards, -- Thierry Carrez (ttx) From ozzzo at yahoo.com Wed Sep 14 16:25:23 2022 From: ozzzo at yahoo.com (Albert Braden) Date: Wed, 14 Sep 2022 16:25:23 +0000 (UTC) Subject: [Horizon] [train] Horizon port security group management fails In-Reply-To: <92876DF2-AAF8-44AF-BFCE-725E2A3AB393@redhat.com> References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> <1541763085.3101109.1663083479831@mail.yahoo.com> <84891126.3588046.1663158984067@mail.yahoo.com> <92876DF2-AAF8-44AF-BFCE-725E2A3AB393@redhat.com> Message-ID: <1338352317.3690165.1663172723209@mail.yahoo.com> Hi Brendan, thanks for offering to help! I'll contact you privately with info about some languishing cases. Here's the policy line: "update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner" Does this policy only affect Horizon? I'm using the same non-admin user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user. On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard wrote: Hi Albert, While I may not be the best person to address your Horizon concern. I can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell. Looking at your Horizon issue though. It seems the default policy file is what prevents you from updating that port. We can see the default policy like this for example: [root at controller-2 ~]# podman exec -it neutron_api oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled""update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner" When you execute the command via the CLI, which user are you using? Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that?s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon. I too would suggest opening a support case. It sounds like you have previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I?m confident we can right whatever wrong may have occurred there. Let me know if I can help in any way. Regards, Brendan Shephard Senior Software Engineer Brisbane, Australia On 14 Sep 2022, at 10:36 pm, Albert Braden wrote: On CLI I can type "openstack port set --no-security-group " to remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group ". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups. I can successfully add security groups to a port via CLI, or I can remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon. Regarding RHOSP support; I assume that you are joking, or maybe haven't experienced the support that they offer. On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont wrote: If you are running RHOSP, you might have a support contract with Red Hat? Are you trying to remove all the security groups from a port that has port_security enabled? On Tue, Sep 13, 2022 at 11:53 AM Albert Braden wrote: Unfortunately we are running RHOSP in which Train is the latest and greatest. This is what we see in horizon.log: [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid 139683266553600] [remote 10.232.233.11:57498] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau wrote: Hello, This is more likely to be a Horizon bug than an issue with Kolla itself, since Kolla doesn't change much from the default configuration. You should check Horizon logs in /var/log/kolla/horizon to find the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently. Cheers,Pierre Riteau (priteau) On Fri, 9 Sept 2022 at 15:41, Albert Braden wrote: We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port ". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Wed Sep 14 18:15:45 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 14 Sep 2022 18:15:45 +0000 Subject: [ironic][release][tc] Ilya Etingof Passed Away In-Reply-To: References: Message-ID: <20220914181544.5sprt6njkzfgly4i@yuggoth.org> On 2022-08-22 08:19:09 -0300 (-0300), Iury Gregory wrote: > With a heavy heart, I am sorry to announce that after a long > struggle with an illness, Ilya Etingof (etingof on IRC) passed > away on Wednesday, 10th August, 2022. [...] In the past, we've dedicated OpenStack releases to our departed colleagues and remembered them in public release communications. Having not known Ilya personally, I'm in a poor position to judge whether doing so with our upcoming release would be a welcome tribute. If it would, the process would be to propose a TC resolution similar to this: https://governance.openstack.org/tc/resolutions/20180206-dedicate-queens-to-shawn-pearce.html Iury: If you think it's something we should do, your touching eulogy could easily be the text of that resolution. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From mrunge at matthias-runge.de Wed Sep 14 18:42:31 2022 From: mrunge at matthias-runge.de (Matthias Runge) Date: Wed, 14 Sep 2022 20:42:31 +0200 Subject: cpu metric not getting created for resource instance | Openstack wallaby | Centos In-Reply-To: References: Message-ID: I just realised, I forgot to attach the commit https://github.com/openstack/tripleo-heat-templates/commit/96c9eb7a34dce1bfdaef4b92919ff562360cb65a Matthias > Am 14.09.2022 um 15:58 schrieb Matthias Runge : > > On 14/09/2022 15:14, Swogat Pradhan wrote: >> edited subject >> On Wed, Sep 14, 2022 at 6:43 PM Swogat Pradhan > wrote: > > Hi, > > I believe you are running into an issue in tripleo, fixed by this commit (or the corresponding backports). > > Matthias > >> Hi, >> I am trying out the heat autoscalling and i am facing an issue where >> the instance created doesn't have cpu metric (enabled in ceilometer >> polling.yaml file) >> (overcloud) [stack at hkg2director ~]$ gnocchi resource show >> 130a0dfd-4e43-4373-ad0c-b5ffd4fcca95 >> +-----------------------+---------------------------------------------------------------------+ >> | Field | Value | >> +-----------------------+---------------------------------------------------------------------+ >> | created_by_project_id | 7c9659572662449da4906cc77b33f21b | >> | created_by_user_id | 4cb066d9701440dea941c5157186d06d | >> | creator | >> 4cb066d9701440dea941c5157186d06d:7c9659572662449da4906cc77b33f21b | >> | ended_at | None | >> | id | 130a0dfd-4e43-4373-ad0c-b5ffd4fcca95 | >> | metrics | compute.instance.booting.time: >> c0f77048-a85d-48a3-92cd-cdca50b341e8 | >> | | disk.ephemeral.size: >> 46d77e5d-aba1-4b93-92eb-3a97f9512a3c | >> | | disk.root.size: >> 3f60cb9f-9c06-4ccc-b47d-d2ca899fe5ea | >> | | memory: >> 97f796ed-c26c-4625-8670-64cf004a7b26 | >> | | vcpus: >> 513908f9-1bba-429e-8106-3bf933f04a76 | >> | original_resource_id | 130a0dfd-4e43-4373-ad0c-b5ffd4fcca95 | >> | project_id | 5d922243077045c48fe4b075e386551b | >> | revision_end | None | >> | revision_start | 2022-09-14T13:00:53.216445+00:00 | >> | started_at | 2022-09-14T12:57:21.846635+00:00 | >> | type | instance | >> | user_id | c1905e3c5a374924980e851840e7f028 | >> +-----------------------+---------------------------------------------------------------------+ >> For other instances also i do not see any cpu metric. >> Now the issue is as cpu metric is not getting created the alarm is >> not getting any data from the VM in terms of cpu usage and my >> autoscaling feature is failing. >> Please suggest how to fix this issue. >> With regards, >> Swogat Pradhan > > From amy at demarco.com Wed Sep 14 21:54:50 2022 From: amy at demarco.com (Amy Marrich) Date: Wed, 14 Sep 2022 22:54:50 +0100 Subject: TC Election Double Ballots Message-ID: Hi everyone, As some of you have reported you have received 2 emails for the election. This was a result of our uploading the lists twice to make sure everyone who had to opt-in were included. Sorry for any confusion, Amy and the rest of the Election Officials -------------- next part -------------- An HTML attachment was scrubbed... URL: From laurentfdumont at gmail.com Wed Sep 14 22:00:09 2022 From: laurentfdumont at gmail.com (Laurent Dumont) Date: Wed, 14 Sep 2022 18:00:09 -0400 Subject: [Horizon] [train] Horizon port security group management fails In-Reply-To: <1338352317.3690165.1663172723209@mail.yahoo.com> References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> <1541763085.3101109.1663083479831@mail.yahoo.com> <84891126.3588046.1663158984067@mail.yahoo.com> <92876DF2-AAF8-44AF-BFCE-725E2A3AB393@redhat.com> <1338352317.3690165.1663172723209@mail.yahoo.com> Message-ID: That?s a bit strange. I?ll give it a try. Regarding RH support, I wasn?t trying to be sarcastic. Like any large scale support service, the quality might vary a little bit but it?s been fairly good in my personal experience. Of course, a good TAM and some poking is always a good asset. On Wed, Sep 14, 2022 at 12:25 PM Albert Braden wrote: > Hi Brendan, thanks for offering to help! I'll contact you privately with > info about some languishing cases. > > Here's the policy line: > "update_port:port_security_enabled": "rule:context_is_advsvc or > rule:admin_or_network_owner" > > Does this policy only affect Horizon? I'm using the same non-admin user > for both CLI and Horizon, on a project where that user is a member. The > network was created by the admin user. > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard < > bshephar at redhat.com> wrote: > > > Hi Albert, > > While I may not be the best person to address your Horizon concern. I can > probably help you with your Red Hat support concerns. If you had any issues > you wanted addressed, or feedback you wanted to provide. Feel free to give > me a yell. > > Looking at your Horizon issue though. It seems the default policy file is > what prevents you from updating that port. We can see the default policy > like this for example: > > [root at controller-2 ~]# podman exec -it neutron_api > oslopolicy-policy-generator --namespace neutron | grep > "update_port:port_security_enabled" > "update_port:port_security_enabled": "rule:context_is_advsvc or > rule:admin_or_network_owner" > > When you execute the command via the CLI, which user are you using? Are > you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. > If that?s the case then you would be using the admin user on the CLI, but > probably a different user when logging into Horizon. > > I too would suggest opening a support case. It sounds like you have > previously had a negative experience with that. If you want to open a new > one and share the case number with me, I can follow up on that for you. As > someone who personally knows a lot of the RHOSP Technical Support team from > around the world. I?m confident we can right whatever wrong may have > occurred there. > > Let me know if I can help in any way. > > Regards, > > Brendan Shephard > Senior Software Engineer > Brisbane, Australia > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden wrote: > > On CLI I can type "openstack port set --no-security-group " to remove > all security groups. In Horizon, the equivalent operation would be using > the - button to remove all groups and then clicking "Update." Using the + > button would be the equivalent of typing "openstack port set > --security-group ". There doesn't seem to be a way to remove a > single security group via CLI; I think the only way would be to set > --no-security-group and then add back the desired groups. > > I can successfully add security groups to a port via CLI, or I can remove > all security groups. If I go into Horizon and try these operations then I > get the error when I click "Update." So it appears that security groups can > be added and removed, with port security set, via CLI. We only see the > failure when we try to do it via Horizon. > > Regarding RHOSP support; I assume that you are joking, or maybe haven't > experienced the support that they offer. > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont < > laurentfdumont at gmail.com> wrote: > > > If you are running RHOSP, you might have a support contract with Red Hat? > > Are you trying to remove all the security groups from a port that has > port_security enabled? > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden wrote: > > Unfortunately we are running RHOSP in which Train is the latest and > greatest. This is what we see in horizon.log: > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid > 139683266553600] [remote 10.232.233.11:57498] Failed to update port > 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and > rule:update_port:binding:vnic_type) and > rule:update_port:port_security_enabled) is disallowed by policy > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < > pierre at stackhpc.com> wrote: > > > Hello, > > This is more likely to be a Horizon bug than an issue with Kolla itself, > since Kolla doesn't change much from the default configuration. > > You should check Horizon logs in /var/log/kolla/horizon to find the error. > I would also encourage you to upgrade to a more recent release, since Train > has been marked as End of Life in Kolla recently. > > Cheers, > Pierre Riteau (priteau) > > On Fri, 9 Sept 2022 at 15:41, Albert Braden wrote: > > We're running kolla train and we're seeing an apparent bug when we try to > add or remove security groups on a port. We see error "Failed to update > port ". It works fine in CLI; we only see this in Horizon. Is this a > known bug, or are we doing something wrong? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bshephar at redhat.com Wed Sep 14 22:59:57 2022 From: bshephar at redhat.com (Brendan Shephard) Date: Thu, 15 Sep 2022 08:59:57 +1000 Subject: [Neutron] [train] Horizon port security group management fails In-Reply-To: <1338352317.3690165.1663172723209@mail.yahoo.com> References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> <1541763085.3101109.1663083479831@mail.yahoo.com> <84891126.3588046.1663158984067@mail.yahoo.com> <92876DF2-AAF8-44AF-BFCE-725E2A3AB393@redhat.com> <1338352317.3690165.1663172723209@mail.yahoo.com> Message-ID: <2EA66220-F3CE-4D0A-B8B3-9D67AA5E1AE9@redhat.com> Hey Albert, The policy is the default Neutron policy in OpenStack Train. These can indeed be changed and customised, but my assumption is that you haven?t created any custom policies. Horizon uses the default for each service unless it?s been overwritten. If I create a non-admin user and try to change security groups I also get the same error: 2022-09-14 22:01:33,370 64 INFO openstack_dashboard.dashboards.project.networks.ports.workflows Failed to update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy And I can reproduce your same scenario ff I try via the CLI using these steps: 1. Add entry for new user to clouds.yaml file: bne-home-test: auth: auth_url: https://openstack.bne-home.net:13000 password: "test" project_domain_name: Default project_name: bne-home user_domain_name: Default username: test cacert: ~/.certs/overcloud-cacert.pem identity_api_version: '3' region_name: regionOne volume_api_version: ?3' 2. export OS_CLOUD=bne-home-test 3. Try to remove security group from port: ? openstack server show test-lb-net -c security_groups -c addresses -f yaml addresses: lb-mgmt-net: - 172.24.0.90 vlan4-infra: - 172.20.13.175 security_groups: - name: management-bne ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips -c port_security_enabled -c security_group_ids -f yaml fixed_ips: - ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 port_security_enabled: true security_group_ids: - a3ae6e20-67df-4a72-9d5b-cc21ad87464f ? openstack port unset --security-group a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips -c port_security_enabled -c security_group_ids -f yaml fixed_ips: - ip_address: 172.20.13.175 subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 port_security_enabled: true security_group_ids: [] Verify that I?m definitely not a admin user: ? openstack server list --all Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8) I don?t think this user should be allowed to do that via the CLI either. So that could be a bug there. The request in the Neutron server.log when I do it via the CLI: 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480 VS Horizon: 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103 I have raised a upstream bug for this since I can still reproduce it on the latest version of OpenStack: https://bugs.launchpad.net/neutron/+bug/1989627? Bug #1989627 ?Policy enforcement variance between openstackcli a...? : Bugs : neutron bugs.launchpad.net Brendan Shephard Senior Software Engineer Brisbane, Australia > On 15 Sep 2022, at 2:25 am, Albert Braden wrote: > > Hi Brendan, thanks for offering to help! I'll contact you privately with info about some languishing cases. > > Here's the policy line: > "update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner" > > Does this policy only affect Horizon? I'm using the same non-admin user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user. > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard wrote: > > > Hi Albert, > > While I may not be the best person to address your Horizon concern. I can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell. > > Looking at your Horizon issue though. It seems the default policy file is what prevents you from updating that port. We can see the default policy like this for example: > > [root at controller-2 ~]# podman exec -it neutron_api oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled" > "update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner" > > When you execute the command via the CLI, which user are you using? Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that?s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon. > > I too would suggest opening a support case. It sounds like you have previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I?m confident we can right whatever wrong may have occurred there. > > Let me know if I can help in any way. > > Regards, > > Brendan Shephard > Senior Software Engineer > Brisbane, Australia > > > >> On 14 Sep 2022, at 10:36 pm, Albert Braden wrote: >> >> On CLI I can type "openstack port set --no-security-group " to remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group ". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups. >> >> I can successfully add security groups to a port via CLI, or I can remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon. >> >> Regarding RHOSP support; I assume that you are joking, or maybe haven't experienced the support that they offer. >> On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont wrote: >> >> >> If you are running RHOSP, you might have a support contract with Red Hat? >> >> Are you trying to remove all the security groups from a port that has port_security enabled? >> >> On Tue, Sep 13, 2022 at 11:53 AM Albert Braden > wrote: >> Unfortunately we are running RHOSP in which Train is the latest and greatest. This is what we see in horizon.log: >> >> [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid 139683266553600] [remote 10.232.233.11:57498 ] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy >> On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau > wrote: >> >> >> Hello, >> >> This is more likely to be a Horizon bug than an issue with Kolla itself, since Kolla doesn't change much from the default configuration. >> >> You should check Horizon logs in /var/log/kolla/horizon to find the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently. >> >> Cheers, >> Pierre Riteau (priteau) >> >> On Fri, 9 Sept 2022 at 15:41, Albert Braden > wrote: >> We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port ". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong? >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: launchpad-og-image.png Type: image/png Size: 5194 bytes Desc: not available URL: From yasufum.o at gmail.com Thu Sep 15 07:59:57 2022 From: yasufum.o at gmail.com (Yasufumi Ogawa) Date: Thu, 15 Sep 2022 16:59:57 +0900 Subject: [tacker] Recent FT errors Message-ID: <4ecd1560-e74b-c76b-efea-8dd0ca39b23c@gmail.com> Hi tacker team, We've several unexpected failures on functional tests since last week or so. It might be because of new tests introduced in the recent some updates, and some lackness of resources on zuul tests we usually meet the same situation at the end of release possibly. Thanks to ueha to propose a patch [1] as a remedy for the issue, but it doesn't work for now unfortunately. For plan B, we can make the new tests non-voting for a while because it's not related to all reamined patches being reviewed now actually. We can revert it and focus on to fix the problem after RC1 is released. What do you think? [1] https://review.opendev.org/c/openstack/tacker/+/857551 Yasufumi From ueha.ayumu at fujitsu.com Thu Sep 15 08:15:53 2022 From: ueha.ayumu at fujitsu.com (ueha.ayumu at fujitsu.com) Date: Thu, 15 Sep 2022 08:15:53 +0000 Subject: [tacker] Recent FT errors In-Reply-To: <4ecd1560-e74b-c76b-efea-8dd0ca39b23c@gmail.com> References: <4ecd1560-e74b-c76b-efea-8dd0ca39b23c@gmail.com> Message-ID: Hi Yasufumi, Thanks for your suggestion! I agree with you. > we can make the new tests non-voting I think it is better to make the old tests (legacy and lib-master) non-voting too, because the old tests has also failed recently. What do you think? Best regards, Ueha -----Original Message----- From: Yasufumi Ogawa Sent: Thursday, September 15, 2022 5:00 PM To: openstack-discuss Subject: [tacker] Recent FT errors Hi tacker team, We've several unexpected failures on functional tests since last week or so. It might be because of new tests introduced in the recent some updates, and some lackness of resources on zuul tests we usually meet the same situation at the end of release possibly. Thanks to ueha to propose a patch [1] as a remedy for the issue, but it doesn't work for now unfortunately. For plan B, we can make the new tests non-voting for a while because it's not related to all reamined patches being reviewed now actually. We can revert it and focus on to fix the problem after RC1 is released. What do you think? [1] https://review.opendev.org/c/openstack/tacker/+/857551 Yasufumi From yasufum.o at gmail.com Thu Sep 15 08:23:21 2022 From: yasufum.o at gmail.com (Yasufumi Ogawa) Date: Thu, 15 Sep 2022 17:23:21 +0900 Subject: [tacker] Recent FT errors In-Reply-To: References: <4ecd1560-e74b-c76b-efea-8dd0ca39b23c@gmail.com> Message-ID: <2c030e90-2ec2-b23c-3958-f830faf39762@gmail.com> Ayumu, On 2022/09/15 17:15, ueha.ayumu at fujitsu.com wrote: > Hi Yasufumi, > > Thanks for your suggestion! I agree with you. > >> we can make the new tests non-voting > I think it is better to make the old tests (legacy and lib-master) non-voting too, > because the old tests has also failed recently. > What do you think? I'd agree if waiting patches don't depend on these tests. > > Best regards, > Ueha > > -----Original Message----- > From: Yasufumi Ogawa > Sent: Thursday, September 15, 2022 5:00 PM > To: openstack-discuss > Subject: [tacker] Recent FT errors > > Hi tacker team, > > We've several unexpected failures on functional tests since last week or so. It might be because of new tests introduced in the recent some updates, and some lackness of resources on zuul tests we usually meet the same situation at the end of release possibly. > > Thanks to ueha to propose a patch [1] as a remedy for the issue, but it doesn't work for now unfortunately. For plan B, we can make the new tests non-voting for a while because it's not related to all reamined patches being reviewed now actually. We can revert it and focus on to fix the problem after RC1 is released. What do you think? > > [1] https://review.opendev.org/c/openstack/tacker/+/857551 > > Yasufumi > From ueha.ayumu at fujitsu.com Thu Sep 15 08:29:45 2022 From: ueha.ayumu at fujitsu.com (ueha.ayumu at fujitsu.com) Date: Thu, 15 Sep 2022 08:29:45 +0000 Subject: [tacker] Recent FT errors In-Reply-To: <2c030e90-2ec2-b23c-3958-f830faf39762@gmail.com> References: <4ecd1560-e74b-c76b-efea-8dd0ca39b23c@gmail.com> <2c030e90-2ec2-b23c-3958-f830faf39762@gmail.com> Message-ID: Hi Yasufumi, I think waiting patches don't depend on these tests because these tests are for legacy implementation of Tacker. -----Original Message----- Ayumu, On 2022/09/15 17:15, ueha.ayumu at fujitsu.com wrote: > Hi Yasufumi, > > Thanks for your suggestion! I agree with you. > >> we can make the new tests non-voting > I think it is better to make the old tests (legacy and lib-master) > non-voting too, because the old tests has also failed recently. > What do you think? I'd agree if waiting patches don't depend on these tests. > > Best regards, > Ueha > > -----Original Message----- > From: Yasufumi Ogawa > Sent: Thursday, September 15, 2022 5:00 PM > To: openstack-discuss > Subject: [tacker] Recent FT errors > > Hi tacker team, > > We've several unexpected failures on functional tests since last week or so. It might be because of new tests introduced in the recent some updates, and some lackness of resources on zuul tests we usually meet the same situation at the end of release possibly. > > Thanks to ueha to propose a patch [1] as a remedy for the issue, but it doesn't work for now unfortunately. For plan B, we can make the new tests non-voting for a while because it's not related to all reamined patches being reviewed now actually. We can revert it and focus on to fix the problem after RC1 is released. What do you think? > > [1] https://review.opendev.org/c/openstack/tacker/+/857551 > > Yasufumi > From yasufum.o at gmail.com Thu Sep 15 08:37:12 2022 From: yasufum.o at gmail.com (Yasufumi Ogawa) Date: Thu, 15 Sep 2022 17:37:12 +0900 Subject: [tacker] Recent FT errors In-Reply-To: References: <4ecd1560-e74b-c76b-efea-8dd0ca39b23c@gmail.com> <2c030e90-2ec2-b23c-3958-f830faf39762@gmail.com> Message-ID: <488a48c4-679e-a9d2-e435-c714569a3018@gmail.com> On 2022/09/15 17:29, ueha.ayumu at fujitsu.com wrote: > Hi Yasufumi, > > I think waiting patches don't depend on these tests > because these tests are for legacy implementation of Tacker. Thanks for the reply quickly. I've realized that. So, could you update your patch for canceling these tests if no other one opposite to the temporary fix? Yasufumi > > -----Original Message----- > > Ayumu, > > On 2022/09/15 17:15, ueha.ayumu at fujitsu.com wrote: >> Hi Yasufumi, >> >> Thanks for your suggestion! I agree with you. >> >>> we can make the new tests non-voting >> I think it is better to make the old tests (legacy and lib-master) >> non-voting too, because the old tests has also failed recently. >> What do you think? > I'd agree if waiting patches don't depend on these tests. > >> >> Best regards, >> Ueha >> >> -----Original Message----- >> From: Yasufumi Ogawa >> Sent: Thursday, September 15, 2022 5:00 PM >> To: openstack-discuss >> Subject: [tacker] Recent FT errors >> >> Hi tacker team, >> >> We've several unexpected failures on functional tests since last week or so. It might be because of new tests introduced in the recent some updates, and some lackness of resources on zuul tests we usually meet the same situation at the end of release possibly. >> >> Thanks to ueha to propose a patch [1] as a remedy for the issue, but it doesn't work for now unfortunately. For plan B, we can make the new tests non-voting for a while because it's not related to all reamined patches being reviewed now actually. We can revert it and focus on to fix the problem after RC1 is released. What do you think? >> >> [1] https://review.opendev.org/c/openstack/tacker/+/857551 >> >> Yasufumi >> From ueha.ayumu at fujitsu.com Thu Sep 15 09:09:46 2022 From: ueha.ayumu at fujitsu.com (ueha.ayumu at fujitsu.com) Date: Thu, 15 Sep 2022 09:09:46 +0000 Subject: [tacker] Recent FT errors In-Reply-To: <488a48c4-679e-a9d2-e435-c714569a3018@gmail.com> References: <4ecd1560-e74b-c76b-efea-8dd0ca39b23c@gmail.com> <2c030e90-2ec2-b23c-3958-f830faf39762@gmail.com> <488a48c4-679e-a9d2-e435-c714569a3018@gmail.com> Message-ID: There seems to be no objection, so I will update the patch. Thanks! Best Regards, Ueha -----Original Message----- On 2022/09/15 17:29, ueha.ayumu at fujitsu.com wrote: > Hi Yasufumi, > > I think waiting patches don't depend on these tests because these > tests are for legacy implementation of Tacker. Thanks for the reply quickly. I've realized that. So, could you update your patch for canceling these tests if no other one opposite to the temporary fix? Yasufumi > > -----Original Message----- > > Ayumu, > > On 2022/09/15 17:15, ueha.ayumu at fujitsu.com wrote: >> Hi Yasufumi, >> >> Thanks for your suggestion! I agree with you. >> >>> we can make the new tests non-voting >> I think it is better to make the old tests (legacy and lib-master) >> non-voting too, because the old tests has also failed recently. >> What do you think? > I'd agree if waiting patches don't depend on these tests. > >> >> Best regards, >> Ueha >> >> -----Original Message----- >> From: Yasufumi Ogawa >> Sent: Thursday, September 15, 2022 5:00 PM >> To: openstack-discuss >> Subject: [tacker] Recent FT errors >> >> Hi tacker team, >> >> We've several unexpected failures on functional tests since last week or so. It might be because of new tests introduced in the recent some updates, and some lackness of resources on zuul tests we usually meet the same situation at the end of release possibly. >> >> Thanks to ueha to propose a patch [1] as a remedy for the issue, but it doesn't work for now unfortunately. For plan B, we can make the new tests non-voting for a while because it's not related to all reamined patches being reviewed now actually. We can revert it and focus on to fix the problem after RC1 is released. What do you think? >> >> [1] https://review.opendev.org/c/openstack/tacker/+/857551 >> >> Yasufumi >> From gmann at ghanshyammann.com Thu Sep 15 09:51:24 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 15 Sep 2022 15:21:24 +0530 Subject: [all][tc] Technical Committee next weekly meeting on 2022 Sept 15 at 1500 UTC Message-ID: <183408f6cfc.c58e67a91424449.4577633017143409342@ghanshyammann.com> Hello Everyone, Below is the agenda for Today's TC meeting schedule at 1500 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting * Roll call * Follow up on past action items * Gate health check ** Bare 'recheck' state *** https://etherpad.opendev.org/p/recheck-weekly-summary * 2023.1 cycle PTG Planning ** TC + Leaders interaction sessions *** https://etherpad.opendev.org/p/tc-leaders-interaction-2023-1 ** TC PTG etherpad *** https://etherpad.opendev.org/p/tc-2023-1-ptg ** Schedule 'operator hours' *** https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030301.html * 2023.1 cycle Technical Election & Leaderless projects ** https://governance.openstack.org/election/ ** https://etherpad.opendev.org/p/2023.1-leaderless ** https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030437.html * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open -gmann From smooney at redhat.com Thu Sep 15 10:47:34 2022 From: smooney at redhat.com (Sean Mooney) Date: Thu, 15 Sep 2022 11:47:34 +0100 Subject: [Neutron] [train] Horizon port security group management fails In-Reply-To: <2EA66220-F3CE-4D0A-B8B3-9D67AA5E1AE9@redhat.com> References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> <1541763085.3101109.1663083479831@mail.yahoo.com> <84891126.3588046.1663158984067@mail.yahoo.com> <92876DF2-AAF8-44AF-BFCE-725E2A3AB393@redhat.com> <1338352317.3690165.1663172723209@mail.yahoo.com> <2EA66220-F3CE-4D0A-B8B3-9D67AA5E1AE9@redhat.com> Message-ID: On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote: > Hey Albert, > > The policy is the default Neutron policy in OpenStack Train. These can indeed be changed and customised, but my assumption is that you haven?t created any custom policies. Horizon uses the default for each service unless it?s been overwritten. policy is defiend server side not client side so it applie equially to all users of the api so the behavior will be the same for horizon or the cli if you ever find a delta because horizon say used a differnt token to make the request that is a securty vulnerablity in horizon and should be reported privatly to the horizon core team :) > > If I create a non-admin user and try to change security groups I also get the same error: > 2022-09-14 22:01:33,370 64 INFO openstack_dashboard.dashboards.project.networks.ports.workflows Failed to update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy > > And I can reproduce your same scenario ff I try via the CLI using these steps: > 1. Add entry for new user to clouds.yaml file: > bne-home-test: > auth: > auth_url: https://openstack.bne-home.net:13000 > password: "test" > project_domain_name: Default > project_name: bne-home > user_domain_name: Default > username: test > cacert: ~/.certs/overcloud-cacert.pem > identity_api_version: '3' > region_name: regionOne > volume_api_version: ?3' > > 2. export OS_CLOUD=bne-home-test > > 3. Try to remove security group from port: > ? openstack server show test-lb-net -c security_groups -c addresses -f yaml > addresses: > lb-mgmt-net: > - 172.24.0.90 > vlan4-infra: > - 172.20.13.175 > security_groups: > - name: management-bne the security group listed in nova is the default security group that will be used by all port create by nova. it only applie to ports created by nova and not ones that are passed in using the uuid of a precreate port. you shoudl in general not mix managing security groups via nova and neutron. horizon shoudl prefer to manage security groups only via neutron if it can. > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips -c port_security_enabled -c security_group_ids -f yaml > fixed_ips: > - ip_address: 172.20.13.175 > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > port_security_enabled: true > security_group_ids: > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f > > ? openstack port unset --security-group a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips -c port_security_enabled -c security_group_ids -f yaml > fixed_ips: > - ip_address: 172.20.13.175 > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > port_security_enabled: true > security_group_ids: [] > > > Verify that I?m definitely not a admin user: > ? openstack server list --all > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8) > > > I don?t think this user should be allowed to do that via the CLI either. So that could be a bug there. The request in the Neutron server.log when I do it via the CLI: > > user can add or remove security groups without being and admin including removing all securtiy groups thats intended behavior and should not require admin. are you implying that horizon is doing "openstack server list --all" --all is short for --all-tenants. outside of the admin tab in horizon horizon would never pass the equivlent of --all to the nova api. > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 len: 1102 time: 0.4449480 > > VS Horizon: > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 len: 386 time: 0.2209103 > > I have raised a upstream bug for this since I can still reproduce it on the latest version of OpenStack: > https://bugs.launchpad.net/neutron/+bug/1989627? > Bug #1989627 ?Policy enforcement variance between openstackcli a...? : Bugs : neutron > bugs.launchpad.net policy is enfoced on the nova/neutron api it cant behave differntly for horizon unless horizon is useing the wrong token. i.e. not he users token. > > > Brendan Shephard > Senior Software Engineer > Brisbane, Australia > > > > > On 15 Sep 2022, at 2:25 am, Albert Braden wrote: > > > > Hi Brendan, thanks for offering to help! I'll contact you privately with info about some languishing cases. > > > > Here's the policy line: > > "update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner" > > > > Does this policy only affect Horizon? I'm using the same non-admin user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user. > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard wrote: > > > > > > Hi Albert, > > > > While I may not be the best person to address your Horizon concern. I can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell. > > > > Looking at your Horizon issue though. It seems the default policy file is what prevents you from updating that port. We can see the default policy like this for example: > > > > [root at controller-2 ~]# podman exec -it neutron_api oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled" > > "update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner" > > > > When you execute the command via the CLI, which user are you using? Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that?s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon. > > > > I too would suggest opening a support case. It sounds like you have previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I?m confident we can right whatever wrong may have occurred there. > > > > Let me know if I can help in any way. > > > > Regards, > > > > Brendan Shephard > > Senior Software Engineer > > Brisbane, Australia > > > > > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden wrote: > > > > > > On CLI I can type "openstack port set --no-security-group " to remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group ". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups. > > > > > > I can successfully add security groups to a port via CLI, or I can remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon. > > > > > > Regarding RHOSP support; I assume that you are joking, or maybe haven't experienced the support that they offer. > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont wrote: > > > > > > > > > If you are running RHOSP, you might have a support contract with Red Hat? > > > > > > Are you trying to remove all the security groups from a port that has port_security enabled? > > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden > wrote: > > > Unfortunately we are running RHOSP in which Train is the latest and greatest. This is what we see in horizon.log: > > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid 139683266553600] [remote 10.232.233.11:57498 ] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau > wrote: > > > > > > > > > Hello, > > > > > > This is more likely to be a Horizon bug than an issue with Kolla itself, since Kolla doesn't change much from the default configuration. > > > > > > You should check Horizon logs in /var/log/kolla/horizon to find the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently. > > > > > > Cheers, > > > Pierre Riteau (priteau) > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden > wrote: > > > We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port ". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong? > > > > > > > Hey Albert, > > The policy is the default Neutron policy in OpenStack Train. These can indeed be changed and customised, but my assumption is that you haven?t created any custom policies. Horizon uses the default for each service unless it?s been overwritten. > > If I create a non-admin user and try to change security groups I also get the same error: > 2022-09-14 22:01:33,370 64 INFO openstack_dashboard.dashboards.project.networks.ports.workflows Failed to update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy > > And I can reproduce your same scenario ff I try via the CLI using these steps: > 1. Add entry for new user to clouds.yaml file: > ? bne-home-test: > ? ? auth: > ? ? ? auth_url: https://openstack.bne-home.net:13000 > ? ? ? password: "test" > ? ? ? project_domain_name: Default > ? ? ? project_name: bne-home > ? ? ? user_domain_name: Default > ? ? ? username: test > ? ? cacert: ~/.certs/overcloud-cacert.pem > ? ? identity_api_version: '3' > ? ? region_name: regionOne > ? ? volume_api_version: ?3' > > 2. export OS_CLOUD=bne-home-test > > 3. Try to remove security group from port: > ? openstack server show test-lb-net -c security_groups -c addresses -f yaml > addresses: > ? lb-mgmt-net: > ? - 172.24.0.90 > ? vlan4-infra: > ? - 172.20.13.175 > security_groups: > - name: management-bne > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips -c port_security_enabled -c security_group_ids -f yaml > fixed_ips: > - ip_address: 172.20.13.175 > ? subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > port_security_enabled: true > security_group_ids: > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f > > ? openstack port unset --security-group a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips -c port_security_enabled -c security_group_ids -f yaml > fixed_ips: > - ip_address: 172.20.13.175 > ? subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > port_security_enabled: true > security_group_ids: [] > > > Verify that I?m definitely not a admin user: > ? openstack server list --all > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8) > > > I don?t think this user should be allowed to do that via the CLI either. So that could be a bug there. The request in the Neutron server.log when I do it via the CLI: > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 192.168.1.17,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 ?len: 1102 time: 0.4449480 > > VS Horizon: > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a 3ff28fc7abf742a6b7a0d016771dee49 - - default default] 172.20.10.25,172.16.2.85 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 ?len: 386 time: 0.2209103 > > I have raised a upstream bug for this since I can still reproduce it on the latest version of OpenStack: > launchpad-og-image.pngBug #1989627 ?Policy enforcement variance between openstackcli a...? : Bugs : neutron > bugs.launchpad.net > > > > Brendan Shephard > Senior Software Engineer > Brisbane, Australia > > > > > On 15 Sep 2022, at 2:25 am, Albert Braden wrote: > > > > Hi Brendan, thanks for offering to help! I'll contact you privately with info about some languishing cases. > > > > Here's the policy line: > > "update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner" > > > > Does this policy only affect Horizon? I'm using the same non-admin user for both CLI and Horizon, on a project where that user is a member. The network was created by the admin user. > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard wrote: > > > > > > Hi Albert, > > > > While I may not be the best person to address your Horizon concern. I can probably help you with your Red Hat support concerns. If you had any issues you wanted addressed, or feedback you wanted to provide. Feel free to give me a yell. > > > > Looking at your Horizon issue though. It seems the default policy file is what prevents you from updating that port. We can see the default policy like this for example: > > > > [root at controller-2 ~]# podman exec -it neutron_api oslopolicy-policy-generator --namespace neutron | grep "update_port:port_security_enabled" > > "update_port:port_security_enabled": "rule:context_is_advsvc or rule:admin_or_network_owner" > > > > When you execute the command via the CLI, which user are you using? Are you just sourcing the overcloudrc file, or using export OS_CLOUD=overcloud. If that?s the case then you would be using the admin user on the CLI, but probably a different user when logging into Horizon. > > > > I too would suggest opening a support case. It sounds like you have previously had a negative experience with that. If you want to open a new one and share the case number with me, I can follow up on that for you. As someone who personally knows a lot of the RHOSP Technical Support team from around the world. I?m confident we can right whatever wrong may have occurred there. > > > > Let me know if I can help in any way. > > > > Regards, > > > > Brendan Shephard > > Senior Software Engineer > > Brisbane, Australia > > > > > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden wrote: > > > > > > On CLI I can type "openstack port set --no-security-group " to remove all security groups. In Horizon, the equivalent operation would be using the - button to remove all groups and then clicking "Update." Using the + button would be the equivalent of typing "openstack port set --security-group ". There doesn't seem to be a way to remove a single security group via CLI; I think the only way would be to set --no-security-group and then add back the desired groups. > > > > > > I can successfully add security groups to a port via CLI, or I can remove all security groups. If I go into Horizon and try these operations then I get the error when I click "Update." So it appears that security groups can be added and removed, with port security set, via CLI. We only see the failure when we try to do it via Horizon. > > > > > > Regarding RHOSP support; I assume that you are joking, or maybe haven't experienced the support that they offer. > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont wrote: > > > > > > > > > If you are running RHOSP, you might have a support contract with Red Hat? > > > > > > Are you trying to remove all the security groups from a port that has port_security enabled? > > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden wrote: > > > > Unfortunately we are running RHOSP in which Train is the latest and greatest. This is what we see in horizon.log: > > > > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid 139683266553600] [remote 10.232.233.11:57498] Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and rule:update_port:binding:vnic_type) and rule:update_port:port_security_enabled) is disallowed by policy > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau wrote: > > > > > > > > > > > > Hello, > > > > > > > > This is more likely to be a Horizon bug than an issue with Kolla itself, since Kolla doesn't change much from the default configuration. > > > > > > > > You should check Horizon logs in /var/log/kolla/horizon to find the error. I would also encourage you to upgrade to a more recent release, since Train has been marked as End of Life in Kolla recently. > > > > > > > > Cheers, > > > > Pierre Riteau (priteau) > > > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden wrote: > > > > > We're running kolla train and we're seeing an apparent bug when we try to add or remove security groups on a port. We see error "Failed to update port ". It works fine in CLI; we only see this in Horizon. Is this a known bug, or are we doing something wrong? > > > > > > > > From smooney at redhat.com Thu Sep 15 12:12:28 2022 From: smooney at redhat.com (Sean Mooney) Date: Thu, 15 Sep 2022 13:12:28 +0100 Subject: [Neutron] [train] Horizon port security group management fails In-Reply-To: References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> <1541763085.3101109.1663083479831@mail.yahoo.com> <84891126.3588046.1663158984067@mail.yahoo.com> <92876DF2-AAF8-44AF-BFCE-725E2A3AB393@redhat.com> <1338352317.3690165.1663172723209@mail.yahoo.com> <2EA66220-F3CE-4D0A-B8B3-9D67AA5E1AE9@redhat.com> Message-ID: <810befc2c803621d92df50b2f789aa2ff1cbc734.camel@redhat.com> On Thu, 2022-09-15 at 21:33 +1000, Brendan Shephard wrote: > Hey Sean, > > Thanks for the reply. > > For reference, I have all the steps to reproduce along with the relevant > debug logs attached to this LP: > https://bugs.launchpad.net/neutron/+bug/1989627 > > But, to summarize. If I go to any random instance in Horizon as a member > user - not a admin. Then try to remove any Security Group at all from any > of the ports it fails with the policy violation (I attached a screenshot of > where I'm making that change in Horizon). But doing it with the same user > from the cli works fine. Since I'm editing individual interfaces there, > rather than the instance itself. I assumed these would all be API calls to > Neutron from Horizon rather than from Horizon to Nova. updating the instance securty group will not affect any exsitng ports when you want to add or remvoe security groups form a port in horizont you do not do that via the instace secutity group you do it via the port edit dialog in the port detail view under the network https:///dashboard/project/networks/ports//detail i just did that now on a train cloud we have internally and was able to add and remove a security group on a port. > > I just run server list --all to demonstrate I was indeed using a member > user and not a admin since an admin would have seen VM's from all projects. > > I agree with you in principle. It should be exactly the same whether it > comes from openstackclient or from Horizon. In fact, I was 98% positive I > would be able to demonstrate the wrong user was being used in this case. > But unfortunately, my efforts to reproduce it demonstrated that the two are > indeed handled differently. what page in horizon are you editing it form if i try and add/remove the secirty group via the interfaces tabe at https:///dashboard/project/instances// it also work for me inlcuding removing all secuity groups and i am not an admin on this cloud. specificly this is the redhat internal shared cloud i was testing on. > > I believe anyone should be able to reproduce it using the steps I outlined > on the LP. > > Brendan Shephard > > Senior Software Engineer > > Red Hat APAC > > 193 N Quay > > Brisbane City QLD 4000 > @RedHat Red Hat > Red Hat > > > > > > On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney wrote: > > > On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote: > > > Hey Albert, > > > > > > The policy is the default Neutron policy in OpenStack Train. These can > > indeed be changed and customised, but my assumption is that you haven?t > > created any custom policies. Horizon uses the default for each service > > unless it?s been overwritten. > > policy is defiend server side not client side so it applie equially to all > > users of the api > > so the behavior will be the same for horizon or the cli > > if you ever find a delta because horizon say used a differnt token to make > > the request that is a securty vulnerablity in horizon and should be > > reported privatly to the horizon core team :) > > > > > > > > If I create a non-admin user and try to change security groups I also > > get the same error: > > > 2022-09-14 22:01:33,370 64 INFO > > openstack_dashboard.dashboards.project.networks.ports.workflows Failed to > > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and > > rule:update_port:binding:vnic_type) and > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > > And I can reproduce your same scenario ff I try via the CLI using these > > steps: > > > 1. Add entry for new user to clouds.yaml file: > > > bne-home-test: > > > auth: > > > auth_url: https://openstack.bne-home.net:13000 > > > password: "test" > > > project_domain_name: Default > > > project_name: bne-home > > > user_domain_name: Default > > > username: test > > > cacert: ~/.certs/overcloud-cacert.pem > > > identity_api_version: '3' > > > region_name: regionOne > > > volume_api_version: ?3' > > > > > > 2. export OS_CLOUD=bne-home-test > > > > > > 3. Try to remove security group from port: > > > ? openstack server show test-lb-net -c security_groups -c addresses -f > > yaml > > > addresses: > > > lb-mgmt-net: > > > - 172.24.0.90 > > > vlan4-infra: > > > - 172.20.13.175 > > > security_groups: > > > - name: management-bne > > the security group listed in nova is the default security group that will > > be used by all port create by nova. > > it only applie to ports created by nova and not ones that are passed in > > using the uuid of a precreate port. > > > > you shoudl in general not mix managing security groups via nova and > > neutron. > > horizon shoudl prefer to manage security groups only via neutron if it can. > > > > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips > > -c port_security_enabled -c security_group_ids -f yaml > > > fixed_ips: > > > - ip_address: 172.20.13.175 > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > port_security_enabled: true > > > security_group_ids: > > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f > > > > > > ? openstack port unset --security-group > > a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips > > -c port_security_enabled -c security_group_ids -f yaml > > > fixed_ips: > > > - ip_address: 172.20.13.175 > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > port_security_enabled: true > > > security_group_ids: [] > > > > > > > > > Verify that I?m definitely not a admin user: > > > ? openstack server list --all > > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be > > performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8) > > > > > > > > > I don?t think this user should be allowed to do that via the CLI either. > > So that could be a bug there. The request in the Neutron server.log when I > > do it via the CLI: > > > > > > > > user can add or remove security groups without being and admin including > > removing all securtiy groups thats intended behavior and should not require > > admin. > > > > are you implying that horizon is doing "openstack server list --all" --all > > is short for --all-tenants. > > outside of the admin tab in horizon horizon would never pass the equivlent > > of --all to the nova api. > > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None > > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > 192.168.1.17,172.16.2.85 "PUT > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 > > len: 1102 time: 0.4449480 > > > > > > VS Horizon: > > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None > > req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > 172.20.10.25,172.16.2.85 "PUT > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 > > len: 386 time: 0.2209103 > > > > > > I have raised a upstream bug for this since I can still reproduce it on > > the latest version of OpenStack: > > > https://bugs.launchpad.net/neutron/+bug/1989627? > > > Bug #1989627 ?Policy enforcement variance between openstackcli a...? : > > Bugs : neutron > > > bugs.launchpad.net > > policy is enfoced on the nova/neutron api it cant behave differntly for > > horizon unless horizon is useing the wrong token. > > i.e. not he users token. > > > > > > > > > Brendan Shephard > > > Senior Software Engineer > > > Brisbane, Australia > > > > > > > > > > > > > On 15 Sep 2022, at 2:25 am, Albert Braden wrote: > > > > > > > > Hi Brendan, thanks for offering to help! I'll contact you privately > > with info about some languishing cases. > > > > > > > > Here's the policy line: > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > rule:admin_or_network_owner" > > > > > > > > Does this policy only affect Horizon? I'm using the same non-admin > > user for both CLI and Horizon, on a project where that user is a member. > > The network was created by the admin user. > > > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard < > > bshephar at redhat.com> wrote: > > > > > > > > > > > > Hi Albert, > > > > > > > > While I may not be the best person to address your Horizon concern. I > > can probably help you with your Red Hat support concerns. If you had any > > issues you wanted addressed, or feedback you wanted to provide. Feel free > > to give me a yell. > > > > > > > > Looking at your Horizon issue though. It seems the default policy file > > is what prevents you from updating that port. We can see the default policy > > like this for example: > > > > > > > > [root at controller-2 ~]# podman exec -it neutron_api > > oslopolicy-policy-generator --namespace neutron | grep > > "update_port:port_security_enabled" > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > rule:admin_or_network_owner" > > > > > > > > When you execute the command via the CLI, which user are you using? > > Are you just sourcing the overcloudrc file, or using export > > OS_CLOUD=overcloud. If that?s the case then you would be using the admin > > user on the CLI, but probably a different user when logging into Horizon. > > > > > > > > I too would suggest opening a support case. It sounds like you have > > previously had a negative experience with that. If you want to open a new > > one and share the case number with me, I can follow up on that for you. As > > someone who personally knows a lot of the RHOSP Technical Support team from > > around the world. I?m confident we can right whatever wrong may have > > occurred there. > > > > > > > > Let me know if I can help in any way. > > > > > > > > Regards, > > > > > > > > Brendan Shephard > > > > Senior Software Engineer > > > > Brisbane, Australia > > > > > > > > > > > > > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden wrote: > > > > > > > > > > On CLI I can type "openstack port set --no-security-group " to > > remove all security groups. In Horizon, the equivalent operation would be > > using the - button to remove all groups and then clicking "Update." Using > > the + button would be the equivalent of typing "openstack port set > > --security-group ". There doesn't seem to be a way to remove a > > single security group via CLI; I think the only way would be to set > > --no-security-group and then add back the desired groups. > > > > > > > > > > I can successfully add security groups to a port via CLI, or I can > > remove all security groups. If I go into Horizon and try these operations > > then I get the error when I click "Update." So it appears that security > > groups can be added and removed, with port security set, via CLI. We only > > see the failure when we try to do it via Horizon. > > > > > > > > > > Regarding RHOSP support; I assume that you are joking, or maybe > > haven't experienced the support that they offer. > > > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont < > > laurentfdumont at gmail.com> wrote: > > > > > > > > > > > > > > > If you are running RHOSP, you might have a support contract with Red > > Hat? > > > > > > > > > > Are you trying to remove all the security groups from a port that > > has port_security enabled? > > > > > > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden > > wrote: > > > > > Unfortunately we are running RHOSP in which Train is the latest and > > greatest. This is what we see in horizon.log: > > > > > > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid > > 139683266553600] [remote 10.232.233.11:57498 ] > > Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: > > ((rule:update_port and rule:update_port:binding:vnic_type) and > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < > > pierre at stackhpc.com > wrote: > > > > > > > > > > > > > > > Hello, > > > > > > > > > > This is more likely to be a Horizon bug than an issue with Kolla > > itself, since Kolla doesn't change much from the default configuration. > > > > > > > > > > You should check Horizon logs in /var/log/kolla/horizon to find the > > error. I would also encourage you to upgrade to a more recent release, > > since Train has been marked as End of Life in Kolla recently. > > > > > > > > > > Cheers, > > > > > Pierre Riteau (priteau) > > > > > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden > > wrote: > > > > > We're running kolla train and we're seeing an apparent bug when we > > try to add or remove security groups on a port. We see error "Failed to > > update port ". It works fine in CLI; we only see this in Horizon. Is > > this a known bug, or are we doing something wrong? > > > > > > > > > > > > > > > Hey Albert, > > > > > > The policy is the default Neutron policy in OpenStack Train. These can > > indeed be changed and customised, but my assumption is that you haven?t > > created any custom policies. Horizon uses the default for each service > > unless it?s been overwritten. > > > > > > If I create a non-admin user and try to change security groups I also > > get the same error: > > > 2022-09-14 22:01:33,370 64 INFO > > openstack_dashboard.dashboards.project.networks.ports.workflows Failed to > > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and > > rule:update_port:binding:vnic_type) and > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > > And I can reproduce your same scenario ff I try via the CLI using these > > steps: > > > 1. Add entry for new user to clouds.yaml file: > > > bne-home-test: > > > auth: > > > auth_url: https://openstack.bne-home.net:13000 > > > password: "test" > > > project_domain_name: Default > > > project_name: bne-home > > > user_domain_name: Default > > > username: test > > > cacert: ~/.certs/overcloud-cacert.pem > > > identity_api_version: '3' > > > region_name: regionOne > > > volume_api_version: ?3' > > > > > > 2. export OS_CLOUD=bne-home-test > > > > > > 3. Try to remove security group from port: > > > ? openstack server show test-lb-net -c security_groups -c addresses -f > > yaml > > > addresses: > > > lb-mgmt-net: > > > - 172.24.0.90 > > > vlan4-infra: > > > - 172.20.13.175 > > > security_groups: > > > - name: management-bne > > > > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips > > -c port_security_enabled -c security_group_ids -f yaml > > > fixed_ips: > > > - ip_address: 172.20.13.175 > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > port_security_enabled: true > > > security_group_ids: > > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f > > > > > > ? openstack port unset --security-group > > a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips > > -c port_security_enabled -c security_group_ids -f yaml > > > fixed_ips: > > > - ip_address: 172.20.13.175 > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > port_security_enabled: true > > > security_group_ids: [] > > > > > > > > > Verify that I?m definitely not a admin user: > > > ? openstack server list --all > > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be > > performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8) > > > > > > > > > I don?t think this user should be allowed to do that via the CLI either. > > So that could be a bug there. The request in the Neutron server.log when I > > do it via the CLI: > > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None > > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > 192.168.1.17,172.16.2.85 "PUT > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 > > len: 1102 time: 0.4449480 > > > > > > VS Horizon: > > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None > > req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > 172.20.10.25,172.16.2.85 "PUT > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 > > len: 386 time: 0.2209103 > > > > > > I have raised a upstream bug for this since I can still reproduce it on > > the latest version of OpenStack: > > > launchpad-og-image.pngBug #1989627 ?Policy enforcement variance between > > openstackcli a...? : Bugs : neutron > > > bugs.launchpad.net > > > > > > > > > > > > Brendan Shephard > > > Senior Software Engineer > > > Brisbane, Australia > > > > > > > > > > > > > On 15 Sep 2022, at 2:25 am, Albert Braden wrote: > > > > > > > > Hi Brendan, thanks for offering to help! I'll contact you privately > > with info about some languishing cases. > > > > > > > > Here's the policy line: > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > rule:admin_or_network_owner" > > > > > > > > Does this policy only affect Horizon? I'm using the same non-admin > > user for both CLI and Horizon, on a project where that user is a member. > > The network was created by the admin user. > > > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard < > > bshephar at redhat.com> wrote: > > > > > > > > > > > > Hi Albert, > > > > > > > > While I may not be the best person to address your Horizon concern. I > > can probably help you with your Red Hat support concerns. If you had any > > issues you wanted addressed, or feedback you wanted to provide. Feel free > > to give me a yell. > > > > > > > > Looking at your Horizon issue though. It seems the default policy file > > is what prevents you from updating that port. We can see the default policy > > like this for example: > > > > > > > > [root at controller-2 ~]# podman exec -it neutron_api > > oslopolicy-policy-generator --namespace neutron | grep > > "update_port:port_security_enabled" > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > rule:admin_or_network_owner" > > > > > > > > When you execute the command via the CLI, which user are you using? > > Are you just sourcing the overcloudrc file, or using export > > OS_CLOUD=overcloud. If that?s the case then you would be using the admin > > user on the CLI, but probably a different user when logging into Horizon. > > > > > > > > I too would suggest opening a support case. It sounds like you have > > previously had a negative experience with that. If you want to open a new > > one and share the case number with me, I can follow up on that for you. As > > someone who personally knows a lot of the RHOSP Technical Support team from > > around the world. I?m confident we can right whatever wrong may have > > occurred there. > > > > > > > > Let me know if I can help in any way. > > > > > > > > Regards, > > > > > > > > Brendan Shephard > > > > Senior Software Engineer > > > > Brisbane, Australia > > > > > > > > > > > > > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden wrote: > > > > > > > > > > On CLI I can type "openstack port set --no-security-group " to > > remove all security groups. In Horizon, the equivalent operation would be > > using the - button to remove all groups and then clicking "Update." Using > > the + button would be the equivalent of typing "openstack port set > > --security-group ". There doesn't seem to be a way to remove a > > single security group via CLI; I think the only way would be to set > > --no-security-group and then add back the desired groups. > > > > > > > > > > I can successfully add security groups to a port via CLI, or I can > > remove all security groups. If I go into Horizon and try these operations > > then I get the error when I click "Update." So it appears that security > > groups can be added and removed, with port security set, via CLI. We only > > see the failure when we try to do it via Horizon. > > > > > > > > > > Regarding RHOSP support; I assume that you are joking, or maybe > > haven't experienced the support that they offer. > > > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont < > > laurentfdumont at gmail.com> wrote: > > > > > > > > > > > > > > > If you are running RHOSP, you might have a support contract with Red > > Hat? > > > > > > > > > > Are you trying to remove all the security groups from a port that > > has port_security enabled? > > > > > > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden > > wrote: > > > > > > Unfortunately we are running RHOSP in which Train is the latest > > and greatest. This is what we see in horizon.log: > > > > > > > > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid > > 139683266553600] [remote 10.232.233.11:57498] Failed to update port > > 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and > > rule:update_port:binding:vnic_type) and > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < > > pierre at stackhpc.com> wrote: > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > This is more likely to be a Horizon bug than an issue with Kolla > > itself, since Kolla doesn't change much from the default configuration. > > > > > > > > > > > > You should check Horizon logs in /var/log/kolla/horizon to find > > the error. I would also encourage you to upgrade to a more recent release, > > since Train has been marked as End of Life in Kolla recently. > > > > > > > > > > > > Cheers, > > > > > > Pierre Riteau (priteau) > > > > > > > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden > > wrote: > > > > > > > We're running kolla train and we're seeing an apparent bug when > > we try to add or remove security groups on a port. We see error "Failed to > > update port ". It works fine in CLI; we only see this in Horizon. Is > > this a known bug, or are we doing something wrong? > > > > > > > > > > > > > > > > > > From bshephar at redhat.com Thu Sep 15 11:33:20 2022 From: bshephar at redhat.com (Brendan Shephard) Date: Thu, 15 Sep 2022 21:33:20 +1000 Subject: [Neutron] [train] Horizon port security group management fails In-Reply-To: References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> <1541763085.3101109.1663083479831@mail.yahoo.com> <84891126.3588046.1663158984067@mail.yahoo.com> <92876DF2-AAF8-44AF-BFCE-725E2A3AB393@redhat.com> <1338352317.3690165.1663172723209@mail.yahoo.com> <2EA66220-F3CE-4D0A-B8B3-9D67AA5E1AE9@redhat.com> Message-ID: Hey Sean, Thanks for the reply. For reference, I have all the steps to reproduce along with the relevant debug logs attached to this LP: https://bugs.launchpad.net/neutron/+bug/1989627 But, to summarize. If I go to any random instance in Horizon as a member user - not a admin. Then try to remove any Security Group at all from any of the ports it fails with the policy violation (I attached a screenshot of where I'm making that change in Horizon). But doing it with the same user from the cli works fine. Since I'm editing individual interfaces there, rather than the instance itself. I assumed these would all be API calls to Neutron from Horizon rather than from Horizon to Nova. I just run server list --all to demonstrate I was indeed using a member user and not a admin since an admin would have seen VM's from all projects. I agree with you in principle. It should be exactly the same whether it comes from openstackclient or from Horizon. In fact, I was 98% positive I would be able to demonstrate the wrong user was being used in this case. But unfortunately, my efforts to reproduce it demonstrated that the two are indeed handled differently. I believe anyone should be able to reproduce it using the steps I outlined on the LP. Brendan Shephard Senior Software Engineer Red Hat APAC 193 N Quay Brisbane City QLD 4000 @RedHat Red Hat Red Hat On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney wrote: > On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote: > > Hey Albert, > > > > The policy is the default Neutron policy in OpenStack Train. These can > indeed be changed and customised, but my assumption is that you haven?t > created any custom policies. Horizon uses the default for each service > unless it?s been overwritten. > policy is defiend server side not client side so it applie equially to all > users of the api > so the behavior will be the same for horizon or the cli > if you ever find a delta because horizon say used a differnt token to make > the request that is a securty vulnerablity in horizon and should be > reported privatly to the horizon core team :) > > > > > If I create a non-admin user and try to change security groups I also > get the same error: > > 2022-09-14 22:01:33,370 64 INFO > openstack_dashboard.dashboards.project.networks.ports.workflows Failed to > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and > rule:update_port:binding:vnic_type) and > rule:update_port:port_security_enabled) is disallowed by policy > > > > And I can reproduce your same scenario ff I try via the CLI using these > steps: > > 1. Add entry for new user to clouds.yaml file: > > bne-home-test: > > auth: > > auth_url: https://openstack.bne-home.net:13000 > > password: "test" > > project_domain_name: Default > > project_name: bne-home > > user_domain_name: Default > > username: test > > cacert: ~/.certs/overcloud-cacert.pem > > identity_api_version: '3' > > region_name: regionOne > > volume_api_version: ?3' > > > > 2. export OS_CLOUD=bne-home-test > > > > 3. Try to remove security group from port: > > ? openstack server show test-lb-net -c security_groups -c addresses -f > yaml > > addresses: > > lb-mgmt-net: > > - 172.24.0.90 > > vlan4-infra: > > - 172.20.13.175 > > security_groups: > > - name: management-bne > the security group listed in nova is the default security group that will > be used by all port create by nova. > it only applie to ports created by nova and not ones that are passed in > using the uuid of a precreate port. > > you shoudl in general not mix managing security groups via nova and > neutron. > horizon shoudl prefer to manage security groups only via neutron if it can. > > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips > -c port_security_enabled -c security_group_ids -f yaml > > fixed_ips: > > - ip_address: 172.20.13.175 > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > port_security_enabled: true > > security_group_ids: > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f > > > > ? openstack port unset --security-group > a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips > -c port_security_enabled -c security_group_ids -f yaml > > fixed_ips: > > - ip_address: 172.20.13.175 > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > port_security_enabled: true > > security_group_ids: [] > > > > > > Verify that I?m definitely not a admin user: > > ? openstack server list --all > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be > performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8) > > > > > > I don?t think this user should be allowed to do that via the CLI either. > So that could be a bug there. The request in the Neutron server.log when I > do it via the CLI: > > > > > user can add or remove security groups without being and admin including > removing all securtiy groups thats intended behavior and should not require > admin. > > are you implying that horizon is doing "openstack server list --all" --all > is short for --all-tenants. > outside of the admin tab in horizon horizon would never pass the equivlent > of --all to the nova api. > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > 192.168.1.17,172.16.2.85 "PUT > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 > len: 1102 time: 0.4449480 > > > > VS Horizon: > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None > req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > 172.20.10.25,172.16.2.85 "PUT > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 > len: 386 time: 0.2209103 > > > > I have raised a upstream bug for this since I can still reproduce it on > the latest version of OpenStack: > > https://bugs.launchpad.net/neutron/+bug/1989627? > > Bug #1989627 ?Policy enforcement variance between openstackcli a...? : > Bugs : neutron > > bugs.launchpad.net > policy is enfoced on the nova/neutron api it cant behave differntly for > horizon unless horizon is useing the wrong token. > i.e. not he users token. > > > > > > Brendan Shephard > > Senior Software Engineer > > Brisbane, Australia > > > > > > > > > On 15 Sep 2022, at 2:25 am, Albert Braden wrote: > > > > > > Hi Brendan, thanks for offering to help! I'll contact you privately > with info about some languishing cases. > > > > > > Here's the policy line: > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > rule:admin_or_network_owner" > > > > > > Does this policy only affect Horizon? I'm using the same non-admin > user for both CLI and Horizon, on a project where that user is a member. > The network was created by the admin user. > > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard < > bshephar at redhat.com> wrote: > > > > > > > > > Hi Albert, > > > > > > While I may not be the best person to address your Horizon concern. I > can probably help you with your Red Hat support concerns. If you had any > issues you wanted addressed, or feedback you wanted to provide. Feel free > to give me a yell. > > > > > > Looking at your Horizon issue though. It seems the default policy file > is what prevents you from updating that port. We can see the default policy > like this for example: > > > > > > [root at controller-2 ~]# podman exec -it neutron_api > oslopolicy-policy-generator --namespace neutron | grep > "update_port:port_security_enabled" > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > rule:admin_or_network_owner" > > > > > > When you execute the command via the CLI, which user are you using? > Are you just sourcing the overcloudrc file, or using export > OS_CLOUD=overcloud. If that?s the case then you would be using the admin > user on the CLI, but probably a different user when logging into Horizon. > > > > > > I too would suggest opening a support case. It sounds like you have > previously had a negative experience with that. If you want to open a new > one and share the case number with me, I can follow up on that for you. As > someone who personally knows a lot of the RHOSP Technical Support team from > around the world. I?m confident we can right whatever wrong may have > occurred there. > > > > > > Let me know if I can help in any way. > > > > > > Regards, > > > > > > Brendan Shephard > > > Senior Software Engineer > > > Brisbane, Australia > > > > > > > > > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden wrote: > > > > > > > > On CLI I can type "openstack port set --no-security-group " to > remove all security groups. In Horizon, the equivalent operation would be > using the - button to remove all groups and then clicking "Update." Using > the + button would be the equivalent of typing "openstack port set > --security-group ". There doesn't seem to be a way to remove a > single security group via CLI; I think the only way would be to set > --no-security-group and then add back the desired groups. > > > > > > > > I can successfully add security groups to a port via CLI, or I can > remove all security groups. If I go into Horizon and try these operations > then I get the error when I click "Update." So it appears that security > groups can be added and removed, with port security set, via CLI. We only > see the failure when we try to do it via Horizon. > > > > > > > > Regarding RHOSP support; I assume that you are joking, or maybe > haven't experienced the support that they offer. > > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont < > laurentfdumont at gmail.com> wrote: > > > > > > > > > > > > If you are running RHOSP, you might have a support contract with Red > Hat? > > > > > > > > Are you trying to remove all the security groups from a port that > has port_security enabled? > > > > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden > wrote: > > > > Unfortunately we are running RHOSP in which Train is the latest and > greatest. This is what we see in horizon.log: > > > > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid > 139683266553600] [remote 10.232.233.11:57498 ] > Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: > ((rule:update_port and rule:update_port:binding:vnic_type) and > rule:update_port:port_security_enabled) is disallowed by policy > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < > pierre at stackhpc.com > wrote: > > > > > > > > > > > > Hello, > > > > > > > > This is more likely to be a Horizon bug than an issue with Kolla > itself, since Kolla doesn't change much from the default configuration. > > > > > > > > You should check Horizon logs in /var/log/kolla/horizon to find the > error. I would also encourage you to upgrade to a more recent release, > since Train has been marked as End of Life in Kolla recently. > > > > > > > > Cheers, > > > > Pierre Riteau (priteau) > > > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden > wrote: > > > > We're running kolla train and we're seeing an apparent bug when we > try to add or remove security groups on a port. We see error "Failed to > update port ". It works fine in CLI; we only see this in Horizon. Is > this a known bug, or are we doing something wrong? > > > > > > > > > > > Hey Albert, > > > > The policy is the default Neutron policy in OpenStack Train. These can > indeed be changed and customised, but my assumption is that you haven?t > created any custom policies. Horizon uses the default for each service > unless it?s been overwritten. > > > > If I create a non-admin user and try to change security groups I also > get the same error: > > 2022-09-14 22:01:33,370 64 INFO > openstack_dashboard.dashboards.project.networks.ports.workflows Failed to > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and > rule:update_port:binding:vnic_type) and > rule:update_port:port_security_enabled) is disallowed by policy > > > > And I can reproduce your same scenario ff I try via the CLI using these > steps: > > 1. Add entry for new user to clouds.yaml file: > > bne-home-test: > > auth: > > auth_url: https://openstack.bne-home.net:13000 > > password: "test" > > project_domain_name: Default > > project_name: bne-home > > user_domain_name: Default > > username: test > > cacert: ~/.certs/overcloud-cacert.pem > > identity_api_version: '3' > > region_name: regionOne > > volume_api_version: ?3' > > > > 2. export OS_CLOUD=bne-home-test > > > > 3. Try to remove security group from port: > > ? openstack server show test-lb-net -c security_groups -c addresses -f > yaml > > addresses: > > lb-mgmt-net: > > - 172.24.0.90 > > vlan4-infra: > > - 172.20.13.175 > > security_groups: > > - name: management-bne > > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips > -c port_security_enabled -c security_group_ids -f yaml > > fixed_ips: > > - ip_address: 172.20.13.175 > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > port_security_enabled: true > > security_group_ids: > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f > > > > ? openstack port unset --security-group > a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips > -c port_security_enabled -c security_group_ids -f yaml > > fixed_ips: > > - ip_address: 172.20.13.175 > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > port_security_enabled: true > > security_group_ids: [] > > > > > > Verify that I?m definitely not a admin user: > > ? openstack server list --all > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be > performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8) > > > > > > I don?t think this user should be allowed to do that via the CLI either. > So that could be a bug there. The request in the Neutron server.log when I > do it via the CLI: > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > 192.168.1.17,172.16.2.85 "PUT > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 > len: 1102 time: 0.4449480 > > > > VS Horizon: > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None > req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > 172.20.10.25,172.16.2.85 "PUT > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 > len: 386 time: 0.2209103 > > > > I have raised a upstream bug for this since I can still reproduce it on > the latest version of OpenStack: > > launchpad-og-image.pngBug #1989627 ?Policy enforcement variance between > openstackcli a...? : Bugs : neutron > > bugs.launchpad.net > > > > > > > > Brendan Shephard > > Senior Software Engineer > > Brisbane, Australia > > > > > > > > > On 15 Sep 2022, at 2:25 am, Albert Braden wrote: > > > > > > Hi Brendan, thanks for offering to help! I'll contact you privately > with info about some languishing cases. > > > > > > Here's the policy line: > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > rule:admin_or_network_owner" > > > > > > Does this policy only affect Horizon? I'm using the same non-admin > user for both CLI and Horizon, on a project where that user is a member. > The network was created by the admin user. > > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard < > bshephar at redhat.com> wrote: > > > > > > > > > Hi Albert, > > > > > > While I may not be the best person to address your Horizon concern. I > can probably help you with your Red Hat support concerns. If you had any > issues you wanted addressed, or feedback you wanted to provide. Feel free > to give me a yell. > > > > > > Looking at your Horizon issue though. It seems the default policy file > is what prevents you from updating that port. We can see the default policy > like this for example: > > > > > > [root at controller-2 ~]# podman exec -it neutron_api > oslopolicy-policy-generator --namespace neutron | grep > "update_port:port_security_enabled" > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > rule:admin_or_network_owner" > > > > > > When you execute the command via the CLI, which user are you using? > Are you just sourcing the overcloudrc file, or using export > OS_CLOUD=overcloud. If that?s the case then you would be using the admin > user on the CLI, but probably a different user when logging into Horizon. > > > > > > I too would suggest opening a support case. It sounds like you have > previously had a negative experience with that. If you want to open a new > one and share the case number with me, I can follow up on that for you. As > someone who personally knows a lot of the RHOSP Technical Support team from > around the world. I?m confident we can right whatever wrong may have > occurred there. > > > > > > Let me know if I can help in any way. > > > > > > Regards, > > > > > > Brendan Shephard > > > Senior Software Engineer > > > Brisbane, Australia > > > > > > > > > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden wrote: > > > > > > > > On CLI I can type "openstack port set --no-security-group " to > remove all security groups. In Horizon, the equivalent operation would be > using the - button to remove all groups and then clicking "Update." Using > the + button would be the equivalent of typing "openstack port set > --security-group ". There doesn't seem to be a way to remove a > single security group via CLI; I think the only way would be to set > --no-security-group and then add back the desired groups. > > > > > > > > I can successfully add security groups to a port via CLI, or I can > remove all security groups. If I go into Horizon and try these operations > then I get the error when I click "Update." So it appears that security > groups can be added and removed, with port security set, via CLI. We only > see the failure when we try to do it via Horizon. > > > > > > > > Regarding RHOSP support; I assume that you are joking, or maybe > haven't experienced the support that they offer. > > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont < > laurentfdumont at gmail.com> wrote: > > > > > > > > > > > > If you are running RHOSP, you might have a support contract with Red > Hat? > > > > > > > > Are you trying to remove all the security groups from a port that > has port_security enabled? > > > > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden > wrote: > > > > > Unfortunately we are running RHOSP in which Train is the latest > and greatest. This is what we see in horizon.log: > > > > > > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid > 139683266553600] [remote 10.232.233.11:57498] Failed to update port > 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and > rule:update_port:binding:vnic_type) and > rule:update_port:port_security_enabled) is disallowed by policy > > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < > pierre at stackhpc.com> wrote: > > > > > > > > > > > > > > > Hello, > > > > > > > > > > This is more likely to be a Horizon bug than an issue with Kolla > itself, since Kolla doesn't change much from the default configuration. > > > > > > > > > > You should check Horizon logs in /var/log/kolla/horizon to find > the error. I would also encourage you to upgrade to a more recent release, > since Train has been marked as End of Life in Kolla recently. > > > > > > > > > > Cheers, > > > > > Pierre Riteau (priteau) > > > > > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden > wrote: > > > > > > We're running kolla train and we're seeing an apparent bug when > we try to add or remove security groups on a port. We see error "Failed to > update port ". It works fine in CLI; we only see this in Horizon. Is > this a known bug, or are we doing something wrong? > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot 2022-09-15 at 9.27.44 pm.png Type: image/png Size: 597589 bytes Desc: not available URL: From bshephar at redhat.com Thu Sep 15 12:20:59 2022 From: bshephar at redhat.com (Brendan Shephard) Date: Thu, 15 Sep 2022 22:20:59 +1000 Subject: [Neutron] [train] Horizon port security group management fails In-Reply-To: <810befc2c803621d92df50b2f789aa2ff1cbc734.camel@redhat.com> References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> <1541763085.3101109.1663083479831@mail.yahoo.com> <84891126.3588046.1663158984067@mail.yahoo.com> <92876DF2-AAF8-44AF-BFCE-725E2A3AB393@redhat.com> <1338352317.3690165.1663172723209@mail.yahoo.com> <2EA66220-F3CE-4D0A-B8B3-9D67AA5E1AE9@redhat.com> <810befc2c803621d92df50b2f789aa2ff1cbc734.camel@redhat.com> Message-ID: Hey, I'm doing it from the instances one: https://openstack.bne-home.net/dashboard/project/instances/ccb72b14-3694-40fa-9b3b-ec1a8d7ef046/ But for what it's worth. I get the same error if I do it from: https://openstack.bne-home.net/dashboard/project/networks/acefae53-b4d5-422f-bcca-dc32a0785d21/detail Interesting that it worked for you there. Be good to confirm with @ozzzo at yahoo.com as well as to exactly where in Horizon he is trying to modify the security groups. Just so we're all trying to do the exact same thing. My environment is also deployed from the latest tripleo packages, so I'll also test on that internal lab you referenced Sean. That would be more representative of Alberts issue since he is using RHOSP. Brendan Shephard Senior Software Engineer Red Hat APAC 193 N Quay Brisbane City QLD 4000 @RedHat Red Hat Red Hat On Thu, Sep 15, 2022 at 10:12 PM Sean Mooney wrote: > On Thu, 2022-09-15 at 21:33 +1000, Brendan Shephard wrote: > > Hey Sean, > > > > Thanks for the reply. > > > > For reference, I have all the steps to reproduce along with the relevant > > debug logs attached to this LP: > > https://bugs.launchpad.net/neutron/+bug/1989627 > > > > But, to summarize. If I go to any random instance in Horizon as a member > > user - not a admin. Then try to remove any Security Group at all from any > > of the ports it fails with the policy violation (I attached a screenshot > of > > where I'm making that change in Horizon). But doing it with the same user > > from the cli works fine. Since I'm editing individual interfaces there, > > rather than the instance itself. I assumed these would all be API calls > to > > Neutron from Horizon rather than from Horizon to Nova. > updating the instance securty group will not affect any exsitng ports > when you want to add or remvoe security groups form a port in horizont > you do not do that via the instace secutity group you do it via the port > edit dialog > in the port detail view under the network > > https:///dashboard/project/networks/ports/ uuid>/detail > > i just did that now on a train cloud we have internally and was able to > add and remove a security group on a port. > > > > > I just run server list --all to demonstrate I was indeed using a member > > user and not a admin since an admin would have seen VM's from all > projects. > > > > I agree with you in principle. It should be exactly the same whether it > > comes from openstackclient or from Horizon. In fact, I was 98% positive I > > would be able to demonstrate the wrong user was being used in this case. > > But unfortunately, my efforts to reproduce it demonstrated that the two > are > > indeed handled differently. > > what page in horizon are you editing it form if i try and add/remove the > secirty group via the interfaces tabe at > https:///dashboard/project/instances// > it also work for me inlcuding removing all secuity groups and i am not an > admin on this cloud. > > specificly this is the redhat internal shared cloud i was testing on. > > > > > I believe anyone should be able to reproduce it using the steps I > outlined > > on the LP. > > > > Brendan Shephard > > > > Senior Software Engineer > > > > Red Hat APAC > > > > 193 N Quay > > > > Brisbane City QLD 4000 > > @RedHat Red Hat > > Red Hat > > > > > > > > > > > > On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney wrote: > > > > > On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote: > > > > Hey Albert, > > > > > > > > The policy is the default Neutron policy in OpenStack Train. These > can > > > indeed be changed and customised, but my assumption is that you haven?t > > > created any custom policies. Horizon uses the default for each service > > > unless it?s been overwritten. > > > policy is defiend server side not client side so it applie equially to > all > > > users of the api > > > so the behavior will be the same for horizon or the cli > > > if you ever find a delta because horizon say used a differnt token to > make > > > the request that is a securty vulnerablity in horizon and should be > > > reported privatly to the horizon core team :) > > > > > > > > > > > If I create a non-admin user and try to change security groups I also > > > get the same error: > > > > 2022-09-14 22:01:33,370 64 INFO > > > openstack_dashboard.dashboards.project.networks.ports.workflows Failed > to > > > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port > and > > > rule:update_port:binding:vnic_type) and > > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > > > > And I can reproduce your same scenario ff I try via the CLI using > these > > > steps: > > > > 1. Add entry for new user to clouds.yaml file: > > > > bne-home-test: > > > > auth: > > > > auth_url: https://openstack.bne-home.net:13000 > > > > password: "test" > > > > project_domain_name: Default > > > > project_name: bne-home > > > > user_domain_name: Default > > > > username: test > > > > cacert: ~/.certs/overcloud-cacert.pem > > > > identity_api_version: '3' > > > > region_name: regionOne > > > > volume_api_version: ?3' > > > > > > > > 2. export OS_CLOUD=bne-home-test > > > > > > > > 3. Try to remove security group from port: > > > > ? openstack server show test-lb-net -c security_groups -c addresses > -f > > > yaml > > > > addresses: > > > > lb-mgmt-net: > > > > - 172.24.0.90 > > > > vlan4-infra: > > > > - 172.20.13.175 > > > > security_groups: > > > > - name: management-bne > > > the security group listed in nova is the default security group that > will > > > be used by all port create by nova. > > > it only applie to ports created by nova and not ones that are passed in > > > using the uuid of a precreate port. > > > > > > you shoudl in general not mix managing security groups via nova and > > > neutron. > > > horizon shoudl prefer to manage security groups only via neutron if it > can. > > > > > > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c > fixed_ips > > > -c port_security_enabled -c security_group_ids -f yaml > > > > fixed_ips: > > > > - ip_address: 172.20.13.175 > > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > > port_security_enabled: true > > > > security_group_ids: > > > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f > > > > > > > > ? openstack port unset --security-group > > > a3ae6e20-67df-4a72-9d5b-cc21ad87464f > 4df563ce-5464-4f7d-8aaf-c5496cdaefda > > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c > fixed_ips > > > -c port_security_enabled -c security_group_ids -f yaml > > > > fixed_ips: > > > > - ip_address: 172.20.13.175 > > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > > port_security_enabled: true > > > > security_group_ids: [] > > > > > > > > > > > > Verify that I?m definitely not a admin user: > > > > ? openstack server list --all > > > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants > to be > > > performed. (HTTP 403) (Request-ID: > req-75c19210-ad91-471f-b500-e1f3482825f8) > > > > > > > > > > > > I don?t think this user should be allowed to do that via the CLI > either. > > > So that could be a bug there. The request in the Neutron server.log > when I > > > do it via the CLI: > > > > > > > > > > > user can add or remove security groups without being and admin > including > > > removing all securtiy groups thats intended behavior and should not > require > > > admin. > > > > > > are you implying that horizon is doing "openstack server list --all" > --all > > > is short for --all-tenants. > > > outside of the admin tab in horizon horizon would never pass the > equivlent > > > of --all to the nova api. > > > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None > > > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 > 781362d053ee4708a21430d3a825795a > > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > > 192.168.1.17,172.16.2.85 "PUT > > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 > > > len: 1102 time: 0.4449480 > > > > > > > > VS Horizon: > > > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None > > > req-4c284690-eb69-43df-b205-4953a88ab87c > 781362d053ee4708a21430d3a825795a > > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > > 172.20.10.25,172.16.2.85 "PUT > > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 > > > len: 386 time: 0.2209103 > > > > > > > > I have raised a upstream bug for this since I can still reproduce it > on > > > the latest version of OpenStack: > > > > https://bugs.launchpad.net/neutron/+bug/1989627? > > > > Bug #1989627 ?Policy enforcement variance between openstackcli a...? > : > > > Bugs : neutron > > > > bugs.launchpad.net > > > policy is enfoced on the nova/neutron api it cant behave differntly for > > > horizon unless horizon is useing the wrong token. > > > i.e. not he users token. > > > > > > > > > > > > Brendan Shephard > > > > Senior Software Engineer > > > > Brisbane, Australia > > > > > > > > > > > > > > > > > On 15 Sep 2022, at 2:25 am, Albert Braden wrote: > > > > > > > > > > Hi Brendan, thanks for offering to help! I'll contact you privately > > > with info about some languishing cases. > > > > > > > > > > Here's the policy line: > > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > > rule:admin_or_network_owner" > > > > > > > > > > Does this policy only affect Horizon? I'm using the same non-admin > > > user for both CLI and Horizon, on a project where that user is a > member. > > > The network was created by the admin user. > > > > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan > Shephard < > > > bshephar at redhat.com> wrote: > > > > > > > > > > > > > > > Hi Albert, > > > > > > > > > > While I may not be the best person to address your Horizon > concern. I > > > can probably help you with your Red Hat support concerns. If you had > any > > > issues you wanted addressed, or feedback you wanted to provide. Feel > free > > > to give me a yell. > > > > > > > > > > Looking at your Horizon issue though. It seems the default policy > file > > > is what prevents you from updating that port. We can see the default > policy > > > like this for example: > > > > > > > > > > [root at controller-2 ~]# podman exec -it neutron_api > > > oslopolicy-policy-generator --namespace neutron | grep > > > "update_port:port_security_enabled" > > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > > rule:admin_or_network_owner" > > > > > > > > > > When you execute the command via the CLI, which user are you using? > > > Are you just sourcing the overcloudrc file, or using export > > > OS_CLOUD=overcloud. If that?s the case then you would be using the > admin > > > user on the CLI, but probably a different user when logging into > Horizon. > > > > > > > > > > I too would suggest opening a support case. It sounds like you have > > > previously had a negative experience with that. If you want to open a > new > > > one and share the case number with me, I can follow up on that for > you. As > > > someone who personally knows a lot of the RHOSP Technical Support team > from > > > around the world. I?m confident we can right whatever wrong may have > > > occurred there. > > > > > > > > > > Let me know if I can help in any way. > > > > > > > > > > Regards, > > > > > > > > > > Brendan Shephard > > > > > Senior Software Engineer > > > > > Brisbane, Australia > > > > > > > > > > > > > > > > > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden > wrote: > > > > > > > > > > > > On CLI I can type "openstack port set --no-security-group " > to > > > remove all security groups. In Horizon, the equivalent operation would > be > > > using the - button to remove all groups and then clicking "Update." > Using > > > the + button would be the equivalent of typing "openstack port set > > > --security-group ". There doesn't seem to be a way to remove > a > > > single security group via CLI; I think the only way would be to set > > > --no-security-group and then add back the desired groups. > > > > > > > > > > > > I can successfully add security groups to a port via CLI, or I > can > > > remove all security groups. If I go into Horizon and try these > operations > > > then I get the error when I click "Update." So it appears that security > > > groups can be added and removed, with port security set, via CLI. We > only > > > see the failure when we try to do it via Horizon. > > > > > > > > > > > > Regarding RHOSP support; I assume that you are joking, or maybe > > > haven't experienced the support that they offer. > > > > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont < > > > laurentfdumont at gmail.com> wrote: > > > > > > > > > > > > > > > > > > If you are running RHOSP, you might have a support contract with > Red > > > Hat? > > > > > > > > > > > > Are you trying to remove all the security groups from a port that > > > has port_security enabled? > > > > > > > > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden > > > wrote: > > > > > > Unfortunately we are running RHOSP in which Train is the latest > and > > > greatest. This is what we see in horizon.log: > > > > > > > > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid > > > 139683266553600] [remote 10.232.233.11:57498 < > http://10.232.233.11:57498/>] > > > Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: > > > ((rule:update_port and rule:update_port:binding:vnic_type) and > > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < > > > pierre at stackhpc.com > wrote: > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > This is more likely to be a Horizon bug than an issue with Kolla > > > itself, since Kolla doesn't change much from the default configuration. > > > > > > > > > > > > You should check Horizon logs in /var/log/kolla/horizon to find > the > > > error. I would also encourage you to upgrade to a more recent release, > > > since Train has been marked as End of Life in Kolla recently. > > > > > > > > > > > > Cheers, > > > > > > Pierre Riteau (priteau) > > > > > > > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden > > > wrote: > > > > > > We're running kolla train and we're seeing an apparent bug when > we > > > try to add or remove security groups on a port. We see error "Failed to > > > update port ". It works fine in CLI; we only see this in Horizon. > Is > > > this a known bug, or are we doing something wrong? > > > > > > > > > > > > > > > > > > > Hey Albert, > > > > > > > > The policy is the default Neutron policy in OpenStack Train. These > can > > > indeed be changed and customised, but my assumption is that you haven?t > > > created any custom policies. Horizon uses the default for each service > > > unless it?s been overwritten. > > > > > > > > If I create a non-admin user and try to change security groups I also > > > get the same error: > > > > 2022-09-14 22:01:33,370 64 INFO > > > openstack_dashboard.dashboards.project.networks.ports.workflows Failed > to > > > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port > and > > > rule:update_port:binding:vnic_type) and > > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > > > > And I can reproduce your same scenario ff I try via the CLI using > these > > > steps: > > > > 1. Add entry for new user to clouds.yaml file: > > > > bne-home-test: > > > > auth: > > > > auth_url: https://openstack.bne-home.net:13000 > > > > password: "test" > > > > project_domain_name: Default > > > > project_name: bne-home > > > > user_domain_name: Default > > > > username: test > > > > cacert: ~/.certs/overcloud-cacert.pem > > > > identity_api_version: '3' > > > > region_name: regionOne > > > > volume_api_version: ?3' > > > > > > > > 2. export OS_CLOUD=bne-home-test > > > > > > > > 3. Try to remove security group from port: > > > > ? openstack server show test-lb-net -c security_groups -c addresses > -f > > > yaml > > > > addresses: > > > > lb-mgmt-net: > > > > - 172.24.0.90 > > > > vlan4-infra: > > > > - 172.20.13.175 > > > > security_groups: > > > > - name: management-bne > > > > > > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c > fixed_ips > > > -c port_security_enabled -c security_group_ids -f yaml > > > > fixed_ips: > > > > - ip_address: 172.20.13.175 > > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > > port_security_enabled: true > > > > security_group_ids: > > > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f > > > > > > > > ? openstack port unset --security-group > > > a3ae6e20-67df-4a72-9d5b-cc21ad87464f > 4df563ce-5464-4f7d-8aaf-c5496cdaefda > > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c > fixed_ips > > > -c port_security_enabled -c security_group_ids -f yaml > > > > fixed_ips: > > > > - ip_address: 172.20.13.175 > > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > > port_security_enabled: true > > > > security_group_ids: [] > > > > > > > > > > > > Verify that I?m definitely not a admin user: > > > > ? openstack server list --all > > > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants > to be > > > performed. (HTTP 403) (Request-ID: > req-75c19210-ad91-471f-b500-e1f3482825f8) > > > > > > > > > > > > I don?t think this user should be allowed to do that via the CLI > either. > > > So that could be a bug there. The request in the Neutron server.log > when I > > > do it via the CLI: > > > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None > > > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 > 781362d053ee4708a21430d3a825795a > > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > > 192.168.1.17,172.16.2.85 "PUT > > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 > > > len: 1102 time: 0.4449480 > > > > > > > > VS Horizon: > > > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None > > > req-4c284690-eb69-43df-b205-4953a88ab87c > 781362d053ee4708a21430d3a825795a > > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > > 172.20.10.25,172.16.2.85 "PUT > > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 > > > len: 386 time: 0.2209103 > > > > > > > > I have raised a upstream bug for this since I can still reproduce it > on > > > the latest version of OpenStack: > > > > launchpad-og-image.pngBug #1989627 ?Policy enforcement variance > between > > > openstackcli a...? : Bugs : neutron > > > > bugs.launchpad.net > > > > > > > > > > > > > > > > Brendan Shephard > > > > Senior Software Engineer > > > > Brisbane, Australia > > > > > > > > > > > > > > > > > On 15 Sep 2022, at 2:25 am, Albert Braden wrote: > > > > > > > > > > Hi Brendan, thanks for offering to help! I'll contact you > privately > > > with info about some languishing cases. > > > > > > > > > > Here's the policy line: > > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > > rule:admin_or_network_owner" > > > > > > > > > > Does this policy only affect Horizon? I'm using the same non-admin > > > user for both CLI and Horizon, on a project where that user is a > member. > > > The network was created by the admin user. > > > > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan > Shephard < > > > bshephar at redhat.com> wrote: > > > > > > > > > > > > > > > Hi Albert, > > > > > > > > > > While I may not be the best person to address your Horizon > concern. I > > > can probably help you with your Red Hat support concerns. If you had > any > > > issues you wanted addressed, or feedback you wanted to provide. Feel > free > > > to give me a yell. > > > > > > > > > > Looking at your Horizon issue though. It seems the default policy > file > > > is what prevents you from updating that port. We can see the default > policy > > > like this for example: > > > > > > > > > > [root at controller-2 ~]# podman exec -it neutron_api > > > oslopolicy-policy-generator --namespace neutron | grep > > > "update_port:port_security_enabled" > > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > > rule:admin_or_network_owner" > > > > > > > > > > When you execute the command via the CLI, which user are you using? > > > Are you just sourcing the overcloudrc file, or using export > > > OS_CLOUD=overcloud. If that?s the case then you would be using the > admin > > > user on the CLI, but probably a different user when logging into > Horizon. > > > > > > > > > > I too would suggest opening a support case. It sounds like you have > > > previously had a negative experience with that. If you want to open a > new > > > one and share the case number with me, I can follow up on that for > you. As > > > someone who personally knows a lot of the RHOSP Technical Support team > from > > > around the world. I?m confident we can right whatever wrong may have > > > occurred there. > > > > > > > > > > Let me know if I can help in any way. > > > > > > > > > > Regards, > > > > > > > > > > Brendan Shephard > > > > > Senior Software Engineer > > > > > Brisbane, Australia > > > > > > > > > > > > > > > > > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden > wrote: > > > > > > > > > > > > On CLI I can type "openstack port set --no-security-group " > to > > > remove all security groups. In Horizon, the equivalent operation would > be > > > using the - button to remove all groups and then clicking "Update." > Using > > > the + button would be the equivalent of typing "openstack port set > > > --security-group ". There doesn't seem to be a way to remove > a > > > single security group via CLI; I think the only way would be to set > > > --no-security-group and then add back the desired groups. > > > > > > > > > > > > I can successfully add security groups to a port via CLI, or I > can > > > remove all security groups. If I go into Horizon and try these > operations > > > then I get the error when I click "Update." So it appears that security > > > groups can be added and removed, with port security set, via CLI. We > only > > > see the failure when we try to do it via Horizon. > > > > > > > > > > > > Regarding RHOSP support; I assume that you are joking, or maybe > > > haven't experienced the support that they offer. > > > > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont > < > > > laurentfdumont at gmail.com> wrote: > > > > > > > > > > > > > > > > > > If you are running RHOSP, you might have a support contract with > Red > > > Hat? > > > > > > > > > > > > Are you trying to remove all the security groups from a port that > > > has port_security enabled? > > > > > > > > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden > > > wrote: > > > > > > > Unfortunately we are running RHOSP in which Train is the > latest > > > and greatest. This is what we see in horizon.log: > > > > > > > > > > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid > > > 139683266553600] [remote 10.232.233.11:57498] Failed to update port > > > 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and > > > rule:update_port:binding:vnic_type) and > > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < > > > pierre at stackhpc.com> wrote: > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > This is more likely to be a Horizon bug than an issue with > Kolla > > > itself, since Kolla doesn't change much from the default configuration. > > > > > > > > > > > > > > You should check Horizon logs in /var/log/kolla/horizon to find > > > the error. I would also encourage you to upgrade to a more recent > release, > > > since Train has been marked as End of Life in Kolla recently. > > > > > > > > > > > > > > Cheers, > > > > > > > Pierre Riteau (priteau) > > > > > > > > > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden > > > wrote: > > > > > > > > We're running kolla train and we're seeing an apparent bug > when > > > we try to add or remove security groups on a port. We see error > "Failed to > > > update port ". It works fine in CLI; we only see this in Horizon. > Is > > > this a known bug, or are we doing something wrong? > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ozzzo at yahoo.com Thu Sep 15 12:46:23 2022 From: ozzzo at yahoo.com (Albert Braden) Date: Thu, 15 Sep 2022 12:46:23 +0000 (UTC) Subject: [Neutron] [train] Horizon port security group management fails In-Reply-To: References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> <1541763085.3101109.1663083479831@mail.yahoo.com> <84891126.3588046.1663158984067@mail.yahoo.com> <92876DF2-AAF8-44AF-BFCE-725E2A3AB393@redhat.com> <1338352317.3690165.1663172723209@mail.yahoo.com> <2EA66220-F3CE-4D0A-B8B3-9D67AA5E1AE9@redhat.com> <810befc2c803621d92df50b2f789aa2ff1cbc734.camel@redhat.com> Message-ID: <234984793.4131684.1663245983327@mail.yahoo.com> If I add/remove security groups from an instance in Horizon, it works. It's when I add/remove security groups from a port that the error occurs. One way to reproduce is to click on the instance and then go to the "Interfaces" tab, and click "Update Security Groups" on the right. On Thursday, September 15, 2022, 08:21:17 AM EDT, Brendan Shephard wrote: Hey, I'm doing it from the instances one:https://openstack.bne-home.net/dashboard/project/instances/ccb72b14-3694-40fa-9b3b-ec1a8d7ef046/ But for what it's worth. I get the same error if I do it from:https://openstack.bne-home.net/dashboard/project/networks/acefae53-b4d5-422f-bcca-dc32a0785d21/detail Interesting that it worked for you there. Be good to confirm with?@ozzzo at yahoo.com?as well as to exactly where in Horizon he is trying to modify the security groups. Just so we're all trying to do the exact same thing. My environment is also deployed from the latest tripleo packages, so I'll also test on that internal lab you referenced Sean. That would be more representative of Alberts issue since he is using RHOSP. Brendan Shephard Senior Software Engineer Red Hat APAC 193 N Quay Brisbane City QLD 4000 @RedHat ? Red Hat ? Red Hat | | | On Thu, Sep 15, 2022 at 10:12 PM Sean Mooney wrote: On Thu, 2022-09-15 at 21:33 +1000, Brendan Shephard wrote: > Hey Sean, > > Thanks for the reply. > > For reference, I have all the steps to reproduce along with the relevant > debug logs attached to this LP: > https://bugs.launchpad.net/neutron/+bug/1989627 > > But, to summarize. If I go to any random instance in Horizon as a member > user - not a admin. Then try to remove any Security Group at all from any > of the ports it fails with the policy violation (I attached a screenshot of > where I'm making that change in Horizon). But doing it with the same user > from the cli works fine. Since I'm editing individual interfaces there, > rather than the instance itself. I assumed these would all be API calls to > Neutron from Horizon rather than from Horizon to Nova. updating the instance securty group will not affect any exsitng ports when you want to add or remvoe security groups form a port in horizont you do not do that via the instace secutity group you do it via the port edit dialog in the port detail view under the network https:///dashboard/project/networks/ports//detail i just did that now on a train cloud we have internally and was able to add and remove a security group on a port. > > I just run server list --all to demonstrate I was indeed using a member > user and not a admin since an admin would have seen VM's from all projects. > > I agree with you in principle. It should be exactly the same whether it > comes from openstackclient or from Horizon. In fact, I was 98% positive I > would be able to demonstrate the wrong user was being used in this case. > But unfortunately, my efforts to reproduce it demonstrated that the two are > indeed handled differently. what page in horizon are you editing it form if i try and add/remove the secirty group via the interfaces tabe at https:///dashboard/project/instances// it also work for me inlcuding removing all secuity groups and i am not an admin on this cloud. specificly this is the redhat internal shared cloud i was testing on. > > I believe anyone should be able to reproduce it using the steps I outlined > on the LP. > > Brendan Shephard > > Senior Software Engineer > > Red Hat APAC > > 193 N Quay > > Brisbane City QLD 4000 > @RedHat ? ?Red Hat > ? Red Hat > > > > > > On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney wrote: > > > On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote: > > > Hey Albert, > > > > > > The policy is the default Neutron policy in OpenStack Train. These can > > indeed be changed and customised, but my assumption is that you haven?t > > created any custom policies. Horizon uses the default for each service > > unless it?s been overwritten. > > policy is defiend server side not client side so it applie equially to all > > users of the api > > so the behavior will be the same for horizon or the cli > > if you ever find a delta because horizon say used a differnt token to make > > the request that is a securty vulnerablity in horizon and should be > > reported privatly to the horizon core team :) > > > > > > > > If I create a non-admin user and try to change security groups I also > > get the same error: > > > 2022-09-14 22:01:33,370 64 INFO > > openstack_dashboard.dashboards.project.networks.ports.workflows Failed to > > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and > > rule:update_port:binding:vnic_type) and > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > > And I can reproduce your same scenario ff I try via the CLI using these > > steps: > > > 1. Add entry for new user to clouds.yaml file: > > >? ?bne-home-test: > > >? ? ?auth: > > >? ? ? ?auth_url: https://openstack.bne-home.net:13000 > > >? ? ? ?password: "test" > > >? ? ? ?project_domain_name: Default > > >? ? ? ?project_name: bne-home > > >? ? ? ?user_domain_name: Default > > >? ? ? ?username: test > > >? ? ?cacert: ~/.certs/overcloud-cacert.pem > > >? ? ?identity_api_version: '3' > > >? ? ?region_name: regionOne > > >? ? ?volume_api_version: ?3' > > > > > > 2. export OS_CLOUD=bne-home-test > > > > > > 3. Try to remove security group from port: > > > ? openstack server show test-lb-net -c security_groups -c addresses -f > > yaml > > > addresses: > > >? ?lb-mgmt-net: > > >? ?- 172.24.0.90 > > >? ?vlan4-infra: > > >? ?- 172.20.13.175 > > > security_groups: > > > - name: management-bne > > the security group listed in nova is the default security group that will > > be used by all port create by nova. > > it only applie to ports created by nova and not ones that are passed in > > using the uuid of a precreate port. > > > > you shoudl in general not mix managing security groups via nova and > > neutron. > > horizon shoudl prefer to manage security groups only via neutron if it can. > > > > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips > > -c port_security_enabled -c security_group_ids -f yaml > > > fixed_ips: > > > - ip_address: 172.20.13.175 > > >? ?subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > port_security_enabled: true > > > security_group_ids: > > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f > > > > > > ? openstack port unset --security-group > > a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips > > -c port_security_enabled -c security_group_ids -f yaml > > > fixed_ips: > > > - ip_address: 172.20.13.175 > > >? ?subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > port_security_enabled: true > > > security_group_ids: [] > > > > > > > > > Verify that I?m definitely not a admin user: > > > ? openstack server list --all > > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be > > performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8) > > > > > > > > > I don?t think this user should be allowed to do that via the CLI either. > > So that could be a bug there. The request in the Neutron server.log when I > > do it via the CLI: > > > > > > > > user can add or remove security groups without being and admin including > > removing all securtiy groups thats intended behavior and should not require > > admin. > > > > are you implying that horizon is doing "openstack server list --all" --all > > is short for --all-tenants. > > outside of the admin tab in horizon horizon would never pass the equivlent > > of --all to the nova api. > > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None > > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > 192.168.1.17,172.16.2.85 "PUT > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 > > len: 1102 time: 0.4449480 > > > > > > VS Horizon: > > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None > > req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > 172.20.10.25,172.16.2.85 "PUT > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 > > len: 386 time: 0.2209103 > > > > > > I have raised a upstream bug for this since I can still reproduce it on > > the latest version of OpenStack: > > > https://bugs.launchpad.net/neutron/+bug/1989627? > > > Bug #1989627 ?Policy enforcement variance between openstackcli a...? : > > Bugs : neutron > > > bugs.launchpad.net > > policy is enfoced on the nova/neutron api it cant behave differntly for > > horizon unless horizon is useing the wrong token. > > i.e. not he users token. > > > > > > > > > Brendan Shephard > > > Senior Software Engineer > > > Brisbane, Australia > > > > > > > > > > > > > On 15 Sep 2022, at 2:25 am, Albert Braden wrote: > > > > > > > > Hi Brendan, thanks for offering to help! I'll contact you privately > > with info about some languishing cases. > > > > > > > > Here's the policy line: > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > rule:admin_or_network_owner" > > > > > > > > Does this policy only affect Horizon? I'm using the same non-admin > > user for both CLI and Horizon, on a project where that user is a member. > > The network was created by the admin user. > > > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard < > > bshephar at redhat.com> wrote: > > > > > > > > > > > > Hi Albert, > > > > > > > > While I may not be the best person to address your Horizon concern. I > > can probably help you with your Red Hat support concerns. If you had any > > issues you wanted addressed, or feedback you wanted to provide. Feel free > > to give me a yell. > > > > > > > > Looking at your Horizon issue though. It seems the default policy file > > is what prevents you from updating that port. We can see the default policy > > like this for example: > > > > > > > > [root at controller-2 ~]# podman exec -it neutron_api > > oslopolicy-policy-generator --namespace neutron | grep > > "update_port:port_security_enabled" > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > rule:admin_or_network_owner" > > > > > > > > When you execute the command via the CLI, which user are you using? > > Are you just sourcing the overcloudrc file, or using export > > OS_CLOUD=overcloud. If that?s the case then you would be using the admin > > user on the CLI, but probably a different user when logging into Horizon. > > > > > > > > I too would suggest opening a support case. It sounds like you have > > previously had a negative experience with that. If you want to open a new > > one and share the case number with me, I can follow up on that for you. As > > someone who personally knows a lot of the RHOSP Technical Support team from > > around the world. I?m confident we can right whatever wrong may have > > occurred there. > > > > > > > > Let me know if I can help in any way. > > > > > > > > Regards, > > > > > > > > Brendan Shephard > > > > Senior Software Engineer > > > > Brisbane, Australia > > > > > > > > > > > > > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden wrote: > > > > > > > > > > On CLI I can type "openstack port set --no-security-group " to > > remove all security groups. In Horizon, the equivalent operation would be > > using the - button to remove all groups and then clicking "Update." Using > > the + button would be the equivalent of typing "openstack port set > > --security-group ". There doesn't seem to be a way to remove a > > single security group via CLI; I think the only way would be to set > > --no-security-group and then add back the desired groups. > > > > > > > > > > I can successfully add security groups to a port via CLI, or I can > > remove all security groups. If I go into Horizon and try these operations > > then I get the error when I click "Update." So it appears that security > > groups can be added and removed, with port security set, via CLI. We only > > see the failure when we try to do it via Horizon. > > > > > > > > > > Regarding RHOSP support; I assume that you are joking, or maybe > > haven't experienced the support that they offer. > > > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont < > > laurentfdumont at gmail.com> wrote: > > > > > > > > > > > > > > > If you are running RHOSP, you might have a support contract with Red > > Hat? > > > > > > > > > > Are you trying to remove all the security groups from a port that > > has port_security enabled? > > > > > > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden > > wrote: > > > > > Unfortunately we are running RHOSP in which Train is the latest and > > greatest. This is what we see in horizon.log: > > > > > > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid > > 139683266553600] [remote 10.232.233.11:57498 ] > > Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: > > ((rule:update_port and rule:update_port:binding:vnic_type) and > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < > > pierre at stackhpc.com > wrote: > > > > > > > > > > > > > > > Hello, > > > > > > > > > > This is more likely to be a Horizon bug than an issue with Kolla > > itself, since Kolla doesn't change much from the default configuration. > > > > > > > > > > You should check Horizon logs in /var/log/kolla/horizon to find the > > error. I would also encourage you to upgrade to a more recent release, > > since Train has been marked as End of Life in Kolla recently. > > > > > > > > > > Cheers, > > > > > Pierre Riteau (priteau) > > > > > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden > > wrote: > > > > > We're running kolla train and we're seeing an apparent bug when we > > try to add or remove security groups on a port. We see error "Failed to > > update port ". It works fine in CLI; we only see this in Horizon. Is > > this a known bug, or are we doing something wrong? > > > > > > > > > > > > > > > Hey Albert, > > > > > > The policy is the default Neutron policy in OpenStack Train. These can > > indeed be changed and customised, but my assumption is that you haven?t > > created any custom policies. Horizon uses the default for each service > > unless it?s been overwritten. > > > > > > If I create a non-admin user and try to change security groups I also > > get the same error: > > > 2022-09-14 22:01:33,370 64 INFO > > openstack_dashboard.dashboards.project.networks.ports.workflows Failed to > > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and > > rule:update_port:binding:vnic_type) and > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > > And I can reproduce your same scenario ff I try via the CLI using these > > steps: > > > 1. Add entry for new user to clouds.yaml file: > > >? ?bne-home-test: > > >? ? ?auth: > > >? ? ? ?auth_url: https://openstack.bne-home.net:13000 > > >? ? ? ?password: "test" > > >? ? ? ?project_domain_name: Default > > >? ? ? ?project_name: bne-home > > >? ? ? ?user_domain_name: Default > > >? ? ? ?username: test > > >? ? ?cacert: ~/.certs/overcloud-cacert.pem > > >? ? ?identity_api_version: '3' > > >? ? ?region_name: regionOne > > >? ? ?volume_api_version: ?3' > > > > > > 2. export OS_CLOUD=bne-home-test > > > > > > 3. Try to remove security group from port: > > > ? openstack server show test-lb-net -c security_groups -c addresses -f > > yaml > > > addresses: > > >? ?lb-mgmt-net: > > >? ?- 172.24.0.90 > > >? ?vlan4-infra: > > >? ?- 172.20.13.175 > > > security_groups: > > > - name: management-bne > > > > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips > > -c port_security_enabled -c security_group_ids -f yaml > > > fixed_ips: > > > - ip_address: 172.20.13.175 > > >? ?subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > port_security_enabled: true > > > security_group_ids: > > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f > > > > > > ? openstack port unset --security-group > > a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips > > -c port_security_enabled -c security_group_ids -f yaml > > > fixed_ips: > > > - ip_address: 172.20.13.175 > > >? ?subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > port_security_enabled: true > > > security_group_ids: [] > > > > > > > > > Verify that I?m definitely not a admin user: > > > ? openstack server list --all > > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be > > performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8) > > > > > > > > > I don?t think this user should be allowed to do that via the CLI either. > > So that could be a bug there. The request in the Neutron server.log when I > > do it via the CLI: > > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None > > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > 192.168.1.17,172.16.2.85 "PUT > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 > >? len: 1102 time: 0.4449480 > > > > > > VS Horizon: > > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None > > req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > 172.20.10.25,172.16.2.85 "PUT > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 > >? len: 386 time: 0.2209103 > > > > > > I have raised a upstream bug for this since I can still reproduce it on > > the latest version of OpenStack: > > > launchpad-og-image.pngBug #1989627 ?Policy enforcement variance between > > openstackcli a...? : Bugs : neutron > > > bugs.launchpad.net > > > > > > > > > > > > Brendan Shephard > > > Senior Software Engineer > > > Brisbane, Australia > > > > > > > > > > > > > On 15 Sep 2022, at 2:25 am, Albert Braden wrote: > > > > > > > >? Hi Brendan, thanks for offering to help! I'll contact you privately > > with info about some languishing cases. > > > > > > > > Here's the policy line: > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > rule:admin_or_network_owner" > > > > > > > > Does this policy only affect Horizon? I'm using the same non-admin > > user for both CLI and Horizon, on a project where that user is a member. > > The network was created by the admin user. > > > >? On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard < > > bshephar at redhat.com> wrote: > > > > > > > > > > > > Hi Albert, > > > > > > > > While I may not be the best person to address your Horizon concern. I > > can probably help you with your Red Hat support concerns. If you had any > > issues you wanted addressed, or feedback you wanted to provide. Feel free > > to give me a yell. > > > > > > > > Looking at your Horizon issue though. It seems the default policy file > > is what prevents you from updating that port. We can see the default policy > > like this for example: > > > > > > > > [root at controller-2 ~]# podman exec -it neutron_api > > oslopolicy-policy-generator --namespace neutron | grep > > "update_port:port_security_enabled" > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > rule:admin_or_network_owner" > > > > > > > > When you execute the command via the CLI, which user are you using? > > Are you just sourcing the overcloudrc file, or using export > > OS_CLOUD=overcloud. If that?s the case then you would be using the admin > > user on the CLI, but probably a different user when logging into Horizon. > > > > > > > > I too would suggest opening a support case. It sounds like you have > > previously had a negative experience with that. If you want to open a new > > one and share the case number with me, I can follow up on that for you. As > > someone who personally knows a lot of the RHOSP Technical Support team from > > around the world. I?m confident we can right whatever wrong may have > > occurred there. > > > > > > > > Let me know if I can help in any way. > > > > > > > > Regards, > > > > > > > > Brendan Shephard > > > > Senior Software Engineer > > > > Brisbane, Australia > > > > > > > > > > > > > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden wrote: > > > > > > > > > >? On CLI I can type "openstack port set --no-security-group " to > > remove all security groups. In Horizon, the equivalent operation would be > > using the - button to remove all groups and then clicking "Update." Using > > the + button would be the equivalent of typing "openstack port set > > --security-group ". There doesn't seem to be a way to remove a > > single security group via CLI; I think the only way would be to set > > --no-security-group and then add back the desired groups. > > > > > > > > > > I can successfully add security groups to a port via CLI, or I can > > remove all security groups. If I go into Horizon and try these operations > > then I get the error when I click "Update." So it appears that security > > groups can be added and removed, with port security set, via CLI. We only > > see the failure when we try to do it via Horizon. > > > > > > > > > > Regarding RHOSP support; I assume that you are joking, or maybe > > haven't experienced the support that they offer. > > > > >? On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont < > > laurentfdumont at gmail.com> wrote: > > > > > > > > > > > > > > > If you are running RHOSP, you might have a support contract with Red > > Hat? > > > > > > > > > > Are you trying to remove all the security groups from a port that > > has port_security enabled? > > > > > > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden > > wrote: > > > > > >? Unfortunately we are running RHOSP in which Train is the latest > > and greatest. This is what we see in horizon.log: > > > > > > > > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid > > 139683266553600] [remote 10.232.233.11:57498] Failed to update port > > 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and > > rule:update_port:binding:vnic_type) and > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > >? On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < > > pierre at stackhpc.com> wrote: > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > This is more likely to be a Horizon bug than an issue with Kolla > > itself, since Kolla doesn't change much from the default configuration. > > > > > > > > > > > > You should check Horizon logs in /var/log/kolla/horizon to find > > the error. I would also encourage you to upgrade to a more recent release, > > since Train has been marked as End of Life in Kolla recently. > > > > > > > > > > > > Cheers, > > > > > > Pierre Riteau (priteau) > > > > > > > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden > > wrote: > > > > > > > We're running kolla train and we're seeing an apparent bug when > > we try to add or remove security groups on a port. We see error "Failed to > > update port ". It works fine in CLI; we only see this in Horizon. Is > > this a known bug, or are we doing something wrong? > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bshephar at redhat.com Thu Sep 15 12:54:45 2022 From: bshephar at redhat.com (Brendan Shephard) Date: Thu, 15 Sep 2022 22:54:45 +1000 Subject: [Neutron] [train] Horizon port security group management fails In-Reply-To: <234984793.4131684.1663245983327@mail.yahoo.com> References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> <1541763085.3101109.1663083479831@mail.yahoo.com> <84891126.3588046.1663158984067@mail.yahoo.com> <92876DF2-AAF8-44AF-BFCE-725E2A3AB393@redhat.com> <1338352317.3690165.1663172723209@mail.yahoo.com> <2EA66220-F3CE-4D0A-B8B3-9D67AA5E1AE9@redhat.com> <810befc2c803621d92df50b2f789aa2ff1cbc734.camel@redhat.com> <234984793.4131684.1663245983327@mail.yahoo.com> Message-ID: Hey all, I think we might be onto something here. With the help of @Sean Mooney ++ and @Takashi Kajinami ++. It appears the API request when sent from Horizon contains additional fields that don't require update. But when the request comes from openstackcli, it is just updating the security group field only. openstackcli: REQ: curl -g -i --cacert "/Users/shep/.certs/overcloud-cacert.pem" -X PUT https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda -H "Content-Type: application/json" -H "User-Agent: openstacksdk/0.100.0 keystoneauth1/5.0.0 python-requests/2.28.1 CPython/3.10.6" -H "X-Auth-Token: {SHA256}3ec8b1d0b17434ec67c2960486ec19f17dfb2884fb47c5b54e1cec2beceb1a87" -d '{"port": {"security_groups": ["a3ae6e20-67df-4a72-9d5b-cc21ad87464f", "a31b9954-b7e6-4d4e-887c-e21a59c052ea"]}}' https://openstack.bne-home.net:13696 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" 200 1002 Horizon API call to Neutron: 2022-09-15 00:02:46,820 33 DEBUG neutronclient.client REQ: b'curl -i https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda -X PUT -H "X-Auth-Token: {SHA256}52f077cf0115286c45f1e212cbec4ecdfc56ae41704c869aeb35cea41fdbfde1" -H "User-Agent: python-neutronclient" -d \'{"port": {"name": "", "admin_state_up": true, "port_security_enabled": true, "security_groups": [], "binding:vnic_type": "normal"}}\'' So when Neutron receives that request from Horizon, we get blocked because we (as members) are not permitted to update the port_security_enabled field. Even though it's already set to true in this case. Given that information, the bug is probably back on Horizon here to not include fields that don't require update. Brendan Shephard Senior Software Engineer Red Hat APAC 193 N Quay Brisbane City QLD 4000 @RedHat Red Hat Red Hat On Thu, Sep 15, 2022 at 10:46 PM Albert Braden wrote: > If I add/remove security groups from an instance in Horizon, it works. > It's when I add/remove security groups from a port that the error occurs. > One way to reproduce is to click on the instance and then go to the > "Interfaces" tab, and click "Update Security Groups" on the right. > On Thursday, September 15, 2022, 08:21:17 AM EDT, Brendan Shephard < > bshephar at redhat.com> wrote: > > > Hey, > > I'm doing it from the instances one: > > https://openstack.bne-home.net/dashboard/project/instances/ccb72b14-3694-40fa-9b3b-ec1a8d7ef046/ > > But for what it's worth. I get the same error if I do it from: > > https://openstack.bne-home.net/dashboard/project/networks/acefae53-b4d5-422f-bcca-dc32a0785d21/detail > > Interesting that it worked for you there. Be good to confirm with > @ozzzo at yahoo.com as well as to exactly where in Horizon > he is trying to modify the security groups. Just so we're all trying to do > the exact same thing. > > My environment is also deployed from the latest tripleo packages, so I'll > also test on that internal lab you referenced Sean. That would be more > representative of Alberts issue since he is using RHOSP. > > Brendan Shephard > > Senior Software Engineer > > Red Hat APAC > > 193 N Quay > > Brisbane City QLD 4000 > @RedHat Red Hat > Red Hat > > > > > > On Thu, Sep 15, 2022 at 10:12 PM Sean Mooney wrote: > > On Thu, 2022-09-15 at 21:33 +1000, Brendan Shephard wrote: > > Hey Sean, > > > > Thanks for the reply. > > > > For reference, I have all the steps to reproduce along with the relevant > > debug logs attached to this LP: > > https://bugs.launchpad.net/neutron/+bug/1989627 > > > > But, to summarize. If I go to any random instance in Horizon as a member > > user - not a admin. Then try to remove any Security Group at all from any > > of the ports it fails with the policy violation (I attached a screenshot > of > > where I'm making that change in Horizon). But doing it with the same user > > from the cli works fine. Since I'm editing individual interfaces there, > > rather than the instance itself. I assumed these would all be API calls > to > > Neutron from Horizon rather than from Horizon to Nova. > updating the instance securty group will not affect any exsitng ports > when you want to add or remvoe security groups form a port in horizont > you do not do that via the instace secutity group you do it via the port > edit dialog > in the port detail view under the network > > https:///dashboard/project/networks/ports/ uuid>/detail > > i just did that now on a train cloud we have internally and was able to > add and remove a security group on a port. > > > > > I just run server list --all to demonstrate I was indeed using a member > > user and not a admin since an admin would have seen VM's from all > projects. > > > > I agree with you in principle. It should be exactly the same whether it > > comes from openstackclient or from Horizon. In fact, I was 98% positive I > > would be able to demonstrate the wrong user was being used in this case. > > But unfortunately, my efforts to reproduce it demonstrated that the two > are > > indeed handled differently. > > what page in horizon are you editing it form if i try and add/remove the > secirty group via the interfaces tabe at > https:///dashboard/project/instances// > it also work for me inlcuding removing all secuity groups and i am not an > admin on this cloud. > > specificly this is the redhat internal shared cloud i was testing on. > > > > > I believe anyone should be able to reproduce it using the steps I > outlined > > on the LP. > > > > Brendan Shephard > > > > Senior Software Engineer > > > > Red Hat APAC > > > > 193 N Quay > > > > Brisbane City QLD 4000 > > @RedHat Red Hat > > Red Hat > > > > > > > > > > > > On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney wrote: > > > > > On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote: > > > > Hey Albert, > > > > > > > > The policy is the default Neutron policy in OpenStack Train. These > can > > > indeed be changed and customised, but my assumption is that you haven?t > > > created any custom policies. Horizon uses the default for each service > > > unless it?s been overwritten. > > > policy is defiend server side not client side so it applie equially to > all > > > users of the api > > > so the behavior will be the same for horizon or the cli > > > if you ever find a delta because horizon say used a differnt token to > make > > > the request that is a securty vulnerablity in horizon and should be > > > reported privatly to the horizon core team :) > > > > > > > > > > > If I create a non-admin user and try to change security groups I also > > > get the same error: > > > > 2022-09-14 22:01:33,370 64 INFO > > > openstack_dashboard.dashboards.project.networks.ports.workflows Failed > to > > > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port > and > > > rule:update_port:binding:vnic_type) and > > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > > > > And I can reproduce your same scenario ff I try via the CLI using > these > > > steps: > > > > 1. Add entry for new user to clouds.yaml file: > > > > bne-home-test: > > > > auth: > > > > auth_url: https://openstack.bne-home.net:13000 > > > > password: "test" > > > > project_domain_name: Default > > > > project_name: bne-home > > > > user_domain_name: Default > > > > username: test > > > > cacert: ~/.certs/overcloud-cacert.pem > > > > identity_api_version: '3' > > > > region_name: regionOne > > > > volume_api_version: ?3' > > > > > > > > 2. export OS_CLOUD=bne-home-test > > > > > > > > 3. Try to remove security group from port: > > > > ? openstack server show test-lb-net -c security_groups -c addresses > -f > > > yaml > > > > addresses: > > > > lb-mgmt-net: > > > > - 172.24.0.90 > > > > vlan4-infra: > > > > - 172.20.13.175 > > > > security_groups: > > > > - name: management-bne > > > the security group listed in nova is the default security group that > will > > > be used by all port create by nova. > > > it only applie to ports created by nova and not ones that are passed in > > > using the uuid of a precreate port. > > > > > > you shoudl in general not mix managing security groups via nova and > > > neutron. > > > horizon shoudl prefer to manage security groups only via neutron if it > can. > > > > > > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c > fixed_ips > > > -c port_security_enabled -c security_group_ids -f yaml > > > > fixed_ips: > > > > - ip_address: 172.20.13.175 > > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > > port_security_enabled: true > > > > security_group_ids: > > > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f > > > > > > > > ? openstack port unset --security-group > > > a3ae6e20-67df-4a72-9d5b-cc21ad87464f > 4df563ce-5464-4f7d-8aaf-c5496cdaefda > > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c > fixed_ips > > > -c port_security_enabled -c security_group_ids -f yaml > > > > fixed_ips: > > > > - ip_address: 172.20.13.175 > > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > > port_security_enabled: true > > > > security_group_ids: [] > > > > > > > > > > > > Verify that I?m definitely not a admin user: > > > > ? openstack server list --all > > > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants > to be > > > performed. (HTTP 403) (Request-ID: > req-75c19210-ad91-471f-b500-e1f3482825f8) > > > > > > > > > > > > I don?t think this user should be allowed to do that via the CLI > either. > > > So that could be a bug there. The request in the Neutron server.log > when I > > > do it via the CLI: > > > > > > > > > > > user can add or remove security groups without being and admin > including > > > removing all securtiy groups thats intended behavior and should not > require > > > admin. > > > > > > are you implying that horizon is doing "openstack server list --all" > --all > > > is short for --all-tenants. > > > outside of the admin tab in horizon horizon would never pass the > equivlent > > > of --all to the nova api. > > > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None > > > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 > 781362d053ee4708a21430d3a825795a > > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > > 192.168.1.17,172.16.2.85 "PUT > > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 > > > len: 1102 time: 0.4449480 > > > > > > > > VS Horizon: > > > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None > > > req-4c284690-eb69-43df-b205-4953a88ab87c > 781362d053ee4708a21430d3a825795a > > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > > 172.20.10.25,172.16.2.85 "PUT > > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 > > > len: 386 time: 0.2209103 > > > > > > > > I have raised a upstream bug for this since I can still reproduce it > on > > > the latest version of OpenStack: > > > > https://bugs.launchpad.net/neutron/+bug/1989627? > > > > Bug #1989627 ?Policy enforcement variance between openstackcli a...? > : > > > Bugs : neutron > > > > bugs.launchpad.net > > > policy is enfoced on the nova/neutron api it cant behave differntly for > > > horizon unless horizon is useing the wrong token. > > > i.e. not he users token. > > > > > > > > > > > > Brendan Shephard > > > > Senior Software Engineer > > > > Brisbane, Australia > > > > > > > > > > > > > > > > > On 15 Sep 2022, at 2:25 am, Albert Braden wrote: > > > > > > > > > > Hi Brendan, thanks for offering to help! I'll contact you privately > > > with info about some languishing cases. > > > > > > > > > > Here's the policy line: > > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > > rule:admin_or_network_owner" > > > > > > > > > > Does this policy only affect Horizon? I'm using the same non-admin > > > user for both CLI and Horizon, on a project where that user is a > member. > > > The network was created by the admin user. > > > > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan > Shephard < > > > bshephar at redhat.com> wrote: > > > > > > > > > > > > > > > Hi Albert, > > > > > > > > > > While I may not be the best person to address your Horizon > concern. I > > > can probably help you with your Red Hat support concerns. If you had > any > > > issues you wanted addressed, or feedback you wanted to provide. Feel > free > > > to give me a yell. > > > > > > > > > > Looking at your Horizon issue though. It seems the default policy > file > > > is what prevents you from updating that port. We can see the default > policy > > > like this for example: > > > > > > > > > > [root at controller-2 ~]# podman exec -it neutron_api > > > oslopolicy-policy-generator --namespace neutron | grep > > > "update_port:port_security_enabled" > > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > > rule:admin_or_network_owner" > > > > > > > > > > When you execute the command via the CLI, which user are you using? > > > Are you just sourcing the overcloudrc file, or using export > > > OS_CLOUD=overcloud. If that?s the case then you would be using the > admin > > > user on the CLI, but probably a different user when logging into > Horizon. > > > > > > > > > > I too would suggest opening a support case. It sounds like you have > > > previously had a negative experience with that. If you want to open a > new > > > one and share the case number with me, I can follow up on that for > you. As > > > someone who personally knows a lot of the RHOSP Technical Support team > from > > > around the world. I?m confident we can right whatever wrong may have > > > occurred there. > > > > > > > > > > Let me know if I can help in any way. > > > > > > > > > > Regards, > > > > > > > > > > Brendan Shephard > > > > > Senior Software Engineer > > > > > Brisbane, Australia > > > > > > > > > > > > > > > > > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden > wrote: > > > > > > > > > > > > On CLI I can type "openstack port set --no-security-group " > to > > > remove all security groups. In Horizon, the equivalent operation would > be > > > using the - button to remove all groups and then clicking "Update." > Using > > > the + button would be the equivalent of typing "openstack port set > > > --security-group ". There doesn't seem to be a way to remove > a > > > single security group via CLI; I think the only way would be to set > > > --no-security-group and then add back the desired groups. > > > > > > > > > > > > I can successfully add security groups to a port via CLI, or I > can > > > remove all security groups. If I go into Horizon and try these > operations > > > then I get the error when I click "Update." So it appears that security > > > groups can be added and removed, with port security set, via CLI. We > only > > > see the failure when we try to do it via Horizon. > > > > > > > > > > > > Regarding RHOSP support; I assume that you are joking, or maybe > > > haven't experienced the support that they offer. > > > > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont < > > > laurentfdumont at gmail.com> wrote: > > > > > > > > > > > > > > > > > > If you are running RHOSP, you might have a support contract with > Red > > > Hat? > > > > > > > > > > > > Are you trying to remove all the security groups from a port that > > > has port_security enabled? > > > > > > > > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden > > > wrote: > > > > > > Unfortunately we are running RHOSP in which Train is the latest > and > > > greatest. This is what we see in horizon.log: > > > > > > > > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid > > > 139683266553600] [remote 10.232.233.11:57498 < > http://10.232.233.11:57498/>] > > > Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: > > > ((rule:update_port and rule:update_port:binding:vnic_type) and > > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < > > > pierre at stackhpc.com > wrote: > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > This is more likely to be a Horizon bug than an issue with Kolla > > > itself, since Kolla doesn't change much from the default configuration. > > > > > > > > > > > > You should check Horizon logs in /var/log/kolla/horizon to find > the > > > error. I would also encourage you to upgrade to a more recent release, > > > since Train has been marked as End of Life in Kolla recently. > > > > > > > > > > > > Cheers, > > > > > > Pierre Riteau (priteau) > > > > > > > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden > > > wrote: > > > > > > We're running kolla train and we're seeing an apparent bug when > we > > > try to add or remove security groups on a port. We see error "Failed to > > > update port ". It works fine in CLI; we only see this in Horizon. > Is > > > this a known bug, or are we doing something wrong? > > > > > > > > > > > > > > > > > > > Hey Albert, > > > > > > > > The policy is the default Neutron policy in OpenStack Train. These > can > > > indeed be changed and customised, but my assumption is that you haven?t > > > created any custom policies. Horizon uses the default for each service > > > unless it?s been overwritten. > > > > > > > > If I create a non-admin user and try to change security groups I also > > > get the same error: > > > > 2022-09-14 22:01:33,370 64 INFO > > > openstack_dashboard.dashboards.project.networks.ports.workflows Failed > to > > > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port > and > > > rule:update_port:binding:vnic_type) and > > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > > > > And I can reproduce your same scenario ff I try via the CLI using > these > > > steps: > > > > 1. Add entry for new user to clouds.yaml file: > > > > bne-home-test: > > > > auth: > > > > auth_url: https://openstack.bne-home.net:13000 > > > > password: "test" > > > > project_domain_name: Default > > > > project_name: bne-home > > > > user_domain_name: Default > > > > username: test > > > > cacert: ~/.certs/overcloud-cacert.pem > > > > identity_api_version: '3' > > > > region_name: regionOne > > > > volume_api_version: ?3' > > > > > > > > 2. export OS_CLOUD=bne-home-test > > > > > > > > 3. Try to remove security group from port: > > > > ? openstack server show test-lb-net -c security_groups -c addresses > -f > > > yaml > > > > addresses: > > > > lb-mgmt-net: > > > > - 172.24.0.90 > > > > vlan4-infra: > > > > - 172.20.13.175 > > > > security_groups: > > > > - name: management-bne > > > > > > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c > fixed_ips > > > -c port_security_enabled -c security_group_ids -f yaml > > > > fixed_ips: > > > > - ip_address: 172.20.13.175 > > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > > port_security_enabled: true > > > > security_group_ids: > > > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f > > > > > > > > ? openstack port unset --security-group > > > a3ae6e20-67df-4a72-9d5b-cc21ad87464f > 4df563ce-5464-4f7d-8aaf-c5496cdaefda > > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c > fixed_ips > > > -c port_security_enabled -c security_group_ids -f yaml > > > > fixed_ips: > > > > - ip_address: 172.20.13.175 > > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > > port_security_enabled: true > > > > security_group_ids: [] > > > > > > > > > > > > Verify that I?m definitely not a admin user: > > > > ? openstack server list --all > > > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants > to be > > > performed. (HTTP 403) (Request-ID: > req-75c19210-ad91-471f-b500-e1f3482825f8) > > > > > > > > > > > > I don?t think this user should be allowed to do that via the CLI > either. > > > So that could be a bug there. The request in the Neutron server.log > when I > > > do it via the CLI: > > > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None > > > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 > 781362d053ee4708a21430d3a825795a > > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > > 192.168.1.17,172.16.2.85 "PUT > > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 > > > len: 1102 time: 0.4449480 > > > > > > > > VS Horizon: > > > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None > > > req-4c284690-eb69-43df-b205-4953a88ab87c > 781362d053ee4708a21430d3a825795a > > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > > 172.20.10.25,172.16.2.85 "PUT > > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 > > > len: 386 time: 0.2209103 > > > > > > > > I have raised a upstream bug for this since I can still reproduce it > on > > > the latest version of OpenStack: > > > > launchpad-og-image.pngBug #1989627 ?Policy enforcement variance > between > > > openstackcli a...? : Bugs : neutron > > > > bugs.launchpad.net > > > > > > > > > > > > > > > > Brendan Shephard > > > > Senior Software Engineer > > > > Brisbane, Australia > > > > > > > > > > > > > > > > > On 15 Sep 2022, at 2:25 am, Albert Braden wrote: > > > > > > > > > > Hi Brendan, thanks for offering to help! I'll contact you > privately > > > with info about some languishing cases. > > > > > > > > > > Here's the policy line: > > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > > rule:admin_or_network_owner" > > > > > > > > > > Does this policy only affect Horizon? I'm using the same non-admin > > > user for both CLI and Horizon, on a project where that user is a > member. > > > The network was created by the admin user. > > > > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan > Shephard < > > > bshephar at redhat.com> wrote: > > > > > > > > > > > > > > > Hi Albert, > > > > > > > > > > While I may not be the best person to address your Horizon > concern. I > > > can probably help you with your Red Hat support concerns. If you had > any > > > issues you wanted addressed, or feedback you wanted to provide. Feel > free > > > to give me a yell. > > > > > > > > > > Looking at your Horizon issue though. It seems the default policy > file > > > is what prevents you from updating that port. We can see the default > policy > > > like this for example: > > > > > > > > > > [root at controller-2 ~]# podman exec -it neutron_api > > > oslopolicy-policy-generator --namespace neutron | grep > > > "update_port:port_security_enabled" > > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > > rule:admin_or_network_owner" > > > > > > > > > > When you execute the command via the CLI, which user are you using? > > > Are you just sourcing the overcloudrc file, or using export > > > OS_CLOUD=overcloud. If that?s the case then you would be using the > admin > > > user on the CLI, but probably a different user when logging into > Horizon. > > > > > > > > > > I too would suggest opening a support case. It sounds like you have > > > previously had a negative experience with that. If you want to open a > new > > > one and share the case number with me, I can follow up on that for > you. As > > > someone who personally knows a lot of the RHOSP Technical Support team > from > > > around the world. I?m confident we can right whatever wrong may have > > > occurred there. > > > > > > > > > > Let me know if I can help in any way. > > > > > > > > > > Regards, > > > > > > > > > > Brendan Shephard > > > > > Senior Software Engineer > > > > > Brisbane, Australia > > > > > > > > > > > > > > > > > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden > wrote: > > > > > > > > > > > > On CLI I can type "openstack port set --no-security-group " > to > > > remove all security groups. In Horizon, the equivalent operation would > be > > > using the - button to remove all groups and then clicking "Update." > Using > > > the + button would be the equivalent of typing "openstack port set > > > --security-group ". There doesn't seem to be a way to remove > a > > > single security group via CLI; I think the only way would be to set > > > --no-security-group and then add back the desired groups. > > > > > > > > > > > > I can successfully add security groups to a port via CLI, or I > can > > > remove all security groups. If I go into Horizon and try these > operations > > > then I get the error when I click "Update." So it appears that security > > > groups can be added and removed, with port security set, via CLI. We > only > > > see the failure when we try to do it via Horizon. > > > > > > > > > > > > Regarding RHOSP support; I assume that you are joking, or maybe > > > haven't experienced the support that they offer. > > > > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont > < > > > laurentfdumont at gmail.com> wrote: > > > > > > > > > > > > > > > > > > If you are running RHOSP, you might have a support contract with > Red > > > Hat? > > > > > > > > > > > > Are you trying to remove all the security groups from a port that > > > has port_security enabled? > > > > > > > > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden > > > wrote: > > > > > > > Unfortunately we are running RHOSP in which Train is the > latest > > > and greatest. This is what we see in horizon.log: > > > > > > > > > > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid > > > 139683266553600] [remote 10.232.233.11:57498] Failed to update port > > > 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and > > > rule:update_port:binding:vnic_type) and > > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < > > > pierre at stackhpc.com> wrote: > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > This is more likely to be a Horizon bug than an issue with > Kolla > > > itself, since Kolla doesn't change much from the default configuration. > > > > > > > > > > > > > > You should check Horizon logs in /var/log/kolla/horizon to find > > > the error. I would also encourage you to upgrade to a more recent > release, > > > since Train has been marked as End of Life in Kolla recently. > > > > > > > > > > > > > > Cheers, > > > > > > > Pierre Riteau (priteau) > > > > > > > > > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden > > > wrote: > > > > > > > > We're running kolla train and we're seeing an apparent bug > when > > > we try to add or remove security groups on a port. We see error > "Failed to > > > update port ". It works fine in CLI; we only see this in Horizon. > Is > > > this a known bug, or are we doing something wrong? > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre at stackhpc.com Thu Sep 15 13:46:01 2022 From: pierre at stackhpc.com (Pierre Riteau) Date: Thu, 15 Sep 2022 15:46:01 +0200 Subject: [blazar][FFE] Improvements to ExternalServiceFilter Message-ID: Hello, We have merged a new Blazar usage enforcement filter late into the cycle, but have since received a change from Rados?aw Piliszek (yoctozepto) improving it [1]. It is important for us to get this merged for Zed, as it changes the name of new configuration options. Not merging it now would require us to deprecate the newly added configuration options in Antelope. I am planning to grant an FFE for it just before issuing RC1. Cheers, Pierre Riteau (priteau) [1] https://review.opendev.org/c/openstack/blazar/+/856527 -------------- next part -------------- An HTML attachment was scrubbed... URL: From amoralej at redhat.com Thu Sep 15 13:55:18 2022 From: amoralej at redhat.com (Alfredo Moralejo Alonso) Date: Thu, 15 Sep 2022 15:55:18 +0200 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 In-Reply-To: References: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> Message-ID: On Fri, Sep 9, 2022 at 4:27 PM Pierre Riteau wrote: > On Tue, 6 Sept 2022 at 12:40, Stephen Finucane > wrote: > >> I did those yesterday. >> >> Aodh: https://review.opendev.org/c/openstack/aodh/+/855962 >> Designate: https://review.opendev.org/c/openstack/designate/+/855965 >> Manila: https://review.opendev.org/c/openstack/manila/+/855967 >> Ironic: https://review.opendev.org/c/openstack/ironic/+/855969 >> Heat: https://review.opendev.org/c/openstack/heat/+/855970 >> Barbican: https://review.opendev.org/c/openstack/barbican/+/855972 >> >> The barbican one isn't correct and I need to respin it. The rest are >> working as >> expected though, as proven at [1]. >> >> Stephen >> >> [1] https://review.opendev.org/c/openstack/requirements/+/855973/ > > > Hi, > > Rados?aw Piliszek (yoctozepto) and I have discovered that Blazar is also > broken by the release of oslo.db 12.1.0: CI jobs are failing CI jobs in [1]. > I will try to fix it like Stephen did for other projects, but I would like > to flag that it is possible other projects are impacted: in particular we > should check any smaller project that doesn't run CI jobs regularly. > According to some functional jobs run in RDO, watcher and ec2-api projects are also affected. I've sent https://review.opendev.org/c/openstack/ec2-api/+/857880 but the gate seems blocked by some other issue. Regards, Alfredo > > This reminds me of the breakage we had at the end of the last cycle with > oslo.context 4.0.0 [2]. > > Cheers, > Pierre Riteau (priteau) > > [1] https://review.opendev.org/c/openstack/blazar/+/856527 > [2] > https://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdopiera at redhat.com Thu Sep 15 13:56:21 2022 From: rdopiera at redhat.com (Radomir Dopieralski) Date: Thu, 15 Sep 2022 15:56:21 +0200 Subject: [Neutron] [train] Horizon port security group management fails In-Reply-To: References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> <1541763085.3101109.1663083479831@mail.yahoo.com> <84891126.3588046.1663158984067@mail.yahoo.com> <92876DF2-AAF8-44AF-BFCE-725E2A3AB393@redhat.com> <1338352317.3690165.1663172723209@mail.yahoo.com> <2EA66220-F3CE-4D0A-B8B3-9D67AA5E1AE9@redhat.com> <810befc2c803621d92df50b2f789aa2ff1cbc734.camel@redhat.com> <234984793.4131684.1663245983327@mail.yahoo.com> Message-ID: It's a known problem and there is a patch for it in review for quite some time: https://review.opendev.org/c/openstack/horizon/+/810224 On Thu, Sep 15, 2022 at 3:36 PM Brendan Shephard wrote: > Hey all, > > I think we might be onto something here. With the help of @Sean Mooney > ++ and @Takashi Kajinami ++. > It appears the API request when sent from Horizon contains additional > fields that don't require update. But when the request comes from > openstackcli, it is just updating the security group field only. > > openstackcli: > REQ: curl -g -i --cacert "/Users/shep/.certs/overcloud-cacert.pem" -X PUT > https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda > -H "Content-Type: application/json" -H "User-Agent: openstacksdk/0.100.0 > keystoneauth1/5.0.0 python-requests/2.28.1 CPython/3.10.6" -H > "X-Auth-Token: > {SHA256}3ec8b1d0b17434ec67c2960486ec19f17dfb2884fb47c5b54e1cec2beceb1a87" > -d '{"port": {"security_groups": ["a3ae6e20-67df-4a72-9d5b-cc21ad87464f", > "a31b9954-b7e6-4d4e-887c-e21a59c052ea"]}}' > https://openstack.bne-home.net:13696 "PUT > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" 200 1002 > > > Horizon API call to Neutron: > 2022-09-15 00:02:46,820 33 DEBUG neutronclient.client REQ: b'curl -i > https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda > -X PUT -H "X-Auth-Token: > {SHA256}52f077cf0115286c45f1e212cbec4ecdfc56ae41704c869aeb35cea41fdbfde1" > -H "User-Agent: python-neutronclient" -d \'{"port": {"name": "", > "admin_state_up": true, "port_security_enabled": true, "security_groups": > [], "binding:vnic_type": "normal"}}\'' > > So when Neutron receives that request from Horizon, we get blocked because > we (as members) are not permitted to update the port_security_enabled > field. Even though it's already set to true in this case. > > Given that information, the bug is probably back on Horizon here to not > include fields that don't require update. > > Brendan Shephard > > Senior Software Engineer > > Red Hat APAC > > 193 N Quay > > Brisbane City QLD 4000 > @RedHat Red Hat > Red Hat > > > > > > On Thu, Sep 15, 2022 at 10:46 PM Albert Braden wrote: > >> If I add/remove security groups from an instance in Horizon, it works. >> It's when I add/remove security groups from a port that the error occurs. >> One way to reproduce is to click on the instance and then go to the >> "Interfaces" tab, and click "Update Security Groups" on the right. >> On Thursday, September 15, 2022, 08:21:17 AM EDT, Brendan Shephard < >> bshephar at redhat.com> wrote: >> >> >> Hey, >> >> I'm doing it from the instances one: >> >> https://openstack.bne-home.net/dashboard/project/instances/ccb72b14-3694-40fa-9b3b-ec1a8d7ef046/ >> >> But for what it's worth. I get the same error if I do it from: >> >> https://openstack.bne-home.net/dashboard/project/networks/acefae53-b4d5-422f-bcca-dc32a0785d21/detail >> >> Interesting that it worked for you there. Be good to confirm with >> @ozzzo at yahoo.com as well as to exactly where in >> Horizon he is trying to modify the security groups. Just so we're all >> trying to do the exact same thing. >> >> My environment is also deployed from the latest tripleo packages, so I'll >> also test on that internal lab you referenced Sean. That would be more >> representative of Alberts issue since he is using RHOSP. >> >> Brendan Shephard >> >> Senior Software Engineer >> >> Red Hat APAC >> >> 193 N Quay >> >> Brisbane City QLD 4000 >> @RedHat Red Hat >> Red Hat >> >> >> >> >> >> On Thu, Sep 15, 2022 at 10:12 PM Sean Mooney wrote: >> >> On Thu, 2022-09-15 at 21:33 +1000, Brendan Shephard wrote: >> > Hey Sean, >> > >> > Thanks for the reply. >> > >> > For reference, I have all the steps to reproduce along with the relevant >> > debug logs attached to this LP: >> > https://bugs.launchpad.net/neutron/+bug/1989627 >> > >> > But, to summarize. If I go to any random instance in Horizon as a member >> > user - not a admin. Then try to remove any Security Group at all from >> any >> > of the ports it fails with the policy violation (I attached a >> screenshot of >> > where I'm making that change in Horizon). But doing it with the same >> user >> > from the cli works fine. Since I'm editing individual interfaces there, >> > rather than the instance itself. I assumed these would all be API calls >> to >> > Neutron from Horizon rather than from Horizon to Nova. >> updating the instance securty group will not affect any exsitng ports >> when you want to add or remvoe security groups form a port in horizont >> you do not do that via the instace secutity group you do it via the port >> edit dialog >> in the port detail view under the network >> >> https:///dashboard/project/networks/ports/> uuid>/detail >> >> i just did that now on a train cloud we have internally and was able to >> add and remove a security group on a port. >> >> > >> > I just run server list --all to demonstrate I was indeed using a member >> > user and not a admin since an admin would have seen VM's from all >> projects. >> > >> > I agree with you in principle. It should be exactly the same whether it >> > comes from openstackclient or from Horizon. In fact, I was 98% positive >> I >> > would be able to demonstrate the wrong user was being used in this case. >> > But unfortunately, my efforts to reproduce it demonstrated that the two >> are >> > indeed handled differently. >> >> what page in horizon are you editing it form if i try and add/remove the >> secirty group via the interfaces tabe at >> https:///dashboard/project/instances// >> it also work for me inlcuding removing all secuity groups and i am not an >> admin on this cloud. >> >> specificly this is the redhat internal shared cloud i was testing on. >> >> > >> > I believe anyone should be able to reproduce it using the steps I >> outlined >> > on the LP. >> > >> > Brendan Shephard >> > >> > Senior Software Engineer >> > >> > Red Hat APAC >> > >> > 193 N Quay >> > >> > Brisbane City QLD 4000 >> > @RedHat Red Hat >> > Red Hat >> > >> > >> > >> > >> > >> > On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney wrote: >> > >> > > On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote: >> > > > Hey Albert, >> > > > >> > > > The policy is the default Neutron policy in OpenStack Train. These >> can >> > > indeed be changed and customised, but my assumption is that you >> haven?t >> > > created any custom policies. Horizon uses the default for each service >> > > unless it?s been overwritten. >> > > policy is defiend server side not client side so it applie equially >> to all >> > > users of the api >> > > so the behavior will be the same for horizon or the cli >> > > if you ever find a delta because horizon say used a differnt token to >> make >> > > the request that is a securty vulnerablity in horizon and should be >> > > reported privatly to the horizon core team :) >> > > >> > > > >> > > > If I create a non-admin user and try to change security groups I >> also >> > > get the same error: >> > > > 2022-09-14 22:01:33,370 64 INFO >> > > openstack_dashboard.dashboards.project.networks.ports.workflows >> Failed to >> > > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port >> and >> > > rule:update_port:binding:vnic_type) and >> > > rule:update_port:port_security_enabled) is disallowed by policy >> > > > >> > > > And I can reproduce your same scenario ff I try via the CLI using >> these >> > > steps: >> > > > 1. Add entry for new user to clouds.yaml file: >> > > > bne-home-test: >> > > > auth: >> > > > auth_url: https://openstack.bne-home.net:13000 >> > > > password: "test" >> > > > project_domain_name: Default >> > > > project_name: bne-home >> > > > user_domain_name: Default >> > > > username: test >> > > > cacert: ~/.certs/overcloud-cacert.pem >> > > > identity_api_version: '3' >> > > > region_name: regionOne >> > > > volume_api_version: ?3' >> > > > >> > > > 2. export OS_CLOUD=bne-home-test >> > > > >> > > > 3. Try to remove security group from port: >> > > > ? openstack server show test-lb-net -c security_groups -c addresses >> -f >> > > yaml >> > > > addresses: >> > > > lb-mgmt-net: >> > > > - 172.24.0.90 >> > > > vlan4-infra: >> > > > - 172.20.13.175 >> > > > security_groups: >> > > > - name: management-bne >> > > the security group listed in nova is the default security group that >> will >> > > be used by all port create by nova. >> > > it only applie to ports created by nova and not ones that are passed >> in >> > > using the uuid of a precreate port. >> > > >> > > you shoudl in general not mix managing security groups via nova and >> > > neutron. >> > > horizon shoudl prefer to manage security groups only via neutron if >> it can. >> > > > >> > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c >> fixed_ips >> > > -c port_security_enabled -c security_group_ids -f yaml >> > > > fixed_ips: >> > > > - ip_address: 172.20.13.175 >> > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 >> > > > port_security_enabled: true >> > > > security_group_ids: >> > > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f >> > > > >> > > > ? openstack port unset --security-group >> > > a3ae6e20-67df-4a72-9d5b-cc21ad87464f >> 4df563ce-5464-4f7d-8aaf-c5496cdaefda >> > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c >> fixed_ips >> > > -c port_security_enabled -c security_group_ids -f yaml >> > > > fixed_ips: >> > > > - ip_address: 172.20.13.175 >> > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 >> > > > port_security_enabled: true >> > > > security_group_ids: [] >> > > > >> > > > >> > > > Verify that I?m definitely not a admin user: >> > > > ? openstack server list --all >> > > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants >> to be >> > > performed. (HTTP 403) (Request-ID: >> req-75c19210-ad91-471f-b500-e1f3482825f8) >> > > > >> > > > >> > > > I don?t think this user should be allowed to do that via the CLI >> either. >> > > So that could be a bug there. The request in the Neutron server.log >> when I >> > > do it via the CLI: >> > > > >> > > > >> > > user can add or remove security groups without being and admin >> including >> > > removing all securtiy groups thats intended behavior and should not >> require >> > > admin. >> > > >> > > are you implying that horizon is doing "openstack server list --all" >> --all >> > > is short for --all-tenants. >> > > outside of the admin tab in horizon horizon would never pass the >> equivlent >> > > of --all to the nova api. >> > > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None >> > > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 >> 781362d053ee4708a21430d3a825795a >> > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] >> > > 192.168.1.17,172.16.2.85 "PUT >> > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 >> > > len: 1102 time: 0.4449480 >> > > > >> > > > VS Horizon: >> > > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None >> > > req-4c284690-eb69-43df-b205-4953a88ab87c >> 781362d053ee4708a21430d3a825795a >> > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] >> > > 172.20.10.25,172.16.2.85 "PUT >> > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 >> > > len: 386 time: 0.2209103 >> > > > >> > > > I have raised a upstream bug for this since I can still reproduce >> it on >> > > the latest version of OpenStack: >> > > > https://bugs.launchpad.net/neutron/+bug/1989627? >> > > > Bug #1989627 ?Policy enforcement variance between openstackcli >> a...? : >> > > Bugs : neutron >> > > > bugs.launchpad.net >> > > policy is enfoced on the nova/neutron api it cant behave differntly >> for >> > > horizon unless horizon is useing the wrong token. >> > > i.e. not he users token. >> > > > >> > > > >> > > > Brendan Shephard >> > > > Senior Software Engineer >> > > > Brisbane, Australia >> > > > >> > > > >> > > > >> > > > > On 15 Sep 2022, at 2:25 am, Albert Braden >> wrote: >> > > > > >> > > > > Hi Brendan, thanks for offering to help! I'll contact you >> privately >> > > with info about some languishing cases. >> > > > > >> > > > > Here's the policy line: >> > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or >> > > rule:admin_or_network_owner" >> > > > > >> > > > > Does this policy only affect Horizon? I'm using the same non-admin >> > > user for both CLI and Horizon, on a project where that user is a >> member. >> > > The network was created by the admin user. >> > > > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan >> Shephard < >> > > bshephar at redhat.com> wrote: >> > > > > >> > > > > >> > > > > Hi Albert, >> > > > > >> > > > > While I may not be the best person to address your Horizon >> concern. I >> > > can probably help you with your Red Hat support concerns. If you had >> any >> > > issues you wanted addressed, or feedback you wanted to provide. Feel >> free >> > > to give me a yell. >> > > > > >> > > > > Looking at your Horizon issue though. It seems the default policy >> file >> > > is what prevents you from updating that port. We can see the default >> policy >> > > like this for example: >> > > > > >> > > > > [root at controller-2 ~]# podman exec -it neutron_api >> > > oslopolicy-policy-generator --namespace neutron | grep >> > > "update_port:port_security_enabled" >> > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or >> > > rule:admin_or_network_owner" >> > > > > >> > > > > When you execute the command via the CLI, which user are you >> using? >> > > Are you just sourcing the overcloudrc file, or using export >> > > OS_CLOUD=overcloud. If that?s the case then you would be using the >> admin >> > > user on the CLI, but probably a different user when logging into >> Horizon. >> > > > > >> > > > > I too would suggest opening a support case. It sounds like you >> have >> > > previously had a negative experience with that. If you want to open a >> new >> > > one and share the case number with me, I can follow up on that for >> you. As >> > > someone who personally knows a lot of the RHOSP Technical Support >> team from >> > > around the world. I?m confident we can right whatever wrong may have >> > > occurred there. >> > > > > >> > > > > Let me know if I can help in any way. >> > > > > >> > > > > Regards, >> > > > > >> > > > > Brendan Shephard >> > > > > Senior Software Engineer >> > > > > Brisbane, Australia >> > > > > >> > > > > >> > > > > >> > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden >> wrote: >> > > > > > >> > > > > > On CLI I can type "openstack port set --no-security-group " >> to >> > > remove all security groups. In Horizon, the equivalent operation >> would be >> > > using the - button to remove all groups and then clicking "Update." >> Using >> > > the + button would be the equivalent of typing "openstack port set >> > > --security-group ". There doesn't seem to be a way to >> remove a >> > > single security group via CLI; I think the only way would be to set >> > > --no-security-group and then add back the desired groups. >> > > > > > >> > > > > > I can successfully add security groups to a port via CLI, or I >> can >> > > remove all security groups. If I go into Horizon and try these >> operations >> > > then I get the error when I click "Update." So it appears that >> security >> > > groups can be added and removed, with port security set, via CLI. We >> only >> > > see the failure when we try to do it via Horizon. >> > > > > > >> > > > > > Regarding RHOSP support; I assume that you are joking, or maybe >> > > haven't experienced the support that they offer. >> > > > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont >> < >> > > laurentfdumont at gmail.com> wrote: >> > > > > > >> > > > > > >> > > > > > If you are running RHOSP, you might have a support contract >> with Red >> > > Hat? >> > > > > > >> > > > > > Are you trying to remove all the security groups from a port >> that >> > > has port_security enabled? >> > > > > > >> > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden > > > > wrote: >> > > > > > Unfortunately we are running RHOSP in which Train is the latest >> and >> > > greatest. This is what we see in horizon.log: >> > > > > > >> > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid >> > > 139683266553600] [remote 10.232.233.11:57498 < >> http://10.232.233.11:57498/>] >> > > Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: >> > > ((rule:update_port and rule:update_port:binding:vnic_type) and >> > > rule:update_port:port_security_enabled) is disallowed by policy >> > > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < >> > > pierre at stackhpc.com > wrote: >> > > > > > >> > > > > > >> > > > > > Hello, >> > > > > > >> > > > > > This is more likely to be a Horizon bug than an issue with Kolla >> > > itself, since Kolla doesn't change much from the default >> configuration. >> > > > > > >> > > > > > You should check Horizon logs in /var/log/kolla/horizon to find >> the >> > > error. I would also encourage you to upgrade to a more recent release, >> > > since Train has been marked as End of Life in Kolla recently. >> > > > > > >> > > > > > Cheers, >> > > > > > Pierre Riteau (priteau) >> > > > > > >> > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden > > > > wrote: >> > > > > > We're running kolla train and we're seeing an apparent bug when >> we >> > > try to add or remove security groups on a port. We see error "Failed >> to >> > > update port ". It works fine in CLI; we only see this in Horizon. >> Is >> > > this a known bug, or are we doing something wrong? >> > > > > > >> > > > > >> > > > >> > > > Hey Albert, >> > > > >> > > > The policy is the default Neutron policy in OpenStack Train. These >> can >> > > indeed be changed and customised, but my assumption is that you >> haven?t >> > > created any custom policies. Horizon uses the default for each service >> > > unless it?s been overwritten. >> > > > >> > > > If I create a non-admin user and try to change security groups I >> also >> > > get the same error: >> > > > 2022-09-14 22:01:33,370 64 INFO >> > > openstack_dashboard.dashboards.project.networks.ports.workflows >> Failed to >> > > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port >> and >> > > rule:update_port:binding:vnic_type) and >> > > rule:update_port:port_security_enabled) is disallowed by policy >> > > > >> > > > And I can reproduce your same scenario ff I try via the CLI using >> these >> > > steps: >> > > > 1. Add entry for new user to clouds.yaml file: >> > > > bne-home-test: >> > > > auth: >> > > > auth_url: https://openstack.bne-home.net:13000 >> > > > password: "test" >> > > > project_domain_name: Default >> > > > project_name: bne-home >> > > > user_domain_name: Default >> > > > username: test >> > > > cacert: ~/.certs/overcloud-cacert.pem >> > > > identity_api_version: '3' >> > > > region_name: regionOne >> > > > volume_api_version: ?3' >> > > > >> > > > 2. export OS_CLOUD=bne-home-test >> > > > >> > > > 3. Try to remove security group from port: >> > > > ? openstack server show test-lb-net -c security_groups -c addresses >> -f >> > > yaml >> > > > addresses: >> > > > lb-mgmt-net: >> > > > - 172.24.0.90 >> > > > vlan4-infra: >> > > > - 172.20.13.175 >> > > > security_groups: >> > > > - name: management-bne >> > > > >> > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c >> fixed_ips >> > > -c port_security_enabled -c security_group_ids -f yaml >> > > > fixed_ips: >> > > > - ip_address: 172.20.13.175 >> > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 >> > > > port_security_enabled: true >> > > > security_group_ids: >> > > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f >> > > > >> > > > ? openstack port unset --security-group >> > > a3ae6e20-67df-4a72-9d5b-cc21ad87464f >> 4df563ce-5464-4f7d-8aaf-c5496cdaefda >> > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c >> fixed_ips >> > > -c port_security_enabled -c security_group_ids -f yaml >> > > > fixed_ips: >> > > > - ip_address: 172.20.13.175 >> > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 >> > > > port_security_enabled: true >> > > > security_group_ids: [] >> > > > >> > > > >> > > > Verify that I?m definitely not a admin user: >> > > > ? openstack server list --all >> > > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants >> to be >> > > performed. (HTTP 403) (Request-ID: >> req-75c19210-ad91-471f-b500-e1f3482825f8) >> > > > >> > > > >> > > > I don?t think this user should be allowed to do that via the CLI >> either. >> > > So that could be a bug there. The request in the Neutron server.log >> when I >> > > do it via the CLI: >> > > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None >> > > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 >> 781362d053ee4708a21430d3a825795a >> > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] >> > > 192.168.1.17,172.16.2.85 "PUT >> > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 >> > > len: 1102 time: 0.4449480 >> > > > >> > > > VS Horizon: >> > > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None >> > > req-4c284690-eb69-43df-b205-4953a88ab87c >> 781362d053ee4708a21430d3a825795a >> > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] >> > > 172.20.10.25,172.16.2.85 "PUT >> > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 >> > > len: 386 time: 0.2209103 >> > > > >> > > > I have raised a upstream bug for this since I can still reproduce >> it on >> > > the latest version of OpenStack: >> > > > launchpad-og-image.pngBug #1989627 ?Policy enforcement variance >> between >> > > openstackcli a...? : Bugs : neutron >> > > > bugs.launchpad.net >> > > > >> > > > >> > > > >> > > > Brendan Shephard >> > > > Senior Software Engineer >> > > > Brisbane, Australia >> > > > >> > > > >> > > > >> > > > > On 15 Sep 2022, at 2:25 am, Albert Braden >> wrote: >> > > > > >> > > > > Hi Brendan, thanks for offering to help! I'll contact you >> privately >> > > with info about some languishing cases. >> > > > > >> > > > > Here's the policy line: >> > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or >> > > rule:admin_or_network_owner" >> > > > > >> > > > > Does this policy only affect Horizon? I'm using the same non-admin >> > > user for both CLI and Horizon, on a project where that user is a >> member. >> > > The network was created by the admin user. >> > > > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan >> Shephard < >> > > bshephar at redhat.com> wrote: >> > > > > >> > > > > >> > > > > Hi Albert, >> > > > > >> > > > > While I may not be the best person to address your Horizon >> concern. I >> > > can probably help you with your Red Hat support concerns. If you had >> any >> > > issues you wanted addressed, or feedback you wanted to provide. Feel >> free >> > > to give me a yell. >> > > > > >> > > > > Looking at your Horizon issue though. It seems the default policy >> file >> > > is what prevents you from updating that port. We can see the default >> policy >> > > like this for example: >> > > > > >> > > > > [root at controller-2 ~]# podman exec -it neutron_api >> > > oslopolicy-policy-generator --namespace neutron | grep >> > > "update_port:port_security_enabled" >> > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or >> > > rule:admin_or_network_owner" >> > > > > >> > > > > When you execute the command via the CLI, which user are you >> using? >> > > Are you just sourcing the overcloudrc file, or using export >> > > OS_CLOUD=overcloud. If that?s the case then you would be using the >> admin >> > > user on the CLI, but probably a different user when logging into >> Horizon. >> > > > > >> > > > > I too would suggest opening a support case. It sounds like you >> have >> > > previously had a negative experience with that. If you want to open a >> new >> > > one and share the case number with me, I can follow up on that for >> you. As >> > > someone who personally knows a lot of the RHOSP Technical Support >> team from >> > > around the world. I?m confident we can right whatever wrong may have >> > > occurred there. >> > > > > >> > > > > Let me know if I can help in any way. >> > > > > >> > > > > Regards, >> > > > > >> > > > > Brendan Shephard >> > > > > Senior Software Engineer >> > > > > Brisbane, Australia >> > > > > >> > > > > >> > > > > >> > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden >> wrote: >> > > > > > >> > > > > > On CLI I can type "openstack port set --no-security-group >> " to >> > > remove all security groups. In Horizon, the equivalent operation >> would be >> > > using the - button to remove all groups and then clicking "Update." >> Using >> > > the + button would be the equivalent of typing "openstack port set >> > > --security-group ". There doesn't seem to be a way to >> remove a >> > > single security group via CLI; I think the only way would be to set >> > > --no-security-group and then add back the desired groups. >> > > > > > >> > > > > > I can successfully add security groups to a port via CLI, or I >> can >> > > remove all security groups. If I go into Horizon and try these >> operations >> > > then I get the error when I click "Update." So it appears that >> security >> > > groups can be added and removed, with port security set, via CLI. We >> only >> > > see the failure when we try to do it via Horizon. >> > > > > > >> > > > > > Regarding RHOSP support; I assume that you are joking, or maybe >> > > haven't experienced the support that they offer. >> > > > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent >> Dumont < >> > > laurentfdumont at gmail.com> wrote: >> > > > > > >> > > > > > >> > > > > > If you are running RHOSP, you might have a support contract >> with Red >> > > Hat? >> > > > > > >> > > > > > Are you trying to remove all the security groups from a port >> that >> > > has port_security enabled? >> > > > > > >> > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden > > >> > > wrote: >> > > > > > > Unfortunately we are running RHOSP in which Train is the >> latest >> > > and greatest. This is what we see in horizon.log: >> > > > > > > >> > > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid >> > > 139683266553600] [remote 10.232.233.11:57498] Failed to update port >> > > 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and >> > > rule:update_port:binding:vnic_type) and >> > > rule:update_port:port_security_enabled) is disallowed by policy >> > > > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau >> < >> > > pierre at stackhpc.com> wrote: >> > > > > > > >> > > > > > > >> > > > > > > Hello, >> > > > > > > >> > > > > > > This is more likely to be a Horizon bug than an issue with >> Kolla >> > > itself, since Kolla doesn't change much from the default >> configuration. >> > > > > > > >> > > > > > > You should check Horizon logs in /var/log/kolla/horizon to >> find >> > > the error. I would also encourage you to upgrade to a more recent >> release, >> > > since Train has been marked as End of Life in Kolla recently. >> > > > > > > >> > > > > > > Cheers, >> > > > > > > Pierre Riteau (priteau) >> > > > > > > >> > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden >> > > wrote: >> > > > > > > > We're running kolla train and we're seeing an apparent bug >> when >> > > we try to add or remove security groups on a port. We see error >> "Failed to >> > > update port ". It works fine in CLI; we only see this in Horizon. >> Is >> > > this a known bug, or are we doing something wrong? >> > > > > > > > >> > > > > >> > > > >> > > >> > > >> >> -- Radomir Dopieralski -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdhasman at redhat.com Thu Sep 15 14:05:31 2022 From: rdhasman at redhat.com (Rajat Dhasmana) Date: Thu, 15 Sep 2022 19:35:31 +0530 Subject: [cinder] Festival of XS reviews Message-ID: Hello Argonauts, We will be having our monthly festival of XS reviews tomorrow i.e. 16th September (Friday) from 1400-1600 UTC. Following are some additional details: Date: 16th September, 2022 Time: 1400-1600 UTC Meeting link: https://bluejeans.com/556681290 etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews -------------- next part -------------- An HTML attachment was scrubbed... URL: From ozzzo at yahoo.com Thu Sep 15 14:45:24 2022 From: ozzzo at yahoo.com (Albert Braden) Date: Thu, 15 Sep 2022 14:45:24 +0000 (UTC) Subject: [Neutron] [train] Horizon port security group management fails In-Reply-To: References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> <1541763085.3101109.1663083479831@mail.yahoo.com> <84891126.3588046.1663158984067@mail.yahoo.com> <92876DF2-AAF8-44AF-BFCE-725E2A3AB393@redhat.com> <1338352317.3690165.1663172723209@mail.yahoo.com> <2EA66220-F3CE-4D0A-B8B3-9D67AA5E1AE9@redhat.com> <810befc2c803621d92df50b2f789aa2ff1cbc734.camel@redhat.com> <234984793.4131684.1663245983327@mail.yahoo.com> Message-ID: <618165.4193992.1663253124271@mail.yahoo.com> Also I see this one that failed to pass Zuul. https://review.opendev.org/c/openstack/horizon/+/819027/1/openstack_dashboard/dashboards/project/networks/ports/workflows.py On Thursday, September 15, 2022, 10:34:50 AM EDT, Radomir Dopieralski wrote: It's a known problem and there is a patch for it in review for quite some time:?https://review.opendev.org/c/openstack/horizon/+/810224 On Thu, Sep 15, 2022 at 3:36 PM Brendan Shephard wrote: Hey all, I think we might be onto something here. With the help of?@Sean Mooney?++ and?@Takashi Kajinami?++. It appears the API request when sent from Horizon contains additional fields that don't require update. But when the request comes from openstackcli, it is just updating the security group field only. openstackcli:REQ: curl -g -i --cacert "/Users/shep/.certs/overcloud-cacert.pem" -X PUT https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda -H "Content-Type: application/json" -H "User-Agent: openstacksdk/0.100.0 keystoneauth1/5.0.0 python-requests/2.28.1 CPython/3.10.6" -H "X-Auth-Token: {SHA256}3ec8b1d0b17434ec67c2960486ec19f17dfb2884fb47c5b54e1cec2beceb1a87" -d '{"port": {"security_groups": ["a3ae6e20-67df-4a72-9d5b-cc21ad87464f", "a31b9954-b7e6-4d4e-887c-e21a59c052ea"]}}' https://openstack.bne-home.net:13696 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" 200 1002 Horizon API call to Neutron:2022-09-15 00:02:46,820 33 DEBUG neutronclient.client REQ: b'curl -i https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda -X PUT -H "X-Auth-Token: {SHA256}52f077cf0115286c45f1e212cbec4ecdfc56ae41704c869aeb35cea41fdbfde1" -H "User-Agent: python-neutronclient" -d \'{"port": {"name": "", "admin_state_up": true, "port_security_enabled": true, "security_groups": [], "binding:vnic_type": "normal"}}\'' So when Neutron receives that request from Horizon, we get blocked because we (as members) are not permitted to update the port_security_enabled field. Even though it's already set to true in this case. Given that information, the bug is probably back on Horizon here to not include fields that don't require update. Brendan Shephard Senior Software Engineer Red Hat APAC 193 N Quay Brisbane City QLD 4000 @RedHat ? Red Hat ? Red Hat | | | On Thu, Sep 15, 2022 at 10:46 PM Albert Braden wrote: If I add/remove security groups from an instance in Horizon, it works. It's when I add/remove security groups from a port that the error occurs. One way to reproduce is to click on the instance and then go to the "Interfaces" tab, and click "Update Security Groups" on the right. On Thursday, September 15, 2022, 08:21:17 AM EDT, Brendan Shephard wrote: Hey, I'm doing it from the instances one:https://openstack.bne-home.net/dashboard/project/instances/ccb72b14-3694-40fa-9b3b-ec1a8d7ef046/ But for what it's worth. I get the same error if I do it from:https://openstack.bne-home.net/dashboard/project/networks/acefae53-b4d5-422f-bcca-dc32a0785d21/detail Interesting that it worked for you there. Be good to confirm with?@ozzzo at yahoo.com?as well as to exactly where in Horizon he is trying to modify the security groups. Just so we're all trying to do the exact same thing. My environment is also deployed from the latest tripleo packages, so I'll also test on that internal lab you referenced Sean. That would be more representative of Alberts issue since he is using RHOSP. Brendan Shephard Senior Software Engineer Red Hat APAC 193 N Quay Brisbane City QLD 4000 @RedHat ? Red Hat ? Red Hat | | | On Thu, Sep 15, 2022 at 10:12 PM Sean Mooney wrote: On Thu, 2022-09-15 at 21:33 +1000, Brendan Shephard wrote: > Hey Sean, > > Thanks for the reply. > > For reference, I have all the steps to reproduce along with the relevant > debug logs attached to this LP: > https://bugs.launchpad.net/neutron/+bug/1989627 > > But, to summarize. If I go to any random instance in Horizon as a member > user - not a admin. Then try to remove any Security Group at all from any > of the ports it fails with the policy violation (I attached a screenshot of > where I'm making that change in Horizon). But doing it with the same user > from the cli works fine. Since I'm editing individual interfaces there, > rather than the instance itself. I assumed these would all be API calls to > Neutron from Horizon rather than from Horizon to Nova. updating the instance securty group will not affect any exsitng ports when you want to add or remvoe security groups form a port in horizont you do not do that via the instace secutity group you do it via the port edit dialog in the port detail view under the network https:///dashboard/project/networks/ports//detail i just did that now on a train cloud we have internally and was able to add and remove a security group on a port. > > I just run server list --all to demonstrate I was indeed using a member > user and not a admin since an admin would have seen VM's from all projects. > > I agree with you in principle. It should be exactly the same whether it > comes from openstackclient or from Horizon. In fact, I was 98% positive I > would be able to demonstrate the wrong user was being used in this case. > But unfortunately, my efforts to reproduce it demonstrated that the two are > indeed handled differently. what page in horizon are you editing it form if i try and add/remove the secirty group via the interfaces tabe at https:///dashboard/project/instances// it also work for me inlcuding removing all secuity groups and i am not an admin on this cloud. specificly this is the redhat internal shared cloud i was testing on. > > I believe anyone should be able to reproduce it using the steps I outlined > on the LP. > > Brendan Shephard > > Senior Software Engineer > > Red Hat APAC > > 193 N Quay > > Brisbane City QLD 4000 > @RedHat ? ?Red Hat > ? Red Hat > > > > > > On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney wrote: > > > On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote: > > > Hey Albert, > > > > > > The policy is the default Neutron policy in OpenStack Train. These can > > indeed be changed and customised, but my assumption is that you haven?t > > created any custom policies. Horizon uses the default for each service > > unless it?s been overwritten. > > policy is defiend server side not client side so it applie equially to all > > users of the api > > so the behavior will be the same for horizon or the cli > > if you ever find a delta because horizon say used a differnt token to make > > the request that is a securty vulnerablity in horizon and should be > > reported privatly to the horizon core team :) > > > > > > > > If I create a non-admin user and try to change security groups I also > > get the same error: > > > 2022-09-14 22:01:33,370 64 INFO > > openstack_dashboard.dashboards.project.networks.ports.workflows Failed to > > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and > > rule:update_port:binding:vnic_type) and > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > > And I can reproduce your same scenario ff I try via the CLI using these > > steps: > > > 1. Add entry for new user to clouds.yaml file: > > >? ?bne-home-test: > > >? ? ?auth: > > >? ? ? ?auth_url: https://openstack.bne-home.net:13000 > > >? ? ? ?password: "test" > > >? ? ? ?project_domain_name: Default > > >? ? ? ?project_name: bne-home > > >? ? ? ?user_domain_name: Default > > >? ? ? ?username: test > > >? ? ?cacert: ~/.certs/overcloud-cacert.pem > > >? ? ?identity_api_version: '3' > > >? ? ?region_name: regionOne > > >? ? ?volume_api_version: ?3' > > > > > > 2. export OS_CLOUD=bne-home-test > > > > > > 3. Try to remove security group from port: > > > ? openstack server show test-lb-net -c security_groups -c addresses -f > > yaml > > > addresses: > > >? ?lb-mgmt-net: > > >? ?- 172.24.0.90 > > >? ?vlan4-infra: > > >? ?- 172.20.13.175 > > > security_groups: > > > - name: management-bne > > the security group listed in nova is the default security group that will > > be used by all port create by nova. > > it only applie to ports created by nova and not ones that are passed in > > using the uuid of a precreate port. > > > > you shoudl in general not mix managing security groups via nova and > > neutron. > > horizon shoudl prefer to manage security groups only via neutron if it can. > > > > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips > > -c port_security_enabled -c security_group_ids -f yaml > > > fixed_ips: > > > - ip_address: 172.20.13.175 > > >? ?subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > port_security_enabled: true > > > security_group_ids: > > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f > > > > > > ? openstack port unset --security-group > > a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips > > -c port_security_enabled -c security_group_ids -f yaml > > > fixed_ips: > > > - ip_address: 172.20.13.175 > > >? ?subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > port_security_enabled: true > > > security_group_ids: [] > > > > > > > > > Verify that I?m definitely not a admin user: > > > ? openstack server list --all > > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be > > performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8) > > > > > > > > > I don?t think this user should be allowed to do that via the CLI either. > > So that could be a bug there. The request in the Neutron server.log when I > > do it via the CLI: > > > > > > > > user can add or remove security groups without being and admin including > > removing all securtiy groups thats intended behavior and should not require > > admin. > > > > are you implying that horizon is doing "openstack server list --all" --all > > is short for --all-tenants. > > outside of the admin tab in horizon horizon would never pass the equivlent > > of --all to the nova api. > > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None > > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > 192.168.1.17,172.16.2.85 "PUT > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 > > len: 1102 time: 0.4449480 > > > > > > VS Horizon: > > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None > > req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > 172.20.10.25,172.16.2.85 "PUT > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 > > len: 386 time: 0.2209103 > > > > > > I have raised a upstream bug for this since I can still reproduce it on > > the latest version of OpenStack: > > > https://bugs.launchpad.net/neutron/+bug/1989627? > > > Bug #1989627 ?Policy enforcement variance between openstackcli a...? : > > Bugs : neutron > > > bugs.launchpad.net > > policy is enfoced on the nova/neutron api it cant behave differntly for > > horizon unless horizon is useing the wrong token. > > i.e. not he users token. > > > > > > > > > Brendan Shephard > > > Senior Software Engineer > > > Brisbane, Australia > > > > > > > > > > > > > On 15 Sep 2022, at 2:25 am, Albert Braden wrote: > > > > > > > > Hi Brendan, thanks for offering to help! I'll contact you privately > > with info about some languishing cases. > > > > > > > > Here's the policy line: > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > rule:admin_or_network_owner" > > > > > > > > Does this policy only affect Horizon? I'm using the same non-admin > > user for both CLI and Horizon, on a project where that user is a member. > > The network was created by the admin user. > > > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard < > > bshephar at redhat.com> wrote: > > > > > > > > > > > > Hi Albert, > > > > > > > > While I may not be the best person to address your Horizon concern. I > > can probably help you with your Red Hat support concerns. If you had any > > issues you wanted addressed, or feedback you wanted to provide. Feel free > > to give me a yell. > > > > > > > > Looking at your Horizon issue though. It seems the default policy file > > is what prevents you from updating that port. We can see the default policy > > like this for example: > > > > > > > > [root at controller-2 ~]# podman exec -it neutron_api > > oslopolicy-policy-generator --namespace neutron | grep > > "update_port:port_security_enabled" > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > rule:admin_or_network_owner" > > > > > > > > When you execute the command via the CLI, which user are you using? > > Are you just sourcing the overcloudrc file, or using export > > OS_CLOUD=overcloud. If that?s the case then you would be using the admin > > user on the CLI, but probably a different user when logging into Horizon. > > > > > > > > I too would suggest opening a support case. It sounds like you have > > previously had a negative experience with that. If you want to open a new > > one and share the case number with me, I can follow up on that for you. As > > someone who personally knows a lot of the RHOSP Technical Support team from > > around the world. I?m confident we can right whatever wrong may have > > occurred there. > > > > > > > > Let me know if I can help in any way. > > > > > > > > Regards, > > > > > > > > Brendan Shephard > > > > Senior Software Engineer > > > > Brisbane, Australia > > > > > > > > > > > > > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden wrote: > > > > > > > > > > On CLI I can type "openstack port set --no-security-group " to > > remove all security groups. In Horizon, the equivalent operation would be > > using the - button to remove all groups and then clicking "Update." Using > > the + button would be the equivalent of typing "openstack port set > > --security-group ". There doesn't seem to be a way to remove a > > single security group via CLI; I think the only way would be to set > > --no-security-group and then add back the desired groups. > > > > > > > > > > I can successfully add security groups to a port via CLI, or I can > > remove all security groups. If I go into Horizon and try these operations > > then I get the error when I click "Update." So it appears that security > > groups can be added and removed, with port security set, via CLI. We only > > see the failure when we try to do it via Horizon. > > > > > > > > > > Regarding RHOSP support; I assume that you are joking, or maybe > > haven't experienced the support that they offer. > > > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont < > > laurentfdumont at gmail.com> wrote: > > > > > > > > > > > > > > > If you are running RHOSP, you might have a support contract with Red > > Hat? > > > > > > > > > > Are you trying to remove all the security groups from a port that > > has port_security enabled? > > > > > > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden > > wrote: > > > > > Unfortunately we are running RHOSP in which Train is the latest and > > greatest. This is what we see in horizon.log: > > > > > > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid > > 139683266553600] [remote 10.232.233.11:57498 ] > > Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: > > ((rule:update_port and rule:update_port:binding:vnic_type) and > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < > > pierre at stackhpc.com > wrote: > > > > > > > > > > > > > > > Hello, > > > > > > > > > > This is more likely to be a Horizon bug than an issue with Kolla > > itself, since Kolla doesn't change much from the default configuration. > > > > > > > > > > You should check Horizon logs in /var/log/kolla/horizon to find the > > error. I would also encourage you to upgrade to a more recent release, > > since Train has been marked as End of Life in Kolla recently. > > > > > > > > > > Cheers, > > > > > Pierre Riteau (priteau) > > > > > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden > > wrote: > > > > > We're running kolla train and we're seeing an apparent bug when we > > try to add or remove security groups on a port. We see error "Failed to > > update port ". It works fine in CLI; we only see this in Horizon. Is > > this a known bug, or are we doing something wrong? > > > > > > > > > > > > > > > Hey Albert, > > > > > > The policy is the default Neutron policy in OpenStack Train. These can > > indeed be changed and customised, but my assumption is that you haven?t > > created any custom policies. Horizon uses the default for each service > > unless it?s been overwritten. > > > > > > If I create a non-admin user and try to change security groups I also > > get the same error: > > > 2022-09-14 22:01:33,370 64 INFO > > openstack_dashboard.dashboards.project.networks.ports.workflows Failed to > > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and > > rule:update_port:binding:vnic_type) and > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > > And I can reproduce your same scenario ff I try via the CLI using these > > steps: > > > 1. Add entry for new user to clouds.yaml file: > > >? ?bne-home-test: > > >? ? ?auth: > > >? ? ? ?auth_url: https://openstack.bne-home.net:13000 > > >? ? ? ?password: "test" > > >? ? ? ?project_domain_name: Default > > >? ? ? ?project_name: bne-home > > >? ? ? ?user_domain_name: Default > > >? ? ? ?username: test > > >? ? ?cacert: ~/.certs/overcloud-cacert.pem > > >? ? ?identity_api_version: '3' > > >? ? ?region_name: regionOne > > >? ? ?volume_api_version: ?3' > > > > > > 2. export OS_CLOUD=bne-home-test > > > > > > 3. Try to remove security group from port: > > > ? openstack server show test-lb-net -c security_groups -c addresses -f > > yaml > > > addresses: > > >? ?lb-mgmt-net: > > >? ?- 172.24.0.90 > > >? ?vlan4-infra: > > >? ?- 172.20.13.175 > > > security_groups: > > > - name: management-bne > > > > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips > > -c port_security_enabled -c security_group_ids -f yaml > > > fixed_ips: > > > - ip_address: 172.20.13.175 > > >? ?subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > port_security_enabled: true > > > security_group_ids: > > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f > > > > > > ? openstack port unset --security-group > > a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips > > -c port_security_enabled -c security_group_ids -f yaml > > > fixed_ips: > > > - ip_address: 172.20.13.175 > > >? ?subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 > > > port_security_enabled: true > > > security_group_ids: [] > > > > > > > > > Verify that I?m definitely not a admin user: > > > ? openstack server list --all > > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be > > performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8) > > > > > > > > > I don?t think this user should be allowed to do that via the CLI either. > > So that could be a bug there. The request in the Neutron server.log when I > > do it via the CLI: > > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None > > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > 192.168.1.17,172.16.2.85 "PUT > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 > >? len: 1102 time: 0.4449480 > > > > > > VS Horizon: > > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None > > req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] > > 172.20.10.25,172.16.2.85 "PUT > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 > >? len: 386 time: 0.2209103 > > > > > > I have raised a upstream bug for this since I can still reproduce it on > > the latest version of OpenStack: > > > launchpad-og-image.pngBug #1989627 ?Policy enforcement variance between > > openstackcli a...? : Bugs : neutron > > > bugs.launchpad.net > > > > > > > > > > > > Brendan Shephard > > > Senior Software Engineer > > > Brisbane, Australia > > > > > > > > > > > > > On 15 Sep 2022, at 2:25 am, Albert Braden wrote: > > > > > > > >? Hi Brendan, thanks for offering to help! I'll contact you privately > > with info about some languishing cases. > > > > > > > > Here's the policy line: > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > rule:admin_or_network_owner" > > > > > > > > Does this policy only affect Horizon? I'm using the same non-admin > > user for both CLI and Horizon, on a project where that user is a member. > > The network was created by the admin user. > > > >? On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard < > > bshephar at redhat.com> wrote: > > > > > > > > > > > > Hi Albert, > > > > > > > > While I may not be the best person to address your Horizon concern. I > > can probably help you with your Red Hat support concerns. If you had any > > issues you wanted addressed, or feedback you wanted to provide. Feel free > > to give me a yell. > > > > > > > > Looking at your Horizon issue though. It seems the default policy file > > is what prevents you from updating that port. We can see the default policy > > like this for example: > > > > > > > > [root at controller-2 ~]# podman exec -it neutron_api > > oslopolicy-policy-generator --namespace neutron | grep > > "update_port:port_security_enabled" > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or > > rule:admin_or_network_owner" > > > > > > > > When you execute the command via the CLI, which user are you using? > > Are you just sourcing the overcloudrc file, or using export > > OS_CLOUD=overcloud. If that?s the case then you would be using the admin > > user on the CLI, but probably a different user when logging into Horizon. > > > > > > > > I too would suggest opening a support case. It sounds like you have > > previously had a negative experience with that. If you want to open a new > > one and share the case number with me, I can follow up on that for you. As > > someone who personally knows a lot of the RHOSP Technical Support team from > > around the world. I?m confident we can right whatever wrong may have > > occurred there. > > > > > > > > Let me know if I can help in any way. > > > > > > > > Regards, > > > > > > > > Brendan Shephard > > > > Senior Software Engineer > > > > Brisbane, Australia > > > > > > > > > > > > > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden wrote: > > > > > > > > > >? On CLI I can type "openstack port set --no-security-group " to > > remove all security groups. In Horizon, the equivalent operation would be > > using the - button to remove all groups and then clicking "Update." Using > > the + button would be the equivalent of typing "openstack port set > > --security-group ". There doesn't seem to be a way to remove a > > single security group via CLI; I think the only way would be to set > > --no-security-group and then add back the desired groups. > > > > > > > > > > I can successfully add security groups to a port via CLI, or I can > > remove all security groups. If I go into Horizon and try these operations > > then I get the error when I click "Update." So it appears that security > > groups can be added and removed, with port security set, via CLI. We only > > see the failure when we try to do it via Horizon. > > > > > > > > > > Regarding RHOSP support; I assume that you are joking, or maybe > > haven't experienced the support that they offer. > > > > >? On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont < > > laurentfdumont at gmail.com> wrote: > > > > > > > > > > > > > > > If you are running RHOSP, you might have a support contract with Red > > Hat? > > > > > > > > > > Are you trying to remove all the security groups from a port that > > has port_security enabled? > > > > > > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden > > wrote: > > > > > >? Unfortunately we are running RHOSP in which Train is the latest > > and greatest. This is what we see in horizon.log: > > > > > > > > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid > > 139683266553600] [remote 10.232.233.11:57498] Failed to update port > > 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and > > rule:update_port:binding:vnic_type) and > > rule:update_port:port_security_enabled) is disallowed by policy > > > > > >? On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < > > pierre at stackhpc.com> wrote: > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > This is more likely to be a Horizon bug than an issue with Kolla > > itself, since Kolla doesn't change much from the default configuration. > > > > > > > > > > > > You should check Horizon logs in /var/log/kolla/horizon to find > > the error. I would also encourage you to upgrade to a more recent release, > > since Train has been marked as End of Life in Kolla recently. > > > > > > > > > > > > Cheers, > > > > > > Pierre Riteau (priteau) > > > > > > > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden > > wrote: > > > > > > > We're running kolla train and we're seeing an apparent bug when > > we try to add or remove security groups on a port. We see error "Failed to > > update port ". It works fine in CLI; we only see this in Horizon. Is > > this a known bug, or are we doing something wrong? > > > > > > > > > > > > > > > > > > -- Radomir Dopieralski -------------- next part -------------- An HTML attachment was scrubbed... URL: From jungleboyj at gmail.com Thu Sep 15 15:33:28 2022 From: jungleboyj at gmail.com (Jay Bryant) Date: Thu, 15 Sep 2022 10:33:28 -0500 Subject: [all][elections][ptl][tc] Reminder to opt-in to CIVS polling In-Reply-To: <446ecabb-803a-a4fc-7efe-45cabd1d1c02@gmail.com> References: <446ecabb-803a-a4fc-7efe-45cabd1d1c02@gmail.com> Message-ID: All, One more reminder that you will need to OPT-IN to be able to vote in the current TC and Ironic PTL election.? We are seeing that many people have not yet opted in. Please see the information on how to opt-in below. Once you opt-in you will immediately be able to vote in the election if you are eligible. Thank you! Jay (jungleboyj) -------- Forwarded Message -------- Subject: [all][elections][ptl][tc] Reminder to opt-in to CIVS polling Date: Mon, 12 Sep 2022 07:54:27 -0500 From: Jay Bryant Reply-To: jsbryant at electronicjungle.net To: openstack-discuss at lists.openstack.org All, Apologies for the additional e-mail in your in-box, but wanted to make sure that everyone saw the reminder to opt-in to voting with CIVS. ACTION IS REQUIRED to receive the voting ballot from CIVS: you must opt-in to receiving email communications from CIVS. More information and the form to do so can be found at https://civs1.civs.us/cgi-bin/opt_in.pl Polling will start TODAY and this operation needs to be completed before then. Happy Voting! - Jay Bryant (jungleboyj) -------------- next part -------------- An HTML attachment was scrubbed... URL: From elod.illes at est.tech Thu Sep 15 15:41:32 2022 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Thu, 15 Sep 2022 17:41:32 +0200 Subject: [requirements][adjutant][magnum][sahara][venus][relmgmt] Requirements Freeze Exception requests Message-ID: <81d5d393-00fe-2c59-da74-12b004a826e8@est.tech> Hi, I would like to ask for a Requirements Freeze Exception for the following deliverables (as their former releases were done from broken gates, thus needed some extra fix): python-adjutantclient?? 0.11.0 [1] python-magnumclient????? 4.0.0 [2] python-saharaclient????? 4.0.2 [3] python-venusclient?????? 1.0.1 [4] [1] https://review.opendev.org/c/openstack/releases/+/857736 [2] https://review.opendev.org/c/openstack/releases/+/856853 [3] https://review.opendev.org/c/openstack/releases/+/856858 [4] https://review.opendev.org/c/openstack/releases/+/856381 El?d irc: elodilles From amoralej at redhat.com Thu Sep 15 16:51:39 2022 From: amoralej at redhat.com (Alfredo Moralejo Alonso) Date: Thu, 15 Sep 2022 18:51:39 +0200 Subject: [all][ptl][release] Zed release critical issue with oslo.db 12.1.0 In-Reply-To: References: <44a24b6e-ffb9-b174-4f72-cebd4fd28d0b@est.tech> Message-ID: On Thu, Sep 15, 2022 at 3:55 PM Alfredo Moralejo Alonso wrote: > > > On Fri, Sep 9, 2022 at 4:27 PM Pierre Riteau wrote: > >> On Tue, 6 Sept 2022 at 12:40, Stephen Finucane >> wrote: >> >>> I did those yesterday. >>> >>> Aodh: https://review.opendev.org/c/openstack/aodh/+/855962 >>> Designate: https://review.opendev.org/c/openstack/designate/+/855965 >>> Manila: https://review.opendev.org/c/openstack/manila/+/855967 >>> Ironic: https://review.opendev.org/c/openstack/ironic/+/855969 >>> Heat: https://review.opendev.org/c/openstack/heat/+/855970 >>> Barbican: https://review.opendev.org/c/openstack/barbican/+/855972 >>> >>> The barbican one isn't correct and I need to respin it. The rest are >>> working as >>> expected though, as proven at [1]. >>> >>> Stephen >>> >>> [1] https://review.opendev.org/c/openstack/requirements/+/855973/ >> >> >> Hi, >> >> Rados?aw Piliszek (yoctozepto) and I have discovered that Blazar is also >> broken by the release of oslo.db 12.1.0: CI jobs are failing CI jobs in [1]. >> I will try to fix it like Stephen did for other projects, but I would >> like to flag that it is possible other projects are impacted: in particular >> we should check any smaller project that doesn't run CI jobs regularly. >> > > According to some functional jobs run in RDO, watcher and ec2-api projects > are also affected. > > I've sent https://review.opendev.org/c/openstack/ec2-api/+/857880 but the > gate seems blocked by some other issue. > > Also for watcher https://review.opendev.org/c/openstack/watcher/+/857887 > Regards, > > Alfredo > > > >> >> This reminds me of the breakage we had at the end of the last cycle with >> oslo.context 4.0.0 [2]. >> >> Cheers, >> Pierre Riteau (priteau) >> >> [1] https://review.opendev.org/c/openstack/blazar/+/856527 >> [2] >> https://lists.openstack.org/pipermail/openstack-discuss/2022-March/027864.html >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From katonalala at gmail.com Thu Sep 15 17:04:33 2022 From: katonalala at gmail.com (Lajos Katona) Date: Thu, 15 Sep 2022 19:04:33 +0200 Subject: [neutron] Drivers meeting - Friday 15.09.2022 - cancelled Message-ID: 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mthode at mthode.org Thu Sep 15 19:25:08 2022 From: mthode at mthode.org (Matthew Thode) Date: Thu, 15 Sep 2022 14:25:08 -0500 Subject: [requirements][adjutant][magnum][sahara][venus][relmgmt] Requirements Freeze Exception requests In-Reply-To: <81d5d393-00fe-2c59-da74-12b004a826e8@est.tech> References: <81d5d393-00fe-2c59-da74-12b004a826e8@est.tech> Message-ID: <20220915192508.7doo3k3o55htlbw5@mthode.org> On 22-09-15 17:41:32, El?d Ill?s wrote: > Hi, > > I would like to ask for a Requirements Freeze Exception for the following > deliverables (as their former releases were done from broken gates, thus > needed some extra fix): > > python-adjutantclient?? 0.11.0 [1] > python-magnumclient????? 4.0.0 [2] > python-saharaclient????? 4.0.2 [3] > python-venusclient?????? 1.0.1 [4] > > [1] https://review.opendev.org/c/openstack/releases/+/857736 > [2] https://review.opendev.org/c/openstack/releases/+/856853 > [3] https://review.opendev.org/c/openstack/releases/+/856858 > [4] https://review.opendev.org/c/openstack/releases/+/856381 > > El?d > irc: elodilles seems ok to me -- Matthew Thode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From bshephar at redhat.com Fri Sep 16 00:56:48 2022 From: bshephar at redhat.com (Brendan Shephard) Date: Fri, 16 Sep 2022 10:56:48 +1000 Subject: [Neutron] [train] Horizon port security group management fails In-Reply-To: References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> <1541763085.3101109.1663083479831@mail.yahoo.com> <84891126.3588046.1663158984067@mail.yahoo.com> <92876DF2-AAF8-44AF-BFCE-725E2A3AB393@redhat.com> <1338352317.3690165.1663172723209@mail.yahoo.com> <2EA66220-F3CE-4D0A-B8B3-9D67AA5E1AE9@redhat.com> <810befc2c803621d92df50b2f789aa2ff1cbc734.camel@redhat.com> <234984793.4131684.1663245983327@mail.yahoo.com> Message-ID: <586CF61A-1D87-465F-ACD8-CA2F0EF4EEF1@redhat.com> Hey Radomir My replies keep getting blocked because they?re too big. I?ll summarise and then you will all get spammed if someone decides to approve my other replies. In our case, I had already tried that patch and it doesn?t resolve this particular issue. The problem I see is that we need to compare the fields in our params with what already exists on the port. Then not send fields that are unchanged. This diff resolved the issue we?re discussing here: ? diff horizon/openstack_dashboard/dashboards/project/networks/ports/workflows.py workflows.py 411c411 < params = self._construct_parameters(data) --- > params = self._construct_parameters(request, data) 420c420 < def _construct_parameters(self, data): --- > def _construct_parameters(self, request, data): 424a425,426 > LOG.info("bshephar - Data variable = %s", data) > initial = api.neutron.port_get(request, self.context['port_id']) 431c433,434 < if data['port_security_enabled'] is not None: --- > if (data['port_security_enabled'] is not None and data['port_security_enabled'] > != initial['port_security_enabled']): This probably isn?t a solution you guys would want to merge. But it demonstrates a working solution to the problem that we?re discussing. Brendan Shephard Senior Software Engineer Brisbane, Australia -------------- next part -------------- An HTML attachment was scrubbed... URL: From bshephar at redhat.com Fri Sep 16 00:27:33 2022 From: bshephar at redhat.com (Brendan Shephard) Date: Fri, 16 Sep 2022 10:27:33 +1000 Subject: [Neutron] [train] Horizon port security group management fails In-Reply-To: References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> <1541763085.3101109.1663083479831@mail.yahoo.com> <84891126.3588046.1663158984067@mail.yahoo.com> <92876DF2-AAF8-44AF-BFCE-725E2A3AB393@redhat.com> <1338352317.3690165.1663172723209@mail.yahoo.com> <2EA66220-F3CE-4D0A-B8B3-9D67AA5E1AE9@redhat.com> <810befc2c803621d92df50b2f789aa2ff1cbc734.camel@redhat.com> <234984793.4131684.1663245983327@mail.yahoo.com> Message-ID: Hey Radomir, Thanks for your input. I did indeed find that patch and used it to patch my env. In this case though, it didn?t seem to change the API request sent to Neutron. It seems the issue comes from here: https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/networks/ports/workflows.py#L431? horizon/workflows.py at master ? openstack/horizon github.com If I log the data variable at that point after applying the patch. It contains all of the fields: 2022-09-16 00:01:55,046 35 INFO openstack_dashboard.dashboards.project.networks.ports.workflows bshephar - Data variable = {'port_id': '4df563ce-5464-4f7d-8aaf-c5496cdaefda', 'network_id': 'acefae53-b4d5-422f-bcca-dc32a0785d21', 'name': '', 'admin_state': True, 'target_tenant_id': '3ff28fc7abf742a6b7a0d016771dee49', 'binding__vnic_type': 'normal', 'port_security_enabled': True, 'instance_id': 'ccb72b14-3694-40fa-9b3b-ec1a8d7ef046', 'mac_state': None, 'wanted_groups': ['a3ae6e20-67df-4a72-9d5b-cc21ad87464f']} So checking if data['port_security_enabled'] is not None: params['port_security_enabled'] = data['port_security_enabled'] This is still True, so we?re setting the param to the data value and using that in our API call to Neutron. I?m really not familiar at all with the Horizon code base. So let me know if I?m misunderstanding the intention of the patch you referenced. But I think the idea would be to check our `params` against the actual value returned from neutron.port_get() and only have fields that are changed in our params. So when we call the port_update() here: https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/networks/ports/workflows.py#L413? horizon/workflows.py at master ? openstack/horizon github.com It would only be the called with params that are different from the current state. At least in the case we?re discussing here, that resolves the issue. So this is just rudimentary hackery to see what works, but this fixes the issue for me (Ignore the LOG line obviously): ? diff horizon/openstack_dashboard/dashboards/project/networks/ports/workflows.py workflows.py 411c411 < params = self._construct_parameters(data) --- > params = self._construct_parameters(request, data) 420c420 < def _construct_parameters(self, data): --- > def _construct_parameters(self, request, data): 424a425,426 > LOG.info("bshephar - Data variable = %s", data) > initial = api.neutron.port_get(request, self.context['port_id']) 431c433,434 < if data['port_security_enabled'] is not None: --- > if (data['port_security_enabled'] is not None and data['port_security_enabled'] > != initial['port_security_enabled']): The API call after this change looks like this: 2022-09-16 00:17:49,147 31 DEBUG neutronclient.client REQ: b'curl -i https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda -X PUT -H "X-Auth-Token: {SHA256}65efff6982c871ae21a157ab46e4e2bebf69fc8619e8a1512d7ce0dd96b94369" -H "User-Agent: python-neutronclient" -d \'{"port": {"name": "", "admin_state_up": true, "security_groups": ["a3ae6e20-67df-4a72-9d5b-cc21ad87464f"], "binding:vnic_type": "normal"}}\'' And subsequently is accepted by Neutron. So I?m not too sure about the approach within your existing framework. But I mean, I?m happy to propose exactly that as a solution and we can debate it further if you like Radomir? Thanks again, Brendan Shephard Senior Software Engineer Brisbane, Australia > On 15 Sep 2022, at 11:56 pm, Radomir Dopieralski wrote: > > It's a known problem and there is a patch for it in review for quite some time: https://review.opendev.org/c/openstack/horizon/+/810224 > > On Thu, Sep 15, 2022 at 3:36 PM Brendan Shephard > wrote: >> Hey all, >> >> I think we might be onto something here. With the help of @Sean Mooney ++ and @Takashi Kajinami ++. It appears the API request when sent from Horizon contains additional fields that don't require update. But when the request comes from openstackcli, it is just updating the security group field only. >> >> openstackcli: >> REQ: curl -g -i --cacert "/Users/shep/.certs/overcloud-cacert.pem" -X PUT https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda -H "Content-Type: application/json" -H "User-Agent: openstacksdk/0.100.0 keystoneauth1/5.0.0 python-requests/2.28.1 CPython/3.10.6" -H "X-Auth-Token: {SHA256}3ec8b1d0b17434ec67c2960486ec19f17dfb2884fb47c5b54e1cec2beceb1a87" -d '{"port": {"security_groups": ["a3ae6e20-67df-4a72-9d5b-cc21ad87464f", "a31b9954-b7e6-4d4e-887c-e21a59c052ea"]}}' >> https://openstack.bne-home.net:13696 "PUT /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" 200 1002 >> >> >> Horizon API call to Neutron: >> 2022-09-15 00:02:46,820 33 DEBUG neutronclient.client REQ: b'curl -i https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda -X PUT -H "X-Auth-Token: {SHA256}52f077cf0115286c45f1e212cbec4ecdfc56ae41704c869aeb35cea41fdbfde1" -H "User-Agent: python-neutronclient" -d \'{"port": {"name": "", "admin_state_up": true, "port_security_enabled": true, "security_groups": [], "binding:vnic_type": "normal"}}\'' >> >> So when Neutron receives that request from Horizon, we get blocked because we (as members) are not permitted to update the port_security_enabled field. Even though it's already set to true in this case. >> >> Given that information, the bug is probably back on Horizon here to not include fields that don't require update. >> >> Brendan Shephard >> Senior Software Engineer >> Red Hat APAC >> 193 N Quay >> Brisbane City QLD 4000 >> @RedHat Red Hat Red Hat >> >> >> >> On Thu, Sep 15, 2022 at 10:46 PM Albert Braden > wrote: >>> If I add/remove security groups from an instance in Horizon, it works. It's when I add/remove security groups from a port that the error occurs. One way to reproduce is to click on the instance and then go to the "Interfaces" tab, and click "Update Security Groups" on the right. >>> On Thursday, September 15, 2022, 08:21:17 AM EDT, Brendan Shephard > wrote: >>> >>> >>> Hey, >>> >>> I'm doing it from the instances one: >>> https://openstack.bne-home.net/dashboard/project/instances/ccb72b14-3694-40fa-9b3b-ec1a8d7ef046/ >>> >>> But for what it's worth. I get the same error if I do it from: >>> https://openstack.bne-home.net/dashboard/project/networks/acefae53-b4d5-422f-bcca-dc32a0785d21/detail >>> >>> Interesting that it worked for you there. Be good to confirm with @ozzzo at yahoo.com as well as to exactly where in Horizon he is trying to modify the security groups. Just so we're all trying to do the exact same thing. >>> >>> My environment is also deployed from the latest tripleo packages, so I'll also test on that internal lab you referenced Sean. That would be more representative of Alberts issue since he is using RHOSP. >>> >>> Brendan Shephard >>> Senior Software Engineer >>> Red Hat APAC >>> 193 N Quay >>> Brisbane City QLD 4000 >>> @RedHat Red Hat Red Hat >>> >>> >>> >>> On Thu, Sep 15, 2022 at 10:12 PM Sean Mooney > wrote: >>> On Thu, 2022-09-15 at 21:33 +1000, Brendan Shephard wrote: >>> > Hey Sean, >>> > >>> > Thanks for the reply. >>> > >>> > For reference, I have all the steps to reproduce along with the relevant >>> > debug logs attached to this LP: >>> > https://bugs.launchpad.net/neutron/+bug/1989627 >>> > >>> > But, to summarize. If I go to any random instance in Horizon as a member >>> > user - not a admin. Then try to remove any Security Group at all from any >>> > of the ports it fails with the policy violation (I attached a screenshot of >>> > where I'm making that change in Horizon). But doing it with the same user >>> > from the cli works fine. Since I'm editing individual interfaces there, >>> > rather than the instance itself. I assumed these would all be API calls to >>> > Neutron from Horizon rather than from Horizon to Nova. >>> updating the instance securty group will not affect any exsitng ports >>> when you want to add or remvoe security groups form a port in horizont >>> you do not do that via the instace secutity group you do it via the port edit dialog >>> in the port detail view under the network >>> >>> https:///dashboard/project/networks/ports//detail >>> >>> i just did that now on a train cloud we have internally and was able to add and remove a security group on a port. >>> >>> > >>> > I just run server list --all to demonstrate I was indeed using a member >>> > user and not a admin since an admin would have seen VM's from all projects. >>> > >>> > I agree with you in principle. It should be exactly the same whether it >>> > comes from openstackclient or from Horizon. In fact, I was 98% positive I >>> > would be able to demonstrate the wrong user was being used in this case. >>> > But unfortunately, my efforts to reproduce it demonstrated that the two are >>> > indeed handled differently. >>> >>> what page in horizon are you editing it form if i try and add/remove the secirty group via the interfaces tabe at >>> https:///dashboard/project/instances// >>> it also work for me inlcuding removing all secuity groups and i am not an admin on this cloud. >>> >>> specificly this is the redhat internal shared cloud i was testing on. >>> >>> > >>> > I believe anyone should be able to reproduce it using the steps I outlined >>> > on the LP. >>> > >>> > Brendan Shephard >>> > >>> > Senior Software Engineer >>> > >>> > Red Hat APAC > >>> > >>> > 193 N Quay >>> > >>> > Brisbane City QLD 4000 >>> > @RedHat Red Hat >>> > Red Hat >>> > >>> > >>> > >>> > >>> > >>> > On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney > wrote: >>> > >>> > > On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote: >>> > > > Hey Albert, >>> > > > >>> > > > The policy is the default Neutron policy in OpenStack Train. These can >>> > > indeed be changed and customised, but my assumption is that you haven?t >>> > > created any custom policies. Horizon uses the default for each service >>> > > unless it?s been overwritten. >>> > > policy is defiend server side not client side so it applie equially to all >>> > > users of the api >>> > > so the behavior will be the same for horizon or the cli >>> > > if you ever find a delta because horizon say used a differnt token to make >>> > > the request that is a securty vulnerablity in horizon and should be >>> > > reported privatly to the horizon core team :) >>> > > >>> > > > >>> > > > If I create a non-admin user and try to change security groups I also >>> > > get the same error: >>> > > > 2022-09-14 22:01:33,370 64 INFO >>> > > openstack_dashboard.dashboards.project.networks.ports.workflows Failed to >>> > > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and >>> > > rule:update_port:binding:vnic_type) and >>> > > rule:update_port:port_security_enabled) is disallowed by policy >>> > > > >>> > > > And I can reproduce your same scenario ff I try via the CLI using these >>> > > steps: >>> > > > 1. Add entry for new user to clouds.yaml file: >>> > > > bne-home-test: >>> > > > auth: >>> > > > auth_url: https://openstack.bne-home.net:13000 >>> > > > password: "test" >>> > > > project_domain_name: Default >>> > > > project_name: bne-home >>> > > > user_domain_name: Default >>> > > > username: test >>> > > > cacert: ~/.certs/overcloud-cacert.pem >>> > > > identity_api_version: '3' >>> > > > region_name: regionOne >>> > > > volume_api_version: ?3' >>> > > > >>> > > > 2. export OS_CLOUD=bne-home-test >>> > > > >>> > > > 3. Try to remove security group from port: >>> > > > ? openstack server show test-lb-net -c security_groups -c addresses -f >>> > > yaml >>> > > > addresses: >>> > > > lb-mgmt-net: >>> > > > - 172.24.0.90 >>> > > > vlan4-infra: >>> > > > - 172.20.13.175 >>> > > > security_groups: >>> > > > - name: management-bne >>> > > the security group listed in nova is the default security group that will >>> > > be used by all port create by nova. >>> > > it only applie to ports created by nova and not ones that are passed in >>> > > using the uuid of a precreate port. >>> > > >>> > > you shoudl in general not mix managing security groups via nova and >>> > > neutron. >>> > > horizon shoudl prefer to manage security groups only via neutron if it can. >>> > > > >>> > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips >>> > > -c port_security_enabled -c security_group_ids -f yaml >>> > > > fixed_ips: >>> > > > - ip_address: 172.20.13.175 >>> > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 >>> > > > port_security_enabled: true >>> > > > security_group_ids: >>> > > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f >>> > > > >>> > > > ? openstack port unset --security-group >>> > > a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda >>> > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips >>> > > -c port_security_enabled -c security_group_ids -f yaml >>> > > > fixed_ips: >>> > > > - ip_address: 172.20.13.175 >>> > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 >>> > > > port_security_enabled: true >>> > > > security_group_ids: [] >>> > > > >>> > > > >>> > > > Verify that I?m definitely not a admin user: >>> > > > ? openstack server list --all >>> > > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be >>> > > performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8) >>> > > > >>> > > > >>> > > > I don?t think this user should be allowed to do that via the CLI either. >>> > > So that could be a bug there. The request in the Neutron server.log when I >>> > > do it via the CLI: >>> > > > >>> > > > >>> > > user can add or remove security groups without being and admin including >>> > > removing all securtiy groups thats intended behavior and should not require >>> > > admin. >>> > > >>> > > are you implying that horizon is doing "openstack server list --all" --all >>> > > is short for --all-tenants. >>> > > outside of the admin tab in horizon horizon would never pass the equivlent >>> > > of --all to the nova api. >>> > > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None >>> > > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a >>> > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] >>> > > 192.168.1.17,172.16.2.85 "PUT >>> > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 >>> > > len: 1102 time: 0.4449480 >>> > > > >>> > > > VS Horizon: >>> > > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None >>> > > req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a >>> > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] >>> > > 172.20.10.25,172.16.2.85 "PUT >>> > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 >>> > > len: 386 time: 0.2209103 >>> > > > >>> > > > I have raised a upstream bug for this since I can still reproduce it on >>> > > the latest version of OpenStack: >>> > > > https://bugs.launchpad.net/neutron/+bug/1989627? >>> > > > Bug #1989627 ?Policy enforcement variance between openstackcli a...? : >>> > > Bugs : neutron >>> > > > bugs.launchpad.net >>> > > policy is enfoced on the nova/neutron api it cant behave differntly for >>> > > horizon unless horizon is useing the wrong token. >>> > > i.e. not he users token. >>> > > > >>> > > > >>> > > > Brendan Shephard >>> > > > Senior Software Engineer >>> > > > Brisbane, Australia >>> > > > >>> > > > >>> > > > >>> > > > > On 15 Sep 2022, at 2:25 am, Albert Braden > wrote: >>> > > > > >>> > > > > Hi Brendan, thanks for offering to help! I'll contact you privately >>> > > with info about some languishing cases. >>> > > > > >>> > > > > Here's the policy line: >>> > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or >>> > > rule:admin_or_network_owner" >>> > > > > >>> > > > > Does this policy only affect Horizon? I'm using the same non-admin >>> > > user for both CLI and Horizon, on a project where that user is a member. >>> > > The network was created by the admin user. >>> > > > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard < >>> > > bshephar at redhat.com > wrote: >>> > > > > >>> > > > > >>> > > > > Hi Albert, >>> > > > > >>> > > > > While I may not be the best person to address your Horizon concern. I >>> > > can probably help you with your Red Hat support concerns. If you had any >>> > > issues you wanted addressed, or feedback you wanted to provide. Feel free >>> > > to give me a yell. >>> > > > > >>> > > > > Looking at your Horizon issue though. It seems the default policy file >>> > > is what prevents you from updating that port. We can see the default policy >>> > > like this for example: >>> > > > > >>> > > > > [root at controller-2 ~]# podman exec -it neutron_api >>> > > oslopolicy-policy-generator --namespace neutron | grep >>> > > "update_port:port_security_enabled" >>> > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or >>> > > rule:admin_or_network_owner" >>> > > > > >>> > > > > When you execute the command via the CLI, which user are you using? >>> > > Are you just sourcing the overcloudrc file, or using export >>> > > OS_CLOUD=overcloud. If that?s the case then you would be using the admin >>> > > user on the CLI, but probably a different user when logging into Horizon. >>> > > > > >>> > > > > I too would suggest opening a support case. It sounds like you have >>> > > previously had a negative experience with that. If you want to open a new >>> > > one and share the case number with me, I can follow up on that for you. As >>> > > someone who personally knows a lot of the RHOSP Technical Support team from >>> > > around the world. I?m confident we can right whatever wrong may have >>> > > occurred there. >>> > > > > >>> > > > > Let me know if I can help in any way. >>> > > > > >>> > > > > Regards, >>> > > > > >>> > > > > Brendan Shephard >>> > > > > Senior Software Engineer >>> > > > > Brisbane, Australia >>> > > > > >>> > > > > >>> > > > > >>> > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden > wrote: >>> > > > > > >>> > > > > > On CLI I can type "openstack port set --no-security-group " to >>> > > remove all security groups. In Horizon, the equivalent operation would be >>> > > using the - button to remove all groups and then clicking "Update." Using >>> > > the + button would be the equivalent of typing "openstack port set >>> > > --security-group ". There doesn't seem to be a way to remove a >>> > > single security group via CLI; I think the only way would be to set >>> > > --no-security-group and then add back the desired groups. >>> > > > > > >>> > > > > > I can successfully add security groups to a port via CLI, or I can >>> > > remove all security groups. If I go into Horizon and try these operations >>> > > then I get the error when I click "Update." So it appears that security >>> > > groups can be added and removed, with port security set, via CLI. We only >>> > > see the failure when we try to do it via Horizon. >>> > > > > > >>> > > > > > Regarding RHOSP support; I assume that you are joking, or maybe >>> > > haven't experienced the support that they offer. >>> > > > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont < >>> > > laurentfdumont at gmail.com > wrote: >>> > > > > > >>> > > > > > >>> > > > > > If you are running RHOSP, you might have a support contract with Red >>> > > Hat? >>> > > > > > >>> > > > > > Are you trying to remove all the security groups from a port that >>> > > has port_security enabled? >>> > > > > > >>> > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden >>> > > >> wrote: >>> > > > > > Unfortunately we are running RHOSP in which Train is the latest and >>> > > greatest. This is what we see in horizon.log: >>> > > > > > >>> > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid >>> > > 139683266553600] [remote 10.232.233.11:57498 ] >>> > > Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: >>> > > ((rule:update_port and rule:update_port:binding:vnic_type) and >>> > > rule:update_port:port_security_enabled) is disallowed by policy >>> > > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < >>> > > pierre at stackhpc.com >> wrote: >>> > > > > > >>> > > > > > >>> > > > > > Hello, >>> > > > > > >>> > > > > > This is more likely to be a Horizon bug than an issue with Kolla >>> > > itself, since Kolla doesn't change much from the default configuration. >>> > > > > > >>> > > > > > You should check Horizon logs in /var/log/kolla/horizon to find the >>> > > error. I would also encourage you to upgrade to a more recent release, >>> > > since Train has been marked as End of Life in Kolla recently. >>> > > > > > >>> > > > > > Cheers, >>> > > > > > Pierre Riteau (priteau) >>> > > > > > >>> > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden >>> > > >> wrote: >>> > > > > > We're running kolla train and we're seeing an apparent bug when we >>> > > try to add or remove security groups on a port. We see error "Failed to >>> > > update port ". It works fine in CLI; we only see this in Horizon. Is >>> > > this a known bug, or are we doing something wrong? >>> > > > > > >>> > > > > >>> > > > >>> > > > Hey Albert, >>> > > > >>> > > > The policy is the default Neutron policy in OpenStack Train. These can >>> > > indeed be changed and customised, but my assumption is that you haven?t >>> > > created any custom policies. Horizon uses the default for each service >>> > > unless it?s been overwritten. >>> > > > >>> > > > If I create a non-admin user and try to change security groups I also >>> > > get the same error: >>> > > > 2022-09-14 22:01:33,370 64 INFO >>> > > openstack_dashboard.dashboards.project.networks.ports.workflows Failed to >>> > > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port and >>> > > rule:update_port:binding:vnic_type) and >>> > > rule:update_port:port_security_enabled) is disallowed by policy >>> > > > >>> > > > And I can reproduce your same scenario ff I try via the CLI using these >>> > > steps: >>> > > > 1. Add entry for new user to clouds.yaml file: >>> > > > bne-home-test: >>> > > > auth: >>> > > > auth_url: https://openstack.bne-home.net:13000 >>> > > > password: "test" >>> > > > project_domain_name: Default >>> > > > project_name: bne-home >>> > > > user_domain_name: Default >>> > > > username: test >>> > > > cacert: ~/.certs/overcloud-cacert.pem >>> > > > identity_api_version: '3' >>> > > > region_name: regionOne >>> > > > volume_api_version: ?3' >>> > > > >>> > > > 2. export OS_CLOUD=bne-home-test >>> > > > >>> > > > 3. Try to remove security group from port: >>> > > > ? openstack server show test-lb-net -c security_groups -c addresses -f >>> > > yaml >>> > > > addresses: >>> > > > lb-mgmt-net: >>> > > > - 172.24.0.90 >>> > > > vlan4-infra: >>> > > > - 172.20.13.175 >>> > > > security_groups: >>> > > > - name: management-bne >>> > > > >>> > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips >>> > > -c port_security_enabled -c security_group_ids -f yaml >>> > > > fixed_ips: >>> > > > - ip_address: 172.20.13.175 >>> > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 >>> > > > port_security_enabled: true >>> > > > security_group_ids: >>> > > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f >>> > > > >>> > > > ? openstack port unset --security-group >>> > > a3ae6e20-67df-4a72-9d5b-cc21ad87464f 4df563ce-5464-4f7d-8aaf-c5496cdaefda >>> > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c fixed_ips >>> > > -c port_security_enabled -c security_group_ids -f yaml >>> > > > fixed_ips: >>> > > > - ip_address: 172.20.13.175 >>> > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 >>> > > > port_security_enabled: true >>> > > > security_group_ids: [] >>> > > > >>> > > > >>> > > > Verify that I?m definitely not a admin user: >>> > > > ? openstack server list --all >>> > > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants to be >>> > > performed. (HTTP 403) (Request-ID: req-75c19210-ad91-471f-b500-e1f3482825f8) >>> > > > >>> > > > >>> > > > I don?t think this user should be allowed to do that via the CLI either. >>> > > So that could be a bug there. The request in the Neutron server.log when I >>> > > do it via the CLI: >>> > > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None >>> > > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 781362d053ee4708a21430d3a825795a >>> > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] >>> > > 192.168.1.17,172.16.2.85 "PUT >>> > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 200 >>> > > len: 1102 time: 0.4449480 >>> > > > >>> > > > VS Horizon: >>> > > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None >>> > > req-4c284690-eb69-43df-b205-4953a88ab87c 781362d053ee4708a21430d3a825795a >>> > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] >>> > > 172.20.10.25,172.16.2.85 "PUT >>> > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: 403 >>> > > len: 386 time: 0.2209103 >>> > > > >>> > > > I have raised a upstream bug for this since I can still reproduce it on >>> > > the latest version of OpenStack: >>> > > > launchpad-og-image.pngBug #1989627 ?Policy enforcement variance between >>> > > openstackcli a...? : Bugs : neutron >>> > > > bugs.launchpad.net >>> > > > >>> > > > >>> > > > >>> > > > Brendan Shephard >>> > > > Senior Software Engineer >>> > > > Brisbane, Australia >>> > > > >>> > > > >>> > > > >>> > > > > On 15 Sep 2022, at 2:25 am, Albert Braden > wrote: >>> > > > > >>> > > > > Hi Brendan, thanks for offering to help! I'll contact you privately >>> > > with info about some languishing cases. >>> > > > > >>> > > > > Here's the policy line: >>> > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or >>> > > rule:admin_or_network_owner" >>> > > > > >>> > > > > Does this policy only affect Horizon? I'm using the same non-admin >>> > > user for both CLI and Horizon, on a project where that user is a member. >>> > > The network was created by the admin user. >>> > > > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan Shephard < >>> > > bshephar at redhat.com > wrote: >>> > > > > >>> > > > > >>> > > > > Hi Albert, >>> > > > > >>> > > > > While I may not be the best person to address your Horizon concern. I >>> > > can probably help you with your Red Hat support concerns. If you had any >>> > > issues you wanted addressed, or feedback you wanted to provide. Feel free >>> > > to give me a yell. >>> > > > > >>> > > > > Looking at your Horizon issue though. It seems the default policy file >>> > > is what prevents you from updating that port. We can see the default policy >>> > > like this for example: >>> > > > > >>> > > > > [root at controller-2 ~]# podman exec -it neutron_api >>> > > oslopolicy-policy-generator --namespace neutron | grep >>> > > "update_port:port_security_enabled" >>> > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or >>> > > rule:admin_or_network_owner" >>> > > > > >>> > > > > When you execute the command via the CLI, which user are you using? >>> > > Are you just sourcing the overcloudrc file, or using export >>> > > OS_CLOUD=overcloud. If that?s the case then you would be using the admin >>> > > user on the CLI, but probably a different user when logging into Horizon. >>> > > > > >>> > > > > I too would suggest opening a support case. It sounds like you have >>> > > previously had a negative experience with that. If you want to open a new >>> > > one and share the case number with me, I can follow up on that for you. As >>> > > someone who personally knows a lot of the RHOSP Technical Support team from >>> > > around the world. I?m confident we can right whatever wrong may have >>> > > occurred there. >>> > > > > >>> > > > > Let me know if I can help in any way. >>> > > > > >>> > > > > Regards, >>> > > > > >>> > > > > Brendan Shephard >>> > > > > Senior Software Engineer >>> > > > > Brisbane, Australia >>> > > > > >>> > > > > >>> > > > > >>> > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden > wrote: >>> > > > > > >>> > > > > > On CLI I can type "openstack port set --no-security-group " to >>> > > remove all security groups. In Horizon, the equivalent operation would be >>> > > using the - button to remove all groups and then clicking "Update." Using >>> > > the + button would be the equivalent of typing "openstack port set >>> > > --security-group ". There doesn't seem to be a way to remove a >>> > > single security group via CLI; I think the only way would be to set >>> > > --no-security-group and then add back the desired groups. >>> > > > > > >>> > > > > > I can successfully add security groups to a port via CLI, or I can >>> > > remove all security groups. If I go into Horizon and try these operations >>> > > then I get the error when I click "Update." So it appears that security >>> > > groups can be added and removed, with port security set, via CLI. We only >>> > > see the failure when we try to do it via Horizon. >>> > > > > > >>> > > > > > Regarding RHOSP support; I assume that you are joking, or maybe >>> > > haven't experienced the support that they offer. >>> > > > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent Dumont < >>> > > laurentfdumont at gmail.com > wrote: >>> > > > > > >>> > > > > > >>> > > > > > If you are running RHOSP, you might have a support contract with Red >>> > > Hat? >>> > > > > > >>> > > > > > Are you trying to remove all the security groups from a port that >>> > > has port_security enabled? >>> > > > > > >>> > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden > >>> > > wrote: >>> > > > > > > Unfortunately we are running RHOSP in which Train is the latest >>> > > and greatest. This is what we see in horizon.log: >>> > > > > > > >>> > > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid >>> > > 139683266553600] [remote 10.232.233.11:57498 ] Failed to update port >>> > > 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and >>> > > rule:update_port:binding:vnic_type) and >>> > > rule:update_port:port_security_enabled) is disallowed by policy >>> > > > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < >>> > > pierre at stackhpc.com > wrote: >>> > > > > > > >>> > > > > > > >>> > > > > > > Hello, >>> > > > > > > >>> > > > > > > This is more likely to be a Horizon bug than an issue with Kolla >>> > > itself, since Kolla doesn't change much from the default configuration. >>> > > > > > > >>> > > > > > > You should check Horizon logs in /var/log/kolla/horizon to find >>> > > the error. I would also encourage you to upgrade to a more recent release, >>> > > since Train has been marked as End of Life in Kolla recently. >>> > > > > > > >>> > > > > > > Cheers, >>> > > > > > > Pierre Riteau (priteau) >>> > > > > > > >>> > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden > >>> > > wrote: >>> > > > > > > > We're running kolla train and we're seeing an apparent bug when >>> > > we try to add or remove security groups on a port. We see error "Failed to >>> > > update port ". It works fine in CLI; we only see this in Horizon. Is >>> > > this a known bug, or are we doing something wrong? >>> > > > > > > > >>> > > > > >>> > > > >>> > > >>> > > >>> > > > -- > Radomir Dopieralski -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: horizon.png Type: image/png Size: 81530 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: horizon.png Type: image/png Size: 81530 bytes Desc: not available URL: From bshephar at redhat.com Fri Sep 16 00:34:45 2022 From: bshephar at redhat.com (Brendan Shephard) Date: Fri, 16 Sep 2022 10:34:45 +1000 Subject: [Neutron] [train] Horizon port security group management fails In-Reply-To: References: <24994302.1451585.1662730205554.ref@mail.yahoo.com> <24994302.1451585.1662730205554@mail.yahoo.com> <1541763085.3101109.1663083479831@mail.yahoo.com> <84891126.3588046.1663158984067@mail.yahoo.com> <92876DF2-AAF8-44AF-BFCE-725E2A3AB393@redhat.com> <1338352317.3690165.1663172723209@mail.yahoo.com> <2EA66220-F3CE-4D0A-B8B3-9D67AA5E1AE9@redhat.com> <810befc2c803621d92df50b2f789aa2ff1cbc734.camel@redhat.com> <234984793.4131684.1663245983327@mail.yahoo.com> Message-ID: Hey Radomir, Thanks for your input. I did indeed find that patch and used it to patch my env. In this case though, it didn?t seem to change the API request sent to Neutron. If I log the data variable at this point after applying the patch. It contains all of the fields: 2022-09-16 00:01:55,046 35 INFO openstack_dashboard.dashboards.project.networks.ports.workflows bshephar - Data variable = {'port_id': '4df563ce-5464-4f7d-8aaf-c5496cdaefda', 'network_id': 'acefae53-b4d5-422f-bcca-dc32a0785d21', 'name': '', 'admin_state': True, 'target_tenant_id': '3ff28fc7abf742a6b7a0d016771dee49', 'binding__vnic_type': 'normal', 'port_security_enabled': True, 'instance_id': 'ccb72b14-3694-40fa-9b3b-ec1a8d7ef046', 'mac_state': None, 'wanted_groups': ['a3ae6e20-67df-4a72-9d5b-cc21ad87464f']} So checking this if data['port_security_enabled'] is not None: params['port_security_enabled'] = data['port_security_enabled'] This is still True, so we?re setting the param to the data value and using that in our API call to Neutron. I?m really not familiar at all with the Horizon code base. So let me know if I?m misunderstanding the intention of the patch you referenced. But I think the idea would be to check our `params` against the actual value returned from neutron.port_get() and only have fields that are changed in our params. So when we call the port_update() here: At least in the case we?re discussing here, that resolves the issue. This is just rudimentary hackery to see what works, but this fixes the issue for me (Ignore the LOG line obviously): ? diff horizon/openstack_dashboard/dashboards/project/networks/ports/workflows.py workflows.py 411c411 < params = self._construct_parameters(data) --- > params = self._construct_parameters(request, data) 420c420 < def _construct_parameters(self, data): --- > def _construct_parameters(self, request, data): 424a425,426 > LOG.info("bshephar - Data variable = %s", data) > initial = api.neutron.port_get(request, self.context['port_id']) 431c433,434 < if data['port_security_enabled'] is not None: --- > if (data['port_security_enabled'] is not None and data['port_security_enabled'] > != initial['port_security_enabled']): The API call after this change looks like this: 2022-09-16 00:17:49,147 31 DEBUG neutronclient.client REQ: b'curl -i https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda -X PUT -H "X-Auth-Token: {SHA256}65efff6982c871ae21a157ab46e4e2bebf69fc8619e8a1512d7ce0dd96b94369" -H "User-Agent: python-neutronclient" -d \'{"port": {"name": "", "admin_state_up": true, "security_groups": ["a3ae6e20-67df-4a72-9d5b-cc21ad87464f"], "binding:vnic_type": "normal"}}\'' And subsequently is accepted by Neutron. So I?m not too sure about the approach within your existing framework. But I mean, I?m happy to propose exactly that as a solution and we can debate it further if you like Radomir? Thanks again, Brendan Shephard Senior Software Engineer Brisbane, Australia Brendan Shephard Senior Software Engineer Red Hat APAC 193 N Quay Brisbane City QLD 4000 @RedHat Red Hat Red Hat On Thu, Sep 15, 2022 at 11:57 PM Radomir Dopieralski wrote: > It's a known problem and there is a patch for it in review for quite some > time: https://review.opendev.org/c/openstack/horizon/+/810224 > > On Thu, Sep 15, 2022 at 3:36 PM Brendan Shephard > wrote: > >> Hey all, >> >> I think we might be onto something here. With the help of @Sean Mooney >> ++ and @Takashi Kajinami ++. >> It appears the API request when sent from Horizon contains additional >> fields that don't require update. But when the request comes from >> openstackcli, it is just updating the security group field only. >> >> openstackcli: >> REQ: curl -g -i --cacert "/Users/shep/.certs/overcloud-cacert.pem" -X PUT >> https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda >> -H "Content-Type: application/json" -H "User-Agent: openstacksdk/0.100.0 >> keystoneauth1/5.0.0 python-requests/2.28.1 CPython/3.10.6" -H >> "X-Auth-Token: >> {SHA256}3ec8b1d0b17434ec67c2960486ec19f17dfb2884fb47c5b54e1cec2beceb1a87" >> -d '{"port": {"security_groups": ["a3ae6e20-67df-4a72-9d5b-cc21ad87464f", >> "a31b9954-b7e6-4d4e-887c-e21a59c052ea"]}}' >> https://openstack.bne-home.net:13696 "PUT >> /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" 200 1002 >> >> >> Horizon API call to Neutron: >> 2022-09-15 00:02:46,820 33 DEBUG neutronclient.client REQ: b'curl -i >> https://openstack.bne-home.net:13696/v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda >> -X PUT -H "X-Auth-Token: >> {SHA256}52f077cf0115286c45f1e212cbec4ecdfc56ae41704c869aeb35cea41fdbfde1" >> -H "User-Agent: python-neutronclient" -d \'{"port": {"name": "", >> "admin_state_up": true, "port_security_enabled": true, "security_groups": >> [], "binding:vnic_type": "normal"}}\'' >> >> So when Neutron receives that request from Horizon, we get blocked >> because we (as members) are not permitted to update the >> port_security_enabled field. Even though it's already set to true in this >> case. >> >> Given that information, the bug is probably back on Horizon here to not >> include fields that don't require update. >> >> Brendan Shephard >> >> Senior Software Engineer >> >> Red Hat APAC >> >> 193 N Quay >> >> Brisbane City QLD 4000 >> @RedHat Red Hat >> Red Hat >> >> >> >> >> >> On Thu, Sep 15, 2022 at 10:46 PM Albert Braden wrote: >> >>> If I add/remove security groups from an instance in Horizon, it works. >>> It's when I add/remove security groups from a port that the error occurs. >>> One way to reproduce is to click on the instance and then go to the >>> "Interfaces" tab, and click "Update Security Groups" on the right. >>> On Thursday, September 15, 2022, 08:21:17 AM EDT, Brendan Shephard < >>> bshephar at redhat.com> wrote: >>> >>> >>> Hey, >>> >>> I'm doing it from the instances one: >>> >>> https://openstack.bne-home.net/dashboard/project/instances/ccb72b14-3694-40fa-9b3b-ec1a8d7ef046/ >>> >>> But for what it's worth. I get the same error if I do it from: >>> >>> https://openstack.bne-home.net/dashboard/project/networks/acefae53-b4d5-422f-bcca-dc32a0785d21/detail >>> >>> Interesting that it worked for you there. Be good to confirm with >>> @ozzzo at yahoo.com as well as to exactly where in >>> Horizon he is trying to modify the security groups. Just so we're all >>> trying to do the exact same thing. >>> >>> My environment is also deployed from the latest tripleo packages, so >>> I'll also test on that internal lab you referenced Sean. That would be more >>> representative of Alberts issue since he is using RHOSP. >>> >>> Brendan Shephard >>> >>> Senior Software Engineer >>> >>> Red Hat APAC >>> >>> 193 N Quay >>> >>> Brisbane City QLD 4000 >>> @RedHat Red Hat >>> Red Hat >>> >>> >>> >>> >>> >>> On Thu, Sep 15, 2022 at 10:12 PM Sean Mooney wrote: >>> >>> On Thu, 2022-09-15 at 21:33 +1000, Brendan Shephard wrote: >>> > Hey Sean, >>> > >>> > Thanks for the reply. >>> > >>> > For reference, I have all the steps to reproduce along with the >>> relevant >>> > debug logs attached to this LP: >>> > https://bugs.launchpad.net/neutron/+bug/1989627 >>> > >>> > But, to summarize. If I go to any random instance in Horizon as a >>> member >>> > user - not a admin. Then try to remove any Security Group at all from >>> any >>> > of the ports it fails with the policy violation (I attached a >>> screenshot of >>> > where I'm making that change in Horizon). But doing it with the same >>> user >>> > from the cli works fine. Since I'm editing individual interfaces there, >>> > rather than the instance itself. I assumed these would all be API >>> calls to >>> > Neutron from Horizon rather than from Horizon to Nova. >>> updating the instance securty group will not affect any exsitng ports >>> when you want to add or remvoe security groups form a port in horizont >>> you do not do that via the instace secutity group you do it via the port >>> edit dialog >>> in the port detail view under the network >>> >>> https:///dashboard/project/networks/ports/>> uuid>/detail >>> >>> i just did that now on a train cloud we have internally and was able to >>> add and remove a security group on a port. >>> >>> > >>> > I just run server list --all to demonstrate I was indeed using a member >>> > user and not a admin since an admin would have seen VM's from all >>> projects. >>> > >>> > I agree with you in principle. It should be exactly the same whether it >>> > comes from openstackclient or from Horizon. In fact, I was 98% >>> positive I >>> > would be able to demonstrate the wrong user was being used in this >>> case. >>> > But unfortunately, my efforts to reproduce it demonstrated that the >>> two are >>> > indeed handled differently. >>> >>> what page in horizon are you editing it form if i try and add/remove the >>> secirty group via the interfaces tabe at >>> https:///dashboard/project/instances// >>> it also work for me inlcuding removing all secuity groups and i am not >>> an admin on this cloud. >>> >>> specificly this is the redhat internal shared cloud i was testing on. >>> >>> > >>> > I believe anyone should be able to reproduce it using the steps I >>> outlined >>> > on the LP. >>> > >>> > Brendan Shephard >>> > >>> > Senior Software Engineer >>> > >>> > Red Hat APAC >>> > >>> > 193 N Quay >>> > >>> > Brisbane City QLD 4000 >>> > @RedHat Red Hat >>> > Red Hat >>> > >>> > >>> > >>> > >>> > >>> > On Thu, Sep 15, 2022 at 8:48 PM Sean Mooney >>> wrote: >>> > >>> > > On Thu, 2022-09-15 at 08:59 +1000, Brendan Shephard wrote: >>> > > > Hey Albert, >>> > > > >>> > > > The policy is the default Neutron policy in OpenStack Train. These >>> can >>> > > indeed be changed and customised, but my assumption is that you >>> haven?t >>> > > created any custom policies. Horizon uses the default for each >>> service >>> > > unless it?s been overwritten. >>> > > policy is defiend server side not client side so it applie equially >>> to all >>> > > users of the api >>> > > so the behavior will be the same for horizon or the cli >>> > > if you ever find a delta because horizon say used a differnt token >>> to make >>> > > the request that is a securty vulnerablity in horizon and should be >>> > > reported privatly to the horizon core team :) >>> > > >>> > > > >>> > > > If I create a non-admin user and try to change security groups I >>> also >>> > > get the same error: >>> > > > 2022-09-14 22:01:33,370 64 INFO >>> > > openstack_dashboard.dashboards.project.networks.ports.workflows >>> Failed to >>> > > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port >>> and >>> > > rule:update_port:binding:vnic_type) and >>> > > rule:update_port:port_security_enabled) is disallowed by policy >>> > > > >>> > > > And I can reproduce your same scenario ff I try via the CLI using >>> these >>> > > steps: >>> > > > 1. Add entry for new user to clouds.yaml file: >>> > > > bne-home-test: >>> > > > auth: >>> > > > auth_url: https://openstack.bne-home.net:13000 >>> > > > password: "test" >>> > > > project_domain_name: Default >>> > > > project_name: bne-home >>> > > > user_domain_name: Default >>> > > > username: test >>> > > > cacert: ~/.certs/overcloud-cacert.pem >>> > > > identity_api_version: '3' >>> > > > region_name: regionOne >>> > > > volume_api_version: ?3' >>> > > > >>> > > > 2. export OS_CLOUD=bne-home-test >>> > > > >>> > > > 3. Try to remove security group from port: >>> > > > ? openstack server show test-lb-net -c security_groups -c >>> addresses -f >>> > > yaml >>> > > > addresses: >>> > > > lb-mgmt-net: >>> > > > - 172.24.0.90 >>> > > > vlan4-infra: >>> > > > - 172.20.13.175 >>> > > > security_groups: >>> > > > - name: management-bne >>> > > the security group listed in nova is the default security group that >>> will >>> > > be used by all port create by nova. >>> > > it only applie to ports created by nova and not ones that are passed >>> in >>> > > using the uuid of a precreate port. >>> > > >>> > > you shoudl in general not mix managing security groups via nova and >>> > > neutron. >>> > > horizon shoudl prefer to manage security groups only via neutron if >>> it can. >>> > > > >>> > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c >>> fixed_ips >>> > > -c port_security_enabled -c security_group_ids -f yaml >>> > > > fixed_ips: >>> > > > - ip_address: 172.20.13.175 >>> > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 >>> > > > port_security_enabled: true >>> > > > security_group_ids: >>> > > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f >>> > > > >>> > > > ? openstack port unset --security-group >>> > > a3ae6e20-67df-4a72-9d5b-cc21ad87464f >>> 4df563ce-5464-4f7d-8aaf-c5496cdaefda >>> > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c >>> fixed_ips >>> > > -c port_security_enabled -c security_group_ids -f yaml >>> > > > fixed_ips: >>> > > > - ip_address: 172.20.13.175 >>> > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 >>> > > > port_security_enabled: true >>> > > > security_group_ids: [] >>> > > > >>> > > > >>> > > > Verify that I?m definitely not a admin user: >>> > > > ? openstack server list --all >>> > > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants >>> to be >>> > > performed. (HTTP 403) (Request-ID: >>> req-75c19210-ad91-471f-b500-e1f3482825f8) >>> > > > >>> > > > >>> > > > I don?t think this user should be allowed to do that via the CLI >>> either. >>> > > So that could be a bug there. The request in the Neutron server.log >>> when I >>> > > do it via the CLI: >>> > > > >>> > > > >>> > > user can add or remove security groups without being and admin >>> including >>> > > removing all securtiy groups thats intended behavior and should not >>> require >>> > > admin. >>> > > >>> > > are you implying that horizon is doing "openstack server list --all" >>> --all >>> > > is short for --all-tenants. >>> > > outside of the admin tab in horizon horizon would never pass the >>> equivlent >>> > > of --all to the nova api. >>> > > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None >>> > > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 >>> 781362d053ee4708a21430d3a825795a >>> > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] >>> > > 192.168.1.17,172.16.2.85 "PUT >>> > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: >>> 200 >>> > > len: 1102 time: 0.4449480 >>> > > > >>> > > > VS Horizon: >>> > > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None >>> > > req-4c284690-eb69-43df-b205-4953a88ab87c >>> 781362d053ee4708a21430d3a825795a >>> > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] >>> > > 172.20.10.25,172.16.2.85 "PUT >>> > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: >>> 403 >>> > > len: 386 time: 0.2209103 >>> > > > >>> > > > I have raised a upstream bug for this since I can still reproduce >>> it on >>> > > the latest version of OpenStack: >>> > > > https://bugs.launchpad.net/neutron/+bug/1989627? >>> > > > Bug #1989627 ?Policy enforcement variance between openstackcli >>> a...? : >>> > > Bugs : neutron >>> > > > bugs.launchpad.net >>> > > policy is enfoced on the nova/neutron api it cant behave differntly >>> for >>> > > horizon unless horizon is useing the wrong token. >>> > > i.e. not he users token. >>> > > > >>> > > > >>> > > > Brendan Shephard >>> > > > Senior Software Engineer >>> > > > Brisbane, Australia >>> > > > >>> > > > >>> > > > >>> > > > > On 15 Sep 2022, at 2:25 am, Albert Braden >>> wrote: >>> > > > > >>> > > > > Hi Brendan, thanks for offering to help! I'll contact you >>> privately >>> > > with info about some languishing cases. >>> > > > > >>> > > > > Here's the policy line: >>> > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or >>> > > rule:admin_or_network_owner" >>> > > > > >>> > > > > Does this policy only affect Horizon? I'm using the same >>> non-admin >>> > > user for both CLI and Horizon, on a project where that user is a >>> member. >>> > > The network was created by the admin user. >>> > > > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan >>> Shephard < >>> > > bshephar at redhat.com> wrote: >>> > > > > >>> > > > > >>> > > > > Hi Albert, >>> > > > > >>> > > > > While I may not be the best person to address your Horizon >>> concern. I >>> > > can probably help you with your Red Hat support concerns. If you had >>> any >>> > > issues you wanted addressed, or feedback you wanted to provide. Feel >>> free >>> > > to give me a yell. >>> > > > > >>> > > > > Looking at your Horizon issue though. It seems the default >>> policy file >>> > > is what prevents you from updating that port. We can see the default >>> policy >>> > > like this for example: >>> > > > > >>> > > > > [root at controller-2 ~]# podman exec -it neutron_api >>> > > oslopolicy-policy-generator --namespace neutron | grep >>> > > "update_port:port_security_enabled" >>> > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or >>> > > rule:admin_or_network_owner" >>> > > > > >>> > > > > When you execute the command via the CLI, which user are you >>> using? >>> > > Are you just sourcing the overcloudrc file, or using export >>> > > OS_CLOUD=overcloud. If that?s the case then you would be using the >>> admin >>> > > user on the CLI, but probably a different user when logging into >>> Horizon. >>> > > > > >>> > > > > I too would suggest opening a support case. It sounds like you >>> have >>> > > previously had a negative experience with that. If you want to open >>> a new >>> > > one and share the case number with me, I can follow up on that for >>> you. As >>> > > someone who personally knows a lot of the RHOSP Technical Support >>> team from >>> > > around the world. I?m confident we can right whatever wrong may have >>> > > occurred there. >>> > > > > >>> > > > > Let me know if I can help in any way. >>> > > > > >>> > > > > Regards, >>> > > > > >>> > > > > Brendan Shephard >>> > > > > Senior Software Engineer >>> > > > > Brisbane, Australia >>> > > > > >>> > > > > >>> > > > > >>> > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden >>> wrote: >>> > > > > > >>> > > > > > On CLI I can type "openstack port set --no-security-group >>> " to >>> > > remove all security groups. In Horizon, the equivalent operation >>> would be >>> > > using the - button to remove all groups and then clicking "Update." >>> Using >>> > > the + button would be the equivalent of typing "openstack port set >>> > > --security-group ". There doesn't seem to be a way to >>> remove a >>> > > single security group via CLI; I think the only way would be to set >>> > > --no-security-group and then add back the desired groups. >>> > > > > > >>> > > > > > I can successfully add security groups to a port via CLI, or I >>> can >>> > > remove all security groups. If I go into Horizon and try these >>> operations >>> > > then I get the error when I click "Update." So it appears that >>> security >>> > > groups can be added and removed, with port security set, via CLI. We >>> only >>> > > see the failure when we try to do it via Horizon. >>> > > > > > >>> > > > > > Regarding RHOSP support; I assume that you are joking, or maybe >>> > > haven't experienced the support that they offer. >>> > > > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent >>> Dumont < >>> > > laurentfdumont at gmail.com> wrote: >>> > > > > > >>> > > > > > >>> > > > > > If you are running RHOSP, you might have a support contract >>> with Red >>> > > Hat? >>> > > > > > >>> > > > > > Are you trying to remove all the security groups from a port >>> that >>> > > has port_security enabled? >>> > > > > > >>> > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden < >>> ozzzo at yahoo.com >>> > > > wrote: >>> > > > > > Unfortunately we are running RHOSP in which Train is the >>> latest and >>> > > greatest. This is what we see in horizon.log: >>> > > > > > >>> > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid >>> > > 139683266553600] [remote 10.232.233.11:57498 < >>> http://10.232.233.11:57498/>] >>> > > Failed to update port 08fdbb97-4896-4afb-9390-41481ff27cac: >>> > > ((rule:update_port and rule:update_port:binding:vnic_type) and >>> > > rule:update_port:port_security_enabled) is disallowed by policy >>> > > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre Riteau < >>> > > pierre at stackhpc.com > wrote: >>> > > > > > >>> > > > > > >>> > > > > > Hello, >>> > > > > > >>> > > > > > This is more likely to be a Horizon bug than an issue with >>> Kolla >>> > > itself, since Kolla doesn't change much from the default >>> configuration. >>> > > > > > >>> > > > > > You should check Horizon logs in /var/log/kolla/horizon to >>> find the >>> > > error. I would also encourage you to upgrade to a more recent >>> release, >>> > > since Train has been marked as End of Life in Kolla recently. >>> > > > > > >>> > > > > > Cheers, >>> > > > > > Pierre Riteau (priteau) >>> > > > > > >>> > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden >> > > > wrote: >>> > > > > > We're running kolla train and we're seeing an apparent bug >>> when we >>> > > try to add or remove security groups on a port. We see error "Failed >>> to >>> > > update port ". It works fine in CLI; we only see this in >>> Horizon. Is >>> > > this a known bug, or are we doing something wrong? >>> > > > > > >>> > > > > >>> > > > >>> > > > Hey Albert, >>> > > > >>> > > > The policy is the default Neutron policy in OpenStack Train. These >>> can >>> > > indeed be changed and customised, but my assumption is that you >>> haven?t >>> > > created any custom policies. Horizon uses the default for each >>> service >>> > > unless it?s been overwritten. >>> > > > >>> > > > If I create a non-admin user and try to change security groups I >>> also >>> > > get the same error: >>> > > > 2022-09-14 22:01:33,370 64 INFO >>> > > openstack_dashboard.dashboards.project.networks.ports.workflows >>> Failed to >>> > > update port 4df563ce-5464-4f7d-8aaf-c5496cdaefda: ((rule:update_port >>> and >>> > > rule:update_port:binding:vnic_type) and >>> > > rule:update_port:port_security_enabled) is disallowed by policy >>> > > > >>> > > > And I can reproduce your same scenario ff I try via the CLI using >>> these >>> > > steps: >>> > > > 1. Add entry for new user to clouds.yaml file: >>> > > > bne-home-test: >>> > > > auth: >>> > > > auth_url: https://openstack.bne-home.net:13000 >>> > > > password: "test" >>> > > > project_domain_name: Default >>> > > > project_name: bne-home >>> > > > user_domain_name: Default >>> > > > username: test >>> > > > cacert: ~/.certs/overcloud-cacert.pem >>> > > > identity_api_version: '3' >>> > > > region_name: regionOne >>> > > > volume_api_version: ?3' >>> > > > >>> > > > 2. export OS_CLOUD=bne-home-test >>> > > > >>> > > > 3. Try to remove security group from port: >>> > > > ? openstack server show test-lb-net -c security_groups -c >>> addresses -f >>> > > yaml >>> > > > addresses: >>> > > > lb-mgmt-net: >>> > > > - 172.24.0.90 >>> > > > vlan4-infra: >>> > > > - 172.20.13.175 >>> > > > security_groups: >>> > > > - name: management-bne >>> > > > >>> > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c >>> fixed_ips >>> > > -c port_security_enabled -c security_group_ids -f yaml >>> > > > fixed_ips: >>> > > > - ip_address: 172.20.13.175 >>> > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 >>> > > > port_security_enabled: true >>> > > > security_group_ids: >>> > > > - a3ae6e20-67df-4a72-9d5b-cc21ad87464f >>> > > > >>> > > > ? openstack port unset --security-group >>> > > a3ae6e20-67df-4a72-9d5b-cc21ad87464f >>> 4df563ce-5464-4f7d-8aaf-c5496cdaefda >>> > > > ? openstack port show 4df563ce-5464-4f7d-8aaf-c5496cdaefda -c >>> fixed_ips >>> > > -c port_security_enabled -c security_group_ids -f yaml >>> > > > fixed_ips: >>> > > > - ip_address: 172.20.13.175 >>> > > > subnet_id: 71aad09a-3e7b-4399-97bf-075f066f6713 >>> > > > port_security_enabled: true >>> > > > security_group_ids: [] >>> > > > >>> > > > >>> > > > Verify that I?m definitely not a admin user: >>> > > > ? openstack server list --all >>> > > > Policy doesn't allow os_compute_api:servers:detail:get_all_tenants >>> to be >>> > > performed. (HTTP 403) (Request-ID: >>> req-75c19210-ad91-471f-b500-e1f3482825f8) >>> > > > >>> > > > >>> > > > I don?t think this user should be allowed to do that via the CLI >>> either. >>> > > So that could be a bug there. The request in the Neutron server.log >>> when I >>> > > do it via the CLI: >>> > > > 2022-09-14 22:19:12.987 21 INFO neutron.wsgi [None >>> > > req-f99c4c15-003c-4f7e-9e41-9100daa2a566 >>> 781362d053ee4708a21430d3a825795a >>> > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] >>> > > 192.168.1.17,172.16.2.85 "PUT >>> > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: >>> 200 >>> > > len: 1102 time: 0.4449480 >>> > > > >>> > > > VS Horizon: >>> > > > 2022-09-14 22:20:23.087 20 INFO neutron.wsgi [None >>> > > req-4c284690-eb69-43df-b205-4953a88ab87c >>> 781362d053ee4708a21430d3a825795a >>> > > 3ff28fc7abf742a6b7a0d016771dee49 - - default default] >>> > > 172.20.10.25,172.16.2.85 "PUT >>> > > /v2.0/ports/4df563ce-5464-4f7d-8aaf-c5496cdaefda HTTP/1.1" status: >>> 403 >>> > > len: 386 time: 0.2209103 >>> > > > >>> > > > I have raised a upstream bug for this since I can still reproduce >>> it on >>> > > the latest version of OpenStack: >>> > > > launchpad-og-image.pngBug #1989627 ?Policy enforcement variance >>> between >>> > > openstackcli a...? : Bugs : neutron >>> > > > bugs.launchpad.net >>> > > > >>> > > > >>> > > > >>> > > > Brendan Shephard >>> > > > Senior Software Engineer >>> > > > Brisbane, Australia >>> > > > >>> > > > >>> > > > >>> > > > > On 15 Sep 2022, at 2:25 am, Albert Braden >>> wrote: >>> > > > > >>> > > > > Hi Brendan, thanks for offering to help! I'll contact you >>> privately >>> > > with info about some languishing cases. >>> > > > > >>> > > > > Here's the policy line: >>> > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or >>> > > rule:admin_or_network_owner" >>> > > > > >>> > > > > Does this policy only affect Horizon? I'm using the same >>> non-admin >>> > > user for both CLI and Horizon, on a project where that user is a >>> member. >>> > > The network was created by the admin user. >>> > > > > On Wednesday, September 14, 2022, 10:41:31 AM EDT, Brendan >>> Shephard < >>> > > bshephar at redhat.com> wrote: >>> > > > > >>> > > > > >>> > > > > Hi Albert, >>> > > > > >>> > > > > While I may not be the best person to address your Horizon >>> concern. I >>> > > can probably help you with your Red Hat support concerns. If you had >>> any >>> > > issues you wanted addressed, or feedback you wanted to provide. Feel >>> free >>> > > to give me a yell. >>> > > > > >>> > > > > Looking at your Horizon issue though. It seems the default >>> policy file >>> > > is what prevents you from updating that port. We can see the default >>> policy >>> > > like this for example: >>> > > > > >>> > > > > [root at controller-2 ~]# podman exec -it neutron_api >>> > > oslopolicy-policy-generator --namespace neutron | grep >>> > > "update_port:port_security_enabled" >>> > > > > "update_port:port_security_enabled": "rule:context_is_advsvc or >>> > > rule:admin_or_network_owner" >>> > > > > >>> > > > > When you execute the command via the CLI, which user are you >>> using? >>> > > Are you just sourcing the overcloudrc file, or using export >>> > > OS_CLOUD=overcloud. If that?s the case then you would be using the >>> admin >>> > > user on the CLI, but probably a different user when logging into >>> Horizon. >>> > > > > >>> > > > > I too would suggest opening a support case. It sounds like you >>> have >>> > > previously had a negative experience with that. If you want to open >>> a new >>> > > one and share the case number with me, I can follow up on that for >>> you. As >>> > > someone who personally knows a lot of the RHOSP Technical Support >>> team from >>> > > around the world. I?m confident we can right whatever wrong may have >>> > > occurred there. >>> > > > > >>> > > > > Let me know if I can help in any way. >>> > > > > >>> > > > > Regards, >>> > > > > >>> > > > > Brendan Shephard >>> > > > > Senior Software Engineer >>> > > > > Brisbane, Australia >>> > > > > >>> > > > > >>> > > > > >>> > > > > > On 14 Sep 2022, at 10:36 pm, Albert Braden >>> wrote: >>> > > > > > >>> > > > > > On CLI I can type "openstack port set --no-security-group >>> " to >>> > > remove all security groups. In Horizon, the equivalent operation >>> would be >>> > > using the - button to remove all groups and then clicking "Update." >>> Using >>> > > the + button would be the equivalent of typing "openstack port set >>> > > --security-group ". There doesn't seem to be a way to >>> remove a >>> > > single security group via CLI; I think the only way would be to set >>> > > --no-security-group and then add back the desired groups. >>> > > > > > >>> > > > > > I can successfully add security groups to a port via CLI, or I >>> can >>> > > remove all security groups. If I go into Horizon and try these >>> operations >>> > > then I get the error when I click "Update." So it appears that >>> security >>> > > groups can be added and removed, with port security set, via CLI. We >>> only >>> > > see the failure when we try to do it via Horizon. >>> > > > > > >>> > > > > > Regarding RHOSP support; I assume that you are joking, or maybe >>> > > haven't experienced the support that they offer. >>> > > > > > On Tuesday, September 13, 2022, 06:30:11 PM EDT, Laurent >>> Dumont < >>> > > laurentfdumont at gmail.com> wrote: >>> > > > > > >>> > > > > > >>> > > > > > If you are running RHOSP, you might have a support contract >>> with Red >>> > > Hat? >>> > > > > > >>> > > > > > Are you trying to remove all the security groups from a port >>> that >>> > > has port_security enabled? >>> > > > > > >>> > > > > > On Tue, Sep 13, 2022 at 11:53 AM Albert Braden < >>> ozzzo at yahoo.com> >>> > > wrote: >>> > > > > > > Unfortunately we are running RHOSP in which Train is the >>> latest >>> > > and greatest. This is what we see in horizon.log: >>> > > > > > > >>> > > > > > > [Tue Sep 13 15:28:15.362703 2022] [wsgi:error] [pid 27:tid >>> > > 139683266553600] [remote 10.232.233.11:57498] Failed to update port >>> > > 08fdbb97-4896-4afb-9390-41481ff27cac: ((rule:update_port and >>> > > rule:update_port:binding:vnic_type) and >>> > > rule:update_port:port_security_enabled) is disallowed by policy >>> > > > > > > On Friday, September 9, 2022, 10:59:34 AM EDT, Pierre >>> Riteau < >>> > > pierre at stackhpc.com> wrote: >>> > > > > > > >>> > > > > > > >>> > > > > > > Hello, >>> > > > > > > >>> > > > > > > This is more likely to be a Horizon bug than an issue with >>> Kolla >>> > > itself, since Kolla doesn't change much from the default >>> configuration. >>> > > > > > > >>> > > > > > > You should check Horizon logs in /var/log/kolla/horizon to >>> find >>> > > the error. I would also encourage you to upgrade to a more recent >>> release, >>> > > since Train has been marked as End of Life in Kolla recently. >>> > > > > > > >>> > > > > > > Cheers, >>> > > > > > > Pierre Riteau (priteau) >>> > > > > > > >>> > > > > > > On Fri, 9 Sept 2022 at 15:41, Albert Braden >> > >>> > > wrote: >>> > > > > > > > We're running kolla train and we're seeing an apparent bug >>> when >>> > > we try to add or remove security groups on a port. We see error >>> "Failed to >>> > > update port ". It works fine in CLI; we only see this in >>> Horizon. Is >>> > > this a known bug, or are we doing something wrong? >>> > > > > > > > >>> > > > > >>> > > > >>> > > >>> > > >>> >>> > > -- > Radomir Dopieralski > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboylan at sapwetik.org Fri Sep 16 15:11:52 2022 From: cboylan at sapwetik.org (Clark Boylan) Date: Fri, 16 Sep 2022 08:11:52 -0700 Subject: [all] Deprecated Zuul queue syntax In-Reply-To: <657e015c-1da4-4bc6-891b-f4373b93a001@www.fastmail.com> References: <657e015c-1da4-4bc6-891b-f4373b93a001@www.fastmail.com> Message-ID: <303d4f50-a1b8-44f7-bd49-c0665aafd985@www.fastmail.com> On Thu, May 19, 2022, at 10:10 AM, Clark Boylan wrote: > Hello, > > Zuul deprecated declaring shared queues at a pipeline level with > release 4.1.0 [0]. Zuul's current plan is to stop accepting this form > of configuration with a future 7.0.0 release. More details on what > needs to change can be found in Zuul's reminder notice on the Zuul > mailing list [1]. > > I expect we have about a month before the v7 release which should give > us plenty of time to fix this. If we don't fix this before the v7 > release the expected fallout will be that these project branches will > not have any pipelines defined, which means no Zuul jobs will run > against that project branch until the configs are updated. > It took a bit longer than a month (extra time!), but the change in zuul has merged [2]. OpenDev performs automated weekly Zuul upgrades each weekened which means we can expect to see this roll out in the next day or so. > > [0] > https://zuul-ci.org/docs/zuul/latest/releasenotes.html#relnotes-4-1-0-deprecation-notes > [1] > https://lists.zuul-ci.org/pipermail/zuul-discuss/2022-May/001801.html [2] https://review.opendev.org/c/zuul/zuul/+/855691 From elod.illes at est.tech Fri Sep 16 15:29:34 2022 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Fri, 16 Sep 2022 17:29:34 +0200 Subject: [release] Release countdown for week R-2, Sep 19 - 23 Message-ID: <8085bd7d-5ad7-89cf-9cad-93a4d129251c@est.tech> Development Focus ----------------- At this point we should have release candidates (RC1 or recent intermediary release) for all the Zed deliverables. Teams should be working on any release-critical bugs that would require another RC or intermediary release before the final release. Actions ------- Early in the week, the release team will be proposing stable/zed branch creation for all deliverables that have not branched yet, using the latest available Zed release as the branch point. If your team is ready to go for creating that branch, please let us know by leaving a +1 on these patches. If you would like to wait for another release before branching, you can -1 the patch and update it later in the week with the new release you would like to use. By the end of the week the release team will merge those patches though, unless an exception is granted. Once stable/zed branches are created, if a release-critical bug is detected, you will need to fix the issue in the master branch first, then backport the fix to the stable/zed branch before releasing out of the stable/zed branch. After all of the cycle-with-rc projects have branched we will branch devstack, grenade, and the requirements repos. This will effectively open them up for 2023.1 Antelope development, though the focus should still be on finishing up Zed until the final release. For projects with translations, watch for any translation patches coming through and merge them quickly. A new release should be produced so that translations are included in the final Zed release. Finally, now is a good time to finalize release notes. In particular, consider adding any relevant "prelude" content. Release notes are targeted for the downstream consumers of your project, so it would be great to include any useful information for those that are going to pick up and use or deploy the Zed version of your project. Upcoming Deadlines & Dates -------------------------- Final RC deadline: September 29th, 2022 (R-1 week) Final Zed release: October 5th, 2022 Virtual PTG: October 17-21, 2022 El?d Ill?s irc: elodilles From gmann at ghanshyammann.com Fri Sep 16 17:29:12 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 16 Sep 2022 22:59:12 +0530 Subject: [all][tc] What's happening in Technical Committee: summary 2022 Sept 16: Reading: 5 min Message-ID: <1834758e6bd.b2a5a4fb101540.1406444319067033576@ghanshyammann.com> Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week's meeting on Sept 15. Most of the meeting discussions are summarized in this email. Most of the meeting discussions are summarized in this email. Meeting logs are available @ https://meetings.opendev.org/meetings/tc/2022/tc.2022-09-15-15.00.log.html * Next TC weekly meeting will be on Sept 22 Thursday at 15:00 UTC, feel free to add the topic on the agenda[1] by Sept 21. 2. What we completed this week: ========================= * Switched release management to distributed leadership [2] * Retired panko projects [3] * Add Keystone OpenID Connect charm to OpenStack charms [4] * 2023.1 cycle testing runtime: 2023.1 cycle testing runtime is defined and merged [5], As feedback by the Horizon team, I am updating Node.JS version also to 18.0[6]. As discussed in last cycle PTG, we are moving to the python version testing template to unversioned name[7] and will control/update the new stable branch and cycle changes in central place in openstack-zuul-jobs repo. With that we do not need to update the each project repo on every release by release bot patches. 3. Activities In progress: ================== TC Tracker for Zed cycle ------------------------------ * Zed tracker etherpad includes the TC working items[8], four are completed and others items are in-progress. Open Reviews ----------------- * Two open reviews for ongoing activities[9]. 2023.1 cycle Technical Election (TC + PTL) -------------------------------------------------- We will have election voting for TC and Ironic project. The voting is open until Sept 19. Please follow the election official emails for actions/things to do. We had 9 projects missed the PTL nomination but good news is that we found the leaders for all the 9 projects now[10]. As next step, TC will be discussing the PTL appointment. 2023.1 cycle TC PTG planning ------------------------------------ Updates on PTG planning: * "TC + Leader interaction" sessions is scheduled for Oct 17 Monday 15-17 UTC[10], * I have created the TC PTG etherpad to collect the topic[11]. * I sent email about the 'Operator Hours' slots in this PTG, please check and reserve the operator hour slot for your project[12] 2021 User Survey TC Question Analysis ----------------------------------------------- No update on this. The survey summary is up for review[13]. Feel free to check and provide feedback. Fixing Zuul config error ---------------------------- Requesting projects with zuul config error to look into those and fix them which should not take much time[14]15]. Project updates ------------------- * None. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[16]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [17] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://review.opendev.org/c/openstack/governance/+/855276 [3] https://review.opendev.org/c/openstack/governance/+/850005 [4] https://review.opendev.org/c/openstack/governance/+/857493 [5] https://review.opendev.org/c/openstack/governance/+/854375 [6] https://review.opendev.org/c/openstack/governance/+/856927 [7] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/856903 [8] https://etherpad.opendev.org/p/tc-zed-tracker [9] https://review.opendev.org/q/projects:openstack/governance+status:open [10] https://etherpad.opendev.org/p/2023.1-leaderless [10] https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030303.html [11] https://etherpad.opendev.org/p/tc-2023-1-ptg [12] https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030301.html [13] https://review.opendev.org/c/openstack/governance/+/836888 [14] https://etherpad.opendev.org/p/zuul-config-error-openstack [15] http://lists.openstack.org/pipermail/openstack-discuss/2022-May/028603.html [16] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [17] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann From hongbin034 at gmail.com Sat Sep 17 09:20:37 2022 From: hongbin034 at gmail.com (Hongbin Lu) Date: Sat, 17 Sep 2022 17:20:37 +0800 Subject: Container not appearing In-Reply-To: References: Message-ID: I saw you were using "admin" tenant in Horizon dashboard. Any luck if you switch to "demo" tenant? Best regards, Hongbin On Mon, Sep 5, 2022 at 11:22 PM Lee, Vincent Z wrote: > Hi all, > I am facing issues with making containers to appear on my gui. I have > managed to run a container, however, it is not showing it on horizon > dashboard. > > When I tried to create a container, it will be successfully > > > > Best, > Vincent > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 530678 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 304252 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 431379 bytes Desc: not available URL: From miguel at mlavalle.com Sun Sep 18 23:39:27 2022 From: miguel at mlavalle.com (Miguel Lavalle) Date: Sun, 18 Sep 2022 18:39:27 -0500 Subject: [neutron] bug deputy report September 12th to 18th Message-ID: Hi, Here's this week's bugs deputy report: Requires follow up ============== High ==== https://bugs.launchpad.net/neutron/+bug/1989480 [OVN] Neutron server floods logs with hash ring messages on startup. Assigned to Lucas Gomes. Proposed fix: https://review.opendev.org/c/openstack/neutron/+/857463 Medium ====== https://bugs.launchpad.net/neutron/+bug/1989460 [ovn-octavia-provider] HealthMonitor event received on port deleted. Assigned to Fernando Royo. Proposed fix: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/857365 https://bugs.launchpad.net/neutron/+bug/1989979 Unexpected number of DHCP interfaces for metadata proxy. Assigned to MIguel Lavalle (mlavalle) RFE === Incomplete ======== https://bugs.launchpad.net/neutron/+bug/1989986 changing dns_domain on the charm does not propagate to ovn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafaelweingartner at gmail.com Mon Sep 19 11:33:32 2022 From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=) Date: Mon, 19 Sep 2022 08:33:32 -0300 Subject: [CloudKitty] Virtual PTG October 2022 Message-ID: Hello everyone, As you probably heard our next PTG will be held virtually in October. We've marked October 17, at 14:00-16:00 UTC [1]. We already have a CloudKitty meeting organized for this day. Therefore, it seems the most practical choice. However, if you guys would like some other dates and/or time, just let me know. The room we selected is called "Essex". I've also created an etherpad [2] to collect ideas/topics for the PTG sessions. If you have anything to discuss, please don't hesitate to write it there. [1] https://ptg.opendev.org/ptg.html [2] https://etherpad.opendev.org/p/oct2022-ptg-cloudkitty -- Rafael Weing?rtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhazan at mandint.org Mon Sep 19 14:11:20 2022 From: mhazan at mandint.org (mhazan at mandint.org) Date: Mon, 19 Sep 2022 16:11:20 +0200 Subject: [neutron][nova][ipv6]instance on compute node not getting dhcpv6 Message-ID: <091032bb358edf4c2a54b50a009ecdbf@mandint.org> Hello all, i manage a small openstack cluster installed via Ubuntu package, it has been upgraded since the day of Newton and currently running Victoria. it started as a single node with the basic services installed, later a dedicated storage node and compute node were added. after upgrading to victoria, any instance that boot on the dedicated compute node start up but fails to get it's global ipv6 via stateful dhcp6, only linklocal(fe80) ip is shown by the instance. The ipv6 is created in openstack, the dhcpv4 works and there are no issue if the instance boot on the "old" all in one node. i can manually allocate (by editing the instance network config file) the ipv6 config and it works. any pointer as to what could cause this issue ? BR, Michael From benedikt.trefzer at cirrax.com Mon Sep 19 16:03:03 2022 From: benedikt.trefzer at cirrax.com (Benedikt Trefzer) Date: Mon, 19 Sep 2022 18:03:03 +0200 Subject: [neutron] dhcp/dnsmasq issue after upgrade to queens Message-ID: Hello out there I'm stuck with neutron not starting any dnsmasq processes after upgrading neutron to the queens release (yes I know this is an elderly version ;)) Details: I see errors from neutron-dhcp-agent (on the dhcp host and on the controller node for the neutron-rpc-server): ValueError: Unrecognized attribute(s) 'binding:host_id' But I'm pretty sure this is a followup of the directory /var/lib/neutron/dhcp ($state_path) beeing almost empty (only empty directories named by the networks beeing there, which are rebuild by the neutron-dhcp-agent if deleted). I'm further do not see any ports in the DB for dhcp. Which eventually explains why the state files for dnsmasq are missing. So now I'm stuck: - Which agent/daemon should create the ports for the dnsmasq process ? The installation should launch two dhcp processes on two router nodes (HA setup). Which is also correctly shown using neutron dhcp-agent-list-hosting-net which shows two dhcp-agents up and running ! Any hints how to solve are appreciated ! Greetings Benedikt From iurygregory at gmail.com Mon Sep 19 19:49:52 2022 From: iurygregory at gmail.com (Iury Gregory) Date: Mon, 19 Sep 2022 16:49:52 -0300 Subject: [ironic] Check PTG topics In-Reply-To: References: Message-ID: Hello ironicers, Tomorrow (Sep 20 at 16 UTC we will have our meeting) We will use https://meet.google.com/ivs-qwyc-kpo , if you want a calendar invite let me know via irc =) See you tomorrow! Em qui., 8 de set. de 2022 ?s 14:54, Iury Gregory escreveu: > Hello ironicers, > > The Antelope PTG is in a a few weeks, we had the idea to check the PTG > topics (so we can group some before setting the final schedule) > Please vote in the doodle [1] for a time where we can discuss a bit o/ > Feel free to add topics to our etherpad! [2] > Thanks! > > [1] https://doodle.com/meeting/participate/id/dBL8ZZXa > [2] https://etherpad.opendev.org/p/ironic-antelope-ptg > -- > *Att[]'s* > > *Iury Gregory Melo Ferreira * > *MSc in Computer Science at UFCG* > *Ironic PTL * > *Senior Software Engineer at Red Hat Brazil* > *Social*: https://www.linkedin.com/in/iurygregory > *E-mail: iurygregory at gmail.com * > -- *Att[]'s* *Iury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Ironic PTL * *Senior Software Engineer at Red Hat Brazil* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From katonalala at gmail.com Tue Sep 20 07:37:36 2022 From: katonalala at gmail.com (Lajos Katona) Date: Tue, 20 Sep 2022 09:37:36 +0200 Subject: [neutron][nova][ipv6]instance on compute node not getting dhcpv6 In-Reply-To: <091032bb358edf4c2a54b50a009ecdbf@mandint.org> References: <091032bb358edf4c2a54b50a009ecdbf@mandint.org> Message-ID: Hi, Do you have some more details of your environment, which backend you use? OVS? Your VMs have both IPv4 and v6 addresses and you mean that they got IPv4 as expected? Lajos ezt ?rta (id?pont: 2022. szept. 19., H, 16:19): > Hello all, > > i manage a small openstack cluster installed via Ubuntu package, it has > been upgraded since the day of Newton and currently running Victoria. it > started as a single node with the basic services installed, later a > dedicated storage node and compute node were added. after upgrading to > victoria, any instance that boot on the dedicated compute node start up > but fails to get it's global ipv6 via stateful dhcp6, only > linklocal(fe80) ip is shown by the instance. The ipv6 is created in > openstack, the dhcpv4 works and there are no issue if the instance boot > on the "old" all in one node. i can manually allocate (by editing the > instance network config file) the ipv6 config and it works. any pointer > as to what could cause this issue ? > > BR, Michael > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhazan at mandint.org Tue Sep 20 08:11:38 2022 From: mhazan at mandint.org (Michael Hazan) Date: Tue, 20 Sep 2022 10:11:38 +0200 Subject: =?utf-8?Q?RE=C2=A0:_[neutron][nova][ipv6]instance_on_compute_node_not_get?= =?utf-8?Q?ting_dhcpv6?= In-Reply-To: References: <091032bb358edf4c2a54b50a009ecdbf@mandint.org> Message-ID: Hello, The 3 nodes are running Ubuntu 20.04 and using libvirt. The instance are Ubuntu or debian based. The openstack virtual network is configured with both a v4 and a v6 dhcp pool. The instance should be getting both v4 and v6 (on the same interface) but the instance that are hosted on the compute node only get v4. If i run the dhclient -6 -r the instance actually get it?s ipv6 but it?s wrongly configured with a /128 (instead of 64) and no route. Michael De?: Lajos Katona Envoy? le?:mardi, 20 septembre 2022 09:39 ??: mhazan at mandint.org Cc?: openstack-discuss at lists.openstack.org Objet?:Re: [neutron][nova][ipv6]instance on compute node not getting dhcpv6 Hi, Do you have some more details of your environment, which backend you use? OVS? Your VMs have both IPv4 and v6 addresses and you mean that they got IPv4 as expected? Lajos ezt ?rta (id?pont: 2022. szept. 19., H, 16:19): Hello all, i manage a small openstack cluster installed via Ubuntu package, it has been upgraded since the day of Newton and currently running Victoria. it started as a single node with the basic services installed, later a dedicated storage node and compute node were added. after upgrading to victoria, any instance that boot on the dedicated compute node start up but fails to get it's global ipv6 via stateful dhcp6, only linklocal(fe80) ip is shown by the instance. The ipv6 is created in openstack, the dhcpv4 works and there are no issue if the instance boot on the "old" all in one node. i can manually allocate (by editing the instance network config file) the ipv6 config and it works. any pointer as to what could cause this issue ? BR, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdemaced at redhat.com Tue Sep 20 08:18:17 2022 From: mdemaced at redhat.com (Maysa De Macedo Souza) Date: Tue, 20 Sep 2022 10:18:17 +0200 Subject: [kuryr] Antelope PTG topics Message-ID: Hello, The Antelope PTG is a few weeks away and if you have any topics to discuss in the Kuryr session, feel free to include it in the etherpad[1]. Cheers, Maysa Macedo. [1] https://etherpad.opendev.org/p/kuryr-antelope-ptg -------------- next part -------------- An HTML attachment was scrubbed... URL: From neil at tigera.io Tue Sep 20 08:47:10 2022 From: neil at tigera.io (Neil Jerram) Date: Tue, 20 Sep 2022 09:47:10 +0100 Subject: [neutron][nova][ipv6]instance on compute node not getting dhcpv6 In-Reply-To: References: <091032bb358edf4c2a54b50a009ecdbf@mandint.org> Message-ID: They may be outdated now, but I wonder if any of the steps described at https://projectcalico.docs.tigera.io/networking/openstack/ipv6 would help you? In particular, given that you have no route, perhaps you need the accept_ra config. Best wishes, Neil On Tue, Sep 20, 2022 at 9:12 AM Michael Hazan wrote: > Hello, > > The 3 nodes are running Ubuntu 20.04 and using libvirt. The instance are > Ubuntu or debian based. The openstack virtual network is configured with > both a v4 and a v6 dhcp pool. The instance should be getting both v4 and v6 > (on the same interface) but the instance that are hosted on the compute > node only get v4. If i run the dhclient -6 -r the instance actually get > it?s ipv6 but it?s wrongly configured with a /128 (instead of 64) and no > route. > > > > Michael > > > > *De : *Lajos Katona > *Envoy? le :*mardi, 20 septembre 2022 09:39 > *? : *mhazan at mandint.org > *Cc : *openstack-discuss at lists.openstack.org > *Objet :*Re: [neutron][nova][ipv6]instance on compute node not getting > dhcpv6 > > > > Hi, > > Do you have some more details of your environment, which backend you use? > OVS? > > Your VMs have both IPv4 and v6 addresses and you mean that they got IPv4 > as expected? > > > > Lajos > > > > ezt ?rta (id?pont: 2022. szept. 19., H, 16:19): > > Hello all, > > i manage a small openstack cluster installed via Ubuntu package, it has > been upgraded since the day of Newton and currently running Victoria. it > started as a single node with the basic services installed, later a > dedicated storage node and compute node were added. after upgrading to > victoria, any instance that boot on the dedicated compute node start up > but fails to get it's global ipv6 via stateful dhcp6, only > linklocal(fe80) ip is shown by the instance. The ipv6 is created in > openstack, the dhcpv4 works and there are no issue if the instance boot > on the "old" all in one node. i can manually allocate (by editing the > instance network config file) the ipv6 config and it works. any pointer > as to what could cause this issue ? > > BR, Michael > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhazan at mandint.org Tue Sep 20 08:53:11 2022 From: mhazan at mandint.org (Michael Hazan) Date: Tue, 20 Sep 2022 10:53:11 +0200 Subject: =?utf-8?Q?RE=C2=A0:_RE_:_[neutron][nova][ipv6]instance_on_compute_node_no?= =?utf-8?Q?t_getting_dhcpv6?= In-Reply-To: References: <091032bb358edf4c2a54b50a009ecdbf@mandint.org> Message-ID: Thanks for the suggestion, i will look into the accept_ra setting. However, the very same image that boot on the ??old?? all in one node are getting ipv6 and ipv4 without issue. The network interfaces are configured similarly on all nodes. Michael De?: Neil Jerram Envoy? le?:mardi, 20 septembre 2022 10:47 ??: Michael Hazan Cc?: Lajos Katona; openstack-discuss at lists.openstack.org Objet?:Re: RE : [neutron][nova][ipv6]instance on compute node not getting dhcpv6 They may be outdated now, but I wonder if any of the steps described at?https://projectcalico.docs.tigera.io/networking/openstack/ipv6 would help you?? In particular, given that you have no route, perhaps you need the accept_ra config. Best wishes, ? ? Neil On Tue, Sep 20, 2022 at 9:12 AM Michael Hazan wrote: Hello, The 3 nodes are running Ubuntu 20.04 and using libvirt. The instance are Ubuntu or debian based. The openstack virtual network is configured with both a v4 and a v6 dhcp pool. The instance should be getting both v4 and v6 (on the same interface) but the instance that are hosted on the compute node only get v4. If i run the dhclient -6 -r the instance actually get it?s ipv6 but it?s wrongly configured with a /128 (instead of 64) and no route. ? Michael ? De?: Lajos Katona Envoy? le?:mardi, 20 septembre 2022 09:39 ??: mhazan at mandint.org Cc?: openstack-discuss at lists.openstack.org Objet?:Re: [neutron][nova][ipv6]instance on compute node not getting dhcpv6 ? Hi, Do you have some more details of your environment, which backend you use? OVS? Your VMs have both IPv4 and v6 addresses and you mean that they got IPv4 as expected? ? Lajos ? ezt ?rta (id?pont: 2022. szept. 19., H, 16:19): Hello all, i manage a small openstack cluster installed via Ubuntu package, it has been upgraded since the day of Newton and currently running Victoria. it started as a single node with the basic services installed, later a dedicated storage node and compute node were added. after upgrading to victoria, any instance that boot on the dedicated compute node start up but fails to get it's global ipv6 via stateful dhcp6, only linklocal(fe80) ip is shown by the instance. The ipv6 is created in openstack, the dhcpv4 works and there are no issue if the instance boot on the "old" all in one node. i can manually allocate (by editing the instance network config file) the ipv6 config and it works. any pointer as to what could cause this issue ? BR, Michael ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From akahat at redhat.com Tue Sep 20 12:01:01 2022 From: akahat at redhat.com (Amol Kahat) Date: Tue, 20 Sep 2022 17:31:01 +0530 Subject: [tripleo] Gate blocker NODE_FAILURES when running tripleo-ci-centos-9-scenario010-standalone Message-ID: Hello All, Description of problem: NODE_FAILURE when running tripleo-ci-centos-9-scenario010-standalone job. We have been seeing this failure[1] since 09/17. Logs are not present so it's hard to say what is the root cause of this issue. This job uses nodeset: single-centos-9-node-nested-virt - so assumption is that it's the nest-virt nodeset [1] https://zuul.openstack.org/builds?job_name=tripleo-ci-centos-9-scenario010-standalone+&skip=0 Thanks, -- *Amol Kahat* Software Engineer *Red Hat India Pvt. Ltd. Pune, India.* akahat at redhat.com B764 E6F8 F4C1 A1AF 816C 6840 FDD3 BA6C 832D 7715 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cboylan at sapwetik.org Tue Sep 20 14:30:14 2022 From: cboylan at sapwetik.org (Clark Boylan) Date: Tue, 20 Sep 2022 07:30:14 -0700 Subject: [tripleo] Gate blocker NODE_FAILURES when running tripleo-ci-centos-9-scenario010-standalone In-Reply-To: References: Message-ID: <6d5c3429-39ba-4133-aa66-a73229d3f76f@www.fastmail.com> On Tue, Sep 20, 2022, at 5:01 AM, Amol Kahat wrote: > Hello All, > > Description of problem: > NODE_FAILURE when running tripleo-ci-centos-9-scenario010-standalone job. > > We have been seeing this failure[1] since 09/17. Logs are not present > so it's hard to say what is the root cause of this issue. NODE_FAILURE indicates that Nodepool could not boot any nodes to fulfill the nodeset requested by your job. The reason there are no job logs is that this occurs before any Zuul jobs can run. See below for the information that is available though. > > This job uses nodeset: single-centos-9-node-nested-virt - so assumption > is that it's the nest-virt nodeset Fungi ended up debugging and correcting [2] this issue, but I was able to get a good idea of what might be happening using just a phone and no special access. This label is provided by four cloud providers [3][4][5][6] only two of which currently have positive max-servers values [7][8]. We can check the general health of those providers using Grafana [9]. This shows the providers idled for some reason. Finding the specific cause of that idling did require extra privileges, and fungi pasted that info for us [10]. While I agree it is more difficult to say what the root cause is, there is still plenty of information to narrow the problem down and determine what might be going on. Ideally we would publish the Nodepool launcher logs too, then we wouldn't need special access to retrieve the traceback in the paste. Unfortunately, there has been a long standing concern that we might leak cloud credentials if openstacksdk or Nodepool logging do something we don't expect. There is also a Zuul spec to merge Nodepool functionality into Zuul proper [11] which should allow us to report better errors when NODE_FAILURE occurs. > > [1] > https://zuul.openstack.org/builds?job_name=tripleo-ci-centos-9-scenario010-standalone+&skip=0 [2] https://review.opendev.org/c/openstack/project-config/+/858523 [3] https://opendev.org/openstack/project-config/src/branch/master/nodepool/nl02.opendev.org.yaml#L210 [4] https://opendev.org/openstack/project-config/src/branch/master/nodepool/nl03.opendev.org.yaml#L404 [5] https://opendev.org/openstack/project-config/src/branch/master/nodepool/nl04.opendev.org.yaml#L174 [6] https://opendev.org/openstack/project-config/src/branch/master/nodepool/nl04.opendev.org.yaml#L195 [7] https://opendev.org/openstack/project-config/src/branch/master/nodepool/nl04.opendev.org.yaml#L82 [8] https://opendev.org/openstack/project-config/src/branch/master/nodepool/nl04.opendev.org.yaml#L194 [9] https://grafana.opendev.org/d/2b4dba9e25/nodepool-ovh?orgId=1&from=now-5d&to=now [10] https://paste.opendev.org/show/816812/ [11] https://zuul-ci.org/docs/zuul/latest/developer/specs/nodepool-in-zuul.html > > Thanks, > -- > *Amol Kahat* > Software Engineer > *Red Hat India Pvt. Ltd. Pune, India.* > akahat at redhat.com > B764 E6F8 F4C1 A1AF 816C 6840 FDD3 BA6C 832D 7715 From iurygregory at gmail.com Tue Sep 20 14:46:15 2022 From: iurygregory at gmail.com (Iury Gregory) Date: Tue, 20 Sep 2022 11:46:15 -0300 Subject: [ironic] Check PTG topics In-Reply-To: References: Message-ID: Hello ironicers, Small update, the meeting won't take place today at 16 UTC, it will be Thursday Sep 22 at 15:00 UTC (same link from my previous email) Em seg., 19 de set. de 2022 ?s 16:49, Iury Gregory escreveu: > Hello ironicers, > > Tomorrow (Sep 20 at 16 UTC we will have our meeting) > We will use https://meet.google.com/ivs-qwyc-kpo , if you want a calendar > invite let me know via irc =) > See you tomorrow! > > > Em qui., 8 de set. de 2022 ?s 14:54, Iury Gregory > escreveu: > >> Hello ironicers, >> >> The Antelope PTG is in a a few weeks, we had the idea to check the PTG >> topics (so we can group some before setting the final schedule) >> Please vote in the doodle [1] for a time where we can discuss a bit o/ >> Feel free to add topics to our etherpad! [2] >> Thanks! >> >> [1] https://doodle.com/meeting/participate/id/dBL8ZZXa >> [2] https://etherpad.opendev.org/p/ironic-antelope-ptg >> -- >> *Att[]'s* >> >> *Iury Gregory Melo Ferreira * >> *MSc in Computer Science at UFCG* >> *Ironic PTL * >> *Senior Software Engineer at Red Hat Brazil* >> *Social*: https://www.linkedin.com/in/iurygregory >> *E-mail: iurygregory at gmail.com * >> > > > -- > *Att[]'s* > > *Iury Gregory Melo Ferreira * > *MSc in Computer Science at UFCG* > *Ironic PTL * > *Senior Software Engineer at Red Hat Brazil* > *Social*: https://www.linkedin.com/in/iurygregory > *E-mail: iurygregory at gmail.com * > -- *Att[]'s* *Iury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Ironic PTL * *Senior Software Engineer at Red Hat Brazil* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From ianyrchoi at gmail.com Tue Sep 20 14:57:56 2022 From: ianyrchoi at gmail.com (Ian Y. Choi) Date: Tue, 20 Sep 2022 23:57:56 +0900 Subject: [all][elections][tc][ptl] Antelope: Technical Committee & PTL Election Conclusion & Results Message-ID: Thank you to the electorate, to all those who voted and to all candidates who put their name forward for Technical Committee (TC) & Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible. 1. Please join me in congratulating the 4 newly elected members of the TC: Dan Smith (dansmith)Ghanshyam Mann (gmann)Jay Faulkner (JayF)Dmitriy Rabotyagov (noonedeadpunk) Full results:https://civs1.civs.us/cgi-bin/results.pl?id=E_41d42603087bcf58 2. For the results of the PTL election process, please join me in extending congratulations to the following PTLs: * Barbican : Grzegorz Grasza (xek)* Blazar : Pierre Riteau (priteau)* Cinder : Rajat Dhasmana ()* Cloudkitty : Rafael Weingartner ()* Cyborg : alex song ()* Designate : Michael Johnson (johnsom)* Ec2 Api : Andrey Pavlov (andrey-mp)* Freezer : ge cong ()* Glance : Pranali Deore (pdeore)* Heat : Brendan Shephard ()* Horizon : Vishal Manchanda (vishalmanchanda)* Ironic : Jay Faulkner (JayF)* Kolla : Michal Nasiadka (mnasiadka)* Kuryr : Roman Dobosz (gryf)* Magnum : Jake Yip (jakeyip)* Manila : Carlos Silva (carloss)* Monasca : Martin Chacon Piza (chaconpiza)* Murano : Rong Zhu (zhurong)* Neutron : Rodolfo Alonso Hernandez ()* Nova : Sylvain Bauza (bauzas)* Octavia : Gregory Thiemonge (gthiemonge)* Openstack Chef : Lance Albertson (Ramereth)* OpenStack Helm : Gage Hugo (gagehugo)* OpenStackAnsible : Dmitriy Rabotyagov (noonedeadpunk)* OpenStackSDK : Artem Goncharov (gtema)* Puppet OpenStack : Takashi Kajinami (tkajinam)* Quality Assurance : Martin Kopec (kopecmartin)* Rally : Andrey Kurilin (andreykurilin)* Skyline : Wenxiang Wu (wu_wenxiang)* Solum : Rong Zhu (zhurong)* Storlets : Takashi Kajinami (tkajinam)* Tacker : Yasufumi Ogawa (yasufum)* Telemetry : Matthias Runge (mrunge)* Tripleo : Rabi Mishra (ramishra)* Trove : wu chunyang (wuchunyang)* Vitrage : Eyal Bar-Ilan ()* Watcher : chen ke ()* Winstackers : Lucian Petrut ()* Zaqar : Hao Wang () PTL Election:* Ironic: https://civs1.civs.us/cgi-bin/results.pl?id=E_c7d81a19f30c67f0 Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round. Ian Y. Choi, on behalf of the OpenStack Technical Election Officials -------------- next part -------------- An HTML attachment was scrubbed... URL: From ianyrchoi at gmail.com Tue Sep 20 15:03:01 2022 From: ianyrchoi at gmail.com (Ian Y. Choi) Date: Wed, 21 Sep 2022 00:03:01 +0900 Subject: [all][elections][tc][ptl] Antelope: Technical Committee & PTL Election Conclusion & Results In-Reply-To: References: Message-ID: (Re-sending with better formatting) Thank you to the electorate, to all those who voted and to all candidates who put their name forward for Technical Committee (TC) & Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible. 1. Please join me in congratulating the 4 newly elected members of the TC: Dan Smith (dansmith) Ghanshyam Mann (gmann) Jay Faulkner (JayF) Dmitriy Rabotyagov (noonedeadpunk) Full results: https://civs1.civs.us/cgi-bin/results.pl?id=E_41d42603087bcf58 2. For the results of the PTL election process, please join me in extending congratulations to the following PTLs: * Barbican : Grzegorz Grasza (xek) * Blazar : Pierre Riteau (priteau) * Cinder : Rajat Dhasmana () * Cloudkitty : Rafael Weingartner () * Cyborg : alex song () * Designate : Michael Johnson (johnsom) * Ec2 Api : Andrey Pavlov (andrey-mp) * Freezer : ge cong () * Glance : Pranali Deore (pdeore) * Heat : Brendan Shephard () * Horizon : Vishal Manchanda (vishalmanchanda) * Ironic : Jay Faulkner (JayF) * Kolla : Michal Nasiadka (mnasiadka) * Kuryr : Roman Dobosz (gryf) * Magnum : Jake Yip (jakeyip) * Manila : Carlos Silva (carloss) * Monasca : Martin Chacon Piza (chaconpiza) * Murano : Rong Zhu (zhurong) * Neutron : Rodolfo Alonso Hernandez () * Nova : Sylvain Bauza (bauzas) * Octavia : Gregory Thiemonge (gthiemonge) * Openstack Chef : Lance Albertson (Ramereth) * OpenStack Helm : Gage Hugo (gagehugo) * OpenStackAnsible : Dmitriy Rabotyagov (noonedeadpunk) * OpenStackSDK : Artem Goncharov (gtema) * Puppet OpenStack : Takashi Kajinami (tkajinam) * Quality Assurance : Martin Kopec (kopecmartin) * Rally : Andrey Kurilin (andreykurilin) * Skyline : Wenxiang Wu (wu_wenxiang) * Solum : Rong Zhu (zhurong) * Storlets : Takashi Kajinami (tkajinam) * Tacker : Yasufumi Ogawa (yasufum) * Telemetry : Matthias Runge (mrunge) * Tripleo : Rabi Mishra (ramishra) * Trove : wu chunyang (wuchunyang) * Vitrage : Eyal Bar-Ilan () * Watcher : chen ke () * Winstackers : Lucian Petrut () * Zaqar : Hao Wang () PTL Election: * Ironic: https://civs1.civs.us/cgi-bin/results.pl?id=E_c7d81a19f30c67f0 Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round. Ian Y. Choi, on behalf of the OpenStack Technical Election Officials On Tue, Sep 20, 2022 at 11:57 PM Ian Y. Choi wrote: > Thank you to the electorate, to all those who voted and to all candidates > who put their name forward for Technical Committee (TC) & Project Team Lead > (PTL) in this election. A healthy, open process breeds trust in our > decision making capability thank you to all those who make this process > possible. > > 1. Please join me in congratulating the 4 newly elected members of the TC: > Dan Smith (dansmith)Ghanshyam Mann (gmann)Jay Faulkner (JayF)Dmitriy > Rabotyagov (noonedeadpunk) > Full results: > https://civs1.civs.us/cgi-bin/results.pl?id=E_41d42603087bcf58 > 2. For the results of the PTL election process, please join me in > extending congratulations to the following PTLs: > * Barbican : Grzegorz Grasza (xek)* Blazar : Pierre > Riteau (priteau)* Cinder : Rajat Dhasmana ()* Cloudkitty > : Rafael Weingartner ()* Cyborg : alex song ()* Designate > : Michael Johnson (johnsom)* Ec2 Api : Andrey Pavlov > (andrey-mp)* Freezer : ge cong ()* Glance : Pranali > Deore (pdeore)* Heat : Brendan Shephard ()* Horizon > : Vishal Manchanda (vishalmanchanda)* Ironic : Jay Faulkner > (JayF)* Kolla : Michal Nasiadka (mnasiadka)* Kuryr > : Roman Dobosz (gryf)* Magnum : Jake Yip (jakeyip)* Manila > : Carlos Silva (carloss)* Monasca : Martin Chacon Piza > (chaconpiza)* Murano : Rong Zhu (zhurong)* Neutron : > Rodolfo Alonso Hernandez ()* Nova : Sylvain Bauza (bauzas)* > Octavia : Gregory Thiemonge (gthiemonge)* Openstack Chef : > Lance Albertson (Ramereth)* OpenStack Helm : Gage Hugo (gagehugo)* > OpenStackAnsible : Dmitriy Rabotyagov (noonedeadpunk)* OpenStackSDK : > Artem Goncharov (gtema)* Puppet OpenStack : Takashi Kajinami (tkajinam)* > Quality Assurance : Martin Kopec (kopecmartin)* Rally : Andrey > Kurilin (andreykurilin)* Skyline : Wenxiang Wu (wu_wenxiang)* > Solum : Rong Zhu (zhurong)* Storlets : Takashi > Kajinami (tkajinam)* Tacker : Yasufumi Ogawa (yasufum)* > Telemetry : Matthias Runge (mrunge)* Tripleo : Rabi > Mishra (ramishra)* Trove : wu chunyang (wuchunyang)* Vitrage > : Eyal Bar-Ilan ()* Watcher : chen ke ()* Winstackers > : Lucian Petrut ()* Zaqar : Hao Wang () > PTL Election:* Ironic: > https://civs1.civs.us/cgi-bin/results.pl?id=E_c7d81a19f30c67f0 > Election process details and results are also available here: > https://governance.openstack.org/election/ > Thank you to all of the candidates, having a good group of candidates > helps engage the community in our democratic process. > Thank you to all who voted and who encouraged others to vote. We need to > ensure your voice is heard. > Thank you for another great round. > > Ian Y. Choi, on behalf of the OpenStack Technical Election Officials > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iurygregory at gmail.com Tue Sep 20 15:19:37 2022 From: iurygregory at gmail.com (Iury Gregory) Date: Tue, 20 Sep 2022 12:19:37 -0300 Subject: [ironic] Proposing Harald Jensas to metalsmith-core Message-ID: Hello ironic-cores and metalsmith-cores, I would like to propose Harald Jensas for metalsmith-core. During the Zed Cycle he had a lot of reviews for the project [1], in yoga he contributed a lot to the project [2]. Looking at all the releases in stackalytics he is #6 in commits [3] and reviews [4]. Please vote with +1/-1 (till Sep 25) [1] https://www.stackalytics.io/?release=zed&module=opendev.org/openstack/metalsmith [2] https://www.stackalytics.io/?release=yoga&module=opendev.org/openstack/metalsmith&metric=commits [3] https://www.stackalytics.io/?release=all&module=opendev.org/openstack/metalsmith&metric=commits [4] https://www.stackalytics.io/?release=all&module=opendev.org/openstack/metalsmith&metric=marks -- *Att[]'s* *Iury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Ironic PTL Yoga and Zed Cycle* *Senior Software Engineer at Red Hat Brazil* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory at gmail.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From saditya at vt.edu Tue Sep 20 04:29:55 2022 From: saditya at vt.edu (Aditya Sathish) Date: Tue, 20 Sep 2022 00:29:55 -0400 Subject: Query about networking-onos for newer OpenStack releases Message-ID: Hello! I am trying to integrate an SDN controller with our lab's OpenStack network. Currently, we have already deployed a version of ONOS to serve our needs and I have been following the SONA project which uses the networking-onos ML2 plugin with OpenStack. However, it seems that the networking-onos project has been retired since the Train release. Is there any way I can get ONOS to work with OpenStack Yoga? If not, what is the go-to way to integrate an SDN controller with OpenFlow support with Neutron?? Any help will be much appreciated. Regards, Aditya. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtantsur at redhat.com Tue Sep 20 15:40:08 2022 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Tue, 20 Sep 2022 17:40:08 +0200 Subject: [ironic] Proposing Harald Jensas to metalsmith-core In-Reply-To: References: Message-ID: Makes sense, +1. Good job Harald! On Tue, Sep 20, 2022 at 5:25 PM Iury Gregory wrote: > Hello ironic-cores and metalsmith-cores, > > I would like to propose Harald Jensas for metalsmith-core. > During the Zed Cycle he had a lot of reviews for the project [1], in yoga > he contributed a lot to the project [2]. Looking at all the releases in > stackalytics he is #6 in commits [3] and reviews [4]. > > Please vote with +1/-1 (till Sep 25) > > [1] > https://www.stackalytics.io/?release=zed&module=opendev.org/openstack/metalsmith > [2] > https://www.stackalytics.io/?release=yoga&module=opendev.org/openstack/metalsmith&metric=commits > [3] > https://www.stackalytics.io/?release=all&module=opendev.org/openstack/metalsmith&metric=commits > [4] > https://www.stackalytics.io/?release=all&module=opendev.org/openstack/metalsmith&metric=marks > > -- > *Att[]'s* > > *Iury Gregory Melo Ferreira * > *MSc in Computer Science at UFCG* > *Ironic PTL Yoga and Zed Cycle* > *Senior Software Engineer at Red Hat Brazil* > *Social*: https://www.linkedin.com/in/iurygregory > *E-mail: iurygregory at gmail.com * > -- Red Hat GmbH , Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross -------------- next part -------------- An HTML attachment was scrubbed... URL: From juliaashleykreger at gmail.com Tue Sep 20 15:43:46 2022 From: juliaashleykreger at gmail.com (Julia Kreger) Date: Tue, 20 Sep 2022 08:43:46 -0700 Subject: [ironic] Proposing Harald Jensas to metalsmith-core In-Reply-To: References: Message-ID: +1 from me! -Julia On Tue, Sep 20, 2022 at 8:23 AM Iury Gregory wrote: > > Hello ironic-cores and metalsmith-cores, > > I would like to propose Harald Jensas for metalsmith-core. [trim] > > Please vote with +1/-1 (till Sep 25) > [trim] From ralonsoh at redhat.com Tue Sep 20 15:59:35 2022 From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez) Date: Tue, 20 Sep 2022 17:59:35 +0200 Subject: Query about networking-onos for newer OpenStack releases In-Reply-To: References: Message-ID: Hello Aditya: I would point you to a similar situation we had with neutron-fwaas [1]. The project was revived and now is maintained. If you need to go through this process, you can first raise this request in the Neutron drivers meeting [2]. You can add this topic to the agenda and then attend the meeting [3] (Friday 1400UTC, #openstack-neutron channel). Regards. [1] https://lists.openstack.org/pipermail/openstack-discuss/2022-January/026742.html [2]https://wiki.openstack.org/wiki/Meetings/NeutronDrivers [3]https://meetings.opendev.org/#Neutron_drivers_Meeting On Tue, Sep 20, 2022 at 5:36 PM Aditya Sathish wrote: > Hello! > > I am trying to integrate an SDN controller with our lab's OpenStack > network. Currently, we have already deployed a version of ONOS to serve our > needs and I have been following the SONA project which uses the > networking-onos ML2 plugin with OpenStack. However, it seems that the > networking-onos project has been retired since the Train release. > > Is there any way I can get ONOS to work with OpenStack Yoga? If not, what > is the go-to way to integrate an SDN controller with OpenFlow support with > Neutron?? > > Any help will be much appreciated. > > Regards, > Aditya. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay at gr-oss.io Tue Sep 20 16:00:58 2022 From: jay at gr-oss.io (Jay Faulkner) Date: Tue, 20 Sep 2022 09:00:58 -0700 Subject: [ironic] Proposing Harald Jensas to metalsmith-core In-Reply-To: References: Message-ID: +1 Congratulations Harald, and thanks for the good work. -- Jay Faulkner On Tue, Sep 20, 2022 at 8:27 AM Iury Gregory wrote: > Hello ironic-cores and metalsmith-cores, > > I would like to propose Harald Jensas for metalsmith-core. > During the Zed Cycle he had a lot of reviews for the project [1], in yoga > he contributed a lot to the project [2]. Looking at all the releases in > stackalytics he is #6 in commits [3] and reviews [4]. > > Please vote with +1/-1 (till Sep 25) > > [1] > https://www.stackalytics.io/?release=zed&module=opendev.org/openstack/metalsmith > [2] > https://www.stackalytics.io/?release=yoga&module=opendev.org/openstack/metalsmith&metric=commits > [3] > https://www.stackalytics.io/?release=all&module=opendev.org/openstack/metalsmith&metric=commits > [4] > https://www.stackalytics.io/?release=all&module=opendev.org/openstack/metalsmith&metric=marks > > -- > *Att[]'s* > > *Iury Gregory Melo Ferreira * > *MSc in Computer Science at UFCG* > *Ironic PTL Yoga and Zed Cycle* > *Senior Software Engineer at Red Hat Brazil* > *Social*: https://www.linkedin.com/in/iurygregory > *E-mail: iurygregory at gmail.com * > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rlandy at redhat.com Tue Sep 20 16:01:09 2022 From: rlandy at redhat.com (Ronelle Landy) Date: Tue, 20 Sep 2022 12:01:09 -0400 Subject: [tripleo] Gate blocker NODE_FAILURES when running tripleo-ci-centos-9-scenario010-standalone In-Reply-To: <6d5c3429-39ba-4133-aa66-a73229d3f76f@www.fastmail.com> References: <6d5c3429-39ba-4133-aa66-a73229d3f76f@www.fastmail.com> Message-ID: On Tue, Sep 20, 2022 at 10:39 AM Clark Boylan wrote: > On Tue, Sep 20, 2022, at 5:01 AM, Amol Kahat wrote: > > Hello All, > > > > Description of problem: > > NODE_FAILURE when running tripleo-ci-centos-9-scenario010-standalone job. > > > > We have been seeing this failure[1] since 09/17. Logs are not present > > so it's hard to say what is the root cause of this issue. > > NODE_FAILURE indicates that Nodepool could not boot any nodes to fulfill > the nodeset requested by your job. The reason there are no job logs is that > this occurs before any Zuul jobs can run. See below for the information > that is available though. > > > > > This job uses nodeset: single-centos-9-node-nested-virt - so assumption > > is that it's the nest-virt nodeset > > Fungi ended up debugging and correcting [2] this issue, but I was able to > get a good idea of what might be happening using just a phone and no > special access. This label is provided by four cloud providers [3][4][5][6] > only two of which currently have positive max-servers values [7][8]. We can > check the general health of those providers using Grafana [9]. This shows > the providers idled for some reason. Finding the specific cause of that > idling did require extra privileges, and fungi pasted that info for us [10]. > > While I agree it is more difficult to say what the root cause is, there is > still plenty of information to narrow the problem down and determine what > might be going on. Ideally we would publish the Nodepool launcher logs too, > then we wouldn't need special access to retrieve the traceback in the > paste. Unfortunately, there has been a long standing concern that we might > leak cloud credentials if openstacksdk or Nodepool logging do something we > don't expect. There is also a Zuul spec to merge Nodepool functionality > into Zuul proper [11] which should allow us to report better errors when > NODE_FAILURE occurs. > > > > > [1] > > > https://zuul.openstack.org/builds?job_name=tripleo-ci-centos-9-scenario010-standalone+&skip=0 > > [2] https://review.opendev.org/c/openstack/project-config/+/858523 > [3] > https://opendev.org/openstack/project-config/src/branch/master/nodepool/nl02.opendev.org.yaml#L210 > [4] > https://opendev.org/openstack/project-config/src/branch/master/nodepool/nl03.opendev.org.yaml#L404 > [5] > https://opendev.org/openstack/project-config/src/branch/master/nodepool/nl04.opendev.org.yaml#L174 > [6] > https://opendev.org/openstack/project-config/src/branch/master/nodepool/nl04.opendev.org.yaml#L195 > [7] > https://opendev.org/openstack/project-config/src/branch/master/nodepool/nl04.opendev.org.yaml#L82 > [8] > https://opendev.org/openstack/project-config/src/branch/master/nodepool/nl04.opendev.org.yaml#L194 > [9] > https://grafana.opendev.org/d/2b4dba9e25/nodepool-ovh?orgId=1&from=now-5d&to=now > [10] https://paste.opendev.org/show/816812/ > [11] > https://zuul-ci.org/docs/zuul/latest/developer/specs/nodepool-in-zuul.html Thanks for the fix and all the above info > > > > > > Thanks, > > -- > > *Amol Kahat* > > Software Engineer > > *Red Hat India Pvt. Ltd. Pune, India.* > > akahat at redhat.com > > B764 E6F8 F4C1 A1AF 816C 6840 FDD3 BA6C 832D 7715 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From swogatpradhan22 at gmail.com Tue Sep 20 19:43:02 2022 From: swogatpradhan22 at gmail.com (Swogat Pradhan) Date: Wed, 21 Sep 2022 01:13:02 +0530 Subject: Floating IP attached to octavia not working | tripleo wallaby | centos | OVN DVR Message-ID: Hi, I've deployed Octavia + OVN + DVR and floating IPs assigned to Octavia VIPs are not reachable. Other floating IPs tied to nova instances are working fine. The octavia vip is reachable and working fine from inside on the private network, however the Floating IP is not reachable at all. I found a similar issue in bugzilla but the bug is closed now and i do not have any solution. https://bugzilla.redhat.com/show_bug.cgi?id=1608951 Please help me get a solution for this issue. With regards, Swogat pradhan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay at gr-oss.io Tue Sep 20 20:27:08 2022 From: jay at gr-oss.io (Jay Faulkner) Date: Tue, 20 Sep 2022 13:27:08 -0700 Subject: [ironic] Looking for downstream users of bugfix/* branches Message-ID: Hey all, Ironic releases intermediate bugfix releases during the cycle. These are consumed by some packagers and standalone users of Ironic. Today, using Ironic as an example, we have 4 active bugfix branches: - bugfix/21.0 and bugfix/20.2 are between yoga and zed - bugfix/19.0 is between xena and yoga - bugfix/18.1 is between wallaby and xena We are considering cleaning up some of the older bugfix branches, to reduce stable maintenance load -- but we would like to poll you all first: Is anyone consuming these releases downstream? If so, which ones and why? This will be useful input to whatever action we decide to take! Thanks, Jay Faulkner -------------- next part -------------- An HTML attachment was scrubbed... URL: From tribecca at tribecc.us Tue Sep 20 22:03:49 2022 From: tribecca at tribecc.us (T. Nichole Williams) Date: Tue, 20 Sep 2022 18:03:49 -0400 Subject: CFP Open - Ubuntu Summit 2022 Message-ID: <039F1D6A-E575-4BE8-992F-6AEBB118504F@tribecc.us> Greetings everyone, Your friendly neighborhood Kata Community Manager checking in to let you all know that the call for presentations[2] is now open for Ubuntu Summit 2022[1]. The event will be held from November 7-9, 2022 in Prague, Czech Republic. The Ubuntu Summit (FKA the Ubuntu Developer Summit) will include a series of talks, workshops, panels and Q&A covering a broad range of topics to appeal not only to developers, but anyone involved in open source. The event is organized into the following tracks: ? Ubuntu Desktop ? Community ? Data Science & Data Platforms ? Application Ecosystem ? Infrastructure Though in-person attendance is preferred, there is a virtual option for those unable to travel. CFP will close September 30, 2002, so if you have a presentation (or workshop) on OpenStack ready to go, please send it in! Regards, T. Nichole Williams Technical Community Manager | Kata Containers Twitter: OGtrilliams GitHub: OGtrilliams IRC: PagliaccisCloud [1] https://events.canonical.com/event/2/ [2] https://events.canonical.com/event/2/abstracts/ From park0kyung0won at dgist.ac.kr Wed Sep 21 02:44:34 2022 From: park0kyung0won at dgist.ac.kr (=?UTF-8?B?67CV6rK97JuQ?=) Date: Wed, 21 Sep 2022 11:44:34 +0900 (KST) Subject: [keystone] Changing user password_hash directly in database Message-ID: <322454722.180028.1663728274336.JavaMail.root@mailwas2> An HTML attachment was scrubbed... URL: From yasufum.o at gmail.com Wed Sep 21 03:12:25 2022 From: yasufum.o at gmail.com (Yasufumi Ogawa) Date: Wed, 21 Sep 2022 12:12:25 +0900 Subject: [tacker][ptg] Virtual PTG Planning Message-ID: Hi Tacker team, I've updated the etherpad for our antelope PTG [1] as I mentioned in the previous IRC meeting. Please add your topics if you have any suggestions for the next release. [1] https://etherpad.opendev.org/p/tacker-antelope-ptg Cheers, Yasufumi From sbaker at redhat.com Wed Sep 21 03:41:44 2022 From: sbaker at redhat.com (Steve Baker) Date: Wed, 21 Sep 2022 15:41:44 +1200 Subject: [ironic] Proposing Harald Jensas to metalsmith-core In-Reply-To: References: Message-ID: +1! Thanks for all your work Harald On 21/09/22 03:19, Iury Gregory wrote: > Hello ironic-cores and metalsmith-cores, > > I would like to propose Harald Jensas for metalsmith-core. > During the Zed Cycle he had a lot of reviews for the project [1], in > yoga he contributed a lot to the project [2]. Looking at all the > releases in stackalytics he is #6 in commits [3] and reviews [4]. > > Please vote with +1/-1 (till Sep 25) > > [1] > https://www.stackalytics.io/?release=zed&module=opendev.org/openstack/metalsmith > > [2] > https://www.stackalytics.io/?release=yoga&module=opendev.org/openstack/metalsmith&metric=commits > > [3] > https://www.stackalytics.io/?release=all&module=opendev.org/openstack/metalsmith&metric=commits > > [4] > https://www.stackalytics.io/?release=all&module=opendev.org/openstack/metalsmith&metric=marks > > > -- > /Att[]'s/ > /Iury Gregory Melo Ferreira > //MSc in Computer Science at UFCG > / > /Ironic PTL Yoga and Zed Cycle/ > //Senior Software Engineer at Red Hat Brazil// > /Social/:https://www.linkedin.com/in/iurygregory > > /E-mail: iurygregory at gmail.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at bakeyournoodle.com Wed Sep 21 05:25:26 2022 From: tony at bakeyournoodle.com (Tony Breeds) Date: Wed, 21 Sep 2022 15:25:26 +1000 Subject: [magnum][heat][requirements][release] Potential blocker for release with python-magnumclient 4.0.0 Message-ID: Hello all, In [1] baymodel code was removed, although it still seems to be listed in the API-ref. Story [2] states it's been deprecated for a long time, but a quick check failed to see this documented anywhere. Heat still supports baymodel and the removal is causing failures. Blocking the use of python-magnumclient 4.0.0[3] inzed, even though the 4.0.0 release is clearly meant for zed. I can see a couple of paths forward. 0. Remove the documentation in the api-ref for baymodels 1. Remove the support in heat for baymodels (I think the newer clusters API can be used instead?) 2. Revert the change in magnumclient and re-release etc etc 3. Keep 4.0.0 for the Antelope release, and reset the stable/zed branch python-magnumclient to fd0cb1e (before the removal of baymodels) Obviously option 1 looks like the least disruptive change, but potentially causes a problem for heat depending on the published state of baymodel support [1] https://review.opendev.org/c/openstack/python-magnumclient/+/803629 [2] https://storyboard.openstack.org/#!/story/2009104 [3] https://review.opendev.org/c/openstack/requirements/+/858089 -- Yours Tony. From bshephar at redhat.com Wed Sep 21 05:49:41 2022 From: bshephar at redhat.com (Brendan Shephard) Date: Wed, 21 Sep 2022 15:49:41 +1000 Subject: [magnum][heat][requirements][release] Potential blocker for release with python-magnumclient 4.0.0 In-Reply-To: References: Message-ID: Hey Tony, Thanks for the heads up. We have deprecated support for these resources some time ago: https://review.opendev.org/c/openstack/heat/+/433549 I don't believe there are any concerns with removing this resource and subsequent use of the baymodel API from Heat now. Brendan Shephard Senior Software Engineer Red Hat APAC 193 N Quay Brisbane City QLD 4000 @RedHat Red Hat Red Hat On Wed, Sep 21, 2022 at 3:37 PM Tony Breeds wrote: > Hello all, > In [1] baymodel code was removed, although it still seems to be > listed in the API-ref. Story [2] states it's been deprecated for a > long time, but a quick check failed to see this documented anywhere. > Heat still supports baymodel and the removal is causing failures. > Blocking the use of python-magnumclient 4.0.0[3] inzed, even though > the 4.0.0 release is clearly meant for zed. > > I can see a couple of paths forward. > > 0. Remove the documentation in the api-ref for baymodels > 1. Remove the support in heat for baymodels (I think the newer > clusters API can be used instead?) > 2. Revert the change in magnumclient and re-release etc etc > 3. Keep 4.0.0 for the Antelope release, and reset the stable/zed > branch python-magnumclient to fd0cb1e (before the removal of > baymodels) > > Obviously option 1 looks like the least disruptive change, but > potentially causes a problem for heat depending on the published state > of baymodel support > > [1] https://review.opendev.org/c/openstack/python-magnumclient/+/803629 > [2] https://storyboard.openstack.org/#!/story/2009104 > [3] https://review.opendev.org/c/openstack/requirements/+/858089 > > -- > Yours Tony. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at bakeyournoodle.com Wed Sep 21 05:57:10 2022 From: tony at bakeyournoodle.com (Tony Breeds) Date: Wed, 21 Sep 2022 15:57:10 +1000 Subject: [magnum][heat][requirements][release] Potential blocker for release with python-magnumclient 4.0.0 In-Reply-To: References: Message-ID: Okay cool. I'll take a punt at removing it On Wed, 21 Sept 2022 at 15:50, Brendan Shephard wrote: > Hey Tony, > > Thanks for the heads up. We have deprecated support for these resources > some time ago: > https://review.opendev.org/c/openstack/heat/+/433549 > > I don't believe there are any concerns with removing this resource and > subsequent use of the baymodel API from Heat now. > > Brendan Shephard > > Senior Software Engineer > > Red Hat APAC > > 193 N Quay > > Brisbane City QLD 4000 > @RedHat Red Hat > Red Hat > > > > > > On Wed, Sep 21, 2022 at 3:37 PM Tony Breeds > wrote: > >> Hello all, >> In [1] baymodel code was removed, although it still seems to be >> listed in the API-ref. Story [2] states it's been deprecated for a >> long time, but a quick check failed to see this documented anywhere. >> Heat still supports baymodel and the removal is causing failures. >> Blocking the use of python-magnumclient 4.0.0[3] inzed, even though >> the 4.0.0 release is clearly meant for zed. >> >> I can see a couple of paths forward. >> >> 0. Remove the documentation in the api-ref for baymodels >> 1. Remove the support in heat for baymodels (I think the newer >> clusters API can be used instead?) >> 2. Revert the change in magnumclient and re-release etc etc >> 3. Keep 4.0.0 for the Antelope release, and reset the stable/zed >> branch python-magnumclient to fd0cb1e (before the removal of >> baymodels) >> >> Obviously option 1 looks like the least disruptive change, but >> potentially causes a problem for heat depending on the published state >> of baymodel support >> >> [1] https://review.opendev.org/c/openstack/python-magnumclient/+/803629 >> [2] https://storyboard.openstack.org/#!/story/2009104 >> [3] https://review.opendev.org/c/openstack/requirements/+/858089 >> >> -- >> Yours Tony. >> >> -- Yours Tony. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dtantsur at redhat.com Wed Sep 21 06:57:10 2022 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Wed, 21 Sep 2022 08:57:10 +0200 Subject: [ironic] Looking for downstream users of bugfix/* branches In-Reply-To: References: Message-ID: Hi Jay, These are the branches OpenShift uses for its downstream versions of Metal3 (extracted from our internal docs): ironic bugfix/21.0 ironic-inspector bugfix/11.0 ironic-python-agent bugfix/9.0 ironic bugfix/20.2 ironic-inspector bugfix/10.12 ironic-python-agent bugfix/8.6 ironic bugfix/19.0 ironic-inspector bugfix/10.9 ironic-python-agent bugfix/8.3 ironic bugfix/18.1 ironic-inspector bugfix/10.7 ironic-python-agent bugfix/8.1 We use them, because OpenShift releases are not aligned with OpenStack ones, so more often than not, we need to have a slice of the master branch. Having bugfix branches allows us to collaborate on bug fixes upstream, rather than on forks in github.com/openshift. Please reach out to Riccardo, Iury or myself if you have any questions on OpenShift's usage of Ironic. Dmitry On Tue, Sep 20, 2022 at 10:32 PM Jay Faulkner wrote: > Hey all, > > Ironic releases intermediate bugfix releases during the cycle. These are > consumed by some packagers and standalone users of Ironic. > > Today, using Ironic as an example, we have 4 active bugfix branches: > - bugfix/21.0 and bugfix/20.2 are between yoga and zed > - bugfix/19.0 is between xena and yoga > - bugfix/18.1 is between wallaby and xena > > We are considering cleaning up some of the older bugfix branches, to > reduce stable maintenance load -- but we would like to poll you all first: > Is anyone consuming these releases downstream? If so, which ones and why? > > This will be useful input to whatever action we decide to take! > > Thanks, > Jay Faulkner > > -- Red Hat GmbH , Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Wed Sep 21 07:36:39 2022 From: skaplons at redhat.com (Slawek Kaplonski) Date: Wed, 21 Sep 2022 09:36:39 +0200 Subject: [all][elections][tc][ptl] Antelope: Technical Committee & PTL Election Conclusion & Results In-Reply-To: References: Message-ID: <4381966.3mUJL5CBU7@p1> Hi, Dnia wtorek, 20 wrze?nia 2022 17:03:01 CEST Ian Y. Choi pisze: > (Re-sending with better formatting) > > Thank you to the electorate, to all those who voted and to all candidates > who put their name forward for Technical Committee (TC) & Project Team Lead > (PTL) in this election. A healthy, open process breeds trust in our > decision making capability thank you to all those who make this process > possible. > > 1. Please join me in congratulating the 4 newly elected members of the TC: > > Dan Smith (dansmith) > Ghanshyam Mann (gmann) > Jay Faulkner (JayF) > Dmitriy Rabotyagov (noonedeadpunk) Welcome new and returning members of the TC :) > > Full results: > https://civs1.civs.us/cgi-bin/results.pl?id=E_41d42603087bcf58 > > 2. For the results of the PTL election process, please join me in extending > congratulations to the following PTLs: > > * Barbican : Grzegorz Grasza (xek) > * Blazar : Pierre Riteau (priteau) > * Cinder : Rajat Dhasmana () > * Cloudkitty : Rafael Weingartner () > * Cyborg : alex song () > * Designate : Michael Johnson (johnsom) > * Ec2 Api : Andrey Pavlov (andrey-mp) > * Freezer : ge cong () > * Glance : Pranali Deore (pdeore) > * Heat : Brendan Shephard () > * Horizon : Vishal Manchanda (vishalmanchanda) > * Ironic : Jay Faulkner (JayF) > * Kolla : Michal Nasiadka (mnasiadka) > * Kuryr : Roman Dobosz (gryf) > * Magnum : Jake Yip (jakeyip) > * Manila : Carlos Silva (carloss) > * Monasca : Martin Chacon Piza (chaconpiza) > * Murano : Rong Zhu (zhurong) > * Neutron : Rodolfo Alonso Hernandez () > * Nova : Sylvain Bauza (bauzas) > * Octavia : Gregory Thiemonge (gthiemonge) > * Openstack Chef : Lance Albertson (Ramereth) > * OpenStack Helm : Gage Hugo (gagehugo) > * OpenStackAnsible : Dmitriy Rabotyagov (noonedeadpunk) > * OpenStackSDK : Artem Goncharov (gtema) > * Puppet OpenStack : Takashi Kajinami (tkajinam) > * Quality Assurance : Martin Kopec (kopecmartin) > * Rally : Andrey Kurilin (andreykurilin) > * Skyline : Wenxiang Wu (wu_wenxiang) > * Solum : Rong Zhu (zhurong) > * Storlets : Takashi Kajinami (tkajinam) > * Tacker : Yasufumi Ogawa (yasufum) > * Telemetry : Matthias Runge (mrunge) > * Tripleo : Rabi Mishra (ramishra) > * Trove : wu chunyang (wuchunyang) > * Vitrage : Eyal Bar-Ilan () > * Watcher : chen ke () > * Winstackers : Lucian Petrut () > * Zaqar : Hao Wang () Congratulations everyone! > > PTL Election: > * Ironic: https://civs1.civs.us/cgi-bin/results.pl?id=E_c7d81a19f30c67f0 > > Election process details and results are also available here: > https://governance.openstack.org/election/ > > Thank you to all of the candidates, having a good group of candidates helps > engage the community in our democratic process. > > Thank you to all who voted and who encouraged others to vote. We need to > ensure your voice is heard. > > Thank you for another great round. > > > Ian Y. Choi, on behalf of the OpenStack Technical Election Officials > > > On Tue, Sep 20, 2022 at 11:57 PM Ian Y. Choi wrote: > > > Thank you to the electorate, to all those who voted and to all candidates > > who put their name forward for Technical Committee (TC) & Project Team Lead > > (PTL) in this election. A healthy, open process breeds trust in our > > decision making capability thank you to all those who make this process > > possible. > > > > 1. Please join me in congratulating the 4 newly elected members of the TC: > > Dan Smith (dansmith)Ghanshyam Mann (gmann)Jay Faulkner (JayF)Dmitriy > > Rabotyagov (noonedeadpunk) > > Full results: > > https://civs1.civs.us/cgi-bin/results.pl?id=E_41d42603087bcf58 > > 2. For the results of the PTL election process, please join me in > > extending congratulations to the following PTLs: > > * Barbican : Grzegorz Grasza (xek)* Blazar : Pierre > > Riteau (priteau)* Cinder : Rajat Dhasmana ()* Cloudkitty > > : Rafael Weingartner ()* Cyborg : alex song ()* Designate > > : Michael Johnson (johnsom)* Ec2 Api : Andrey Pavlov > > (andrey-mp)* Freezer : ge cong ()* Glance : Pranali > > Deore (pdeore)* Heat : Brendan Shephard ()* Horizon > > : Vishal Manchanda (vishalmanchanda)* Ironic : Jay Faulkner > > (JayF)* Kolla : Michal Nasiadka (mnasiadka)* Kuryr > > : Roman Dobosz (gryf)* Magnum : Jake Yip (jakeyip)* Manila > > : Carlos Silva (carloss)* Monasca : Martin Chacon Piza > > (chaconpiza)* Murano : Rong Zhu (zhurong)* Neutron : > > Rodolfo Alonso Hernandez ()* Nova : Sylvain Bauza (bauzas)* > > Octavia : Gregory Thiemonge (gthiemonge)* Openstack Chef : > > Lance Albertson (Ramereth)* OpenStack Helm : Gage Hugo (gagehugo)* > > OpenStackAnsible : Dmitriy Rabotyagov (noonedeadpunk)* OpenStackSDK : > > Artem Goncharov (gtema)* Puppet OpenStack : Takashi Kajinami (tkajinam)* > > Quality Assurance : Martin Kopec (kopecmartin)* Rally : Andrey > > Kurilin (andreykurilin)* Skyline : Wenxiang Wu (wu_wenxiang)* > > Solum : Rong Zhu (zhurong)* Storlets : Takashi > > Kajinami (tkajinam)* Tacker : Yasufumi Ogawa (yasufum)* > > Telemetry : Matthias Runge (mrunge)* Tripleo : Rabi > > Mishra (ramishra)* Trove : wu chunyang (wuchunyang)* Vitrage > > : Eyal Bar-Ilan ()* Watcher : chen ke ()* Winstackers > > : Lucian Petrut ()* Zaqar : Hao Wang () > > PTL Election:* Ironic: > > https://civs1.civs.us/cgi-bin/results.pl?id=E_c7d81a19f30c67f0 > > Election process details and results are also available here: > > https://governance.openstack.org/election/ > > Thank you to all of the candidates, having a good group of candidates > > helps engage the community in our democratic process. > > Thank you to all who voted and who encouraged others to vote. We need to > > ensure your voice is heard. > > Thank you for another great round. > > > > Ian Y. Choi, on behalf of the OpenStack Technical Election Officials > > > -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From mhazan at mandint.org Wed Sep 21 07:57:41 2022 From: mhazan at mandint.org (mhazan at mandint.org) Date: Wed, 21 Sep 2022 09:57:41 +0200 Subject: =?UTF-8?Q?Re=3A_RE=C2=A0=3A_RE_=3A_=5Bneutron=5D=5Bnova=5D=5Bipv?= =?UTF-8?Q?6=5Dinstance_on_compute_node_not_getting_dhcpv6?= In-Reply-To: References: <091032bb358edf4c2a54b50a009ecdbf@mandint.org> Message-ID: no joy with the accept_ra fiddling, the image are all ubuntu or debian cloud-init ready and are working on all in one node but not dedicated compute node, it's as if the dhcpv6 packet (before address is allocated to interface) are not passing between the control node and the dedicated compute node. Le 2022-09-20 10:53, Michael Hazan a ?crit : > Thanks for the suggestion, i will look into the accept_ra setting. However, the very same image that boot on the ? old ? all in one node are getting ipv6 and ipv4 without issue. The network interfaces are configured similarly on all nodes. > > Michael > > DE : Neil Jerram > ENVOY? LE :mardi, 20 septembre 2022 10:47 > ? : Michael Hazan > CC : Lajos Katona; openstack-discuss at lists.openstack.org > OBJET :Re: RE : [neutron][nova][ipv6]instance on compute node not getting dhcpv6 > > They may be outdated now, but I wonder if any of the steps described at https://projectcalico.docs.tigera.io/networking/openstack/ipv6 would help you? In particular, given that you have no route, perhaps you need the accept_ra config. > > Best wishes, > > Neil > > On Tue, Sep 20, 2022 at 9:12 AM Michael Hazan wrote: > >> Hello, >> >> The 3 nodes are running Ubuntu 20.04 and using libvirt. The instance are Ubuntu or debian based. The openstack virtual network is configured with both a v4 and a v6 dhcp pool. The instance should be getting both v4 and v6 (on the same interface) but the instance that are hosted on the compute node only get v4. If i run the dhclient -6 -r the instance actually get it's ipv6 but it's wrongly configured with a /128 (instead of 64) and no route. >> >> Michael >> >> DE : Lajos Katona >> ENVOY? LE :mardi, 20 septembre 2022 09:39 >> ? : mhazan at mandint.org >> CC : openstack-discuss at lists.openstack.org >> OBJET :Re: [neutron][nova][ipv6]instance on compute node not getting dhcpv6 >> >> Hi, >> >> Do you have some more details of your environment, which backend you use? OVS? >> >> Your VMs have both IPv4 and v6 addresses and you mean that they got IPv4 as expected? >> >> Lajos >> >> ezt ?rta (id?pont: 2022. szept. 19., H, 16:19): >> >> Hello all, >> >> i manage a small openstack cluster installed via Ubuntu package, it has >> been upgraded since the day of Newton and currently running Victoria. it >> started as a single node with the basic services installed, later a >> dedicated storage node and compute node were added. after upgrading to >> victoria, any instance that boot on the dedicated compute node start up >> but fails to get it's global ipv6 via stateful dhcp6, only >> linklocal(fe80) ip is shown by the instance. The ipv6 is created in >> openstack, the dhcpv4 works and there are no issue if the instance boot >> on the "old" all in one node. i can manually allocate (by editing the >> instance network config file) the ipv6 config and it works. any pointer >> as to what could cause this issue ? >> >> BR, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From senrique at redhat.com Wed Sep 21 11:00:00 2022 From: senrique at redhat.com (Sofia Enriquez) Date: Wed, 21 Sep 2022 08:00:00 -0300 Subject: [cinder] Bug Report 09-21-2022 Message-ID: This is a bug report from 09-14-2022 to 09-21-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Medium - https://bugs.launchpad.net/cinder/+bug/1989514 "NFS volume snapshot does not update volume attachment format to qcow2." Fix proposed to master. Low - https://bugs.launchpad.net/cinder/+bug/1989730 "Dell PowerMax - Optimized SL should be assigned when retyping a volume to a default volume type." Fixed proposed to master. - https://bugs.launchpad.net/cinder/+bug/1990136 " Dell PowerFlex: Failed to attach a volume when using self-signed Certificates." Fixed proposed to master. - https://bugs.launchpad.net/cinder/+bug/1990134 "Tatlin driver does not set project id for temp volumes." Fixed proposed to master. -- Sof?a Enriquez she/her Software Engineer Red Hat PnT IRC: @enriquetaso @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From amy at demarco.com Wed Sep 21 12:20:46 2022 From: amy at demarco.com (Amy Marrich) Date: Wed, 21 Sep 2022 07:20:46 -0500 Subject: [all][elections][tc][ptl] Antelope: Technical Committee & PTL Election Conclusion & Results In-Reply-To: References: Message-ID: Congrats to new and returning OpenStack leadership! Amy On Tue, Sep 20, 2022 at 10:06 AM Ian Y. Choi wrote: > Thank you to the electorate, to all those who voted and to all candidates > who put their name forward for Technical Committee (TC) & Project Team Lead > (PTL) in this election. A healthy, open process breeds trust in our > decision making capability thank you to all those who make this process > possible. > > 1. Please join me in congratulating the 4 newly elected members of the TC: > Dan Smith (dansmith)Ghanshyam Mann (gmann)Jay Faulkner (JayF)Dmitriy > Rabotyagov (noonedeadpunk) > Full results: > https://civs1.civs.us/cgi-bin/results.pl?id=E_41d42603087bcf58 > 2. For the results of the PTL election process, please join me in > extending congratulations to the following PTLs: > * Barbican : Grzegorz Grasza (xek)* Blazar : Pierre > Riteau (priteau)* Cinder : Rajat Dhasmana ()* Cloudkitty > : Rafael Weingartner ()* Cyborg : alex song ()* Designate > : Michael Johnson (johnsom)* Ec2 Api : Andrey Pavlov > (andrey-mp)* Freezer : ge cong ()* Glance : Pranali > Deore (pdeore)* Heat : Brendan Shephard ()* Horizon > : Vishal Manchanda (vishalmanchanda)* Ironic : Jay Faulkner > (JayF)* Kolla : Michal Nasiadka (mnasiadka)* Kuryr > : Roman Dobosz (gryf)* Magnum : Jake Yip (jakeyip)* Manila > : Carlos Silva (carloss)* Monasca : Martin Chacon Piza > (chaconpiza)* Murano : Rong Zhu (zhurong)* Neutron : > Rodolfo Alonso Hernandez ()* Nova : Sylvain Bauza (bauzas)* > Octavia : Gregory Thiemonge (gthiemonge)* Openstack Chef : > Lance Albertson (Ramereth)* OpenStack Helm : Gage Hugo (gagehugo)* > OpenStackAnsible : Dmitriy Rabotyagov (noonedeadpunk)* OpenStackSDK : > Artem Goncharov (gtema)* Puppet OpenStack : Takashi Kajinami (tkajinam)* > Quality Assurance : Martin Kopec (kopecmartin)* Rally : Andrey > Kurilin (andreykurilin)* Skyline : Wenxiang Wu (wu_wenxiang)* > Solum : Rong Zhu (zhurong)* Storlets : Takashi > Kajinami (tkajinam)* Tacker : Yasufumi Ogawa (yasufum)* > Telemetry : Matthias Runge (mrunge)* Tripleo : Rabi > Mishra (ramishra)* Trove : wu chunyang (wuchunyang)* Vitrage > : Eyal Bar-Ilan ()* Watcher : chen ke ()* Winstackers > : Lucian Petrut ()* Zaqar : Hao Wang () > PTL Election:* Ironic: > https://civs1.civs.us/cgi-bin/results.pl?id=E_c7d81a19f30c67f0 > Election process details and results are also available here: > https://governance.openstack.org/election/ > Thank you to all of the candidates, having a good group of candidates > helps engage the community in our democratic process. > Thank you to all who voted and who encouraged others to vote. We need to > ensure your voice is heard. > Thank you for another great round. > > Ian Y. Choi, on behalf of the OpenStack Technical Election Officials > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnsomor at gmail.com Wed Sep 21 17:05:00 2022 From: johnsomor at gmail.com (Michael Johnson) Date: Wed, 21 Sep 2022 10:05:00 -0700 Subject: Floating IP attached to octavia not working | tripleo wallaby | centos | OVN DVR In-Reply-To: References: Message-ID: The issue you referenced was fixed here: https://review.opendev.org/c/openstack/networking-ovn/+/592538/ I would suspect this is a new OVN related bug, I would recommend opening a neutron bug on launchpad to track it. https://bugs.launchpad.net/neutron Michael On Tue, Sep 20, 2022 at 12:48 PM Swogat Pradhan wrote: > > Hi, > > I've deployed Octavia + OVN + DVR and floating IPs assigned to Octavia VIPs are not reachable. > > Other floating IPs tied to nova instances are working fine. > The octavia vip is reachable and working fine from inside on the private network, however the Floating IP is not reachable at all. > > I found a similar issue in bugzilla but the bug is closed now and i do not have any solution. > > https://bugzilla.redhat.com/show_bug.cgi?id=1608951 > > > Please help me get a solution for this issue. > > > With regards, > > Swogat pradhan > > From ralonsoh at redhat.com Wed Sep 21 17:13:03 2022 From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez) Date: Wed, 21 Sep 2022 19:13:03 +0200 Subject: OpenStack PTG, Neutron schedule Message-ID: Hello Neutrinos: This is the poll to vote for the Neutron schedule during the next OpenStack PTG. The goal is to have at least 3 hours per day, from Monday to Thursday. The second poll is to decide the operator hour for Neutron [2], according to [3]. I'll keep the polls open until next Monday 26 Sep. Then I'll reserve the room in [3]. Thank you for participating. [1]https://doodle.com/meeting/participate/id/dwmlAVra [2]https://doodle.com/meeting/participate/id/eZVRoxge [3]https://ptg.opendev.org/ptg.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Wed Sep 21 19:12:33 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 21 Sep 2022 12:12:33 -0700 Subject: [openstack-announce] [all][elections][tc][ptl] Antelope: Technical Committee & PTL Election Conclusion & Results In-Reply-To: References: Message-ID: <18361775358.107252dfd264109.3709678930550465385@ghanshyammann.com> Thanks to all the leaders (PTL, TC) for their nominations which shows the good leadership pool in OpenStack. Welcome returning and new TC members. Thanks to James and Chandan for TC nomination, its good to see more members interested to contribute as TC. -gmann ---- On Tue, 20 Sep 2022 08:03:01 -0700 Ian Y. Choi wrote --- > (Re-sending?with better formatting) > Thank you to the electorate, to all those who voted and to all candidates who put their name forward for Technical Committee (TC) & Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible. > > 1. Please join me in congratulating the 4 newly elected members of the TC: > > Dan Smith (dansmith) > Ghanshyam Mann (gmann) > Jay Faulkner (JayF) > Dmitriy Rabotyagov (noonedeadpunk) > > Full results: > https://civs1.civs.us/cgi-bin/results.pl?id=E_41d42603087bcf58 > > 2. For the results of the PTL election process, please join me in extending congratulations to the following PTLs: > > * Barbican ? ? ? ? ?: Grzegorz Grasza (xek) > * Blazar ? ? ? ? ? ?: Pierre Riteau (priteau) > * Cinder ? ? ? ? ? ?: Rajat Dhasmana () > * Cloudkitty ? ? ? ?: Rafael Weingartner () > * Cyborg ? ? ? ? ? ?: alex song () > * Designate ? ? ? ? : Michael Johnson (johnsom) > * Ec2 Api ? ? ? ? ? : Andrey Pavlov (andrey-mp) > * Freezer ? ? ? ? ? : ge cong () > * Glance ? ? ? ? ? ?: Pranali Deore (pdeore) > * Heat ? ? ? ? ? ? ?: Brendan Shephard () > * Horizon ? ? ? ? ? : Vishal Manchanda (vishalmanchanda) > * Ironic ? ? ? ? ? ?: Jay Faulkner (JayF) > * Kolla ? ? ? ? ? ? : Michal Nasiadka (mnasiadka) > * Kuryr ? ? ? ? ? ? : Roman Dobosz (gryf) > * Magnum ? ? ? ? ? ?: Jake Yip (jakeyip) > * Manila ? ? ? ? ? ?: Carlos Silva (carloss) > * Monasca ? ? ? ? ? : Martin Chacon Piza (chaconpiza) > * Murano ? ? ? ? ? ?: Rong Zhu (zhurong) > * Neutron ? ? ? ? ? : Rodolfo Alonso Hernandez () > * Nova ? ? ? ? ? ? ?: Sylvain Bauza (bauzas) > * Octavia ? ? ? ? ? : Gregory Thiemonge (gthiemonge) > * Openstack Chef ? ?: Lance Albertson (Ramereth) > * OpenStack Helm ? ?: Gage Hugo (gagehugo) > * OpenStackAnsible ?: Dmitriy Rabotyagov (noonedeadpunk) > * OpenStackSDK ? ? ?: Artem Goncharov (gtema) > * Puppet OpenStack ?: Takashi Kajinami (tkajinam) > * Quality Assurance : Martin Kopec (kopecmartin) > * Rally ? ? ? ? ? ? : Andrey Kurilin (andreykurilin) > * Skyline ? ? ? ? ? : Wenxiang Wu (wu_wenxiang) > * Solum ? ? ? ? ? ? : Rong Zhu (zhurong) > * Storlets ? ? ? ? ?: Takashi Kajinami (tkajinam) > * Tacker ? ? ? ? ? ?: Yasufumi Ogawa (yasufum) > * Telemetry ? ? ? ? : Matthias Runge (mrunge) > * Tripleo ? ? ? ? ? : Rabi Mishra (ramishra) > * Trove ? ? ? ? ? ? : wu chunyang (wuchunyang) > * Vitrage ? ? ? ? ? : Eyal Bar-Ilan () > * Watcher ? ? ? ? ? : chen ke () > * Winstackers ? ? ? : Lucian Petrut () > * Zaqar ? ? ? ? ? ? : Hao Wang () > > PTL Election: > * Ironic: https://civs1.civs.us/cgi-bin/results.pl?id=E_c7d81a19f30c67f0 > > Election process details and results are also available here: https://governance.openstack.org/election/ > > Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. > > Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. > > Thank you for another great round. > > > Ian Y. Choi, on behalf of the OpenStack Technical Election Officials > > On Tue, Sep 20, 2022 at 11:57 PM Ian Y. Choi ianyrchoi at gmail.com> wrote: > _______________________________________________ > OpenStack-announce mailing list > OpenStack-announce at lists.openstack.org > https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce > Thank you to the electorate, to all those who voted and to all candidates who put their name forward for Technical Committee (TC) & Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible. > > 1. Please join me in congratulating the 4 newly elected members of the TC: > Dan Smith (dansmith)Ghanshyam Mann (gmann)Jay Faulkner (JayF)Dmitriy Rabotyagov (noonedeadpunk) > Full results:https://civs1.civs.us/cgi-bin/results.pl?id=E_41d42603087bcf58 > 2. For the results of the PTL election process, please join me in extending congratulations to the following PTLs: > * Barbican ? ? ? ? ?: Grzegorz Grasza (xek)* Blazar ? ? ? ? ? ?: Pierre Riteau (priteau)* Cinder ? ? ? ? ? ?: Rajat Dhasmana ()* Cloudkitty ? ? ? ?: Rafael Weingartner ()* Cyborg ? ? ? ? ? ?: alex song ()* Designate ? ? ? ? : Michael Johnson (johnsom)* Ec2 Api ? ? ? ? ? : Andrey Pavlov (andrey-mp)* Freezer ? ? ? ? ? : ge cong ()* Glance ? ? ? ? ? ?: Pranali Deore (pdeore)* Heat ? ? ? ? ? ? ?: Brendan Shephard ()* Horizon ? ? ? ? ? : Vishal Manchanda (vishalmanchanda)* Ironic ? ? ? ? ? ?: Jay Faulkner (JayF)* Kolla ? ? ? ? ? ? : Michal Nasiadka (mnasiadka)* Kuryr ? ? ? ? ? ? : Roman Dobosz (gryf)* Magnum ? ? ? ? ? ?: Jake Yip (jakeyip)* Manila ? ? ? ? ? ?: Carlos Silva (carloss)* Monasca ? ? ? ? ? : Martin Chacon Piza (chaconpiza)* Murano ? ? ? ? ? ?: Rong Zhu (zhurong)* Neutron ? ? ? ? ? : Rodolfo Alonso Hernandez ()* Nova ? ? ? ? ? ? ?: Sylvain Bauza (bauzas)* Octavia ? ? ? ? ? : Gregory Thiemonge (gthiemonge)* Openstack Chef ? ?: Lance Albertson (Ramereth)* OpenStack Helm ? ?: Gage Hugo (gagehugo)* OpenStackAnsible ?: Dmitriy Rabotyagov (noonedeadpunk)* OpenStackSDK ? ? ?: Artem Goncharov (gtema)* Puppet OpenStack ?: Takashi Kajinami (tkajinam)* Quality Assurance : Martin Kopec (kopecmartin)* Rally ? ? ? ? ? ? : Andrey Kurilin (andreykurilin)* Skyline ? ? ? ? ? : Wenxiang Wu (wu_wenxiang)* Solum ? ? ? ? ? ? : Rong Zhu (zhurong)* Storlets ? ? ? ? ?: Takashi Kajinami (tkajinam)* Tacker ? ? ? ? ? ?: Yasufumi Ogawa (yasufum)* Telemetry ? ? ? ? : Matthias Runge (mrunge)* Tripleo ? ? ? ? ? : Rabi Mishra (ramishra)* Trove ? ? ? ? ? ? : wu chunyang (wuchunyang)* Vitrage ? ? ? ? ? : Eyal Bar-Ilan ()* Watcher ? ? ? ? ? : chen ke ()* Winstackers ? ? ? : Lucian Petrut ()* Zaqar ? ? ? ? ? ? : Hao Wang () > PTL Election:* Ironic: https://civs1.civs.us/cgi-bin/results.pl?id=E_c7d81a19f30c67f0 > Election process details and results are also available here: https://governance.openstack.org/election/ > Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. > Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. > Thank you for another great round. > > Ian Y. Choi, on behalf of the OpenStack Technical Election Officials From mkopec at redhat.com Wed Sep 21 22:46:45 2022 From: mkopec at redhat.com (Martin Kopec) Date: Thu, 22 Sep 2022 00:46:45 +0200 Subject: [qa][ptg] Virtual PTG Planning Message-ID: Hello everyone, here is [1] our etherpad for Antelope PTG. Please, add your topics there if there is anything you would like to discuss / propose ... You can also vote for time slots of our sessions so that they fit your schedule at [2]. We will go with 3 maybe 4 one hour slots, depending on the number of topics. [1] https://etherpad.opendev.org/p/qa-antelope-ptg [2] https://framadate.org/dC2AEBTq8b5rAkvv Thanks, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA IM: kopecmartin -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Thu Sep 22 05:58:15 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 21 Sep 2022 22:58:15 -0700 Subject: [all][tc] Technical Committee next weekly meeting on 2022 Sept 22 at 1500 UTC Message-ID: <18363c67a62.10d04ab73273037.8847472280626653475@ghanshyammann.com> Hello Everyone, Below is the agenda for tomorrow's TC meeting schedule at 1500 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting * Roll call * Follow up on past action items * Gate health check ** Bare 'recheck' state *** https://etherpad.opendev.org/p/recheck-weekly-summary * Zed cycle tracker checks ** https://etherpad.opendev.org/p/tc-zed-tracker * 2023.1 cycle PTG Planning ** TC + Leaders interaction sessions *** https://etherpad.opendev.org/p/tc-leaders-interaction-2023-1 ** TC PTG etherpad *** https://etherpad.opendev.org/p/tc-2023-1-ptg ** Schedule 'operator hours' *** https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030301.html * 2023.1 cycle Technical Election & Leaderless projects ** https://governance.openstack.org/election/ ** https://etherpad.opendev.org/p/2023.1-leaderless ** https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030437.html * Meeting time check ** We have new TC members. Let's check if the current meeting time is ok for everyone. * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open -gmann From ltomasbo at redhat.com Thu Sep 22 06:12:39 2022 From: ltomasbo at redhat.com (Luis Tomas Bolivar) Date: Thu, 22 Sep 2022 08:12:39 +0200 Subject: Floating IP attached to octavia not working | tripleo wallaby | centos | OVN DVR In-Reply-To: References: Message-ID: Is this an ovn load balancer or an amphora loadbalancer? On Wed, Sep 21, 2022 at 7:11 PM Michael Johnson wrote: > The issue you referenced was fixed here: > https://review.opendev.org/c/openstack/networking-ovn/+/592538/ > > I would suspect this is a new OVN related bug, I would recommend > opening a neutron bug on launchpad to track it. > > https://bugs.launchpad.net/neutron > > Michael > > On Tue, Sep 20, 2022 at 12:48 PM Swogat Pradhan > wrote: > > > > Hi, > > > > I've deployed Octavia + OVN + DVR and floating IPs assigned to Octavia > VIPs are not reachable. > > > > Other floating IPs tied to nova instances are working fine. > > The octavia vip is reachable and working fine from inside on the private > network, however the Floating IP is not reachable at all. > > > > I found a similar issue in bugzilla but the bug is closed now and i do > not have any solution. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1608951 > > > > > > Please help me get a solution for this issue. > > > > > > With regards, > > > > Swogat pradhan > > > > > > -- LUIS TOM?S BOL?VAR Principal Software Engineer Red Hat Madrid, Spain ltomasbo at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kkchn.in at gmail.com Thu Sep 22 06:23:09 2022 From: kkchn.in at gmail.com (KK CHN) Date: Thu, 22 Sep 2022 11:53:09 +0530 Subject: cloud Stack Testing Message-ID: List, We have deployed Openstack wallaby using kolla-ansible openstack installation . The setup is up and running with default configurations all-in-one node ... Reference: https://docs.openstack.org/project-deploy-guide/kolla-ansible/wallaby/quickstart.html 1. We need to test this cloud stack for Compute, Network, and storage able to scale across multiple local and remote zones. What other components/configurations needed to be configured /built for this purpose? What are the testing parameters to check the above setup scale across multiple local and remote zones? or what methods/procedures need to be performed for this testing ? 2. for Successful deployment of enterprise applications having enough scaling and availability requirements in each IaaS, SaaS & PaaS category may further help in evaluating this setup across these categories. Is there any such kind of benchmarking tools or sample application/s to test the capacity to kindly share the name/details of such application/s to deploy as PoC? Any help/hints much appreciated. Thanks in advance, Krish -------------- next part -------------- An HTML attachment was scrubbed... URL: From vmudemela at gmail.com Thu Sep 22 07:18:13 2022 From: vmudemela at gmail.com (Vish Mudemela) Date: Thu, 22 Sep 2022 00:18:13 -0700 Subject: cloud Stack Testing In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: favicon.ico Type: image/png Size: 338 bytes Desc: not available URL: From geguileo at redhat.com Thu Sep 22 09:03:19 2022 From: geguileo at redhat.com (Gorka Eguileor) Date: Thu, 22 Sep 2022 11:03:19 +0200 Subject: [openstack][quuens][cinder] consistency groups bug ? In-Reply-To: References: Message-ID: <20220922090319.nne6ns3qsmkgaaq4@localhost> On 03/09, Ignazio Cassano wrote: > Hello, > some updates. > The issue appears also using volume group instead of consistency groups. > Ignazio > Hi, Consistency Groups do not work across Cinder backends: - Backends from different drivers/vendors. - Backends from different storage arrays in different geographic locations I don't know if there's a way to make it "work" with generic groups, but if it were possible it would probably just loop over the volumes and take individual snapshots, as I don't think it's implemented the option of having multiple consistency groups (1 per backend) and doing 1 snapshot request per backend. Cheers, Gorka. > > Il giorno ven 2 set 2022 alle ore 19:06 Ignazio Cassano < > ignaziocassano at gmail.com> ha scritto: > > > Hi everyone, in my openstack installation, for performance reasons, I use > > a cinder type to address different storage virtual machines on the same > > device. Balancing takes place via the scheduler. Below is an example of > > my configuration in cinder.conf: > > > > https://paste.openstack.org/show/b0hCTsdniLhinoQiVT7A/ > > > > As you can see nfsgold1 to nfsgold8 are all part of the volume type > > nfsgold. > > Unfortunately if I create a consistency group with volume type nfsgold, it > > can only contain volumes on the same backend, even though they are of the > > same type. For example, if in my consistency group there is a volume on > > nfsgold1 and I add a volume present on nfsgold8 I get the following: > > > > https://paste.openstack.org/show/b4XnUeGDF5wYlCBLTcuc/ > > > > > > Any help, please ? > > Ignazio > > From geguileo at redhat.com Thu Sep 22 09:10:04 2022 From: geguileo at redhat.com (Gorka Eguileor) Date: Thu, 22 Sep 2022 11:10:04 +0200 Subject: Cinder-volume active active setup In-Reply-To: <20220831152521.Horde.J3_STEHgChGGhiQ5On3wH_1@webmail.nde.ag> References: <20220830110408.Horde.JzrsPeWuptf080t_8QXR1Sh@webmail.nde.ag> <20220831152521.Horde.J3_STEHgChGGhiQ5On3wH_1@webmail.nde.ag> Message-ID: <20220922091004.6oltnw3racvxelz7@localhost> On 31/08, Eugen Block wrote: > I think I found my answers. Currently I only have a single-control node in > my test lab but I'll redeploy it with three control nodes and test it with > zookeeper. With a single control node the zookeeper and cinder cluster > config seem to work. > Hi Eugen, Besides deploying the DLM, configuring it in Cinder, and setting the `cluser` configuration option you should also be careful with the `host`/`backend_host` configuration option. In Active-Passive deployments we set the `backend_host` configuration option so it is preserved when cinder-volume fails over to a different controller host, but in Active-Active we actually want each host to have cinder-volume running with different values, so we usually leave it unset so it takes the controller's host name. Changing a deployment from Active-Passive to Active-Active is a bit trickier, because you need to leave one of the cinder-volume services running (at least once) with the old `backend_host` so it can "move" resources (volumes/snapshots) to the "cluster". Cheers, Gorka. > Zitat von Eugen Block : > > > Hi, > > > > I didn't mean to hijack the other thread so I'll start a new one. > > There are some pages I found incl. Gorkas article [1], but I don't > > really understand yet how to configure it. > > > > We don't use any of the automated deployments (we created our own) like > > TripleO etc., is there any guide showing how to setup cinder-volume > > active/active? I see in my lab environment that python3-tooz is already > > installed on the control node, but how do I use it? Besides the > > "cluster" config option in the cinder.conf (is that defined when setting > > up the DLM?) what else is required? I also found this thread [2] > > pointing to the source code, but that doesn't really help me at this > > point. Any pointers to a how-to or deployment guide would be highly > > appreciated! > > > > Thanks, > > Eugen > > > > [1] https://gorka.eguileor.com/a-cinder-road-to-activeactive-ha/ > > [2] https://www.mail-archive.com/openstack at lists.openstack.org/msg18385.html > > > > From ignaziocassano at gmail.com Thu Sep 22 09:17:54 2022 From: ignaziocassano at gmail.com (Ignazio Cassano) Date: Thu, 22 Sep 2022 11:17:54 +0200 Subject: [openstack][quuens][cinder] consistency groups bug ? In-Reply-To: <20220922090319.nne6ns3qsmkgaaq4@localhost> References: <20220922090319.nne6ns3qsmkgaaq4@localhost> Message-ID: Thanks for the feedback! Il giorno gio 22 set 2022 alle ore 11:03 Gorka Eguileor ha scritto: > On 03/09, Ignazio Cassano wrote: > > Hello, > > some updates. > > The issue appears also using volume group instead of consistency groups. > > Ignazio > > > > Hi, > > Consistency Groups do not work across Cinder backends: > > - Backends from different drivers/vendors. > > - Backends from different storage arrays in different geographic > locations > > I don't know if there's a way to make it "work" with generic groups, but > if it were possible it would probably just loop over the volumes and > take individual snapshots, as I don't think it's implemented the option > of having multiple consistency groups (1 per backend) and doing 1 > snapshot request per backend. > > Cheers, > Gorka. > > > > > Il giorno ven 2 set 2022 alle ore 19:06 Ignazio Cassano < > > ignaziocassano at gmail.com> ha scritto: > > > > > Hi everyone, in my openstack installation, for performance reasons, I > use > > > a cinder type to address different storage virtual machines on the same > > > device. Balancing takes place via the scheduler. Below is an example of > > > my configuration in cinder.conf: > > > > > > https://paste.openstack.org/show/b0hCTsdniLhinoQiVT7A/ > > > > > > As you can see nfsgold1 to nfsgold8 are all part of the volume type > > > nfsgold. > > > Unfortunately if I create a consistency group with volume type > nfsgold, it > > > can only contain volumes on the same backend, even though they are of > the > > > same type. For example, if in my consistency group there is a volume on > > > nfsgold1 and I add a volume present on nfsgold8 I get the following: > > > > > > https://paste.openstack.org/show/b4XnUeGDF5wYlCBLTcuc/ > > > > > > > > > Any help, please ? > > > Ignazio > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmeng at redhat.com Thu Sep 22 09:27:52 2022 From: jmeng at redhat.com (Jakob Meng) Date: Thu, 22 Sep 2022 11:27:52 +0200 Subject: [ansible-os-modules] Antelope PTG in October | Ansible OpenStack Collection Message-ID: <0d849b28-6a34-17aa-d3ff-d2909535dc32@redhat.com> Hi everyone, we have scheduled our Antelope's vPTG session for the Ansible OpenStack Collection [1] at the same time and place as in April: at 13:00 - 15:00 UTC on Thursday October 20, 2022 in Essex room. Topics will be our migration progress to openstacksdk's first major release, new features, notable changes and open todos. Do not hesitate to add any questions and topics you want to address in our PTG session to etherpad [2]. Looking forward to meet you ?? [1] https://opendev.org/openstack/ansible-collections-openstack [2] https://etherpad.opendev.org/p/oct2022-ptg-os-ansible-modules Thanks, Ananya, Arx, Rafael, Sagi and Jakob From swogatpradhan22 at gmail.com Thu Sep 22 10:51:54 2022 From: swogatpradhan22 at gmail.com (Swogat Pradhan) Date: Thu, 22 Sep 2022 16:21:54 +0530 Subject: Floating IP attached to octavia not working | tripleo wallaby | centos | OVN DVR In-Reply-To: References: Message-ID: It;s an amphora loadbalancer On Thu, Sep 22, 2022 at 11:42 AM Luis Tomas Bolivar wrote: > Is this an ovn load balancer or an amphora loadbalancer? > > On Wed, Sep 21, 2022 at 7:11 PM Michael Johnson > wrote: > >> The issue you referenced was fixed here: >> https://review.opendev.org/c/openstack/networking-ovn/+/592538/ >> >> I would suspect this is a new OVN related bug, I would recommend >> opening a neutron bug on launchpad to track it. >> >> https://bugs.launchpad.net/neutron >> >> Michael >> >> On Tue, Sep 20, 2022 at 12:48 PM Swogat Pradhan >> wrote: >> > >> > Hi, >> > >> > I've deployed Octavia + OVN + DVR and floating IPs assigned to Octavia >> VIPs are not reachable. >> > >> > Other floating IPs tied to nova instances are working fine. >> > The octavia vip is reachable and working fine from inside on the >> private network, however the Floating IP is not reachable at all. >> > >> > I found a similar issue in bugzilla but the bug is closed now and i do >> not have any solution. >> > >> > https://bugzilla.redhat.com/show_bug.cgi?id=1608951 >> > >> > >> > Please help me get a solution for this issue. >> > >> > >> > With regards, >> > >> > Swogat pradhan >> > >> > >> >> > > -- > LUIS TOM?S BOL?VAR > Principal Software Engineer > Red Hat > Madrid, Spain > ltomasbo at redhat.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eblock at nde.ag Thu Sep 22 11:00:19 2022 From: eblock at nde.ag (Eugen Block) Date: Thu, 22 Sep 2022 11:00:19 +0000 Subject: Cinder-volume active active setup In-Reply-To: <20220922091004.6oltnw3racvxelz7@localhost> References: <20220830110408.Horde.JzrsPeWuptf080t_8QXR1Sh@webmail.nde.ag> <20220831152521.Horde.J3_STEHgChGGhiQ5On3wH_1@webmail.nde.ag> <20220922091004.6oltnw3racvxelz7@localhost> Message-ID: <20220922110019.Horde.33vsYAsDVQ6wuro21EKCeue@webmail.nde.ag> Hi, thanks for the clarification. We don't set "backend_host" at all at the moment, only "host" to the virtual hostname which has the virtual IP assigned by pacemaker. This seems to work fine. > Changing a deployment from Active-Passive to Active-Active is a bit > trickier, because you need to leave one of the cinder-volume services > running (at least once) with the old `backend_host` so it can "move" > resources (volumes/snapshots) to the "cluster". I'm not sure if we'll even try that, I was thinking more about new deployments that would be using active/active from the beginning. If we decided to switch we'd test it heavily before chaning anything. ;-) Thanks again! Eugen Zitat von Gorka Eguileor : > On 31/08, Eugen Block wrote: >> I think I found my answers. Currently I only have a single-control node in >> my test lab but I'll redeploy it with three control nodes and test it with >> zookeeper. With a single control node the zookeeper and cinder cluster >> config seem to work. >> > > Hi Eugen, > > Besides deploying the DLM, configuring it in Cinder, and setting the > `cluser` configuration option you should also be careful with the > `host`/`backend_host` configuration option. > > In Active-Passive deployments we set the `backend_host` configuration > option so it is preserved when cinder-volume fails over to a different > controller host, but in Active-Active we actually want each host to have > cinder-volume running with different values, so we usually leave it > unset so it takes the controller's host name. > > Changing a deployment from Active-Passive to Active-Active is a bit > trickier, because you need to leave one of the cinder-volume services > running (at least once) with the old `backend_host` so it can "move" > resources (volumes/snapshots) to the "cluster". > > Cheers, > Gorka. > >> Zitat von Eugen Block : >> >> > Hi, >> > >> > I didn't mean to hijack the other thread so I'll start a new one. >> > There are some pages I found incl. Gorkas article [1], but I don't >> > really understand yet how to configure it. >> > >> > We don't use any of the automated deployments (we created our own) like >> > TripleO etc., is there any guide showing how to setup cinder-volume >> > active/active? I see in my lab environment that python3-tooz is already >> > installed on the control node, but how do I use it? Besides the >> > "cluster" config option in the cinder.conf (is that defined when setting >> > up the DLM?) what else is required? I also found this thread [2] >> > pointing to the source code, but that doesn't really help me at this >> > point. Any pointers to a how-to or deployment guide would be highly >> > appreciated! >> > >> > Thanks, >> > Eugen >> > >> > [1] https://gorka.eguileor.com/a-cinder-road-to-activeactive-ha/ >> > [2] >> https://www.mail-archive.com/openstack at lists.openstack.org/msg18385.html >> >> >> >> From geguileo at redhat.com Thu Sep 22 11:15:54 2022 From: geguileo at redhat.com (Gorka Eguileor) Date: Thu, 22 Sep 2022 13:15:54 +0200 Subject: Cinder-volume active active setup In-Reply-To: <20220922110019.Horde.33vsYAsDVQ6wuro21EKCeue@webmail.nde.ag> References: <20220830110408.Horde.JzrsPeWuptf080t_8QXR1Sh@webmail.nde.ag> <20220831152521.Horde.J3_STEHgChGGhiQ5On3wH_1@webmail.nde.ag> <20220922091004.6oltnw3racvxelz7@localhost> <20220922110019.Horde.33vsYAsDVQ6wuro21EKCeue@webmail.nde.ag> Message-ID: <20220922111554.ovswtdo4ibrc222s@localhost> On 22/09, Eugen Block wrote: > Hi, > > thanks for the clarification. > We don't set "backend_host" at all at the moment, only "host" to the virtual > hostname which has the virtual IP assigned by pacemaker. This seems to work > fine. Hi, I assume than in an Active-Active deployment you won't be using pacemaker, and in that case I would not define "host" at all. Cheers, Gorka. > > > Changing a deployment from Active-Passive to Active-Active is a bit > > trickier, because you need to leave one of the cinder-volume services > > running (at least once) with the old `backend_host` so it can "move" > > resources (volumes/snapshots) to the "cluster". > > I'm not sure if we'll even try that, I was thinking more about new > deployments that would be using active/active from the beginning. If we > decided to switch we'd test it heavily before chaning anything. ;-) > > Thanks again! > Eugen > > Zitat von Gorka Eguileor : > > > On 31/08, Eugen Block wrote: > > > I think I found my answers. Currently I only have a single-control node in > > > my test lab but I'll redeploy it with three control nodes and test it with > > > zookeeper. With a single control node the zookeeper and cinder cluster > > > config seem to work. > > > > > > > Hi Eugen, > > > > Besides deploying the DLM, configuring it in Cinder, and setting the > > `cluser` configuration option you should also be careful with the > > `host`/`backend_host` configuration option. > > > > In Active-Passive deployments we set the `backend_host` configuration > > option so it is preserved when cinder-volume fails over to a different > > controller host, but in Active-Active we actually want each host to have > > cinder-volume running with different values, so we usually leave it > > unset so it takes the controller's host name. > > > > Changing a deployment from Active-Passive to Active-Active is a bit > > trickier, because you need to leave one of the cinder-volume services > > running (at least once) with the old `backend_host` so it can "move" > > resources (volumes/snapshots) to the "cluster". > > > > Cheers, > > Gorka. > > > > > Zitat von Eugen Block : > > > > > > > Hi, > > > > > > > > I didn't mean to hijack the other thread so I'll start a new one. > > > > There are some pages I found incl. Gorkas article [1], but I don't > > > > really understand yet how to configure it. > > > > > > > > We don't use any of the automated deployments (we created our own) like > > > > TripleO etc., is there any guide showing how to setup cinder-volume > > > > active/active? I see in my lab environment that python3-tooz is already > > > > installed on the control node, but how do I use it? Besides the > > > > "cluster" config option in the cinder.conf (is that defined when setting > > > > up the DLM?) what else is required? I also found this thread [2] > > > > pointing to the source code, but that doesn't really help me at this > > > > point. Any pointers to a how-to or deployment guide would be highly > > > > appreciated! > > > > > > > > Thanks, > > > > Eugen > > > > > > > > [1] https://gorka.eguileor.com/a-cinder-road-to-activeactive-ha/ > > > > [2] > > > https://www.mail-archive.com/openstack at lists.openstack.org/msg18385.html > > > > > > > > > > > > > > > From eblock at nde.ag Thu Sep 22 11:19:41 2022 From: eblock at nde.ag (Eugen Block) Date: Thu, 22 Sep 2022 11:19:41 +0000 Subject: Cinder-volume active active setup In-Reply-To: <20220922111554.ovswtdo4ibrc222s@localhost> References: <20220830110408.Horde.JzrsPeWuptf080t_8QXR1Sh@webmail.nde.ag> <20220831152521.Horde.J3_STEHgChGGhiQ5On3wH_1@webmail.nde.ag> <20220922091004.6oltnw3racvxelz7@localhost> <20220922110019.Horde.33vsYAsDVQ6wuro21EKCeue@webmail.nde.ag> <20220922111554.ovswtdo4ibrc222s@localhost> Message-ID: <20220922111941.Horde.AfeJpEkN5lznhc-sMdDUba5@webmail.nde.ag> Exactly, for cinder a/a we would remove it from pacemaker config (as recommended) and only define a cluster with zookeeper. I still didn't have the time to actually test it properly, but I definitely will. Zitat von Gorka Eguileor : > On 22/09, Eugen Block wrote: >> Hi, >> >> thanks for the clarification. >> We don't set "backend_host" at all at the moment, only "host" to the virtual >> hostname which has the virtual IP assigned by pacemaker. This seems to work >> fine. > > Hi, > > I assume than in an Active-Active deployment you won't be using > pacemaker, and in that case I would not define "host" at all. > > Cheers, > Gorka. > >> >> > Changing a deployment from Active-Passive to Active-Active is a bit >> > trickier, because you need to leave one of the cinder-volume services >> > running (at least once) with the old `backend_host` so it can "move" >> > resources (volumes/snapshots) to the "cluster". >> >> I'm not sure if we'll even try that, I was thinking more about new >> deployments that would be using active/active from the beginning. If we >> decided to switch we'd test it heavily before chaning anything. ;-) >> >> Thanks again! >> Eugen >> >> Zitat von Gorka Eguileor : >> >> > On 31/08, Eugen Block wrote: >> > > I think I found my answers. Currently I only have a >> single-control node in >> > > my test lab but I'll redeploy it with three control nodes and >> test it with >> > > zookeeper. With a single control node the zookeeper and cinder cluster >> > > config seem to work. >> > > >> > >> > Hi Eugen, >> > >> > Besides deploying the DLM, configuring it in Cinder, and setting the >> > `cluser` configuration option you should also be careful with the >> > `host`/`backend_host` configuration option. >> > >> > In Active-Passive deployments we set the `backend_host` configuration >> > option so it is preserved when cinder-volume fails over to a different >> > controller host, but in Active-Active we actually want each host to have >> > cinder-volume running with different values, so we usually leave it >> > unset so it takes the controller's host name. >> > >> > Changing a deployment from Active-Passive to Active-Active is a bit >> > trickier, because you need to leave one of the cinder-volume services >> > running (at least once) with the old `backend_host` so it can "move" >> > resources (volumes/snapshots) to the "cluster". >> > >> > Cheers, >> > Gorka. >> > >> > > Zitat von Eugen Block : >> > > >> > > > Hi, >> > > > >> > > > I didn't mean to hijack the other thread so I'll start a new one. >> > > > There are some pages I found incl. Gorkas article [1], but I don't >> > > > really understand yet how to configure it. >> > > > >> > > > We don't use any of the automated deployments (we created our >> own) like >> > > > TripleO etc., is there any guide showing how to setup cinder-volume >> > > > active/active? I see in my lab environment that python3-tooz >> is already >> > > > installed on the control node, but how do I use it? Besides the >> > > > "cluster" config option in the cinder.conf (is that defined >> when setting >> > > > up the DLM?) what else is required? I also found this thread [2] >> > > > pointing to the source code, but that doesn't really help me at this >> > > > point. Any pointers to a how-to or deployment guide would be highly >> > > > appreciated! >> > > > >> > > > Thanks, >> > > > Eugen >> > > > >> > > > [1] https://gorka.eguileor.com/a-cinder-road-to-activeactive-ha/ >> > > > [2] >> > > https://www.mail-archive.com/openstack at lists.openstack.org/msg18385.html >> > > >> > > >> > > >> > > >> >> >> From thomasmulhall410 at yahoo.com Thu Sep 22 11:49:06 2022 From: thomasmulhall410 at yahoo.com (Paladox) Date: Thu, 22 Sep 2022 11:49:06 +0000 (UTC) Subject: How do I disable replication in swift References: <1112921123.2169438.1663847346908.ref@mail.yahoo.com> Message-ID: <1112921123.2169438.1663847346908@mail.yahoo.com> Hello, I would like Swift to only have 1 file not any copies of it, how do I disable replication as you must set the value to 1 when you create the rings? (We don?t have the disk space to have replication / copies of the files) -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Thu Sep 22 15:55:20 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 22 Sep 2022 15:55:20 +0000 Subject: [dev][security-sig] Revisiting tarfile, or "What's old is new again" Message-ID: <20220922155519.xinmnlfmgewwqqnh@yuggoth.org> The tarfile module from Python's standard library is in the news this week, with people publicly exploiting the very long-standing CVE-2007-4559[0] (yes, you read that correctly, *2007*). Some old-timers in the community might remember this from such popular hits as OSSA-2011-001: Path traversal issues registering malicious images using EC2 API[1], our very first OpenStack Security Advisory! This revived interest in unsafe use of tarfile methods will undoubtedly have lots of people scanning OpenStack's Git repos looking for potentially exploitable calls. Indeed, some of our own community members are already auditing the collective codebase to make sure new vulnerabilities haven't sneaked in over the 11 years since this first came up for us, but more help is always welcome. I encourage anyone using tarfile in their projects to double-check you're doing so safely[2]. If you rely bandit to check your source code, be advised that the most recent 1.7.4 release doesn't catch this but you can install its main branch[3] instead which does include a check for it, at least until they tag a new release (which I have a feeling they'll do quite soon given the recent furor around this topic). On a related note, I want to take this opportunity to remind everyone that OpenStack has a Security Special Interest Group (SIG), which meets monthly[4] on IRC, and members will also be in attendance at the upcoming virtual PTG[5] in case anyone is interested in discussing this or similar subject matter. Our PTG slot is currently booked for 15:00 UTC Wednesday (2022-10-19), though we can adjust or book an additional hour at another time if this conflicts with any tracks people also need to join, just let me know. [0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4559 [1] https://security.openstack.org/ossa/OSSA-2011-001.html [2] https://docs.python.org/3/library/tarfile.html#tarfile.TarFile.extractall [3] https://github.com/pycqa/bandit [4] https://meetings.opendev.org/#OpenStack_Security_SIG_meeting [5] https://ptg.opendev.org/ptg.html -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From katonalala at gmail.com Thu Sep 22 16:22:57 2022 From: katonalala at gmail.com (Lajos Katona) Date: Thu, 22 Sep 2022 18:22:57 +0200 Subject: [neutron] Drivers meeting - Friday 22.09.2022 - cancelled Message-ID: 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) -------------- next part -------------- An HTML attachment was scrubbed... URL: From alsotoes at gmail.com Thu Sep 22 16:40:31 2022 From: alsotoes at gmail.com (Alvaro Soto) Date: Thu, 22 Sep 2022 11:40:31 -0500 Subject: How do I disable replication in swift In-Reply-To: <1112921123.2169438.1663847346908@mail.yahoo.com> References: <1112921123.2169438.1663847346908.ref@mail.yahoo.com> <1112921123.2169438.1663847346908@mail.yahoo.com> Message-ID: Check changing the replica counts https://docs.openstack.org/swift/xena/admin/objectstorage-ringbuilder.html#replica-counts --- Alvaro Soto. Note: My work hours may not be your work hours. Please do not feel the need to respond during a time that is not convenient for you. ---------------------------------------------------------- Great people talk about ideas, ordinary people talk about things, small people talk... about other people. On Thu, Sep 22, 2022, 6:54 AM Paladox wrote: > Hello, I would like Swift to only have 1 file not any copies of it, how do > I disable replication as you must set the value to 1 when you create the > rings? > > (We don?t have the disk space to have replication / copies of the files) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alsotoes at gmail.com Thu Sep 22 16:42:51 2022 From: alsotoes at gmail.com (Alvaro Soto) Date: Thu, 22 Sep 2022 11:42:51 -0500 Subject: How do I disable replication in swift In-Reply-To: References: <1112921123.2169438.1663847346908.ref@mail.yahoo.com> <1112921123.2169438.1663847346908@mail.yahoo.com> Message-ID: Btw, not a good idea.... Try to clean space first, but if you want to do this in the meantime you buy more disk/nodes 'maybe' you can work it out. --- Alvaro Soto. Note: My work hours may not be your work hours. Please do not feel the need to respond during a time that is not convenient for you. ---------------------------------------------------------- Great people talk about ideas, ordinary people talk about things, small people talk... about other people. On Thu, Sep 22, 2022, 11:40 AM Alvaro Soto wrote: > Check changing the replica counts > > > https://docs.openstack.org/swift/xena/admin/objectstorage-ringbuilder.html#replica-counts > > --- > Alvaro Soto. > > Note: My work hours may not be your work hours. Please do not feel the > need to respond during a time that is not convenient for you. > ---------------------------------------------------------- > Great people talk about ideas, > ordinary people talk about things, > small people talk... about other people. > > On Thu, Sep 22, 2022, 6:54 AM Paladox wrote: > >> Hello, I would like Swift to only have 1 file not any copies of it, how >> do I disable replication as you must set the value to 1 when you create the >> rings? >> >> (We don?t have the disk space to have replication / copies of the files) >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay at gr-oss.io Thu Sep 22 16:54:32 2022 From: jay at gr-oss.io (Jay Faulkner) Date: Thu, 22 Sep 2022 09:54:32 -0700 Subject: [nova][ironic][ptg] Improved ironic<>nova driver interactions session Message-ID: Hello Nova folks, At the Ironic PTG planning meeting this morning, discussion of improving Nova and Ironic driver interactions; and specifically this spec: https://review.opendev.org/c/openstack/nova-specs/+/842015/ came up. It's important for our teams to come together and reach consensus as to how to fix this. According to the latest OpenStack user survey ( https://www.openstack.org/analytics/) over 20% of Nova deployments utilize the Ironic driver. However, in my years operating Ironic for multiple different organizations, the Nova<>Ironic driver interface has repeatedly been the source of most operational pain. We should work together to prioritize saving these operators from downtime and bad failure semantics. I'd love for Ironic and Nova to schedule a session together to talk about this and try to find a solution. We owe it to our users to no longer shy away from this hard technical problem and fix things. What's the best way for us to get this time scheduled? Someone can feel free to reach out to me on IRC (JayF), or reply here and I'm sure we can work it out. Thanks in Advance, Jay Faulkner G-Research Open Source Software lab OpenStack Ironic PTL OpenStack Technical Committee member -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay at gr-oss.io Thu Sep 22 16:56:37 2022 From: jay at gr-oss.io (Jay Faulkner) Date: Thu, 22 Sep 2022 09:56:37 -0700 Subject: [ironic][ptg] Last call for topics Message-ID: This morning, a group of Ironic cores met and mapped out a rough schedule for our PTG sessions. Please review the etherpad here: https://etherpad.opendev.org/p/ironic-antelope-ptg for more details on the outcome of that. We did want to give one last chance for anyone who has not yet had a chance to add their topic to do so before the plans are finalized. Please add any additional topics to the etherpad, and preferably, also respond to this email or let us know in #openstack-ironic on IRC. Thanks, Jay Faulkner G-Research Open Source Software lab OpenStack Ironic PTL OpenStack Technical Committee member -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at andrewboring.com Thu Sep 22 16:57:25 2022 From: andrew at andrewboring.com (Andrew Boring) Date: Thu, 22 Sep 2022 12:57:25 -0400 Subject: Swift not recognizing mounted drives Message-ID: <2CA5E246-20C0-4244-A840-CB5A7B93FF2E@andrewboring.com> Hi all. I have a new Openstack Swift install, currently a single node with 12 disks running CentOS 8 Stream and Openstack Yoga / RDO release with Keystone Auth. Disks are formatted with xfs and mounted at /srv/node/sd[a-l] as described in the Install docs, but no Swift services reccognize it. SELinux is set to permissive mode. Log sample: Sep 22 11:29:01 [hostname] account-replicator[182475]: Skipping: /srv/node/sda is not mounted Sep 22 11:29:01 [hostname] account-replicator[182475]: Skipping: /srv/node/sdb is not mounted Sep 22 11:29:01 [hostname] account-replicator[182475]: Skipping: /srv/node/sdc is not mounted Sep 22 11:29:01 [hostname] account-replicator[182475]: Skipping: /srv/node/sdd is not mounted Sep 22 11:29:01 [hostname] account-replicator[182475]: Skipping: /srv/node/sde is not mounted Sep 22 11:29:01 [hostname] account-replicator[182475]: Skipping: /srv/node/sdf is not mounted Sep 22 11:29:01 [hostname] account-replicator[182475]: Skipping: /srv/node/sdg is not mounted Sep 22 11:29:01 [hostname] account-replicator[182475]: Skipping: /srv/node/sdh is not mounted Sep 22 11:29:01 [hostname] account-replicator[182475]: Skipping: /srv/node/sdi is not mounted Sep 22 11:29:01 [hostname] account-replicator[182475]: Skipping: /srv/node/sdj is not mounted Sep 22 11:29:01 [hostname] account-replicator[182475]: Skipping: /srv/node/sdk is not mounted Sep 22 11:29:01 [hostname] account-replicator[182475]: Skipping: /srv/node/sdl is not mounted Sep 22 11:29:01 [hostname] account-replicator[182475]: Beginning replication run Sep 22 11:29:01 [hostname] account-replicator[182475]: Replication run OVER Sep 22 11:29:01 [hostname] account-replicator[182475]: Attempted to replicate 0 dbs in 0.00344 seconds (0.00000/s) Sep 22 11:29:01 [hostname] account-replicator[182475]: Removed 0 dbs Sep 22 11:29:01 [hostname] account-replicator[182475]: 0 successes, 144 failures Sep 22 11:29:01 [hostname] account-replicator[182475]: diff:0 diff_capped:0 empty:0 hashmatch:0 no_change:0 remote_merge:0 rsync:0 ts_repl:0 Container and Object processes show the same issue. And yet...devices are mounted: [root at swift]# mount | grep srv /dev/sdb on /srv/node/sdb type xfs (rw,noatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota) /dev/sdc on /srv/node/sdc type xfs (rw,noatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota) /dev/sdd on /srv/node/sdd type xfs (rw,noatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota) /dev/sde on /srv/node/sde type xfs (rw,noatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota) /dev/sdf on /srv/node/sdf type xfs (rw,noatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota) /dev/sdg on /srv/node/sdg type xfs (rw,noatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota) /dev/sdh on /srv/node/sdh type xfs (rw,noatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota) /dev/sdi on /srv/node/sdi type xfs (rw,noatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota) /dev/sdj on /srv/node/sdj type xfs (rw,noatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota) /dev/sdk on /srv/node/sdk type xfs (rw,noatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota) /dev/sdl on /srv/node/sdl type xfs (rw,noatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota) /dev/sda on /srv/node/sda type xfs (rw,noatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota) And the rings are built: [root at swift]# swift-ring-builder /etc/swift/account.builder /etc/swift/account.builder, build version 13, id 415987b4753847e9924147119872d547 2048 partitions, 3.000000 replicas, 1 regions, 1 zones, 12 devices, 0.00 balance, 0.00 dispersion The minimum number of hours before a partition can be reassigned is 1 (0:16:41 remaining) The overload factor is 0.00% (0.000000) Ring file /etc/swift/account.ring.gz is up-to-date Devices: id region zone ip address:port replication ip:port name weight partitions balance flags meta 0 1 1 172.16.2.2:6202 172.16.2.2:6202 sda 100.00 512 0.00 1 1 1 172.16.2.2:6202 172.16.2.2:6202 sdb 100.00 512 0.00 2 1 1 172.16.2.2:6202 172.16.2.2:6202 sdc 100.00 512 0.00 3 1 1 172.16.2.2:6202 172.16.2.2:6202 sdd 100.00 512 0.00 4 1 1 172.16.2.2:6202 172.16.2.2:6202 sde 100.00 512 0.00 5 1 1 172.16.2.2:6202 172.16.2.2:6202 sdf 100.00 512 0.00 6 1 1 172.16.2.2:6202 172.16.2.2:6202 sdg 100.00 512 0.00 7 1 1 172.16.2.2:6202 172.16.2.2:6202 sdh 100.00 512 0.00 8 1 1 172.16.2.2:6202 172.16.2.2:6202 sdi 100.00 512 0.00 9 1 1 172.16.2.2:6202 172.16.2.2:6202 sdj 100.00 512 0.00 10 1 1 172.16.2.2:6202 172.16.2.2:6202 sdk 100.00 512 0.00 11 1 1 172.16.2.2:6202 172.16.2.2:6202 sdl 100.00 512 0.00 Bash certainly thinks they are actually mounted and writable: [root at swift ~]# ls -l /srv/node/sda total 0 [root at swift ~]# touch /srv/node/sda/file [root at swift ~]# ls /srv/node/sda file [root at swift ~]# umount /dev/sda [root at swift ~]# ls /srv/node/sda [root at swift ~]# mount /srv/node/sda/ [root at swift ~]# ls /srv/node/sda file [root at swift ~]# rm /srv/node/sda/file rm: remove regular empty file '/srv/node/sda/file'? y And Swift is configured to look at /srv/node for the devices: [root at swift ~]# grep devices /etc/swift/*.conf /etc/swift/account-server.conf:devices = /srv/node /etc/swift/container-server.conf:devices = /srv/node /etc/swift/object-server.conf:devices = /srv/node Running "swift info" shows the expected configuration output, but "swift stat" throws this error: [root at controller ~]# swift stat Account HEAD failed: https:/[api endpoint]/v1/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8 403 Forbidden Failed Transaction ID: tx9128250987cb4e07ad55d-00632c8d05 and the logs show account-server throwing "507 ERROR Insufficient Storage" before 503, and then returning a 403. [root at swift ~]# journalctl -b | grep tx9128250987cb4e07ad55d-00632c8d05 Sep 22 12:27:49 [hostname] account-server[182505]: 172.16.2.2 - - [22/Sep/2022:16:27:49 +0000] "HEAD /sdc/456/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8" 507 - "HEAD http://[api endpoint]/v1/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8?format=json" "tx9128250987cb4e07ad55d-00632c8d05" "proxy-server 182464" 0.0004 "-" 182505 - Sep 22 12:27:49 [hostname] proxy-server[182464]: ERROR Insufficient Storage 172.16.2.2:6202/sdc (txn: tx9128250987cb4e07ad55d-00632c8d05) Sep 22 12:27:49 [hostname] account-server[182515]: 172.16.2.2 - - [22/Sep/2022:16:27:49 +0000] "HEAD /sdj/456/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8" 507 - "HEAD http://[api endpoint]/v1/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8?format=json" "tx9128250987cb4e07ad55d-00632c8d05" "proxy-server 182464" 0.0004 "-" 182515 - Sep 22 12:27:49 [hostname] proxy-server[182464]: ERROR Insufficient Storage 172.16.2.2:6202/sdj (txn: tx9128250987cb4e07ad55d-00632c8d05) Sep 22 12:27:49 [hostname] account-server[182514]: 172.16.2.2 - - [22/Sep/2022:16:27:49 +0000] "HEAD /sdh/456/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8" 507 - "HEAD http://[api endpoint]/v1/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8?format=json" "tx9128250987cb4e07ad55d-00632c8d05" "proxy-server 182464" 0.0011 "-" 182514 - Sep 22 12:27:49 [hostname] proxy-server[182464]: ERROR Insufficient Storage 172.16.2.2:6202/sdh (txn: tx9128250987cb4e07ad55d-00632c8d05) Sep 22 12:27:49 [hostname] account-server[182506]: 172.16.2.2 - - [22/Sep/2022:16:27:49 +0000] "HEAD /sdl/456/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8" 507 - "HEAD http://[api endpoint]/v1/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8?format=json" "tx9128250987cb4e07ad55d-00632c8d05" "proxy-server 182464" 0.0011 "-" 182506 - Sep 22 12:27:49 [hostname] account-server[182504]: 172.16.2.2 - - [22/Sep/2022:16:27:49 +0000] "HEAD /sdf/456/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8" 507 - "HEAD http://[api endpoint]/v1/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8?format=json" "tx9128250987cb4e07ad55d-00632c8d05" "proxy-server 182464" 0.0010 "-" 182504 - Sep 22 12:27:49 [hostname] account-server[182504]: 172.16.2.2 - - [22/Sep/2022:16:27:49 +0000] "HEAD /sdi/456/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8" 507 - "HEAD http://[api endpoint]/v1/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8?format=json" "tx9128250987cb4e07ad55d-00632c8d05" "proxy-server 182464" 0.0002 "-" 182504 - Sep 22 12:27:49 [hostname] proxy-server[182464]: Handoff requested (4) (txn: tx9128250987cb4e07ad55d-00632c8d05) Sep 22 12:27:50 [hostname] account-server[182512]: 172.16.2.2 - - [22/Sep/2022:16:27:50 +0000] "HEAD /sda/456/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8" 507 - "HEAD http://[api endpoint]/v1/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8?format=json" "tx9128250987cb4e07ad55d-00632c8d05" "proxy-server 182464" 0.0011 "-" 182512 - Sep 22 12:27:50 [hostname] proxy-server[182464]: Handoff requested (5) (txn: tx9128250987cb4e07ad55d-00632c8d05) Sep 22 12:27:50 [hostname] account-server[182494]: 172.16.2.2 - - [22/Sep/2022:16:27:50 +0000] "HEAD /sde/456/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8" 507 - "HEAD http://[api endpoint]/v1/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8?format=json" "tx9128250987cb4e07ad55d-00632c8d05" "proxy-server 182464" 0.0010 "-" 182494 - Sep 22 12:27:50 [hostname] proxy-server[182464]: Handoff requested (6) (txn: tx9128250987cb4e07ad55d-00632c8d05) Sep 22 12:27:50 [hostname] account-server[182506]: 172.16.2.2 - - [22/Sep/2022:16:27:50 +0000] "HEAD /sdk/456/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8" 507 - "HEAD http://[api endpoint]/v1/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8?format=json" "tx9128250987cb4e07ad55d-00632c8d05" "proxy-server 182464" 0.0003 "-" 182506 - Sep 22 12:27:50 [hostname] proxy-server[182464]: Account HEAD returning 503 for [507, 507, 507] (txn: tx9128250987cb4e07ad55d-00632c8d05) Sep 22 12:27:50 [hostname] proxy-server[182464]: - - 22/Sep/2022/16/27/50 HEAD /v1/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8%3Fformat%3Djson HTTP/1.0 503 - Swift - - - - tx9128250987cb4e07ad55d-00632c8d05 - 0.0337 RL - 1663864069.976659298 1663864070.010398626 - Sep 22 12:27:51 [hostname] proxy-server[182464]: [IP] 172.16.2.2 22/Sep/2022/16/27/51 HEAD /v1/AUTH_5198a36c0f454ae49e9e8a5d6e154ee8%3Fformat%3Djson HTTP/1.0 403 - python-swiftclient-3.13.1 gAAAAABjLI0FH9MP... - - - tx9128250987cb4e07ad55d-00632c8d05 - 1.4298 - - 1663864069.970289707 1663864071.400121450 - No data is being written to the disks by Swift: [root at swift ~]# ls -lR /srv/node /srv/node: total 0 drwxr-xr-x. 2 swift swift 6 Sep 22 11:13 sda drwxr-xr-x. 2 swift swift 6 Sep 22 11:07 sdb drwxr-xr-x. 2 swift swift 6 Sep 22 11:07 sdc ... /srv/node/sda: total 0 /srv/node/sdb: total 0 /srv/node/sdc: total 0 ... What am I missing here? From dms at danplanet.com Thu Sep 22 17:01:53 2022 From: dms at danplanet.com (Dan Smith) Date: Thu, 22 Sep 2022 10:01:53 -0700 Subject: [dev][security-sig] Revisiting tarfile, or "What's old is new again" In-Reply-To: <20220922155519.xinmnlfmgewwqqnh@yuggoth.org> (Jeremy Stanley's message of "Thu, 22 Sep 2022 15:55:20 +0000") References: <20220922155519.xinmnlfmgewwqqnh@yuggoth.org> Message-ID: > I encourage anyone using tarfile in their projects to double-check > you're doing so safely[2]. I looked at Nova and Glance this morning and I think we're good. The only use in nova is in the vmwareapi driver, which does use tarfile to pull out a vmdk file, but it does so in memory and streams it direct to vmfs without extracting it to the local disk. Glance's only use is in the ova processing, which extracts the ovf and disk image from the tarfile, but it processes the ovf in memory and then streams the disk image to a uuid-based-name file on disk. So I think those are okay at least, although I'm happy for others to check my work of course. --Dan From clay.gerrard at gmail.com Thu Sep 22 17:08:09 2022 From: clay.gerrard at gmail.com (Clay Gerrard) Date: Thu, 22 Sep 2022 12:08:09 -0500 Subject: Swift not recognizing mounted drives In-Reply-To: <2CA5E246-20C0-4244-A840-CB5A7B93FF2E@andrewboring.com> References: <2CA5E246-20C0-4244-A840-CB5A7B93FF2E@andrewboring.com> Message-ID: On Thu, Sep 22, 2022 at 12:02 PM Andrew Boring wrote: > > > What am I missing here? > > Wow I wish I knew! It looks like you tried everything. ??? I have a troubleshooting strategy I call "start with something that works" - the 507 in the logs makes it look like the device mount check is failing for some reason - but you can disable that: https://opendev.org/openstack/swift/src/branch/master/etc/account-server.conf-sample#L10 Does it "work" if we turn off the mount check entirely? Have you been able to configure swift successfully in the past on *different* hardware or software configuration(s)? -- Clay Gerrard -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at andrewboring.com Thu Sep 22 17:31:56 2022 From: andrew at andrewboring.com (Andrew Boring) Date: Thu, 22 Sep 2022 13:31:56 -0400 Subject: Swift not recognizing mounted drives In-Reply-To: References: <2CA5E246-20C0-4244-A840-CB5A7B93FF2E@andrewboring.com> Message-ID: <8814D05E-0EDD-47B6-9C97-FC53613D2060@andrewboring.com> Hi Clay. This is my first Swift install from Openstack packages. My prior expeirence with Swift has been through third-party systems that abstract a lot of the day-to-day disk mgmt activities, so this my first run-through manually. My personal installs have always been on Supermicro hardware, so I don't think that would be an issue (standard SATA controller, not RAID, etc), though I'm happy to check anything further. But if the kernel and shell are seeing the mounted disks without issue, I have to think it's something at the Swift process level. I did try disabling mount_check, which gives me this instead: Sep 22 13:12:46 [hostname] account-replicator[183238]: Skipping: /srv/node/sda is not a directory Sep 22 13:12:46 [hostname] account-replicator[183238]: Skipping: /srv/node/sdb is not a directory Sep 22 13:12:46 [hostname] account-replicator[183238]: Skipping: /srv/node/sdc is not a directory Sep 22 13:12:46 [hostname] account-replicator[183238]: Skipping: /srv/node/sdd is not a directory Sep 22 13:12:46 [hostname] account-replicator[183238]: Skipping: /srv/node/sde is not a directory Sep 22 13:12:46 [hostname] account-replicator[183238]: Skipping: /srv/node/sdf is not a directory Sep 22 13:12:46 [hostname] account-replicator[183238]: Skipping: /srv/node/sdg is not a directory Sep 22 13:12:46 [hostname] account-replicator[183238]: Skipping: /srv/node/sdh is not a directory Sep 22 13:12:46 [hostname] account-replicator[183238]: Skipping: /srv/node/sdi is not a directory Sep 22 13:12:46 [hostname] account-replicator[183238]: Skipping: /srv/node/sdj is not a directory Sep 22 13:12:46 [hostname] account-replicator[183238]: Skipping: /srv/node/sdk is not a directory Sep 22 13:12:46 [hostname] account-replicator[183238]: Skipping: /srv/node/sdl is not a directory Sep 22 13:12:46 [hostname] account-replicator[183238]: Beginning replication run Sep 22 13:12:46 [hostname] account-replicator[183238]: Replication run OVER Sep 22 13:12:46 [hostname] account-replicator[183238]: Attempted to replicate 0 dbs in 0.00372 seconds (0.00000/s) Sep 22 13:12:46 [hostname] account-replicator[183238]: Removed 0 dbs Sep 22 13:12:46 [hostname] account-replicator[183238]: 0 successes, 144 failures Sep 22 13:12:46 [hostname] account-replicator[183238]: diff:0 diff_capped:0 empty:0 hashmatch:0 no_change:0 remote_merge:0 rsync:0 ts_repl:0 Sep 22 13:12:47 [hostname] object-replicator[183230]: Starting object replication pass. And yet: [root at swift]# file /srv/node/sda /srv/node/sda: directory [root at swift]# file /srv/node/sdb /srv/node/sdb: directory ...and so on. Running "swift stat" with mount_check = false gives the same 507 Insufficient Storage as before. -Andrew > On Sep 22, 2022, at 1:08 PM, Clay Gerrard wrote: > > > > On Thu, Sep 22, 2022 at 12:02 PM Andrew Boring wrote: > > > What am I missing here? > > > Wow I wish I knew! It looks like you tried everything. ??? > > I have a troubleshooting strategy I call "start with something that works" - the 507 in the logs makes it look like the device mount check is failing for some reason - but you can disable that: > > https://opendev.org/openstack/swift/src/branch/master/etc/account-server.conf-sample#L10 > > Does it "work" if we turn off the mount check entirely? Have you been able to configure swift successfully in the past on *different* hardware or software configuration(s)? > > > -- > Clay Gerrard From clay.gerrard at gmail.com Thu Sep 22 19:06:13 2022 From: clay.gerrard at gmail.com (Clay Gerrard) Date: Thu, 22 Sep 2022 14:06:13 -0500 Subject: Swift not recognizing mounted drives In-Reply-To: <8814D05E-0EDD-47B6-9C97-FC53613D2060@andrewboring.com> References: <2CA5E246-20C0-4244-A840-CB5A7B93FF2E@andrewboring.com> <8814D05E-0EDD-47B6-9C97-FC53613D2060@andrewboring.com> Message-ID: On Thu, Sep 22, 2022 at 12:36 PM Andrew Boring wrote: > > Sep 22 13:12:46 [hostname] account-replicator[183238]: Skipping: > /srv/node/sda is not a directory > Ok well that's right here: https://opendev.org/openstack/swift/src/branch/master/swift/common/db_replicator.py#L813 Which you can look at in constraints is pretty straightforward: https://opendev.org/openstack/swift/src/branch/master/swift/common/constraints.py#L274 > [root at swift]# file /srv/node/sda > /srv/node/sda: directory > > ok, that seems like something that works - let's see if we can get closer to the problem? What if we use python (as root): sudo python -c "import os.path; print(os.path.isdir('/srv/node/sda'))" ... or again with the "swift" user sudo -u swift python -c "import os.path; print(os.path.isdir('/srv/node/sda'))" N.B. the user swift is just the default - use whatever you have set as "user =" in your config Also check syslog/journald and security or whatever for any warning logs about permissions or SELinux -- Clay Gerrard -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at andrewboring.com Thu Sep 22 19:51:52 2022 From: andrew at andrewboring.com (Andrew Boring) Date: Thu, 22 Sep 2022 15:51:52 -0400 Subject: Swift not recognizing mounted drives In-Reply-To: References: <2CA5E246-20C0-4244-A840-CB5A7B93FF2E@andrewboring.com> <8814D05E-0EDD-47B6-9C97-FC53613D2060@andrewboring.com> Message-ID: <259A047A-ED0B-4A0E-9A2A-D86458EDBD6E@andrewboring.com> Clay, Well, I'm an idiot. I absolutely remembered to cchange the SELinux config file to permissive, and absolutely forgot to 'setenforce 0' immediately afteward. I even watched the audit log, thinking it was just logging the actions that will be blocked when I set it back to enforcing. [root at swift ~]# grep SELINUX= /etc/selinux/config # SELINUX= can take one of these three values: SELINUX=permissive And yet: [root at swift ~]# getenforce Enforcing A quick "setenforce 0" made all the nasty errors go away. Thanks for your patience. > On Sep 22, 2022, at 3:06 PM, Clay Gerrard wrote: > > > > On Thu, Sep 22, 2022 at 12:36 PM Andrew Boring wrote: > > Sep 22 13:12:46 [hostname] account-replicator[183238]: Skipping: /srv/node/sda is not a directory > > Ok well that's right here: > > https://opendev.org/openstack/swift/src/branch/master/swift/common/db_replicator.py#L813 > > Which you can look at in constraints is pretty straightforward: > > https://opendev.org/openstack/swift/src/branch/master/swift/common/constraints.py#L274 > > > [root at swift]# file /srv/node/sda > /srv/node/sda: directory > > > ok, that seems like something that works - let's see if we can get closer to the problem? What if we use python (as root): > > sudo python -c "import os.path; print(os.path.isdir('/srv/node/sda'))" > > ... or again with the "swift" user > > sudo -u swift python -c "import os.path; print(os.path.isdir('/srv/node/sda'))" > > N.B. the user swift is just the default - use whatever you have set as "user =" in your config > > Also check syslog/journald and security or whatever for any warning logs about permissions or SELinux > > -- > Clay Gerrard From clay.gerrard at gmail.com Thu Sep 22 19:59:54 2022 From: clay.gerrard at gmail.com (Clay Gerrard) Date: Thu, 22 Sep 2022 14:59:54 -0500 Subject: Swift not recognizing mounted drives In-Reply-To: <259A047A-ED0B-4A0E-9A2A-D86458EDBD6E@andrewboring.com> References: <2CA5E246-20C0-4244-A840-CB5A7B93FF2E@andrewboring.com> <8814D05E-0EDD-47B6-9C97-FC53613D2060@andrewboring.com> <259A047A-ED0B-4A0E-9A2A-D86458EDBD6E@andrewboring.com> Message-ID: On Thu, Sep 22, 2022 at 2:51 PM Andrew Boring wrote: > > A quick "setenforce 0" made all the nasty errors go away. Thanks for your > patience. > > Ah! Well spotted! Nice work. -- Clay Gerrard -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Fri Sep 23 01:52:59 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Thu, 22 Sep 2022 18:52:59 -0700 Subject: [all][tc] 2023.1 Antelope TC-PTG Planning In-Reply-To: <182d57d2a78.1127e41be140296.2872907929814651386@ghanshyammann.com> References: <182d57d2a78.1127e41be140296.2872907929814651386@ghanshyammann.com> Message-ID: <183680c4a58.dc375de7355972.8647386454272610958@ghanshyammann.com> Updates: TC decided to meet at the below slots: * Monday 15:00 - 17:00 UTC (2 hours) for TC+leaders interaction discussion. * Thursday 15:00 - 19:00 UTC (4 hours) * Friday 15:00 - 19:00 UTC (4 hours) PLEASE NOTE: To minimize the conflict with the project sessions, the last 2 hours on Thursday and Friday are booked out of the PTG schedule. Details are there in the below etherpad, please start adding the topic you would like to discuss: - https://etherpad.opendev.org/p/tc-2023-1-ptg -gmann ---- On Thu, 25 Aug 2022 07:52:06 -0700 Ghanshyam Mann wrote --- > Hello Everyone, > > As you already know that the 2023.1 cycle virtual PTG will be held between Oct 17th - 21[1]. > > I have started the preparation for the Technical Committee PTG sessions. Please do the following: > > 1. Fill the below poll as per your availability. > > - https://framadate.org/yi8LNQaph5wrirks > > 2. Add the topics you would like to discuss to the below etherpad. > > - https://etherpad.opendev.org/p/tc-2023-1-ptg > > NOTE: this is not limited to TC members only; I would like all community members to > fill the doodle poll and, add the topics you would like or want TC members to discuss in PTG. > > [1] https://lists.openstack.org/pipermail/openstack-discuss/2022-August/030041.html > > -gmann > > From tony at bakeyournoodle.com Fri Sep 23 07:29:45 2022 From: tony at bakeyournoodle.com (Tony Breeds) Date: Fri, 23 Sep 2022 17:29:45 +1000 Subject: [magnum][heat][requirements][release] Potential blocker for release with python-magnumclient 4.0.0 In-Reply-To: References: Message-ID: Hi all, Thanks to the heat team they quickly resolved the problem and the release and requirements teams can/have moved forward. #thanks On Wed, 21 Sept 2022 at 15:57, Tony Breeds wrote: > Okay cool. I'll take a punt at removing it > > On Wed, 21 Sept 2022 at 15:50, Brendan Shephard > wrote: > >> Hey Tony, >> >> Thanks for the heads up. We have deprecated support for these resources >> some time ago: >> https://review.opendev.org/c/openstack/heat/+/433549 >> >> I don't believe there are any concerns with removing this resource and >> subsequent use of the baymodel API from Heat now. >> >> Brendan Shephard >> >> Senior Software Engineer >> >> Red Hat APAC >> >> 193 N Quay >> >> Brisbane City QLD 4000 >> @RedHat Red Hat >> Red Hat >> >> >> >> >> >> On Wed, Sep 21, 2022 at 3:37 PM Tony Breeds >> wrote: >> >>> Hello all, >>> In [1] baymodel code was removed, although it still seems to be >>> listed in the API-ref. Story [2] states it's been deprecated for a >>> long time, but a quick check failed to see this documented anywhere. >>> Heat still supports baymodel and the removal is causing failures. >>> Blocking the use of python-magnumclient 4.0.0[3] inzed, even though >>> the 4.0.0 release is clearly meant for zed. >>> >>> I can see a couple of paths forward. >>> >>> 0. Remove the documentation in the api-ref for baymodels >>> 1. Remove the support in heat for baymodels (I think the newer >>> clusters API can be used instead?) >>> 2. Revert the change in magnumclient and re-release etc etc >>> 3. Keep 4.0.0 for the Antelope release, and reset the stable/zed >>> branch python-magnumclient to fd0cb1e (before the removal of >>> baymodels) >>> >>> Obviously option 1 looks like the least disruptive change, but >>> potentially causes a problem for heat depending on the published state >>> of baymodel support >>> >>> [1] https://review.opendev.org/c/openstack/python-magnumclient/+/803629 >>> [2] https://storyboard.openstack.org/#!/story/2009104 >>> [3] https://review.opendev.org/c/openstack/requirements/+/858089 >>> >>> -- >>> Yours Tony. >>> >>> > > -- > Yours Tony. > -- Yours Tony. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sylvain.bauza at gmail.com Fri Sep 23 08:47:26 2022 From: sylvain.bauza at gmail.com (Sylvain Bauza) Date: Fri, 23 Sep 2022 10:47:26 +0200 Subject: [nova][ironic][ptg] Improved ironic<>nova driver interactions session In-Reply-To: References: Message-ID: Le jeu. 22 sept. 2022 ? 18:58, Jay Faulkner a ?crit : > Hello Nova folks, > > At the Ironic PTG planning meeting this morning, discussion of improving > Nova and Ironic driver interactions; and specifically this spec: > https://review.opendev.org/c/openstack/nova-specs/+/842015/ came up. It's > important for our teams to come together and reach consensus as to how to > fix this. > > According to the latest OpenStack user survey ( > https://www.openstack.org/analytics/) over 20% of Nova deployments > utilize the Ironic driver. However, in my years operating Ironic for > multiple different organizations, the Nova<>Ironic driver interface has > repeatedly been the source of most operational pain. We should work > together to prioritize saving these operators from downtime and bad failure > semantics. > > I'd love for Ironic and Nova to schedule a session together to talk about > this and try to find a solution. We owe it to our users to no longer shy > away from this hard technical problem and fix things. > > Yup, I was also wanting to have a cross-project session in the PTG for discussing about the above spec (which is actually not really a spec, just a document ;-) ) > What's the best way for us to get this time scheduled? Someone can feel > free to reach out to me on IRC (JayF), or reply here and I'm sure we can > work it out. > > As you can see, Nova already has the schedule in https://ptg.opendev.org/ptg.html We'll be having sessions between Tuesday and Friday on the Bexar track. Just ping me on #openstack-nova and we'll try to find a time for the cross-project session then. -Sylvain Thanks in Advance, > > Jay Faulkner > G-Research Open Source Software lab > OpenStack Ironic PTL > OpenStack Technical Committee member > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mnasiadka at gmail.com Fri Sep 23 09:18:24 2022 From: mnasiadka at gmail.com (=?utf-8?Q?Micha=C5=82_Nasiadka?=) Date: Fri, 23 Sep 2022 11:18:24 +0200 Subject: [kolla] Antelope PTG Message-ID: Greetings Koalas, As you most probably know the OpenStack Antelope PTG is coming soon (17-21th Oct 2022). I?ve booked the usual slots (Mon-Wed) for Kolla project group (Kolla, Kolla-Ansible, Kayobe) with Wed being primary a slot for Kayobe. For operator-focus - the Kolla projects Operator Hour is booked for Tue, 16-17 UTC. Please sign up to the ether pad https://etherpad.opendev.org/p/kolla-antelope-ptg and propose topics. See you on the PTG! Best regards, Michal Nasiadka -------------- next part -------------- An HTML attachment was scrubbed... URL: From adivya1.singh at gmail.com Fri Sep 23 13:44:29 2022 From: adivya1.singh at gmail.com (Adivya Singh) Date: Fri, 23 Sep 2022 19:14:29 +0530 Subject: Regarding Magnum configuration on Xena Openstack Message-ID: Hi Team, Can we have standard inputs to put and test to implement Containerization in Xena Openstack installed using ansible Regards Adivya Singh -------------- next part -------------- An HTML attachment was scrubbed... URL: From elod.illes at est.tech Fri Sep 23 16:31:55 2022 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Fri, 23 Sep 2022 18:31:55 +0200 Subject: [release] Release countdown for week R-1, Sep 26 - 30 Message-ID: <1a21d7f6-92c0-094e-d453-33576b3489b7@est.tech> Development Focus ----------------- We are on the final mile of the Zed development cycle! Remember that the Zed final release will include the latest release candidate (for cycle-with-rc deliverables) or the latest intermediary release (for cycle-with-intermediary deliverables) available. September 29th, 2022 is the deadline for final Zed release candidates as well as any last cycle-with-intermediary deliverables. We will then enter a quiet period until we tag the final release on October 5th, 2022. Teams should be prioritizing fixing release-critical bugs, before that deadline. Otherwise it's time to start planning the 2023.1 Antelope development cycle, including discussing Forum and PTG sessions content, in preparation of Virtual PTG @ October 17-21, 2022. Actions ------- Watch for any translation patches coming through on the stable/zed branch and merge them quickly. If you discover a release-critical issue, please make sure to fix it on the master branch first, then backport the bugfix to the stable/zed branch before triggering a new release. Please drop by #openstack-release with any questions or concerns about the upcoming release ! Upcoming Deadlines & Dates -------------------------- Final Zed release: October 5th, 2022 Virtual PTG: October 17-21, 2022 El?d Ill?s irc: elodilles From alsotoes at gmail.com Fri Sep 23 18:25:35 2022 From: alsotoes at gmail.com (Alvaro Soto) Date: Fri, 23 Sep 2022 13:25:35 -0500 Subject: How do I disable replication in swift In-Reply-To: <1295063360.641866.1663941856275@mail.yahoo.com> References: <1112921123.2169438.1663847346908.ref@mail.yahoo.com> <1112921123.2169438.1663847346908@mail.yahoo.com> <1295063360.641866.1663941856275@mail.yahoo.com> Message-ID: question: Do you want to delete replicas of old objects? o just disable it for future objects until you get more disk/nodes? for the second did you try to stop the object replicator service? On Fri, Sep 23, 2022 at 9:04 AM Paladox wrote: > Thanks! But that doesn?t tell you how to disable as the value must be one > or higher? Unless it?s not 1+1 (or what ever you set as the replica value). > > On Thursday, 22 September 2022 at 19:58:41 BST, Alvaro Soto < > alsotoes at gmail.com> wrote: > > > Check changing the replica counts > > > https://docs.openstack.org/swift/xena/admin/objectstorage-ringbuilder.html#replica-counts > > --- > Alvaro Soto. > > Note: My work hours may not be your work hours. Please do not feel the > need to respond during a time that is not convenient for you. > ---------------------------------------------------------- > Great people talk about ideas, > ordinary people talk about things, > small people talk... about other people. > > On Thu, Sep 22, 2022, 6:54 AM Paladox wrote: > > Hello, I would like Swift to only have 1 file not any copies of it, how do > I disable replication as you must set the value to 1 when you create the > rings? > > (We don?t have the disk space to have replication / copies of the files) > > -- Alvaro Soto *Note: My work hours may not be your work hours. Please do not feel the need to respond during a time that is not convenient for you.* ---------------------------------------------------------- Great people talk about ideas, ordinary people talk about things, small people talk... about other people. -------------- next part -------------- An HTML attachment was scrubbed... URL: From swogatpradhan22 at gmail.com Fri Sep 23 19:13:14 2022 From: swogatpradhan22 at gmail.com (Swogat Pradhan) Date: Sat, 24 Sep 2022 00:43:14 +0530 Subject: Unable to create access rules 'state:error' | Wallaby | Tripelo | NetApp Message-ID: Hi, When i am trying to create access rule for manila share, the rules are created in error state. Here is the manila share log: 2022-09-23 19:03:58.557 43 INFO manila.share.manager [req-ef21b41e-efc6-4b7d-9214-3de878d50d7f - - - - -] Updating share status 2022-09-23 19:04:01.720 26 INFO manila.share.manager [req-3d66c534-a782-414b-a0a7-2bdd57f57b8f - - - - -] Updating share status 2022-09-23 19:04:58.554 43 INFO manila.share.manager [req-ef21b41e-efc6-4b7d-9214-3de878d50d7f - - - - -] Updating share status 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server [req-5f035b4a-7dc8-4e61-bbd5-d38d4b81a00d c1905e3c5a374924980e851840e7f028 5d922243077045c48fe4b075e386551b - - -] Exception during message handling: manila.share.drivers.netapp.dataontap.client.api.NaApiError: NetApp API failed. Reason - 15661:entry doesn't exist 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/oslo_messaging/rpc/server.py", line 165, in _process_incoming 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line 309, in dispatch 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line 229, in _do_dispatch 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/manager.py", line 216, in wrapped 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server return f(self, *args, **kwargs) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/utils.py", line 568, in wrapper 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server return func(self, *args, **kwargs) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/manager.py", line 3965, in update_access 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server share_server_id=share_server_id) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/manager.py", line 3981, in update_access_for_instances 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server share_server=share_server) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/access.py", line 302, in update_access_rules 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server share_server=share_server) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/access.py", line 341, in _update_access_rules 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server share_server) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/access.py", line 409, in _update_rules_through_share_driver 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server share_server=share_server 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/cluster_mode/drv_single_svm.py", line 104, in update_access 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server delete_rules, **kwargs) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/utils.py", line 112, in trace_wrapper 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server result = f(self, *args, **kwargs) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/cluster_mode/lib_base.py", line 2347, in update_access 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server helper.update_access(share, share_name, access_rules) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/utils.py", line 112, in trace_wrapper 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server result = f(self, *args, **kwargs) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/protocols/base.py", line 36, in wrapped_func 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server return source_func(self, *args, **kwargs) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/oslo_concurrency/lockutils.py", line 391, in inner 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server return f(*args, **kwargs) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/protocols/base.py", line 34, in source_func 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server return f(self, *args, **kwargs) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/protocols/nfs_cmode.py", line 115, in update_access 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server auth_methods = self._get_auth_methods() 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/utils.py", line 112, in trace_wrapper 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server result = f(self, *args, **kwargs) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/protocols/nfs_cmode.py", line 222, in _get_auth_methods 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server kerberos_enabled = self._client.is_kerberos_enabled() 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/utils.py", line 112, in trace_wrapper 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server result = f(self, *args, **kwargs) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/client/client_cmode.py", line 1896, in is_kerberos_enabled 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server result = self.send_request('kerberos-config-get', api_args) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/client/client_base.py", line 90, in send_request 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server use_zapi=use_zapi) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/client/api.py", line 710, in invoke_successfully 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server na_element, api_args=api_args, enable_tunneling=enable_tunneling) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/client/api.py", line 380, in invoke_successfully 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server raise NaApiError(code, msg) 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server manila.share.drivers.netapp.dataontap.client.api.NaApiError: NetApp API failed. Reason - 15661:entry doesn't exist Please suggest how to mitigate this issue. With regards, Swogat Pradhan -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmulhall410 at yahoo.com Fri Sep 23 19:26:11 2022 From: thomasmulhall410 at yahoo.com (Paladox) Date: Fri, 23 Sep 2022 19:26:11 +0000 (UTC) Subject: How do I disable replication in swift In-Reply-To: References: <1112921123.2169438.1663847346908.ref@mail.yahoo.com> <1112921123.2169438.1663847346908@mail.yahoo.com> <1295063360.641866.1663941856275@mail.yahoo.com> Message-ID: <527985954.3334066.1663961171011@mail.yahoo.com> We're just setting it up so i can erase everything. Ah so if i stoped the object replicator service, that'll be fine? On Friday, 23 September 2022, 19:30:28 BST, Alvaro Soto wrote: question:Do you want to delete replicas of old objects? o just disable it for future objects until you get more disk/nodes?for the second did you try to stop the object replicator service?? On Fri, Sep 23, 2022 at 9:04 AM Paladox wrote: Thanks! But that doesn?t tell you how to disable as the value must be one or higher? Unless it?s not 1+1 (or what ever you set as the replica value). On Thursday, 22 September 2022 at 19:58:41 BST, Alvaro Soto wrote: Check changing the replica counts? https://docs.openstack.org/swift/xena/admin/objectstorage-ringbuilder.html#replica-counts --- Alvaro Soto. Note: My work hours may not be your work hours. Please do not feel the need to respond during a time that is not convenient for you. ---------------------------------------------------------- Great people talk about ideas, ordinary?people talk about things, small people talk... about other people. On Thu, Sep 22, 2022, 6:54 AM Paladox wrote: Hello, I would like Swift to only have 1 file not any copies of it, how do I disable replication as you must set the value to 1 when you create the rings? (We don?t have the disk space to have replication / copies of the files) -- Alvaro Soto? Note: My work hours may not be your work hours. Please do not feel the need to respond during a time that is not convenient for you. ---------------------------------------------------------- Great people talk about ideas, ordinary people talk about things, small people talk... about other people. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alsotoes at gmail.com Fri Sep 23 19:59:20 2022 From: alsotoes at gmail.com (Alvaro Soto) Date: Fri, 23 Sep 2022 14:59:20 -0500 Subject: How do I disable replication in swift In-Reply-To: <527985954.3334066.1663961171011@mail.yahoo.com> References: <1112921123.2169438.1663847346908.ref@mail.yahoo.com> <1112921123.2169438.1663847346908@mail.yahoo.com> <1295063360.641866.1663941856275@mail.yahoo.com> <527985954.3334066.1663961171011@mail.yahoo.com> Message-ID: If I'm no mistaken, that will stop replication for new objects but also stop checking for old objects consistency (maybe l, just maybe you will loose information if you disk or network disruption) I consider this a quick and dirty fix in the mean time you get more disk space without stop serving write IO, better option to preserve old objects consistency will be maybe to put your cluster in read-only but from the ACL, not from the Linux boxes. Can I ask what is the current space statuses on your cluster drives? --- Alvaro Soto. Note: My work hours may not be your work hours. Please do not feel the need to respond during a time that is not convenient for you. ---------------------------------------------------------- Great people talk about ideas, ordinary people talk about things, small people talk... about other people. On Fri, Sep 23, 2022, 2:26 PM Paladox wrote: > We're just setting it up so i can erase everything. Ah so if i stoped the > object replicator service, that'll be fine? > > On Friday, 23 September 2022, 19:30:28 BST, Alvaro Soto < > alsotoes at gmail.com> wrote: > > > question: > Do you want to delete replicas of old objects? o just disable it for > future objects until you get more disk/nodes? > for the second did you try to stop the object replicator service? > > On Fri, Sep 23, 2022 at 9:04 AM Paladox > wrote: > > Thanks! But that doesn?t tell you how to disable as the value must be one > or higher? Unless it?s not 1+1 (or what ever you set as the replica value). > > On Thursday, 22 September 2022 at 19:58:41 BST, Alvaro Soto < > alsotoes at gmail.com> wrote: > > > Check changing the replica counts > > > https://docs.openstack.org/swift/xena/admin/objectstorage-ringbuilder.html#replica-counts > > --- > Alvaro Soto. > > Note: My work hours may not be your work hours. Please do not feel the > need to respond during a time that is not convenient for you. > ---------------------------------------------------------- > Great people talk about ideas, > ordinary people talk about things, > small people talk... about other people. > > On Thu, Sep 22, 2022, 6:54 AM Paladox wrote: > > Hello, I would like Swift to only have 1 file not any copies of it, how do > I disable replication as you must set the value to 1 when you create the > rings? > > (We don?t have the disk space to have replication / copies of the files) > > > > -- > > Alvaro Soto > > *Note: My work hours may not be your work hours. Please do not feel the > need to respond during a time that is not convenient for you.* > ---------------------------------------------------------- > Great people talk about ideas, > ordinary people talk about things, > small people talk... about other people. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ces.eduardo98 at gmail.com Fri Sep 23 20:24:55 2022 From: ces.eduardo98 at gmail.com (Carlos Silva) Date: Fri, 23 Sep 2022 17:24:55 -0300 Subject: [manila] Antelope PTG planning Message-ID: Greetings, Zorillas and interested stackers! At this point, I bet you already know that the PTG is coming. It goes from 17th to 21st of October 2022, and if you have not registered yet, there is still time! [1] We have already booked the slots for our discussions, please add it to your agenda: 17th: 16:00 UTC to 17:00 UTC (Monday) 19th: 14:00 UTC to 17:00 UTC (Wednesday) 20th: 14:00 UTC to 17:00 UTC (Thursday) 21st: 13:00 UTC to 17:00 UTC (Friday) Please add the topics you would like to bring up to our planning etherpad [2]. Looking forward to meeting you there! [1] https://openinfra.dev/ptg/ [2] https://etherpad.opendev.org/p/antelope-ptg-manila-planning - carloss -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomasmulhall410 at yahoo.com Fri Sep 23 21:20:03 2022 From: thomasmulhall410 at yahoo.com (Paladox) Date: Fri, 23 Sep 2022 21:20:03 +0000 (UTC) Subject: How do I disable replication in swift In-Reply-To: References: <1112921123.2169438.1663847346908.ref@mail.yahoo.com> <1112921123.2169438.1663847346908@mail.yahoo.com> <1295063360.641866.1663941856275@mail.yahoo.com> <527985954.3334066.1663961171011@mail.yahoo.com> Message-ID: <2052306468.3384214.1663968003125@mail.yahoo.com> We have around 3.8tb but we're wanting to move from gluster to swift (which we're currently using?2.6tb). We're a small not-for-profit in the UK. We don't have the funds to support replicating data right now. On Friday, 23 September 2022, 21:04:32 BST, Alvaro Soto wrote: If I'm no mistaken, that will stop replication for new objects but also stop checking for old objects consistency (maybe l, just maybe you will loose information if you disk or network disruption) I consider this a quick and dirty fix in the mean time you get more disk space without stop serving write IO, better option to preserve old objects consistency will be maybe to put your cluster in read-only but from the ACL, not from the Linux boxes. Can I ask what is the current space statuses on your cluster drives? --- Alvaro Soto. Note: My work hours may not be your work hours. Please do not feel the need to respond during a time that is not convenient for you. ---------------------------------------------------------- Great people talk about ideas, ordinary?people talk about things, small people talk... about other people. On Fri, Sep 23, 2022, 2:26 PM Paladox wrote: We're just setting it up so i can erase everything. Ah so if i stoped the object replicator service, that'll be fine? On Friday, 23 September 2022, 19:30:28 BST, Alvaro Soto wrote: question:Do you want to delete replicas of old objects? o just disable it for future objects until you get more disk/nodes?for the second did you try to stop the object replicator service?? On Fri, Sep 23, 2022 at 9:04 AM Paladox wrote: Thanks! But that doesn?t tell you how to disable as the value must be one or higher? Unless it?s not 1+1 (or what ever you set as the replica value). On Thursday, 22 September 2022 at 19:58:41 BST, Alvaro Soto wrote: Check changing the replica counts? https://docs.openstack.org/swift/xena/admin/objectstorage-ringbuilder.html#replica-counts --- Alvaro Soto. Note: My work hours may not be your work hours. Please do not feel the need to respond during a time that is not convenient for you. ---------------------------------------------------------- Great people talk about ideas, ordinary?people talk about things, small people talk... about other people. On Thu, Sep 22, 2022, 6:54 AM Paladox wrote: Hello, I would like Swift to only have 1 file not any copies of it, how do I disable replication as you must set the value to 1 when you create the rings? (We don?t have the disk space to have replication / copies of the files) -- Alvaro Soto? Note: My work hours may not be your work hours. Please do not feel the need to respond during a time that is not convenient for you. ---------------------------------------------------------- Great people talk about ideas, ordinary people talk about things, small people talk... about other people. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alsotoes at gmail.com Fri Sep 23 22:17:06 2022 From: alsotoes at gmail.com (Alvaro Soto) Date: Fri, 23 Sep 2022 17:17:06 -0500 Subject: How do I disable replication in swift In-Reply-To: <2052306468.3384214.1663968003125@mail.yahoo.com> References: <1112921123.2169438.1663847346908.ref@mail.yahoo.com> <1112921123.2169438.1663847346908@mail.yahoo.com> <1295063360.641866.1663941856275@mail.yahoo.com> <527985954.3334066.1663961171011@mail.yahoo.com> <2052306468.3384214.1663968003125@mail.yahoo.com> Message-ID: Have you considered using Ceph? so you can easily tune this kind of thing. Also, Ceph is thin provisioning and supports compression, devs are working on deduplication. Cheers!. On Fri, Sep 23, 2022 at 4:20 PM Paladox wrote: > We have around 3.8tb but we're wanting to move from gluster to swift > (which we're currently using 2.6tb). We're a small not-for-profit in the > UK. We don't have the funds to support replicating data right now. > > On Friday, 23 September 2022, 21:04:32 BST, Alvaro Soto < > alsotoes at gmail.com> wrote: > > > If I'm no mistaken, that will stop replication for new objects but also > stop checking for old objects consistency (maybe l, just maybe you will > loose information if you disk or network disruption) I consider this a > quick and dirty fix in the mean time you get more disk space without stop > serving write IO, better option to preserve old objects consistency will be > maybe to put your cluster in read-only but from the ACL, not from the Linux > boxes. > > Can I ask what is the current space statuses on your cluster drives? > > --- > Alvaro Soto. > > Note: My work hours may not be your work hours. Please do not feel the > need to respond during a time that is not convenient for you. > ---------------------------------------------------------- > Great people talk about ideas, > ordinary people talk about things, > small people talk... about other people. > > On Fri, Sep 23, 2022, 2:26 PM Paladox wrote: > > We're just setting it up so i can erase everything. Ah so if i stoped the > object replicator service, that'll be fine? > > On Friday, 23 September 2022, 19:30:28 BST, Alvaro Soto < > alsotoes at gmail.com> wrote: > > > question: > Do you want to delete replicas of old objects? o just disable it for > future objects until you get more disk/nodes? > for the second did you try to stop the object replicator service? > > On Fri, Sep 23, 2022 at 9:04 AM Paladox > wrote: > > Thanks! But that doesn?t tell you how to disable as the value must be one > or higher? Unless it?s not 1+1 (or what ever you set as the replica value). > > On Thursday, 22 September 2022 at 19:58:41 BST, Alvaro Soto < > alsotoes at gmail.com> wrote: > > > Check changing the replica counts > > > https://docs.openstack.org/swift/xena/admin/objectstorage-ringbuilder.html#replica-counts > > --- > Alvaro Soto. > > Note: My work hours may not be your work hours. Please do not feel the > need to respond during a time that is not convenient for you. > ---------------------------------------------------------- > Great people talk about ideas, > ordinary people talk about things, > small people talk... about other people. > > On Thu, Sep 22, 2022, 6:54 AM Paladox wrote: > > Hello, I would like Swift to only have 1 file not any copies of it, how do > I disable replication as you must set the value to 1 when you create the > rings? > > (We don?t have the disk space to have replication / copies of the files) > > > > -- > > Alvaro Soto > > *Note: My work hours may not be your work hours. Please do not feel the > need to respond during a time that is not convenient for you.* > ---------------------------------------------------------- > Great people talk about ideas, > ordinary people talk about things, > small people talk... about other people. > > -- Alvaro Soto *Note: My work hours may not be your work hours. Please do not feel the need to respond during a time that is not convenient for you.* ---------------------------------------------------------- Great people talk about ideas, ordinary people talk about things, small people talk... about other people. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Fri Sep 23 22:22:41 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 23 Sep 2022 15:22:41 -0700 Subject: [all][tc] What's happening in Technical Committee: summary 2022 Sept 23: Reading: 5 min Message-ID: <1836c721baa.bf68f124417856.6843552062416861876@ghanshyammann.com> Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week's meeting on Sept 22. Most of the meeting discussions are summarized in this email. Meeting logs are available @ https://meetings.opendev.org/meetings/tc/2022/tc.2022-09-22-15.00.log.html * Next TC weekly meeting will be on Sept 29 Thursday at 15:00 UTC, feel free to add the topic on the agenda[1] by Sept 28. 2. What we completed this week: ========================= * Antelope Elections[2]. Thanks to all the leaders who step up for the role. Also thanks to the election official. * Updated node.js version to 18 in 2023.1 testing runtime[3] 3. Activities In progress: ================== TC Tracker for Zed cycle ------------------------------ * Zed tracker etherpad includes the TC working items[4], Five are completed and other items are in-progress. Open Reviews ----------------- * Thirteen open reviews for ongoing activities[5]. New community-wide goal proposal "Migration CI/CD to Ubuntu 22.04" -------------------------------------------------------------------------------------- As we decided to migrate the CI/CD testing from Ubuntu 20.04 to 22.04 in 2023.1 cycle, we need to define this task as a community-wide goal. This work requires more testing than changes which are covered in base jobs. The goal proposal is under review[6]. Thanks, Dmitriy to compose and volunteer to drive this goal. 2023.1 cycle Leaderless projects & TC Chair ---------------------------------------------------- * We had 9 projects that missed the PTL nomination but the good news is that we found the leaders for all 9 projects now[7]. TC is discussing their appointment on gerrit reviews. * TC Chair: we have two nominations for the TC Chair[8][9] which is really a good thing having multiple people stepping up for the role. We will keep nomination open until Tuesday (27 Sept) if anyone else also would like to add a nomination. On Tuesday, we can start the CIVS poll among TC members to select the chair for next term. 2023.1 cycle TC PTG planning ------------------------------------ Updates on PTG planning: * TC decided to meet at the below slots [10]: ** Monday 15:00 - 17:00 UTC (2 hours) for TC+leaders interaction discussion. ** Thursday 15:00 - 19:00 UTC (4 hours) ** Friday 15:00 - 19:00 UTC (4 hours) * Etherpads: ** https://etherpad.opendev.org/p/tc-2023-1-ptg ** https://etherpad.opendev.org/p/tc-leaders-interaction-2023-1 * I sent an email about the 'Operator Hours' slots in this PTG, please check and reserve the operator hour slot for your project[11] 2021 User Survey TC Question Analysis ----------------------------------------------- No update on this. The survey summary is up for review[12]. Feel free to check and provide feedback. Fixing Zuul config error ---------------------------- Requesting projects with zuul config error to look into those and fix them which should not take much time[13]14]. Project updates ------------------- * None. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[15]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [16] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://review.opendev.org/c/openstack/governance/+/858539 [3] https://review.opendev.org/c/openstack/governance/+/856927 [4] https://etherpad.opendev.org/p/tc-zed-tracker [5] https://review.opendev.org/q/projects:openstack/governance+status:open [6] https://review.opendev.org/c/openstack/governance/+/858690 [7] https://etherpad.opendev.org/p/2023.1-leaderless [8] https://review.opendev.org/c/openstack/governance/+/858947 [9] https://review.opendev.org/c/openstack/governance/+/858957 [10] https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030575.html [11] https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030301.html [12] https://review.opendev.org/c/openstack/governance/+/836888 [13] https://etherpad.opendev.org/p/zuul-config-error-openstack [14] http://lists.openstack.org/pipermail/openstack-discuss/2022-May/028603.html [15] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [16] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann From gagehugo at gmail.com Sun Sep 25 19:46:26 2022 From: gagehugo at gmail.com (Gage Hugo) Date: Sun, 25 Sep 2022 14:46:26 -0500 Subject: [openstack-helm] OpenStack-Helm PTG Message-ID: Hey team, The next PTG is coming up (Oct 17-21). I've booked a slot for project discussions on Tue Oct 18th @ 1500 UTC Please sign up to the etherpad if you wish to propose any topics: https://etherpad.opendev.org/p/oct2022-ptg-openstack-helm See you there! -------------- next part -------------- An HTML attachment was scrubbed... URL: From swogatpradhan22 at gmail.com Mon Sep 26 07:27:24 2022 From: swogatpradhan22 at gmail.com (Swogat Pradhan) Date: Mon, 26 Sep 2022 12:57:24 +0530 Subject: Unable to create access rules 'state:error' | Wallaby | Tripelo | NetApp In-Reply-To: References: Message-ID: Hi, Can anyone please suggest a fix? On Sat, Sep 24, 2022 at 12:43 AM Swogat Pradhan wrote: > Hi, > When i am trying to create access rule for manila share, the rules are > created in error state. > > Here is the manila share log: > 2022-09-23 19:03:58.557 43 INFO manila.share.manager > [req-ef21b41e-efc6-4b7d-9214-3de878d50d7f - - - - -] Updating share status > 2022-09-23 19:04:01.720 26 INFO manila.share.manager > [req-3d66c534-a782-414b-a0a7-2bdd57f57b8f - - - - -] Updating share status > 2022-09-23 19:04:58.554 43 INFO manila.share.manager > [req-ef21b41e-efc6-4b7d-9214-3de878d50d7f - - - - -] Updating share status > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server > [req-5f035b4a-7dc8-4e61-bbd5-d38d4b81a00d c1905e3c5a374924980e851840e7f028 > 5d922243077045c48fe4b075e386551b - - -] Exception during message handling: > manila.share.drivers.netapp.dataontap.client.api.NaApiError: NetApp API > failed. Reason - 15661:entry doesn't exist > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server Traceback (most > recent call last): > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/oslo_messaging/rpc/server.py", line 165, > in _process_incoming > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server res = > self.dispatcher.dispatch(message) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line > 309, in dispatch > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server return > self._do_dispatch(endpoint, method, ctxt, args) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line > 229, in _do_dispatch > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server result = > func(ctxt, **new_args) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/manager.py", line 216, in > wrapped > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server return > f(self, *args, **kwargs) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/utils.py", line 568, in wrapper > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server return > func(self, *args, **kwargs) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/manager.py", line 3965, in > update_access > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server > share_server_id=share_server_id) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/manager.py", line 3981, in > update_access_for_instances > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server > share_server=share_server) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/access.py", line 302, in > update_access_rules > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server > share_server=share_server) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/access.py", line 341, in > _update_access_rules > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server > share_server) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/access.py", line 409, in > _update_rules_through_share_driver > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server > share_server=share_server > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/cluster_mode/drv_single_svm.py", > line 104, in update_access > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server > delete_rules, **kwargs) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/utils.py", > line 112, in trace_wrapper > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server result = > f(self, *args, **kwargs) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/cluster_mode/lib_base.py", > line 2347, in update_access > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server > helper.update_access(share, share_name, access_rules) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/utils.py", > line 112, in trace_wrapper > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server result = > f(self, *args, **kwargs) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/protocols/base.py", > line 36, in wrapped_func > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server return > source_func(self, *args, **kwargs) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/oslo_concurrency/lockutils.py", line 391, > in inner > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server return > f(*args, **kwargs) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/protocols/base.py", > line 34, in source_func > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server return > f(self, *args, **kwargs) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/protocols/nfs_cmode.py", > line 115, in update_access > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server > auth_methods = self._get_auth_methods() > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/utils.py", > line 112, in trace_wrapper > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server result = > f(self, *args, **kwargs) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/protocols/nfs_cmode.py", > line 222, in _get_auth_methods > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server > kerberos_enabled = self._client.is_kerberos_enabled() > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/utils.py", > line 112, in trace_wrapper > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server result = > f(self, *args, **kwargs) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/client/client_cmode.py", > line 1896, in is_kerberos_enabled > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server result = > self.send_request('kerberos-config-get', api_args) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/client/client_base.py", > line 90, in send_request > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server > use_zapi=use_zapi) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/client/api.py", > line 710, in invoke_successfully > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server na_element, > api_args=api_args, enable_tunneling=enable_tunneling) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File > "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/client/api.py", > line 380, in invoke_successfully > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server raise > NaApiError(code, msg) > 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server > manila.share.drivers.netapp.dataontap.client.api.NaApiError: NetApp API > failed. Reason - 15661:entry doesn't exist > > Please suggest how to mitigate this issue. > > With regards, > Swogat Pradhan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yuta.kazato.nw at hco.ntt.co.jp Mon Sep 26 07:57:29 2022 From: yuta.kazato.nw at hco.ntt.co.jp (Yuta Kazato) Date: Mon, 26 Sep 2022 16:57:29 +0900 Subject: [tacker] Critical bug report and backport the fix Message-ID: <0b6ce55f-e524-1244-0462-69543962c563@hco.ntt.co.jp> Hi tacker team, As you know, new bug report #1990793 [1] related to K8s resource name and v2 API is submitted by Masaki. The bug will appear if K8s resource name contains `-`. I think this is a critical issue because users often set resource names that contain `-`. Fortunately, the fix patch [2] has already been submitted. I suggest that we should backport the fix patch to the stable/zed branch before Zed release. What do you think? [1] https://bugs.launchpad.net/tacker/+bug/1990793 [2] https://review.opendev.org/c/openstack/tacker/+/859206 Yuta -- Yuta Kazato (?? ??) NTT Network Innovation Center. tel: +81-422-59-6754 mail: yuta.kazato.nw at hco.ntt.co.jp From adivya1.singh at gmail.com Mon Sep 26 11:59:32 2022 From: adivya1.singh at gmail.com (Adivya Singh) Date: Mon, 26 Sep 2022 17:29:32 +0530 Subject: Regarding Magnum configuration on Xena Openstack In-Reply-To: References: Message-ID: Hi Team, Any input on this? Regards Adivya Singh On Fri, Sep 23, 2022 at 7:14 PM Adivya Singh wrote: > Hi Team, > > Can we have standard inputs to put and test to implement Containerization > in Xena Openstack installed using ansible > > Regards > Adivya Singh > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jake.yip at ardc.edu.au Mon Sep 26 12:25:19 2022 From: jake.yip at ardc.edu.au (Jake Yip) Date: Mon, 26 Sep 2022 22:25:19 +1000 Subject: [magnum][heat][requirements][release] Potential blocker for release with python-magnumclient 4.0.0 In-Reply-To: References: Message-ID: <5255c632-120f-5a9b-5487-b1af3a572deb@ardc.edu.au> Hi all, Sorry about the lack of reply, it was a extended long weekend over here. Thanks to the heat team for jumping on this and resolving it so quickly. Regards, Jake On 23/9/2022 5:29 pm, Tony Breeds wrote: > Hi all, > ? ? Thanks to the heat team they quickly resolved the problem and the > release and requirements teams can/have moved forward. > > #thanks > > On Wed, 21 Sept 2022 at 15:57, Tony Breeds > wrote: > > Okay cool.? I'll take a punt at removing it > > On Wed, 21 Sept 2022 at 15:50, Brendan Shephard > wrote: > > Hey Tony, > > Thanks for the heads up. We have deprecated support for these > resources some time ago: > https://review.opendev.org/c/openstack/heat/+/433549 > > > I don't believe there are any concerns with removing this > resource and subsequent use of the baymodel API from Heat now. > > Brendan Shephard > > Senior Software Engineer > > Red Hat APAC > > 193 N Quay > > Brisbane City QLD 4000 > > @RedHat Red Hat > Red Hat > > > > > > > On Wed, Sep 21, 2022 at 3:37 PM Tony Breeds > > wrote: > > Hello all, > ? ? In [1] baymodel code was removed, although it still > seems to be > listed in the API-ref. Story [2] states it's been deprecated > for a > long time, but a quick check failed to see this documented > anywhere. > Heat still supports baymodel and the removal is causing > failures. > Blocking the use of python-magnumclient 4.0.0[3] inzed, even > though > the 4.0.0 release is clearly meant for zed. > > I can see a couple of paths forward. > > 0. Remove the documentation in the api-ref for baymodels > 1. Remove the support in heat for baymodels? (I think the newer > clusters API can be used instead?) > 2. Revert the change in magnumclient and re-release etc etc > 3. Keep 4.0.0 for the Antelope release, and reset the stable/zed > branch python-magnumclient to fd0cb1e (before the removal of > baymodels) > > Obviously option 1 looks like the least disruptive change, but > potentially causes a problem for heat depending on the > published state > of baymodel support > > [1] > https://review.opendev.org/c/openstack/python-magnumclient/+/803629 > [2] https://storyboard.openstack.org/#!/story/2009104 > > [3] > https://review.opendev.org/c/openstack/requirements/+/858089 > > > -- > Yours Tony. > > > > -- > Yours Tony. > > > > -- > Yours Tony. From wodel.youchi at gmail.com Mon Sep 26 13:00:35 2022 From: wodel.youchi at gmail.com (wodel youchi) Date: Mon, 26 Sep 2022 14:00:35 +0100 Subject: [kolla-ansible][Yoga] What are the benefits to run libvirt daemon on host rather on a container? Message-ID: Hi, What are the benefits to run libvirt daemon directly on the host rather than on a container? In Yoga's release note, it is said : "Currently this is only supported for fresh deployments without an existing nova_libvirt container" But Also it it is said : "Adds a kolla-ansible nova-libvirt-cleanup command, which may be used to clean up the nova_libvirt container. This may be useful if switching to a host libvirt daemon". Is switching supported? I am in ther verge of upgrading from Xena to Yoga and I ma wondering about this. - What is the gain to use libvirt daemon? - Could the switch be done after the upgrade to Yoga? Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhazan at mandint.org Mon Sep 26 13:28:24 2022 From: mhazan at mandint.org (mhazan at mandint.org) Date: Mon, 26 Sep 2022 15:28:24 +0200 Subject: =?UTF-8?Q?Re=3A_RE=C2=A0=3A_RE_=3A_=5Bneutron=5D=5Bnova=5D=5Bipv?= =?UTF-8?Q?6=5Dinstance_on_compute_node_not_getting_dhcpv6?= In-Reply-To: References: <091032bb358edf4c2a54b50a009ecdbf@mandint.org> Message-ID: <9b46022f739d79dfc3806030bb3ab02e@mandint.org> i've been trying to look where the packets get lost via tcpdump and i found this error "satus-code NoAddrsAvail" but it doesn't seem linked to the old checksum-fill bug. anyone has see this ? ethertype IPv6, IP6 (class 0xc0, flowlabel 0x399d4, hlim 64, next-header UDP (17) payload length: 76) fe80::a9fe:a9fe.dhcpv6-server > fe80::x.dhcpv6-client: [udp sum ok] dhcp6 advertise (xid=2096d0 (client-ID hwaddr/time type 1 time 717510824 fa163e066ac7) (server-ID hwaddr/time type 1 time 664975537 fa163eb2d07e) (status-code NoAddrsAvail)) Le 2022-09-21 09:57, mhazan at mandint.org a ?crit : > no joy with the accept_ra fiddling, the image are all ubuntu or debian cloud-init ready and are working on all in one node but not dedicated compute node, it's as if the dhcpv6 packet (before address is allocated to interface) are not passing between the control node and the dedicated compute node. > > Le 2022-09-20 10:53, Michael Hazan a ?crit : > > Thanks for the suggestion, i will look into the accept_ra setting. However, the very same image that boot on the ? old ? all in one node are getting ipv6 and ipv4 without issue. The network interfaces are configured similarly on all nodes. > > Michael > > DE : Neil Jerram > ENVOY? LE :mardi, 20 septembre 2022 10:47 > ? : Michael Hazan > CC : Lajos Katona; openstack-discuss at lists.openstack.org > OBJET :Re: RE : [neutron][nova][ipv6]instance on compute node not getting dhcpv6 > > They may be outdated now, but I wonder if any of the steps described at https://projectcalico.docs.tigera.io/networking/openstack/ipv6 would help you? In particular, given that you have no route, perhaps you need the accept_ra config. > > Best wishes, > > Neil > > On Tue, Sep 20, 2022 at 9:12 AM Michael Hazan wrote: > > Hello, > > The 3 nodes are running Ubuntu 20.04 and using libvirt. The instance are Ubuntu or debian based. The openstack virtual network is configured with both a v4 and a v6 dhcp pool. The instance should be getting both v4 and v6 (on the same interface) but the instance that are hosted on the compute node only get v4. If i run the dhclient -6 -r the instance actually get it's ipv6 but it's wrongly configured with a /128 (instead of 64) and no route. > > Michael > > DE : Lajos Katona > ENVOY? LE :mardi, 20 septembre 2022 09:39 > ? : mhazan at mandint.org > CC : openstack-discuss at lists.openstack.org > OBJET :Re: [neutron][nova][ipv6]instance on compute node not getting dhcpv6 > > Hi, > > Do you have some more details of your environment, which backend you use? OVS? > > Your VMs have both IPv4 and v6 addresses and you mean that they got IPv4 as expected? > > Lajos > > ezt ?rta (id?pont: 2022. szept. 19., H, 16:19): > > Hello all, > > i manage a small openstack cluster installed via Ubuntu package, it has > been upgraded since the day of Newton and currently running Victoria. it > started as a single node with the basic services installed, later a > dedicated storage node and compute node were added. after upgrading to > victoria, any instance that boot on the dedicated compute node start up > but fails to get it's global ipv6 via stateful dhcp6, only > linklocal(fe80) ip is shown by the instance. The ipv6 is created in > openstack, the dhcpv4 works and there are no issue if the instance boot > on the "old" all in one node. i can manually allocate (by editing the > instance network config file) the ipv6 config and it works. any pointer > as to what could cause this issue ? > > BR, Michael -------------- next part -------------- An HTML attachment was scrubbed... URL: From bence.romsics at gmail.com Mon Sep 26 13:50:59 2022 From: bence.romsics at gmail.com (Bence Romsics) Date: Mon, 26 Sep 2022 15:50:59 +0200 Subject: [neutron] bug deputy report of week 2022-09-19 Message-ID: Hi All, Here comes last week's deputy report (we had only a handful of reports): Unassigned: * https://bugs.launchpad.net/neutron/+bug/1990229 [OVN] Stop using external_ids from SB Chassis table Edit Medium: * https://bugs.launchpad.net/neutron/+bug/1990129 [ovn-octavia-provider] Avoid LB in ERROR status on delete due to LR/LS not found proposed fix: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/857716 Low: * https://bugs.launchpad.net/neutron/+bug/1990285 Help for `network create --external` is incorrect Edit proposed fix: https://review.opendev.org/c/openstack/python-openstackclient/+/858708 Incomplete: * https://bugs.launchpad.net/neutron/+bug/1990561 Network filtering by provider attributes has a race condition with network removal Cheers, Bence From ildiko.vancsa at gmail.com Mon Sep 26 13:53:49 2022 From: ildiko.vancsa at gmail.com (Ildiko Vancsa) Date: Mon, 26 Sep 2022 06:53:49 -0700 Subject: [ptg][edge]OpenStack at the Edge discussions In-Reply-To: <9A553237-F0C1-4E16-BBBB-0D501D4E2EA5@gmail.com> References: <9A553237-F0C1-4E16-BBBB-0D501D4E2EA5@gmail.com> Message-ID: Hi, The OpenInfra Edge Computing Group is currently planning sessions and discussion topics for the PTG. As I mentioned in my previous email, it would be great to discuss OpenStack projects in an edge context as well. If your project has relevant activities, please reply to this thread or add it to the working group?s etherpad, so we can work on joint sessions to discuss challenges and solutions in that area: https://etherpad.opendev.org/p/ecg-ptg-october-2022 Please let me know if you have any questions or comments. Thanks, Ildik? > On Aug 25, 2022, at 16:22, Ildiko Vancsa wrote: > > Hi, > > I?m reaching out to you in preparation to the upcoming PTG. > > The Edge Computing Group already started to prepare for the event and OpenStack came up during our conversations to have cross-project discussions with. The number of edge computing use cases in production is growing and OpenStack is a key infrastructure building block. > > Some edge related discussions regarding the project came up at previous PTGs and it would be great to continue and extend them. We covered areas in networking and looked into storage a little bit, and the question of finding a central place to store edge related documentation also came up. > > To identify new topics and follow up on ones we already started to discuss I added an OpenStack section to the Edge WG?s planning etherpad: https://etherpad.opendev.org/p/ecg-ptg-october-2022 > > If you are working on related features, have requirements or case studies to share, please add them to the above etherpad, so we can discuss them at the PTG and identify areas we can work together on to solve challenges and share information about exiting solutions. > > Please let me know if you have any questions or comments. > > Thanks, > Ildik? > > From allison at openinfra.dev Mon Sep 26 15:08:48 2022 From: allison at openinfra.dev (Allison Price) Date: Mon, 26 Sep 2022 10:08:48 -0500 Subject: [ptls][zed] OpenInfra Live: OpenStack Zed In-Reply-To: <6900286A-BE8F-44AD-93F7-6A1838EE0F36@openinfra.dev> References: <6900286A-BE8F-44AD-93F7-6A1838EE0F36@openinfra.dev> Message-ID: I wanted to resurface this request as we get closer to the release next week to see if any PTLs would like to present their release highlights in an OpenInfra Live episode. Cheers, Allison > On Sep 12, 2022, at 4:20 PM, Allison Price wrote: > > Hi everyone, > > As we get closer to the OpenStack release, I wanted to reach out to see if any PTLs were interested in providing their Zed cycle highlights in an OpenInfra Live[1] episode on Thursday, October 6 at 1400 UTC. Ideally, we would get 4-6 projects represented. Previous examples of OpenStack release episodes can be found here[2] and here[3]. > > Please let me know if you?re interested and I can provide next steps. If you would like to provide a project update but that time doesn?t work for you, please share a recording with me and I can get it added to the project navigator. > > Thanks, > Allison > > > [1] https://openinfra.dev/live/ > [2] https://www.youtube.com/watch?v=hwPfjvshxOM > [3] https://www.youtube.com/watch?v=aqilhEmkEBw -------------- next part -------------- An HTML attachment was scrubbed... URL: From wodel.youchi at gmail.com Mon Sep 26 15:17:30 2022 From: wodel.youchi at gmail.com (wodel youchi) Date: Mon, 26 Sep 2022 16:17:30 +0100 Subject: [kolla-ansible] question about network nodes number Message-ID: Hi, Is it a good idea to configure more than 02 network nodes? Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean-francois.taltavull at elca.ch Mon Sep 26 15:58:35 2022 From: jean-francois.taltavull at elca.ch (=?utf-8?B?VGFsdGF2dWxsIEplYW4tRnJhbsOnb2lz?=) Date: Mon, 26 Sep 2022 15:58:35 +0000 Subject: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number In-Reply-To: References: <2aa77e24a33d48a69032f30b86e9cad8@elca.ch> <1b17c23f8982480db73cf50d04d51af7@elca.ch> <86f048d7931c4cc482f6785437c9b5ea@elca.ch> Message-ID: <671023b5ab3846dfb3a39ef313018eac@elca.ch> Hello Rafael, Thanks for the information about ceilometer patches but for now I?m testing with the credentials in the dynamic pollster config file. I will use barbican when I push all this to production. The keystone authentication performed by the rados gw with the credentials provided by ceilometer still does not work. I wonder if this could be a S3 signature version issue on ceilometer side, that is on S3 client side. This kind of issue exists with the s3 client ?s3cmd? and you have to add ??signature-v2? so that ?s3cmd? works well. What do you think ? Do you know which version of S3 signature ceilometer uses while authenticating ? From: Rafael Weing?rtner Sent: mercredi, 7 septembre 2022 19:23 To: Taltavull Jean-Fran?ois Cc: openstack-discuss Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Jean, there are two problems with the Ceilometer. I just opened the patches to resolve it: - https://review.opendev.org/c/openstack/ceilometer/+/856305 - https://review.opendev.org/c/openstack/ceilometer/+/856304 Without these patches, you might have problems to use Ceilometer with Non-OpenStack dynamic pollsters and barbican credentials. On Wed, Aug 31, 2022 at 3:55 PM Rafael Weing?rtner > wrote: It is the RGW user that you have. This user must have the role that is needed to access the usage feature in RGW. If I am not mistaken, it required an admin user. On Wed, Aug 31, 2022 at 1:54 PM Taltavull Jean-Fran?ois > wrote: Thanks to your help, I am close to the goal. Dynamic pollster is loaded and triggered. But I get a ?Status[403] and reason [Forbidden]? in ceilometer logs while requesting admin/usage. I?m not sure to understand well the auth mechanism. Are we talking about keystone credentials, ec2 credentials, Rados GW user ?... For now, in testing phase, I use ?authentication_parameters?, not barbican. -JF From: Rafael Weing?rtner > Sent: mardi, 30 ao?t 2022 14:17 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Yes, you will need to enable the metric/pollster to be processed. That is done via "polling.yml" file. Also, do not forget that you will need to configure Ceilometer to push this new metric. If you use Gnocchi as the backend, you will need to change/update the gnocchi resource YML file. That file maps resources and metrics in the Gnocchi backend. The configuration resides in Ceilometer. You can create/define new resource types and map them to specific metrics. It depends on how you structure your solution. P.S. You do not need to use "authentication_parameters". You can use the barbican integration to avoid setting your credentials in a file. On Tue, Aug 30, 2022 at 9:11 AM Taltavull Jean-Fran?ois > wrote: Hello, I tried to define a Rados GW dynamic pollster and I can see, in Ceilometer logs, that it?s actually loaded. But it looks like it was not triggered, I see no trace of ceilometer connection in Rados GW logs. My definition: - name: "dynamic.radosgw.usage" sample_type: "gauge" unit: "B" value_attribute: "total.size" url_path: http:///object-store/swift/v1/admin/usage module: "awsauth" authentication_object: "S3Auth" authentication_parameters: xxxxxxxxxxxxx,yyyyyyyyyyyyy, user_id_attribute: "admin" project_id_attribute: "admin" resource_id_attribute: "admin" response_entries_key: "summary" Do I have to set an option in ceilometer.conf, or elsewhere, to get my Rados GW dynamic pollster triggered ? -JF From: Taltavull Jean-Fran?ois Sent: lundi, 29 ao?t 2022 18:41 To: 'Rafael Weing?rtner' > Cc: openstack-discuss > Subject: RE: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number Thanks a lot for your quick answer, Rafael ! I will explore this approach. Jean-Francois From: Rafael Weing?rtner > Sent: lundi, 29 ao?t 2022 17:54 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. You could use a different approach. You can use Dynamic pollster [1], and create your own mechanism to collect data, without needing to change Ceilometer code. Basically all hard-coded pollsters can be converted to a dynamic pollster that is defined in YML. [1] https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollster.html#the-dynamic-pollsters-system-configuration-for-non-openstack-apis On Mon, Aug 29, 2022 at 12:51 PM Taltavull Jean-Fran?ois > wrote: Hi All, In our OpenStack deployment, API endpoints are defined by using URLs instead of port numbers and HAProxy forwards requests to the right bakend after having ACLed the URL. In the case of our object-store service, based on RadosGW, the internal API endpoint is "https:///object-store/swift/v1/AUTH_" When Ceilometer RadosGW pollster tries to connect to the RadosGW admin API with the object-store internal endpoint, the URL becomes https:///admin, as shown by HAProxy logs. This URL does not match any API endpoint from HAProxy point of view. The line of code that rewrites the URL is this one: https://opendev.org/openstack/ceilometer/src/branch/stable/wallaby/ceilometer/objectstore/rgw.py#L81 What would you think of adding a mechanism based on new Ceilometer configuration option(s) to control the URL rewriting ? Our deployment characteristics: - OpenStack release: Wallaby - Ceph and RadosGW version: 15.2.16 - deployment tool: OSA 23.2.1 and ceph-ansible Best regards, Jean-Francois -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Mon Sep 26 17:57:59 2022 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Mon, 26 Sep 2022 19:57:59 +0200 Subject: [kolla-ansible] question about network nodes number In-Reply-To: References: Message-ID: Hi, It is not wrong but you likely do not need it (because you asked). Kind regards, Radek -yoctozepto On Mon, 26 Sept 2022 at 17:18, wodel youchi wrote: > > Hi, > > Is it a good idea to configure more than 02 network nodes? > > Regards. From radoslaw.piliszek at gmail.com Mon Sep 26 18:04:08 2022 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Mon, 26 Sep 2022 20:04:08 +0200 Subject: [kolla-ansible][Yoga] What are the benefits to run libvirt daemon on host rather on a container? In-Reply-To: References: Message-ID: Hi, The golden rule is "if you need to ask, stick to the defaults". ;-) The default is to run libvirtd in a container: it's a proven, working solution. However, some may prefer to run it on the host. There are no extra perks for doing this, unless you want to do it like this (because then you have established the benefits yourself). Kind regards, Radek -yoctozepto On Mon, 26 Sept 2022 at 15:02, wodel youchi wrote: > > Hi, > > What are the benefits to run libvirt daemon directly on the host rather than on a container? > > In Yoga's release note, it is said : > "Currently this is only supported for fresh deployments without an existing nova_libvirt container" > > But Also it it is said : > "Adds a kolla-ansible nova-libvirt-cleanup command, which may be used to clean up the nova_libvirt container. This may be useful if switching to a host libvirt daemon". > > Is switching supported? > > I am in ther verge of upgrading from Xena to Yoga and I ma wondering about this. > - What is the gain to use libvirt daemon? > - Could the switch be done after the upgrade to Yoga? > > > Regards. From yasufum.o at gmail.com Tue Sep 27 01:42:12 2022 From: yasufum.o at gmail.com (Yasufumi Ogawa) Date: Tue, 27 Sep 2022 10:42:12 +0900 Subject: [tacker] Critical bug report and backport the fix In-Reply-To: <0b6ce55f-e524-1244-0462-69543962c563@hco.ntt.co.jp> References: <0b6ce55f-e524-1244-0462-69543962c563@hco.ntt.co.jp> Message-ID: <979284b8-259c-de0e-f93a-ce88db5e8dd4@gmail.com> Hi Yuta, On 2022/09/26 16:57, Yuta Kazato wrote: > Hi tacker team, > > As you know, new bug report #1990793 [1] related to K8s resource name > and v2 API is submitted by Masaki. > The bug will appear if K8s resource name contains `-`. > > I think this is a critical issue because users often set resource names > that contain `-`. Agree. > Fortunately, the fix patch [2] has already been submitted. > > I suggest that we should backport the fix patch to the stable/zed branch > before Zed release. > What do you think? We should fix the issue in stable/zed, or this k8s support doesn't work for many usecases. Yasufumi > > [1] https://bugs.launchpad.net/tacker/+bug/1990793 > [2] https://review.opendev.org/c/openstack/tacker/+/859206 > > Yuta > From ueha.ayumu at fujitsu.com Tue Sep 27 07:46:52 2022 From: ueha.ayumu at fujitsu.com (ueha.ayumu at fujitsu.com) Date: Tue, 27 Sep 2022 07:46:52 +0000 Subject: [tacker] Critical bug report and backport the fix In-Reply-To: <979284b8-259c-de0e-f93a-ce88db5e8dd4@gmail.com> References: <0b6ce55f-e524-1244-0462-69543962c563@hco.ntt.co.jp> <979284b8-259c-de0e-f93a-ce88db5e8dd4@gmail.com> Message-ID: Hi Yuta and Yasufumi, +1 And we have a patch for another critical bug related with pm interface. The bug report [1] and the fix patch [2] have been already posted. This patch also requires a backport to stable/zed. [1] https://bugs.launchpad.net/tacker/+bug/1990828 [2] https://review.opendev.org/c/openstack/tacker/+/859377 Best Regards, Ueha -----Original Message----- From: Yasufumi Ogawa Sent: Tuesday, September 27, 2022 10:42 AM To: openstack-discuss at lists.openstack.org Subject: Re: [tacker] Critical bug report and backport the fix Hi Yuta, On 2022/09/26 16:57, Yuta Kazato wrote: > Hi tacker team, > > As you know, new bug report #1990793 [1] related to K8s resource name > and v2 API is submitted by Masaki. > The bug will appear if K8s resource name contains `-`. > > I think this is a critical issue because users often set resource > names that contain `-`. Agree. > Fortunately, the fix patch [2] has already been submitted. > > I suggest that we should backport the fix patch to the stable/zed > branch before Zed release. > What do you think? We should fix the issue in stable/zed, or this k8s support doesn't work for many usecases. Yasufumi > > [1] https://bugs.launchpad.net/tacker/+bug/1990793 > [2] https://review.opendev.org/c/openstack/tacker/+/859206 > > Yuta > From viroel at gmail.com Tue Sep 27 12:29:00 2022 From: viroel at gmail.com (Douglas Viroel) Date: Tue, 27 Sep 2022 09:29:00 -0300 Subject: Unable to create access rules 'state:error' | Wallaby | Tripelo | NetApp In-Reply-To: References: Message-ID: Hi Swogat, Thanks for reporting the LP bug[1]. We can continue to discuss it there and get some feedback from NetApp developers. Feel free to join our community meeting on Thursday [2] too, where we can further discuss this issue. [1] https://bugs.launchpad.net/manila/+bug/1990693 [2] https://wiki.openstack.org/wiki/Manila/Meetings On Mon, Sep 26, 2022 at 4:29 AM Swogat Pradhan wrote: > Hi, > Can anyone please suggest a fix? > > On Sat, Sep 24, 2022 at 12:43 AM Swogat Pradhan > wrote: > >> Hi, >> When i am trying to create access rule for manila share, the rules are >> created in error state. >> >> Here is the manila share log: >> 2022-09-23 19:03:58.557 43 INFO manila.share.manager >> [req-ef21b41e-efc6-4b7d-9214-3de878d50d7f - - - - -] Updating share status >> 2022-09-23 19:04:01.720 26 INFO manila.share.manager >> [req-3d66c534-a782-414b-a0a7-2bdd57f57b8f - - - - -] Updating share status >> 2022-09-23 19:04:58.554 43 INFO manila.share.manager >> [req-ef21b41e-efc6-4b7d-9214-3de878d50d7f - - - - -] Updating share status >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server >> [req-5f035b4a-7dc8-4e61-bbd5-d38d4b81a00d c1905e3c5a374924980e851840e7f028 >> 5d922243077045c48fe4b075e386551b - - -] Exception during message handling: >> manila.share.drivers.netapp.dataontap.client.api.NaApiError: NetApp API >> failed. Reason - 15661:entry doesn't exist >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server Traceback >> (most recent call last): >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/oslo_messaging/rpc/server.py", line 165, >> in _process_incoming >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server res = >> self.dispatcher.dispatch(message) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line >> 309, in dispatch >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server return >> self._do_dispatch(endpoint, method, ctxt, args) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py", line >> 229, in _do_dispatch >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server result = >> func(ctxt, **new_args) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/manager.py", line 216, in >> wrapped >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server return >> f(self, *args, **kwargs) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/utils.py", line 568, in wrapper >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server return >> func(self, *args, **kwargs) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/manager.py", line 3965, in >> update_access >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server >> share_server_id=share_server_id) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/manager.py", line 3981, in >> update_access_for_instances >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server >> share_server=share_server) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/access.py", line 302, in >> update_access_rules >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server >> share_server=share_server) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/access.py", line 341, in >> _update_access_rules >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server >> share_server) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/access.py", line 409, in >> _update_rules_through_share_driver >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server >> share_server=share_server >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/cluster_mode/drv_single_svm.py", >> line 104, in update_access >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server >> delete_rules, **kwargs) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/utils.py", >> line 112, in trace_wrapper >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server result = >> f(self, *args, **kwargs) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/cluster_mode/lib_base.py", >> line 2347, in update_access >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server >> helper.update_access(share, share_name, access_rules) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/utils.py", >> line 112, in trace_wrapper >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server result = >> f(self, *args, **kwargs) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/protocols/base.py", >> line 36, in wrapped_func >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server return >> source_func(self, *args, **kwargs) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/oslo_concurrency/lockutils.py", line 391, >> in inner >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server return >> f(*args, **kwargs) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/protocols/base.py", >> line 34, in source_func >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server return >> f(self, *args, **kwargs) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/protocols/nfs_cmode.py", >> line 115, in update_access >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server >> auth_methods = self._get_auth_methods() >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/utils.py", >> line 112, in trace_wrapper >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server result = >> f(self, *args, **kwargs) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/protocols/nfs_cmode.py", >> line 222, in _get_auth_methods >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server >> kerberos_enabled = self._client.is_kerberos_enabled() >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/utils.py", >> line 112, in trace_wrapper >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server result = >> f(self, *args, **kwargs) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/client/client_cmode.py", >> line 1896, in is_kerberos_enabled >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server result = >> self.send_request('kerberos-config-get', api_args) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/client/client_base.py", >> line 90, in send_request >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server >> use_zapi=use_zapi) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/client/api.py", >> line 710, in invoke_successfully >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server >> na_element, api_args=api_args, enable_tunneling=enable_tunneling) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server File >> "/usr/lib/python3.6/site-packages/manila/share/drivers/netapp/dataontap/client/api.py", >> line 380, in invoke_successfully >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server raise >> NaApiError(code, msg) >> 2022-09-23 19:04:59.447 43 ERROR oslo_messaging.rpc.server >> manila.share.drivers.netapp.dataontap.client.api.NaApiError: NetApp API >> failed. Reason - 15661:entry doesn't exist >> >> Please suggest how to mitigate this issue. >> >> With regards, >> Swogat Pradhan >> > -- Douglas Viroel - dviroel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdhasman at redhat.com Tue Sep 27 13:39:10 2022 From: rdhasman at redhat.com (Rajat Dhasmana) Date: Tue, 27 Sep 2022 19:09:10 +0530 Subject: [cinder] This week's meeting will be in video+IRC Message-ID: Hello Argonauts, As we keep last meeting of the month in video + IRC mode, this week's meeting (tomorrow) will be held in video + IRC mode with details as follows: Date: 28th September, 2022 Time: 1400 UTC Meeting link: https://bluejeans.com/556681290 IRC Channel: #openstack-meeting-alt Make sure you're connected to both the bluejeans meeting and IRC since we do roll call and also discuss topics on IRC (if the author is more comfortable in written format). Thanks and regards Rajat Dhasmana -------------- next part -------------- An HTML attachment was scrubbed... URL: From surangap at hsenidmobile.com Tue Sep 27 04:24:36 2022 From: surangap at hsenidmobile.com (Suranga Prabhath) Date: Tue, 27 Sep 2022 09:54:36 +0530 Subject: Create the TripleO container images using the command in Xena Message-ID: Hi All, I.m going to install OpenStack Xena on CentOS 8.5. I'm following the TripleO in RDO Xena Release. I followed the RDO guide & enable the required packages. Package installation is successful, but the pulling of the triple container imagers using the command was unsuccessful. Here is the command I use. openstack tripleo container image build --base ubi8 --debug --distro centos \ --namespace tripleoxena --prefix openstack --tag cloudsig-xena \ --push --registry 172.22.1.10::8787 \ --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/dnf/vars:/etc/dnf/vars:z \ --work-dir ~/workdir After executing the above command error was received & I attach it to this mail. Please provide me with a solution for this. -- Thanks & Regards, *Suranga Prabhath,* System Administrator hSenid Software International *Sri Lanka* *M* : +94 00 000 0000 *P* : +94 11 268 3751 *F* : +94 11 268 3951 *Singapore* *M* : +65 00 000 000 *P* : +65 65 332 140 *F* : +65 62 910 023 *www.hSenid.com* *Disclaimer*: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. The content and opinions contained in this email are not necessarily those of hSenid Mobile Solutions. If you have received this email in error please contact the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Stderr: 'time="2022-09-14T16:16:16+05:30" level=debug msg="Pull Policy for pull [ifnewer]"\nerror building at STEP "RUN dnf -y install libqb pacemaker pacemaker-remote pcs procps-ng redis resource-agents stunnel && dnf clean all && rm -rf /var/cache/dnf": error while running runtime: exit status 1\nFailed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/redis/redis-build.log: file already closed\nFailed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/redis/redis-build.log: file already closed\n' 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder Traceback (most recent call last): 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder File "/usr/lib/python3.6/site-packages/tripleo_common/image/builder/buildah.py", line 143, in _generate_container 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder self._find_container_dir(container_name)) 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder File "/usr/lib/python3.6/site-packages/tenacity/__init__.py", line 329, in wrapped_f 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder return self.call(f, *args, **kw) 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder File "/usr/lib/python3.6/site-packages/tenacity/__init__.py", line 409, in call 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder do = self.iter(retry_state=retry_state) 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder File "/usr/lib/python3.6/site-packages/tenacity/__init__.py", line 368, in iter 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder raise retry_exc.reraise() 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder File "/usr/lib/python3.6/site-packages/tenacity/__init__.py", line 186, in reraise 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder raise self.last_attempt.result() 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder File "/usr/lib64/python3.6/concurrent/futures/_base.py", line 425, in result 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder return self.__get_result() 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder File "/usr/lib64/python3.6/concurrent/futures/_base.py", line 384, in __get_result 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder raise self._exception 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder File "/usr/lib/python3.6/site-packages/tenacity/__init__.py", line 412, in call 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder result = fn(*args, **kwargs) 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder File "/usr/lib/python3.6/site-packages/tripleo_common/image/builder/buildah.py", line 196, in build 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder use_standard_locale=True 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder File "/usr/lib/python3.6/site-packages/tripleo_common/utils/process.py", line 53, in execute 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder result = processutils.execute(*cmd, **kwargs) 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder File "/usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py", line 441, in execute 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder cmd=sanitized_cmd) 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder Command: sudo buildah --log-level=debug bud --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/dnf/vars:/etc/dnf/vars:z --loglevel=3 --format docker --tls-verify=False --logfile /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/redis/redis-build.log -t localhost/tripleoxena/openstack-redis:cloudsig-xena /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/redis 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder Exit code: 1 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder Stdout: '' 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder Stderr: 'time="2022-09-14T16:16:16+05:30" level=debug msg="Pull Policy for pull [ifnewer]"\nerror building at STEP "RUN dnf -y install libqb pacemaker pacemaker-remote pcs procps-ng redis resource-agents stunnel && dnf clean all && rm -rf /var/cache/dnf": error while running runtime: exit status 1\nFailed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/redis/redis-build.log: file already closed\nFailed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/redis/redis-build.log: file already closed\n' 2022-09-14 16:18:58.426 2667667 ERROR tripleo_common.image.builder.buildah.BuildahBuilder 2022-09-14 16:19:47.206 2667667 DEBUG oslo_concurrency.processutils [-] CMD "sudo buildah --log-level=debug bud --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/dnf/vars:/etc/dnf/vars:z --loglevel=3 --format docker --tls-verify=False --logfile /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/tripleoclient/tripleoclient-build.log -t localhost/tripleoxena/openstack-tripleoclient:cloudsig-xena /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/tripleoclient" returned: 0 in 557.069s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 2022-09-14 16:19:47.209 2667667 DEBUG tripleo_common.utils.process [-] Execution completed, command line is "sudo buildah --log-level=debug bud --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/dnf/vars:/etc/dnf/vars:z --loglevel=3 --format docker --tls-verify=False --logfile /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/tripleoclient/tripleoclient-build.log -t localhost/tripleoxena/openstack-tripleoclient:cloudsig-xena /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/tripleoclient" execute /usr/lib/python3.6/site-packages/tripleo_common/utils/process.py:55 2022-09-14 16:19:47.209 2667667 DEBUG tripleo_common.utils.process [-] Command stdout is: "" execute /usr/lib/python3.6/site-packages/tripleo_common/utils/process.py:57 2022-09-14 16:19:47.210 2667667 DEBUG tripleo_common.utils.process [-] Command stderr is: "time="2022-09-14T16:10:30+05:30" level=debug msg="Pull Policy for pull [ifnewer]" Failed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/tripleoclient/tripleoclient-build.log: file already closed Failed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/tripleoclient/tripleoclient-build.log: file already closed " execute /usr/lib/python3.6/site-packages/tripleo_common/utils/process.py:58 2022-09-14 16:19:49.096 2667667 DEBUG oslo_concurrency.processutils [-] CMD "sudo buildah --log-level=debug bud --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/dnf/vars:/etc/dnf/vars:z --loglevel=3 --format docker --tls-verify=False --logfile /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/ovn-base/ovn-base-build.log -t localhost/tripleoxena/openstack-ovn-base:cloudsig-xena /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/ovn-base" returned: 0 in 227.527s execute /usr/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 2022-09-14 16:19:49.097 2667667 DEBUG tripleo_common.utils.process [-] Execution completed, command line is "sudo buildah --log-level=debug bud --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/dnf/vars:/etc/dnf/vars:z --loglevel=3 --format docker --tls-verify=False --logfile /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/ovn-base/ovn-base-build.log -t localhost/tripleoxena/openstack-ovn-base:cloudsig-xena /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/ovn-base" execute /usr/lib/python3.6/site-packages/tripleo_common/utils/process.py:55 2022-09-14 16:19:49.097 2667667 DEBUG tripleo_common.utils.process [-] Command stdout is: "" execute /usr/lib/python3.6/site-packages/tripleo_common/utils/process.py:57 2022-09-14 16:19:49.097 2667667 DEBUG tripleo_common.utils.process [-] Command stderr is: "time="2022-09-14T16:16:01+05:30" level=debug msg="Pull Policy for pull [ifnewer]" Failed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/ovn-base/ovn-base-build.log: file already closed Failed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/ovn-base/ovn-base-build.log: file already closed " execute /usr/lib/python3.6/site-packages/tripleo_common/utils/process.py:58 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build [-] Exception occured while running the command: RuntimeError: The following errors were detected during container build(s): Exception information: Unexpected error while running command. Command: sudo buildah --log-level=debug bud --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/dnf/vars:/etc/dnf/vars:z --loglevel=3 --format docker --tls-verify=False --logfile /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb/mariadb-build.log -t localhost/tripleoxena/openstack-mariadb:cloudsig-xena /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb Exit code: 1 Stdout: '' Stderr: 'time="2022-09-14T15:54:53+05:30" level=debug msg="Pull Policy for pull [ifnewer]"\nerror building at STEP "RUN dnf -y install expect galera hostname libqb mariadb mariadb-backup mariadb-server-galera mariadb-server-utils pacemaker pacemaker-remote pcs python3-pynacl resource-agents rsync socat tar && dnf clean all && rm -rf /var/cache/dnf": error while running runtime: exit status 1\nFailed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb/mariadb-build.log: file already closed\nFailed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb/mariadb-build.log: file already closed\n' 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build Traceback (most recent call last): 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build File "/usr/lib/python3.6/site-packages/tripleoclient/command.py", line 34, in run 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build super(Command, self).run(parsed_args) 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build File "/usr/lib/python3.6/site-packages/osc_lib/command/command.py", line 39, in run 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build return super(Command, self).run(parsed_args) 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build File "/usr/lib/python3.6/site-packages/cliff/command.py", line 186, in run 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build return_code = self.take_action(parsed_args) or 0 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build File "/usr/lib/python3.6/site-packages/tripleoclient/v2/tripleo_container_image.py", line 707, in take_action 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build bb.build_all() 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build File "/usr/lib/python3.6/site-packages/tripleo_common/image/builder/buildah.py", line 248, in build_all 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build self._multi_build(containers=containers) 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build File "/usr/lib/python3.6/site-packages/tripleo_common/image/builder/buildah.py", line 362, in _multi_build 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build exceptions='\n'.join(exceptions) 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build RuntimeError: 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build The following errors were detected during container build(s): 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build Exception information: Unexpected error while running command. 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build Command: sudo buildah --log-level=debug bud --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/dnf/vars:/etc/dnf/vars:z --loglevel=3 --format docker --tls-verify=False --logfile /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb/mariadb-build.log -t localhost/tripleoxena/openstack-mariadb:cloudsig-xena /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build Exit code: 1 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build Stdout: '' 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build Stderr: 'time="2022-09-14T15:54:53+05:30" level=debug msg="Pull Policy for pull [ifnewer]"\nerror building at STEP "RUN dnf -y install expect galera hostname libqb mariadb mariadb-backup mariadb-server-galera mariadb-server-utils pacemaker pacemaker-remote pcs python3-pynacl resource-agents rsync socat tar && dnf clean all && rm -rf /var/cache/dnf": error while running runtime: exit status 1\nFailed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb/mariadb-build.log: file already closed\nFailed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb/mariadb-build.log: file already closed\n' 2022-09-14 16:19:49.100 2667667 ERROR tripleoclient.v2.tripleo_container_image.Build 2022-09-14 16:19:49.109 2667667 ERROR openstack [-] The following errors were detected during container build(s): Exception information: Unexpected error while running command. Command: sudo buildah --log-level=debug bud --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/dnf/vars:/etc/dnf/vars:z --loglevel=3 --format docker --tls-verify=False --logfile /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb/mariadb-build.log -t localhost/tripleoxena/openstack-mariadb:cloudsig-xena /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb Exit code: 1 Stdout: '' Stderr: 'time="2022-09-14T15:54:53+05:30" level=debug msg="Pull Policy for pull [ifnewer]"\nerror building at STEP "RUN dnf -y install expect galera hostname libqb mariadb mariadb-backup mariadb-server-galera mariadb-server-utils pacemaker pacemaker-remote pcs python3-pynacl resource-agents rsync socat tar && dnf clean all && rm -rf /var/cache/dnf": error while running runtime: exit status 1\nFailed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb/mariadb-build.log: file already closed\nFailed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb/mariadb-build.log: file already closed\n': RuntimeError: The following errors were detected during container build(s): Exception information: Unexpected error while running command. Command: sudo buildah --log-level=debug bud --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/dnf/vars:/etc/dnf/vars:z --loglevel=3 --format docker --tls-verify=False --logfile /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb/mariadb-build.log -t localhost/tripleoxena/openstack-mariadb:cloudsig-xena /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb Exit code: 1 Stdout: '' Stderr: 'time="2022-09-14T15:54:53+05:30" level=debug msg="Pull Policy for pull [ifnewer]"\nerror building at STEP "RUN dnf -y install expect galera hostname libqb mariadb mariadb-backup mariadb-server-galera mariadb-server-utils pacemaker pacemaker-remote pcs python3-pynacl resource-agents rsync socat tar && dnf clean all && rm -rf /var/cache/dnf": error while running runtime: exit status 1\nFailed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb/mariadb-build.log: file already closed\nFailed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb/mariadb-build.log: file already closed\n' 2022-09-14 16:19:49.109 2667667 ERROR openstack Traceback (most recent call last): 2022-09-14 16:19:49.109 2667667 ERROR openstack File "/usr/lib/python3.6/site-packages/cliff/app.py", line 407, in run_subcommand 2022-09-14 16:19:49.109 2667667 ERROR openstack result = cmd.run(parsed_args) 2022-09-14 16:19:49.109 2667667 ERROR openstack File "/usr/lib/python3.6/site-packages/tripleoclient/command.py", line 34, in run 2022-09-14 16:19:49.109 2667667 ERROR openstack super(Command, self).run(parsed_args) 2022-09-14 16:19:49.109 2667667 ERROR openstack File "/usr/lib/python3.6/site-packages/osc_lib/command/command.py", line 39, in run 2022-09-14 16:19:49.109 2667667 ERROR openstack return super(Command, self).run(parsed_args) 2022-09-14 16:19:49.109 2667667 ERROR openstack File "/usr/lib/python3.6/site-packages/cliff/command.py", line 186, in run 2022-09-14 16:19:49.109 2667667 ERROR openstack return_code = self.take_action(parsed_args) or 0 2022-09-14 16:19:49.109 2667667 ERROR openstack File "/usr/lib/python3.6/site-packages/tripleoclient/v2/tripleo_container_image.py", line 707, in take_action 2022-09-14 16:19:49.109 2667667 ERROR openstack bb.build_all() 2022-09-14 16:19:49.109 2667667 ERROR openstack File "/usr/lib/python3.6/site-packages/tripleo_common/image/builder/buildah.py", line 248, in build_all 2022-09-14 16:19:49.109 2667667 ERROR openstack self._multi_build(containers=containers) 2022-09-14 16:19:49.109 2667667 ERROR openstack File "/usr/lib/python3.6/site-packages/tripleo_common/image/builder/buildah.py", line 362, in _multi_build 2022-09-14 16:19:49.109 2667667 ERROR openstack exceptions='\n'.join(exceptions) 2022-09-14 16:19:49.109 2667667 ERROR openstack RuntimeError: 2022-09-14 16:19:49.109 2667667 ERROR openstack The following errors were detected during container build(s): 2022-09-14 16:19:49.109 2667667 ERROR openstack 2022-09-14 16:19:49.109 2667667 ERROR openstack Exception information: Unexpected error while running command. 2022-09-14 16:19:49.109 2667667 ERROR openstack Command: sudo buildah --log-level=debug bud --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/dnf/vars:/etc/dnf/vars:z --loglevel=3 --format docker --tls-verify=False --logfile /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb/mariadb-build.log -t localhost/tripleoxena/openstack-mariadb:cloudsig-xena /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb 2022-09-14 16:19:49.109 2667667 ERROR openstack Exit code: 1 2022-09-14 16:19:49.109 2667667 ERROR openstack Stdout: '' 2022-09-14 16:19:49.109 2667667 ERROR openstack Stderr: 'time="2022-09-14T15:54:53+05:30" level=debug msg="Pull Policy for pull [ifnewer]"\nerror building at STEP "RUN dnf -y install expect galera hostname libqb mariadb mariadb-backup mariadb-server-galera mariadb-server-utils pacemaker pacemaker-remote pcs python3-pynacl resource-agents rsync socat tar && dnf clean all && rm -rf /var/cache/dnf": error while running runtime: exit status 1\nFailed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb/mariadb-build.log: file already closed\nFailed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb/mariadb-build.log: file already closed\n' 2022-09-14 16:19:49.109 2667667 ERROR openstack 2022-09-14 16:19:49.110 2667667 DEBUG osc_lib.shell [-] clean_up Build: The following errors were detected during container build(s): Exception information: Unexpected error while running command. Command: sudo buildah --log-level=debug bud --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/yum.repos.d:/etc/distro.repos.d:z --volume /etc/pki/rpm-gpg:/etc/pki/rpm-gpg:z --volume /etc/dnf/vars:/etc/dnf/vars:z --loglevel=3 --format docker --tls-verify=False --logfile /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb/mariadb-build.log -t localhost/tripleoxena/openstack-mariadb:cloudsig-xena /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb Exit code: 1 Stdout: '' Stderr: 'time="2022-09-14T15:54:53+05:30" level=debug msg="Pull Policy for pull [ifnewer]"\nerror building at STEP "RUN dnf -y install expect galera hostname libqb mariadb mariadb-backup mariadb-server-galera mariadb-server-utils pacemaker pacemaker-remote pcs python3-pynacl resource-agents rsync socat tar && dnf clean all && rm -rf /var/cache/dnf": error while running runtime: exit status 1\nFailed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb/mariadb-build.log: file already closed\nFailed to write to log, write /home/ceph/workdir/b1245609-dada-47f5-8dea-379c2c78d179/base/mariadb/mariadb-build.log: file already closed\n' clean_up /usr/lib/python3.6/site-packages/osc_lib/shell.py:496 2022-09-14 16:19:49.114 2667667 INFO osc_lib.shell [-] END return value: 1 From rguyett at datto.com Tue Sep 27 13:35:47 2022 From: rguyett at datto.com (Reid Guyett) Date: Tue, 27 Sep 2022 13:35:47 +0000 Subject: [Swift][Ussuri] Erasure Coding Quarantines Message-ID: Hello, I'm not sure if it is related, but I am testing reimaging a node from Ubuntu 18.04 to 20.04 (Cloud Archive Ussuri 2.25.1 to Focal Repo Ussuri 2.25.2) in a 3-node cluster. I have a lot of servers to upgrade, and the environments will be mixed for a while, so I have left this mixed for a week. Now the 18.04 servers are starting to accumulate quarantined EC objects. The 20.04 server has log messages indicating that it is unable to get enough responses from the reconstructor. The 18.04 servers have a couple EC messages. "...liberasurecode[30807]: Invalid fragment header information!" followed by "...object-server: Quarantined object /srv/node/d9/objects-4/10321/b2e/50a3dce515aafc6f222824ec5c7dfb2e/1664002866.33100#8#d.data: Invalid EC metadata at offset 0x0 Is there any thing you can think of that would cause this issue? My steps to reproduce: 1. Create a container in an EC policy 2. Upload object to EC container 3. Wait a bit of time (It looks like the object-server is quarantining but not sure on the trigger) 4. Try to download the file and it will give a 504 Looking at python3-swift dependencies and the package versions I thought may affect this: 20.04 libjerasure2 = 2.0.0+2017.04.10.git.de1739cc84-1 python3-pyeclib = 1.6.0-6build1 python3-xattr = 0.9.6-1.1 18.04 libjerasure2 = 2.0.0+2017.04.10.git.de1739cc84-1 python3-pyeclib = 1.3.1-1ubuntu3 python3-xattr = 0.9.2-0ubuntu1 Thanks! Reid Important Notice: This email is intended to be received only by persons entitled to receive the confidential and legally privileged information it presumptively contains, and this notice constitutes identification as such. Any reading, disclosure, copying, distribution or use of this information by or to someone who is not the intended recipient, is prohibited. If you received this email in error, please notify us immediately at legal at kaseya.com, and then delete it. To opt-out of receiving emails Please click here. The term 'this e-mail' includes any and all attachments. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.rosser at rd.bbc.co.uk Tue Sep 27 15:09:50 2022 From: jonathan.rosser at rd.bbc.co.uk (Jonathan Rosser) Date: Tue, 27 Sep 2022 16:09:50 +0100 Subject: [openstack-ansible] Re: Regarding Magnum configuration on Xena Openstack In-Reply-To: References: Message-ID: Hi Adivya I'm assuming you're talking about a deployment done with openstack-ansible? If you put [openstack-ansible] on the subject line of your email to the list it will hopefully be better seen by the right people. Regards, Jonathan. On 23/09/2022 14:44, Adivya Singh wrote: > Hi Team, > > Can we have standard inputs to put and test to implement > Containerization in Xena Openstack installed using ansible > > Regards > Adivya Singh From adivya1.singh at gmail.com Tue Sep 27 16:38:55 2022 From: adivya1.singh at gmail.com (Adivya Singh) Date: Tue, 27 Sep 2022 22:08:55 +0530 Subject: [openstack-ansible] Re: Regarding Magnum configuration on Xena Openstack In-Reply-To: References: Message-ID: Hi Jonathan, Thanks for correcting it Regards Adivya Singh On Tue, Sep 27, 2022 at 8:45 PM Jonathan Rosser < jonathan.rosser at rd.bbc.co.uk> wrote: > Hi Adivya > > I'm assuming you're talking about a deployment done with > openstack-ansible? If you put [openstack-ansible] on the subject line of > your email to the list it will hopefully be better seen by the right > people. > > Regards, > Jonathan. > > On 23/09/2022 14:44, Adivya Singh wrote: > > Hi Team, > > > > Can we have standard inputs to put and test to implement > > Containerization in Xena Openstack installed using ansible > > > > Regards > > Adivya Singh > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafaelweingartner at gmail.com Wed Sep 28 00:00:56 2022 From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=) Date: Tue, 27 Sep 2022 21:00:56 -0300 Subject: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number In-Reply-To: <671023b5ab3846dfb3a39ef313018eac@elca.ch> References: <2aa77e24a33d48a69032f30b86e9cad8@elca.ch> <1b17c23f8982480db73cf50d04d51af7@elca.ch> <86f048d7931c4cc482f6785437c9b5ea@elca.ch> <671023b5ab3846dfb3a39ef313018eac@elca.ch> Message-ID: Can you show your YML configuration? Also, did you install the AWS authentication module in the container/host where Ceilometer central is running? On Mon, Sep 26, 2022 at 12:58 PM Taltavull Jean-Fran?ois < jean-francois.taltavull at elca.ch> wrote: > Hello Rafael, > > > > Thanks for the information about ceilometer patches but for now I?m > testing with the credentials in the dynamic pollster config file. I will > use barbican when I push all this to production. > > > > The keystone authentication performed by the rados gw with the credentials > provided by ceilometer still does not work. I wonder if this could be a S3 > signature version issue on ceilometer side, that is on S3 client side. This > kind of issue exists with the s3 client ?s3cmd? and you have to add > ??signature-v2? so that ?s3cmd? works well. > > > > What do you think ? Do you know which version of S3 signature ceilometer > uses while authenticating ? > > > > *From:* Rafael Weing?rtner > *Sent:* mercredi, 7 septembre 2022 19:23 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Jean, there are two problems with the Ceilometer. I just opened the > patches to resolve it: > - https://review.opendev.org/c/openstack/ceilometer/+/856305 > > - https://review.opendev.org/c/openstack/ceilometer/+/856304 > > > > Without these patches, you might have problems to use Ceilometer with > Non-OpenStack dynamic pollsters and barbican credentials. > > > > On Wed, Aug 31, 2022 at 3:55 PM Rafael Weing?rtner < > rafaelweingartner at gmail.com> wrote: > > It is the RGW user that you have. This user must have the role that is > needed to access the usage feature in RGW. If I am not mistaken, it > required an admin user. > > > > On Wed, Aug 31, 2022 at 1:54 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Thanks to your help, I am close to the goal. Dynamic pollster is loaded > and triggered. > > > > But I get a ?Status[403] and reason [Forbidden]? in ceilometer logs while > requesting admin/usage. > > > > I?m not sure to understand well the auth mechanism. Are we talking about > keystone credentials, ec2 credentials, Rados GW user ?... > > > > For now, in testing phase, I use ?authentication_parameters?, not barbican. > > > > -JF > > > > *From:* Rafael Weing?rtner > *Sent:* mardi, 30 ao?t 2022 14:17 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Yes, you will need to enable the metric/pollster to be processed. That is > done via "polling.yml" file. Also, do not forget that you will need to > configure Ceilometer to push this new metric. If you use Gnocchi as the > backend, you will need to change/update the gnocchi resource YML file. That > file maps resources and metrics in the Gnocchi backend. The configuration > resides in Ceilometer. You can create/define new resource types and map > them to specific metrics. It depends on how you structure your solution. > > P.S. You do not need to use "authentication_parameters". You can use the > barbican integration to avoid setting your credentials in a file. > > > > On Tue, Aug 30, 2022 at 9:11 AM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Hello, > > > > I tried to define a Rados GW dynamic pollster and I can see, in Ceilometer > logs, that it?s actually loaded. But it looks like it was not triggered, I > see no trace of ceilometer connection in Rados GW logs. > > > > My definition: > > > > - name: "dynamic.radosgw.usage" > > sample_type: "gauge" > > unit: "B" > > value_attribute: "total.size" > > url_path: http:///object-store/swift/v1/admin/usage > > module: "awsauth" > > authentication_object: "S3Auth" > > authentication_parameters: xxxxxxxxxxxxx,yyyyyyyyyyyyy, > > user_id_attribute: "admin" > > project_id_attribute: "admin" > > resource_id_attribute: "admin" > > response_entries_key: "summary" > > > > Do I have to set an option in ceilometer.conf, or elsewhere, to get my > Rados GW dynamic pollster triggered ? > > > > -JF > > > > *From:* Taltavull Jean-Fran?ois > *Sent:* lundi, 29 ao?t 2022 18:41 > *To:* 'Rafael Weing?rtner' > *Cc:* openstack-discuss > *Subject:* RE: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > Thanks a lot for your quick answer, Rafael ! > > I will explore this approach. > > > > Jean-Francois > > > > *From:* Rafael Weing?rtner > *Sent:* lundi, 29 ao?t 2022 17:54 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > You could use a different approach. You can use Dynamic pollster [1], and > create your own mechanism to collect data, without needing to change > Ceilometer code. Basically all hard-coded pollsters can be converted to a > dynamic pollster that is defined in YML. > > > > [1] > https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollster.html#the-dynamic-pollsters-system-configuration-for-non-openstack-apis > > > > > > On Mon, Aug 29, 2022 at 12:51 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Hi All, > > In our OpenStack deployment, API endpoints are defined by using URLs > instead of port numbers and HAProxy forwards requests to the right bakend > after having ACLed the URL. > > In the case of our object-store service, based on RadosGW, the internal > API endpoint is "https:///object-store/swift/v1/AUTH_" > > When Ceilometer RadosGW pollster tries to connect to the RadosGW admin API > with the object-store internal endpoint, the URL becomes > https:///admin, as shown by HAProxy logs. This URL does not match > any API endpoint from HAProxy point of view. The line of code that rewrites > the URL is this one: > https://opendev.org/openstack/ceilometer/src/branch/stable/wallaby/ceilometer/objectstore/rgw.py#L81 > > What would you think of adding a mechanism based on new Ceilometer > configuration option(s) to control the URL rewriting ? > > Our deployment characteristics: > - OpenStack release: Wallaby > - Ceph and RadosGW version: 15.2.16 > - deployment tool: OSA 23.2.1 and ceph-ansible > > > Best regards, > Jean-Francois > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > -- Rafael Weing?rtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From gibi at redhat.com Wed Sep 28 10:34:06 2022 From: gibi at redhat.com (Balazs Gibizer) Date: Wed, 28 Sep 2022 12:34:06 +0200 Subject: [release][requirements][oslo][nova] How to fix a bug and release the fix in oslo.concurrency 4.5.x series Message-ID: Hi, So we have a bug[1] that was fixed in oslo.concurrency on master[2] and released as 5.0.1 and Zed is released with 5.0.1. The issue is present in stable/yoga as well. There we have oslo.concurrency upper constraint pinned to 4.5.0 [3]. 1) How can I backport [2] to the 4.5.x series of oslo.concurrency to release 4.5.2 with the fix? I don't see a branch that I could use for this. 2) If #1) is solved and 4.5.2 is released can I propose an upper constraint bump on stable/yoga from 4.5.0 to 4.5.2? 3) If #1) and #2) is done. Can I propose a minimum requirement bump in nova's requirements.txt from >= 4.5.0 to >= 4.5.2 on stable/yoga? Cheers, gibi [1] https://bugs.launchpad.net/nova/+bug/1988311 [2] https://review.opendev.org/c/openstack/oslo.concurrency/+/855714 [3] https://github.com/openstack/requirements/blob/e64217c9f9316675f57e14ff559bb4de90bc6637/upper-constraints.txt#L26 From rafaelweingartner at gmail.com Wed Sep 28 11:14:43 2022 From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=) Date: Wed, 28 Sep 2022 08:14:43 -0300 Subject: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number In-Reply-To: References: <2aa77e24a33d48a69032f30b86e9cad8@elca.ch> <1b17c23f8982480db73cf50d04d51af7@elca.ch> <86f048d7931c4cc482f6785437c9b5ea@elca.ch> <671023b5ab3846dfb3a39ef313018eac@elca.ch> Message-ID: I think that the last parameter "/object-store/", should be only " ". Can you test it? You are using EC2 credentials to authenticate in RGW. Did you enable the Keystone integration in RGW? Also, as far as I know, this admin endpoint needs a RGW admin. I am not sure if the Keystone and RGW integration would enable/make it possible for someone to authenticate as an admin in RGW. Can you check it? To see if you can call that endpoint with these credentials. On Wed, Sep 28, 2022 at 6:01 AM Taltavull Jean-Fran?ois < jean-francois.taltavull at elca.ch> wrote: > Pollster YML configuration : > > > > --- > > - name: "dynamic.radosgw.usage" > > sample_type: "gauge" > > unit: "B" > > value_attribute: "total.size" > > url_path: http:///object-store/admin/usage > > module: "awsauth" > > authentication_object: "S3Auth" > > authentication_parameters: ,,/object-store/ > > user_id_attribute: "user" > > project_id_attribute: "user" > > resource_id_attribute: "user" > > response_entries_key: "summary" > > > > ACCESS_KEY and SECRET_KEY have been created with ?openstack ec2 > credentials create?. > > > > Ceilometer central is deployed with OSA and it uses awsauth.py module. > > > > > > *From:* Rafael Weing?rtner > *Sent:* mercredi, 28 septembre 2022 02:01 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Can you show your YML configuration? Also, did you install the AWS > authentication module in the container/host where Ceilometer central is > running? > > > > On Mon, Sep 26, 2022 at 12:58 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Hello Rafael, > > > > Thanks for the information about ceilometer patches but for now I?m > testing with the credentials in the dynamic pollster config file. I will > use barbican when I push all this to production. > > > > The keystone authentication performed by the rados gw with the credentials > provided by ceilometer still does not work. I wonder if this could be a S3 > signature version issue on ceilometer side, that is on S3 client side. This > kind of issue exists with the s3 client ?s3cmd? and you have to add > ??signature-v2? so that ?s3cmd? works well. > > > > What do you think ? Do you know which version of S3 signature ceilometer > uses while authenticating ? > > > > *From:* Rafael Weing?rtner > *Sent:* mercredi, 7 septembre 2022 19:23 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Jean, there are two problems with the Ceilometer. I just opened the > patches to resolve it: > - https://review.opendev.org/c/openstack/ceilometer/+/856305 > > - https://review.opendev.org/c/openstack/ceilometer/+/856304 > > > > Without these patches, you might have problems to use Ceilometer with > Non-OpenStack dynamic pollsters and barbican credentials. > > > > On Wed, Aug 31, 2022 at 3:55 PM Rafael Weing?rtner < > rafaelweingartner at gmail.com> wrote: > > It is the RGW user that you have. This user must have the role that is > needed to access the usage feature in RGW. If I am not mistaken, it > required an admin user. > > > > On Wed, Aug 31, 2022 at 1:54 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Thanks to your help, I am close to the goal. Dynamic pollster is loaded > and triggered. > > > > But I get a ?Status[403] and reason [Forbidden]? in ceilometer logs while > requesting admin/usage. > > > > I?m not sure to understand well the auth mechanism. Are we talking about > keystone credentials, ec2 credentials, Rados GW user ?... > > > > For now, in testing phase, I use ?authentication_parameters?, not barbican. > > > > -JF > > > > *From:* Rafael Weing?rtner > *Sent:* mardi, 30 ao?t 2022 14:17 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Yes, you will need to enable the metric/pollster to be processed. That is > done via "polling.yml" file. Also, do not forget that you will need to > configure Ceilometer to push this new metric. If you use Gnocchi as the > backend, you will need to change/update the gnocchi resource YML file. That > file maps resources and metrics in the Gnocchi backend. The configuration > resides in Ceilometer. You can create/define new resource types and map > them to specific metrics. It depends on how you structure your solution. > > P.S. You do not need to use "authentication_parameters". You can use the > barbican integration to avoid setting your credentials in a file. > > > > On Tue, Aug 30, 2022 at 9:11 AM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Hello, > > > > I tried to define a Rados GW dynamic pollster and I can see, in Ceilometer > logs, that it?s actually loaded. But it looks like it was not triggered, I > see no trace of ceilometer connection in Rados GW logs. > > > > My definition: > > > > - name: "dynamic.radosgw.usage" > > sample_type: "gauge" > > unit: "B" > > value_attribute: "total.size" > > url_path: http:///object-store/swift/v1/admin/usage > > module: "awsauth" > > authentication_object: "S3Auth" > > authentication_parameters: xxxxxxxxxxxxx,yyyyyyyyyyyyy, > > user_id_attribute: "admin" > > project_id_attribute: "admin" > > resource_id_attribute: "admin" > > response_entries_key: "summary" > > > > Do I have to set an option in ceilometer.conf, or elsewhere, to get my > Rados GW dynamic pollster triggered ? > > > > -JF > > > > *From:* Taltavull Jean-Fran?ois > *Sent:* lundi, 29 ao?t 2022 18:41 > *To:* 'Rafael Weing?rtner' > *Cc:* openstack-discuss > *Subject:* RE: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > Thanks a lot for your quick answer, Rafael ! > > I will explore this approach. > > > > Jean-Francois > > > > *From:* Rafael Weing?rtner > *Sent:* lundi, 29 ao?t 2022 17:54 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > You could use a different approach. You can use Dynamic pollster [1], and > create your own mechanism to collect data, without needing to change > Ceilometer code. Basically all hard-coded pollsters can be converted to a > dynamic pollster that is defined in YML. > > > > [1] > https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollster.html#the-dynamic-pollsters-system-configuration-for-non-openstack-apis > > > > > > On Mon, Aug 29, 2022 at 12:51 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Hi All, > > In our OpenStack deployment, API endpoints are defined by using URLs > instead of port numbers and HAProxy forwards requests to the right bakend > after having ACLed the URL. > > In the case of our object-store service, based on RadosGW, the internal > API endpoint is "https:///object-store/swift/v1/AUTH_" > > When Ceilometer RadosGW pollster tries to connect to the RadosGW admin API > with the object-store internal endpoint, the URL becomes > https:///admin, as shown by HAProxy logs. This URL does not match > any API endpoint from HAProxy point of view. The line of code that rewrites > the URL is this one: > https://opendev.org/openstack/ceilometer/src/branch/stable/wallaby/ceilometer/objectstore/rgw.py#L81 > > What would you think of adding a mechanism based on new Ceilometer > configuration option(s) to control the URL rewriting ? > > Our deployment characteristics: > - OpenStack release: Wallaby > - Ceph and RadosGW version: 15.2.16 > - deployment tool: OSA 23.2.1 and ceph-ansible > > > Best regards, > Jean-Francois > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > -- Rafael Weing?rtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From wodel.youchi at gmail.com Wed Sep 28 11:38:03 2022 From: wodel.youchi at gmail.com (wodel youchi) Date: Wed, 28 Sep 2022 12:38:03 +0100 Subject: [kolla-ansible] Error while upgrading from xena to yoga Message-ID: Hi, I am trying to upgrade from xena to yoga. I have created a test environment that resembles the production one using VMs. The deployment consists of 03 controllers and 03 compute/storage nodes. I am using Rokcy 8 as my base OS and I am using another VM as a deployer with a local registry. I followed the documentation here : https://docs.openstack.org/kolla-ansible/yoga/user/operating-kolla.html The precheks went well, but when deploying I got the following error : fatal: [ctrl02]: FAILED! => {"changed": true, "msg": "'Traceback (most > recent call last):\\n > File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line > 268, in _raise_for_status\\n > response.raise_for_status()\\n File > \"/usr/local/lib/python3.6/site-packages/requests/models.py\", line 960, > in raise_for_status\\n raise HTTPError(http_error_msg, response=self)\\n > requests.exceptions.HTTPError: 404 Client Error: Not Found for url: > http+docker://localhost/v1.41/images/create?tag=yoga& > fromImage=10.50.0.252%3A4000%2Fopenstack.kolla%2Fcentos-source-rabbitmq\\n\\nDuring > handling of the above exception, > another exception occurred:\\n\\nTraceback (most recent call last):\\n > File > \"/tmp/ansible_kolla_docker_payload_8hum8og4/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", > line 381, > in main\\n File > \"/tmp/ansible_kolla_docker_payload_8hum8og4/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", > > line 660, in recreate_or_restart_container\\n self.pull_image()\\n > File > \"/tmp/ansible_kolla_docker_payload_8hum8og4/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", > > line 451, in pull_image\\n repository=image, tag=tag, stream=True\\n > File \ > "/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line 430, > in pull\\n self._raise_for_status(response)\\n > File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", line > 270, in _raise_for_status\\n > raise create_api_error_from_http_exception(e)\\n File > \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", > line 31, in create_api_error_from_http_exception\\n raise cls(e, > response=response, explanation=explanation)\\n > docker.errors.NotFound: 404 Client Error for > http+docker://localhost/v1.41/images/create?tag=yoga > &fromImage=10.50.0.252%3A4000%2Fopenstack.kolla%2Fcentos-source-rabbitmq: > Not Found > *(\"manifest for > 10.50.0.252:4000/openstack.kolla/centos-source-rabbitmq:yoga > not > found: manifest unknown: manifest unknown\")\\n'"}* > [deployer at deployer yoga]$ sudo docker images | grep yoga | grep rabbit quay.io/openstack.kolla/centos-source-rabbitmq yoga 4ea3207bfef3 33 hours ago 920MB 10.50.0.252:4000/openstack.kolla/centos-source-rabbitmq yoga 4ea3207bfef3 33 hours ago 920MB Any ideas? Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephenfin at redhat.com Wed Sep 28 12:11:45 2022 From: stephenfin at redhat.com (Stephen Finucane) Date: Wed, 28 Sep 2022 13:11:45 +0100 Subject: [release][requirements][oslo][nova] How to fix a bug and release the fix in oslo.concurrency 4.5.x series In-Reply-To: References: Message-ID: On Wed, 2022-09-28 at 12:34 +0200, Balazs Gibizer wrote: > Hi, > > So we have a bug[1] that was fixed in oslo.concurrency on master[2] and > released as 5.0.1 and Zed is released with 5.0.1. > > The issue is present in stable/yoga as well. There we have > oslo.concurrency upper constraint pinned to 4.5.0 [3]. > > 1) How can I backport [2] to the 4.5.x series of oslo.concurrency to > release 4.5.2 with the fix? I don't see a branch that I could use for > this. I don't have answers for you but I can say that the reason for this is because oslo.concurrency has been using the independent release model for some time now [1]. We won't have stable branches (or any kind of long-lived release branch) without manually creating them. Stephen [1] https://review.opendev.org/c/openstack/releases/+/764624 > > 2) If #1) is solved and 4.5.2 is released can I propose an upper > constraint bump on stable/yoga from 4.5.0 to 4.5.2? > > 3) If #1) and #2) is done. Can I propose a minimum requirement bump in > nova's requirements.txt from >= 4.5.0 to >= 4.5.2 on stable/yoga? > > Cheers, > gibi > > [1] https://bugs.launchpad.net/nova/+bug/1988311 > [2] https://review.opendev.org/c/openstack/oslo.concurrency/+/855714 > [3] > https://github.com/openstack/requirements/blob/e64217c9f9316675f57e14ff559bb4de90bc6637/upper-constraints.txt#L26 > > > From elod.illes at est.tech Wed Sep 28 12:40:04 2022 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Wed, 28 Sep 2022 14:40:04 +0200 Subject: [release][requirements][oslo][nova] How to fix a bug and release the fix in oslo.concurrency 4.5.x series In-Reply-To: References: Message-ID: Hi Gibi, Thanks for raising this issue here! Some notes: - oslo.concurrency is in *independent* release model, thus it does not have stable branches since stable/victoria (when the model change happened) - for openstack projects (that are not in independent release model) upper constraint changes are generated automatically - for projects in independent release model these should be proposed manually for stable branches, if needed - lower constraints can only be bumped at development phase according to the policy [1] (i guess because this could lead to issues during upgrades of an existing environment), however, probably after weighing the circumstances, an exception can be granted See my comments to your questions inline. (Anyone from Release Management or Requirements team: correct me if i am wrong with them) [1] https://docs.openstack.org/project-team-guide/dependency-management.html#stable-branch-maintenance Cheers, El?d On 2022. 09. 28. 12:34, Balazs Gibizer wrote: > Hi, > > So we have a bug[1] that was fixed in oslo.concurrency on master[2] > and released as 5.0.1 and Zed is released with 5.0.1. > > The issue is present in stable/yoga as well. There we have > oslo.concurrency upper constraint pinned to 4.5.0 [3]. > > 1) How can I backport [2] to the 4.5.x series of oslo.concurrency to > release 4.5.2 with the fix? I don't see a branch that I could use for > this. Either we use 5.0.1 for stable/yoga as well, or a bugfix/4.5.0 branch can be cut (e.g. from 4.5.1 release) and 4.5.2 released from that (maybe need to be released by hand as our tools don't support this if i'm not mistaken) > > 2) If #1) is solved and 4.5.2 is released can I propose an upper > constraint bump on stable/yoga from 4.5.0 to 4.5.2? As I wrote above, i think it's possible, but needs to be done manually > > 3) If #1) and #2) is done. Can I propose a minimum requirement bump in > nova's requirements.txt from >= 4.5.0 to >= 4.5.2 on stable/yoga? If i understand correctly, simply bumping the upper constraint would resolve our issue, so this is probably not needed. But as I said above, it can be considered to raise it anyway. > > Cheers, > gibi > > [1] https://bugs.launchpad.net/nova/+bug/1988311 > [2] https://review.opendev.org/c/openstack/oslo.concurrency/+/855714 > [3] > https://github.com/openstack/requirements/blob/e64217c9f9316675f57e14ff559bb4de90bc6637/upper-constraints.txt#L26 > > > From fungi at yuggoth.org Wed Sep 28 12:53:20 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 28 Sep 2022 12:53:20 +0000 Subject: [release][requirements][oslo][nova] How to fix a bug and release the fix in oslo.concurrency 4.5.x series In-Reply-To: References: Message-ID: <20220928125319.l5k5wzozrmsxm5n4@yuggoth.org> On 2022-09-28 14:40:04 +0200 (+0200), El?d Ill?s wrote: [...] > - for projects in independent release model these should be proposed > manually for stable branches, if needed > - lower constraints can only be bumped at development phase according to the > policy [...] Another way to phrase this is that "independent release" dependencies are essentially external dependencies, so you treat them the same way as dependencies which are developed outside our community when it comes to constraints changes and the like. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From satish.txt at gmail.com Wed Sep 28 13:41:29 2022 From: satish.txt at gmail.com (Satish Patel) Date: Wed, 28 Sep 2022 09:41:29 -0400 Subject: [kolla-ansible] Error while upgrading from xena to yoga In-Reply-To: References: Message-ID: Did you build an image for yoga before upgrading? I am reading this line so asking a question - *10.50.0.252:4000/openstack.kolla/centos-source-rabbitmq:yoga not found * On Wed, Sep 28, 2022 at 7:40 AM wodel youchi wrote: > Hi, > > I am trying to upgrade from xena to yoga. I have created a test > environment that resembles the production one using VMs. > The deployment consists of 03 controllers and 03 compute/storage nodes. > I am using Rokcy 8 as my base OS and I am using another VM as a deployer > with a local registry. > > > > I followed the documentation here : > https://docs.openstack.org/kolla-ansible/yoga/user/operating-kolla.html > The precheks went well, but when deploying I got the following error : > > fatal: [ctrl02]: FAILED! => {"changed": true, "msg": "'Traceback (most >> recent call last):\\n >> File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", >> line 268, in _raise_for_status\\n >> response.raise_for_status()\\n File >> \"/usr/local/lib/python3.6/site-packages/requests/models.py\", line 960, >> in raise_for_status\\n raise HTTPError(http_error_msg, >> response=self)\\n >> requests.exceptions.HTTPError: 404 Client Error: Not Found for url: >> http+docker://localhost/v1.41/images/create?tag=yoga& >> fromImage=10.50.0.252%3A4000%2Fopenstack.kolla%2Fcentos-source-rabbitmq\\n\\nDuring >> handling of the above exception, >> another exception occurred:\\n\\nTraceback (most recent call last):\\n >> File >> \"/tmp/ansible_kolla_docker_payload_8hum8og4/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", >> line 381, >> in main\\n File >> \"/tmp/ansible_kolla_docker_payload_8hum8og4/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", >> >> line 660, in recreate_or_restart_container\\n self.pull_image()\\n >> File >> \"/tmp/ansible_kolla_docker_payload_8hum8og4/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", >> >> line 451, in pull_image\\n repository=image, tag=tag, stream=True\\n >> File \ >> "/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line 430, >> in pull\\n self._raise_for_status(response)\\n >> File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", >> line 270, in _raise_for_status\\n >> raise create_api_error_from_http_exception(e)\\n File >> \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", >> line 31, in create_api_error_from_http_exception\\n raise cls(e, >> response=response, explanation=explanation)\\n >> docker.errors.NotFound: 404 Client Error for >> http+docker://localhost/v1.41/images/create?tag=yoga >> &fromImage=10.50.0.252%3A4000%2Fopenstack.kolla%2Fcentos-source-rabbitmq: >> Not Found >> *(\"manifest for >> 10.50.0.252:4000/openstack.kolla/centos-source-rabbitmq:yoga >> not >> found: manifest unknown: manifest unknown\")\\n'"}* >> > > > [deployer at deployer yoga]$ sudo docker images | grep yoga | grep rabbit > quay.io/openstack.kolla/centos-source-rabbitmq > yoga 4ea3207bfef3 33 hours ago 920MB > 10.50.0.252:4000/openstack.kolla/centos-source-rabbitmq > yoga 4ea3207bfef3 33 hours ago 920MB > > > Any ideas? > > Regards. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From senrique at redhat.com Wed Sep 28 13:47:42 2022 From: senrique at redhat.com (Sofia Enriquez) Date: Wed, 28 Sep 2022 10:47:42 -0300 Subject: [cinder] Bug Report 09-28-2022 Message-ID: This is a bug report from 09-21-2022 to 09-28-2022. Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting ----------------------------------------------------------------------------------------- Low - https://bugs.launchpad.net/cinder/+bug/1990053 "Cinder NFS backend with image-volume cache creates volumes with the wrong size." Unassigned. - https://bugs.launchpad.net/cinder/+bug/1990846 "NetApp FC: Not filterings WWPNs correctly in multiple HA pair deployments." Unassigned. - https://bugs.launchpad.net/cinder/+bug/1990946 "Dell PowerFlex: Size shown for a volume doesn't match powerflex backend allocation." Unassigned. - https://bugs.launchpad.net/cinder/+bug/1991068 "Duplicate config option barbican in tempest plugins cinder and barbican." Unassigned. - https://bugs.launchpad.net/os-brick/+bug/1939390 "Missing dependency: lsscsi." Unassigned. Incomplete - https://bugs.launchpad.net/os-brick/+bug/1990825 "Should wait for all devices to appear?." Cheers, -- Sof?a Enriquez she/her Software Engineer Red Hat PnT IRC: @enriquetaso @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean-francois.taltavull at elca.ch Wed Sep 28 09:01:55 2022 From: jean-francois.taltavull at elca.ch (=?utf-8?B?VGFsdGF2dWxsIEplYW4tRnJhbsOnb2lz?=) Date: Wed, 28 Sep 2022 09:01:55 +0000 Subject: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number In-Reply-To: References: <2aa77e24a33d48a69032f30b86e9cad8@elca.ch> <1b17c23f8982480db73cf50d04d51af7@elca.ch> <86f048d7931c4cc482f6785437c9b5ea@elca.ch> <671023b5ab3846dfb3a39ef313018eac@elca.ch> Message-ID: Pollster YML configuration : --- - name: "dynamic.radosgw.usage" sample_type: "gauge" unit: "B" value_attribute: "total.size" url_path: http:///object-store/admin/usage module: "awsauth" authentication_object: "S3Auth" authentication_parameters: ,,/object-store/ user_id_attribute: "user" project_id_attribute: "user" resource_id_attribute: "user" response_entries_key: "summary" ACCESS_KEY and SECRET_KEY have been created with ?openstack ec2 credentials create?. Ceilometer central is deployed with OSA and it uses awsauth.py module. From: Rafael Weing?rtner Sent: mercredi, 28 septembre 2022 02:01 To: Taltavull Jean-Fran?ois Cc: openstack-discuss Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Can you show your YML configuration? Also, did you install the AWS authentication module in the container/host where Ceilometer central is running? On Mon, Sep 26, 2022 at 12:58 PM Taltavull Jean-Fran?ois > wrote: Hello Rafael, Thanks for the information about ceilometer patches but for now I?m testing with the credentials in the dynamic pollster config file. I will use barbican when I push all this to production. The keystone authentication performed by the rados gw with the credentials provided by ceilometer still does not work. I wonder if this could be a S3 signature version issue on ceilometer side, that is on S3 client side. This kind of issue exists with the s3 client ?s3cmd? and you have to add ??signature-v2? so that ?s3cmd? works well. What do you think ? Do you know which version of S3 signature ceilometer uses while authenticating ? From: Rafael Weing?rtner > Sent: mercredi, 7 septembre 2022 19:23 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Jean, there are two problems with the Ceilometer. I just opened the patches to resolve it: - https://review.opendev.org/c/openstack/ceilometer/+/856305 - https://review.opendev.org/c/openstack/ceilometer/+/856304 Without these patches, you might have problems to use Ceilometer with Non-OpenStack dynamic pollsters and barbican credentials. On Wed, Aug 31, 2022 at 3:55 PM Rafael Weing?rtner > wrote: It is the RGW user that you have. This user must have the role that is needed to access the usage feature in RGW. If I am not mistaken, it required an admin user. On Wed, Aug 31, 2022 at 1:54 PM Taltavull Jean-Fran?ois > wrote: Thanks to your help, I am close to the goal. Dynamic pollster is loaded and triggered. But I get a ?Status[403] and reason [Forbidden]? in ceilometer logs while requesting admin/usage. I?m not sure to understand well the auth mechanism. Are we talking about keystone credentials, ec2 credentials, Rados GW user ?... For now, in testing phase, I use ?authentication_parameters?, not barbican. -JF From: Rafael Weing?rtner > Sent: mardi, 30 ao?t 2022 14:17 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Yes, you will need to enable the metric/pollster to be processed. That is done via "polling.yml" file. Also, do not forget that you will need to configure Ceilometer to push this new metric. If you use Gnocchi as the backend, you will need to change/update the gnocchi resource YML file. That file maps resources and metrics in the Gnocchi backend. The configuration resides in Ceilometer. You can create/define new resource types and map them to specific metrics. It depends on how you structure your solution. P.S. You do not need to use "authentication_parameters". You can use the barbican integration to avoid setting your credentials in a file. On Tue, Aug 30, 2022 at 9:11 AM Taltavull Jean-Fran?ois > wrote: Hello, I tried to define a Rados GW dynamic pollster and I can see, in Ceilometer logs, that it?s actually loaded. But it looks like it was not triggered, I see no trace of ceilometer connection in Rados GW logs. My definition: - name: "dynamic.radosgw.usage" sample_type: "gauge" unit: "B" value_attribute: "total.size" url_path: http:///object-store/swift/v1/admin/usage module: "awsauth" authentication_object: "S3Auth" authentication_parameters: xxxxxxxxxxxxx,yyyyyyyyyyyyy, user_id_attribute: "admin" project_id_attribute: "admin" resource_id_attribute: "admin" response_entries_key: "summary" Do I have to set an option in ceilometer.conf, or elsewhere, to get my Rados GW dynamic pollster triggered ? -JF From: Taltavull Jean-Fran?ois Sent: lundi, 29 ao?t 2022 18:41 To: 'Rafael Weing?rtner' > Cc: openstack-discuss > Subject: RE: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number Thanks a lot for your quick answer, Rafael ! I will explore this approach. Jean-Francois From: Rafael Weing?rtner > Sent: lundi, 29 ao?t 2022 17:54 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. You could use a different approach. You can use Dynamic pollster [1], and create your own mechanism to collect data, without needing to change Ceilometer code. Basically all hard-coded pollsters can be converted to a dynamic pollster that is defined in YML. [1] https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollster.html#the-dynamic-pollsters-system-configuration-for-non-openstack-apis On Mon, Aug 29, 2022 at 12:51 PM Taltavull Jean-Fran?ois > wrote: Hi All, In our OpenStack deployment, API endpoints are defined by using URLs instead of port numbers and HAProxy forwards requests to the right bakend after having ACLed the URL. In the case of our object-store service, based on RadosGW, the internal API endpoint is "https:///object-store/swift/v1/AUTH_" When Ceilometer RadosGW pollster tries to connect to the RadosGW admin API with the object-store internal endpoint, the URL becomes https:///admin, as shown by HAProxy logs. This URL does not match any API endpoint from HAProxy point of view. The line of code that rewrites the URL is this one: https://opendev.org/openstack/ceilometer/src/branch/stable/wallaby/ceilometer/objectstore/rgw.py#L81 What would you think of adding a mechanism based on new Ceilometer configuration option(s) to control the URL rewriting ? Our deployment characteristics: - OpenStack release: Wallaby - Ceph and RadosGW version: 15.2.16 - deployment tool: OSA 23.2.1 and ceph-ansible Best regards, Jean-Francois -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephenfin at redhat.com Wed Sep 28 14:10:58 2022 From: stephenfin at redhat.com (Stephen Finucane) Date: Wed, 28 Sep 2022 15:10:58 +0100 Subject: [release][requirements][oslo][nova] How to fix a bug and release the fix in oslo.concurrency 4.5.x series In-Reply-To: <20220928125319.l5k5wzozrmsxm5n4@yuggoth.org> References: <20220928125319.l5k5wzozrmsxm5n4@yuggoth.org> Message-ID: On Wed, 2022-09-28 at 12:53 +0000, Jeremy Stanley wrote: > On 2022-09-28 14:40:04 +0200 (+0200), El?d Ill?s wrote: > [...] > > - for projects in independent release model these should be proposed > > manually for stable branches, if needed > > - lower constraints can only be bumped at development phase according to the > > policy > [...] > > Another way to phrase this is that "independent release" > dependencies are essentially external dependencies, so you treat > them the same way as dependencies which are developed outside our > community when it comes to constraints changes and the like. Makes sense. Is there a guide for how we can create our release branches (a la the 'feature/r1' branch for 'openstacksdk')? I assume infra need to be involved and we can't do this via a patch somewhere? Stephen From fungi at yuggoth.org Wed Sep 28 14:21:03 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Wed, 28 Sep 2022 14:21:03 +0000 Subject: [release][requirements][oslo][nova] How to fix a bug and release the fix in oslo.concurrency 4.5.x series In-Reply-To: References: <20220928125319.l5k5wzozrmsxm5n4@yuggoth.org> Message-ID: <20220928142102.lbrdtfz6w2h6q5ed@yuggoth.org> On 2022-09-28 15:10:58 +0100 (+0100), Stephen Finucane wrote: [...] > Makes sense. Is there a guide for how we can create our release > branches (a la the 'feature/r1' branch for 'openstacksdk')? I > assume infra need to be involved and we can't do this via a patch > somewhere? Yes, you can adjust the Gerrit ACL for that project in order to grant branch creation (or deletion) privileges to any specific group: https://docs.opendev.org/opendev/infra-manual/latest/drivers.html Also, for OpenStack projects specifically, their ACLs all inherit from a general ACL which grants those permissions to the Release Managers: https://opendev.org/openstack/project-config/src/commit/e21759f/gerrit/acls/openstack/oslo.concurrency.config#L2 https://opendev.org/openstack/project-config/src/commit/0d066f9/gerrit/acls/openstack/meta-config.config -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From wodel.youchi at gmail.com Wed Sep 28 15:51:41 2022 From: wodel.youchi at gmail.com (wodel youchi) Date: Wed, 28 Sep 2022 16:51:41 +0100 Subject: [kolla-ansible] How to recover from unfinished upgrade Message-ID: Hi, I am testing the upgrade from xena to yoga and I made a mistake in globals.yml, I forgot to specify the correct name of gnocchi ceph pool, so my deployment went wrong. I interrupted the deployment Ctrl+C I corrected the mistake, then I restarted the upgrade and it got stuck somewhere else, but I couldn't find where, I interrupted then restarted the deployment again and it got stuck at the same place. My questions : - Is there a way to rollback the upgrade in case of a problem, then start over? - What is the best way to restart a broken upgrade process? Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wodel.youchi at gmail.com Wed Sep 28 15:57:36 2022 From: wodel.youchi at gmail.com (wodel youchi) Date: Wed, 28 Sep 2022 16:57:36 +0100 Subject: [Solved][kolla-ansible] Error while upgrading from xena to yoga In-Reply-To: References: Message-ID: Hi, Thanks for the help, I searched a bit, and I think I got it, the downloaded image was broken somehow, I redid the pull of that image then pushed it again in my local registry and it worked. docker pull quay.io/openstack.kolla/centos-source-rabbitmq:yoga docker tag quay.io/openstack.kolla/centos-source-rabbitmq:yoga 10.50.0.252:4000/openstack.kolla/centos-source-rabbitmq:yoga docker push 10.50.0.252:4000/openstack.kolla/centos-source-rabbitmq:yoga Regards. Le mer. 28 sept. 2022 ? 14:41, Satish Patel a ?crit : > Did you build an image for yoga before upgrading? I am reading this line > so asking a question - *10.50.0.252:4000/openstack.kolla/centos-source-rabbitmq:yoga > not > found * > > On Wed, Sep 28, 2022 at 7:40 AM wodel youchi > wrote: > >> Hi, >> >> I am trying to upgrade from xena to yoga. I have created a test >> environment that resembles the production one using VMs. >> The deployment consists of 03 controllers and 03 compute/storage nodes. >> I am using Rokcy 8 as my base OS and I am using another VM as a deployer >> with a local registry. >> >> >> >> I followed the documentation here : >> https://docs.openstack.org/kolla-ansible/yoga/user/operating-kolla.html >> The precheks went well, but when deploying I got the following error : >> >> fatal: [ctrl02]: FAILED! => {"changed": true, "msg": "'Traceback (most >>> recent call last):\\n >>> File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", >>> line 268, in _raise_for_status\\n >>> response.raise_for_status()\\n File >>> \"/usr/local/lib/python3.6/site-packages/requests/models.py\", line 960, >>> in raise_for_status\\n raise HTTPError(http_error_msg, >>> response=self)\\n >>> requests.exceptions.HTTPError: 404 Client Error: Not Found for url: >>> http+docker://localhost/v1.41/images/create?tag=yoga& >>> fromImage=10.50.0.252%3A4000%2Fopenstack.kolla%2Fcentos-source-rabbitmq\\n\\nDuring >>> handling of the above exception, >>> another exception occurred:\\n\\nTraceback (most recent call last):\\n >>> File >>> \"/tmp/ansible_kolla_docker_payload_8hum8og4/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\", >>> line 381, >>> in main\\n File >>> \"/tmp/ansible_kolla_docker_payload_8hum8og4/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", >>> >>> line 660, in recreate_or_restart_container\\n self.pull_image()\\n >>> File >>> \"/tmp/ansible_kolla_docker_payload_8hum8og4/ansible_kolla_docker_payload.zip/ansible/module_utils/kolla_docker_worker.py\", >>> >>> line 451, in pull_image\\n repository=image, tag=tag, stream=True\\n >>> File \ >>> "/usr/local/lib/python3.6/site-packages/docker/api/image.py\", line 430, >>> in pull\\n self._raise_for_status(response)\\n >>> File \"/usr/local/lib/python3.6/site-packages/docker/api/client.py\", >>> line 270, in _raise_for_status\\n >>> raise create_api_error_from_http_exception(e)\\n File >>> \"/usr/local/lib/python3.6/site-packages/docker/errors.py\", >>> line 31, in create_api_error_from_http_exception\\n raise cls(e, >>> response=response, explanation=explanation)\\n >>> docker.errors.NotFound: 404 Client Error for >>> http+docker://localhost/v1.41/images/create?tag=yoga >>> &fromImage=10.50.0.252%3A4000%2Fopenstack.kolla%2Fcentos-source-rabbitmq: >>> Not Found >>> *(\"manifest for >>> 10.50.0.252:4000/openstack.kolla/centos-source-rabbitmq:yoga >>> not >>> found: manifest unknown: manifest unknown\")\\n'"}* >>> >> >> >> [deployer at deployer yoga]$ sudo docker images | grep yoga | grep rabbit >> quay.io/openstack.kolla/centos-source-rabbitmq >> yoga 4ea3207bfef3 33 hours ago 920MB >> 10.50.0.252:4000/openstack.kolla/centos-source-rabbitmq >> yoga 4ea3207bfef3 33 hours ago 920MB >> >> >> Any ideas? >> >> Regards. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean-francois.taltavull at elca.ch Wed Sep 28 16:21:07 2022 From: jean-francois.taltavull at elca.ch (=?utf-8?B?VGFsdGF2dWxsIEplYW4tRnJhbsOnb2lz?=) Date: Wed, 28 Sep 2022 16:21:07 +0000 Subject: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number In-Reply-To: References: <2aa77e24a33d48a69032f30b86e9cad8@elca.ch> <1b17c23f8982480db73cf50d04d51af7@elca.ch> <86f048d7931c4cc482f6785437c9b5ea@elca.ch> <671023b5ab3846dfb3a39ef313018eac@elca.ch> Message-ID: <33f69d386462450b9964b2ed78284d57@elca.ch> I removed trailing ?/object-store/? from the last value of authentication_parameters I also: - disabled s3 keystone auth in RGW - created a RGW ?admin? user with the right privileges to allow admin API calls - put RGW in debug mode And here is what I get in RGW logs: get_usage string_to_sign=GET Wed, 28 Sep 2022 16:15:45 GMT /admin/usage get_usage server signature=BlaBlaBlaBla get_usage client signature=BloBloBlo get_usage compare=-75 get_usage rgw::auth::s3::LocalEngine denied with reason=-2027 get_usage rgw::auth::s3::AWSAuthStrategy denied with reason=-2027 get_usage rgw::auth::StrategyRegistry::s3_main_strategy_t: trying rgw::auth::s3::AWSAuthStrategy get_usage rgw::auth::s3::AWSAuthStrategy: trying rgw::auth::s3::LocalEngine From: Rafael Weing?rtner Sent: mercredi, 28 septembre 2022 13:15 To: Taltavull Jean-Fran?ois Cc: openstack-discuss Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. I think that the last parameter "/object-store/", should be only "". Can you test it? You are using EC2 credentials to authenticate in RGW. Did you enable the Keystone integration in RGW? Also, as far as I know, this admin endpoint needs a RGW admin. I am not sure if the Keystone and RGW integration would enable/make it possible for someone to authenticate as an admin in RGW. Can you check it? To see if you can call that endpoint with these credentials. On Wed, Sep 28, 2022 at 6:01 AM Taltavull Jean-Fran?ois > wrote: Pollster YML configuration : --- - name: "dynamic.radosgw.usage" sample_type: "gauge" unit: "B" value_attribute: "total.size" url_path: http:///object-store/admin/usage module: "awsauth" authentication_object: "S3Auth" authentication_parameters: ,,/object-store/ user_id_attribute: "user" project_id_attribute: "user" resource_id_attribute: "user" response_entries_key: "summary" ACCESS_KEY and SECRET_KEY have been created with ?openstack ec2 credentials create?. Ceilometer central is deployed with OSA and it uses awsauth.py module. From: Rafael Weing?rtner > Sent: mercredi, 28 septembre 2022 02:01 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Can you show your YML configuration? Also, did you install the AWS authentication module in the container/host where Ceilometer central is running? On Mon, Sep 26, 2022 at 12:58 PM Taltavull Jean-Fran?ois > wrote: Hello Rafael, Thanks for the information about ceilometer patches but for now I?m testing with the credentials in the dynamic pollster config file. I will use barbican when I push all this to production. The keystone authentication performed by the rados gw with the credentials provided by ceilometer still does not work. I wonder if this could be a S3 signature version issue on ceilometer side, that is on S3 client side. This kind of issue exists with the s3 client ?s3cmd? and you have to add ??signature-v2? so that ?s3cmd? works well. What do you think ? Do you know which version of S3 signature ceilometer uses while authenticating ? From: Rafael Weing?rtner > Sent: mercredi, 7 septembre 2022 19:23 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Jean, there are two problems with the Ceilometer. I just opened the patches to resolve it: - https://review.opendev.org/c/openstack/ceilometer/+/856305 - https://review.opendev.org/c/openstack/ceilometer/+/856304 Without these patches, you might have problems to use Ceilometer with Non-OpenStack dynamic pollsters and barbican credentials. On Wed, Aug 31, 2022 at 3:55 PM Rafael Weing?rtner > wrote: It is the RGW user that you have. This user must have the role that is needed to access the usage feature in RGW. If I am not mistaken, it required an admin user. On Wed, Aug 31, 2022 at 1:54 PM Taltavull Jean-Fran?ois > wrote: Thanks to your help, I am close to the goal. Dynamic pollster is loaded and triggered. But I get a ?Status[403] and reason [Forbidden]? in ceilometer logs while requesting admin/usage. I?m not sure to understand well the auth mechanism. Are we talking about keystone credentials, ec2 credentials, Rados GW user ?... For now, in testing phase, I use ?authentication_parameters?, not barbican. -JF From: Rafael Weing?rtner > Sent: mardi, 30 ao?t 2022 14:17 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Yes, you will need to enable the metric/pollster to be processed. That is done via "polling.yml" file. Also, do not forget that you will need to configure Ceilometer to push this new metric. If you use Gnocchi as the backend, you will need to change/update the gnocchi resource YML file. That file maps resources and metrics in the Gnocchi backend. The configuration resides in Ceilometer. You can create/define new resource types and map them to specific metrics. It depends on how you structure your solution. P.S. You do not need to use "authentication_parameters". You can use the barbican integration to avoid setting your credentials in a file. On Tue, Aug 30, 2022 at 9:11 AM Taltavull Jean-Fran?ois > wrote: Hello, I tried to define a Rados GW dynamic pollster and I can see, in Ceilometer logs, that it?s actually loaded. But it looks like it was not triggered, I see no trace of ceilometer connection in Rados GW logs. My definition: - name: "dynamic.radosgw.usage" sample_type: "gauge" unit: "B" value_attribute: "total.size" url_path: http:///object-store/swift/v1/admin/usage module: "awsauth" authentication_object: "S3Auth" authentication_parameters: xxxxxxxxxxxxx,yyyyyyyyyyyyy, user_id_attribute: "admin" project_id_attribute: "admin" resource_id_attribute: "admin" response_entries_key: "summary" Do I have to set an option in ceilometer.conf, or elsewhere, to get my Rados GW dynamic pollster triggered ? -JF From: Taltavull Jean-Fran?ois Sent: lundi, 29 ao?t 2022 18:41 To: 'Rafael Weing?rtner' > Cc: openstack-discuss > Subject: RE: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number Thanks a lot for your quick answer, Rafael ! I will explore this approach. Jean-Francois From: Rafael Weing?rtner > Sent: lundi, 29 ao?t 2022 17:54 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. You could use a different approach. You can use Dynamic pollster [1], and create your own mechanism to collect data, without needing to change Ceilometer code. Basically all hard-coded pollsters can be converted to a dynamic pollster that is defined in YML. [1] https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollster.html#the-dynamic-pollsters-system-configuration-for-non-openstack-apis On Mon, Aug 29, 2022 at 12:51 PM Taltavull Jean-Fran?ois > wrote: Hi All, In our OpenStack deployment, API endpoints are defined by using URLs instead of port numbers and HAProxy forwards requests to the right bakend after having ACLed the URL. In the case of our object-store service, based on RadosGW, the internal API endpoint is "https:///object-store/swift/v1/AUTH_" When Ceilometer RadosGW pollster tries to connect to the RadosGW admin API with the object-store internal endpoint, the URL becomes https:///admin, as shown by HAProxy logs. This URL does not match any API endpoint from HAProxy point of view. The line of code that rewrites the URL is this one: https://opendev.org/openstack/ceilometer/src/branch/stable/wallaby/ceilometer/objectstore/rgw.py#L81 What would you think of adding a mechanism based on new Ceilometer configuration option(s) to control the URL rewriting ? Our deployment characteristics: - OpenStack release: Wallaby - Ceph and RadosGW version: 15.2.16 - deployment tool: OSA 23.2.1 and ceph-ansible Best regards, Jean-Francois -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafaelweingartner at gmail.com Wed Sep 28 16:39:54 2022 From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=) Date: Wed, 28 Sep 2022 13:39:54 -0300 Subject: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number In-Reply-To: <33f69d386462450b9964b2ed78284d57@elca.ch> References: <2aa77e24a33d48a69032f30b86e9cad8@elca.ch> <1b17c23f8982480db73cf50d04d51af7@elca.ch> <86f048d7931c4cc482f6785437c9b5ea@elca.ch> <671023b5ab3846dfb3a39ef313018eac@elca.ch> <33f69d386462450b9964b2ed78284d57@elca.ch> Message-ID: Can you also execute the following: ``` python import awsauth awsauth ``` That will output a path, and then you can `cat `, example: `cat /var/lib/kolla/venv/lib/python3.8/site-packages/awsauth.py` On Wed, Sep 28, 2022 at 1:21 PM Taltavull Jean-Fran?ois < jean-francois.taltavull at elca.ch> wrote: > I removed trailing ?/object-store/? from the last value of > authentication_parameters > > > > I also: > > - disabled s3 keystone auth in RGW > > - created a RGW ?admin? user with the right privileges to allow admin API > calls > > - put RGW in debug mode > > > > And here is what I get in RGW logs: > > > > get_usage > string_to_sign=GET > Wed, > 28 Sep 2022 16:15:45 > GMT > /admin/usage > > get_usage server signature=BlaBlaBlaBla > > get_usage client signature=BloBloBlo > > get_usage compare=-75 > > get_usage rgw::auth::s3::LocalEngine denied with reason=-2027 > > get_usage rgw::auth::s3::AWSAuthStrategy denied with reason=-2027 > > get_usage rgw::auth::StrategyRegistry::s3_main_strategy_t: trying > rgw::auth::s3::AWSAuthStrategy > > get_usage rgw::auth::s3::AWSAuthStrategy: trying rgw::auth::s3::LocalEngine > > > > *From:* Rafael Weing?rtner > *Sent:* mercredi, 28 septembre 2022 13:15 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > I think that the last parameter "/object-store/", should be only " > ". Can you test it? > > > > > > You are using EC2 credentials to authenticate in RGW. Did you enable the > Keystone integration in RGW? > > Also, as far as I know, this admin endpoint needs a RGW admin. I am not > sure if the Keystone and RGW integration would enable/make it possible for > someone to authenticate as an admin in RGW. Can you check it? To see if you > can call that endpoint with these credentials. > > > > On Wed, Sep 28, 2022 at 6:01 AM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Pollster YML configuration : > > > > --- > > - name: "dynamic.radosgw.usage" > > sample_type: "gauge" > > unit: "B" > > value_attribute: "total.size" > > url_path: http:///object-store/admin/usage > > module: "awsauth" > > authentication_object: "S3Auth" > > authentication_parameters: ,,/object-store/ > > user_id_attribute: "user" > > project_id_attribute: "user" > > resource_id_attribute: "user" > > response_entries_key: "summary" > > > > ACCESS_KEY and SECRET_KEY have been created with ?openstack ec2 > credentials create?. > > > > Ceilometer central is deployed with OSA and it uses awsauth.py module. > > > > > > *From:* Rafael Weing?rtner > *Sent:* mercredi, 28 septembre 2022 02:01 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Can you show your YML configuration? Also, did you install the AWS > authentication module in the container/host where Ceilometer central is > running? > > > > On Mon, Sep 26, 2022 at 12:58 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Hello Rafael, > > > > Thanks for the information about ceilometer patches but for now I?m > testing with the credentials in the dynamic pollster config file. I will > use barbican when I push all this to production. > > > > The keystone authentication performed by the rados gw with the credentials > provided by ceilometer still does not work. I wonder if this could be a S3 > signature version issue on ceilometer side, that is on S3 client side. This > kind of issue exists with the s3 client ?s3cmd? and you have to add > ??signature-v2? so that ?s3cmd? works well. > > > > What do you think ? Do you know which version of S3 signature ceilometer > uses while authenticating ? > > > > *From:* Rafael Weing?rtner > *Sent:* mercredi, 7 septembre 2022 19:23 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Jean, there are two problems with the Ceilometer. I just opened the > patches to resolve it: > - https://review.opendev.org/c/openstack/ceilometer/+/856305 > > - https://review.opendev.org/c/openstack/ceilometer/+/856304 > > > > Without these patches, you might have problems to use Ceilometer with > Non-OpenStack dynamic pollsters and barbican credentials. > > > > On Wed, Aug 31, 2022 at 3:55 PM Rafael Weing?rtner < > rafaelweingartner at gmail.com> wrote: > > It is the RGW user that you have. This user must have the role that is > needed to access the usage feature in RGW. If I am not mistaken, it > required an admin user. > > > > On Wed, Aug 31, 2022 at 1:54 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Thanks to your help, I am close to the goal. Dynamic pollster is loaded > and triggered. > > > > But I get a ?Status[403] and reason [Forbidden]? in ceilometer logs while > requesting admin/usage. > > > > I?m not sure to understand well the auth mechanism. Are we talking about > keystone credentials, ec2 credentials, Rados GW user ?... > > > > For now, in testing phase, I use ?authentication_parameters?, not barbican. > > > > -JF > > > > *From:* Rafael Weing?rtner > *Sent:* mardi, 30 ao?t 2022 14:17 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Yes, you will need to enable the metric/pollster to be processed. That is > done via "polling.yml" file. Also, do not forget that you will need to > configure Ceilometer to push this new metric. If you use Gnocchi as the > backend, you will need to change/update the gnocchi resource YML file. That > file maps resources and metrics in the Gnocchi backend. The configuration > resides in Ceilometer. You can create/define new resource types and map > them to specific metrics. It depends on how you structure your solution. > > P.S. You do not need to use "authentication_parameters". You can use the > barbican integration to avoid setting your credentials in a file. > > > > On Tue, Aug 30, 2022 at 9:11 AM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Hello, > > > > I tried to define a Rados GW dynamic pollster and I can see, in Ceilometer > logs, that it?s actually loaded. But it looks like it was not triggered, I > see no trace of ceilometer connection in Rados GW logs. > > > > My definition: > > > > - name: "dynamic.radosgw.usage" > > sample_type: "gauge" > > unit: "B" > > value_attribute: "total.size" > > url_path: http:///object-store/swift/v1/admin/usage > > module: "awsauth" > > authentication_object: "S3Auth" > > authentication_parameters: xxxxxxxxxxxxx,yyyyyyyyyyyyy, > > user_id_attribute: "admin" > > project_id_attribute: "admin" > > resource_id_attribute: "admin" > > response_entries_key: "summary" > > > > Do I have to set an option in ceilometer.conf, or elsewhere, to get my > Rados GW dynamic pollster triggered ? > > > > -JF > > > > *From:* Taltavull Jean-Fran?ois > *Sent:* lundi, 29 ao?t 2022 18:41 > *To:* 'Rafael Weing?rtner' > *Cc:* openstack-discuss > *Subject:* RE: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > Thanks a lot for your quick answer, Rafael ! > > I will explore this approach. > > > > Jean-Francois > > > > *From:* Rafael Weing?rtner > *Sent:* lundi, 29 ao?t 2022 17:54 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > You could use a different approach. You can use Dynamic pollster [1], and > create your own mechanism to collect data, without needing to change > Ceilometer code. Basically all hard-coded pollsters can be converted to a > dynamic pollster that is defined in YML. > > > > [1] > https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollster.html#the-dynamic-pollsters-system-configuration-for-non-openstack-apis > > > > > > On Mon, Aug 29, 2022 at 12:51 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Hi All, > > In our OpenStack deployment, API endpoints are defined by using URLs > instead of port numbers and HAProxy forwards requests to the right bakend > after having ACLed the URL. > > In the case of our object-store service, based on RadosGW, the internal > API endpoint is "https:///object-store/swift/v1/AUTH_" > > When Ceilometer RadosGW pollster tries to connect to the RadosGW admin API > with the object-store internal endpoint, the URL becomes > https:///admin, as shown by HAProxy logs. This URL does not match > any API endpoint from HAProxy point of view. The line of code that rewrites > the URL is this one: > https://opendev.org/openstack/ceilometer/src/branch/stable/wallaby/ceilometer/objectstore/rgw.py#L81 > > What would you think of adding a mechanism based on new Ceilometer > configuration option(s) to control the URL rewriting ? > > Our deployment characteristics: > - OpenStack release: Wallaby > - Ceph and RadosGW version: 15.2.16 > - deployment tool: OSA 23.2.1 and ceph-ansible > > > Best regards, > Jean-Francois > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > -- Rafael Weing?rtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Wed Sep 28 21:00:11 2022 From: satish.txt at gmail.com (Satish Patel) Date: Wed, 28 Sep 2022 17:00:11 -0400 Subject: [kolla][ssl] Deploy third-party SSL for HAProxy Message-ID: Folks, I have GoDaddy SSL cert and trying to deploy with kolla but little big confused with this doc https://docs.openstack.org/kolla-ansible/latest/admin/tls.html I have a single interface for internal/external vip and try following config to deploy SSL/TLS for haproxy and other services. --- openstack_release: "wallaby" kolla_internal_vip_address: "10.73.0.180" kolla_external_vip_address: "{{ kolla_internal_vip_address }}" network_interface: "eth0" neutron_external_interface: "eth1" # TLS kolla_enable_tls_internal: "yes" kolla_certificates_dir: "/etc/kolla/certificates" kolla_internal_fqdn_cert: "{{ kolla_certificates_dir }}/my_company_cert.pem" When i run "kolla-ansible -i multinode certificates" command it deploy something but then i found it generated certificate itself (self-sign) in /etc/kolla/cacertificates directory and override my third-party cert When I tried in the browser https://foobar.com it didn't connect to 443 port that means it did not enable SSL. Am I missing something here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From senrique at redhat.com Wed Sep 28 22:14:25 2022 From: senrique at redhat.com (Sofia Enriquez) Date: Wed, 28 Sep 2022 19:14:25 -0300 Subject: =?UTF-8?B?W2NpbmRlcl1bb3V0cmVhY2h5XSBJbnRlcm5zaGlwIHByb3Bvc2FsIPCfkrs=?= Message-ID: Hello Argonauts, As discussed in Cinder Meeting two weeks ago[1], I've created the internship proposal Etherpad[2]. Please, feel free to add comments and in particular, if you have any suggestions on the benefits please add them. The deadline is this Friday. Thanks in advance, Cheers, Sofi [1] https://meetings.opendev.org/meetings/cinder/2022/cinder.2022-09-21-14.00.log.html#l-82 [2] https://etherpad.opendev.org/p/outreachy-cinder-dec-2022-to-march-2023 -- Sof?a Enriquez she/her Software Engineer Red Hat PnT IRC: @enriquetaso @RedHat Red Hat Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmann at ghanshyammann.com Thu Sep 29 01:44:43 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Wed, 28 Sep 2022 18:44:43 -0700 Subject: [all][tc] Technical Committee next weekly meeting on 2022 Sept 29 at 1500 UTC Message-ID: <18386eae14f.ae5803f4712506.6112411485456441088@ghanshyammann.com> Hello Everyone, Below is the agenda for Tomorrow's TC meeting scheduled at 1500 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting * Roll call * Follow up on past action items * Gate health check ** Bare 'recheck' state *** https://etherpad.opendev.org/p/recheck-weekly-summary * 2023.1 cycle PTG Planning ** TC + Leaders interaction sessions *** https://etherpad.opendev.org/p/tc-leaders-interaction-2023-1 ** TC PTG etherpad *** https://etherpad.opendev.org/p/tc-2023-1-ptg ** Schedule 'operator hours' *** https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030301.html * 2023.1 cycle Technical Election & Leaderless projects ** Leaderless projects *** https://etherpad.opendev.org/p/2023.1-leaderless ** TC Chair election * Open Reviews ** https://review.opendev.org/q/projects:openstack/governance+is:open -gmann From fereshtehloghmani at gmail.com Thu Sep 29 06:57:30 2022 From: fereshtehloghmani at gmail.com (fereshteh loghmani) Date: Thu, 29 Sep 2022 10:27:30 +0330 Subject: No subject Message-ID: in kolla ansible (release: victoria) when i run command: " kolla-ansible -i ./multinode bootstrap-servers --limit compute1 " i receive this error: TASK [baremetal : Enable docker apt repository] * fatal: [R5DG1.cpaas.ir]: FAILED! => {"changed": false, "msg": "apt cache update failed"} could you please help me how could i fix this? ( my compute1 has the ubuntu20 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Thu Sep 29 07:59:55 2022 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 29 Sep 2022 09:59:55 +0200 Subject: No subject In-Reply-To: References: Message-ID: It means your host could not run ``apt update``. Try it by yourself, it's probably a network issue. Radek -yoctozepto On Thu, 29 Sept 2022 at 08:59, fereshteh loghmani wrote: > > in kolla ansible (release: victoria) when i run command: " kolla-ansible -i ./multinode bootstrap-servers --limit compute1 " > i receive this error: > TASK [baremetal : Enable docker apt repository] * fatal: [R5DG1.cpaas.ir]: FAILED! => {"changed": false, "msg": "apt cache update failed"} > could you please help me how could i fix this? > ( my compute1 has the ubuntu20 ) From radoslaw.piliszek at gmail.com Thu Sep 29 08:01:25 2022 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 29 Sep 2022 10:01:25 +0200 Subject: [kolla][ssl] Deploy third-party SSL for HAProxy In-Reply-To: References: Message-ID: The ``certificates`` command is for generating certificates (the help is explicit on it). For all-things-deployment one just needs to run ``deploy`` again. Radek -yoctozepto On Wed, 28 Sept 2022 at 23:02, Satish Patel wrote: > > Folks, > > I have GoDaddy SSL cert and trying to deploy with kolla but little big confused with this doc https://docs.openstack.org/kolla-ansible/latest/admin/tls.html > > I have a single interface for internal/external vip and try following config to deploy SSL/TLS for haproxy and other services. > > --- > openstack_release: "wallaby" > kolla_internal_vip_address: "10.73.0.180" > kolla_external_vip_address: "{{ kolla_internal_vip_address }}" > network_interface: "eth0" > neutron_external_interface: "eth1" > > # TLS > kolla_enable_tls_internal: "yes" > kolla_certificates_dir: "/etc/kolla/certificates" > kolla_internal_fqdn_cert: "{{ kolla_certificates_dir }}/my_company_cert.pem" > > > When i run "kolla-ansible -i multinode certificates" command it deploy something but then i found it generated certificate itself (self-sign) in /etc/kolla/cacertificates directory and override my third-party cert > > When I tried in the browser https://foobar.com it didn't connect to 443 port that means it did not enable SSL. Am I missing something here? > > > From sbauza at redhat.com Thu Sep 29 08:14:19 2022 From: sbauza at redhat.com (Sylvain Bauza) Date: Thu, 29 Sep 2022 10:14:19 +0200 Subject: [nova][placement] add your PTG topics before Oct-06 please ! Message-ID: Hi folks, as I said in the nova meeting, I'd like to create an agenda for our PTG topics. Given the PTG is in 3 weeks, please provide your topics you'd like to discuss at the PTG in [1] so I could look at them and try to provide an agenda for them. Eventually, I'd love to have most of the topics by Oct 6th as I said in the title so the agenda would be on the Friday Oct 7th. Also, if you can't be in the Nova PTG sessions for all the PTG schedule (between Tues and Fri for Nova), just add in the topic when you would like to be around. Thanks, -Sylvain [1] https://etherpad.opendev.org/p/nova-antelope-ptg -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramishra at redhat.com Thu Sep 29 08:43:37 2022 From: ramishra at redhat.com (Rabi Mishra) Date: Thu, 29 Sep 2022 14:13:37 +0530 Subject: [TripleO] TripleO Antelope PTG Topics In-Reply-To: References: Message-ID: Hi All, Gentle reminder. As we're only three weeks away, if you've any topics to discuss at the PTG, please add them to the etherpad by this weekend. -- Regards, Rabi Mishra On Tue, Sep 13, 2022 at 5:28 PM Rabi Mishra wrote: > Hi All, > > Please add your session proposals to this etherpad[1]. We'll reserve time > allocation based on proposed topics and work out a schedule in the coming > weeks. > > [1] https://etherpad.opendev.org/p/tripleo-antelope-topics > > -- > Regards, > Rabi Mishra > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Thu Sep 29 09:03:06 2022 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 29 Sep 2022 05:03:06 -0400 Subject: [kolla][ssl] Deploy third-party SSL for HAProxy In-Reply-To: References: Message-ID: Thanks Rados?aw, I figured out later that "certificates" are used to generate self-signed certificates. I have a similar ip address on both internal/external vip in that case how does it work? I am seeing in doc which is saying. "If there is only a single network configured in your topology (as opposed to separate internal and external networks), TLS can only be enabled using the internal network configuration variables." Based on the above sentence I should use only kolla_enable_tls_internal: "yes" in global.yml correct? no need to use external. I am trying to find a good working example to deploy third party SSL which is not in the official doc. On Thu, Sep 29, 2022 at 4:01 AM Rados?aw Piliszek < radoslaw.piliszek at gmail.com> wrote: > The ``certificates`` command is for generating certificates (the help > is explicit on it). > For all-things-deployment one just needs to run ``deploy`` again. > > Radek > -yoctozepto > > On Wed, 28 Sept 2022 at 23:02, Satish Patel wrote: > > > > Folks, > > > > I have GoDaddy SSL cert and trying to deploy with kolla but little big > confused with this doc > https://docs.openstack.org/kolla-ansible/latest/admin/tls.html > > > > I have a single interface for internal/external vip and try following > config to deploy SSL/TLS for haproxy and other services. > > > > --- > > openstack_release: "wallaby" > > kolla_internal_vip_address: "10.73.0.180" > > kolla_external_vip_address: "{{ kolla_internal_vip_address }}" > > network_interface: "eth0" > > neutron_external_interface: "eth1" > > > > # TLS > > kolla_enable_tls_internal: "yes" > > kolla_certificates_dir: "/etc/kolla/certificates" > > kolla_internal_fqdn_cert: "{{ kolla_certificates_dir > }}/my_company_cert.pem" > > > > > > When i run "kolla-ansible -i multinode certificates" command it deploy > something but then i found it generated certificate itself (self-sign) in > /etc/kolla/cacertificates directory and override my third-party cert > > > > When I tried in the browser https://foobar.com it didn't connect to 443 > port that means it did not enable SSL. Am I missing something here? > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Thu Sep 29 09:08:19 2022 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 29 Sep 2022 11:08:19 +0200 Subject: [kolla][ssl] Deploy third-party SSL for HAProxy In-Reply-To: References: Message-ID: On Thu, 29 Sept 2022 at 11:03, Satish Patel wrote: > I have a similar ip address on both internal/external vip in that case how does it work? I am seeing in doc which is saying. I don't know a good definition for a "similar" IP address so I assume you mean the *same* for the rest of the answer. If that is not the case, i.e., you have two addresses on the same network, then the sentence below does not apply. The docs could be worded better mayhaps... > "If there is only a single network configured in your topology (as opposed to separate internal and external networks), TLS can only be enabled using the internal network configuration variables." > > Based on the above sentence I should use only kolla_enable_tls_internal: "yes" in global.yml correct? no need to use external. Yes, when addresses are the same, k-a detects that and simply configures everything to the kolla_enable_tls_internal and family settings. The external family of vars should be left unset (i.e. not included in your globals.yml). Radek -yoctozepto From satish.txt at gmail.com Thu Sep 29 09:22:22 2022 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 29 Sep 2022 05:22:22 -0400 Subject: [kolla][ssl] Deploy third-party SSL for HAProxy In-Reply-To: References: Message-ID: Hi Radoslaw, I meant the same ip address for internal/external vips. like the following snippet. 10.73.0.180 is used for internal and external addresses. kolla_internal_vip_address: "10.73.0.180" kolla_external_vip_address: "{{ kolla_internal_vip_address }}" network_interface: "eth0" neutron_external_interface: "eth1" I did the following in global.yml and ran "deploy" but it stuck somewhere in nova. I am looking for errors to find out what happened. Am I missing something in the following configuration? kolla_enable_tls_internal: "yes" kolla_certificates_dir: "/etc/kolla/certificates" kolla_internal_fqdn_cert: "{{ kolla_certificates_dir }}/my_company_certificate.pem" Is the above going to enable SSL for all communications or just horizon web GUI? On Thu, Sep 29, 2022 at 5:08 AM Rados?aw Piliszek < radoslaw.piliszek at gmail.com> wrote: > On Thu, 29 Sept 2022 at 11:03, Satish Patel wrote: > > I have a similar ip address on both internal/external vip in that case > how does it work? I am seeing in doc which is saying. > > I don't know a good definition for a "similar" IP address so I assume > you mean the *same* for the rest of the answer. If that is not the > case, i.e., you have two addresses on the same network, then the > sentence below does not apply. The docs could be worded better > mayhaps... > > > "If there is only a single network configured in your topology (as > opposed to separate internal and external networks), TLS can only be > enabled using the internal network configuration variables." > > > > Based on the above sentence I should use only > kolla_enable_tls_internal: "yes" in global.yml correct? no need to use > external. > > Yes, when addresses are the same, k-a detects that and simply > configures everything to the kolla_enable_tls_internal and family > settings. The external family of vars should be left unset (i.e. not > included in your globals.yml). > > Radek > -yoctozepto > -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Thu Sep 29 09:25:52 2022 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 29 Sep 2022 11:25:52 +0200 Subject: [kolla][ssl] Deploy third-party SSL for HAProxy In-Reply-To: References: Message-ID: On Thu, 29 Sept 2022 at 11:22, Satish Patel wrote: > I did the following in global.yml and ran "deploy" but it stuck somewhere in nova. I am looking for errors to find out what happened. Am I missing something in the following configuration? It looks correct at first glance. You need to be more specific about the issue at hand. The error message, circumstances... > kolla_enable_tls_internal: "yes" > kolla_certificates_dir: "/etc/kolla/certificates" > kolla_internal_fqdn_cert: "{{ kolla_certificates_dir }}/my_company_certificate.pem" > > Is the above going to enable SSL for all communications or just horizon web GUI? All communications via haproxy. Radek -yoctozepto From satish.txt at gmail.com Thu Sep 29 09:32:04 2022 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 29 Sep 2022 05:32:04 -0400 Subject: [kolla][ssl] Deploy third-party SSL for HAProxy In-Reply-To: References: Message-ID: Hi Rados?aw, Following error encounter if i turn on above 3 lines to implement SSL. if i remove then the error disappears. https://paste.opendev.org/show/bOqOAQyqni0nJcWbUuv9/ TASK [nova-cell : Waiting for nova-compute services to register themselves] ****************************************************************************************************** skipping: [kolla-comp-2] skipping: [kolla-infra-1] fatal: [kolla-comp-1 -> kolla-infra-1]: FAILED! => {"msg": "The conditional check '(nova_compute_services.stdout | from_json | map(attribute='Host') | list) is superset(expected_compute_service_hosts)' failed. The error was: Expecting value: line 1 column 1 (char 0)"} TASK [nova-cell : Fail if nova-compute service failed to register] *************************************************************************************************************** fatal: [kolla-comp-2]: FAILED! => {"msg": "The conditional check 'any_failed_services or (nova_compute_registration_fatal | bool and\n failed_compute_service_hosts | length > 0)' failed. The error was: error while evaluating conditional (any_failed_services or (nova_compute_registration_fatal | bool and\n failed_compute_service_hosts | length > 0)): {{ ansible_facts.nodename in failed_compute_service_hosts or\n (ansible_facts.hostname ~ \"-ironic\") in failed_compute_service_hosts }}: {{ expected_compute_service_hosts | difference(nova_compute_service_hosts) | list }}: {{ hostvars[all_computes_in_batch[0]].nova_compute_services.stdout |\n from_json |\n map(attribute='Host') |\n list }}: Unable to look up a name or access an attribute in template string ({{ hostvars[all_computes_in_batch[0]].nova_compute_services.stdout |\n from_json |\n map(attribute='Host') |\n list }}).\nMake sure your variable name does not contain invalid characters like '-': the JSON object must be str, bytes or bytearray, not AnsibleUndefined\n\nThe error appears to be in '/root/venv-kolla/share/kolla-ansible/ansible/roles/nova-cell/tasks/wait_discover_computes.yml': line 46, column 7, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n # that failed to register.\n - name: Fail if nova-compute service failed to register\n ^ here\n"} fatal: [kolla-infra-1]: FAILED! => {"msg": "The conditional check 'any_failed_services or (nova_compute_registration_fatal | bool and\n failed_compute_service_hosts | length > 0)' failed. The error was: error while evaluating conditional (any_failed_services or (nova_compute_registration_fatal | bool and\n failed_compute_service_hosts | length > 0)): {{ ansible_facts.nodename in failed_compute_service_hosts or\n (ansible_facts.hostname ~ \"-ironic\") in failed_compute_service_hosts }}: {{ expected_compute_service_hosts | difference(nova_compute_service_hosts) | list }}: {{ hostvars[all_computes_in_batch[0]].nova_compute_services.stdout |\n from_json |\n map(attribute='Host') |\n list }}: Unable to look up a name or access an attribute in template string ({{ hostvars[all_computes_in_batch[0]].nova_compute_services.stdout |\n from_json |\n map(attribute='Host') |\n list }}).\nMake sure your variable name does not contain invalid characters like '-': the JSON object must be str, bytes or bytearray, not AnsibleUndefined\n\nThe error appears to be in '/root/venv-kolla/share/kolla-ansible/ansible/roles/nova-cell/tasks/wait_discover_computes.yml': line 46, column 7, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n # that failed to register.\n - name: Fail if nova-compute service failed to register\n ^ here\n"} PLAY RECAP *********************************************************************************************************************************************************************** kolla-comp-1 : ok=46 changed=9 unreachable=0 failed=1 skipped=14 rescued=0 ignored=0 kolla-comp-2 : ok=42 changed=9 unreachable=0 failed=1 skipped=13 rescued=0 ignored=0 kolla-infra-1 : ok=214 changed=51 unreachable=0 failed=1 skipped=133 rescued=0 ignored=0 localhost : ok=4 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Command failed ansible-playbook -i multinode -e @/etc/kolla/globals.yml -e @/etc/kolla/passwords.yml -e CONFIG_DIR=/etc/kolla -e kolla_action=deploy /root/venv-kolla/share/kolla-ansible/ansible/site.yml On Thu, Sep 29, 2022 at 5:26 AM Rados?aw Piliszek < radoslaw.piliszek at gmail.com> wrote: > On Thu, 29 Sept 2022 at 11:22, Satish Patel wrote: > > I did the following in global.yml and ran "deploy" but it stuck > somewhere in nova. I am looking for errors to find out what happened. Am I > missing something in the following configuration? > > It looks correct at first glance. You need to be more specific about > the issue at hand. The error message, circumstances... > > > kolla_enable_tls_internal: "yes" > > kolla_certificates_dir: "/etc/kolla/certificates" > > kolla_internal_fqdn_cert: "{{ kolla_certificates_dir > }}/my_company_certificate.pem" > > > > Is the above going to enable SSL for all communications or just horizon > web GUI? > > All communications via haproxy. > > Radek > -yoctozepto > -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Thu Sep 29 09:38:40 2022 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 29 Sep 2022 05:38:40 -0400 Subject: [kolla][ssl] Deploy third-party SSL for HAProxy In-Reply-To: References: Message-ID: Looking into nova-compute logs looks like it's trying to talk to keystone using http instead of https. Do i need to tell exclusive somewhere to use SSL for keystone service or it should be default when you turn on SSL? 2022-09-29 11:29:09.562 7 ERROR nova.compute.manager keystoneauth1.exceptions.connection.ConnectFailure: Unable to establish connection to http://10.73.0.180:8780/resource_providers?in_tree=a3163bbf-a97b-4162-89c7-5adfbae4febd: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response')) On Thu, Sep 29, 2022 at 5:32 AM Satish Patel wrote: > Hi Rados?aw, > > Following error encounter if i turn on above 3 lines to implement SSL. if > i remove then the error disappears. > https://paste.opendev.org/show/bOqOAQyqni0nJcWbUuv9/ > > TASK [nova-cell : Waiting for nova-compute services to register themselves] ****************************************************************************************************** > skipping: [kolla-comp-2] > skipping: [kolla-infra-1] > fatal: [kolla-comp-1 -> kolla-infra-1]: FAILED! => {"msg": "The conditional check '(nova_compute_services.stdout | from_json | map(attribute='Host') | list) is superset(expected_compute_service_hosts)' failed. The error was: Expecting value: line 1 column 1 (char 0)"} > > TASK [nova-cell : Fail if nova-compute service failed to register] *************************************************************************************************************** > fatal: [kolla-comp-2]: FAILED! => {"msg": "The conditional check 'any_failed_services or (nova_compute_registration_fatal | bool and\n failed_compute_service_hosts | length > 0)' failed. The error was: error while evaluating conditional (any_failed_services or (nova_compute_registration_fatal | bool and\n failed_compute_service_hosts | length > 0)): {{ ansible_facts.nodename in failed_compute_service_hosts or\n (ansible_facts.hostname ~ \"-ironic\") in failed_compute_service_hosts }}: {{ expected_compute_service_hosts | difference(nova_compute_service_hosts) | list }}: {{ hostvars[all_computes_in_batch[0]].nova_compute_services.stdout |\n from_json |\n map(attribute='Host') |\n list }}: Unable to look up a name or access an attribute in template string ({{ hostvars[all_computes_in_batch[0]].nova_compute_services.stdout |\n from_json |\n map(attribute='Host') |\n list }}).\nMake sure your variable name does not contain invalid characters like '-': the JSON object must be str, bytes or bytearray, not AnsibleUndefined\n\nThe error appears to be in '/root/venv-kolla/share/kolla-ansible/ansible/roles/nova-cell/tasks/wait_discover_computes.yml': line 46, column 7, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n # that failed to register.\n - name: Fail if nova-compute service failed to register\n ^ here\n"} > fatal: [kolla-infra-1]: FAILED! => {"msg": "The conditional check 'any_failed_services or (nova_compute_registration_fatal | bool and\n failed_compute_service_hosts | length > 0)' failed. The error was: error while evaluating conditional (any_failed_services or (nova_compute_registration_fatal | bool and\n failed_compute_service_hosts | length > 0)): {{ ansible_facts.nodename in failed_compute_service_hosts or\n (ansible_facts.hostname ~ \"-ironic\") in failed_compute_service_hosts }}: {{ expected_compute_service_hosts | difference(nova_compute_service_hosts) | list }}: {{ hostvars[all_computes_in_batch[0]].nova_compute_services.stdout |\n from_json |\n map(attribute='Host') |\n list }}: Unable to look up a name or access an attribute in template string ({{ hostvars[all_computes_in_batch[0]].nova_compute_services.stdout |\n from_json |\n map(attribute='Host') |\n list }}).\nMake sure your variable name does not contain invalid characters like '-': the JSON object must be str, bytes or bytearray, not AnsibleUndefined\n\nThe error appears to be in '/root/venv-kolla/share/kolla-ansible/ansible/roles/nova-cell/tasks/wait_discover_computes.yml': line 46, column 7, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n # that failed to register.\n - name: Fail if nova-compute service failed to register\n ^ here\n"} > > PLAY RECAP *********************************************************************************************************************************************************************** > kolla-comp-1 : ok=46 changed=9 unreachable=0 failed=1 skipped=14 rescued=0 ignored=0 > kolla-comp-2 : ok=42 changed=9 unreachable=0 failed=1 skipped=13 rescued=0 ignored=0 > kolla-infra-1 : ok=214 changed=51 unreachable=0 failed=1 skipped=133 rescued=0 ignored=0 > localhost : ok=4 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 > > Command failed ansible-playbook -i multinode -e @/etc/kolla/globals.yml -e @/etc/kolla/passwords.yml -e CONFIG_DIR=/etc/kolla -e kolla_action=deploy /root/venv-kolla/share/kolla-ansible/ansible/site.yml > > > On Thu, Sep 29, 2022 at 5:26 AM Rados?aw Piliszek < > radoslaw.piliszek at gmail.com> wrote: > >> On Thu, 29 Sept 2022 at 11:22, Satish Patel wrote: >> > I did the following in global.yml and ran "deploy" but it stuck >> somewhere in nova. I am looking for errors to find out what happened. Am I >> missing something in the following configuration? >> >> It looks correct at first glance. You need to be more specific about >> the issue at hand. The error message, circumstances... >> >> > kolla_enable_tls_internal: "yes" >> > kolla_certificates_dir: "/etc/kolla/certificates" >> > kolla_internal_fqdn_cert: "{{ kolla_certificates_dir >> }}/my_company_certificate.pem" >> > >> > Is the above going to enable SSL for all communications or just horizon >> web GUI? >> >> All communications via haproxy. >> >> Radek >> -yoctozepto >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From satish.txt at gmail.com Thu Sep 29 10:19:51 2022 From: satish.txt at gmail.com (Satish Patel) Date: Thu, 29 Sep 2022 06:19:51 -0400 Subject: [kolla][ssl] Deploy third-party SSL for HAProxy In-Reply-To: References: Message-ID: Following my problem, it was missing FQDN. Now everything is working fine. Thanks for the help. kolla_internal_vip_address: "10.73.0.180" kolla_external_vip_address: "{{ kolla_internal_vip_address }}" kolla_external_fqdn: "openstack-kolla.mycompany.com" kolla_internal_fqdn: "openstack-kolla.mycompany.com" kolla_enable_tls_internal: "yes" kolla_certificates_dir: "/etc/kolla/certificates" kolla_internal_fqdn_cert: "{{ kolla_certificates_dir }}/mycompany.pem" On Thu, Sep 29, 2022 at 5:38 AM Satish Patel wrote: > Looking into nova-compute logs looks like it's trying to talk to keystone > using http instead of https. Do i need to tell exclusive somewhere to use > SSL for keystone service or it should be default when you turn on SSL? > > 2022-09-29 11:29:09.562 7 ERROR nova.compute.manager > keystoneauth1.exceptions.connection.ConnectFailure: Unable to establish > connection to > http://10.73.0.180:8780/resource_providers?in_tree=a3163bbf-a97b-4162-89c7-5adfbae4febd: > ('Connection aborted.', RemoteDisconnected('Remote end closed connection > without response')) > > On Thu, Sep 29, 2022 at 5:32 AM Satish Patel wrote: > >> Hi Rados?aw, >> >> Following error encounter if i turn on above 3 lines to implement SSL. if >> i remove then the error disappears. >> https://paste.opendev.org/show/bOqOAQyqni0nJcWbUuv9/ >> >> TASK [nova-cell : Waiting for nova-compute services to register themselves] ****************************************************************************************************** >> skipping: [kolla-comp-2] >> skipping: [kolla-infra-1] >> fatal: [kolla-comp-1 -> kolla-infra-1]: FAILED! => {"msg": "The conditional check '(nova_compute_services.stdout | from_json | map(attribute='Host') | list) is superset(expected_compute_service_hosts)' failed. The error was: Expecting value: line 1 column 1 (char 0)"} >> >> TASK [nova-cell : Fail if nova-compute service failed to register] *************************************************************************************************************** >> fatal: [kolla-comp-2]: FAILED! => {"msg": "The conditional check 'any_failed_services or (nova_compute_registration_fatal | bool and\n failed_compute_service_hosts | length > 0)' failed. The error was: error while evaluating conditional (any_failed_services or (nova_compute_registration_fatal | bool and\n failed_compute_service_hosts | length > 0)): {{ ansible_facts.nodename in failed_compute_service_hosts or\n (ansible_facts.hostname ~ \"-ironic\") in failed_compute_service_hosts }}: {{ expected_compute_service_hosts | difference(nova_compute_service_hosts) | list }}: {{ hostvars[all_computes_in_batch[0]].nova_compute_services.stdout |\n from_json |\n map(attribute='Host') |\n list }}: Unable to look up a name or access an attribute in template string ({{ hostvars[all_computes_in_batch[0]].nova_compute_services.stdout |\n from_json |\n map(attribute='Host') |\n list }}).\nMake sure your variable name does not contain invalid characters like '-': the JSON object must be str, bytes or bytearray, not AnsibleUndefined\n\nThe error appears to be in '/root/venv-kolla/share/kolla-ansible/ansible/roles/nova-cell/tasks/wait_discover_computes.yml': line 46, column 7, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n # that failed to register.\n - name: Fail if nova-compute service failed to register\n ^ here\n"} >> fatal: [kolla-infra-1]: FAILED! => {"msg": "The conditional check 'any_failed_services or (nova_compute_registration_fatal | bool and\n failed_compute_service_hosts | length > 0)' failed. The error was: error while evaluating conditional (any_failed_services or (nova_compute_registration_fatal | bool and\n failed_compute_service_hosts | length > 0)): {{ ansible_facts.nodename in failed_compute_service_hosts or\n (ansible_facts.hostname ~ \"-ironic\") in failed_compute_service_hosts }}: {{ expected_compute_service_hosts | difference(nova_compute_service_hosts) | list }}: {{ hostvars[all_computes_in_batch[0]].nova_compute_services.stdout |\n from_json |\n map(attribute='Host') |\n list }}: Unable to look up a name or access an attribute in template string ({{ hostvars[all_computes_in_batch[0]].nova_compute_services.stdout |\n from_json |\n map(attribute='Host') |\n list }}).\nMake sure your variable name does not contain invalid characters like '-': the JSON object must be str, bytes or bytearray, not AnsibleUndefined\n\nThe error appears to be in '/root/venv-kolla/share/kolla-ansible/ansible/roles/nova-cell/tasks/wait_discover_computes.yml': line 46, column 7, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n # that failed to register.\n - name: Fail if nova-compute service failed to register\n ^ here\n"} >> >> PLAY RECAP *********************************************************************************************************************************************************************** >> kolla-comp-1 : ok=46 changed=9 unreachable=0 failed=1 skipped=14 rescued=0 ignored=0 >> kolla-comp-2 : ok=42 changed=9 unreachable=0 failed=1 skipped=13 rescued=0 ignored=0 >> kolla-infra-1 : ok=214 changed=51 unreachable=0 failed=1 skipped=133 rescued=0 ignored=0 >> localhost : ok=4 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 >> >> Command failed ansible-playbook -i multinode -e @/etc/kolla/globals.yml -e @/etc/kolla/passwords.yml -e CONFIG_DIR=/etc/kolla -e kolla_action=deploy /root/venv-kolla/share/kolla-ansible/ansible/site.yml >> >> >> On Thu, Sep 29, 2022 at 5:26 AM Rados?aw Piliszek < >> radoslaw.piliszek at gmail.com> wrote: >> >>> On Thu, 29 Sept 2022 at 11:22, Satish Patel >>> wrote: >>> > I did the following in global.yml and ran "deploy" but it stuck >>> somewhere in nova. I am looking for errors to find out what happened. Am I >>> missing something in the following configuration? >>> >>> It looks correct at first glance. You need to be more specific about >>> the issue at hand. The error message, circumstances... >>> >>> > kolla_enable_tls_internal: "yes" >>> > kolla_certificates_dir: "/etc/kolla/certificates" >>> > kolla_internal_fqdn_cert: "{{ kolla_certificates_dir >>> }}/my_company_certificate.pem" >>> > >>> > Is the above going to enable SSL for all communications or just >>> horizon web GUI? >>> >>> All communications via haproxy. >>> >>> Radek >>> -yoctozepto >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pdeore at redhat.com Thu Sep 29 10:40:39 2022 From: pdeore at redhat.com (Pranali Deore) Date: Thu, 29 Sep 2022 16:10:39 +0530 Subject: [Glance] Weekly Meeting Cancelled Message-ID: Hello, This week's upstream meeting is cancelled, since there is nothing on agenda for today. Thanks & Regards, Pranali Deore -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Thu Sep 29 12:36:35 2022 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 29 Sep 2022 14:36:35 +0200 Subject: [kolla][centos][rdo] NOTICE: OVS version mismatch between Wallaby and later Message-ID: Dears, This is a notice to users of OVS with Kolla with CentOS-Stream-8-based images or RDO directly. It seems that RDO Wallaby currently installs OVS 2.17 while later ones install OVS 2.15. The problem is that currently: *** Upgrades from Wallaby to Xena will cause OVS to misbehave and lose all network connectivity until host reboot. *** This is because downgrades of running OVS are not supported. We are investigating this issue, please stay tuned to this topic. The solution we believe to be the correct one now is to bump OVS to 2.17 also in later branches of RDO. Kind regards, Radek -yoctozepto From jean-francois.taltavull at elca.ch Thu Sep 29 07:09:02 2022 From: jean-francois.taltavull at elca.ch (=?utf-8?B?VGFsdGF2dWxsIEplYW4tRnJhbsOnb2lz?=) Date: Thu, 29 Sep 2022 07:09:02 +0000 Subject: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number In-Reply-To: References: <2aa77e24a33d48a69032f30b86e9cad8@elca.ch> <1b17c23f8982480db73cf50d04d51af7@elca.ch> <86f048d7931c4cc482f6785437c9b5ea@elca.ch> <671023b5ab3846dfb3a39ef313018eac@elca.ch> <33f69d386462450b9964b2ed78284d57@elca.ch> Message-ID: python Python 3.8.10 (default, Sep 28 2021, 16:10:42) [GCC 9.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import awsauth >>> awsauth >>> From: Rafael Weing?rtner Sent: mercredi, 28 septembre 2022 18:40 To: Taltavull Jean-Fran?ois Cc: openstack-discuss Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Can you also execute the following: ``` python import awsauth awsauth ``` That will output a path, and then you can `cat `, example: `cat /var/lib/kolla/venv/lib/python3.8/site-packages/awsauth.py` On Wed, Sep 28, 2022 at 1:21 PM Taltavull Jean-Fran?ois > wrote: I removed trailing ?/object-store/? from the last value of authentication_parameters I also: - disabled s3 keystone auth in RGW - created a RGW ?admin? user with the right privileges to allow admin API calls - put RGW in debug mode And here is what I get in RGW logs: get_usage string_to_sign=GET Wed, 28 Sep 2022 16:15:45 GMT /admin/usage get_usage server signature=BlaBlaBlaBla get_usage client signature=BloBloBlo get_usage compare=-75 get_usage rgw::auth::s3::LocalEngine denied with reason=-2027 get_usage rgw::auth::s3::AWSAuthStrategy denied with reason=-2027 get_usage rgw::auth::StrategyRegistry::s3_main_strategy_t: trying rgw::auth::s3::AWSAuthStrategy get_usage rgw::auth::s3::AWSAuthStrategy: trying rgw::auth::s3::LocalEngine From: Rafael Weing?rtner > Sent: mercredi, 28 septembre 2022 13:15 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. I think that the last parameter "/object-store/", should be only "". Can you test it? You are using EC2 credentials to authenticate in RGW. Did you enable the Keystone integration in RGW? Also, as far as I know, this admin endpoint needs a RGW admin. I am not sure if the Keystone and RGW integration would enable/make it possible for someone to authenticate as an admin in RGW. Can you check it? To see if you can call that endpoint with these credentials. On Wed, Sep 28, 2022 at 6:01 AM Taltavull Jean-Fran?ois > wrote: Pollster YML configuration : --- - name: "dynamic.radosgw.usage" sample_type: "gauge" unit: "B" value_attribute: "total.size" url_path: http:///object-store/admin/usage module: "awsauth" authentication_object: "S3Auth" authentication_parameters: ,,/object-store/ user_id_attribute: "user" project_id_attribute: "user" resource_id_attribute: "user" response_entries_key: "summary" ACCESS_KEY and SECRET_KEY have been created with ?openstack ec2 credentials create?. Ceilometer central is deployed with OSA and it uses awsauth.py module. From: Rafael Weing?rtner > Sent: mercredi, 28 septembre 2022 02:01 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Can you show your YML configuration? Also, did you install the AWS authentication module in the container/host where Ceilometer central is running? On Mon, Sep 26, 2022 at 12:58 PM Taltavull Jean-Fran?ois > wrote: Hello Rafael, Thanks for the information about ceilometer patches but for now I?m testing with the credentials in the dynamic pollster config file. I will use barbican when I push all this to production. The keystone authentication performed by the rados gw with the credentials provided by ceilometer still does not work. I wonder if this could be a S3 signature version issue on ceilometer side, that is on S3 client side. This kind of issue exists with the s3 client ?s3cmd? and you have to add ??signature-v2? so that ?s3cmd? works well. What do you think ? Do you know which version of S3 signature ceilometer uses while authenticating ? From: Rafael Weing?rtner > Sent: mercredi, 7 septembre 2022 19:23 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Jean, there are two problems with the Ceilometer. I just opened the patches to resolve it: - https://review.opendev.org/c/openstack/ceilometer/+/856305 - https://review.opendev.org/c/openstack/ceilometer/+/856304 Without these patches, you might have problems to use Ceilometer with Non-OpenStack dynamic pollsters and barbican credentials. On Wed, Aug 31, 2022 at 3:55 PM Rafael Weing?rtner > wrote: It is the RGW user that you have. This user must have the role that is needed to access the usage feature in RGW. If I am not mistaken, it required an admin user. On Wed, Aug 31, 2022 at 1:54 PM Taltavull Jean-Fran?ois > wrote: Thanks to your help, I am close to the goal. Dynamic pollster is loaded and triggered. But I get a ?Status[403] and reason [Forbidden]? in ceilometer logs while requesting admin/usage. I?m not sure to understand well the auth mechanism. Are we talking about keystone credentials, ec2 credentials, Rados GW user ?... For now, in testing phase, I use ?authentication_parameters?, not barbican. -JF From: Rafael Weing?rtner > Sent: mardi, 30 ao?t 2022 14:17 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Yes, you will need to enable the metric/pollster to be processed. That is done via "polling.yml" file. Also, do not forget that you will need to configure Ceilometer to push this new metric. If you use Gnocchi as the backend, you will need to change/update the gnocchi resource YML file. That file maps resources and metrics in the Gnocchi backend. The configuration resides in Ceilometer. You can create/define new resource types and map them to specific metrics. It depends on how you structure your solution. P.S. You do not need to use "authentication_parameters". You can use the barbican integration to avoid setting your credentials in a file. On Tue, Aug 30, 2022 at 9:11 AM Taltavull Jean-Fran?ois > wrote: Hello, I tried to define a Rados GW dynamic pollster and I can see, in Ceilometer logs, that it?s actually loaded. But it looks like it was not triggered, I see no trace of ceilometer connection in Rados GW logs. My definition: - name: "dynamic.radosgw.usage" sample_type: "gauge" unit: "B" value_attribute: "total.size" url_path: http:///object-store/swift/v1/admin/usage module: "awsauth" authentication_object: "S3Auth" authentication_parameters: xxxxxxxxxxxxx,yyyyyyyyyyyyy, user_id_attribute: "admin" project_id_attribute: "admin" resource_id_attribute: "admin" response_entries_key: "summary" Do I have to set an option in ceilometer.conf, or elsewhere, to get my Rados GW dynamic pollster triggered ? -JF From: Taltavull Jean-Fran?ois Sent: lundi, 29 ao?t 2022 18:41 To: 'Rafael Weing?rtner' > Cc: openstack-discuss > Subject: RE: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number Thanks a lot for your quick answer, Rafael ! I will explore this approach. Jean-Francois From: Rafael Weing?rtner > Sent: lundi, 29 ao?t 2022 17:54 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. You could use a different approach. You can use Dynamic pollster [1], and create your own mechanism to collect data, without needing to change Ceilometer code. Basically all hard-coded pollsters can be converted to a dynamic pollster that is defined in YML. [1] https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollster.html#the-dynamic-pollsters-system-configuration-for-non-openstack-apis On Mon, Aug 29, 2022 at 12:51 PM Taltavull Jean-Fran?ois > wrote: Hi All, In our OpenStack deployment, API endpoints are defined by using URLs instead of port numbers and HAProxy forwards requests to the right bakend after having ACLed the URL. In the case of our object-store service, based on RadosGW, the internal API endpoint is "https:///object-store/swift/v1/AUTH_" When Ceilometer RadosGW pollster tries to connect to the RadosGW admin API with the object-store internal endpoint, the URL becomes https:///admin, as shown by HAProxy logs. This URL does not match any API endpoint from HAProxy point of view. The line of code that rewrites the URL is this one: https://opendev.org/openstack/ceilometer/src/branch/stable/wallaby/ceilometer/objectstore/rgw.py#L81 What would you think of adding a mechanism based on new Ceilometer configuration option(s) to control the URL rewriting ? Our deployment characteristics: - OpenStack release: Wallaby - Ceph and RadosGW version: 15.2.16 - deployment tool: OSA 23.2.1 and ceph-ansible Best regards, Jean-Francois -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafaelweingartner at gmail.com Thu Sep 29 10:31:41 2022 From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=) Date: Thu, 29 Sep 2022 07:31:41 -0300 Subject: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number In-Reply-To: References: <2aa77e24a33d48a69032f30b86e9cad8@elca.ch> <1b17c23f8982480db73cf50d04d51af7@elca.ch> <86f048d7931c4cc482f6785437c9b5ea@elca.ch> <671023b5ab3846dfb3a39ef313018eac@elca.ch> <33f69d386462450b9964b2ed78284d57@elca.ch> Message-ID: Can you test you credentials with the following code? ``` import json import requests import os import six.moves.urllib.parse as urlparse class RGWAdminAPIFailed(Exception): pass if __name__ == '__main__': rados_gw_base_url = "put your RGW URL here. E.g. http://server.com:port /something" print("Executing test on: [%s]." % rados_gw_base_url) rados_gw_admin_context = "/admin" rados_gw_path = "/usage?stats=True" print("Rados GW admin context [%s] and path [%s] used." % (rados_gw_admin_context, rados_gw_path)) rados_gw_request_url = urlparse.urljoin(rados_gw_base_url, '/admin') + '/bucket?stats=True' print("Rados GW request URL [%s]." % rados_gw_request_url) rados_gw_access_key_to_use = "put your access key here" rados_gw_secret_key_to_use = "put your secret key here" rados_gw_host_name = urlparse.urlparse(rados_gw_request_url).netloc print("Rados GW host: %s" % rados_gw_host_name) module_name = "awsauth" class_name = "S3Auth" arguments = [rados_gw_access_key_to_use, rados_gw_secret_key_to_use, rados_gw_host_name] module = __import__(module_name) class_ = getattr(module, class_name) instance = class_(*arguments) r = requests.get( rados_gw_request_url, auth=instance, timeout=30) #auth=awsauth.S3Auth(*arguments)) if r.status_code != 200: raise RGWAdminAPIFailed( ('RGW AdminOps API returned %(status)s %(reason)s') % {'status': r.status_code, 'reason': r.reason}) response_body = r.text parsed_json = json.loads(response_body) print("Response cookies: [%s]." % r.cookies) radosGw_output_file = "/home//Downloads/radosGw-usage.json" if os.path.exists(radosGw_output_file): os.remove(radosGw_output_file) with open(radosGw_output_file, "w") as file1: file1.writelines(json.dumps(parsed_json, indent=4, sort_keys=True)) file1.flush() exit(0) ``` On Thu, Sep 29, 2022 at 4:09 AM Taltavull Jean-Fran?ois < jean-francois.taltavull at elca.ch> wrote: > python > > Python 3.8.10 (default, Sep 28 2021, 16:10:42) > > [GCC 9.3.0] on linux > > Type "help", "copyright", "credits" or "license" for more information. > > >>> import awsauth > > >>> awsauth > > '/openstack/venvs/ceilometer-23.2.0/lib/python3.8/site-packages/awsauth.py'> > > >>> > > > > *From:* Rafael Weing?rtner > *Sent:* mercredi, 28 septembre 2022 18:40 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Can you also execute the following: > > ``` > > python > > > > import awsauth > > > > awsauth > > ``` > > That will output a path, and then you can `cat `, example: `cat > /var/lib/kolla/venv/lib/python3.8/site-packages/awsauth.py` > > > > On Wed, Sep 28, 2022 at 1:21 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > I removed trailing ?/object-store/? from the last value of > authentication_parameters > > > > I also: > > - disabled s3 keystone auth in RGW > > - created a RGW ?admin? user with the right privileges to allow admin API > calls > > - put RGW in debug mode > > > > And here is what I get in RGW logs: > > > > get_usage > string_to_sign=GET > Wed, > 28 Sep 2022 16:15:45 > GMT > /admin/usage > > get_usage server signature=BlaBlaBlaBla > > get_usage client signature=BloBloBlo > > get_usage compare=-75 > > get_usage rgw::auth::s3::LocalEngine denied with reason=-2027 > > get_usage rgw::auth::s3::AWSAuthStrategy denied with reason=-2027 > > get_usage rgw::auth::StrategyRegistry::s3_main_strategy_t: trying > rgw::auth::s3::AWSAuthStrategy > > get_usage rgw::auth::s3::AWSAuthStrategy: trying rgw::auth::s3::LocalEngine > > > > *From:* Rafael Weing?rtner > *Sent:* mercredi, 28 septembre 2022 13:15 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > I think that the last parameter "/object-store/", should be only " > ". Can you test it? > > > > > > You are using EC2 credentials to authenticate in RGW. Did you enable the > Keystone integration in RGW? > > Also, as far as I know, this admin endpoint needs a RGW admin. I am not > sure if the Keystone and RGW integration would enable/make it possible for > someone to authenticate as an admin in RGW. Can you check it? To see if you > can call that endpoint with these credentials. > > > > On Wed, Sep 28, 2022 at 6:01 AM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Pollster YML configuration : > > > > --- > > - name: "dynamic.radosgw.usage" > > sample_type: "gauge" > > unit: "B" > > value_attribute: "total.size" > > url_path: http:///object-store/admin/usage > > module: "awsauth" > > authentication_object: "S3Auth" > > authentication_parameters: ,,/object-store/ > > user_id_attribute: "user" > > project_id_attribute: "user" > > resource_id_attribute: "user" > > response_entries_key: "summary" > > > > ACCESS_KEY and SECRET_KEY have been created with ?openstack ec2 > credentials create?. > > > > Ceilometer central is deployed with OSA and it uses awsauth.py module. > > > > > > *From:* Rafael Weing?rtner > *Sent:* mercredi, 28 septembre 2022 02:01 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Can you show your YML configuration? Also, did you install the AWS > authentication module in the container/host where Ceilometer central is > running? > > > > On Mon, Sep 26, 2022 at 12:58 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Hello Rafael, > > > > Thanks for the information about ceilometer patches but for now I?m > testing with the credentials in the dynamic pollster config file. I will > use barbican when I push all this to production. > > > > The keystone authentication performed by the rados gw with the credentials > provided by ceilometer still does not work. I wonder if this could be a S3 > signature version issue on ceilometer side, that is on S3 client side. This > kind of issue exists with the s3 client ?s3cmd? and you have to add > ??signature-v2? so that ?s3cmd? works well. > > > > What do you think ? Do you know which version of S3 signature ceilometer > uses while authenticating ? > > > > *From:* Rafael Weing?rtner > *Sent:* mercredi, 7 septembre 2022 19:23 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Jean, there are two problems with the Ceilometer. I just opened the > patches to resolve it: > - https://review.opendev.org/c/openstack/ceilometer/+/856305 > > - https://review.opendev.org/c/openstack/ceilometer/+/856304 > > > > Without these patches, you might have problems to use Ceilometer with > Non-OpenStack dynamic pollsters and barbican credentials. > > > > On Wed, Aug 31, 2022 at 3:55 PM Rafael Weing?rtner < > rafaelweingartner at gmail.com> wrote: > > It is the RGW user that you have. This user must have the role that is > needed to access the usage feature in RGW. If I am not mistaken, it > required an admin user. > > > > On Wed, Aug 31, 2022 at 1:54 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Thanks to your help, I am close to the goal. Dynamic pollster is loaded > and triggered. > > > > But I get a ?Status[403] and reason [Forbidden]? in ceilometer logs while > requesting admin/usage. > > > > I?m not sure to understand well the auth mechanism. Are we talking about > keystone credentials, ec2 credentials, Rados GW user ?... > > > > For now, in testing phase, I use ?authentication_parameters?, not barbican. > > > > -JF > > > > *From:* Rafael Weing?rtner > *Sent:* mardi, 30 ao?t 2022 14:17 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Yes, you will need to enable the metric/pollster to be processed. That is > done via "polling.yml" file. Also, do not forget that you will need to > configure Ceilometer to push this new metric. If you use Gnocchi as the > backend, you will need to change/update the gnocchi resource YML file. That > file maps resources and metrics in the Gnocchi backend. The configuration > resides in Ceilometer. You can create/define new resource types and map > them to specific metrics. It depends on how you structure your solution. > > P.S. You do not need to use "authentication_parameters". You can use the > barbican integration to avoid setting your credentials in a file. > > > > On Tue, Aug 30, 2022 at 9:11 AM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Hello, > > > > I tried to define a Rados GW dynamic pollster and I can see, in Ceilometer > logs, that it?s actually loaded. But it looks like it was not triggered, I > see no trace of ceilometer connection in Rados GW logs. > > > > My definition: > > > > - name: "dynamic.radosgw.usage" > > sample_type: "gauge" > > unit: "B" > > value_attribute: "total.size" > > url_path: http:///object-store/swift/v1/admin/usage > > module: "awsauth" > > authentication_object: "S3Auth" > > authentication_parameters: xxxxxxxxxxxxx,yyyyyyyyyyyyy, > > user_id_attribute: "admin" > > project_id_attribute: "admin" > > resource_id_attribute: "admin" > > response_entries_key: "summary" > > > > Do I have to set an option in ceilometer.conf, or elsewhere, to get my > Rados GW dynamic pollster triggered ? > > > > -JF > > > > *From:* Taltavull Jean-Fran?ois > *Sent:* lundi, 29 ao?t 2022 18:41 > *To:* 'Rafael Weing?rtner' > *Cc:* openstack-discuss > *Subject:* RE: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > Thanks a lot for your quick answer, Rafael ! > > I will explore this approach. > > > > Jean-Francois > > > > *From:* Rafael Weing?rtner > *Sent:* lundi, 29 ao?t 2022 17:54 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > You could use a different approach. You can use Dynamic pollster [1], and > create your own mechanism to collect data, without needing to change > Ceilometer code. Basically all hard-coded pollsters can be converted to a > dynamic pollster that is defined in YML. > > > > [1] > https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollster.html#the-dynamic-pollsters-system-configuration-for-non-openstack-apis > > > > > > On Mon, Aug 29, 2022 at 12:51 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Hi All, > > In our OpenStack deployment, API endpoints are defined by using URLs > instead of port numbers and HAProxy forwards requests to the right bakend > after having ACLed the URL. > > In the case of our object-store service, based on RadosGW, the internal > API endpoint is "https:///object-store/swift/v1/AUTH_" > > When Ceilometer RadosGW pollster tries to connect to the RadosGW admin API > with the object-store internal endpoint, the URL becomes > https:///admin, as shown by HAProxy logs. This URL does not match > any API endpoint from HAProxy point of view. The line of code that rewrites > the URL is this one: > https://opendev.org/openstack/ceilometer/src/branch/stable/wallaby/ceilometer/objectstore/rgw.py#L81 > > What would you think of adding a mechanism based on new Ceilometer > configuration option(s) to control the URL rewriting ? > > Our deployment characteristics: > - OpenStack release: Wallaby > - Ceph and RadosGW version: 15.2.16 > - deployment tool: OSA 23.2.1 and ceph-ansible > > > Best regards, > Jean-Francois > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > -- Rafael Weing?rtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean-francois.taltavull at elca.ch Thu Sep 29 12:15:21 2022 From: jean-francois.taltavull at elca.ch (=?utf-8?B?VGFsdGF2dWxsIEplYW4tRnJhbsOnb2lz?=) Date: Thu, 29 Sep 2022 12:15:21 +0000 Subject: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number In-Reply-To: References: <2aa77e24a33d48a69032f30b86e9cad8@elca.ch> <1b17c23f8982480db73cf50d04d51af7@elca.ch> <86f048d7931c4cc482f6785437c9b5ea@elca.ch> <671023b5ab3846dfb3a39ef313018eac@elca.ch> <33f69d386462450b9964b2ed78284d57@elca.ch> Message-ID: <1d1c1c3cc6184b529819bb8f3598813f@elca.ch> ``` $ python test_creds.py Executing test on: [FQDN/object-store/]. Rados GW admin context [/admin] and path [/usage?stats=True] used. Rados GW request URL [http://FQDN/object-store/admin/bucket?stats=True]. Rados GW host: FQDN Traceback (most recent call last): File "test_creds.py", line 45, in raise RGWAdminAPIFailed( __main__.RGWAdminAPIFailed: RGW AdminOps API returned 403 Forbidden ``` So the same as with ceilometer. Auth is done by RGW, not by keystone, and the ceph ?admin? user exists and owns the right privileges: ``` $ sudo radosgw-admin user info --uid admin [22/296]{ "user_id": "admin", "display_name": "admin user", "email": "", "suspended": 0, "max_buckets": 1000, "subusers": [], "keys": [ { "user": "admin", "access_key": ?admin_access_key", "secret_key": "admin_secret_key" } ], "swift_keys": [], "caps": [ { "type": "buckets", "perm": "*" }, { "type": "metadata", "perm": "*" }, { "type": "usage", "perm": "*" }, { "type": "users", "perm": "*" } ], ``` From: Rafael Weing?rtner Sent: jeudi, 29 septembre 2022 12:32 To: Taltavull Jean-Fran?ois Cc: openstack-discuss Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Can you test you credentials with the following code? ``` import json import requests import os import six.moves.urllib.parse as urlparse class RGWAdminAPIFailed(Exception): pass if __name__ == '__main__': rados_gw_base_url = "put your RGW URL here. E.g. http://server.com:port/something" print("Executing test on: [%s]." % rados_gw_base_url) rados_gw_admin_context = "/admin" rados_gw_path = "/usage?stats=True" print("Rados GW admin context [%s] and path [%s] used." % (rados_gw_admin_context, rados_gw_path)) rados_gw_request_url = urlparse.urljoin(rados_gw_base_url, '/admin') + '/bucket?stats=True' print("Rados GW request URL [%s]." % rados_gw_request_url) rados_gw_access_key_to_use = "put your access key here" rados_gw_secret_key_to_use = "put your secret key here" rados_gw_host_name = urlparse.urlparse(rados_gw_request_url).netloc print("Rados GW host: %s" % rados_gw_host_name) module_name = "awsauth" class_name = "S3Auth" arguments = [rados_gw_access_key_to_use, rados_gw_secret_key_to_use, rados_gw_host_name] module = __import__(module_name) class_ = getattr(module, class_name) instance = class_(*arguments) r = requests.get( rados_gw_request_url, auth=instance, timeout=30) #auth=awsauth.S3Auth(*arguments)) if r.status_code != 200: raise RGWAdminAPIFailed( ('RGW AdminOps API returned %(status)s %(reason)s') % {'status': r.status_code, 'reason': r.reason}) response_body = r.text parsed_json = json.loads(response_body) print("Response cookies: [%s]." % r.cookies) radosGw_output_file = "/home//Downloads/radosGw-usage.json" if os.path.exists(radosGw_output_file): os.remove(radosGw_output_file) with open(radosGw_output_file, "w") as file1: file1.writelines(json.dumps(parsed_json, indent=4, sort_keys=True)) file1.flush() exit(0) ``` On Thu, Sep 29, 2022 at 4:09 AM Taltavull Jean-Fran?ois > wrote: python Python 3.8.10 (default, Sep 28 2021, 16:10:42) [GCC 9.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import awsauth >>> awsauth >>> From: Rafael Weing?rtner > Sent: mercredi, 28 septembre 2022 18:40 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Can you also execute the following: ``` python import awsauth awsauth ``` That will output a path, and then you can `cat `, example: `cat /var/lib/kolla/venv/lib/python3.8/site-packages/awsauth.py` On Wed, Sep 28, 2022 at 1:21 PM Taltavull Jean-Fran?ois > wrote: I removed trailing ?/object-store/? from the last value of authentication_parameters I also: - disabled s3 keystone auth in RGW - created a RGW ?admin? user with the right privileges to allow admin API calls - put RGW in debug mode And here is what I get in RGW logs: get_usage string_to_sign=GET Wed, 28 Sep 2022 16:15:45 GMT /admin/usage get_usage server signature=BlaBlaBlaBla get_usage client signature=BloBloBlo get_usage compare=-75 get_usage rgw::auth::s3::LocalEngine denied with reason=-2027 get_usage rgw::auth::s3::AWSAuthStrategy denied with reason=-2027 get_usage rgw::auth::StrategyRegistry::s3_main_strategy_t: trying rgw::auth::s3::AWSAuthStrategy get_usage rgw::auth::s3::AWSAuthStrategy: trying rgw::auth::s3::LocalEngine From: Rafael Weing?rtner > Sent: mercredi, 28 septembre 2022 13:15 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. I think that the last parameter "/object-store/", should be only "". Can you test it? You are using EC2 credentials to authenticate in RGW. Did you enable the Keystone integration in RGW? Also, as far as I know, this admin endpoint needs a RGW admin. I am not sure if the Keystone and RGW integration would enable/make it possible for someone to authenticate as an admin in RGW. Can you check it? To see if you can call that endpoint with these credentials. On Wed, Sep 28, 2022 at 6:01 AM Taltavull Jean-Fran?ois > wrote: Pollster YML configuration : --- - name: "dynamic.radosgw.usage" sample_type: "gauge" unit: "B" value_attribute: "total.size" url_path: http:///object-store/admin/usage module: "awsauth" authentication_object: "S3Auth" authentication_parameters: ,,/object-store/ user_id_attribute: "user" project_id_attribute: "user" resource_id_attribute: "user" response_entries_key: "summary" ACCESS_KEY and SECRET_KEY have been created with ?openstack ec2 credentials create?. Ceilometer central is deployed with OSA and it uses awsauth.py module. From: Rafael Weing?rtner > Sent: mercredi, 28 septembre 2022 02:01 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Can you show your YML configuration? Also, did you install the AWS authentication module in the container/host where Ceilometer central is running? On Mon, Sep 26, 2022 at 12:58 PM Taltavull Jean-Fran?ois > wrote: Hello Rafael, Thanks for the information about ceilometer patches but for now I?m testing with the credentials in the dynamic pollster config file. I will use barbican when I push all this to production. The keystone authentication performed by the rados gw with the credentials provided by ceilometer still does not work. I wonder if this could be a S3 signature version issue on ceilometer side, that is on S3 client side. This kind of issue exists with the s3 client ?s3cmd? and you have to add ??signature-v2? so that ?s3cmd? works well. What do you think ? Do you know which version of S3 signature ceilometer uses while authenticating ? From: Rafael Weing?rtner > Sent: mercredi, 7 septembre 2022 19:23 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Jean, there are two problems with the Ceilometer. I just opened the patches to resolve it: - https://review.opendev.org/c/openstack/ceilometer/+/856305 - https://review.opendev.org/c/openstack/ceilometer/+/856304 Without these patches, you might have problems to use Ceilometer with Non-OpenStack dynamic pollsters and barbican credentials. On Wed, Aug 31, 2022 at 3:55 PM Rafael Weing?rtner > wrote: It is the RGW user that you have. This user must have the role that is needed to access the usage feature in RGW. If I am not mistaken, it required an admin user. On Wed, Aug 31, 2022 at 1:54 PM Taltavull Jean-Fran?ois > wrote: Thanks to your help, I am close to the goal. Dynamic pollster is loaded and triggered. But I get a ?Status[403] and reason [Forbidden]? in ceilometer logs while requesting admin/usage. I?m not sure to understand well the auth mechanism. Are we talking about keystone credentials, ec2 credentials, Rados GW user ?... For now, in testing phase, I use ?authentication_parameters?, not barbican. -JF From: Rafael Weing?rtner > Sent: mardi, 30 ao?t 2022 14:17 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Yes, you will need to enable the metric/pollster to be processed. That is done via "polling.yml" file. Also, do not forget that you will need to configure Ceilometer to push this new metric. If you use Gnocchi as the backend, you will need to change/update the gnocchi resource YML file. That file maps resources and metrics in the Gnocchi backend. The configuration resides in Ceilometer. You can create/define new resource types and map them to specific metrics. It depends on how you structure your solution. P.S. You do not need to use "authentication_parameters". You can use the barbican integration to avoid setting your credentials in a file. On Tue, Aug 30, 2022 at 9:11 AM Taltavull Jean-Fran?ois > wrote: Hello, I tried to define a Rados GW dynamic pollster and I can see, in Ceilometer logs, that it?s actually loaded. But it looks like it was not triggered, I see no trace of ceilometer connection in Rados GW logs. My definition: - name: "dynamic.radosgw.usage" sample_type: "gauge" unit: "B" value_attribute: "total.size" url_path: http:///object-store/swift/v1/admin/usage module: "awsauth" authentication_object: "S3Auth" authentication_parameters: xxxxxxxxxxxxx,yyyyyyyyyyyyy, user_id_attribute: "admin" project_id_attribute: "admin" resource_id_attribute: "admin" response_entries_key: "summary" Do I have to set an option in ceilometer.conf, or elsewhere, to get my Rados GW dynamic pollster triggered ? -JF From: Taltavull Jean-Fran?ois Sent: lundi, 29 ao?t 2022 18:41 To: 'Rafael Weing?rtner' > Cc: openstack-discuss > Subject: RE: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number Thanks a lot for your quick answer, Rafael ! I will explore this approach. Jean-Francois From: Rafael Weing?rtner > Sent: lundi, 29 ao?t 2022 17:54 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. You could use a different approach. You can use Dynamic pollster [1], and create your own mechanism to collect data, without needing to change Ceilometer code. Basically all hard-coded pollsters can be converted to a dynamic pollster that is defined in YML. [1] https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollster.html#the-dynamic-pollsters-system-configuration-for-non-openstack-apis On Mon, Aug 29, 2022 at 12:51 PM Taltavull Jean-Fran?ois > wrote: Hi All, In our OpenStack deployment, API endpoints are defined by using URLs instead of port numbers and HAProxy forwards requests to the right bakend after having ACLed the URL. In the case of our object-store service, based on RadosGW, the internal API endpoint is "https:///object-store/swift/v1/AUTH_" When Ceilometer RadosGW pollster tries to connect to the RadosGW admin API with the object-store internal endpoint, the URL becomes https:///admin, as shown by HAProxy logs. This URL does not match any API endpoint from HAProxy point of view. The line of code that rewrites the URL is this one: https://opendev.org/openstack/ceilometer/src/branch/stable/wallaby/ceilometer/objectstore/rgw.py#L81 What would you think of adding a mechanism based on new Ceilometer configuration option(s) to control the URL rewriting ? Our deployment characteristics: - OpenStack release: Wallaby - Ceph and RadosGW version: 15.2.16 - deployment tool: OSA 23.2.1 and ceph-ansible Best regards, Jean-Francois -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From radoslaw.piliszek at gmail.com Thu Sep 29 13:20:20 2022 From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=) Date: Thu, 29 Sep 2022 15:20:20 +0200 Subject: [kolla][centos][rdo] NOTICE: OVS version mismatch between Wallaby and later In-Reply-To: References: Message-ID: On Thu, 29 Sept 2022 at 14:36, Rados?aw Piliszek wrote: > > Dears, > > This is a notice to users of OVS with Kolla with CentOS-Stream-8-based > images or RDO directly. > It seems that RDO Wallaby currently installs OVS 2.17 while later ones > install OVS 2.15. > The problem is that currently: > *** > Upgrades from Wallaby to Xena will cause OVS to misbehave and lose all > network connectivity until host reboot. > *** > This is because downgrades of running OVS are not supported. > > We are investigating this issue, please stay tuned to this topic. The > solution we believe to be the correct one now is to bump OVS to 2.17 > also in later branches of RDO. RDO is now switching its testing flavor to 2.17 on Xena and Yoga. [1] Then it will be switched also on the release flavor (i.e. what appears in the primary repos and in Kolla images). Stay tuned. [1] https://review.rdoproject.org/r/c/rdoinfo/+/45381 Kind regards, Radek -yoctozepto From katonalala at gmail.com Thu Sep 29 15:20:47 2022 From: katonalala at gmail.com (Lajos Katona) Date: Thu, 29 Sep 2022 17:20:47 +0200 Subject: [neutron] Drivers meeting agenda -30.09.2022. Message-ID: Hi Neutron Drivers, The agenda for tomorrow's drivers meeting is at [1]. We have the following RFE to discuss: * [RFE] Expose Open vSwitch other_config column in the API (#link https://bugs.launchpad.net/neutron/+bug/1990842 ) [1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda See you at the meeting tomorrow. Lajos Katona (lajoskatona) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay at gr-oss.io Thu Sep 29 16:47:43 2022 From: jay at gr-oss.io (Jay Faulkner) Date: Thu, 29 Sep 2022 09:47:43 -0700 Subject: [all][tc] 2023.1 Antelope TC-PTG Planning In-Reply-To: <183680c4a58.dc375de7355972.8647386454272610958@ghanshyammann.com> References: <182d57d2a78.1127e41be140296.2872907929814651386@ghanshyammann.com> <183680c4a58.dc375de7355972.8647386454272610958@ghanshyammann.com> Message-ID: Hey all, In order to make this easier on folks (and to let the computers do timezone calculations!) I've created an ICS file that you can import into your calendaring app of choice to get these TC sessions added to your calendar. See you there, Jay Faulkner On Thu, Sep 22, 2022 at 7:08 PM Ghanshyam Mann wrote: > Updates: > > TC decided to meet at the below slots: > > * Monday 15:00 - 17:00 UTC (2 hours) for TC+leaders interaction discussion. > * Thursday 15:00 - 19:00 UTC (4 hours) > * Friday 15:00 - 19:00 UTC (4 hours) > > PLEASE NOTE: To minimize the conflict with the project sessions, the last > 2 hours on Thursday and Friday are booked out of the PTG schedule. > > Details are there in the below etherpad, please start adding the topic you > would like to discuss: > > - https://etherpad.opendev.org/p/tc-2023-1-ptg > > > -gmann > > ---- On Thu, 25 Aug 2022 07:52:06 -0700 Ghanshyam Mann wrote --- > > Hello Everyone, > > > > As you already know that the 2023.1 cycle virtual PTG will be held > between Oct 17th - 21[1]. > > > > I have started the preparation for the Technical Committee PTG > sessions. Please do the following: > > > > 1. Fill the below poll as per your availability. > > > > - https://framadate.org/yi8LNQaph5wrirks > > > > 2. Add the topics you would like to discuss to the below etherpad. > > > > - https://etherpad.opendev.org/p/tc-2023-1-ptg > > > > NOTE: this is not limited to TC members only; I would like all > community members to > > fill the doodle poll and, add the topics you would like or want TC > members to discuss in PTG. > > > > [1] > https://lists.openstack.org/pipermail/openstack-discuss/2022-August/030041.html > > > > -gmann > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 1604 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tc-ptg-2023-1.ics Type: text/calendar Size: 1634 bytes Desc: not available URL: From jay at gr-oss.io Thu Sep 29 17:49:20 2022 From: jay at gr-oss.io (Jay Faulkner) Date: Thu, 29 Sep 2022 10:49:20 -0700 Subject: [ironic] Stable & Bugfix branch maintenance and retirement Message-ID: Hi folks, I'm letting you all know it's my intention to, very soon, perform the following actions on all Ironic projects: 1) Perform a release for any maintained stable and bugfix branches (EM stable branches excluded by policy) 2) Retire all stable branches for releases prior to stable/train (For Ironic; this is queens, rocky, and stein -- I have not enumerated them yet for other projects). If you either have code you'd like to ensure gets in the stable release or want to step up and volunteer to maintain the older branches -- including backporting existing bugfixes that did not make it back that far and maintaining CI -- please let me know within the next couple of days. Thanks, Jay Faulkner OpenStack Ironic PTL OpenStack TC member -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay at gr-oss.io Thu Sep 29 17:51:20 2022 From: jay at gr-oss.io (Jay Faulkner) Date: Thu, 29 Sep 2022 10:51:20 -0700 Subject: [all][tc] 2023.1 Antelope TC-PTG Planning In-Reply-To: References: <182d57d2a78.1127e41be140296.2872907929814651386@ghanshyammann.com> <183680c4a58.dc375de7355972.8647386454272610958@ghanshyammann.com> Message-ID: It was indicated to me that some GMail users were having trouble importing this ICS file. Please use the following procedure for best results: Open Google Calendar, click the gear and choose Settings, then select Import & Export from the left side, and import the ICS file attached on the previous email on this thread. When properly imported; you should see all three meetings imported from that single ICS file. Please reach out to me over email or at JayF in #openstack-tc if there are any further issues. -Jay Faulkner On Thu, Sep 29, 2022 at 9:47 AM Jay Faulkner wrote: > Hey all, > > In order to make this easier on folks (and to let the computers do > timezone calculations!) I've created an ICS file that you can import into > your calendaring app of choice to get these TC sessions added to your > calendar. > > See you there, > Jay Faulkner > > On Thu, Sep 22, 2022 at 7:08 PM Ghanshyam Mann > wrote: > >> Updates: >> >> TC decided to meet at the below slots: >> >> * Monday 15:00 - 17:00 UTC (2 hours) for TC+leaders interaction >> discussion. >> * Thursday 15:00 - 19:00 UTC (4 hours) >> * Friday 15:00 - 19:00 UTC (4 hours) >> >> PLEASE NOTE: To minimize the conflict with the project sessions, the last >> 2 hours on Thursday and Friday are booked out of the PTG schedule. >> >> Details are there in the below etherpad, please start adding the topic >> you would like to discuss: >> >> - https://etherpad.opendev.org/p/tc-2023-1-ptg >> >> >> -gmann >> >> ---- On Thu, 25 Aug 2022 07:52:06 -0700 Ghanshyam Mann wrote --- >> > Hello Everyone, >> > >> > As you already know that the 2023.1 cycle virtual PTG will be held >> between Oct 17th - 21[1]. >> > >> > I have started the preparation for the Technical Committee PTG >> sessions. Please do the following: >> > >> > 1. Fill the below poll as per your availability. >> > >> > - https://framadate.org/yi8LNQaph5wrirks >> > >> > 2. Add the topics you would like to discuss to the below etherpad. >> > >> > - https://etherpad.opendev.org/p/tc-2023-1-ptg >> > >> > NOTE: this is not limited to TC members only; I would like all >> community members to >> > fill the doodle poll and, add the topics you would like or want TC >> members to discuss in PTG. >> > >> > [1] >> https://lists.openstack.org/pipermail/openstack-discuss/2022-August/030041.html >> > >> > -gmann >> > >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafaelweingartner at gmail.com Thu Sep 29 15:23:04 2022 From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=) Date: Thu, 29 Sep 2022 12:23:04 -0300 Subject: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number In-Reply-To: <1d1c1c3cc6184b529819bb8f3598813f@elca.ch> References: <2aa77e24a33d48a69032f30b86e9cad8@elca.ch> <1b17c23f8982480db73cf50d04d51af7@elca.ch> <86f048d7931c4cc482f6785437c9b5ea@elca.ch> <671023b5ab3846dfb3a39ef313018eac@elca.ch> <33f69d386462450b9964b2ed78284d57@elca.ch> <1d1c1c3cc6184b529819bb8f3598813f@elca.ch> Message-ID: This is the signature used by the `awsauth` library: ``` def get_signature(self, r): canonical_string = self.get_canonical_string( r.url, r.headers, r.method) if py3k: key = self.secret_key.encode('utf-8') msg = canonical_string.encode('utf-8') else: key = self.secret_key msg = canonical_string h = hmac.new(key, msg, digestmod=sha) return encodestring(h.digest()).strip() ``` After that is generated, it is added in the headers: # Create date header if it is not created yet. if 'date' not in r.headers and 'x-amz-date' not in r.headers: r.headers['date'] = formatdate( timeval=None, localtime=False, usegmt=True) signature = self.get_signature(r) if py3k: signature = signature.decode('utf-8') r.headers['Authorization'] = 'AWS %s:%s' % (self.access_key, signature) On Thu, Sep 29, 2022 at 9:15 AM Taltavull Jean-Fran?ois < jean-francois.taltavull at elca.ch> wrote: > ``` > > $ python test_creds.py > > Executing test on: [FQDN/object-store/]. > > Rados GW admin context [/admin] and path [/usage?stats=True] used. > > Rados GW request URL [http://FQDN/object-store/admin/bucket?stats=True]. > > Rados GW host: FQDN > > Traceback (most recent call last): > > File "test_creds.py", line 45, in > > raise RGWAdminAPIFailed( > > __main__.RGWAdminAPIFailed: RGW AdminOps API returned 403 Forbidden > > ``` > > > > So the same as with ceilometer. Auth is done by RGW, not by keystone, and > the ceph ?admin? user exists and owns the right privileges: > > ``` > > $ sudo radosgw-admin user info --uid > admin > [22/296]{ > > "user_id": "admin", > > "display_name": "admin user", > > "email": "", > > "suspended": 0, > > "max_buckets": 1000, > > "subusers": [], > > "keys": [ > > { > > "user": "admin", > > "access_key": ?admin_access_key", > > "secret_key": "admin_secret_key" > > } > > ], > > "swift_keys": [], > > "caps": [ > > { > > "type": "buckets", > > "perm": "*" > > }, > > { > > "type": "metadata", > > "perm": "*" > > }, > > > { > "type": > "usage", > "perm": > "*" > }, > { > > "type": "users", > "perm": > "*" > } > ], > > > > > ``` > > > > > > *From:* Rafael Weing?rtner > *Sent:* jeudi, 29 septembre 2022 12:32 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Can you test you credentials with the following code? > > ``` > > import json > import requests > import os > > import six.moves.urllib.parse as urlparse > > > class RGWAdminAPIFailed(Exception): > pass > > > if __name__ == '__main__': > > rados_gw_base_url = "put your RGW URL here. E.g. > http://server.com:port/something" > print("Executing test on: [%s]." % rados_gw_base_url) > > rados_gw_admin_context = "/admin" > > rados_gw_path = "/usage?stats=True" > > print("Rados GW admin context [%s] and path [%s] used." % > (rados_gw_admin_context, rados_gw_path)) > > rados_gw_request_url = urlparse.urljoin(rados_gw_base_url, '/admin') + > '/bucket?stats=True' > print("Rados GW request URL [%s]." % rados_gw_request_url) > > rados_gw_access_key_to_use = "put your access key here" > rados_gw_secret_key_to_use = "put your secret key here" > > rados_gw_host_name = urlparse.urlparse(rados_gw_request_url).netloc > print("Rados GW host: %s" % rados_gw_host_name) > module_name = "awsauth" > class_name = "S3Auth" > arguments = [rados_gw_access_key_to_use, rados_gw_secret_key_to_use, > rados_gw_host_name] > module = __import__(module_name) > class_ = getattr(module, class_name) > instance = class_(*arguments) > > r = requests.get( > rados_gw_request_url, > auth=instance, timeout=30) > #auth=awsauth.S3Auth(*arguments)) > > > if r.status_code != 200: > raise RGWAdminAPIFailed( > ('RGW AdminOps API returned %(status)s %(reason)s') % > {'status': r.status_code, 'reason': r.reason}) > > response_body = r.text > parsed_json = json.loads(response_body) > > print("Response cookies: [%s]." % r.cookies) > > radosGw_output_file = "/home//Downloads/radosGw-usage.json" > > if os.path.exists(radosGw_output_file): > os.remove(radosGw_output_file) > > with open(radosGw_output_file, "w") as file1: > file1.writelines(json.dumps(parsed_json, indent=4, sort_keys=True)) > file1.flush() > > exit(0) > > ``` > > > > On Thu, Sep 29, 2022 at 4:09 AM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > python > > Python 3.8.10 (default, Sep 28 2021, 16:10:42) > > [GCC 9.3.0] on linux > > Type "help", "copyright", "credits" or "license" for more information. > > >>> import awsauth > > >>> awsauth > > '/openstack/venvs/ceilometer-23.2.0/lib/python3.8/site-packages/awsauth.py'> > > >>> > > > > *From:* Rafael Weing?rtner > *Sent:* mercredi, 28 septembre 2022 18:40 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Can you also execute the following: > > ``` > > python > > > > import awsauth > > > > awsauth > > ``` > > That will output a path, and then you can `cat `, example: `cat > /var/lib/kolla/venv/lib/python3.8/site-packages/awsauth.py` > > > > On Wed, Sep 28, 2022 at 1:21 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > I removed trailing ?/object-store/? from the last value of > authentication_parameters > > > > I also: > > - disabled s3 keystone auth in RGW > > - created a RGW ?admin? user with the right privileges to allow admin API > calls > > - put RGW in debug mode > > > > And here is what I get in RGW logs: > > > > get_usage > string_to_sign=GET > Wed, > 28 Sep 2022 16:15:45 > GMT > /admin/usage > > get_usage server signature=BlaBlaBlaBla > > get_usage client signature=BloBloBlo > > get_usage compare=-75 > > get_usage rgw::auth::s3::LocalEngine denied with reason=-2027 > > get_usage rgw::auth::s3::AWSAuthStrategy denied with reason=-2027 > > get_usage rgw::auth::StrategyRegistry::s3_main_strategy_t: trying > rgw::auth::s3::AWSAuthStrategy > > get_usage rgw::auth::s3::AWSAuthStrategy: trying rgw::auth::s3::LocalEngine > > > > *From:* Rafael Weing?rtner > *Sent:* mercredi, 28 septembre 2022 13:15 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > I think that the last parameter "/object-store/", should be only " > ". Can you test it? > > > > > > You are using EC2 credentials to authenticate in RGW. Did you enable the > Keystone integration in RGW? > > Also, as far as I know, this admin endpoint needs a RGW admin. I am not > sure if the Keystone and RGW integration would enable/make it possible for > someone to authenticate as an admin in RGW. Can you check it? To see if you > can call that endpoint with these credentials. > > > > On Wed, Sep 28, 2022 at 6:01 AM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Pollster YML configuration : > > > > --- > > - name: "dynamic.radosgw.usage" > > sample_type: "gauge" > > unit: "B" > > value_attribute: "total.size" > > url_path: http:///object-store/admin/usage > > module: "awsauth" > > authentication_object: "S3Auth" > > authentication_parameters: ,,/object-store/ > > user_id_attribute: "user" > > project_id_attribute: "user" > > resource_id_attribute: "user" > > response_entries_key: "summary" > > > > ACCESS_KEY and SECRET_KEY have been created with ?openstack ec2 > credentials create?. > > > > Ceilometer central is deployed with OSA and it uses awsauth.py module. > > > > > > *From:* Rafael Weing?rtner > *Sent:* mercredi, 28 septembre 2022 02:01 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Can you show your YML configuration? Also, did you install the AWS > authentication module in the container/host where Ceilometer central is > running? > > > > On Mon, Sep 26, 2022 at 12:58 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Hello Rafael, > > > > Thanks for the information about ceilometer patches but for now I?m > testing with the credentials in the dynamic pollster config file. I will > use barbican when I push all this to production. > > > > The keystone authentication performed by the rados gw with the credentials > provided by ceilometer still does not work. I wonder if this could be a S3 > signature version issue on ceilometer side, that is on S3 client side. This > kind of issue exists with the s3 client ?s3cmd? and you have to add > ??signature-v2? so that ?s3cmd? works well. > > > > What do you think ? Do you know which version of S3 signature ceilometer > uses while authenticating ? > > > > *From:* Rafael Weing?rtner > *Sent:* mercredi, 7 septembre 2022 19:23 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Jean, there are two problems with the Ceilometer. I just opened the > patches to resolve it: > - https://review.opendev.org/c/openstack/ceilometer/+/856305 > > - https://review.opendev.org/c/openstack/ceilometer/+/856304 > > > > Without these patches, you might have problems to use Ceilometer with > Non-OpenStack dynamic pollsters and barbican credentials. > > > > On Wed, Aug 31, 2022 at 3:55 PM Rafael Weing?rtner < > rafaelweingartner at gmail.com> wrote: > > It is the RGW user that you have. This user must have the role that is > needed to access the usage feature in RGW. If I am not mistaken, it > required an admin user. > > > > On Wed, Aug 31, 2022 at 1:54 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Thanks to your help, I am close to the goal. Dynamic pollster is loaded > and triggered. > > > > But I get a ?Status[403] and reason [Forbidden]? in ceilometer logs while > requesting admin/usage. > > > > I?m not sure to understand well the auth mechanism. Are we talking about > keystone credentials, ec2 credentials, Rados GW user ?... > > > > For now, in testing phase, I use ?authentication_parameters?, not barbican. > > > > -JF > > > > *From:* Rafael Weing?rtner > *Sent:* mardi, 30 ao?t 2022 14:17 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Yes, you will need to enable the metric/pollster to be processed. That is > done via "polling.yml" file. Also, do not forget that you will need to > configure Ceilometer to push this new metric. If you use Gnocchi as the > backend, you will need to change/update the gnocchi resource YML file. That > file maps resources and metrics in the Gnocchi backend. The configuration > resides in Ceilometer. You can create/define new resource types and map > them to specific metrics. It depends on how you structure your solution. > > P.S. You do not need to use "authentication_parameters". You can use the > barbican integration to avoid setting your credentials in a file. > > > > On Tue, Aug 30, 2022 at 9:11 AM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Hello, > > > > I tried to define a Rados GW dynamic pollster and I can see, in Ceilometer > logs, that it?s actually loaded. But it looks like it was not triggered, I > see no trace of ceilometer connection in Rados GW logs. > > > > My definition: > > > > - name: "dynamic.radosgw.usage" > > sample_type: "gauge" > > unit: "B" > > value_attribute: "total.size" > > url_path: http:///object-store/swift/v1/admin/usage > > module: "awsauth" > > authentication_object: "S3Auth" > > authentication_parameters: xxxxxxxxxxxxx,yyyyyyyyyyyyy, > > user_id_attribute: "admin" > > project_id_attribute: "admin" > > resource_id_attribute: "admin" > > response_entries_key: "summary" > > > > Do I have to set an option in ceilometer.conf, or elsewhere, to get my > Rados GW dynamic pollster triggered ? > > > > -JF > > > > *From:* Taltavull Jean-Fran?ois > *Sent:* lundi, 29 ao?t 2022 18:41 > *To:* 'Rafael Weing?rtner' > *Cc:* openstack-discuss > *Subject:* RE: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > Thanks a lot for your quick answer, Rafael ! > > I will explore this approach. > > > > Jean-Francois > > > > *From:* Rafael Weing?rtner > *Sent:* lundi, 29 ao?t 2022 17:54 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > You could use a different approach. You can use Dynamic pollster [1], and > create your own mechanism to collect data, without needing to change > Ceilometer code. Basically all hard-coded pollsters can be converted to a > dynamic pollster that is defined in YML. > > > > [1] > https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollster.html#the-dynamic-pollsters-system-configuration-for-non-openstack-apis > > > > > > On Mon, Aug 29, 2022 at 12:51 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Hi All, > > In our OpenStack deployment, API endpoints are defined by using URLs > instead of port numbers and HAProxy forwards requests to the right bakend > after having ACLed the URL. > > In the case of our object-store service, based on RadosGW, the internal > API endpoint is "https:///object-store/swift/v1/AUTH_" > > When Ceilometer RadosGW pollster tries to connect to the RadosGW admin API > with the object-store internal endpoint, the URL becomes > https:///admin, as shown by HAProxy logs. This URL does not match > any API endpoint from HAProxy point of view. The line of code that rewrites > the URL is this one: > https://opendev.org/openstack/ceilometer/src/branch/stable/wallaby/ceilometer/objectstore/rgw.py#L81 > > What would you think of adding a mechanism based on new Ceilometer > configuration option(s) to control the URL rewriting ? > > Our deployment characteristics: > - OpenStack release: Wallaby > - Ceph and RadosGW version: 15.2.16 > - deployment tool: OSA 23.2.1 and ceph-ansible > > > Best regards, > Jean-Francois > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > -- Rafael Weing?rtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From josephine.seifert at secustack.com Fri Sep 30 08:27:11 2022 From: josephine.seifert at secustack.com (Josephine Seifert) Date: Fri, 30 Sep 2022 10:27:11 +0200 Subject: [Image Encryption] No meeting on Monday Message-ID: <1f51e323-5dc2-5d2c-3f34-d77a615b1ff2@secustack.com> Hi, Monday the 3. of October is a national holiday. So there will not be a meeting for the Image Encryption pop up team. cheers, Luzi From skaplons at redhat.com Fri Sep 30 09:16:42 2022 From: skaplons at redhat.com (Slawek Kaplonski) Date: Fri, 30 Sep 2022 11:16:42 +0200 Subject: [all] Skip level upgrades (SLURP) grenade job Message-ID: <2192586.PpGQZzfNtr@p1> Hi, As You may know there some time ago TC merged resolution about release cadence adjustment [1]. According to that resolution starting from 2023.1 (Antelope) will be first "SLURP" release. That means that upgrade directly from 2023.1 to 2024.1 ("C") needs to be supported so projects will need to run "skip-level" grenade job [2]. To start that effort and see how it works currently and what needs to be done/fixed by teams we (TC) would like to ask teams to add such job to CI in the current (2023.1) cycle already. That job will test upgrade from Yoga to master (2023.1). You can refer to the Manila job [3] and do something similar in Your project. If that job will cause some problems, You can make it non-voting temporary and work on fix it but we highly recommend to have this job voting already. If You would have any questions, please reach out to us here or on the #openstack-tc IRC channel. [1] https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html [2] https://github.com/openstack/grenade/blob/b1cd7a1866ee7d17392bd9896db6060d40463726/.zuul.yaml#L378 [3] https://review.opendev.org/c/openstack/manila/+/859875 -- Slawek Kaplonski Principal Software Engineer Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: From ralonsoh at redhat.com Fri Sep 30 10:00:19 2022 From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez) Date: Fri, 30 Sep 2022 12:00:19 +0200 Subject: [neutron] PTG topics and scheduling Message-ID: Hello all: Based on the schedule polls results, I've booked the Neutron meetings from Tuesday to Thursday in Mitaka channel [1], from 13UTC to 16UTC. Of course, if that is not enough, we can always use Friday to continue any pending conversation. The operator hour (actually 2), will be on Friday (pending for reservation), from 13UTC to 15UTC. Please continue adding any topic you want to discuss in the Neutron etherpad [2]. There is a specific section for the Nova-Neutron cross-team meeting. If you have any doubt or question, do not hesitate to let me know (IRC: ralonsoh, mail: ralonsoh at redhat.com). You can also ping any core reviewer in #openstack-neutron channel. See you in a few weeks! [1]https://ptg.opendev.org/ptg.html [2]https://etherpad.opendev.org/p/neutron-antelope-ptg -------------- next part -------------- An HTML attachment was scrubbed... URL: From neil at tigera.io Fri Sep 30 10:09:27 2022 From: neil at tigera.io (Neil Jerram) Date: Fri, 30 Sep 2022 11:09:27 +0100 Subject: TLS error when cloning https://opendev.org/openstack/devstack Message-ID: Anyone else seeing this? neil at glaurung:~/tt$ git clone https://opendev.org/openstack/devstack Cloning into 'devstack'... remote: Enumerating objects: 28589, done. remote: Counting objects: 100% (28589/28589), done. remote: Compressing objects: 100% (9638/9638), done. error: RPC failed; curl 56 GnuTLS recv error (-9): Error decoding the received TLS packet. fatal: early EOF fatal: fetch-pack: invalid index-pack output Best wishes, Neil -- Neil Jerram Principal Software Engineer Tigera neil at tigera.io | @neiljerram Follow Tigera: Blog | Twitter | LinkedIn Security and observability for containers, Kubernetes, and cloud -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.dibbo at stfc.ac.uk Fri Sep 30 10:13:18 2022 From: alexander.dibbo at stfc.ac.uk (Alexander Dibbo - STFC UKRI) Date: Fri, 30 Sep 2022 10:13:18 +0000 Subject: Live Migration Issues Message-ID: Hi All, I'm having a few issues with live migration at the moment. This is an openstack train deployed with rdo packages. 1. when migrating some VMs the migration succeeds but the VM doesn't move and the following error can be found in the nova logs with nothing that seems to correspond in the neutron logs: 2022-09-30 11:04:04.069 716669 INFO nova.compute.manager [-] [instance: c10d1d9e-2baf-4ab5-ba3a-2f60f521aea6] Took 76.49 seconds for pre_live_migration on destination host hv548.nubes.rl. ac.uk. 2022-09-30 11:04:04.720 716669 ERROR nova.virt.libvirt.driver [-] [instance: c10d1d9e-2baf-4ab5-ba3a-2f60f521aea6] Live Migration failure: 'fa:ca:ad:1f:71:41' 2. When migrating some VMs the migration is marked as complete and the VM is moved from the source to the destination hypervisor but nova keeps the migrating state and doesn't update the host or the node fields. The following error is found in nova with no corresponding error that I can find in neutron. The config is the same across all hypervisors. 2022-09-13 10:37:23.709 12387 ERROR nova.network.neutronv2.api [req-ee51a8b4-911c-4f92-860b-9d6a7a24c786 27be800439c244c1bd742ff056cf700c 4de86830e89b4a46b590536571b6ccd4 - 38372510d9bb4ac7916178b062d387de 38372510d9bb4ac7916178b062d387de] Neutron client was not able to generate a valid admin token, please verify Neutron admin credential located in nova.conf: neutronclient.common.exceptions.Unauthorized: 401-{'error': {'message': 'The request you have made requires authentication.', 'code': 401, 'title': 'Unauthorized'}} 2022-09-13 10:37:23.845 12387 ERROR oslo_messaging.rpc.server [req-ee51a8b4-911c-4f92-860b-9d6a7a24c786 27be800439c244c1bd742ff056cf700c 4de86830e89b4a46b590536571b6ccd4 - 38372510d9bb4ac7916178b062d387de 38372510d9bb4ac7916178b062d387de] Exception during message handling: nova.exception.NeutronAdminCredentialConfigurationInvalid: Networking client is experiencing an unauthorized exception. Regards Alexander Dibbo - Cloud Architect / Cloud Operations Group Leader For STFC Cloud Documentation visit https://stfc-cloud-docs.readthedocs.io To raise a support ticket with the cloud team please email cloud-support at stfc.ac.uk To receive notifications about the service please subscribe to our mailing list at: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=STFC-CLOUD To receive fast notifications or to discuss usage of the cloud please join our Slack: https://stfc-cloud.slack.com/ This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. -------------- next part -------------- An HTML attachment was scrubbed... URL: From artem.goncharov at gmail.com Fri Sep 30 10:41:11 2022 From: artem.goncharov at gmail.com (Artem Goncharov) Date: Fri, 30 Sep 2022 12:41:11 +0200 Subject: TLS error when cloning https://opendev.org/openstack/devstack In-Reply-To: References: Message-ID: I experience similar (but not same) error cloning freshly SDK repo [linux at demo ~]$ git clone https://opendev.org/openstack/openstacksdk Cloning into 'openstacksdk'... remote: Enumerating objects: 22680, done. remote: Counting objects: 100% (22680/22680), done. remote: Compressing objects: 100% (4690/4690), done. error: RPC failed; curl 18 transfer closed with outstanding read data remaining fatal: early EOF fatal: fetch-pack: invalid index-pack output Artem > On 30. Sep 2022, at 12:09, Neil Jerram wrote: > > Anyone else seeing this? > > neil at glaurung:~/tt$ git clone https://opendev.org/openstack/devstack > Cloning into 'devstack'... > remote: Enumerating objects: 28589, done. > remote: Counting objects: 100% (28589/28589), done. > remote: Compressing objects: 100% (9638/9638), done. > error: RPC failed; curl 56 GnuTLS recv error (-9): Error decoding the received TLS packet. > fatal: early EOF > fatal: fetch-pack: invalid index-pack output > > Best wishes, > Neil > > -- > Neil Jerram > Principal Software Engineer > Tigera > neil at tigera.io | @neiljerram > Follow Tigera: Blog | Twitter | LinkedIn > Security and observability for containers, Kubernetes, and cloud > -------------- next part -------------- An HTML attachment was scrubbed... URL: From katonalala at gmail.com Fri Sep 30 11:06:49 2022 From: katonalala at gmail.com (Lajos Katona) Date: Fri, 30 Sep 2022 13:06:49 +0200 Subject: TLS error when cloning https://opendev.org/openstack/devstack In-Reply-To: References: Message-ID: Hi, I had the same with keystone, and pulling Neutron, but strangely pulling neutron-lib (and networking-bagpipe also) worked... Lajos Artem Goncharov ezt ?rta (id?pont: 2022. szept. 30., P, 12:48): > I experience similar (but not same) error cloning freshly SDK repo > > [linux at demo ~]$ git clone https://opendev.org/openstack/openstacksdk > Cloning into 'openstacksdk'... > remote: Enumerating objects: 22680, done. > remote: Counting objects: 100% (22680/22680), done. > remote: Compressing objects: 100% (4690/4690), done. > error: RPC failed; curl 18 transfer closed with outstanding read data > remaining > fatal: early EOF > fatal: fetch-pack: invalid index-pack output > > Artem > > On 30. Sep 2022, at 12:09, Neil Jerram wrote: > > Anyone else seeing this? > > neil at glaurung:~/tt$ git clone https://opendev.org/openstack/devstack > Cloning into 'devstack'... > remote: Enumerating objects: 28589, done. > remote: Counting objects: 100% (28589/28589), done. > remote: Compressing objects: 100% (9638/9638), done. > error: RPC failed; curl 56 GnuTLS recv error (-9): Error decoding the > received TLS packet. > fatal: early EOF > fatal: fetch-pack: invalid index-pack output > > Best wishes, > Neil > > -- > Neil Jerram > Principal Software Engineer > Tigera > neil at tigera.io | @neiljerram > Follow Tigera: Blog | Twitter > | LinkedIn > > > Security and observability for containers, Kubernetes, and cloud > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neil at tigera.io Fri Sep 30 11:55:35 2022 From: neil at tigera.io (Neil Jerram) Date: Fri, 30 Sep 2022 12:55:35 +0100 Subject: TLS error when cloning https://opendev.org/openstack/devstack In-Reply-To: References: Message-ID: Yes, I've seen a failure with keystone as well today, and in some of my CI runs devstack itself has been OK. But in the context of a whole devstack setup, it seems there's currently a flake which is very likely to prevent the setup as a whole from succeeding. On Fri, Sep 30, 2022 at 12:07 PM Lajos Katona wrote: > Hi, > I had the same with keystone, and pulling Neutron, but strangely pulling > neutron-lib (and networking-bagpipe also) worked... > > Lajos > > Artem Goncharov ezt ?rta (id?pont: 2022. > szept. 30., P, 12:48): > >> I experience similar (but not same) error cloning freshly SDK repo >> >> [linux at demo ~]$ git clone https://opendev.org/openstack/openstacksdk >> Cloning into 'openstacksdk'... >> remote: Enumerating objects: 22680, done. >> remote: Counting objects: 100% (22680/22680), done. >> remote: Compressing objects: 100% (4690/4690), done. >> error: RPC failed; curl 18 transfer closed with outstanding read data >> remaining >> fatal: early EOF >> fatal: fetch-pack: invalid index-pack output >> >> Artem >> >> On 30. Sep 2022, at 12:09, Neil Jerram wrote: >> >> Anyone else seeing this? >> >> neil at glaurung:~/tt$ git clone https://opendev.org/openstack/devstack >> Cloning into 'devstack'... >> remote: Enumerating objects: 28589, done. >> remote: Counting objects: 100% (28589/28589), done. >> remote: Compressing objects: 100% (9638/9638), done. >> error: RPC failed; curl 56 GnuTLS recv error (-9): Error decoding the >> received TLS packet. >> fatal: early EOF >> fatal: fetch-pack: invalid index-pack output >> >> Best wishes, >> Neil >> >> -- >> Neil Jerram >> Principal Software Engineer >> Tigera >> neil at tigera.io | @neiljerram >> Follow Tigera: Blog | Twitter >> | LinkedIn >> >> >> Security and observability for containers, Kubernetes, and cloud >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Fri Sep 30 12:51:42 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 30 Sep 2022 12:51:42 +0000 Subject: [infra] TLS error when cloning https://opendev.org/openstack/devstack In-Reply-To: References: Message-ID: <20220930125142.elicofi3tnc34pd3@yuggoth.org> On 2022-09-30 11:09:27 +0100 (+0100), Neil Jerram wrote: > Anyone else seeing this? > > neil at glaurung:~/tt$ git clone https://opendev.org/openstack/devstack > Cloning into 'devstack'... > remote: Enumerating objects: 28589, done. > remote: Counting objects: 100% (28589/28589), done. > remote: Compressing objects: 100% (9638/9638), done. > error: RPC failed; curl 56 GnuTLS recv error (-9): Error decoding the > received TLS packet. > fatal: early EOF > fatal: fetch-pack: invalid index-pack output [...] I've tested each of our 8 backends individually by cloning devstack from them directly, and am not seeing any errors. If there is a problem with one (or more) of them, it's not consistent. Our cacti graphs show no significant spikes in activity nor resource consumption on the backends or the load balancer around the time the first message about this was posted. Is the problem ongoing at this point? Persistent or inconsistent? Are there any commonalities for the people/sites where the errors are being observed? -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From neil at tigera.io Fri Sep 30 13:05:39 2022 From: neil at tigera.io (Neil Jerram) Date: Fri, 30 Sep 2022 14:05:39 +0100 Subject: [infra] TLS error when cloning https://opendev.org/openstack/devstack In-Reply-To: <20220930125142.elicofi3tnc34pd3@yuggoth.org> References: <20220930125142.elicofi3tnc34pd3@yuggoth.org> Message-ID: For me it seems to be still ongoing. I have been seeing these errors in CI runs from .semaphoreci.com. There have been 6 occurrences in the last 5 hours, all when cloning either devstack or keystone, and all with an error like "error: RPC failed; curl 56 GnuTLS recv error (-9): A TLS packet with unexpected length was received." I've just kicked off a new run just now, and it has got past cloning devstack - I'll write again about how that goes. On Fri, Sep 30, 2022 at 1:53 PM Jeremy Stanley wrote: > On 2022-09-30 11:09:27 +0100 (+0100), Neil Jerram wrote: > > Anyone else seeing this? > > > > neil at glaurung:~/tt$ git clone https://opendev.org/openstack/devstack > > Cloning into 'devstack'... > > remote: Enumerating objects: 28589, done. > > remote: Counting objects: 100% (28589/28589), done. > > remote: Compressing objects: 100% (9638/9638), done. > > error: RPC failed; curl 56 GnuTLS recv error (-9): Error decoding the > > received TLS packet. > > fatal: early EOF > > fatal: fetch-pack: invalid index-pack output > [...] > > I've tested each of our 8 backends individually by cloning devstack > from them directly, and am not seeing any errors. If there is a > problem with one (or more) of them, it's not consistent. Our cacti > graphs show no significant spikes in activity nor resource > consumption on the backends or the load balancer around the time > the first message about this was posted. > > Is the problem ongoing at this point? Persistent or inconsistent? > Are there any commonalities for the people/sites where the errors > are being observed? > -- > Jeremy Stanley > -------------- next part -------------- An HTML attachment was scrubbed... URL: From katonalala at gmail.com Fri Sep 30 13:25:08 2022 From: katonalala at gmail.com (Lajos Katona) Date: Fri, 30 Sep 2022 15:25:08 +0200 Subject: [infra] TLS error when cloning https://opendev.org/openstack/devstack In-Reply-To: References: <20220930125142.elicofi3tnc34pd3@yuggoth.org> Message-ID: Hi, For me it seems things are ok now. Thanks for checking. Lajos Neil Jerram ezt ?rta (id?pont: 2022. szept. 30., P, 15:16): > For me it seems to be still ongoing. I have been seeing these errors in > CI runs from .semaphoreci.com. There have been 6 occurrences > in the last 5 hours, all when cloning either devstack or keystone, and all > with an error like "error: RPC failed; curl 56 GnuTLS recv error (-9): A > TLS packet with unexpected length was received." I've just kicked off a > new run just now, and it has got past cloning devstack - I'll write again > about how that goes. > > > On Fri, Sep 30, 2022 at 1:53 PM Jeremy Stanley wrote: > >> On 2022-09-30 11:09:27 +0100 (+0100), Neil Jerram wrote: >> > Anyone else seeing this? >> > >> > neil at glaurung:~/tt$ git clone https://opendev.org/openstack/devstack >> > Cloning into 'devstack'... >> > remote: Enumerating objects: 28589, done. >> > remote: Counting objects: 100% (28589/28589), done. >> > remote: Compressing objects: 100% (9638/9638), done. >> > error: RPC failed; curl 56 GnuTLS recv error (-9): Error decoding the >> > received TLS packet. >> > fatal: early EOF >> > fatal: fetch-pack: invalid index-pack output >> [...] >> >> I've tested each of our 8 backends individually by cloning devstack >> from them directly, and am not seeing any errors. If there is a >> problem with one (or more) of them, it's not consistent. Our cacti >> graphs show no significant spikes in activity nor resource >> consumption on the backends or the load balancer around the time >> the first message about this was posted. >> >> Is the problem ongoing at this point? Persistent or inconsistent? >> Are there any commonalities for the people/sites where the errors >> are being observed? >> -- >> Jeremy Stanley >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neil at tigera.io Fri Sep 30 13:59:21 2022 From: neil at tigera.io (Neil Jerram) Date: Fri, 30 Sep 2022 14:59:21 +0100 Subject: [infra] TLS error when cloning https://opendev.org/openstack/devstack In-Reply-To: References: <20220930125142.elicofi3tnc34pd3@yuggoth.org> Message-ID: On Fri, Sep 30, 2022 at 2:05 PM Neil Jerram wrote: > For me it seems to be still ongoing. I have been seeing these errors in > CI runs from .semaphoreci.com. There have been 6 occurrences > in the last 5 hours, all when cloning either devstack or keystone, and all > with an error like "error: RPC failed; curl 56 GnuTLS recv error (-9): A > TLS packet with unexpected length was received." I've just kicked off a > new run just now, and it has got past cloning devstack - I'll write again > about how that goes. > That test actually passed. But then I kicked off two more, and the first of those failed with Cloning into '/opt/stack/neutron'... error: RPC failed; curl 56 GnuTLS recv error (-9): A TLS packet with unexpected length was received. fatal: early EOF fatal: fetch-pack: invalid index-pack output The second is still running, unusually slowly. It appears to be in the middle of cloning Nova - possibly hung there. Best wishes, Neil > > On Fri, Sep 30, 2022 at 1:53 PM Jeremy Stanley wrote: > >> On 2022-09-30 11:09:27 +0100 (+0100), Neil Jerram wrote: >> > Anyone else seeing this? >> > >> > neil at glaurung:~/tt$ git clone https://opendev.org/openstack/devstack >> > Cloning into 'devstack'... >> > remote: Enumerating objects: 28589, done. >> > remote: Counting objects: 100% (28589/28589), done. >> > remote: Compressing objects: 100% (9638/9638), done. >> > error: RPC failed; curl 56 GnuTLS recv error (-9): Error decoding the >> > received TLS packet. >> > fatal: early EOF >> > fatal: fetch-pack: invalid index-pack output >> [...] >> >> I've tested each of our 8 backends individually by cloning devstack >> from them directly, and am not seeing any errors. If there is a >> problem with one (or more) of them, it's not consistent. Our cacti >> graphs show no significant spikes in activity nor resource >> consumption on the backends or the load balancer around the time >> the first message about this was posted. >> >> Is the problem ongoing at this point? Persistent or inconsistent? >> Are there any commonalities for the people/sites where the errors >> are being observed? >> -- >> Jeremy Stanley >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Fri Sep 30 14:05:08 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 30 Sep 2022 14:05:08 +0000 Subject: [infra] TLS error when cloning https://opendev.org/openstack/devstack In-Reply-To: References: <20220930125142.elicofi3tnc34pd3@yuggoth.org> Message-ID: <20220930140508.kswc2k3srlbxv5pn@yuggoth.org> On 2022-09-30 14:59:21 +0100 (+0100), Neil Jerram wrote: [...] > That test actually passed. > > But then I kicked off two more, and the first of those failed with > > Cloning into '/opt/stack/neutron'... > error: RPC failed; curl 56 GnuTLS recv error (-9): A TLS packet with > unexpected length was received. > fatal: early EOF > fatal: fetch-pack: invalid index-pack output > > The second is still running, unusually slowly. It appears to be in the > middle of cloning Nova - possibly hung there. [...] I ran repeated devstack clones in a tight loop for roughly half an hour from my home network and never had a single failure. Is it possible all the people experiencing this issue may be coming from the same Internet provider or the same region of the World? -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From mkopec at redhat.com Fri Sep 30 14:28:45 2022 From: mkopec at redhat.com (Martin Kopec) Date: Fri, 30 Sep 2022 16:28:45 +0200 Subject: [neutron] PTG topics and scheduling In-Reply-To: References: Message-ID: Hi Rodolfo, in QA we have "Clean up deprecated lib/neutron code" [3] topic up for a discussion. Is that something you plan to discuss? Would you like to? We can either move that topic to the neutron's schedule or keep it in ours and you may just comment/or attend our session - depending on how much input from the neutron team is required there. [3] https://etherpad.opendev.org/p/qa-antelope-ptg Thank you, On Fri, 30 Sept 2022 at 12:06, Rodolfo Alonso Hernandez wrote: > Hello all: > > Based on the schedule polls results, I've booked the Neutron meetings from > Tuesday to Thursday in Mitaka channel [1], from 13UTC to 16UTC. Of course, > if that is not enough, we can always use Friday to continue any pending > conversation. > > The operator hour (actually 2), will be on Friday (pending for > reservation), from 13UTC to 15UTC. > > Please continue adding any topic you want to discuss in the Neutron > etherpad [2]. There is a specific section for the Nova-Neutron cross-team > meeting. > > If you have any doubt or question, do not hesitate to let me know (IRC: > ralonsoh, mail: ralonsoh at redhat.com). You can also ping any core reviewer > in #openstack-neutron channel. > > See you in a few weeks! > > [1]https://ptg.opendev.org/ptg.html > [2]https://etherpad.opendev.org/p/neutron-antelope-ptg > > -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA IM: kopecmartin -------------- next part -------------- An HTML attachment was scrubbed... URL: From longsube at gmail.com Fri Sep 30 10:30:12 2022 From: longsube at gmail.com (Quang Long) Date: Fri, 30 Sep 2022 17:30:12 +0700 Subject: Oracle Linux 6 VM disk performance Message-ID: Hi Openstack-users, I am having a problem with I/O performance on VM running Oracle Linux 6, I/O throughput on VM Oracle Linux 6 is much lower than VM using another OS (Ubuntu, CentOS). - VM Oracle Linux 6: throughput 40 MBps https://prnt.sc/buKscX_qEtcF - Other VM: throughput 113 MBps https://prnt.sc/IRhBUPrGgLOy - Test tool: dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync; rm -f test My Enviroment: - Openstack: Ussuri - Ceph: Octopus 15.2.8 - Compute: CentOS8_x86_64, kernel: 4.18.0-240.15.1.el8_3.x86_64 - KVM: qemu-kvm-5.2.0-16.el8.x86_64 - VM Oracle linux6: kernel-uek-4.1.12-124.42.3.el6uek.x86_64 I think because the kernel of Oracle Linux 6 is too old, maybe an older KVM version could support it, and now KVM does not optimize for this OS. Could you guy can help me with this? -- *L? Quang Long* 0942.533.683 | 0977.116.502 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean-francois.taltavull at elca.ch Fri Sep 30 07:09:39 2022 From: jean-francois.taltavull at elca.ch (=?utf-8?B?VGFsdGF2dWxsIEplYW4tRnJhbsOnb2lz?=) Date: Fri, 30 Sep 2022 07:09:39 +0000 Subject: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number In-Reply-To: References: <2aa77e24a33d48a69032f30b86e9cad8@elca.ch> <1b17c23f8982480db73cf50d04d51af7@elca.ch> <86f048d7931c4cc482f6785437c9b5ea@elca.ch> <671023b5ab3846dfb3a39ef313018eac@elca.ch> <33f69d386462450b9964b2ed78284d57@elca.ch> <1d1c1c3cc6184b529819bb8f3598813f@elca.ch> Message-ID: <3516ab2892694a17a76b56ccacc463f1@elca.ch> Do you mean the issue comes from how the `awsauth` module handles the signature ? From: Rafael Weing?rtner Sent: jeudi, 29 septembre 2022 17:23 To: Taltavull Jean-Fran?ois Cc: openstack-discuss Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. This is the signature used by the `awsauth` library: ``` def get_signature(self, r): canonical_string = self.get_canonical_string( r.url, r.headers, r.method) if py3k: key = self.secret_key.encode('utf-8') msg = canonical_string.encode('utf-8') else: key = self.secret_key msg = canonical_string h = hmac.new(key, msg, digestmod=sha) return encodestring(h.digest()).strip() ``` After that is generated, it is added in the headers: # Create date header if it is not created yet. if 'date' not in r.headers and 'x-amz-date' not in r.headers: r.headers['date'] = formatdate( timeval=None, localtime=False, usegmt=True) signature = self.get_signature(r) if py3k: signature = signature.decode('utf-8') r.headers['Authorization'] = 'AWS %s:%s' % (self.access_key, signature) On Thu, Sep 29, 2022 at 9:15 AM Taltavull Jean-Fran?ois > wrote: ``` $ python test_creds.py Executing test on: [FQDN/object-store/]. Rados GW admin context [/admin] and path [/usage?stats=True] used. Rados GW request URL [http://FQDN/object-store/admin/bucket?stats=True]. Rados GW host: FQDN Traceback (most recent call last): File "test_creds.py", line 45, in raise RGWAdminAPIFailed( __main__.RGWAdminAPIFailed: RGW AdminOps API returned 403 Forbidden ``` So the same as with ceilometer. Auth is done by RGW, not by keystone, and the ceph ?admin? user exists and owns the right privileges: ``` $ sudo radosgw-admin user info --uid admin [22/296]{ "user_id": "admin", "display_name": "admin user", "email": "", "suspended": 0, "max_buckets": 1000, "subusers": [], "keys": [ { "user": "admin", "access_key": ?admin_access_key", "secret_key": "admin_secret_key" } ], "swift_keys": [], "caps": [ { "type": "buckets", "perm": "*" }, { "type": "metadata", "perm": "*" }, { "type": "usage", "perm": "*" }, { "type": "users", "perm": "*" } ], ``` From: Rafael Weing?rtner > Sent: jeudi, 29 septembre 2022 12:32 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Can you test you credentials with the following code? ``` import json import requests import os import six.moves.urllib.parse as urlparse class RGWAdminAPIFailed(Exception): pass if __name__ == '__main__': rados_gw_base_url = "put your RGW URL here. E.g. http://server.com:port/something" print("Executing test on: [%s]." % rados_gw_base_url) rados_gw_admin_context = "/admin" rados_gw_path = "/usage?stats=True" print("Rados GW admin context [%s] and path [%s] used." % (rados_gw_admin_context, rados_gw_path)) rados_gw_request_url = urlparse.urljoin(rados_gw_base_url, '/admin') + '/bucket?stats=True' print("Rados GW request URL [%s]." % rados_gw_request_url) rados_gw_access_key_to_use = "put your access key here" rados_gw_secret_key_to_use = "put your secret key here" rados_gw_host_name = urlparse.urlparse(rados_gw_request_url).netloc print("Rados GW host: %s" % rados_gw_host_name) module_name = "awsauth" class_name = "S3Auth" arguments = [rados_gw_access_key_to_use, rados_gw_secret_key_to_use, rados_gw_host_name] module = __import__(module_name) class_ = getattr(module, class_name) instance = class_(*arguments) r = requests.get( rados_gw_request_url, auth=instance, timeout=30) #auth=awsauth.S3Auth(*arguments)) if r.status_code != 200: raise RGWAdminAPIFailed( ('RGW AdminOps API returned %(status)s %(reason)s') % {'status': r.status_code, 'reason': r.reason}) response_body = r.text parsed_json = json.loads(response_body) print("Response cookies: [%s]." % r.cookies) radosGw_output_file = "/home//Downloads/radosGw-usage.json" if os.path.exists(radosGw_output_file): os.remove(radosGw_output_file) with open(radosGw_output_file, "w") as file1: file1.writelines(json.dumps(parsed_json, indent=4, sort_keys=True)) file1.flush() exit(0) ``` On Thu, Sep 29, 2022 at 4:09 AM Taltavull Jean-Fran?ois > wrote: python Python 3.8.10 (default, Sep 28 2021, 16:10:42) [GCC 9.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import awsauth >>> awsauth >>> From: Rafael Weing?rtner > Sent: mercredi, 28 septembre 2022 18:40 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Can you also execute the following: ``` python import awsauth awsauth ``` That will output a path, and then you can `cat `, example: `cat /var/lib/kolla/venv/lib/python3.8/site-packages/awsauth.py` On Wed, Sep 28, 2022 at 1:21 PM Taltavull Jean-Fran?ois > wrote: I removed trailing ?/object-store/? from the last value of authentication_parameters I also: - disabled s3 keystone auth in RGW - created a RGW ?admin? user with the right privileges to allow admin API calls - put RGW in debug mode And here is what I get in RGW logs: get_usage string_to_sign=GET Wed, 28 Sep 2022 16:15:45 GMT /admin/usage get_usage server signature=BlaBlaBlaBla get_usage client signature=BloBloBlo get_usage compare=-75 get_usage rgw::auth::s3::LocalEngine denied with reason=-2027 get_usage rgw::auth::s3::AWSAuthStrategy denied with reason=-2027 get_usage rgw::auth::StrategyRegistry::s3_main_strategy_t: trying rgw::auth::s3::AWSAuthStrategy get_usage rgw::auth::s3::AWSAuthStrategy: trying rgw::auth::s3::LocalEngine From: Rafael Weing?rtner > Sent: mercredi, 28 septembre 2022 13:15 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. I think that the last parameter "/object-store/", should be only "". Can you test it? You are using EC2 credentials to authenticate in RGW. Did you enable the Keystone integration in RGW? Also, as far as I know, this admin endpoint needs a RGW admin. I am not sure if the Keystone and RGW integration would enable/make it possible for someone to authenticate as an admin in RGW. Can you check it? To see if you can call that endpoint with these credentials. On Wed, Sep 28, 2022 at 6:01 AM Taltavull Jean-Fran?ois > wrote: Pollster YML configuration : --- - name: "dynamic.radosgw.usage" sample_type: "gauge" unit: "B" value_attribute: "total.size" url_path: http:///object-store/admin/usage module: "awsauth" authentication_object: "S3Auth" authentication_parameters: ,,/object-store/ user_id_attribute: "user" project_id_attribute: "user" resource_id_attribute: "user" response_entries_key: "summary" ACCESS_KEY and SECRET_KEY have been created with ?openstack ec2 credentials create?. Ceilometer central is deployed with OSA and it uses awsauth.py module. From: Rafael Weing?rtner > Sent: mercredi, 28 septembre 2022 02:01 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Can you show your YML configuration? Also, did you install the AWS authentication module in the container/host where Ceilometer central is running? On Mon, Sep 26, 2022 at 12:58 PM Taltavull Jean-Fran?ois > wrote: Hello Rafael, Thanks for the information about ceilometer patches but for now I?m testing with the credentials in the dynamic pollster config file. I will use barbican when I push all this to production. The keystone authentication performed by the rados gw with the credentials provided by ceilometer still does not work. I wonder if this could be a S3 signature version issue on ceilometer side, that is on S3 client side. This kind of issue exists with the s3 client ?s3cmd? and you have to add ??signature-v2? so that ?s3cmd? works well. What do you think ? Do you know which version of S3 signature ceilometer uses while authenticating ? From: Rafael Weing?rtner > Sent: mercredi, 7 septembre 2022 19:23 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Jean, there are two problems with the Ceilometer. I just opened the patches to resolve it: - https://review.opendev.org/c/openstack/ceilometer/+/856305 - https://review.opendev.org/c/openstack/ceilometer/+/856304 Without these patches, you might have problems to use Ceilometer with Non-OpenStack dynamic pollsters and barbican credentials. On Wed, Aug 31, 2022 at 3:55 PM Rafael Weing?rtner > wrote: It is the RGW user that you have. This user must have the role that is needed to access the usage feature in RGW. If I am not mistaken, it required an admin user. On Wed, Aug 31, 2022 at 1:54 PM Taltavull Jean-Fran?ois > wrote: Thanks to your help, I am close to the goal. Dynamic pollster is loaded and triggered. But I get a ?Status[403] and reason [Forbidden]? in ceilometer logs while requesting admin/usage. I?m not sure to understand well the auth mechanism. Are we talking about keystone credentials, ec2 credentials, Rados GW user ?... For now, in testing phase, I use ?authentication_parameters?, not barbican. -JF From: Rafael Weing?rtner > Sent: mardi, 30 ao?t 2022 14:17 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Yes, you will need to enable the metric/pollster to be processed. That is done via "polling.yml" file. Also, do not forget that you will need to configure Ceilometer to push this new metric. If you use Gnocchi as the backend, you will need to change/update the gnocchi resource YML file. That file maps resources and metrics in the Gnocchi backend. The configuration resides in Ceilometer. You can create/define new resource types and map them to specific metrics. It depends on how you structure your solution. P.S. You do not need to use "authentication_parameters". You can use the barbican integration to avoid setting your credentials in a file. On Tue, Aug 30, 2022 at 9:11 AM Taltavull Jean-Fran?ois > wrote: Hello, I tried to define a Rados GW dynamic pollster and I can see, in Ceilometer logs, that it?s actually loaded. But it looks like it was not triggered, I see no trace of ceilometer connection in Rados GW logs. My definition: - name: "dynamic.radosgw.usage" sample_type: "gauge" unit: "B" value_attribute: "total.size" url_path: http:///object-store/swift/v1/admin/usage module: "awsauth" authentication_object: "S3Auth" authentication_parameters: xxxxxxxxxxxxx,yyyyyyyyyyyyy, user_id_attribute: "admin" project_id_attribute: "admin" resource_id_attribute: "admin" response_entries_key: "summary" Do I have to set an option in ceilometer.conf, or elsewhere, to get my Rados GW dynamic pollster triggered ? -JF From: Taltavull Jean-Fran?ois Sent: lundi, 29 ao?t 2022 18:41 To: 'Rafael Weing?rtner' > Cc: openstack-discuss > Subject: RE: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number Thanks a lot for your quick answer, Rafael ! I will explore this approach. Jean-Francois From: Rafael Weing?rtner > Sent: lundi, 29 ao?t 2022 17:54 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. You could use a different approach. You can use Dynamic pollster [1], and create your own mechanism to collect data, without needing to change Ceilometer code. Basically all hard-coded pollsters can be converted to a dynamic pollster that is defined in YML. [1] https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollster.html#the-dynamic-pollsters-system-configuration-for-non-openstack-apis On Mon, Aug 29, 2022 at 12:51 PM Taltavull Jean-Fran?ois > wrote: Hi All, In our OpenStack deployment, API endpoints are defined by using URLs instead of port numbers and HAProxy forwards requests to the right bakend after having ACLed the URL. In the case of our object-store service, based on RadosGW, the internal API endpoint is "https:///object-store/swift/v1/AUTH_" When Ceilometer RadosGW pollster tries to connect to the RadosGW admin API with the object-store internal endpoint, the URL becomes https:///admin, as shown by HAProxy logs. This URL does not match any API endpoint from HAProxy point of view. The line of code that rewrites the URL is this one: https://opendev.org/openstack/ceilometer/src/branch/stable/wallaby/ceilometer/objectstore/rgw.py#L81 What would you think of adding a mechanism based on new Ceilometer configuration option(s) to control the URL rewriting ? Our deployment characteristics: - OpenStack release: Wallaby - Ceph and RadosGW version: 15.2.16 - deployment tool: OSA 23.2.1 and ceph-ansible Best regards, Jean-Francois -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafaelweingartner at gmail.com Fri Sep 30 10:36:35 2022 From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=) Date: Fri, 30 Sep 2022 07:36:35 -0300 Subject: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number In-Reply-To: <3516ab2892694a17a76b56ccacc463f1@elca.ch> References: <2aa77e24a33d48a69032f30b86e9cad8@elca.ch> <1b17c23f8982480db73cf50d04d51af7@elca.ch> <86f048d7931c4cc482f6785437c9b5ea@elca.ch> <671023b5ab3846dfb3a39ef313018eac@elca.ch> <33f69d386462450b9964b2ed78284d57@elca.ch> <1d1c1c3cc6184b529819bb8f3598813f@elca.ch> <3516ab2892694a17a76b56ccacc463f1@elca.ch> Message-ID: No, I just showed you the code, so you can see how the authentication is being executed, and where/how the parameters are set in the headers. It is a bit odd, I have used this so many times, and it always works. What is your RGW instance version? On Fri, Sep 30, 2022 at 4:09 AM Taltavull Jean-Fran?ois < jean-francois.taltavull at elca.ch> wrote: > Do you mean the issue comes from how the `awsauth` module handles the > signature ? > > > > *From:* Rafael Weing?rtner > *Sent:* jeudi, 29 septembre 2022 17:23 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > This is the signature used by the `awsauth` library: > ``` > > def get_signature(self, r): > canonical_string = self.get_canonical_string( > r.url, r.headers, r.method) > if py3k: > key = self.secret_key.encode('utf-8') > msg = canonical_string.encode('utf-8') > else: > key = self.secret_key > msg = canonical_string > h = hmac.new(key, msg, digestmod=sha) > return encodestring(h.digest()).strip() > > > > ``` > > > > After that is generated, it is added in the headers: > > # Create date header if it is not created yet. > if 'date' not in r.headers and 'x-amz-date' not in r.headers: > r.headers['date'] = formatdate( > timeval=None, > localtime=False, > usegmt=True) > signature = self.get_signature(r) > if py3k: > signature = signature.decode('utf-8') > r.headers['Authorization'] = 'AWS %s:%s' % (self.access_key, signature) > > > > On Thu, Sep 29, 2022 at 9:15 AM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > ``` > > $ python test_creds.py > > Executing test on: [FQDN/object-store/]. > > Rados GW admin context [/admin] and path [/usage?stats=True] used. > > Rados GW request URL [http://FQDN/object-store/admin/bucket?stats=True]. > > Rados GW host: FQDN > > Traceback (most recent call last): > > File "test_creds.py", line 45, in > > raise RGWAdminAPIFailed( > > __main__.RGWAdminAPIFailed: RGW AdminOps API returned 403 Forbidden > > ``` > > > > So the same as with ceilometer. Auth is done by RGW, not by keystone, and > the ceph ?admin? user exists and owns the right privileges: > > ``` > > $ sudo radosgw-admin user info --uid > admin > [22/296]{ > > "user_id": "admin", > > "display_name": "admin user", > > "email": "", > > "suspended": 0, > > "max_buckets": 1000, > > "subusers": [], > > "keys": [ > > { > > "user": "admin", > > "access_key": ?admin_access_key", > > "secret_key": "admin_secret_key" > > } > > ], > > "swift_keys": [], > > "caps": [ > > { > > "type": "buckets", > > "perm": "*" > > }, > > { > > "type": "metadata", > > "perm": "*" > > }, > > > { > "type": > "usage", > "perm": > "*" > }, > { > > "type": "users", > "perm": > "*" > } > ], > > > > > ``` > > > > > > *From:* Rafael Weing?rtner > *Sent:* jeudi, 29 septembre 2022 12:32 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Can you test you credentials with the following code? > > ``` > > import json > import requests > import os > > import six.moves.urllib.parse as urlparse > > > class RGWAdminAPIFailed(Exception): > pass > > > if __name__ == '__main__': > > rados_gw_base_url = "put your RGW URL here. E.g. > http://server.com:port/something" > print("Executing test on: [%s]." % rados_gw_base_url) > > rados_gw_admin_context = "/admin" > > rados_gw_path = "/usage?stats=True" > > print("Rados GW admin context [%s] and path [%s] used." % > (rados_gw_admin_context, rados_gw_path)) > > rados_gw_request_url = urlparse.urljoin(rados_gw_base_url, '/admin') + > '/bucket?stats=True' > print("Rados GW request URL [%s]." % rados_gw_request_url) > > rados_gw_access_key_to_use = "put your access key here" > rados_gw_secret_key_to_use = "put your secret key here" > > rados_gw_host_name = urlparse.urlparse(rados_gw_request_url).netloc > print("Rados GW host: %s" % rados_gw_host_name) > module_name = "awsauth" > class_name = "S3Auth" > arguments = [rados_gw_access_key_to_use, rados_gw_secret_key_to_use, > rados_gw_host_name] > module = __import__(module_name) > class_ = getattr(module, class_name) > instance = class_(*arguments) > > r = requests.get( > rados_gw_request_url, > auth=instance, timeout=30) > #auth=awsauth.S3Auth(*arguments)) > > > if r.status_code != 200: > raise RGWAdminAPIFailed( > ('RGW AdminOps API returned %(status)s %(reason)s') % > {'status': r.status_code, 'reason': r.reason}) > > response_body = r.text > parsed_json = json.loads(response_body) > > print("Response cookies: [%s]." % r.cookies) > > radosGw_output_file = "/home//Downloads/radosGw-usage.json" > > if os.path.exists(radosGw_output_file): > os.remove(radosGw_output_file) > > with open(radosGw_output_file, "w") as file1: > file1.writelines(json.dumps(parsed_json, indent=4, sort_keys=True)) > file1.flush() > > exit(0) > > ``` > > > > On Thu, Sep 29, 2022 at 4:09 AM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > python > > Python 3.8.10 (default, Sep 28 2021, 16:10:42) > > [GCC 9.3.0] on linux > > Type "help", "copyright", "credits" or "license" for more information. > > >>> import awsauth > > >>> awsauth > > '/openstack/venvs/ceilometer-23.2.0/lib/python3.8/site-packages/awsauth.py'> > > >>> > > > > *From:* Rafael Weing?rtner > *Sent:* mercredi, 28 septembre 2022 18:40 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Can you also execute the following: > > ``` > > python > > > > import awsauth > > > > awsauth > > ``` > > That will output a path, and then you can `cat `, example: `cat > /var/lib/kolla/venv/lib/python3.8/site-packages/awsauth.py` > > > > On Wed, Sep 28, 2022 at 1:21 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > I removed trailing ?/object-store/? from the last value of > authentication_parameters > > > > I also: > > - disabled s3 keystone auth in RGW > > - created a RGW ?admin? user with the right privileges to allow admin API > calls > > - put RGW in debug mode > > > > And here is what I get in RGW logs: > > > > get_usage > string_to_sign=GET > Wed, > 28 Sep 2022 16:15:45 > GMT > /admin/usage > > get_usage server signature=BlaBlaBlaBla > > get_usage client signature=BloBloBlo > > get_usage compare=-75 > > get_usage rgw::auth::s3::LocalEngine denied with reason=-2027 > > get_usage rgw::auth::s3::AWSAuthStrategy denied with reason=-2027 > > get_usage rgw::auth::StrategyRegistry::s3_main_strategy_t: trying > rgw::auth::s3::AWSAuthStrategy > > get_usage rgw::auth::s3::AWSAuthStrategy: trying rgw::auth::s3::LocalEngine > > > > *From:* Rafael Weing?rtner > *Sent:* mercredi, 28 septembre 2022 13:15 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > I think that the last parameter "/object-store/", should be only " > ". Can you test it? > > > > > > You are using EC2 credentials to authenticate in RGW. Did you enable the > Keystone integration in RGW? > > Also, as far as I know, this admin endpoint needs a RGW admin. I am not > sure if the Keystone and RGW integration would enable/make it possible for > someone to authenticate as an admin in RGW. Can you check it? To see if you > can call that endpoint with these credentials. > > > > On Wed, Sep 28, 2022 at 6:01 AM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Pollster YML configuration : > > > > --- > > - name: "dynamic.radosgw.usage" > > sample_type: "gauge" > > unit: "B" > > value_attribute: "total.size" > > url_path: http:///object-store/admin/usage > > module: "awsauth" > > authentication_object: "S3Auth" > > authentication_parameters: ,,/object-store/ > > user_id_attribute: "user" > > project_id_attribute: "user" > > resource_id_attribute: "user" > > response_entries_key: "summary" > > > > ACCESS_KEY and SECRET_KEY have been created with ?openstack ec2 > credentials create?. > > > > Ceilometer central is deployed with OSA and it uses awsauth.py module. > > > > > > *From:* Rafael Weing?rtner > *Sent:* mercredi, 28 septembre 2022 02:01 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Can you show your YML configuration? Also, did you install the AWS > authentication module in the container/host where Ceilometer central is > running? > > > > On Mon, Sep 26, 2022 at 12:58 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Hello Rafael, > > > > Thanks for the information about ceilometer patches but for now I?m > testing with the credentials in the dynamic pollster config file. I will > use barbican when I push all this to production. > > > > The keystone authentication performed by the rados gw with the credentials > provided by ceilometer still does not work. I wonder if this could be a S3 > signature version issue on ceilometer side, that is on S3 client side. This > kind of issue exists with the s3 client ?s3cmd? and you have to add > ??signature-v2? so that ?s3cmd? works well. > > > > What do you think ? Do you know which version of S3 signature ceilometer > uses while authenticating ? > > > > *From:* Rafael Weing?rtner > *Sent:* mercredi, 7 septembre 2022 19:23 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Jean, there are two problems with the Ceilometer. I just opened the > patches to resolve it: > - https://review.opendev.org/c/openstack/ceilometer/+/856305 > > - https://review.opendev.org/c/openstack/ceilometer/+/856304 > > > > Without these patches, you might have problems to use Ceilometer with > Non-OpenStack dynamic pollsters and barbican credentials. > > > > On Wed, Aug 31, 2022 at 3:55 PM Rafael Weing?rtner < > rafaelweingartner at gmail.com> wrote: > > It is the RGW user that you have. This user must have the role that is > needed to access the usage feature in RGW. If I am not mistaken, it > required an admin user. > > > > On Wed, Aug 31, 2022 at 1:54 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Thanks to your help, I am close to the goal. Dynamic pollster is loaded > and triggered. > > > > But I get a ?Status[403] and reason [Forbidden]? in ceilometer logs while > requesting admin/usage. > > > > I?m not sure to understand well the auth mechanism. Are we talking about > keystone credentials, ec2 credentials, Rados GW user ?... > > > > For now, in testing phase, I use ?authentication_parameters?, not barbican. > > > > -JF > > > > *From:* Rafael Weing?rtner > *Sent:* mardi, 30 ao?t 2022 14:17 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > Yes, you will need to enable the metric/pollster to be processed. That is > done via "polling.yml" file. Also, do not forget that you will need to > configure Ceilometer to push this new metric. If you use Gnocchi as the > backend, you will need to change/update the gnocchi resource YML file. That > file maps resources and metrics in the Gnocchi backend. The configuration > resides in Ceilometer. You can create/define new resource types and map > them to specific metrics. It depends on how you structure your solution. > > P.S. You do not need to use "authentication_parameters". You can use the > barbican integration to avoid setting your credentials in a file. > > > > On Tue, Aug 30, 2022 at 9:11 AM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Hello, > > > > I tried to define a Rados GW dynamic pollster and I can see, in Ceilometer > logs, that it?s actually loaded. But it looks like it was not triggered, I > see no trace of ceilometer connection in Rados GW logs. > > > > My definition: > > > > - name: "dynamic.radosgw.usage" > > sample_type: "gauge" > > unit: "B" > > value_attribute: "total.size" > > url_path: http:///object-store/swift/v1/admin/usage > > module: "awsauth" > > authentication_object: "S3Auth" > > authentication_parameters: xxxxxxxxxxxxx,yyyyyyyyyyyyy, > > user_id_attribute: "admin" > > project_id_attribute: "admin" > > resource_id_attribute: "admin" > > response_entries_key: "summary" > > > > Do I have to set an option in ceilometer.conf, or elsewhere, to get my > Rados GW dynamic pollster triggered ? > > > > -JF > > > > *From:* Taltavull Jean-Fran?ois > *Sent:* lundi, 29 ao?t 2022 18:41 > *To:* 'Rafael Weing?rtner' > *Cc:* openstack-discuss > *Subject:* RE: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > Thanks a lot for your quick answer, Rafael ! > > I will explore this approach. > > > > Jean-Francois > > > > *From:* Rafael Weing?rtner > *Sent:* lundi, 29 ao?t 2022 17:54 > *To:* Taltavull Jean-Fran?ois > *Cc:* openstack-discuss > *Subject:* Re: [Ceilometer] Pollster cannot get RadosGW metrics when API > endpoints are based on URL instead of port number > > > > > > *EXTERNAL MESSAGE *- This email comes from *outside ELCA companies*. > > You could use a different approach. You can use Dynamic pollster [1], and > create your own mechanism to collect data, without needing to change > Ceilometer code. Basically all hard-coded pollsters can be converted to a > dynamic pollster that is defined in YML. > > > > [1] > https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollster.html#the-dynamic-pollsters-system-configuration-for-non-openstack-apis > > > > > > On Mon, Aug 29, 2022 at 12:51 PM Taltavull Jean-Fran?ois < > jean-francois.taltavull at elca.ch> wrote: > > Hi All, > > In our OpenStack deployment, API endpoints are defined by using URLs > instead of port numbers and HAProxy forwards requests to the right bakend > after having ACLed the URL. > > In the case of our object-store service, based on RadosGW, the internal > API endpoint is "https:///object-store/swift/v1/AUTH_" > > When Ceilometer RadosGW pollster tries to connect to the RadosGW admin API > with the object-store internal endpoint, the URL becomes > https:///admin, as shown by HAProxy logs. This URL does not match > any API endpoint from HAProxy point of view. The line of code that rewrites > the URL is this one: > https://opendev.org/openstack/ceilometer/src/branch/stable/wallaby/ceilometer/objectstore/rgw.py#L81 > > What would you think of adding a mechanism based on new Ceilometer > configuration option(s) to control the URL rewriting ? > > Our deployment characteristics: > - OpenStack release: Wallaby > - Ceph and RadosGW version: 15.2.16 > - deployment tool: OSA 23.2.1 and ceph-ansible > > > Best regards, > Jean-Francois > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > > > > -- > > Rafael Weing?rtner > -- Rafael Weing?rtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean-francois.taltavull at elca.ch Fri Sep 30 12:47:51 2022 From: jean-francois.taltavull at elca.ch (=?utf-8?B?VGFsdGF2dWxsIEplYW4tRnJhbsOnb2lz?=) Date: Fri, 30 Sep 2022 12:47:51 +0000 Subject: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number In-Reply-To: References: <2aa77e24a33d48a69032f30b86e9cad8@elca.ch> <1b17c23f8982480db73cf50d04d51af7@elca.ch> <86f048d7931c4cc482f6785437c9b5ea@elca.ch> <671023b5ab3846dfb3a39ef313018eac@elca.ch> <33f69d386462450b9964b2ed78284d57@elca.ch> <1d1c1c3cc6184b529819bb8f3598813f@elca.ch> <3516ab2892694a17a76b56ccacc463f1@elca.ch> Message-ID: ``` $ sudo /usr/bin/radosgw --version ceph version 15.2.16 (d46a73d6d0a67a79558054a3a5a72cb561724974) octopus (stable) ``` From: Rafael Weing?rtner Sent: vendredi, 30 septembre 2022 12:37 To: Taltavull Jean-Fran?ois Cc: openstack-discuss Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. No, I just showed you the code, so you can see how the authentication is being executed, and where/how the parameters are set in the headers. It is a bit odd, I have used this so many times, and it always works. What is your RGW instance version? On Fri, Sep 30, 2022 at 4:09 AM Taltavull Jean-Fran?ois > wrote: Do you mean the issue comes from how the `awsauth` module handles the signature ? From: Rafael Weing?rtner > Sent: jeudi, 29 septembre 2022 17:23 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. This is the signature used by the `awsauth` library: ``` def get_signature(self, r): canonical_string = self.get_canonical_string( r.url, r.headers, r.method) if py3k: key = self.secret_key.encode('utf-8') msg = canonical_string.encode('utf-8') else: key = self.secret_key msg = canonical_string h = hmac.new(key, msg, digestmod=sha) return encodestring(h.digest()).strip() ``` After that is generated, it is added in the headers: # Create date header if it is not created yet. if 'date' not in r.headers and 'x-amz-date' not in r.headers: r.headers['date'] = formatdate( timeval=None, localtime=False, usegmt=True) signature = self.get_signature(r) if py3k: signature = signature.decode('utf-8') r.headers['Authorization'] = 'AWS %s:%s' % (self.access_key, signature) On Thu, Sep 29, 2022 at 9:15 AM Taltavull Jean-Fran?ois > wrote: ``` $ python test_creds.py Executing test on: [FQDN/object-store/]. Rados GW admin context [/admin] and path [/usage?stats=True] used. Rados GW request URL [http://FQDN/object-store/admin/bucket?stats=True]. Rados GW host: FQDN Traceback (most recent call last): File "test_creds.py", line 45, in raise RGWAdminAPIFailed( __main__.RGWAdminAPIFailed: RGW AdminOps API returned 403 Forbidden ``` So the same as with ceilometer. Auth is done by RGW, not by keystone, and the ceph ?admin? user exists and owns the right privileges: ``` $ sudo radosgw-admin user info --uid admin [22/296]{ "user_id": "admin", "display_name": "admin user", "email": "", "suspended": 0, "max_buckets": 1000, "subusers": [], "keys": [ { "user": "admin", "access_key": ?admin_access_key", "secret_key": "admin_secret_key" } ], "swift_keys": [], "caps": [ { "type": "buckets", "perm": "*" }, { "type": "metadata", "perm": "*" }, { "type": "usage", "perm": "*" }, { "type": "users", "perm": "*" } ], ``` From: Rafael Weing?rtner > Sent: jeudi, 29 septembre 2022 12:32 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Can you test you credentials with the following code? ``` import json import requests import os import six.moves.urllib.parse as urlparse class RGWAdminAPIFailed(Exception): pass if __name__ == '__main__': rados_gw_base_url = "put your RGW URL here. E.g. http://server.com:port/something" print("Executing test on: [%s]." % rados_gw_base_url) rados_gw_admin_context = "/admin" rados_gw_path = "/usage?stats=True" print("Rados GW admin context [%s] and path [%s] used." % (rados_gw_admin_context, rados_gw_path)) rados_gw_request_url = urlparse.urljoin(rados_gw_base_url, '/admin') + '/bucket?stats=True' print("Rados GW request URL [%s]." % rados_gw_request_url) rados_gw_access_key_to_use = "put your access key here" rados_gw_secret_key_to_use = "put your secret key here" rados_gw_host_name = urlparse.urlparse(rados_gw_request_url).netloc print("Rados GW host: %s" % rados_gw_host_name) module_name = "awsauth" class_name = "S3Auth" arguments = [rados_gw_access_key_to_use, rados_gw_secret_key_to_use, rados_gw_host_name] module = __import__(module_name) class_ = getattr(module, class_name) instance = class_(*arguments) r = requests.get( rados_gw_request_url, auth=instance, timeout=30) #auth=awsauth.S3Auth(*arguments)) if r.status_code != 200: raise RGWAdminAPIFailed( ('RGW AdminOps API returned %(status)s %(reason)s') % {'status': r.status_code, 'reason': r.reason}) response_body = r.text parsed_json = json.loads(response_body) print("Response cookies: [%s]." % r.cookies) radosGw_output_file = "/home//Downloads/radosGw-usage.json" if os.path.exists(radosGw_output_file): os.remove(radosGw_output_file) with open(radosGw_output_file, "w") as file1: file1.writelines(json.dumps(parsed_json, indent=4, sort_keys=True)) file1.flush() exit(0) ``` On Thu, Sep 29, 2022 at 4:09 AM Taltavull Jean-Fran?ois > wrote: python Python 3.8.10 (default, Sep 28 2021, 16:10:42) [GCC 9.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import awsauth >>> awsauth >>> From: Rafael Weing?rtner > Sent: mercredi, 28 septembre 2022 18:40 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Can you also execute the following: ``` python import awsauth awsauth ``` That will output a path, and then you can `cat `, example: `cat /var/lib/kolla/venv/lib/python3.8/site-packages/awsauth.py` On Wed, Sep 28, 2022 at 1:21 PM Taltavull Jean-Fran?ois > wrote: I removed trailing ?/object-store/? from the last value of authentication_parameters I also: - disabled s3 keystone auth in RGW - created a RGW ?admin? user with the right privileges to allow admin API calls - put RGW in debug mode And here is what I get in RGW logs: get_usage string_to_sign=GET Wed, 28 Sep 2022 16:15:45 GMT /admin/usage get_usage server signature=BlaBlaBlaBla get_usage client signature=BloBloBlo get_usage compare=-75 get_usage rgw::auth::s3::LocalEngine denied with reason=-2027 get_usage rgw::auth::s3::AWSAuthStrategy denied with reason=-2027 get_usage rgw::auth::StrategyRegistry::s3_main_strategy_t: trying rgw::auth::s3::AWSAuthStrategy get_usage rgw::auth::s3::AWSAuthStrategy: trying rgw::auth::s3::LocalEngine From: Rafael Weing?rtner > Sent: mercredi, 28 septembre 2022 13:15 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. I think that the last parameter "/object-store/", should be only "". Can you test it? You are using EC2 credentials to authenticate in RGW. Did you enable the Keystone integration in RGW? Also, as far as I know, this admin endpoint needs a RGW admin. I am not sure if the Keystone and RGW integration would enable/make it possible for someone to authenticate as an admin in RGW. Can you check it? To see if you can call that endpoint with these credentials. On Wed, Sep 28, 2022 at 6:01 AM Taltavull Jean-Fran?ois > wrote: Pollster YML configuration : --- - name: "dynamic.radosgw.usage" sample_type: "gauge" unit: "B" value_attribute: "total.size" url_path: http:///object-store/admin/usage module: "awsauth" authentication_object: "S3Auth" authentication_parameters: ,,/object-store/ user_id_attribute: "user" project_id_attribute: "user" resource_id_attribute: "user" response_entries_key: "summary" ACCESS_KEY and SECRET_KEY have been created with ?openstack ec2 credentials create?. Ceilometer central is deployed with OSA and it uses awsauth.py module. From: Rafael Weing?rtner > Sent: mercredi, 28 septembre 2022 02:01 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Can you show your YML configuration? Also, did you install the AWS authentication module in the container/host where Ceilometer central is running? On Mon, Sep 26, 2022 at 12:58 PM Taltavull Jean-Fran?ois > wrote: Hello Rafael, Thanks for the information about ceilometer patches but for now I?m testing with the credentials in the dynamic pollster config file. I will use barbican when I push all this to production. The keystone authentication performed by the rados gw with the credentials provided by ceilometer still does not work. I wonder if this could be a S3 signature version issue on ceilometer side, that is on S3 client side. This kind of issue exists with the s3 client ?s3cmd? and you have to add ??signature-v2? so that ?s3cmd? works well. What do you think ? Do you know which version of S3 signature ceilometer uses while authenticating ? From: Rafael Weing?rtner > Sent: mercredi, 7 septembre 2022 19:23 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Jean, there are two problems with the Ceilometer. I just opened the patches to resolve it: - https://review.opendev.org/c/openstack/ceilometer/+/856305 - https://review.opendev.org/c/openstack/ceilometer/+/856304 Without these patches, you might have problems to use Ceilometer with Non-OpenStack dynamic pollsters and barbican credentials. On Wed, Aug 31, 2022 at 3:55 PM Rafael Weing?rtner > wrote: It is the RGW user that you have. This user must have the role that is needed to access the usage feature in RGW. If I am not mistaken, it required an admin user. On Wed, Aug 31, 2022 at 1:54 PM Taltavull Jean-Fran?ois > wrote: Thanks to your help, I am close to the goal. Dynamic pollster is loaded and triggered. But I get a ?Status[403] and reason [Forbidden]? in ceilometer logs while requesting admin/usage. I?m not sure to understand well the auth mechanism. Are we talking about keystone credentials, ec2 credentials, Rados GW user ?... For now, in testing phase, I use ?authentication_parameters?, not barbican. -JF From: Rafael Weing?rtner > Sent: mardi, 30 ao?t 2022 14:17 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. Yes, you will need to enable the metric/pollster to be processed. That is done via "polling.yml" file. Also, do not forget that you will need to configure Ceilometer to push this new metric. If you use Gnocchi as the backend, you will need to change/update the gnocchi resource YML file. That file maps resources and metrics in the Gnocchi backend. The configuration resides in Ceilometer. You can create/define new resource types and map them to specific metrics. It depends on how you structure your solution. P.S. You do not need to use "authentication_parameters". You can use the barbican integration to avoid setting your credentials in a file. On Tue, Aug 30, 2022 at 9:11 AM Taltavull Jean-Fran?ois > wrote: Hello, I tried to define a Rados GW dynamic pollster and I can see, in Ceilometer logs, that it?s actually loaded. But it looks like it was not triggered, I see no trace of ceilometer connection in Rados GW logs. My definition: - name: "dynamic.radosgw.usage" sample_type: "gauge" unit: "B" value_attribute: "total.size" url_path: http:///object-store/swift/v1/admin/usage module: "awsauth" authentication_object: "S3Auth" authentication_parameters: xxxxxxxxxxxxx,yyyyyyyyyyyyy, user_id_attribute: "admin" project_id_attribute: "admin" resource_id_attribute: "admin" response_entries_key: "summary" Do I have to set an option in ceilometer.conf, or elsewhere, to get my Rados GW dynamic pollster triggered ? -JF From: Taltavull Jean-Fran?ois Sent: lundi, 29 ao?t 2022 18:41 To: 'Rafael Weing?rtner' > Cc: openstack-discuss > Subject: RE: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number Thanks a lot for your quick answer, Rafael ! I will explore this approach. Jean-Francois From: Rafael Weing?rtner > Sent: lundi, 29 ao?t 2022 17:54 To: Taltavull Jean-Fran?ois > Cc: openstack-discuss > Subject: Re: [Ceilometer] Pollster cannot get RadosGW metrics when API endpoints are based on URL instead of port number EXTERNAL MESSAGE - This email comes from outside ELCA companies. You could use a different approach. You can use Dynamic pollster [1], and create your own mechanism to collect data, without needing to change Ceilometer code. Basically all hard-coded pollsters can be converted to a dynamic pollster that is defined in YML. [1] https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollster.html#the-dynamic-pollsters-system-configuration-for-non-openstack-apis On Mon, Aug 29, 2022 at 12:51 PM Taltavull Jean-Fran?ois > wrote: Hi All, In our OpenStack deployment, API endpoints are defined by using URLs instead of port numbers and HAProxy forwards requests to the right bakend after having ACLed the URL. In the case of our object-store service, based on RadosGW, the internal API endpoint is "https:///object-store/swift/v1/AUTH_" When Ceilometer RadosGW pollster tries to connect to the RadosGW admin API with the object-store internal endpoint, the URL becomes https:///admin, as shown by HAProxy logs. This URL does not match any API endpoint from HAProxy point of view. The line of code that rewrites the URL is this one: https://opendev.org/openstack/ceilometer/src/branch/stable/wallaby/ceilometer/objectstore/rgw.py#L81 What would you think of adding a mechanism based on new Ceilometer configuration option(s) to control the URL rewriting ? Our deployment characteristics: - OpenStack release: Wallaby - Ceph and RadosGW version: 15.2.16 - deployment tool: OSA 23.2.1 and ceph-ansible Best regards, Jean-Francois -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -- Rafael Weing?rtner -------------- next part -------------- An HTML attachment was scrubbed... URL: From longsube at gmail.com Fri Sep 30 14:45:41 2022 From: longsube at gmail.com (Quang Long) Date: Fri, 30 Sep 2022 21:45:41 +0700 Subject: Oracle Linux 6 VM volume performance Message-ID: Hi Openstack-users, I am having a problem with I/O performance on VM running Oracle Linux 6, I/O throughput on VM Oracle Linux 6 is much lower than VM using another OS (Ubuntu, CentOS). - VM Oracle Linux 6: throughput 40 MBps https://prnt.sc/buKscX_qEtcF - Other VM: throughput 113 MBps https://prnt.sc/IRhBUPrGgLOy - Test tool: dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync; rm -f test My Enviroment: - Openstack: Ussuri - Ceph: Octopus 15.2.8 - Compute: CentOS8_x86_64, kernel: 4.18.0-240.15.1.el8_3.x86_64 - KVM: qemu-kvm-5.2.0-16.el8.x86_64 - VM Oracle linux6: kernel-uek-4.1.12-124.42.3.el6uek.x86_64 I think because the kernel of Oracle Linux 6 is too old, maybe an older KVM version could support it, and now KVM does not optimize for this OS. Could you guy can help me with this? -- *L? Quang Long* 0942.533.683 | 0977.116.502 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkopec at redhat.com Fri Sep 30 14:48:06 2022 From: mkopec at redhat.com (Martin Kopec) Date: Fri, 30 Sep 2022 16:48:06 +0200 Subject: [qa][ptg] Virtual PTG Planning In-Reply-To: References: Message-ID: So far we have the following 4 topics: * Retrospective * S-RBAC * Clean up deprecated lib/neutron code * Decide which job variant should become the new tempest default Feel free to add any other topic, you would like to discuss, to our ptg etherpad [1]. We haven't booked any time slots yet, before that, I wanted to make sure that we have all topics gathered so that we can plan enough time to cover them all. We'll book the slots next week, so hurry up :) See you soon, On Thu, 22 Sept 2022 at 00:46, Martin Kopec wrote: > Hello everyone, > > here is [1] our etherpad for Antelope PTG. Please, add your topics there > if there is anything you would like to discuss / propose ... > You can also vote for time slots of our sessions so that they fit your > schedule at [2]. > We will go with 3 maybe 4 one hour slots, depending on the number of > topics. > > [1] https://etherpad.opendev.org/p/qa-antelope-ptg > [2] https://framadate.org/dC2AEBTq8b5rAkvv > > Thanks, > -- > Martin Kopec > Senior Software Quality Engineer > Red Hat EMEA > IM: kopecmartin > > > > -- Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From neil at tigera.io Fri Sep 30 14:53:22 2022 From: neil at tigera.io (Neil Jerram) Date: Fri, 30 Sep 2022 15:53:22 +0100 Subject: [infra] TLS error when cloning https://opendev.org/openstack/devstack In-Reply-To: <20220930140508.kswc2k3srlbxv5pn@yuggoth.org> References: <20220930125142.elicofi3tnc34pd3@yuggoth.org> <20220930140508.kswc2k3srlbxv5pn@yuggoth.org> Message-ID: On Fri, Sep 30, 2022 at 3:05 PM Jeremy Stanley wrote: > On 2022-09-30 14:59:21 +0100 (+0100), Neil Jerram wrote: > [...] > > That test actually passed. > > > > But then I kicked off two more, and the first of those failed with > > > > Cloning into '/opt/stack/neutron'... > > error: RPC failed; curl 56 GnuTLS recv error (-9): A TLS packet with > > unexpected length was received. > > fatal: early EOF > > fatal: fetch-pack: invalid index-pack output > > > > The second is still running, unusually slowly. It appears to be in the > > middle of cloning Nova - possibly hung there. > [...] > > I ran repeated devstack clones in a tight loop for roughly half an > hour from my home network and never had a single failure. Is it > possible all the people experiencing this issue may be coming from > the same Internet provider or the same region of the World? > For me it would be coming from wherever Semaphore's machines are. But I also tried from my own laptop, based in Cambridge UK, and that failed as in my report that started this thread. My ISP is Shell Energy. I just tried again from my laptop, and now the clone has succeeded. -- > Jeremy Stanley > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Fri Sep 30 15:07:55 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 30 Sep 2022 15:07:55 +0000 Subject: [infra] TLS error when cloning https://opendev.org/openstack/devstack In-Reply-To: References: <20220930125142.elicofi3tnc34pd3@yuggoth.org> <20220930140508.kswc2k3srlbxv5pn@yuggoth.org> Message-ID: <20220930150754.7s3t3l3exhvpct6v@yuggoth.org> On 2022-09-30 15:53:22 +0100 (+0100), Neil Jerram wrote: [...] > For me it would be coming from wherever Semaphore's machines are. But I > also tried from my own laptop, based in Cambridge UK, and that failed as in > my report that started this thread. My ISP is Shell Energy. > > I just tried again from my laptop, and now the clone has succeeded. Our server farm for Git is generously hosted within VEXXHOST's San Jose USA public cloud region, so it's possible something is causing disconnects reaching it from some parts of the 'net and not others. I'm connecting to it from Charter Cable in the USA, who peers with Zayo (formerly AboveNet) in Atlanta, and then VEXXHOST peers with them in San Jose. Not exactly next door, but I'm only traversing one backbone provider to get there (and with access to the server I've confirmed the return route is mostly symmetrical though comes back through a Zayo/Charter peering in Washington DC). To rule out IP protocol differences, I've done repeated git clone tests over both IPv4 and IPv6 too, with no observable issues. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From neil at tigera.io Fri Sep 30 15:15:36 2022 From: neil at tigera.io (Neil Jerram) Date: Fri, 30 Sep 2022 16:15:36 +0100 Subject: [infra] TLS error when cloning https://opendev.org/openstack/devstack In-Reply-To: <20220930150754.7s3t3l3exhvpct6v@yuggoth.org> References: <20220930125142.elicofi3tnc34pd3@yuggoth.org> <20220930140508.kswc2k3srlbxv5pn@yuggoth.org> <20220930150754.7s3t3l3exhvpct6v@yuggoth.org> Message-ID: On Fri, Sep 30, 2022 at 4:09 PM Jeremy Stanley wrote: > On 2022-09-30 15:53:22 +0100 (+0100), Neil Jerram wrote: > [...] > > For me it would be coming from wherever Semaphore's machines are. But I > > also tried from my own laptop, based in Cambridge UK, and that failed as > in > > my report that started this thread. My ISP is Shell Energy. > > > > I just tried again from my laptop, and now the clone has succeeded. > > Our server farm for Git is generously hosted within VEXXHOST's > San Jose USA public cloud region, so it's possible something is > causing disconnects reaching it from some parts of the 'net and not > others. I'm connecting to it from Charter Cable in the USA, who > peers with Zayo (formerly AboveNet) in Atlanta, and then VEXXHOST > peers with them in San Jose. Not exactly next door, but I'm only > traversing one backbone provider to get there (and with access to > the server I've confirmed the return route is mostly symmetrical > though comes back through a Zayo/Charter peering in Washington DC). > > To rule out IP protocol differences, I've done repeated git clone > tests over both IPv4 and IPv6 too, with no observable issues. > Thanks for thinking about and investigating this, Jeremy. Apparently my team's Semaphore servers are based in Germany, so there could be a transatlantic factor here. Perhaps we just need to wait now for any further reports. Best wishes, Neil > -- > Jeremy Stanley > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.vanommen at gmail.com Fri Sep 30 15:20:42 2022 From: john.vanommen at gmail.com (John van Ommen) Date: Fri, 30 Sep 2022 08:20:42 -0700 Subject: Oracle Linux 6 VM volume performance In-Reply-To: References: Message-ID: Why not update to a newer release? Such as Oracle Linux 8? On Fri, Sep 30, 2022 at 7:50 AM Quang Long wrote: > Hi Openstack-users, > > I am having a problem with I/O performance on VM running Oracle Linux 6, > I/O throughput on VM Oracle Linux 6 is much lower than VM using another OS > (Ubuntu, CentOS). > > - VM Oracle Linux 6: throughput 40 MBps > https://prnt.sc/buKscX_qEtcF > > - Other VM: throughput 113 MBps > https://prnt.sc/IRhBUPrGgLOy > > - Test tool: > dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync; rm -f test > > > My Enviroment: > - Openstack: Ussuri > - Ceph: Octopus 15.2.8 > - Compute: CentOS8_x86_64, kernel: 4.18.0-240.15.1.el8_3.x86_64 > - KVM: qemu-kvm-5.2.0-16.el8.x86_64 > - VM Oracle linux6: kernel-uek-4.1.12-124.42.3.el6uek.x86_64 > > I think because the kernel of Oracle Linux 6 is too old, maybe an older > KVM version could support it, and now KVM does not optimize for this OS. > > Could you guy can help me with this? > > -- > > *L? Quang Long* > > 0942.533.683 | 0977.116.502 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From artem.goncharov at gmail.com Fri Sep 30 15:25:33 2022 From: artem.goncharov at gmail.com (Artem Goncharov) Date: Fri, 30 Sep 2022 17:25:33 +0200 Subject: [infra] TLS error when cloning https://opendev.org/openstack/devstack In-Reply-To: <20220930150754.7s3t3l3exhvpct6v@yuggoth.org> References: <20220930125142.elicofi3tnc34pd3@yuggoth.org> <20220930140508.kswc2k3srlbxv5pn@yuggoth.org> <20220930150754.7s3t3l3exhvpct6v@yuggoth.org> Message-ID: <742185CE-14E1-4BEE-BCF9-52436142218B@gmail.com> My trace route shows that once my traffic enters Zayo network it becomes terribly unstable and most rechecks are even showing different routes on their side. Apparently EU-US connection is going now this way and is therefore affected. > On 30. Sep 2022, at 17:07, Jeremy Stanley wrote: > > On 2022-09-30 15:53:22 +0100 (+0100), Neil Jerram wrote: > [...] >> For me it would be coming from wherever Semaphore's machines are. But I >> also tried from my own laptop, based in Cambridge UK, and that failed as in >> my report that started this thread. My ISP is Shell Energy. >> >> I just tried again from my laptop, and now the clone has succeeded. > > Our server farm for Git is generously hosted within VEXXHOST's > San Jose USA public cloud region, so it's possible something is > causing disconnects reaching it from some parts of the 'net and not > others. I'm connecting to it from Charter Cable in the USA, who > peers with Zayo (formerly AboveNet) in Atlanta, and then VEXXHOST > peers with them in San Jose. Not exactly next door, but I'm only > traversing one backbone provider to get there (and with access to > the server I've confirmed the return route is mostly symmetrical > though comes back through a Zayo/Charter peering in Washington DC). > > To rule out IP protocol differences, I've done repeated git clone > tests over both IPv4 and IPv6 too, with no observable issues. > -- > Jeremy Stanley From longsube at gmail.com Fri Sep 30 15:25:33 2022 From: longsube at gmail.com (Quang Long) Date: Fri, 30 Sep 2022 22:25:33 +0700 Subject: Oracle Linux 6 VM volume performance In-Reply-To: References: Message-ID: My clients need Oracle Linux 6 to maintain their applications. On Fri, Sep 30, 2022 at 10:20 PM John van Ommen wrote: > Why not update to a newer release? Such as Oracle Linux 8? > > On Fri, Sep 30, 2022 at 7:50 AM Quang Long wrote: > >> Hi Openstack-users, >> >> I am having a problem with I/O performance on VM running Oracle Linux 6, >> I/O throughput on VM Oracle Linux 6 is much lower than VM using another OS >> (Ubuntu, CentOS). >> >> - VM Oracle Linux 6: throughput 40 MBps >> https://prnt.sc/buKscX_qEtcF >> >> - Other VM: throughput 113 MBps >> https://prnt.sc/IRhBUPrGgLOy >> >> - Test tool: >> dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync; rm -f test >> >> >> My Enviroment: >> - Openstack: Ussuri >> - Ceph: Octopus 15.2.8 >> - Compute: CentOS8_x86_64, kernel: 4.18.0-240.15.1.el8_3.x86_64 >> - KVM: qemu-kvm-5.2.0-16.el8.x86_64 >> - VM Oracle linux6: kernel-uek-4.1.12-124.42.3.el6uek.x86_64 >> >> I think because the kernel of Oracle Linux 6 is too old, maybe an older >> KVM version could support it, and now KVM does not optimize for this OS. >> >> Could you guy can help me with this? >> >> -- >> >> *L? Quang Long* >> >> 0942.533.683 | 0977.116.502 >> > -- *L? Quang Long* 0942.533.683 | 0977.116.502 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Fri Sep 30 15:32:52 2022 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 30 Sep 2022 15:32:52 +0000 Subject: [infra] TLS error when cloning https://opendev.org/openstack/devstack In-Reply-To: References: <20220930125142.elicofi3tnc34pd3@yuggoth.org> <20220930140508.kswc2k3srlbxv5pn@yuggoth.org> <20220930150754.7s3t3l3exhvpct6v@yuggoth.org> Message-ID: <20220930153251.bndn26jh4zc4zmod@yuggoth.org> On 2022-09-30 16:15:36 +0100 (+0100), Neil Jerram wrote: [...] > Thanks for thinking about and investigating this, Jeremy. Apparently my > team's Semaphore servers are based in Germany, so there could be a > transatlantic factor here. Perhaps we just need to wait now for any > further reports. That mostly confirms what we're finding on the load balancer. Haproxy records numerous prematurely disconnected sessions involving a small number of clients, many of which are from an IP address in Germany, and also some others from Europe. -- Jeremy Stanley -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From elod.illes at est.tech Fri Sep 30 15:35:03 2022 From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=) Date: Fri, 30 Sep 2022 17:35:03 +0200 Subject: [release] Release countdown for week R+0, Oct 3 - 7 Message-ID: <874cd430-2dfe-1664-f8d1-7d5df920c49b@est.tech> Development Focus ----------------- We will be releasing the coordinated OpenStack Zed release next week, on October 5th, 2022. Thanks to everyone involved in the Zed cycle! We are now in pre-release freeze, so no new deliverable will be created until final release, unless a release-critical regression is spotted. Otherwise, teams attending the virtual PTG should start to plan what they will be discussing there, by creating and filling team etherpads. You can access the list of PTG etherpads at: http://ptg.openstack.org/etherpads.html General Information ------------------- On release day, the release team will produce final versions of deliverables following the cycle-with-rc release model, by re-tagging the commit used for the last RC. A patch doing just that will be proposed. PTLs and release liaisons should watch for that final release patch from the release team. While not required, we would appreciate having an ack from each team before we approve it on the 5th, so that their approval is included in the metadata that goes onto the signed tag. Upcoming Deadlines & Dates -------------------------- Final Zed release: October 5th, 2022 Virtual PTG: October 17-21, 2022 El?d Ill?s irc: elodilles From dtantsur at redhat.com Fri Sep 30 15:35:02 2022 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Fri, 30 Sep 2022 17:35:02 +0200 Subject: [infra] TLS error when cloning https://opendev.org/openstack/devstack In-Reply-To: <742185CE-14E1-4BEE-BCF9-52436142218B@gmail.com> References: <20220930125142.elicofi3tnc34pd3@yuggoth.org> <20220930140508.kswc2k3srlbxv5pn@yuggoth.org> <20220930150754.7s3t3l3exhvpct6v@yuggoth.org> <742185CE-14E1-4BEE-BCF9-52436142218B@gmail.com> Message-ID: I also see the traffic entering Zayo to cross the ocean, but I've been so far unable to get a failure after cloning devstack in a loop. On Fri, Sep 30, 2022 at 5:31 PM Artem Goncharov wrote: > My trace route shows that once my traffic enters Zayo network it becomes > terribly unstable and most rechecks are even showing different routes on > their side. Apparently EU-US connection is going now this way and is > therefore affected. > > > On 30. Sep 2022, at 17:07, Jeremy Stanley wrote: > > > > On 2022-09-30 15:53:22 +0100 (+0100), Neil Jerram wrote: > > [...] > >> For me it would be coming from wherever Semaphore's machines are. But I > >> also tried from my own laptop, based in Cambridge UK, and that failed > as in > >> my report that started this thread. My ISP is Shell Energy. > >> > >> I just tried again from my laptop, and now the clone has succeeded. > > > > Our server farm for Git is generously hosted within VEXXHOST's > > San Jose USA public cloud region, so it's possible something is > > causing disconnects reaching it from some parts of the 'net and not > > others. I'm connecting to it from Charter Cable in the USA, who > > peers with Zayo (formerly AboveNet) in Atlanta, and then VEXXHOST > > peers with them in San Jose. Not exactly next door, but I'm only > > traversing one backbone provider to get there (and with access to > > the server I've confirmed the return route is mostly symmetrical > > though comes back through a Zayo/Charter peering in Washington DC). > > > > To rule out IP protocol differences, I've done repeated git clone > > tests over both IPv4 and IPv6 too, with no observable issues. > > -- > > Jeremy Stanley > > > -- Red Hat GmbH , Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross -------------- next part -------------- An HTML attachment was scrubbed... URL: From katonalala at gmail.com Fri Sep 30 15:37:36 2022 From: katonalala at gmail.com (Lajos Katona) Date: Fri, 30 Sep 2022 17:37:36 +0200 Subject: [neutron] PTG topics and scheduling In-Reply-To: References: Message-ID: Hi We have this topic I think on the Neutron etherpad: https://etherpad.opendev.org/p/neutron-antelope-ptg#L74 So this can be a common topic which we can discuss for sure. Lajos Martin Kopec ezt ?rta (id?pont: 2022. szept. 30., P, 16:41): > Hi Rodolfo, > > in QA we have "Clean up deprecated lib/neutron code" [3] topic up for a > discussion. > Is that something you plan to discuss? Would you like to? We can either > move that topic to the neutron's schedule or keep it in ours and you may > just comment/or attend our session - depending on how much input from the > neutron team is required there. > > [3] https://etherpad.opendev.org/p/qa-antelope-ptg > > Thank you, > > On Fri, 30 Sept 2022 at 12:06, Rodolfo Alonso Hernandez < > ralonsoh at redhat.com> wrote: > >> Hello all: >> >> Based on the schedule polls results, I've booked the Neutron meetings >> from Tuesday to Thursday in Mitaka channel [1], from 13UTC to 16UTC. Of >> course, if that is not enough, we can always use Friday to continue any >> pending conversation. >> >> The operator hour (actually 2), will be on Friday (pending for >> reservation), from 13UTC to 15UTC. >> >> Please continue adding any topic you want to discuss in the Neutron >> etherpad [2]. There is a specific section for the Nova-Neutron cross-team >> meeting. >> >> If you have any doubt or question, do not hesitate to let me know (IRC: >> ralonsoh, mail: ralonsoh at redhat.com). You can also ping any core >> reviewer in #openstack-neutron channel. >> >> See you in a few weeks! >> >> [1]https://ptg.opendev.org/ptg.html >> [2]https://etherpad.opendev.org/p/neutron-antelope-ptg >> >> > > -- > Martin Kopec > Senior Software Quality Engineer > Red Hat EMEA > IM: kopecmartin > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ihtisham.ul_Haq at mail.schwarz Fri Sep 30 16:20:23 2022 From: Ihtisham.ul_Haq at mail.schwarz (Ihtisham ul Haq) Date: Fri, 30 Sep 2022 16:20:23 +0000 Subject: [ovn][neutron] RE: OVN BGP Agent query In-Reply-To: References: Message-ID: Hi Luis and Daniel, Please see inline response. > From: Daniel Alvarez Sanchez > Sent: 29 September 2022 11:37 > Subject: Re: OVN BGP Agent query > > Hi Ihtisham and Luis, > > On Thu, Sep 29, 2022 at 7:42 AM Luis Tomas Bolivar wrote: > > Some comments and questions inline > > > > On Tue, Sep 27, 2022 at 1:39 PM Ihtisham ul haq wrote: > > > Hi Luis, > > > > > > Thanks for your work on the OVN BGP Agent. We are planning > > > to use it in our OVN deployment, but have a question regarding it. > > > > Great to hear! Can you share a bit more info about this environment? like > > openstack version, target workload, etc. We plan to use this with Yoga version. Our workload consist of enterprise users with VMs running on Openstack and connected to their enterprise network via transfer network(to which the customer neutron router is attached to). And we also have public workload but with the ovn-bgp we only want to we want to advertise the former. > > > > > The way our current setup with ML2/OVS works is that our customer VM IP routes > > > are announced via the router IP(of the that customer) to the leaf switch instead of > > > the IP of the host where the neutron BGP agent runs. And then even if the > > > router fails over, the IP of the router stays the same and thus the BGP route > > > doesn't need to be updated. > > > > Is this with Neutron Dynamic Routing? When you say Router IP, do you mean the virtual neutron router and its IP associated with the provider network? What type of IPs are you announcing with BGP? IPs on provider network or on tenant networks (or both)? Yes, that's with Neutron DR agent, and I meant virtual neutron router with IP from the provider network. We announce IPs of our tenant network via the virtual routers external address. > > If the router fails over, the route needs to be updated, doesn't it? Same IP, but exposed in the new location of the router? Correct. > The route to the tenant network doesn't change, ie. > 192.168.0.0 via 172.24.4.100 (this route remains the same regardless of where 172.24.4.100 is). > If there's L2 in the 172.24.4.0 network, the new location of 172.24.4.100 will be learnt via GARP announcement. In our case, this won't happen as we don't have L2 so we expose directly connected routes to overcome this "limitation". Right, in our case we have a stretched L2 transfer network(mentioned above) to which our gateway nodes and customer routers are connected to, so we can advertise the IPs from the tenant network via the virtual router external IP and thus the location of the router isn't relevant in case of failover as its address will be relearned. > In the case of Neutron Dynamic Routing, there's no assumption that everything is L3 so GARPs are needed to learn the new location. > > > > We see that the routes are announced by the ovn-bgp-agent via the host IP(GTW) in our > > > switch peers. If that's the case then how do you make sure that during failover > > > of a router, the BGP routes gets updated with the new host IP(where the router > > > failed over to)? > > > > The local FRR running at each node is in charge of exposing the IPs. For the IPs on the provider network, the traffic is directly exposed where the VMs are, without having to go through the virtual router, so a router failover won't change the route. > > In the case of VMs on tenant networks, the traffic is exposed on the node where the virtual router gateway port is associated (I suppose this is what you refer to with router IP). In the case of a failover the agent is in charge of making FRR to withdraw the exposed routes on the old node, and re-advertise them on the new router IP location > > > > > Can we accomplish the same route advertisement as our ML2/OVS setup, using the ovn-bgp-agent? > > I think this is technically possible, and perhaps you want to contribute that functionality or even help integrating the agent as a driver of Neutron Dynamic Routing? Sounds good, our plan currently is to add this to the ovn-bgp-agent, so we can announce our tenant routes via virtual routers external address on a stretched L2 network, to make it work with our use case. -- Ihtisham ul Haq Diese E Mail enth?lt m?glicherweise vertrauliche Inhalte und ist nur f?r die Verwertung durch den vorgesehenen Empf?nger bestimmt. Sollten Sie nicht der vorgesehene Empf?nger sein, setzen Sie den Absender bitte unverz?glich in Kenntnis und l?schen diese E Mail. Hinweise zum Datenschutz finden Sie hier. From amy at demarco.com Fri Sep 30 17:09:16 2022 From: amy at demarco.com (Amy Marrich) Date: Fri, 30 Sep 2022 12:09:16 -0500 Subject: [Diversity] Diversity and Inclusion WG meeting reminder Message-ID: The D&I WG will be meeting Monday at 15:00 UTC. ? The meeting will be held on video at https://meetpad.opendev.org/osf-diversity-and-inclusion and the agenda can be found at https://etherpad.openstack.org/p/diversity -wg-agenda. Thanks, Amy (spotz) -------------- next part -------------- An HTML attachment was scrubbed... URL: From zaitcev at redhat.com Fri Sep 30 21:39:46 2022 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 30 Sep 2022 16:39:46 -0500 Subject: How do I disable replication in swift In-Reply-To: <527985954.3334066.1663961171011@mail.yahoo.com> References: <1112921123.2169438.1663847346908.ref@mail.yahoo.com> <1112921123.2169438.1663847346908@mail.yahoo.com> <1295063360.641866.1663941856275@mail.yahoo.com> <527985954.3334066.1663961171011@mail.yahoo.com> Message-ID: <20220930163304.6b1dffd7@niphredil.zaitcev.lan> On Fri, 23 Sep 2022 19:26:11 +0000 (UTC) Paladox wrote: > Ah so if i stoped the object replicator service, that'll be fine? Because replicator deletes tombstones, you'll run out of inodes eventually. So you probably want to run one per node, even if you don't replicate and have replication factor of 1 in your rings. -- Pete From zaitcev at redhat.com Fri Sep 30 21:41:21 2022 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 30 Sep 2022 16:41:21 -0500 Subject: How do I disable replication in swift In-Reply-To: <2052306468.3384214.1663968003125@mail.yahoo.com> References: <1112921123.2169438.1663847346908.ref@mail.yahoo.com> <1112921123.2169438.1663847346908@mail.yahoo.com> <1295063360.641866.1663941856275@mail.yahoo.com> <527985954.3334066.1663961171011@mail.yahoo.com> <2052306468.3384214.1663968003125@mail.yahoo.com> Message-ID: <20220930164121.7caa41cb@niphredil.zaitcev.lan> On Fri, 23 Sep 2022 21:20:03 +0000 (UTC) Paladox wrote: > We have around 3.8tb but we're wanting to move from gluster to swift (which we're currently using?2.6tb). We're a small not-for-profit in the UK. We don't have the funds to support replicating data right now. You are setting yourself for a data loss and then you'll inevitably blame Swift, even though we told you not to do that. -- Pete From zaitcev at redhat.com Fri Sep 30 21:52:17 2022 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 30 Sep 2022 16:52:17 -0500 Subject: [Swift][Ussuri] Erasure Coding Quarantines In-Reply-To: References: Message-ID: <20220930165217.2901f9cf@niphredil.zaitcev.lan> On Tue, 27 Sep 2022 13:35:47 +0000 Reid Guyett wrote: > The 20.04 server has log messages indicating that it is unable to get enough responses from the reconstructor. > > The 18.04 servers have a couple EC messages. > "...liberasurecode[30807]: Invalid fragment header information!" followed by "...object-server: Quarantined object /srv/node/d9/objects-4/10321/b2e/50a3dce515aafc6f222824ec5c7dfb2e/1664002866.33100#8#d.data: Invalid EC metadata at offset 0x0 Ouch, tbat is unfortunate. Unfortunately, I'm not familiar with the exact details of this. There was a window where depending on how linker worked, our code could get linked with an incorrect zlib crc routine randomly. I'll try to raise someone on IRC about this. -- Pete From gmann at ghanshyammann.com Fri Sep 30 22:35:01 2022 From: gmann at ghanshyammann.com (Ghanshyam Mann) Date: Fri, 30 Sep 2022 15:35:01 -0700 Subject: [all][tc] What's happening in Technical Committee: summary 2022 Sept 30: Reading: 5 min Message-ID: <1839089eb53.ec1b15ad865364.5215444219612446089@ghanshyammann.com> Hello Everyone, Here is this week's summary of the Technical Committee activities. 1. TC Meetings: ============ * We had this week's meeting on Sept 29. Most of the meeting discussions are summarized in this email. Meeting logs are available @ https://meetings.opendev.org/meetings/tc/2022/tc.2022-09-29-15.00.log.html * Next TC weekly meeting will be a video call on Oct 6 Thursday at 15:00 UTC, feel free to add the topic on the agenda[1] by Oct 5. 2. What we completed this week: ========================= * Goal proposal of 'Migrating CI/CD testing from Ubuntu 20.04 to 22.04' is merged [2] * 2023.1 cycle leaderless projects: PTL appointment done for below projects: ** Adjutant[3] ** Keystone[4] ** Masakari[5] ** OpenStack_Charms[6] ** Sahara[7 ** Senlin[8] ** Swift[9] ** Venus[10] 3. Activities In progress: ================== TC Tracker for Zed cycle ------------------------------ * Zed tracker etherpad includes the TC working items[11], Five are completed and other items are in-progress. Open Reviews ----------------- * Five open reviews for ongoing activities[12]. Dedicating Zed release to Ilya Etingof -------------------------------------------- As you might know, there is sad news of Ilya Etingof (Ironic contributor) passed away on Aug 10[13] and we will be dedicating the Zed release to Ilya[14] New community-wide goal "Migration CI/CD to Ubuntu 22.04" -------------------------------------------------------------------------------------- The goal proposal is merged[15]. Dmitriy will propose this goal to be selected for 2023.1 cycle. 2023.1 cycle Leaderless projects & TC Chair ---------------------------------------------------- * PTL appointments for 8 projects are done. Zun project PTL appointment is under review[16]. * TC Chair: TC members are in the progress to select the chair for the next term. 2023.1 cycle TC PTG planning ------------------------------------ * JayF sent the ICS invite of TC PTG slots on ML[17] * Etherpads to add the topics: ** https://etherpad.opendev.org/p/tc-2023-1-ptg ** https://etherpad.opendev.org/p/tc-leaders-interaction-2023-1 * I sent an email about the 'Operator Hours' slots in this PTG, please check and reserve the operator hour slot for your project[18] 2021 User Survey TC Question Analysis ----------------------------------------------- No update on this. The survey summary is up for review[19]. Feel free to check and provide feedback. Fixing Zuul config error ---------------------------- We discussed the Zuul config error for zuul 'queue' syntex[20]. Also added it in the zuul config error etherpad[21 ]. Requesting projects have zuul config errors in their jobs to look into those and fix them asap. As most of the errors occur while project renaming/retiring, I am adding a separate step about it in the project rename/retiring process[22]. Project updates ------------------- * None. 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[23]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [24] 3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://review.opendev.org/c/openstack/governance/+/858690 [3] https://review.opendev.org/c/openstack/governance/+/858967 [4] https://review.opendev.org/c/openstack/governance/+/858969 [5] https://review.opendev.org/c/openstack/governance/+/858974 [6] https://review.opendev.org/c/openstack/governance/+/858973 [7] https://review.opendev.org/c/openstack/governance/+/858975 [8] https://review.opendev.org/c/openstack/governance/+/858976 [9] https://review.opendev.org/c/openstack/governance/+/858978 [10] https://review.opendev.org/c/openstack/governance/+/858979 [11] https://etherpad.opendev.org/p/tc-zed-tracker [12] https://review.opendev.org/q/projects:openstack/governance+status:open [13] https://lists.openstack.org/pipermail/openstack-discuss/2022-August/030062.html [14] https://review.opendev.org/c/openstack/governance/+/859464 [15] https://review.opendev.org/c/openstack/governance/+/858690 [16] https://review.opendev.org/c/openstack/governance/+/858980 [17] https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030649.html [18] https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030301.html [19] https://review.opendev.org/c/openstack/governance/+/836888 [20] https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030505.html [21] https://etherpad.opendev.org/p/zuul-config-error-openstack [22] https://review.opendev.org/c/openstack/project-team-guide/+/859886 [23] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [24] http://eavesdrop.openstack.org/#Technical_Committee_Meeting -gmann