From gmann at ghanshyammann.com  Tue Mar  1 00:22:51 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 28 Feb 2022 18:22:51 -0600
Subject: [all][tc] Technical Committee next weekly meeting on Mar 3rd
 (not 4th) at 1500 UTC
In-Reply-To: <17f413dc13b.1112c1076280164.9078145143439661308@ghanshyammann.com>
References: <17f413dc13b.1112c1076280164.9078145143439661308@ghanshyammann.com>
Message-ID: <17f42dbbe35.e38a85b0295421.3903320940743592043@ghanshyammann.com>

Sorry I mentioned Mar 4th as the next meeting but it is on Mar 3rd Thursday 15:00 UTC

-gmann

 ---- On Mon, 28 Feb 2022 10:50:40 -0600 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > Hello Everyone,
 > 
 > Technical Committee's next weekly meeting is scheduled for Mar 4th at 1500 UTC.
 > 
 > If you would like to add topics for discussion, please add them to the below wiki page by
 > Wednesday, Mar 3rd, at 2100 UTC.
 > 
 > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting
 > 
 > -gmann
 > 
 > 


From johnsomor at gmail.com  Tue Mar  1 00:38:53 2022
From: johnsomor at gmail.com (Michael Johnson)
Date: Mon, 28 Feb 2022 16:38:53 -0800
Subject: [Neutron][Octavia][ovn-octavia-provider] proposing Luis Tomas
 Bolivar for ovn-octavia-provider core reviewer
In-Reply-To: <96c49d33-fc30-2380-fe82-8247fffc264f@gmail.com>
References: <CALg0jKmGBwSPowJRmcwukit1P26NvGeei8ay2VyDaM2BS2wUTg@mail.gmail.com>
 <96c49d33-fc30-2380-fe82-8247fffc264f@gmail.com>
Message-ID: <CAMH0MgLftyb6MtaAMxNipoPZLujoz6W+30=U2fu802eby+mLZw@mail.gmail.com>

+1 from me

Michael

On Mon, Feb 28, 2022 at 2:19 PM Brian Haley <haleyb.dev at gmail.com> wrote:
>
> +1 from me, Luis has been great at finding and fixing issues in this
> repo for a while.
>
> -Brian
>
> On 2/28/22 09:38, Lajos Katona wrote:
> > Hi
> >
> > I would like to propose Luis Tomas Bolivar (ltomasbo) as a core reviewer
> > to the ovn-octavia-provider project.
> > Luis is very active in the project (see [1] and [2]) and has experience
> > with Kuryr side also which uses ovn-octavia-provider.
> >
> > As ovn-octavia-provider is a link between Neutron and Octavia I ask both
> > Neutron and Octavia cores to vote by answering to this thread, to have a
> > final decision.
> > Thanks for your consideration
> >
> > [1]:
> > https://review.opendev.org/q/owner:ltomasbo%2540redhat.com+branch:master
> > <https://review.opendev.org/q/owner:ltomasbo%2540redhat.com+branch:master>
> > [2]:
> > https://www.stackalytics.io/report/contribution?module=neutron-group&project_type=openstack&days=60
> > <https://www.stackalytics.io/report/contribution?module=neutron-group&project_type=openstack&days=60>
> >
> > Cheers
> > Lajos
>


From laurentfdumont at gmail.com  Tue Mar  1 01:54:32 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Mon, 28 Feb 2022 20:54:32 -0500
Subject: Fluentd error with Kolla ansible deployment
In-Reply-To: <CAOAKi8zi5N+4ZDigjqHNf9DhK83AQHhcMseV1Hh7qFDJBa2a7Q@mail.gmail.com>
References: <CAEc0zitLtnXrA-5-QJq3rTVJZGAnDhWYgBg7mCGdV0_+fryaTw@mail.gmail.com>
 <CAOAKi8zi5N+4ZDigjqHNf9DhK83AQHhcMseV1Hh7qFDJBa2a7Q@mail.gmail.com>
Message-ID: <CAOAKi8yyoqV87W_-bBjS+sAk3Y1aC-5LOJoWDCYvw41fbseFWA@mail.gmail.com>

Not super familiar with the kolla docker part, but the code seems pretty
straightforward.

What is the IP of your registry? I dont think you should use localhost as
the tasks are running on the computes/controllers? Can you use the registry
IP in the same subnet/reachable subnet?

Tracing the code


- name: Ensure fluentd image is present for label check
  vars:
    service_name: "fluentd"
    service: "{{ common_services[service_name] }}"
  become: true
  kolla_docker:
    action: "ensure_image"
    common_options: "{{ docker_common_options }}"
    image: "{{ service.image }}"
  when:
    - fluentd_version is not defined or fluentd_binary is not defined
    - enable_fluentd | bool


This calls

    def ensure_image(self):
        if not self.check_image():
            self.pull_image()

This then calls (if the image is not there)

    def pull_image(self):
        if self.params.get('auth_username'):
            self.dc.login(
                username=self.params.get('auth_username'),
                password=self.params.get('auth_password'),
                registry=self.params.get('auth_registry'),
                email=self.params.get('auth_email')
            )

        image, tag = self.parse_image()
        old_image_id = self.get_image_id()

        statuses = [
            json.loads(line.strip().decode('utf-8')) for line in
self.dc.pull(
                repository=image, tag=tag, stream=True
            )
        ]

        for status in reversed(statuses):
            if 'error' in status:
                if status['error'].endswith('not found'):
                    self.module.fail_json(
                        msg="The requested image does not exist:
{}:{}".format(
                            image, tag),
                        failed=True
                    )
                else:
                    self.module.fail_json(
                        msg="Unknown error message: {}".format(
                            status['error']),
                        failed=True
                    )

        new_image_id = self.get_image_id()
        self.changed = old_image_id != new_image_id


On Mon, Feb 28, 2022 at 6:26 PM Laurent Dumont <laurentfdumont at gmail.com>
wrote:

> Can you pull from that registry manually? If that doesn't work, Kolla
> won't work either.
>
> On Mon, Feb 28, 2022 at 6:47 AM A Monster <amonster369 at gmail.com> wrote:
>
>> I'm getting the following error while trying to deploy openstack using
>> kolla-ansible.
>> I've set up a local docker registry and enabled insecure registries in
>> daemon.json file and I even tried to pull fluentd docker image but I still
>> get the following error
>>
>> TASK [common : Ensure fluentd image is present for label check]
>> fatal: [localhost]: 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/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: 500 Server Error: Internal
>> Server Error for url:
>> http+docker://localhost/v1.41/images/create?tag=xena&fromImage=quay.io%2Fkolla%2Fcentos-source-fluentd\\n\\nDuring
>> handling of the above exception, another exception occurred:\\n\\nTraceback
>> (most recent call last):\\n  File
>> \"/tmp/ansible_kolla_docker_payload_xizndx9s/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\",
>> line 1241, in main\\n  File
>> \"/tmp/ansible_kolla_docker_payload_xizndx9s/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\",
>> line 1116, in ensure_image\\n  File
>> \"/tmp/ansible_kolla_docker_payload_xizndx9s/ansible_kolla_docker_payload.zip/ansible/modules/kolla_docker.py\",
>> line 692, in pull_image\\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.APIError: 500
>> Server Error for
>> http+docker://localhost/v1.41/images/create?tag=xena&fromImage=quay.io%2Fkolla%2Fcentos-source-fluentd:
>> Internal Server Error (\"unauthorized: access to the requested resource is
>> not authorized\")\\n'"}
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220228/eabe3e1c/attachment-0001.htm>

From tkajinam at redhat.com  Tue Mar  1 02:11:56 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Tue, 1 Mar 2022 11:11:56 +0900
Subject: [puppet] Gate blocker: CentOS 9 integration jobs are broken
Message-ID: <CAL_crJSq8sfwqybc9CC_iQ6sqHFSQNaFnE6uReNfyofch=icKg@mail.gmail.com>

Hi,

Please be aware that currently CentOS 9 integration jobs are broken
because of the two problems caused by recent updates in c9s repos.
 https://bugs.launchpad.net/puppet-openstack-integration/+bug/1962506
 https://bugs.launchpad.net/puppet-openstack-integration/+bug/1962507

I'm currently working on implementing workaround[1], but in case it would
take
some time, I'll make c9s integration jobs non-voting again to unblock our
gate.
[1]
https://review.opendev.org/c/openstack/puppet-openstack-integration/+/831197

Please avoid approving changes which require integration jobs.

Thank you,
Takashi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220301/91926035/attachment.htm>

From gagehugo at gmail.com  Tue Mar  1 04:05:57 2022
From: gagehugo at gmail.com (Gage Hugo)
Date: Mon, 28 Feb 2022 22:05:57 -0600
Subject: [openstack-helm] No Meeting Tomorrow
Message-ID: <CAE4Awf8eB=ddnsvSw8-eUk9b6oQSoT5kRsKkxrQfuMA51rm+iA@mail.gmail.com>

Hey team,

Since there's nothing on the agenda for tomorrow's meeting, it has been
cancelled. We will meet again next week.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220228/7e1c1782/attachment.htm>

From johnsomor at gmail.com  Tue Mar  1 04:48:51 2022
From: johnsomor at gmail.com (Michael Johnson)
Date: Mon, 28 Feb 2022 20:48:51 -0800
Subject: [nova][octavia][masakari][designate][oslo][requirements]
 oslo.context>=4.0.0 seems to need updated tests
In-Reply-To: <CAL_crJRzdSjx7KgiRjgXF+CmpFJaC+PqQknXuDsHACHUTQozrA@mail.gmail.com>
References: <20220228165609.zzz7ur2mktfrqmue@mthode.org>
 <CAMH0Mg+_Hf+hBEbjiWQJAhjedU5c0podQYfEgJX4bWRVRjMxiw@mail.gmail.com>
 <c6c0a89a62ef8a7112177b05e69287699ab64393.camel@redhat.com>
 <60238d97d4f9d44413441ec75e0b893e47bb9f6f.camel@redhat.com>
 <CAL_crJRzdSjx7KgiRjgXF+CmpFJaC+PqQknXuDsHACHUTQozrA@mail.gmail.com>
Message-ID: <CAMH0MgJA_4Oy8F3QQhjooYt+qD34KkCJ0k=R65Fr=RkTRN=abw@mail.gmail.com>

Yep, thanks Takashi.

Patches for both Octavia and Designate have now merged. I fired off a
recheck to confirm.

Michael

On Mon, Feb 28, 2022 at 3:28 PM Takashi Kajinami <tkajinam at redhat.com> wrote:
>
> I hope the issue with Octavia was resolved by https://review.opendev.org/c/openstack/octavia/+/801860 .
> (Thank you Michael for merging this !)
>
> AFAIK Mistral is still dependent on the old arguments and we need
>  https://review.opendev.org/c/openstack/mistral/+/801853
> to fix it. It'd be nice if somebody from Mistral team can merge this
> (and the series of clean up patches)
>
> On Tue, Mar 1, 2022 at 3:47 AM Sean Mooney <smooney at redhat.com> wrote:
>>
>> On Mon, 2022-02-28 at 18:37 +0000, Sean Mooney wrote:
>> > On Mon, 2022-02-28 at 10:09 -0800, Michael Johnson wrote:
>> > > This is a legit API change in oslo.context (Thus the major version
>> > > bump). It's been a long time coming too.
>> > we are currently pass m3 in the rc period.
>> > i dont know if we can do a breaking change like this in yoga at this point depending on how invaise it is.
>> > we might need to hold this until after RC1 is out ideally this type of change would happen very erarly in the cycle before the ptg or m1
>> > not at the very end on the nova side there is only one failing unit test
>> > https://6b96a36d22f450141095-9e4eb9f05513870f0e5456f29474f6b2.ssl.cf5.rackcdn.com/829599/1/check/cross-nova-py38/60113ea/testr_results.html
>> > but i need to also run the func tests to see if there is other impact
>> > tempest-full-py3 passed so nova iteslf is likely fine.
>> >
>> > ill try running it locally and see if that is the only impact or not.
>>
>> gmann beat me too it.
>> https://review.opendev.org/c/openstack/nova/+/831244
>> so ya it is apprently just the one unit test so i dont think this should be an issue for nova
>>
>> >
>> > >
>> > > I will get started on the required code changes to Designate. Maybe
>> > > Octavia as well if someone else doesn't get to it before I do.
>> > >
>> > > Michael
>> > >
>> > > On Mon, Feb 28, 2022 at 9:04 AM Matthew Thode <mthode at mthode.org> wrote:
>> > > >
>> > > > The update to see what's breaking is here
>> > > > https://review.opendev.org/829599
>> > > >
>> > > > Feel free to make that patch depend on your fix to test (with rechecks)
>> > > >
>> > > > --
>> > > > Matthew Thode
>> > >
>> >
>>
>>


From lucasagomes at gmail.com  Tue Mar  1 08:48:40 2022
From: lucasagomes at gmail.com (Lucas Alvares Gomes)
Date: Tue, 1 Mar 2022 08:48:40 +0000
Subject: [Neutron][Octavia][ovn-octavia-provider] proposing Luis Tomas
 Bolivar for ovn-octavia-provider core reviewer
In-Reply-To: <CALg0jKmGBwSPowJRmcwukit1P26NvGeei8ay2VyDaM2BS2wUTg@mail.gmail.com>
References: <CALg0jKmGBwSPowJRmcwukit1P26NvGeei8ay2VyDaM2BS2wUTg@mail.gmail.com>
Message-ID: <CAB1EZBrAsQiLC__EmwuBp-EHOYQfummYh-EEgP8ihKDGoZzEwg@mail.gmail.com>

+1 from me!

On Mon, Feb 28, 2022 at 2:42 PM Lajos Katona <katonalala at gmail.com> wrote:
>
> Hi
>
> I would like to propose Luis Tomas Bolivar (ltomasbo) as a core reviewer to the ovn-octavia-provider project.
> Luis is very active in the project (see [1] and [2]) and has experience with Kuryr side also which uses ovn-octavia-provider.
>
> As ovn-octavia-provider is a link between Neutron and Octavia I ask both Neutron and Octavia cores to vote by answering to this thread, to have a final decision.
> Thanks for your consideration
>
> [1]: https://review.opendev.org/q/owner:ltomasbo%2540redhat.com+branch:master
> [2]: https://www.stackalytics.io/report/contribution?module=neutron-group&project_type=openstack&days=60
>
> Cheers
> Lajos


From skaplons at redhat.com  Tue Mar  1 09:53:33 2022
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Tue, 01 Mar 2022 10:53:33 +0100
Subject: [neutron] CI meeting - agenda for 1.03.2022
Message-ID: <2176895.iZASKD2KPV@p1>

Hi,

Agenda for today's Neutron CI meeting is at [1]. Please remember that we will 
meet on the video call today [2]. See You all there at 1500 UTC

[1] https://etherpad.opendev.org/p/neutron-ci-meetings
[2] https://meetpad.opendev.org/neutron-ci-meetings

-- 
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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220301/d0b46076/attachment.sig>

From tkajinam at redhat.com  Tue Mar  1 13:47:41 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Tue, 1 Mar 2022 22:47:41 +0900
Subject: [puppet] Gate blocker: CentOS 9 integration jobs are broken
In-Reply-To: <CAL_crJSq8sfwqybc9CC_iQ6sqHFSQNaFnE6uReNfyofch=icKg@mail.gmail.com>
References: <CAL_crJSq8sfwqybc9CC_iQ6sqHFSQNaFnE6uReNfyofch=icKg@mail.gmail.com>
Message-ID: <CAL_crJTJz+BjSsg+NyTAdhvC9HL_F2WR3-TtUs1nWGY30ZN3Tg@mail.gmail.com>

Unfortunately I've not yet managed to implement a workaround and it's likely
I need some more time to fix it, I'm merging the patch to make c9s jobs
non-voting.

https://review.opendev.org/c/openstack/puppet-openstack-integration/+/831183

I'll revert that change once we can implement workaround/solution.

On Tue, Mar 1, 2022 at 11:11 AM Takashi Kajinami <tkajinam at redhat.com>
wrote:

> Hi,
>
> Please be aware that currently CentOS 9 integration jobs are broken
> because of the two problems caused by recent updates in c9s repos.
>  https://bugs.launchpad.net/puppet-openstack-integration/+bug/1962506
>  https://bugs.launchpad.net/puppet-openstack-integration/+bug/1962507
>
> I'm currently working on implementing workaround[1], but in case it would
> take
> some time, I'll make c9s integration jobs non-voting again to unblock our
> gate.
> [1]
> https://review.opendev.org/c/openstack/puppet-openstack-integration/+/831197
>
> Please avoid approving changes which require integration jobs.
>
> Thank you,
> Takashi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220301/8a7a0618/attachment.htm>

From tkajinam at redhat.com  Tue Mar  1 13:58:40 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Tue, 1 Mar 2022 22:58:40 +0900
Subject: [puppet][tripleo][neutron][ops] Deprecating support for
 networking-bigswitch
Message-ID: <CAL_crJT_2ZHNds7Fp8HM_VMx=JKn1y01uF0c-JxCe6b8qkYbMA@mail.gmail.com>

Hi,


Today I noticed networking-bigswitch has been unmaintained recently.
The repos have not been updated for 2 years and no release has been made
since stable/train.
 https://opendev.org/x/networking-bigswitch

Based on the above observation, I assume no users would be using the plugin
with recent OpenStack releases and I've proposed deprecating support for
the plugin
in puppet-neutron.
 https://review.opendev.org/c/openstack/puppet-neutron/+/831376

In case if anyone has concern with this, please post your thoughts in the
above review.

Once this deprecation is approved/merged, I'll remove support for the
plugin from TripleO
because implementation in TripleO depends on puppet-neutron.

Thank you,
Takashi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220301/d1e48da6/attachment.htm>

From juliaashleykreger at gmail.com  Tue Mar  1 14:06:01 2022
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Tue, 1 Mar 2022 06:06:01 -0800
Subject: [Ironic] No suitable device was found for deployment
In-Reply-To: <3209d9fc-8db1-6dca-5736-402c6f082fcc@cern.ch>
References: <CAOirdiX4RuYYdzmDWBp0Ofua0B6BV0mGat0YWnwZZwebmMOeQQ@mail.gmail.com>
 <fbcd7e11-e4b4-6022-0b5e-df42b1d9b998@cern.ch>
 <CAOirdiV8s80SYcbtZ8G4-VCMs9OGvfeVy=CF-d8V0Fw0N9xO0g@mail.gmail.com>
 <04af20bb-143b-9b56-6787-d5ac6ab0d38c@cern.ch>
 <CAF7gwdgkJiXShCM0z1ZyERj0=Z63713Xy6JXctwazNobqvxqVw@mail.gmail.com>
 <CAOirdiUPkXOVZDg8DgrOMDeK8xJxPGcbsu4Y+XPVCbbjJOGCDg@mail.gmail.com>
 <ca926b29-9dff-cceb-5734-7d510a48a045@cern.ch>
 <CAOirdiUEO+yE1=KN-kEVLR3sRBY15weFjc_kRzMEboS=UjZ-gA@mail.gmail.com>
 <3209d9fc-8db1-6dca-5736-402c6f082fcc@cern.ch>
Message-ID: <CAF7gwdhXXWA_Q0ZO57w24oCY7FoeuxMwah7shRj_tEdpeBPiMw@mail.gmail.com>

On Mon, Feb 28, 2022 at 1:12 AM Arne Wiebalck <arne.wiebalck at cern.ch> wrote:
>
> Hi Guangyu,
>
> I am not aware of anything in the Ironic Python Agent that
> would remove disks from the system in a way that they would
> not be visible after a reboot (apart from, as mentioned before,
> the clean up of a hardware RAID in a way the IPA is not able
> to see any devices after).
>
> How about trying to access and configure the hardware RAID with
> the corresponding tool from the RAM disk you booted into from the
> USB stick? Install the tool and see if it detects the controller.
>
> The very first step before doing anything with Ironic is to
> get the disks back or understand why they are not visible.
>

Did cleaning fail at any given point with these machines?

If you have physical access, try disconnecting all of the drives, and
then powering up the machine and see if you can get into the firmware
configuration screen with control-h. If you can, remove all of the
prior configuration or disk volumes. They will look like they are in
error states most likely. If your unable to get into this screen, I
would be worried about your disk controller card. If your able to
clear everything out of the controller, power off, try re-inserting
drives, and see what happens. See if the controller can view/interact
with the drives. If it sees no drives, then my next paragraph is
likely the case.

The disks sound like they might be in security locked state which will
likely require a desktop SATA disk controller to remedy by attaching
and manually removing from a security locked state. Megaraid
controllers can't recognize security locked devices (most controllers
and especially ones labeled "raid controllers" can't handle it) when
in pass-through mode, but I've never heard of security lock commands
actually getting through to the device with those controllers in
pass-through mode. If the card was in raid mode to begin with, then it
likely never did anything involving secure erase as the controller
should not be offering that as a feature of provided disks to the OS.

> Cheers,
>   Arne
>
> On 28.02.22 09:28, ??? wrote:
> > Hi Arne,
> >
> > I didn't find hardware RAID config option during the initial boot
> > sequence. Ctrl+H is unresponsive in this computer. I just saw "Press
> > Del to enter firmware configuration, press F3 to enter boot menu, and
> > press F12 to enter network boot". And I press 'Del' to enter the BIOS.
> > But I didn't find RAID config menu in BIOS. Sorry that I have poor
> > knowledge about this.
> >
> > And now, even though I installed the operating system manually using a
> > USB stick, I still couldn't find the hard drive. Is there anything
> > that ironic-agent did in the clean phase that would have caused this
> > problem?
> >
> > I wonder if this is a thinking pointto solve the problem. Now, my idea
> > is to first find a way to manually configure RAID.  Do you agree with
> > this?  And than, whether RAID configurations are still cleared in the
> > Clean phase if clean phase will do this?
> >
> > Sorry that I have so much confuse.
> >
> > love you,
> > Guangyu
> >
> > Arne Wiebalck <arne.wiebalck at cern.ch> ?2022?2?14??? 15:59???
> >>
> >> Hi Guangyu,
> >>
> >> It seems like Julia had the right idea and the disks
> >> are not visible since the RAID controller does not
> >> expose anything to the operating system. This seems
> >> to be confirmed by you booting into the CentOS7 image.
> >>
> >> What I would suggest to try next is to look for the
> >> hardware RAID config option during the initial boot
> >> sequence to enter the RAID config menu (there should be
> >> a message quite early on, and maybe Ctrl-H is needed
> >> to enter the menu).
> >>
> >> Once there, manually configure the disks as JBODs or
> >> create a RAID device. Upon reboot this should be visible
> >> and accessible as a device. Maybe check from your CentOS7
> >> image again. If the devices are there, Ironic should
> >> also be able to deploy on them (for this you can remove
> >> the RAID config you added).
> >>
> >> It depends a little on what your goal is, but I would
> >> try this first to see if you can make a device visible
> >> and if the Ironic deploy bit works, before trying to
> >> configure the hardware RAID via Ironic.
> >>
> >> Cheers,
> >>    Arne
> >>
> >> On 14.02.22 03:20, ??? wrote:
> >>> Hi Arne and Julia,
> >>>
> >>> You make me feel so warm. Best wishes to you.
> >>>
> >>> I have tried to boot the node into a CentOS7, but it still coundnot to
> >>> find disk. And sorry that I didn't notice the RAID card.
> >>>
> >>> # lspci -v
> >>> ...
> >>> 23:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS-3 3108
> >>> [Invader] (rev 02)
> >>>           Subsystem: Broadcom / LSI MegaRAID SAS 9361-8i
> >>>           Flags: bus master, fast devsel, latency 0, IRQ -2147483648, NUMA node 1
> >>>           I/O ports at 3000 [size=256]
> >>>           Memory at e9900000 (64-bit, non-prefetchable) [size=64K]
> >>>           Memory at e9700000 (64-bit, non-prefetchable) [size=1M]
> >>>           Expansion ROM at e9800000 [disabled] [size=1M]
> >>>           Capabilities: [50] Power Management version 3
> >>>           Capabilities: [68] Express Endpoint, MSI 00
> >>>           Capabilities: [d0] Vital Product Data
> >>>           Capabilities: [a8] MSI: Enable- Count=1/1 Maskable+ 64bit+
> >>>           Capabilities: [c0] MSI-X: Enable+ Count=97 Masked-
> >>>           Capabilities: [100] Advanced Error Reporting
> >>>           Capabilities: [1e0] #19
> >>>           Capabilities: [1c0] Power Budgeting <?>
> >>>           Capabilities: [148] Alternative Routing-ID Interpretation (ARI)
> >>>           Kernel driver in use: megaraid_sas
> >>>           Kernel modules: megaraid_sas
> >>> ...
> >>>
> >>> I try to config raid fallowing
> >>> https://docs.openstack.org/ironic/latest/admin/raid.html
> >>> by `baremetal node set $NODE_UUID --target-raid-config raid.json`. The
> >>> server have  three same disk(Western Digital DC HA210 2TB SATA 6GB/s)
> >>> # cat raid.json
> >>> {
> >>>     "logical_disks": [
> >>>       {
> >>>         "size_gb": "MAX",
> >>>         "raid_level": "0",
> >>>         "is_root_volume": true
> >>>       }
> >>>     ]
> >>> }
> >>>
> >>> But Ironic still coundn't see disk. I still got
> >>> ```
> >>> ## In deploy images
> >>> # journalctl -fxeu ironic-python-agent
> >>> Feb 14 02:17:22 host-10-12-22-74 ironic-python-agent[2329]: 2022-02-14
> >>> 02:17:22.863 2329 WARNING root [-] Path /dev/disk/by-path is
> >>> inaccessible, /dev/disk/by-path/* version of block device name is
> >>> unavailable Cause: [Errno 2] No such file or directory:
> >>> '/dev/disk/by-path': FileNotFoundError: [Errno 2] No such file or
> >>> directory: '/dev/disk/by-path'
> >>> Feb 14 02:17:44 host-10-12-22-74 ironic-python-agent[2329]: 2022-02-14
> >>> 02:17:44.391 2329 ERROR root [-] Unexpected error dispatching
> >>> get_os_install_device to manager
> >>> <ironic_python_agent.hardware.GenericHardwareManager object at
> >>> 0x7efbf4da2208>: Error finding the disk or partition device to deploy
> >>> the image onto: No suitable device was found for deployment - root
> >>> device hints were not provided and all found block devices are smaller
> >>> than 4294967296B.: ironic_python_agent.errors.DeviceNotFound: Error
> >>> finding the disk or partition device to deploy the image onto: No
> >>> suitable device was found for deployment - root device hints were not
> >>> provided and all found block devices are smaller than 4294967296B.
> >>> ```
> >>>
> >>> I don't know if it's a lack of a RAID card driver or a lack of a disk
> >>> driver or a lack of RAID configuration. Could you have some idea about
> >>> this question?
> >>>
> >>> love you,
> >>> Han Guangyu
> >>>
> >>>
> >>> Julia Kreger <juliaashleykreger at gmail.com> ?2022?2?10??? 23:11???
> >>>
> >>>>
> >>>> If the disk controllers *are* enumerated in the kernel log, which is
> >>>> something to also look for, then the disks themselves may be in some
> >>>> weird state like security locked. Generally this shows up as the
> >>>> operating system kind of sees the disk and the SATA port connected but
> >>>> can't really access it. This is also an exceptionally rare state to
> >>>> find one's self in.
> >>>>
> >>>> More common, especially in enterprise grade hardware: If the disk
> >>>> controller is actually a raid controller, and there are no raid
> >>>> volumes configured, then the operating system likely cannot see the
> >>>> underlying disks and turn that into a usable block device. I've seen a
> >>>> couple drivers over the years which expose hints of disks in the
> >>>> kernel log and without raid configuration in the cards, the drivers
> >>>> can't present usable block devices to the operating system system.
> >>>>
> >>>> -Julia
> >>>>
> >>>> On Thu, Feb 10, 2022 at 3:17 AM Arne Wiebalck <arne.wiebalck at cern.ch> wrote:
> >>>>>
> >>>>> Hi Guangyu,
> >>>>>
> >>>>> No worries about asking questions, this is what the mailing
> >>>>> list is for :)
> >>>>>
> >>>>> Just to clarify, you do not have to set root device hints,
> >>>>> it also works without (with the algorithm I mentioned).
> >>>>> However, hints help to define the exact device and/or make
> >>>>> deployment more predictable/repeatable.
> >>>>>
> >>>>> If it is really a driver problem, it is an issue with the
> >>>>> operating system of the image you use, i.e. CentOS8. Some
> >>>>> drivers were removed from 7 to 8, and we have seen issues
> >>>>> with specific drive models as well.
> >>>>>
> >>>>> You can try to build your own IPA images as described in
> >>>>> [1], e.g. to add your ssh key to be able to log into the
> >>>>> IPA to debug further, and to eventually include drivers
> >>>>> (if you can identify them and they are available for CentOS8).
> >>>>>
> >>>>> Another option may be to add another (newer) disk model to
> >>>>> the server, just to confirm it is the disk model/driver which
> >>>>> is the cause.
> >>>>>
> >>>>> You could also try to boot the node into a CentOS7 (and then
> >>>>> a CentOS8) live image to confirm it can see the disks at all.
> >>>>>
> >>>>> Hope this helps!
> >>>>>     Arne
> >>>>>
> >>>>> [1]
> >>>>> https://docs.openstack.org/ironic-python-agent-builder/latest/admin/dib.html
> >>>>>
> >>>>>
> >>>>> On 10.02.22 11:15, ??? wrote:
> >>>>>> Hi Arne,
> >>>>>>
> >>>>>> Thank you very much for your response. Love you. You take away a lot
> >>>>>> of my confusion.
> >>>>>>
> >>>>>> You are right, I didn't set 'root device'. And Ironic also can not see
> >>>>>> disk, the content of the 'lsblk' file in the deploy los is emply.
> >>>>>> I tried to set 'root device', but because ironic can't find any disk,
> >>>>>> the deploy still filed.
> >>>>>>
> >>>>>> Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
> >>>>>> 09:51:55.045 2324 WARNING root [-] Path /dev/disk/by-path is
> >>>>>> inaccessible, /dev/disk/by-path/* version of block device name is
> >>>>>> unavailable Cause: [Errno 2] No such file or directory:
> >>>>>> '/dev/disk/by-path': FileNotFoundError: [Errno 2] No such file or
> >>>>>> directory: '/dev/disk/by-path'
> >>>>>> Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
> >>>>>> 09:51:55.056 2324 WARNING ironic_lib.utils [-] No device found that
> >>>>>> matches the root device hints {'wwn': '0x50014EE2691D724C'}:
> >>>>>> StopIteration
> >>>>>>
> >>>>>> Sorry to bother you, I'm a newcomer of Ironic and I didn't find
> >>>>>> information about it on google.
> >>>>>>
> >>>>>> The bare metal node have three same disk(Western Digital DC HA210 2TB
> >>>>>> SATA 6GB/s). Where I can confirm whether ironic-python-agent supports
> >>>>>> this disk?
> >>>>>>
> >>>>>> And If Ironic cannot find disk since the corresponding drivers in the
> >>>>>> IPA image are missing, do you know how to resolve it? I have used the
> >>>>>> latest deploy images in
> >>>>>> https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/
> >>>>>> .  Do I need to find and manually add driver in the source code or
> >>>>>> ramdisk(That was difficult tome)?
> >>>>>>
> >>>>>> Love you.
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Guangyu
> >>>>>>
> >>>>>> Arne Wiebalck <arne.wiebalck at cern.ch> ?2022?2?10??? 15:51???
> >>>>>>>
> >>>>>>> Hi Guangyu,
> >>>>>>>
> >>>>>>> The error indicates that Ironic was not able to find
> >>>>>>> a device where it could deploy the image to.
> >>>>>>>
> >>>>>>> To find a device, Ironic will use 'root device'
> >>>>>>> hints [1], usually set by the admin on a node. If that
> >>>>>>> does not yield anything, Ironic will loop over all
> >>>>>>> block devices and pick the smallest which is larger
> >>>>>>> than 4GB (and order them alphabetically).
> >>>>>>>
> >>>>>>> If you have disks in your server which are larger than
> >>>>>>> 4GB, one potential explanation is that Ironic cannot see them,
> >>>>>>> e.g. since the corresponding drivers in the IPA image are missing.
> >>>>>>> The logs you posted seem to confirm something along those
> >>>>>>> lines.
> >>>>>>>
> >>>>>>> Check the content of the 'lsblk' file in the deploy logs which
> >>>>>>> you can find in the tar archive in /var/log/ironic/deploy/
> >>>>>>> on the controller for your deployment attempt to see what
> >>>>>>> devices Ironic has access to.
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>>      Arne
> >>>>>>>
> >>>>>>>
> >>>>>>> [1] https://docs.openstack.org/ironic/latest/install/advanced.html#root-device-hints
> >>>>>>>
> >>>>>>> On 10.02.22 02:50, ??? wrote:
> >>>>>>>> Dear all,
> >>>>>>>>
> >>>>>>>> I have a OpenStack Victoria environment, and tried to use ironic
> >>>>>>>> manage bare metal. But I got "- root device hints were not provided
> >>>>>>>> and all found block devices are smaller than 4294967296B." in deploy
> >>>>>>>> stage.
> >>>>>>>>
> >>>>>>>> 2022-02-09 17:57:56.492 3908982 ERROR
> >>>>>>>> ironic.drivers.modules.agent_base [-] Agent returned error for deploy
> >>>>>>>> step {'step': 'write_image', 'priority': 80, 'argsinfo': None,
> >>>>>>>> 'interface': 'deploy'} on node cc68c450-ce54-4e1c-be04-8b0a6169ef92 :
> >>>>>>>> No suitable device was found for deployment - root device hints were
> >>>>>>>> not provided and all found block devices are smaller than
> >>>>>>>> 4294967296B..
> >>>>>>>>
> >>>>>>>> I used "openstack server create --flavor my-baremetal-flavor --nic
> >>>>>>>> net-id=$net_id --image $image testing" to deploy bare metal node.  I
> >>>>>>>> download deploy images(ipa-centos8-master.kernel and
> >>>>>>>> ipa-centos8-master.initramfs) in
> >>>>>>>> https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/.
> >>>>>>>>
> >>>>>>>> The baremetal node info and flavor info as following:
> >>>>>>>> https://paste.opendev.org/show/bV7lgO6RkNQY6ZGPbT2e/
> >>>>>>>> Ironic configure file as following:
> >>>>>>>> https://paste.opendev.org/show/bTgY9Kpn7KWqwQl73aEa/
> >>>>>>>> Ironic-conductor log:    https://paste.opendev.org/show/bFKZYlXmccxNxU8lEogk/
> >>>>>>>> The log of ironic-python-agent in bare metal node:
> >>>>>>>> https://paste.opendev.org/show/btAuaMuV2IutV2Pa7YIa/
> >>>>>>>>
> >>>>>>>> I see some old discussion about this, such as:
> >>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1312187. But those
> >>>>>>>> discussions took place a long time ago, not version V, and no solution
> >>>>>>>> was seen.
> >>>>>>>>
> >>>>>>>> Does anyone know how to solve this problem? I would appreciate any
> >>>>>>>> kind of guidance or help.
> >>>>>>>>
> >>>>>>>> Thank you,
> >>>>>>>> Han Guangyu
> >>>>>>>>
> >>>>>


From jesse at odyssey4.me  Tue Mar  1 14:57:48 2022
From: jesse at odyssey4.me (Jesse Pretorius)
Date: Tue, 1 Mar 2022 14:57:48 +0000
Subject: [TripleO] centos9 jobs only for master, centos 8 & 9 for wallaby
In-Reply-To: <CAM51kHVWBO07=crAXJ8ZpfA4b9A7w+YuFBG3N17dc=hU=k_e-A@mail.gmail.com>
References: <CAM51kHVWBO07=crAXJ8ZpfA4b9A7w+YuFBG3N17dc=hU=k_e-A@mail.gmail.com>
Message-ID: <32D116CA-5034-4557-BEDF-6D7E8C7FDD48@odyssey4.me>

Hi folks, response in-line.

> On 24 Feb 2022, at 15:11, Marios Andreou <marios at redhat.com> wrote:
> 
> Hello TripleO o/
> 
> During the last period the tripleo-ci team has been working on getting
> tripleo CI jobs to run centos-9.
> 
> On master branches across all TripleO repos we now run C9 exclusively
> (since [1]).
> 
> On Wallaby branches, after the work at [2] (in particular after
> https://review.opendev.org/c/openstack/tripleo-ci/+/830132 merges) we
> will run both C8 and C9 jobs. I started an etherpad at [3] thinking
> this would be a PTG topic, but I think we'll want to have this
> conversation way before then. There is a tripleo-heat-templates
> example in the etherpad that shows what we can expect from the job
> runs (note the exact jobs that run will vary per repo and even between
> changes depending on the files touched - but generally there will be
> duplication between 8 and 9 jobs).
> 
> The current proposal is that we keep a minimal subset on C8 Wallaby,
> with C9 wallaby having the full set of jobs.
> 
> Two factors that will affect our decisions are (there may be more?)
> 
>  i) Upgrades requirements - are we supporting upgrading to Wallaby on
> 8? For example, the coming undercloud-upgrade-ffu job will be train 8
> to wallaby 8. In which case we definitely need to keep at least some
> subset of 8 jobs (and can't entertain the removal of 8 from Wallaby
> completely).

I think trying to keep up with the moving target of 8-stream would be counterproductive given that we are pinned downstream to RHEL 8.4 for Train. We do have a pending patch to merge a job for 8-Stream/Train->8-Stream Wallaby for the Undercloud only, which would be nice to keep but if it becomes troublesome then I?d suggest we remove it. This job adds some value to us (and has added quite a bit already in preparing it and making it pass), but if 8-stream starts making it fail, or it starts failing due to database migrations then we?ll have to shift that job downstream and deal with the consequences of only ever finding upgrade bugs post-merge.

It is well known that a Fast-Forward Upgrade (FFU) of OpenStack services is not supported upstream, so we can not expect any upstream jobs to reliability support this process. If/when there is broader support for enabling FFU support officially in OpenStack services, then we can reconsider this position.

>  ii) Are we importing from Wallaby 8 or Wallaby 9? Currently it is 8
> but this will soon switch.
> 
> For the wallaby c8 'subset of jobs' e.g. multinode, vanilla standalone
> (no scenarios? some subset of them?), undercloud-ffu, minor update.
> 
> This is just to start the conversation so please reply if you have
> thoughts or comments about any of the above.
> 
> We are planning to discuss this in the coming tripleo-ci community
> call this coming Tuesday at 1330 UTC - meeting link at [4] so please
> join us if you can and would like to participate,
> 
> regards, marios
> 
> [1] https://review.opendev.org/q/topic:c8_teardown_master
> [2] https://review.opendev.org/q/topic:c9_wallaby_gates
> [3] https://etherpad.opendev.org/p/tripleoci-wallaby-centos-8-9
> [4] https://meet.google.com/bqx-xwht-wky
> 
> 


From mthode at mthode.org  Tue Mar  1 17:12:17 2022
From: mthode at mthode.org (Matthew Thode)
Date: Tue, 1 Mar 2022 11:12:17 -0600
Subject: [masakari][oslo][requirements] oslo.context>=4.0.0 seems to need
 updated tests
In-Reply-To: <20220228165609.zzz7ur2mktfrqmue@mthode.org>
References: <20220228165609.zzz7ur2mktfrqmue@mthode.org>
Message-ID: <20220301171217.ixkrog3yrxefqntz@mthode.org>

On 22-02-28 10:56:09, Matthew Thode wrote:
> The update to see what's breaking is here
> https://review.opendev.org/829599
> 
> Feel free to make that patch depend on your fix to test (with rechecks)
> 

Looks like it's just masakari now, not too many commits though :|

-- 
Matthew Thode


From elod.illes at est.tech  Tue Mar  1 20:43:35 2022
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Tue, 1 Mar 2022 21:43:35 +0100
Subject: [release][requirements][oslo][kuryr][keystone] RFE request
Message-ID: <116ca5d1-c8e3-d51b-dd98-3b2c444a06b7@est.tech>

Hi,

It turned out that kuryr [1] and keystoneauth [2] deliverables were 
missed at non-client libraries final release period. So we need to 
release them now and request Requirement Freeze Exception for them. 
(PTLs / release liaisons of kuryr and keystoneauth: please review the 
patches [1][2] as soon as possible)

Also I want to mention here oslo.context as well, to formally include it 
to RFE. (It seems versions >=4.0.0 break things, see thread [3] and [4].)


[1] https://review.opendev.org/c/openstack/releases/+/831025
[2] https://review.opendev.org/c/openstack/releases/+/831024
[3] 
http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027455.html
[4] 
http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027480.html


El?d


From sunny at openstack.org  Tue Mar  1 20:29:48 2022
From: sunny at openstack.org (Sunny Cai)
Date: Tue, 1 Mar 2022 12:29:48 -0800
Subject: How OpenStack is Used in Academia - OpenInfra Live
References: <59f2a75e-8a74-4e04-899b-05e46f7496ab@Spark>
Message-ID: <c25a2501-507e-4af6-bb50-f32eb6712633@Spark>

Hi everyone,

This week on OpenInfra Live episode, we are featuring topics on how OpenStack is used in Academic space

Open source cloud computing has gained a lot of adoption momentum due to advantages including low cost, flexibility, scalability, and more. Since the early days of OpenStack with NASA?s direct involvement, OpenStack has been deployed in various notable academic institutions all over the world for their infrastructure needs. For this episode, we have invited experts from Oregon State University, Monash University, T?l?com Paris, and OpenStack Scientific SIG to talk about how they use OpenStack in academia.

Episode: How OpenStack is Used in Academia

Date and time: Thursday, March 3 at 9am CT (1500 UTC)

You can watch us live on YouTube [1], LinkedIn [2] and Facebook[3].

Host:?Kendall Nelson, Senior Upstream Developer Advocate at the OpenInfra Foundation
Speakers:

? Stig Telfer, Scientific SIG Chair and CTO at StackHPC Ltd
? Steve Quenette, Deputy Director at Monash eResearch Centre, Monash University
? R?mi Sharrock, Researcher and Lecturer at T?l?com Paris & Marc Jeanmougin, Research Engineer at T?l?com Paris
? Lance Albertson, Director at Oregon State University Open Source Lab

Have an idea for a future episode? Share it now at ideas.openinfra.live [4].

[1] https://www.youtube.com/watch?v=xqGvMn0B7jc&ab_channel=OpenInfrastructureFoundation
[2]?https://www.linkedin.com/video/event/urn:li:ugcPost:6902672962731016192/
[3] https://www.facebook.com/104139126308032/posts/4883571768364720/
[4] https://openinfrafoundation.formstack.com/forms/openinfralive


Thanks,

Sunny Cai
OpenInfra Foundation
Marketing & Community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220301/e90ebdbb/attachment-0001.htm>

From mthode at mthode.org  Tue Mar  1 20:53:46 2022
From: mthode at mthode.org (Matthew Thode)
Date: Tue, 1 Mar 2022 14:53:46 -0600
Subject: [release][requirements][oslo][kuryr][keystone] RFE request
In-Reply-To: <116ca5d1-c8e3-d51b-dd98-3b2c444a06b7@est.tech>
References: <116ca5d1-c8e3-d51b-dd98-3b2c444a06b7@est.tech>
Message-ID: <20220301205346.nbdx5yi6fbcifeks@mthode.org>

On 22-03-01 21:43:35, El?d Ill?s wrote:
> Hi,
> 
> It turned out that kuryr [1] and keystoneauth [2] deliverables were missed
> at non-client libraries final release period. So we need to release them now
> and request Requirement Freeze Exception for them. (PTLs / release liaisons
> of kuryr and keystoneauth: please review the patches [1][2] as soon as
> possible)
> 
> Also I want to mention here oslo.context as well, to formally include it to
> RFE. (It seems versions >=4.0.0 break things, see thread [3] and [4].)
> 
> 
> [1] https://review.opendev.org/c/openstack/releases/+/831025
> [2] https://review.opendev.org/c/openstack/releases/+/831024
> [3] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027455.html
> [4]
> http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027480.html
> 
> 
> El?d
> 

Requirements is ok with these and approves.  Thanks for the formal email
:D

-- 
Matthew Thode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220301/b516ea2e/attachment.sig>

From laurentfdumont at gmail.com  Wed Mar  2 03:31:07 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Tue, 1 Mar 2022 22:31:07 -0500
Subject: [horizon][customization]
In-Reply-To: <7b01ef62-8442-3ab8-8c40-5935547bffae@ovhcloud.com>
References: <3aa4a3df-fab3-ccc0-5bc3-821cdb80ce67@ovhcloud.com>
 <CAOAKi8yRGCJOQnfyxg=VOSb1BbjwQTebEFAOrBBmYY9PUoGYKQ@mail.gmail.com>
 <7b01ef62-8442-3ab8-8c40-5935547bffae@ovhcloud.com>
Message-ID: <CAOAKi8wgfb1jM3rWMgmnyuz2Ux2yDRmrr7m0mBoHSAzOr-ZOTw@mail.gmail.com>

Hi!

That is possible. Which version of the doc we're you looking at? I think
those are able to be modified through merge requests.

On Tue, Mar 1, 2022 at 9:07 AM Mathilde Hermet <mathilde.hermet at ovhcloud.com>
wrote:

> Hello,
>
>
> I manage to find that the problem in your documentation is that you forgot
> to tell that command "$python manage.py compress --force" must be run after
> collecting statics.
>
> I run it and then my custom themes worked.
>
> This appears to be required in earlier version of horizon that is why
> documentation is may be not up to date.
>
>
> Thanks
>
>
> Mathilde
> On 3/1/22 00:25, Laurent Dumont wrote:
>
> Salut!
>
> A 500 from Horizon is a bit strange. What do the Horizon logs say?
>
> If you remove your customization and restart Horizon, does it recover?
>
> On Mon, Feb 28, 2022 at 11:17 AM Mathilde Hermet <
> mathilde.hermet at ovhcloud.com> wrote:
>
>> Hello Openstack team,
>>
>>
>> I'm currently working on customizing the Horizon (xena) dashboard to use
>> the OVHcloud assets: logo.svg and logo-splash.svg.
>>
>> I've been following this documentation
>> https://docs.openstack.org/horizon/latest/configuration/themes.html
>>
>> I added the ovhcloud theme in
>> horizon/openstack_dashboard/local/local_settings.py in AVAILABLE_THEMES,
>>
>> I created the subdir ovhcloud in horizon/openstack_dashboard/themes and
>> I created a ovhcloud/img with logo.svg and logo-splash.svg in it.
>>
>> I put a _variables.scss and a _styles.scss in /themes/ovhcloud/
>>
>> Then I executed python manage.py collectstatic
>>
>> It put all the files in horizon-sources/horizon.../static/themes/ovhcloud
>>
>>
>> But then when trying to connect with the session cookie
>> theme="ovhcloud", I have a 500 error.
>>
>> i don't think it comes from images because i've been puting it in
>> /horizon-souurces/horizon.../static/dashbaord.img and they were
>> displayed correctly.
>>
>>
>> Do you have any idea about the misconfiguration I've done ?
>>
>>
>> Best regards,
>>
>>
>> Mathilde Hermet
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220301/6b389104/attachment.htm>

From marios at redhat.com  Wed Mar  2 06:57:55 2022
From: marios at redhat.com (Marios Andreou)
Date: Wed, 2 Mar 2022 08:57:55 +0200
Subject: [TripleO] centos9 jobs only for master, centos 8 & 9 for wallaby
In-Reply-To: <32D116CA-5034-4557-BEDF-6D7E8C7FDD48@odyssey4.me>
References: <CAM51kHVWBO07=crAXJ8ZpfA4b9A7w+YuFBG3N17dc=hU=k_e-A@mail.gmail.com>
 <32D116CA-5034-4557-BEDF-6D7E8C7FDD48@odyssey4.me>
Message-ID: <CAM51kHWM4QqxNs9AFcr1NnR5RBfL2D4Q=PiGLo=WnpsQVYgeLw@mail.gmail.com>

On Tue, Mar 1, 2022 at 5:03 PM Jesse Pretorius <jesse at odyssey4.me> wrote:
>
> Hi folks, response in-line.
>
> > On 24 Feb 2022, at 15:11, Marios Andreou <marios at redhat.com> wrote:
> >
> > Hello TripleO o/
> >
> > During the last period the tripleo-ci team has been working on getting
> > tripleo CI jobs to run centos-9.
> >
> > On master branches across all TripleO repos we now run C9 exclusively
> > (since [1]).
> >
> > On Wallaby branches, after the work at [2] (in particular after
> > https://review.opendev.org/c/openstack/tripleo-ci/+/830132 merges) we
> > will run both C8 and C9 jobs. I started an etherpad at [3] thinking
> > this would be a PTG topic, but I think we'll want to have this
> > conversation way before then. There is a tripleo-heat-templates
> > example in the etherpad that shows what we can expect from the job
> > runs (note the exact jobs that run will vary per repo and even between
> > changes depending on the files touched - but generally there will be
> > duplication between 8 and 9 jobs).
> >
> > The current proposal is that we keep a minimal subset on C8 Wallaby,
> > with C9 wallaby having the full set of jobs.
> >
> > Two factors that will affect our decisions are (there may be more?)
> >
> >  i) Upgrades requirements - are we supporting upgrading to Wallaby on
> > 8? For example, the coming undercloud-upgrade-ffu job will be train 8
> > to wallaby 8. In which case we definitely need to keep at least some
> > subset of 8 jobs (and can't entertain the removal of 8 from Wallaby
> > completely).
>
> I think trying to keep up with the moving target of 8-stream would be counterproductive given that we are pinned downstream to RHEL 8.4 for Train. We do have a pending patch to merge a job for 8-Stream/Train->8-Stream Wallaby for the Undercloud only, which would be nice to keep but if it becomes troublesome then I?d suggest we remove it. This job adds some value to us (and has added quite a bit already in preparing it and making it pass), but if 8-stream starts making it fail, or it starts failing due to database migrations then we?ll have to shift that job downstream and deal with the consequences of only ever finding upgrade bugs post-merge.
>
> It is well known that a Fast-Forward Upgrade (FFU) of OpenStack services is not supported upstream, so we can not expect any upstream jobs to reliability support this process. If/when there is broader support for enabling FFU support officially in OpenStack services, then we can reconsider this position.
>

Hi Jesse,

thanks for replying here too.

As shaped by the discussions yesterday and for the benefit of others -
our current plan is to keep the c8 undercloud-ffu job and in fact that
will be the *only* job we will keep on C8 (if standalone ffu upgrade
becomes a thing then that will also be 8 only). At least, we'll make a
best effort to keep this and we can re-evaluate once we hit blocking
issues.

In order to maintain this C8 gate we'll also need to maintain the
equivalent periodic version for the integration line. So we'll have a
C8 integration line running the undercloud-ffu job and possibly one
ovb job (TBD, likely featureset 1).

To be clear, our plan is to remove *all* centos8 check/gate jobs,
except the undercloud-ffu. We are not planning to keep any 'base' set
of c8 jobs unless someone can make a case for their value.

The tripleo-ci team will start implementing the removal of c8/wallaby
jobs once we switch to use c9 for the imports which should happen
within the next week or so.

regards, marios

> >  ii) Are we importing from Wallaby 8 or Wallaby 9? Currently it is 8
> > but this will soon switch.
> >
> > For the wallaby c8 'subset of jobs' e.g. multinode, vanilla standalone
> > (no scenarios? some subset of them?), undercloud-ffu, minor update.
> >
> > This is just to start the conversation so please reply if you have
> > thoughts or comments about any of the above.
> >
> > We are planning to discuss this in the coming tripleo-ci community
> > call this coming Tuesday at 1330 UTC - meeting link at [4] so please
> > join us if you can and would like to participate,
> >
> > regards, marios
> >
> > [1] https://review.opendev.org/q/topic:c8_teardown_master
> > [2] https://review.opendev.org/q/topic:c9_wallaby_gates
> > [3] https://etherpad.opendev.org/p/tripleoci-wallaby-centos-8-9
> > [4] https://meet.google.com/bqx-xwht-wky
> >
> >
>



From jpodivin at redhat.com  Wed Mar  2 07:43:59 2022
From: jpodivin at redhat.com (Jiri Podivin)
Date: Wed, 2 Mar 2022 08:43:59 +0100
Subject: [TripleO] centos9 jobs only for master, centos 8 & 9 for wallaby
In-Reply-To: <CAM51kHWM4QqxNs9AFcr1NnR5RBfL2D4Q=PiGLo=WnpsQVYgeLw@mail.gmail.com>
References: <CAM51kHVWBO07=crAXJ8ZpfA4b9A7w+YuFBG3N17dc=hU=k_e-A@mail.gmail.com>
 <32D116CA-5034-4557-BEDF-6D7E8C7FDD48@odyssey4.me>
 <CAM51kHWM4QqxNs9AFcr1NnR5RBfL2D4Q=PiGLo=WnpsQVYgeLw@mail.gmail.com>
Message-ID: <CAD0_RgFE0JMjPRfUEuoShwnH7VtfxN4Fg-u13DH=j67tHW2YRw@mail.gmail.com>

Hi,
Sorry I'm replying this late, but this line raised some questions for me:
> To be clear, our plan is to remove *all* centos8 check/gate jobs,

It seems to imply that all centos8 jobs in both pipelines will be removed,
across stable branches.
Does this mean up to and including train?
It was my understanding that everything older than wallaby will remain as
it is.


On Wed, Mar 2, 2022 at 8:04 AM Marios Andreou <marios at redhat.com> wrote:

> On Tue, Mar 1, 2022 at 5:03 PM Jesse Pretorius <jesse at odyssey4.me> wrote:
> >
> > Hi folks, response in-line.
> >
> > > On 24 Feb 2022, at 15:11, Marios Andreou <marios at redhat.com> wrote:
> > >
> > > Hello TripleO o/
> > >
> > > During the last period the tripleo-ci team has been working on getting
> > > tripleo CI jobs to run centos-9.
> > >
> > > On master branches across all TripleO repos we now run C9 exclusively
> > > (since [1]).
> > >
> > > On Wallaby branches, after the work at [2] (in particular after
> > > https://review.opendev.org/c/openstack/tripleo-ci/+/830132 merges) we
> > > will run both C8 and C9 jobs. I started an etherpad at [3] thinking
> > > this would be a PTG topic, but I think we'll want to have this
> > > conversation way before then. There is a tripleo-heat-templates
> > > example in the etherpad that shows what we can expect from the job
> > > runs (note the exact jobs that run will vary per repo and even between
> > > changes depending on the files touched - but generally there will be
> > > duplication between 8 and 9 jobs).
> > >
> > > The current proposal is that we keep a minimal subset on C8 Wallaby,
> > > with C9 wallaby having the full set of jobs.
> > >
> > > Two factors that will affect our decisions are (there may be more?)
> > >
> > >  i) Upgrades requirements - are we supporting upgrading to Wallaby on
> > > 8? For example, the coming undercloud-upgrade-ffu job will be train 8
> > > to wallaby 8. In which case we definitely need to keep at least some
> > > subset of 8 jobs (and can't entertain the removal of 8 from Wallaby
> > > completely).
> >
> > I think trying to keep up with the moving target of 8-stream would be
> counterproductive given that we are pinned downstream to RHEL 8.4 for
> Train. We do have a pending patch to merge a job for
> 8-Stream/Train->8-Stream Wallaby for the Undercloud only, which would be
> nice to keep but if it becomes troublesome then I?d suggest we remove it.
> This job adds some value to us (and has added quite a bit already in
> preparing it and making it pass), but if 8-stream starts making it fail, or
> it starts failing due to database migrations then we?ll have to shift that
> job downstream and deal with the consequences of only ever finding upgrade
> bugs post-merge.
> >
> > It is well known that a Fast-Forward Upgrade (FFU) of OpenStack services
> is not supported upstream, so we can not expect any upstream jobs to
> reliability support this process. If/when there is broader support for
> enabling FFU support officially in OpenStack services, then we can
> reconsider this position.
> >
>
> Hi Jesse,
>
> thanks for replying here too.
>
> As shaped by the discussions yesterday and for the benefit of others -
> our current plan is to keep the c8 undercloud-ffu job and in fact that
> will be the *only* job we will keep on C8 (if standalone ffu upgrade
> becomes a thing then that will also be 8 only). At least, we'll make a
> best effort to keep this and we can re-evaluate once we hit blocking
> issues.
>
> In order to maintain this C8 gate we'll also need to maintain the
> equivalent periodic version for the integration line. So we'll have a
> C8 integration line running the undercloud-ffu job and possibly one
> ovb job (TBD, likely featureset 1).
>
> To be clear, our plan is to remove *all* centos8 check/gate jobs,
> except the undercloud-ffu. We are not planning to keep any 'base' set
> of c8 jobs unless someone can make a case for their value.
>
> The tripleo-ci team will start implementing the removal of c8/wallaby
> jobs once we switch to use c9 for the imports which should happen
> within the next week or so.
>
> regards, marios
>
> > >  ii) Are we importing from Wallaby 8 or Wallaby 9? Currently it is 8
> > > but this will soon switch.
> > >
> > > For the wallaby c8 'subset of jobs' e.g. multinode, vanilla standalone
> > > (no scenarios? some subset of them?), undercloud-ffu, minor update.
> > >
> > > This is just to start the conversation so please reply if you have
> > > thoughts or comments about any of the above.
> > >
> > > We are planning to discuss this in the coming tripleo-ci community
> > > call this coming Tuesday at 1330 UTC - meeting link at [4] so please
> > > join us if you can and would like to participate,
> > >
> > > regards, marios
> > >
> > > [1] https://review.opendev.org/q/topic:c8_teardown_master
> > > [2] https://review.opendev.org/q/topic:c9_wallaby_gates
> > > [3] https://etherpad.opendev.org/p/tripleoci-wallaby-centos-8-9
> > > [4] https://meet.google.com/bqx-xwht-wky
> > >
> > >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220302/6fcf48e9/attachment-0001.htm>

From marios at redhat.com  Wed Mar  2 08:05:18 2022
From: marios at redhat.com (Marios Andreou)
Date: Wed, 2 Mar 2022 10:05:18 +0200
Subject: [TripleO] centos9 jobs only for master, centos 8 & 9 for wallaby
In-Reply-To: <CAD0_RgFE0JMjPRfUEuoShwnH7VtfxN4Fg-u13DH=j67tHW2YRw@mail.gmail.com>
References: <CAM51kHVWBO07=crAXJ8ZpfA4b9A7w+YuFBG3N17dc=hU=k_e-A@mail.gmail.com>
 <32D116CA-5034-4557-BEDF-6D7E8C7FDD48@odyssey4.me>
 <CAM51kHWM4QqxNs9AFcr1NnR5RBfL2D4Q=PiGLo=WnpsQVYgeLw@mail.gmail.com>
 <CAD0_RgFE0JMjPRfUEuoShwnH7VtfxN4Fg-u13DH=j67tHW2YRw@mail.gmail.com>
Message-ID: <CAM51kHVFq6vUR-yNWeqnKhvECFNp2itXgKy_F30Jb+r8vW_ZVg@mail.gmail.com>

On Wed, Mar 2, 2022 at 9:44 AM Jiri Podivin <jpodivin at redhat.com> wrote:
>
> Hi,
> Sorry I'm replying this late, but this line raised some questions for me:
> > To be clear, our plan is to remove *all* centos8 check/gate jobs,
>
> It seems to imply that all centos8 jobs in both pipelines will be removed, across stable branches.
> Does this mean up to and including train?
> It was my understanding that everything older than wallaby will remain as it is.
>

This discussion is exclusively about wallaby - older stable branches
will be unaffected.





>
> On Wed, Mar 2, 2022 at 8:04 AM Marios Andreou <marios at redhat.com> wrote:
>>
>> On Tue, Mar 1, 2022 at 5:03 PM Jesse Pretorius <jesse at odyssey4.me> wrote:
>> >
>> > Hi folks, response in-line.
>> >
>> > > On 24 Feb 2022, at 15:11, Marios Andreou <marios at redhat.com> wrote:
>> > >
>> > > Hello TripleO o/
>> > >
>> > > During the last period the tripleo-ci team has been working on getting
>> > > tripleo CI jobs to run centos-9.
>> > >
>> > > On master branches across all TripleO repos we now run C9 exclusively
>> > > (since [1]).
>> > >
>> > > On Wallaby branches, after the work at [2] (in particular after
>> > > https://review.opendev.org/c/openstack/tripleo-ci/+/830132 merges) we
>> > > will run both C8 and C9 jobs. I started an etherpad at [3] thinking
>> > > this would be a PTG topic, but I think we'll want to have this
>> > > conversation way before then. There is a tripleo-heat-templates
>> > > example in the etherpad that shows what we can expect from the job
>> > > runs (note the exact jobs that run will vary per repo and even between
>> > > changes depending on the files touched - but generally there will be
>> > > duplication between 8 and 9 jobs).
>> > >
>> > > The current proposal is that we keep a minimal subset on C8 Wallaby,
>> > > with C9 wallaby having the full set of jobs.
>> > >
>> > > Two factors that will affect our decisions are (there may be more?)
>> > >
>> > >  i) Upgrades requirements - are we supporting upgrading to Wallaby on
>> > > 8? For example, the coming undercloud-upgrade-ffu job will be train 8
>> > > to wallaby 8. In which case we definitely need to keep at least some
>> > > subset of 8 jobs (and can't entertain the removal of 8 from Wallaby
>> > > completely).
>> >
>> > I think trying to keep up with the moving target of 8-stream would be counterproductive given that we are pinned downstream to RHEL 8.4 for Train. We do have a pending patch to merge a job for 8-Stream/Train->8-Stream Wallaby for the Undercloud only, which would be nice to keep but if it becomes troublesome then I?d suggest we remove it. This job adds some value to us (and has added quite a bit already in preparing it and making it pass), but if 8-stream starts making it fail, or it starts failing due to database migrations then we?ll have to shift that job downstream and deal with the consequences of only ever finding upgrade bugs post-merge.
>> >
>> > It is well known that a Fast-Forward Upgrade (FFU) of OpenStack services is not supported upstream, so we can not expect any upstream jobs to reliability support this process. If/when there is broader support for enabling FFU support officially in OpenStack services, then we can reconsider this position.
>> >
>>
>> Hi Jesse,
>>
>> thanks for replying here too.
>>
>> As shaped by the discussions yesterday and for the benefit of others -
>> our current plan is to keep the c8 undercloud-ffu job and in fact that
>> will be the *only* job we will keep on C8 (if standalone ffu upgrade
>> becomes a thing then that will also be 8 only). At least, we'll make a
>> best effort to keep this and we can re-evaluate once we hit blocking
>> issues.
>>
>> In order to maintain this C8 gate we'll also need to maintain the
>> equivalent periodic version for the integration line. So we'll have a
>> C8 integration line running the undercloud-ffu job and possibly one
>> ovb job (TBD, likely featureset 1).
>>
>> To be clear, our plan is to remove *all* centos8 check/gate jobs,
>> except the undercloud-ffu. We are not planning to keep any 'base' set
>> of c8 jobs unless someone can make a case for their value.
>>
>> The tripleo-ci team will start implementing the removal of c8/wallaby
>> jobs once we switch to use c9 for the imports which should happen
>> within the next week or so.
>>
>> regards, marios
>>
>> > >  ii) Are we importing from Wallaby 8 or Wallaby 9? Currently it is 8
>> > > but this will soon switch.
>> > >
>> > > For the wallaby c8 'subset of jobs' e.g. multinode, vanilla standalone
>> > > (no scenarios? some subset of them?), undercloud-ffu, minor update.
>> > >
>> > > This is just to start the conversation so please reply if you have
>> > > thoughts or comments about any of the above.
>> > >
>> > > We are planning to discuss this in the coming tripleo-ci community
>> > > call this coming Tuesday at 1330 UTC - meeting link at [4] so please
>> > > join us if you can and would like to participate,
>> > >
>> > > regards, marios
>> > >
>> > > [1] https://review.opendev.org/q/topic:c8_teardown_master
>> > > [2] https://review.opendev.org/q/topic:c9_wallaby_gates
>> > > [3] https://etherpad.opendev.org/p/tripleoci-wallaby-centos-8-9
>> > > [4] https://meet.google.com/bqx-xwht-wky
>> > >
>> > >
>> >
>>
>>

On Wed, Mar 2, 2022 at 9:44 AM Jiri Podivin <jpodivin at redhat.com> wrote:
>
> Hi,
> Sorry I'm replying this late, but this line raised some questions for me:
> > To be clear, our plan is to remove *all* centos8 check/gate jobs,
>
> It seems to imply that all centos8 jobs in both pipelines will be removed, across stable branches.
> Does this mean up to and including train?
> It was my understanding that everything older than wallaby will remain as it is.
>
>
> On Wed, Mar 2, 2022 at 8:04 AM Marios Andreou <marios at redhat.com> wrote:
>>
>> On Tue, Mar 1, 2022 at 5:03 PM Jesse Pretorius <jesse at odyssey4.me> wrote:
>> >
>> > Hi folks, response in-line.
>> >
>> > > On 24 Feb 2022, at 15:11, Marios Andreou <marios at redhat.com> wrote:
>> > >
>> > > Hello TripleO o/
>> > >
>> > > During the last period the tripleo-ci team has been working on getting
>> > > tripleo CI jobs to run centos-9.
>> > >
>> > > On master branches across all TripleO repos we now run C9 exclusively
>> > > (since [1]).
>> > >
>> > > On Wallaby branches, after the work at [2] (in particular after
>> > > https://review.opendev.org/c/openstack/tripleo-ci/+/830132 merges) we
>> > > will run both C8 and C9 jobs. I started an etherpad at [3] thinking
>> > > this would be a PTG topic, but I think we'll want to have this
>> > > conversation way before then. There is a tripleo-heat-templates
>> > > example in the etherpad that shows what we can expect from the job
>> > > runs (note the exact jobs that run will vary per repo and even between
>> > > changes depending on the files touched - but generally there will be
>> > > duplication between 8 and 9 jobs).
>> > >
>> > > The current proposal is that we keep a minimal subset on C8 Wallaby,
>> > > with C9 wallaby having the full set of jobs.
>> > >
>> > > Two factors that will affect our decisions are (there may be more?)
>> > >
>> > >  i) Upgrades requirements - are we supporting upgrading to Wallaby on
>> > > 8? For example, the coming undercloud-upgrade-ffu job will be train 8
>> > > to wallaby 8. In which case we definitely need to keep at least some
>> > > subset of 8 jobs (and can't entertain the removal of 8 from Wallaby
>> > > completely).
>> >
>> > I think trying to keep up with the moving target of 8-stream would be counterproductive given that we are pinned downstream to RHEL 8.4 for Train. We do have a pending patch to merge a job for 8-Stream/Train->8-Stream Wallaby for the Undercloud only, which would be nice to keep but if it becomes troublesome then I?d suggest we remove it. This job adds some value to us (and has added quite a bit already in preparing it and making it pass), but if 8-stream starts making it fail, or it starts failing due to database migrations then we?ll have to shift that job downstream and deal with the consequences of only ever finding upgrade bugs post-merge.
>> >
>> > It is well known that a Fast-Forward Upgrade (FFU) of OpenStack services is not supported upstream, so we can not expect any upstream jobs to reliability support this process. If/when there is broader support for enabling FFU support officially in OpenStack services, then we can reconsider this position.
>> >
>>
>> Hi Jesse,
>>
>> thanks for replying here too.
>>
>> As shaped by the discussions yesterday and for the benefit of others -
>> our current plan is to keep the c8 undercloud-ffu job and in fact that
>> will be the *only* job we will keep on C8 (if standalone ffu upgrade
>> becomes a thing then that will also be 8 only). At least, we'll make a
>> best effort to keep this and we can re-evaluate once we hit blocking
>> issues.
>>
>> In order to maintain this C8 gate we'll also need to maintain the
>> equivalent periodic version for the integration line. So we'll have a
>> C8 integration line running the undercloud-ffu job and possibly one
>> ovb job (TBD, likely featureset 1).
>>
>> To be clear, our plan is to remove *all* centos8 check/gate jobs,
>> except the undercloud-ffu. We are not planning to keep any 'base' set
>> of c8 jobs unless someone can make a case for their value.
>>
>> The tripleo-ci team will start implementing the removal of c8/wallaby
>> jobs once we switch to use c9 for the imports which should happen
>> within the next week or so.
>>
>> regards, marios
>>
>> > >  ii) Are we importing from Wallaby 8 or Wallaby 9? Currently it is 8
>> > > but this will soon switch.
>> > >
>> > > For the wallaby c8 'subset of jobs' e.g. multinode, vanilla standalone
>> > > (no scenarios? some subset of them?), undercloud-ffu, minor update.
>> > >
>> > > This is just to start the conversation so please reply if you have
>> > > thoughts or comments about any of the above.
>> > >
>> > > We are planning to discuss this in the coming tripleo-ci community
>> > > call this coming Tuesday at 1330 UTC - meeting link at [4] so please
>> > > join us if you can and would like to participate,
>> > >
>> > > regards, marios
>> > >
>> > > [1] https://review.opendev.org/q/topic:c8_teardown_master
>> > > [2] https://review.opendev.org/q/topic:c9_wallaby_gates
>> > > [3] https://etherpad.opendev.org/p/tripleoci-wallaby-centos-8-9
>> > > [4] https://meet.google.com/bqx-xwht-wky
>> > >
>> > >
>> >
>>
>>



From jpodivin at redhat.com  Wed Mar  2 08:07:33 2022
From: jpodivin at redhat.com (Jiri Podivin)
Date: Wed, 2 Mar 2022 09:07:33 +0100
Subject: [TripleO] centos9 jobs only for master, centos 8 & 9 for wallaby
In-Reply-To: <CAM51kHVFq6vUR-yNWeqnKhvECFNp2itXgKy_F30Jb+r8vW_ZVg@mail.gmail.com>
References: <CAM51kHVWBO07=crAXJ8ZpfA4b9A7w+YuFBG3N17dc=hU=k_e-A@mail.gmail.com>
 <32D116CA-5034-4557-BEDF-6D7E8C7FDD48@odyssey4.me>
 <CAM51kHWM4QqxNs9AFcr1NnR5RBfL2D4Q=PiGLo=WnpsQVYgeLw@mail.gmail.com>
 <CAD0_RgFE0JMjPRfUEuoShwnH7VtfxN4Fg-u13DH=j67tHW2YRw@mail.gmail.com>
 <CAM51kHVFq6vUR-yNWeqnKhvECFNp2itXgKy_F30Jb+r8vW_ZVg@mail.gmail.com>
Message-ID: <CAD0_RgGR5yKdDWiov95z40mWdOXuw0mLumtfy2HJgieg8dRt+w@mail.gmail.com>

Great,
Thanks for the clarification, it had me worried for a bit.

On Wed, Mar 2, 2022 at 9:05 AM Marios Andreou <marios at redhat.com> wrote:

> On Wed, Mar 2, 2022 at 9:44 AM Jiri Podivin <jpodivin at redhat.com> wrote:
> >
> > Hi,
> > Sorry I'm replying this late, but this line raised some questions for me:
> > > To be clear, our plan is to remove *all* centos8 check/gate jobs,
> >
> > It seems to imply that all centos8 jobs in both pipelines will be
> removed, across stable branches.
> > Does this mean up to and including train?
> > It was my understanding that everything older than wallaby will remain
> as it is.
> >
>
> This discussion is exclusively about wallaby - older stable branches
> will be unaffected.
>
>
>
>
>
> >
> > On Wed, Mar 2, 2022 at 8:04 AM Marios Andreou <marios at redhat.com> wrote:
> >>
> >> On Tue, Mar 1, 2022 at 5:03 PM Jesse Pretorius <jesse at odyssey4.me>
> wrote:
> >> >
> >> > Hi folks, response in-line.
> >> >
> >> > > On 24 Feb 2022, at 15:11, Marios Andreou <marios at redhat.com> wrote:
> >> > >
> >> > > Hello TripleO o/
> >> > >
> >> > > During the last period the tripleo-ci team has been working on
> getting
> >> > > tripleo CI jobs to run centos-9.
> >> > >
> >> > > On master branches across all TripleO repos we now run C9
> exclusively
> >> > > (since [1]).
> >> > >
> >> > > On Wallaby branches, after the work at [2] (in particular after
> >> > > https://review.opendev.org/c/openstack/tripleo-ci/+/830132 merges)
> we
> >> > > will run both C8 and C9 jobs. I started an etherpad at [3] thinking
> >> > > this would be a PTG topic, but I think we'll want to have this
> >> > > conversation way before then. There is a tripleo-heat-templates
> >> > > example in the etherpad that shows what we can expect from the job
> >> > > runs (note the exact jobs that run will vary per repo and even
> between
> >> > > changes depending on the files touched - but generally there will be
> >> > > duplication between 8 and 9 jobs).
> >> > >
> >> > > The current proposal is that we keep a minimal subset on C8 Wallaby,
> >> > > with C9 wallaby having the full set of jobs.
> >> > >
> >> > > Two factors that will affect our decisions are (there may be more?)
> >> > >
> >> > >  i) Upgrades requirements - are we supporting upgrading to Wallaby
> on
> >> > > 8? For example, the coming undercloud-upgrade-ffu job will be train
> 8
> >> > > to wallaby 8. In which case we definitely need to keep at least some
> >> > > subset of 8 jobs (and can't entertain the removal of 8 from Wallaby
> >> > > completely).
> >> >
> >> > I think trying to keep up with the moving target of 8-stream would be
> counterproductive given that we are pinned downstream to RHEL 8.4 for
> Train. We do have a pending patch to merge a job for
> 8-Stream/Train->8-Stream Wallaby for the Undercloud only, which would be
> nice to keep but if it becomes troublesome then I?d suggest we remove it.
> This job adds some value to us (and has added quite a bit already in
> preparing it and making it pass), but if 8-stream starts making it fail, or
> it starts failing due to database migrations then we?ll have to shift that
> job downstream and deal with the consequences of only ever finding upgrade
> bugs post-merge.
> >> >
> >> > It is well known that a Fast-Forward Upgrade (FFU) of OpenStack
> services is not supported upstream, so we can not expect any upstream jobs
> to reliability support this process. If/when there is broader support for
> enabling FFU support officially in OpenStack services, then we can
> reconsider this position.
> >> >
> >>
> >> Hi Jesse,
> >>
> >> thanks for replying here too.
> >>
> >> As shaped by the discussions yesterday and for the benefit of others -
> >> our current plan is to keep the c8 undercloud-ffu job and in fact that
> >> will be the *only* job we will keep on C8 (if standalone ffu upgrade
> >> becomes a thing then that will also be 8 only). At least, we'll make a
> >> best effort to keep this and we can re-evaluate once we hit blocking
> >> issues.
> >>
> >> In order to maintain this C8 gate we'll also need to maintain the
> >> equivalent periodic version for the integration line. So we'll have a
> >> C8 integration line running the undercloud-ffu job and possibly one
> >> ovb job (TBD, likely featureset 1).
> >>
> >> To be clear, our plan is to remove *all* centos8 check/gate jobs,
> >> except the undercloud-ffu. We are not planning to keep any 'base' set
> >> of c8 jobs unless someone can make a case for their value.
> >>
> >> The tripleo-ci team will start implementing the removal of c8/wallaby
> >> jobs once we switch to use c9 for the imports which should happen
> >> within the next week or so.
> >>
> >> regards, marios
> >>
> >> > >  ii) Are we importing from Wallaby 8 or Wallaby 9? Currently it is 8
> >> > > but this will soon switch.
> >> > >
> >> > > For the wallaby c8 'subset of jobs' e.g. multinode, vanilla
> standalone
> >> > > (no scenarios? some subset of them?), undercloud-ffu, minor update.
> >> > >
> >> > > This is just to start the conversation so please reply if you have
> >> > > thoughts or comments about any of the above.
> >> > >
> >> > > We are planning to discuss this in the coming tripleo-ci community
> >> > > call this coming Tuesday at 1330 UTC - meeting link at [4] so please
> >> > > join us if you can and would like to participate,
> >> > >
> >> > > regards, marios
> >> > >
> >> > > [1] https://review.opendev.org/q/topic:c8_teardown_master
> >> > > [2] https://review.opendev.org/q/topic:c9_wallaby_gates
> >> > > [3] https://etherpad.opendev.org/p/tripleoci-wallaby-centos-8-9
> >> > > [4] https://meet.google.com/bqx-xwht-wky
> >> > >
> >> > >
> >> >
> >>
> >>
>
> On Wed, Mar 2, 2022 at 9:44 AM Jiri Podivin <jpodivin at redhat.com> wrote:
> >
> > Hi,
> > Sorry I'm replying this late, but this line raised some questions for me:
> > > To be clear, our plan is to remove *all* centos8 check/gate jobs,
> >
> > It seems to imply that all centos8 jobs in both pipelines will be
> removed, across stable branches.
> > Does this mean up to and including train?
> > It was my understanding that everything older than wallaby will remain
> as it is.
> >
> >
> > On Wed, Mar 2, 2022 at 8:04 AM Marios Andreou <marios at redhat.com> wrote:
> >>
> >> On Tue, Mar 1, 2022 at 5:03 PM Jesse Pretorius <jesse at odyssey4.me>
> wrote:
> >> >
> >> > Hi folks, response in-line.
> >> >
> >> > > On 24 Feb 2022, at 15:11, Marios Andreou <marios at redhat.com> wrote:
> >> > >
> >> > > Hello TripleO o/
> >> > >
> >> > > During the last period the tripleo-ci team has been working on
> getting
> >> > > tripleo CI jobs to run centos-9.
> >> > >
> >> > > On master branches across all TripleO repos we now run C9
> exclusively
> >> > > (since [1]).
> >> > >
> >> > > On Wallaby branches, after the work at [2] (in particular after
> >> > > https://review.opendev.org/c/openstack/tripleo-ci/+/830132 merges)
> we
> >> > > will run both C8 and C9 jobs. I started an etherpad at [3] thinking
> >> > > this would be a PTG topic, but I think we'll want to have this
> >> > > conversation way before then. There is a tripleo-heat-templates
> >> > > example in the etherpad that shows what we can expect from the job
> >> > > runs (note the exact jobs that run will vary per repo and even
> between
> >> > > changes depending on the files touched - but generally there will be
> >> > > duplication between 8 and 9 jobs).
> >> > >
> >> > > The current proposal is that we keep a minimal subset on C8 Wallaby,
> >> > > with C9 wallaby having the full set of jobs.
> >> > >
> >> > > Two factors that will affect our decisions are (there may be more?)
> >> > >
> >> > >  i) Upgrades requirements - are we supporting upgrading to Wallaby
> on
> >> > > 8? For example, the coming undercloud-upgrade-ffu job will be train
> 8
> >> > > to wallaby 8. In which case we definitely need to keep at least some
> >> > > subset of 8 jobs (and can't entertain the removal of 8 from Wallaby
> >> > > completely).
> >> >
> >> > I think trying to keep up with the moving target of 8-stream would be
> counterproductive given that we are pinned downstream to RHEL 8.4 for
> Train. We do have a pending patch to merge a job for
> 8-Stream/Train->8-Stream Wallaby for the Undercloud only, which would be
> nice to keep but if it becomes troublesome then I?d suggest we remove it.
> This job adds some value to us (and has added quite a bit already in
> preparing it and making it pass), but if 8-stream starts making it fail, or
> it starts failing due to database migrations then we?ll have to shift that
> job downstream and deal with the consequences of only ever finding upgrade
> bugs post-merge.
> >> >
> >> > It is well known that a Fast-Forward Upgrade (FFU) of OpenStack
> services is not supported upstream, so we can not expect any upstream jobs
> to reliability support this process. If/when there is broader support for
> enabling FFU support officially in OpenStack services, then we can
> reconsider this position.
> >> >
> >>
> >> Hi Jesse,
> >>
> >> thanks for replying here too.
> >>
> >> As shaped by the discussions yesterday and for the benefit of others -
> >> our current plan is to keep the c8 undercloud-ffu job and in fact that
> >> will be the *only* job we will keep on C8 (if standalone ffu upgrade
> >> becomes a thing then that will also be 8 only). At least, we'll make a
> >> best effort to keep this and we can re-evaluate once we hit blocking
> >> issues.
> >>
> >> In order to maintain this C8 gate we'll also need to maintain the
> >> equivalent periodic version for the integration line. So we'll have a
> >> C8 integration line running the undercloud-ffu job and possibly one
> >> ovb job (TBD, likely featureset 1).
> >>
> >> To be clear, our plan is to remove *all* centos8 check/gate jobs,
> >> except the undercloud-ffu. We are not planning to keep any 'base' set
> >> of c8 jobs unless someone can make a case for their value.
> >>
> >> The tripleo-ci team will start implementing the removal of c8/wallaby
> >> jobs once we switch to use c9 for the imports which should happen
> >> within the next week or so.
> >>
> >> regards, marios
> >>
> >> > >  ii) Are we importing from Wallaby 8 or Wallaby 9? Currently it is 8
> >> > > but this will soon switch.
> >> > >
> >> > > For the wallaby c8 'subset of jobs' e.g. multinode, vanilla
> standalone
> >> > > (no scenarios? some subset of them?), undercloud-ffu, minor update.
> >> > >
> >> > > This is just to start the conversation so please reply if you have
> >> > > thoughts or comments about any of the above.
> >> > >
> >> > > We are planning to discuss this in the coming tripleo-ci community
> >> > > call this coming Tuesday at 1330 UTC - meeting link at [4] so please
> >> > > join us if you can and would like to participate,
> >> > >
> >> > > regards, marios
> >> > >
> >> > > [1] https://review.opendev.org/q/topic:c8_teardown_master
> >> > > [2] https://review.opendev.org/q/topic:c9_wallaby_gates
> >> > > [3] https://etherpad.opendev.org/p/tripleoci-wallaby-centos-8-9
> >> > > [4] https://meet.google.com/bqx-xwht-wky
> >> > >
> >> > >
> >> >
> >>
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220302/25f88ea1/attachment-0001.htm>

From mdemaced at redhat.com  Wed Mar  2 10:45:01 2022
From: mdemaced at redhat.com (Maysa De Macedo Souza)
Date: Wed, 2 Mar 2022 11:45:01 +0100
Subject: [release][requirements][oslo][kuryr][keystone] RFE request
In-Reply-To: <20220301205346.nbdx5yi6fbcifeks@mthode.org>
References: <116ca5d1-c8e3-d51b-dd98-3b2c444a06b7@est.tech>
 <20220301205346.nbdx5yi6fbcifeks@mthode.org>
Message-ID: <CAEn0wJXD3q50TxOnnV32q7Pzdn96T4fyHweo49qkzA+L+0LN8g@mail.gmail.com>

Hello,

Thanks for catching that. I just checked the Kuryr related patch.


On Tue, Mar 1, 2022 at 9:58 PM Matthew Thode <mthode at mthode.org> wrote:

> On 22-03-01 21:43:35, El?d Ill?s wrote:
> > Hi,
> >
> > It turned out that kuryr [1] and keystoneauth [2] deliverables were
> missed
> > at non-client libraries final release period. So we need to release them
> now
> > and request Requirement Freeze Exception for them. (PTLs / release
> liaisons
> > of kuryr and keystoneauth: please review the patches [1][2] as soon as
> > possible)
> >
> > Also I want to mention here oslo.context as well, to formally include it
> to
> > RFE. (It seems versions >=4.0.0 break things, see thread [3] and [4].)
> >
> >
> > [1] https://review.opendev.org/c/openstack/releases/+/831025
> > [2] https://review.opendev.org/c/openstack/releases/+/831024
> > [3]
> http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027455.html
> > [4]
> >
> http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027480.html
> >
> >
> > El?d
> >
>
> Requirements is ok with these and approves.  Thanks for the formal email
> :D
>
> --
> Matthew Thode
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220302/57a0d8b3/attachment.htm>

From zigo at debian.org  Wed Mar  2 11:16:44 2022
From: zigo at debian.org (Thomas Goirand)
Date: Wed, 2 Mar 2022 12:16:44 +0100
Subject: [horizon][customization]
In-Reply-To: <3aa4a3df-fab3-ccc0-5bc3-821cdb80ce67@ovhcloud.com>
References: <3aa4a3df-fab3-ccc0-5bc3-821cdb80ce67@ovhcloud.com>
Message-ID: <375340aa-227f-8fc2-77f6-c147bf247b98@debian.org>

On 2/28/22 09:45, Mathilde Hermet wrote:
> Hello Openstack team,
> 
> 
> I'm currently working on customizing the Horizon (xena) dashboard to use 
> the OVHcloud assets: logo.svg and logo-splash.svg.
> 
> I've been following this documentation 
> https://docs.openstack.org/horizon/latest/configuration/themes.html
> 
> I added the ovhcloud theme in 
> horizon/openstack_dashboard/local/local_settings.py in AVAILABLE_THEMES,
> 
> I created the subdir ovhcloud in horizon/openstack_dashboard/themes and 
> I created a ovhcloud/img with logo.svg and logo-splash.svg in it.
> 
> I put a _variables.scss and a _styles.scss in /themes/ovhcloud/
> 
> Then I executed python manage.py collectstatic
> 
> It put all the files in horizon-sources/horizon.../static/themes/ovhcloud
> 
> 
> But then when trying to connect with the session cookie 
> theme="ovhcloud", I have a 500 error.
> 
> i don't think it comes from images because i've been puting it in 
> /horizon-souurces/horizon.../static/dashbaord.img and they were 
> displayed correctly.
> 
> 
> Do you have any idea about the misconfiguration I've done ?
> 
> 
> Best regards,
> 
> 
> Mathilde Hermet

Hi Mathilde,

I'm not sure where your error is, but if you want, you can have a look 
at for exemple:
https://packages.debian.org/openstack-dashboard-debian-theme

which has it's git over here:
https://salsa.debian.org/openstack-team/debian/openstack-dashboard-debian-theme

I hope this helps,

Cheers,

Thomas Goirand (zigo)


From mrunge at matthias-runge.de  Wed Mar  2 12:37:15 2022
From: mrunge at matthias-runge.de (Matthias Runge)
Date: Wed, 2 Mar 2022 13:37:15 +0100
Subject: [horizon][customization]
In-Reply-To: <375340aa-227f-8fc2-77f6-c147bf247b98@debian.org>
References: <3aa4a3df-fab3-ccc0-5bc3-821cdb80ce67@ovhcloud.com>
 <375340aa-227f-8fc2-77f6-c147bf247b98@debian.org>
Message-ID: <edb18c4f-6880-954d-e07a-5ba30beb6a92@matthias-runge.de>

On 3/2/22 12:16, Thomas Goirand wrote:

>>
>>
>> Do you have any idea about the misconfiguration I've done ?
>>
>>
>> Best regards,
>>
>>
>> Mathilde Hermet
> 
> Hi Mathilde,
> 
> I'm not sure where your error is, but if you want, you can have a look 
> at for exemple:
> https://packages.debian.org/openstack-dashboard-debian-theme
> 
> which has it's git over here:
> https://salsa.debian.org/openstack-team/debian/openstack-dashboard-debian-theme 
> 
> 
> I hope this helps,
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 
a 500 error is always a server error and should be logged in http error 
log. I'd take a look at the error log in the next step.

Matthias


From johfulto at redhat.com  Wed Mar  2 13:09:36 2022
From: johfulto at redhat.com (John Fulton)
Date: Wed, 2 Mar 2022 08:09:36 -0500
Subject: [TripleO] centos9 jobs only for master, centos 8 & 9 for wallaby
In-Reply-To: <CAD0_RgGR5yKdDWiov95z40mWdOXuw0mLumtfy2HJgieg8dRt+w@mail.gmail.com>
References: <CAM51kHVWBO07=crAXJ8ZpfA4b9A7w+YuFBG3N17dc=hU=k_e-A@mail.gmail.com>
 <32D116CA-5034-4557-BEDF-6D7E8C7FDD48@odyssey4.me>
 <CAM51kHWM4QqxNs9AFcr1NnR5RBfL2D4Q=PiGLo=WnpsQVYgeLw@mail.gmail.com>
 <CAD0_RgFE0JMjPRfUEuoShwnH7VtfxN4Fg-u13DH=j67tHW2YRw@mail.gmail.com>
 <CAM51kHVFq6vUR-yNWeqnKhvECFNp2itXgKy_F30Jb+r8vW_ZVg@mail.gmail.com>
 <CAD0_RgGR5yKdDWiov95z40mWdOXuw0mLumtfy2HJgieg8dRt+w@mail.gmail.com>
Message-ID: <CAE66OMApQQe7MGqbPSto6=72=d_OFxO8yPq+rWkUuEX5j5CfUw@mail.gmail.com>

Just wanted to add that for Ceph integration in TripleO, these are the
important Ceph jobs which run when THT is patched in the main branch:

tripleo-ci-centos-9-scenario001-standalone
tripleo-ci-centos-9-scenario004-standalone

If the Wallaby branch only had centos-9 versions of the above and no
centos-8 versions of the above, then I don't see that as a problem.

  John

On Wed, Mar 2, 2022 at 3:08 AM Jiri Podivin <jpodivin at redhat.com> wrote:

> Great,
> Thanks for the clarification, it had me worried for a bit.
>
> On Wed, Mar 2, 2022 at 9:05 AM Marios Andreou <marios at redhat.com> wrote:
>
>> On Wed, Mar 2, 2022 at 9:44 AM Jiri Podivin <jpodivin at redhat.com> wrote:
>> >
>> > Hi,
>> > Sorry I'm replying this late, but this line raised some questions for
>> me:
>> > > To be clear, our plan is to remove *all* centos8 check/gate jobs,
>> >
>> > It seems to imply that all centos8 jobs in both pipelines will be
>> removed, across stable branches.
>> > Does this mean up to and including train?
>> > It was my understanding that everything older than wallaby will remain
>> as it is.
>> >
>>
>> This discussion is exclusively about wallaby - older stable branches
>> will be unaffected.
>>
>>
>>
>>
>>
>> >
>> > On Wed, Mar 2, 2022 at 8:04 AM Marios Andreou <marios at redhat.com>
>> wrote:
>> >>
>> >> On Tue, Mar 1, 2022 at 5:03 PM Jesse Pretorius <jesse at odyssey4.me>
>> wrote:
>> >> >
>> >> > Hi folks, response in-line.
>> >> >
>> >> > > On 24 Feb 2022, at 15:11, Marios Andreou <marios at redhat.com>
>> wrote:
>> >> > >
>> >> > > Hello TripleO o/
>> >> > >
>> >> > > During the last period the tripleo-ci team has been working on
>> getting
>> >> > > tripleo CI jobs to run centos-9.
>> >> > >
>> >> > > On master branches across all TripleO repos we now run C9
>> exclusively
>> >> > > (since [1]).
>> >> > >
>> >> > > On Wallaby branches, after the work at [2] (in particular after
>> >> > > https://review.opendev.org/c/openstack/tripleo-ci/+/830132
>> merges) we
>> >> > > will run both C8 and C9 jobs. I started an etherpad at [3] thinking
>> >> > > this would be a PTG topic, but I think we'll want to have this
>> >> > > conversation way before then. There is a tripleo-heat-templates
>> >> > > example in the etherpad that shows what we can expect from the job
>> >> > > runs (note the exact jobs that run will vary per repo and even
>> between
>> >> > > changes depending on the files touched - but generally there will
>> be
>> >> > > duplication between 8 and 9 jobs).
>> >> > >
>> >> > > The current proposal is that we keep a minimal subset on C8
>> Wallaby,
>> >> > > with C9 wallaby having the full set of jobs.
>> >> > >
>> >> > > Two factors that will affect our decisions are (there may be more?)
>> >> > >
>> >> > >  i) Upgrades requirements - are we supporting upgrading to Wallaby
>> on
>> >> > > 8? For example, the coming undercloud-upgrade-ffu job will be
>> train 8
>> >> > > to wallaby 8. In which case we definitely need to keep at least
>> some
>> >> > > subset of 8 jobs (and can't entertain the removal of 8 from Wallaby
>> >> > > completely).
>> >> >
>> >> > I think trying to keep up with the moving target of 8-stream would
>> be counterproductive given that we are pinned downstream to RHEL 8.4 for
>> Train. We do have a pending patch to merge a job for
>> 8-Stream/Train->8-Stream Wallaby for the Undercloud only, which would be
>> nice to keep but if it becomes troublesome then I?d suggest we remove it.
>> This job adds some value to us (and has added quite a bit already in
>> preparing it and making it pass), but if 8-stream starts making it fail, or
>> it starts failing due to database migrations then we?ll have to shift that
>> job downstream and deal with the consequences of only ever finding upgrade
>> bugs post-merge.
>> >> >
>> >> > It is well known that a Fast-Forward Upgrade (FFU) of OpenStack
>> services is not supported upstream, so we can not expect any upstream jobs
>> to reliability support this process. If/when there is broader support for
>> enabling FFU support officially in OpenStack services, then we can
>> reconsider this position.
>> >> >
>> >>
>> >> Hi Jesse,
>> >>
>> >> thanks for replying here too.
>> >>
>> >> As shaped by the discussions yesterday and for the benefit of others -
>> >> our current plan is to keep the c8 undercloud-ffu job and in fact that
>> >> will be the *only* job we will keep on C8 (if standalone ffu upgrade
>> >> becomes a thing then that will also be 8 only). At least, we'll make a
>> >> best effort to keep this and we can re-evaluate once we hit blocking
>> >> issues.
>> >>
>> >> In order to maintain this C8 gate we'll also need to maintain the
>> >> equivalent periodic version for the integration line. So we'll have a
>> >> C8 integration line running the undercloud-ffu job and possibly one
>> >> ovb job (TBD, likely featureset 1).
>> >>
>> >> To be clear, our plan is to remove *all* centos8 check/gate jobs,
>> >> except the undercloud-ffu. We are not planning to keep any 'base' set
>> >> of c8 jobs unless someone can make a case for their value.
>> >>
>> >> The tripleo-ci team will start implementing the removal of c8/wallaby
>> >> jobs once we switch to use c9 for the imports which should happen
>> >> within the next week or so.
>> >>
>> >> regards, marios
>> >>
>> >> > >  ii) Are we importing from Wallaby 8 or Wallaby 9? Currently it is
>> 8
>> >> > > but this will soon switch.
>> >> > >
>> >> > > For the wallaby c8 'subset of jobs' e.g. multinode, vanilla
>> standalone
>> >> > > (no scenarios? some subset of them?), undercloud-ffu, minor update.
>> >> > >
>> >> > > This is just to start the conversation so please reply if you have
>> >> > > thoughts or comments about any of the above.
>> >> > >
>> >> > > We are planning to discuss this in the coming tripleo-ci community
>> >> > > call this coming Tuesday at 1330 UTC - meeting link at [4] so
>> please
>> >> > > join us if you can and would like to participate,
>> >> > >
>> >> > > regards, marios
>> >> > >
>> >> > > [1] https://review.opendev.org/q/topic:c8_teardown_master
>> >> > > [2] https://review.opendev.org/q/topic:c9_wallaby_gates
>> >> > > [3] https://etherpad.opendev.org/p/tripleoci-wallaby-centos-8-9
>> >> > > [4] https://meet.google.com/bqx-xwht-wky
>> >> > >
>> >> > >
>> >> >
>> >>
>> >>
>>
>> On Wed, Mar 2, 2022 at 9:44 AM Jiri Podivin <jpodivin at redhat.com> wrote:
>> >
>> > Hi,
>> > Sorry I'm replying this late, but this line raised some questions for
>> me:
>> > > To be clear, our plan is to remove *all* centos8 check/gate jobs,
>> >
>> > It seems to imply that all centos8 jobs in both pipelines will be
>> removed, across stable branches.
>> > Does this mean up to and including train?
>> > It was my understanding that everything older than wallaby will remain
>> as it is.
>> >
>> >
>> > On Wed, Mar 2, 2022 at 8:04 AM Marios Andreou <marios at redhat.com>
>> wrote:
>> >>
>> >> On Tue, Mar 1, 2022 at 5:03 PM Jesse Pretorius <jesse at odyssey4.me>
>> wrote:
>> >> >
>> >> > Hi folks, response in-line.
>> >> >
>> >> > > On 24 Feb 2022, at 15:11, Marios Andreou <marios at redhat.com>
>> wrote:
>> >> > >
>> >> > > Hello TripleO o/
>> >> > >
>> >> > > During the last period the tripleo-ci team has been working on
>> getting
>> >> > > tripleo CI jobs to run centos-9.
>> >> > >
>> >> > > On master branches across all TripleO repos we now run C9
>> exclusively
>> >> > > (since [1]).
>> >> > >
>> >> > > On Wallaby branches, after the work at [2] (in particular after
>> >> > > https://review.opendev.org/c/openstack/tripleo-ci/+/830132
>> merges) we
>> >> > > will run both C8 and C9 jobs. I started an etherpad at [3] thinking
>> >> > > this would be a PTG topic, but I think we'll want to have this
>> >> > > conversation way before then. There is a tripleo-heat-templates
>> >> > > example in the etherpad that shows what we can expect from the job
>> >> > > runs (note the exact jobs that run will vary per repo and even
>> between
>> >> > > changes depending on the files touched - but generally there will
>> be
>> >> > > duplication between 8 and 9 jobs).
>> >> > >
>> >> > > The current proposal is that we keep a minimal subset on C8
>> Wallaby,
>> >> > > with C9 wallaby having the full set of jobs.
>> >> > >
>> >> > > Two factors that will affect our decisions are (there may be more?)
>> >> > >
>> >> > >  i) Upgrades requirements - are we supporting upgrading to Wallaby
>> on
>> >> > > 8? For example, the coming undercloud-upgrade-ffu job will be
>> train 8
>> >> > > to wallaby 8. In which case we definitely need to keep at least
>> some
>> >> > > subset of 8 jobs (and can't entertain the removal of 8 from Wallaby
>> >> > > completely).
>> >> >
>> >> > I think trying to keep up with the moving target of 8-stream would
>> be counterproductive given that we are pinned downstream to RHEL 8.4 for
>> Train. We do have a pending patch to merge a job for
>> 8-Stream/Train->8-Stream Wallaby for the Undercloud only, which would be
>> nice to keep but if it becomes troublesome then I?d suggest we remove it.
>> This job adds some value to us (and has added quite a bit already in
>> preparing it and making it pass), but if 8-stream starts making it fail, or
>> it starts failing due to database migrations then we?ll have to shift that
>> job downstream and deal with the consequences of only ever finding upgrade
>> bugs post-merge.
>> >> >
>> >> > It is well known that a Fast-Forward Upgrade (FFU) of OpenStack
>> services is not supported upstream, so we can not expect any upstream jobs
>> to reliability support this process. If/when there is broader support for
>> enabling FFU support officially in OpenStack services, then we can
>> reconsider this position.
>> >> >
>> >>
>> >> Hi Jesse,
>> >>
>> >> thanks for replying here too.
>> >>
>> >> As shaped by the discussions yesterday and for the benefit of others -
>> >> our current plan is to keep the c8 undercloud-ffu job and in fact that
>> >> will be the *only* job we will keep on C8 (if standalone ffu upgrade
>> >> becomes a thing then that will also be 8 only). At least, we'll make a
>> >> best effort to keep this and we can re-evaluate once we hit blocking
>> >> issues.
>> >>
>> >> In order to maintain this C8 gate we'll also need to maintain the
>> >> equivalent periodic version for the integration line. So we'll have a
>> >> C8 integration line running the undercloud-ffu job and possibly one
>> >> ovb job (TBD, likely featureset 1).
>> >>
>> >> To be clear, our plan is to remove *all* centos8 check/gate jobs,
>> >> except the undercloud-ffu. We are not planning to keep any 'base' set
>> >> of c8 jobs unless someone can make a case for their value.
>> >>
>> >> The tripleo-ci team will start implementing the removal of c8/wallaby
>> >> jobs once we switch to use c9 for the imports which should happen
>> >> within the next week or so.
>> >>
>> >> regards, marios
>> >>
>> >> > >  ii) Are we importing from Wallaby 8 or Wallaby 9? Currently it is
>> 8
>> >> > > but this will soon switch.
>> >> > >
>> >> > > For the wallaby c8 'subset of jobs' e.g. multinode, vanilla
>> standalone
>> >> > > (no scenarios? some subset of them?), undercloud-ffu, minor update.
>> >> > >
>> >> > > This is just to start the conversation so please reply if you have
>> >> > > thoughts or comments about any of the above.
>> >> > >
>> >> > > We are planning to discuss this in the coming tripleo-ci community
>> >> > > call this coming Tuesday at 1330 UTC - meeting link at [4] so
>> please
>> >> > > join us if you can and would like to participate,
>> >> > >
>> >> > > regards, marios
>> >> > >
>> >> > > [1] https://review.opendev.org/q/topic:c8_teardown_master
>> >> > > [2] https://review.opendev.org/q/topic:c9_wallaby_gates
>> >> > > [3] https://etherpad.opendev.org/p/tripleoci-wallaby-centos-8-9
>> >> > > [4] https://meet.google.com/bqx-xwht-wky
>> >> > >
>> >> > >
>> >> >
>> >>
>> >>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220302/804072a4/attachment-0001.htm>

From marios at redhat.com  Wed Mar  2 13:20:47 2022
From: marios at redhat.com (Marios Andreou)
Date: Wed, 2 Mar 2022 15:20:47 +0200
Subject: [TripleO] centos9 jobs only for master, centos 8 & 9 for wallaby
In-Reply-To: <CAE66OMApQQe7MGqbPSto6=72=d_OFxO8yPq+rWkUuEX5j5CfUw@mail.gmail.com>
References: <CAM51kHVWBO07=crAXJ8ZpfA4b9A7w+YuFBG3N17dc=hU=k_e-A@mail.gmail.com>
 <32D116CA-5034-4557-BEDF-6D7E8C7FDD48@odyssey4.me>
 <CAM51kHWM4QqxNs9AFcr1NnR5RBfL2D4Q=PiGLo=WnpsQVYgeLw@mail.gmail.com>
 <CAD0_RgFE0JMjPRfUEuoShwnH7VtfxN4Fg-u13DH=j67tHW2YRw@mail.gmail.com>
 <CAM51kHVFq6vUR-yNWeqnKhvECFNp2itXgKy_F30Jb+r8vW_ZVg@mail.gmail.com>
 <CAD0_RgGR5yKdDWiov95z40mWdOXuw0mLumtfy2HJgieg8dRt+w@mail.gmail.com>
 <CAE66OMApQQe7MGqbPSto6=72=d_OFxO8yPq+rWkUuEX5j5CfUw@mail.gmail.com>
Message-ID: <CAM51kHXht1nRD2SU82sc2D=W9DqPveE=PCpqLTZeHEyp14O00A@mail.gmail.com>

On Wed, Mar 2, 2022 at 3:09 PM John Fulton <johfulto at redhat.com> wrote:
>
> Just wanted to add that for Ceph integration in TripleO, these are the important Ceph jobs which run when THT is patched in the main branch:
>
> tripleo-ci-centos-9-scenario001-standalone
> tripleo-ci-centos-9-scenario004-standalone
>
> If the Wallaby branch only had centos-9 versions of the above and no centos-8 versions of the above, then I don't see that as a problem.
>

ack thanks for joining the tripleo-ci community call yesterday and for
confirming here

Yes we will continue to have the centos-9 versions of those jobs
triggering as before (i.e. same files: matches etc)

regards, marios

>   John
>
> On Wed, Mar 2, 2022 at 3:08 AM Jiri Podivin <jpodivin at redhat.com> wrote:
>>
>> Great,
>> Thanks for the clarification, it had me worried for a bit.
>>
>> On Wed, Mar 2, 2022 at 9:05 AM Marios Andreou <marios at redhat.com> wrote:
>>>
>>> On Wed, Mar 2, 2022 at 9:44 AM Jiri Podivin <jpodivin at redhat.com> wrote:
>>> >
>>> > Hi,
>>> > Sorry I'm replying this late, but this line raised some questions for me:
>>> > > To be clear, our plan is to remove *all* centos8 check/gate jobs,
>>> >
>>> > It seems to imply that all centos8 jobs in both pipelines will be removed, across stable branches.
>>> > Does this mean up to and including train?
>>> > It was my understanding that everything older than wallaby will remain as it is.
>>> >
>>>
>>> This discussion is exclusively about wallaby - older stable branches
>>> will be unaffected.
>>>
>>>
>>>
>>>
>>>
>>> >
>>> > On Wed, Mar 2, 2022 at 8:04 AM Marios Andreou <marios at redhat.com> wrote:
>>> >>
>>> >> On Tue, Mar 1, 2022 at 5:03 PM Jesse Pretorius <jesse at odyssey4.me> wrote:
>>> >> >
>>> >> > Hi folks, response in-line.
>>> >> >
>>> >> > > On 24 Feb 2022, at 15:11, Marios Andreou <marios at redhat.com> wrote:
>>> >> > >
>>> >> > > Hello TripleO o/
>>> >> > >
>>> >> > > During the last period the tripleo-ci team has been working on getting
>>> >> > > tripleo CI jobs to run centos-9.
>>> >> > >
>>> >> > > On master branches across all TripleO repos we now run C9 exclusively
>>> >> > > (since [1]).
>>> >> > >
>>> >> > > On Wallaby branches, after the work at [2] (in particular after
>>> >> > > https://review.opendev.org/c/openstack/tripleo-ci/+/830132 merges) we
>>> >> > > will run both C8 and C9 jobs. I started an etherpad at [3] thinking
>>> >> > > this would be a PTG topic, but I think we'll want to have this
>>> >> > > conversation way before then. There is a tripleo-heat-templates
>>> >> > > example in the etherpad that shows what we can expect from the job
>>> >> > > runs (note the exact jobs that run will vary per repo and even between
>>> >> > > changes depending on the files touched - but generally there will be
>>> >> > > duplication between 8 and 9 jobs).
>>> >> > >
>>> >> > > The current proposal is that we keep a minimal subset on C8 Wallaby,
>>> >> > > with C9 wallaby having the full set of jobs.
>>> >> > >
>>> >> > > Two factors that will affect our decisions are (there may be more?)
>>> >> > >
>>> >> > >  i) Upgrades requirements - are we supporting upgrading to Wallaby on
>>> >> > > 8? For example, the coming undercloud-upgrade-ffu job will be train 8
>>> >> > > to wallaby 8. In which case we definitely need to keep at least some
>>> >> > > subset of 8 jobs (and can't entertain the removal of 8 from Wallaby
>>> >> > > completely).
>>> >> >
>>> >> > I think trying to keep up with the moving target of 8-stream would be counterproductive given that we are pinned downstream to RHEL 8.4 for Train. We do have a pending patch to merge a job for 8-Stream/Train->8-Stream Wallaby for the Undercloud only, which would be nice to keep but if it becomes troublesome then I?d suggest we remove it. This job adds some value to us (and has added quite a bit already in preparing it and making it pass), but if 8-stream starts making it fail, or it starts failing due to database migrations then we?ll have to shift that job downstream and deal with the consequences of only ever finding upgrade bugs post-merge.
>>> >> >
>>> >> > It is well known that a Fast-Forward Upgrade (FFU) of OpenStack services is not supported upstream, so we can not expect any upstream jobs to reliability support this process. If/when there is broader support for enabling FFU support officially in OpenStack services, then we can reconsider this position.
>>> >> >
>>> >>
>>> >> Hi Jesse,
>>> >>
>>> >> thanks for replying here too.
>>> >>
>>> >> As shaped by the discussions yesterday and for the benefit of others -
>>> >> our current plan is to keep the c8 undercloud-ffu job and in fact that
>>> >> will be the *only* job we will keep on C8 (if standalone ffu upgrade
>>> >> becomes a thing then that will also be 8 only). At least, we'll make a
>>> >> best effort to keep this and we can re-evaluate once we hit blocking
>>> >> issues.
>>> >>
>>> >> In order to maintain this C8 gate we'll also need to maintain the
>>> >> equivalent periodic version for the integration line. So we'll have a
>>> >> C8 integration line running the undercloud-ffu job and possibly one
>>> >> ovb job (TBD, likely featureset 1).
>>> >>
>>> >> To be clear, our plan is to remove *all* centos8 check/gate jobs,
>>> >> except the undercloud-ffu. We are not planning to keep any 'base' set
>>> >> of c8 jobs unless someone can make a case for their value.
>>> >>
>>> >> The tripleo-ci team will start implementing the removal of c8/wallaby
>>> >> jobs once we switch to use c9 for the imports which should happen
>>> >> within the next week or so.
>>> >>
>>> >> regards, marios
>>> >>
>>> >> > >  ii) Are we importing from Wallaby 8 or Wallaby 9? Currently it is 8
>>> >> > > but this will soon switch.
>>> >> > >
>>> >> > > For the wallaby c8 'subset of jobs' e.g. multinode, vanilla standalone
>>> >> > > (no scenarios? some subset of them?), undercloud-ffu, minor update.
>>> >> > >
>>> >> > > This is just to start the conversation so please reply if you have
>>> >> > > thoughts or comments about any of the above.
>>> >> > >
>>> >> > > We are planning to discuss this in the coming tripleo-ci community
>>> >> > > call this coming Tuesday at 1330 UTC - meeting link at [4] so please
>>> >> > > join us if you can and would like to participate,
>>> >> > >
>>> >> > > regards, marios
>>> >> > >
>>> >> > > [1] https://review.opendev.org/q/topic:c8_teardown_master
>>> >> > > [2] https://review.opendev.org/q/topic:c9_wallaby_gates
>>> >> > > [3] https://etherpad.opendev.org/p/tripleoci-wallaby-centos-8-9
>>> >> > > [4] https://meet.google.com/bqx-xwht-wky
>>> >> > >
>>> >> > >
>>> >> >
>>> >>
>>> >>
>>>
>>> On Wed, Mar 2, 2022 at 9:44 AM Jiri Podivin <jpodivin at redhat.com> wrote:
>>> >
>>> > Hi,
>>> > Sorry I'm replying this late, but this line raised some questions for me:
>>> > > To be clear, our plan is to remove *all* centos8 check/gate jobs,
>>> >
>>> > It seems to imply that all centos8 jobs in both pipelines will be removed, across stable branches.
>>> > Does this mean up to and including train?
>>> > It was my understanding that everything older than wallaby will remain as it is.
>>> >
>>> >
>>> > On Wed, Mar 2, 2022 at 8:04 AM Marios Andreou <marios at redhat.com> wrote:
>>> >>
>>> >> On Tue, Mar 1, 2022 at 5:03 PM Jesse Pretorius <jesse at odyssey4.me> wrote:
>>> >> >
>>> >> > Hi folks, response in-line.
>>> >> >
>>> >> > > On 24 Feb 2022, at 15:11, Marios Andreou <marios at redhat.com> wrote:
>>> >> > >
>>> >> > > Hello TripleO o/
>>> >> > >
>>> >> > > During the last period the tripleo-ci team has been working on getting
>>> >> > > tripleo CI jobs to run centos-9.
>>> >> > >
>>> >> > > On master branches across all TripleO repos we now run C9 exclusively
>>> >> > > (since [1]).
>>> >> > >
>>> >> > > On Wallaby branches, after the work at [2] (in particular after
>>> >> > > https://review.opendev.org/c/openstack/tripleo-ci/+/830132 merges) we
>>> >> > > will run both C8 and C9 jobs. I started an etherpad at [3] thinking
>>> >> > > this would be a PTG topic, but I think we'll want to have this
>>> >> > > conversation way before then. There is a tripleo-heat-templates
>>> >> > > example in the etherpad that shows what we can expect from the job
>>> >> > > runs (note the exact jobs that run will vary per repo and even between
>>> >> > > changes depending on the files touched - but generally there will be
>>> >> > > duplication between 8 and 9 jobs).
>>> >> > >
>>> >> > > The current proposal is that we keep a minimal subset on C8 Wallaby,
>>> >> > > with C9 wallaby having the full set of jobs.
>>> >> > >
>>> >> > > Two factors that will affect our decisions are (there may be more?)
>>> >> > >
>>> >> > >  i) Upgrades requirements - are we supporting upgrading to Wallaby on
>>> >> > > 8? For example, the coming undercloud-upgrade-ffu job will be train 8
>>> >> > > to wallaby 8. In which case we definitely need to keep at least some
>>> >> > > subset of 8 jobs (and can't entertain the removal of 8 from Wallaby
>>> >> > > completely).
>>> >> >
>>> >> > I think trying to keep up with the moving target of 8-stream would be counterproductive given that we are pinned downstream to RHEL 8.4 for Train. We do have a pending patch to merge a job for 8-Stream/Train->8-Stream Wallaby for the Undercloud only, which would be nice to keep but if it becomes troublesome then I?d suggest we remove it. This job adds some value to us (and has added quite a bit already in preparing it and making it pass), but if 8-stream starts making it fail, or it starts failing due to database migrations then we?ll have to shift that job downstream and deal with the consequences of only ever finding upgrade bugs post-merge.
>>> >> >
>>> >> > It is well known that a Fast-Forward Upgrade (FFU) of OpenStack services is not supported upstream, so we can not expect any upstream jobs to reliability support this process. If/when there is broader support for enabling FFU support officially in OpenStack services, then we can reconsider this position.
>>> >> >
>>> >>
>>> >> Hi Jesse,
>>> >>
>>> >> thanks for replying here too.
>>> >>
>>> >> As shaped by the discussions yesterday and for the benefit of others -
>>> >> our current plan is to keep the c8 undercloud-ffu job and in fact that
>>> >> will be the *only* job we will keep on C8 (if standalone ffu upgrade
>>> >> becomes a thing then that will also be 8 only). At least, we'll make a
>>> >> best effort to keep this and we can re-evaluate once we hit blocking
>>> >> issues.
>>> >>
>>> >> In order to maintain this C8 gate we'll also need to maintain the
>>> >> equivalent periodic version for the integration line. So we'll have a
>>> >> C8 integration line running the undercloud-ffu job and possibly one
>>> >> ovb job (TBD, likely featureset 1).
>>> >>
>>> >> To be clear, our plan is to remove *all* centos8 check/gate jobs,
>>> >> except the undercloud-ffu. We are not planning to keep any 'base' set
>>> >> of c8 jobs unless someone can make a case for their value.
>>> >>
>>> >> The tripleo-ci team will start implementing the removal of c8/wallaby
>>> >> jobs once we switch to use c9 for the imports which should happen
>>> >> within the next week or so.
>>> >>
>>> >> regards, marios
>>> >>
>>> >> > >  ii) Are we importing from Wallaby 8 or Wallaby 9? Currently it is 8
>>> >> > > but this will soon switch.
>>> >> > >
>>> >> > > For the wallaby c8 'subset of jobs' e.g. multinode, vanilla standalone
>>> >> > > (no scenarios? some subset of them?), undercloud-ffu, minor update.
>>> >> > >
>>> >> > > This is just to start the conversation so please reply if you have
>>> >> > > thoughts or comments about any of the above.
>>> >> > >
>>> >> > > We are planning to discuss this in the coming tripleo-ci community
>>> >> > > call this coming Tuesday at 1330 UTC - meeting link at [4] so please
>>> >> > > join us if you can and would like to participate,
>>> >> > >
>>> >> > > regards, marios
>>> >> > >
>>> >> > > [1] https://review.opendev.org/q/topic:c8_teardown_master
>>> >> > > [2] https://review.opendev.org/q/topic:c9_wallaby_gates
>>> >> > > [3] https://etherpad.opendev.org/p/tripleoci-wallaby-centos-8-9
>>> >> > > [4] https://meet.google.com/bqx-xwht-wky
>>> >> > >
>>> >> > >
>>> >> >
>>> >>
>>> >>
>>>



From senrique at redhat.com  Wed Mar  2 13:39:52 2022
From: senrique at redhat.com (Sofia Enriquez)
Date: Wed, 2 Mar 2022 10:39:52 -0300
Subject: [cinder] Bug deputy report for week of 03-02-2022
Message-ID: <CANtmtpEJYu9Xwdtkr5DqgOa+SEHY_6fvnyH0NNKV3sRDq4i5Kw@mail.gmail.com>

This is a bug report from 02-23-2022 to 03-02-2022.
Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting
-----------------------------------------------------------------------------------------
Low

   - https://bugs.launchpad.net/cinder/+bug/1962221 "[lightos] Compression
   handling in lightos driver while default compression enabled." Fix proposed
   to master.

Incomplete

   - https://bugs.launchpad.net/cinder/+bug/1962607 "IndexError when
   creating Backups." Fix proposed to master.

Cheers
-- 

Sof?a Enriquez

she/her

Software Engineer

Red Hat PnT <https://www.redhat.com>

IRC: @enriquetaso
@RedHat <https://twitter.com/redhat>   Red Hat
<https://www.linkedin.com/company/red-hat>  Red Hat
<https://www.facebook.com/RedHatInc>
<https://www.redhat.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220302/1b485cf9/attachment.htm>

From elod.illes at est.tech  Wed Mar  2 14:50:51 2022
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Wed, 2 Mar 2022 15:50:51 +0100
Subject: [QA][OpenStackSDK][release] Cycle With Intermediary without recent
 deliverables
Message-ID: <a9d3acc2-5d1a-8aff-dc3a-0a632a1b0067@est.tech>

Hi,

Quick reminder that for deliverables following the cycle-with-intermediary
model, the release team will use the latest Yoga release available on
release week.

The following deliverables have done a Yoga release, but it was not
refreshed in the last two months:

  tempest
  patrole (this was not yet released at all in Yoga)
  python-openstackclient (I remember that openstacksdk cannot do another
    release in Yoga due to issues on master branch. Is this also valid for
    python-openstackclient?)

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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220302/f4c80390/attachment-0001.htm>

From beagles at redhat.com  Wed Mar  2 14:59:18 2022
From: beagles at redhat.com (Brent Eagles)
Date: Wed, 2 Mar 2022 11:29:18 -0330
Subject: [tripleo] Dynamically generating firewall rules for the haproxy host
 on behalf of a deployed service
Message-ID: <Yh+GRquoFNNu34fu@knife.localdomain>

Hi all,

Designate has a requirement that appears to be a first for TripleO. It
needs to deploy miniDNS instances on the internal network but each are
accessible from the public network so external bind instances can sync
with them. This is done by mapping port numbers on the VIP to each
miniDNS instances [1] e.g.

 10.0.0.5:16000        --> 172.16.2.184:5354
 10.0.0.5:16001        --> 172.16.2.185:5354
 10.0.0.5:16002        --> 172.16.2.186:5354
      .
      .
      .
<for each controller>

The haproxy configuration is relatively straightforward [2].  There
would be no problem if it the haproxy puppet managed the firewall rules,
but for typical deployments we appear to disable this [3] and rely on
the tripleo.firewall ansible module instead.


The complicating factors are:

a. the ports range depends on the number of miniDNS instances.

b. the miniDNS deployment needs to set firewall rules wherever haproxy
happens to live as they are not guaranteed to be on the same host.
AFAICT, our ansible based firewall rule mechanism doesn't allow for
setting firewall rules on hosts in addition to the ones that the service
is being deployed on.


Possible solutions I've been considering:

a. Have haproxy puppet create firewall rules on the public API network
and use tripleo.firewall for everything else. I think we generally don't
distinguish which networks firewall rules are applicable to so this
would be an "interesting", pervasive change. This is in PID 1's
wheelhouse and I'd be interested in how they feel about this.

b. Somehow create a jinja-ed firewall rule for haproxy that gets
processed at deploy time so details could be filled in using cloud
information. This seems like it would be kind of fragile, may not even
be possible and depends on details of the framework I'm not familiar
with.

c. Extend tripleo.firewall or tripleo.iptables to process jinja'd rules
- but that's problematic because it needs to be set on the haproxy host,
  and miniDNS is elsewhere.

d. Create some ansible that gets run in the haproxy hosts that
generates the firewall rules based on cloud info. I feel this is a bit
ugly.


Does anyone have any suggestions on other solutions or thoughts on the
above?

Cheers,

Brent


1. https://bugzilla.redhat.com/show_bug.cgi?id=1897319 The TripleO HAProxy instance needs to be configured for BIND->miniDNS AXFR

2. https://review.opendev.org/c/openstack/puppet-tripleo/+/828169
Designate: create proxy ports on external VIP to access miniDNS workers.

3. https://bugs.launchpad.net/tripleo/+bug/1961799 haproxy template
tasks to apply IPTables rules are no ops.

--
Brent Eagles
Principal Software Engineer
Red Hat Inc.



From kecarter at redhat.com  Wed Mar  2 15:41:38 2022
From: kecarter at redhat.com (Kevin Carter)
Date: Wed, 2 Mar 2022 09:41:38 -0600
Subject: [tripleo] Dynamically generating firewall rules for the haproxy
 host on behalf of a deployed service
In-Reply-To: <Yh+GRquoFNNu34fu@knife.localdomain>
References: <Yh+GRquoFNNu34fu@knife.localdomain>
Message-ID: <CAKd7Fv0CLLaGYJbdqLznfY06h=mTrZT+rFZj-eUJhcS49T7vfQ@mail.gmail.com>

On Wed, Mar 2, 2022 at 8:59 AM Brent Eagles <beagles at redhat.com> wrote:

> Hi all,
>
> Designate has a requirement that appears to be a first for TripleO. It
> needs to deploy miniDNS instances on the internal network but each are
> accessible from the public network so external bind instances can sync
> with them. This is done by mapping port numbers on the VIP to each
> miniDNS instances [1] e.g.
>
>  10.0.0.5:16000        --> 172.16.2.184:5354
>  10.0.0.5:16001        --> 172.16.2.185:5354
>  10.0.0.5:16002        --> 172.16.2.186:5354
>       .
>       .
>       .
> <for each controller>
>
> The haproxy configuration is relatively straightforward [2].  There
> would be no problem if it the haproxy puppet managed the firewall rules,
> but for typical deployments we appear to disable this [3] and rely on
> the tripleo.firewall ansible module instead.
>
>
> The complicating factors are:
>
> a. the ports range depends on the number of miniDNS instances.
>
> b. the miniDNS deployment needs to set firewall rules wherever haproxy
> happens to live as they are not guaranteed to be on the same host.
> AFAICT, our ansible based firewall rule mechanism doesn't allow for
> setting firewall rules on hosts in addition to the ones that the service
> is being deployed on.
>
>
> Possible solutions I've been considering:
>
> a. Have haproxy puppet create firewall rules on the public API network
> and use tripleo.firewall for everything else. I think we generally don't
> distinguish which networks firewall rules are applicable to so this
> would be an "interesting", pervasive change. This is in PID 1's
> wheelhouse and I'd be interested in how they feel about this.
>
> This seems like the easiest path forward. That said, within the DF we're
actively attempting to reduce our dependence on puppet. As such, while the
other options may be ugly or even more complex, I think they're worth
pursuing especially if it means we have less puppet to maintain.



> b. Somehow create a jinja-ed firewall rule for haproxy that gets
> processed at deploy time so details could be filled in using cloud
> information. This seems like it would be kind of fragile, may not even
> be possible and depends on details of the framework I'm not familiar
> with.
>
> c. Extend tripleo.firewall or tripleo.iptables to process jinja'd rules
> - but that's problematic because it needs to be set on the haproxy host,
>   and miniDNS is elsewhere.
>
> d. Create some ansible that gets run in the haproxy hosts that
> generates the firewall rules based on cloud info. I feel this is a bit
> ugly.
>
>
> Does anyone have any suggestions on other solutions or thoughts on the
> above?
>
> We make heavy use of YAQL to organize our firewall rules for
tripleo.firewall, is there something we can do there? We could also
transition some of our firewall setup to use hostvars / facts across the
deployment and to pull back information for specific nodes, or all nodes
within a given group; maybe we can make better use of that within the
firewall role to pull back runtime information and compute the needed
firewall rules for minidns?



> Cheers,
>
> Brent
>
>
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1897319 The TripleO
> HAProxy instance needs to be configured for BIND->miniDNS AXFR
>
> 2. https://review.opendev.org/c/openstack/puppet-tripleo/+/828169
> Designate: create proxy ports on external VIP to access miniDNS workers.
>
> 3. https://bugs.launchpad.net/tripleo/+bug/1961799 haproxy template
> tasks to apply IPTables rules are no ops.
>
> --
> Brent Eagles
> Principal Software Engineer
> Red Hat Inc.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220302/4d0a47ff/attachment.htm>

From thierry at openstack.org  Wed Mar  2 15:49:26 2022
From: thierry at openstack.org (Thierry Carrez)
Date: Wed, 2 Mar 2022 16:49:26 +0100
Subject: [largescale-sig] Next meeting: Mar 2nd, 15utc
In-Reply-To: <7e4962b0-b479-9ed7-5d69-72a68bcf7a73@openstack.org>
References: <7e4962b0-b479-9ed7-5d69-72a68bcf7a73@openstack.org>
Message-ID: <9615cc25-7fc8-eec6-37e3-0036bf137cbc@openstack.org>

Our meeting just concluded.

We discussed the special guest for our next "Large Scale OpenStack" 
episode on OpenInfra.Live, but also our participation to the PTG in 
April. In preparation for that, between now and next IRC meeting we will 
collect topics for the PTG meeting on:
  https://etherpad.opendev.org/p/large-scale-sig-meeting

You can read the meeting logs at:
https://meetings.opendev.org/meetings/large_scale_sig/2022/large_scale_sig.2022-03-02-15.09.html

Our next IRC meeting will be March 16, at 1500utc on 
#openstack-operators on OFTC. We will finalize our guest speaker for 
OILive and (hopefully) the contents of our PTG session.

Regards,

-- 
Thierry Carrez (ttx)


From tkajinam at redhat.com  Wed Mar  2 16:00:15 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Thu, 3 Mar 2022 01:00:15 +0900
Subject: [tripleo] Dynamically generating firewall rules for the haproxy
 host on behalf of a deployed service
In-Reply-To: <CAKd7Fv0CLLaGYJbdqLznfY06h=mTrZT+rFZj-eUJhcS49T7vfQ@mail.gmail.com>
References: <Yh+GRquoFNNu34fu@knife.localdomain>
 <CAKd7Fv0CLLaGYJbdqLznfY06h=mTrZT+rFZj-eUJhcS49T7vfQ@mail.gmail.com>
Message-ID: <CAL_crJSLuJpGskJU7d5BWwMeWp34h+WCgRvN1OXLvs7GYyUAVg@mail.gmail.com>

I agree with Kevin. What I'd like to add here is that enabling haproxy
firewall management by puppet
means we have both ansible and puppet to manage firewall rules, and this is
likely to cause undesired
conjunction in the future. IMO it's better to find out the way to
facilitate the requirement within tripleo-ansible(*1).

Note that this issue is not specific to Designate and can affect any
deployment which has separate nodes
for api servers and haproxy, as is mentioned in the bug.

I tend to think of a mixed approach of b and c, and gather frontend
firewall rules for all services enabled in all roles by yaql,
and then put that data into tripleo-firewall, then use that data only if
haproxy is enabled in the node.
I started drafting the change, but it's too late in my tz to implement such
composition beyond roles ...
 https://review.opendev.org/q/topic:bug%252F1961799
(I hesitate to share this because it implements almost nothing but hope
this explains my thought well)

(*1)
By the way it reminds me that we still require puppet to set up NAT rules,
which we also need to deal with, later,
as a completely separate topic.


On Thu, Mar 3, 2022 at 12:43 AM Kevin Carter <kecarter at redhat.com> wrote:

> On Wed, Mar 2, 2022 at 8:59 AM Brent Eagles <beagles at redhat.com> wrote:
>
>> Hi all,
>>
>> Designate has a requirement that appears to be a first for TripleO. It
>> needs to deploy miniDNS instances on the internal network but each are
>> accessible from the public network so external bind instances can sync
>> with them. This is done by mapping port numbers on the VIP to each
>> miniDNS instances [1] e.g.
>>
>>  10.0.0.5:16000        --> 172.16.2.184:5354
>>  10.0.0.5:16001        --> 172.16.2.185:5354
>>  10.0.0.5:16002        --> 172.16.2.186:5354
>>       .
>>       .
>>       .
>> <for each controller>
>>
>> The haproxy configuration is relatively straightforward [2].  There
>> would be no problem if it the haproxy puppet managed the firewall rules,
>> but for typical deployments we appear to disable this [3] and rely on
>> the tripleo.firewall ansible module instead.
>>
>>
>> The complicating factors are:
>>
>> a. the ports range depends on the number of miniDNS instances.
>>
>> b. the miniDNS deployment needs to set firewall rules wherever haproxy
>> happens to live as they are not guaranteed to be on the same host.
>> AFAICT, our ansible based firewall rule mechanism doesn't allow for
>> setting firewall rules on hosts in addition to the ones that the service
>> is being deployed on.
>>
>>
>> Possible solutions I've been considering:
>>
>> a. Have haproxy puppet create firewall rules on the public API network
>> and use tripleo.firewall for everything else. I think we generally don't
>> distinguish which networks firewall rules are applicable to so this
>> would be an "interesting", pervasive change. This is in PID 1's
>> wheelhouse and I'd be interested in how they feel about this.
>>
>> This seems like the easiest path forward. That said, within the DF we're
> actively attempting to reduce our dependence on puppet. As such, while the
> other options may be ugly or even more complex, I think they're worth
> pursuing especially if it means we have less puppet to maintain.
>
>
>
>> b. Somehow create a jinja-ed firewall rule for haproxy that gets
>> processed at deploy time so details could be filled in using cloud
>> information. This seems like it would be kind of fragile, may not even
>> be possible and depends on details of the framework I'm not familiar
>> with.
>>
>> c. Extend tripleo.firewall or tripleo.iptables to process jinja'd rules
>> - but that's problematic because it needs to be set on the haproxy host,
>>   and miniDNS is elsewhere.
>>
>> d. Create some ansible that gets run in the haproxy hosts that
>> generates the firewall rules based on cloud info. I feel this is a bit
>> ugly.
>>
>>
>> Does anyone have any suggestions on other solutions or thoughts on the
>> above?
>>
>> We make heavy use of YAQL to organize our firewall rules for
> tripleo.firewall, is there something we can do there? We could also
> transition some of our firewall setup to use hostvars / facts across the
> deployment and to pull back information for specific nodes, or all nodes
> within a given group; maybe we can make better use of that within the
> firewall role to pull back runtime information and compute the needed
> firewall rules for minidns?
>
>
>
>> Cheers,
>>
>> Brent
>>
>>
>> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1897319 The TripleO
>> HAProxy instance needs to be configured for BIND->miniDNS AXFR
>>
>> 2. https://review.opendev.org/c/openstack/puppet-tripleo/+/828169
>> Designate: create proxy ports on external VIP to access miniDNS workers.
>>
>> 3. https://bugs.launchpad.net/tripleo/+bug/1961799 haproxy template
>> tasks to apply IPTables rules are no ops.
>>
>> --
>> Brent Eagles
>> Principal Software Engineer
>> Red Hat Inc.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220303/a918b8a4/attachment-0001.htm>

From johnsomor at gmail.com  Wed Mar  2 16:59:37 2022
From: johnsomor at gmail.com (Michael Johnson)
Date: Wed, 2 Mar 2022 08:59:37 -0800
Subject: [designate] Zed PTG planning etherpad
Message-ID: <CAMH0MgJ4OntZ6cWBth83YeMTKNXwTCaMT990sLzvk1DDzrX4ZA@mail.gmail.com>

Hi Designate community,

In preparation for our PTG sessions in April I have created an
etherpad for us to add topics for discussion.

https://etherpad.opendev.org/p/zed-ptg-designate

Please add your attendance and topics.

Michael


From iurygregory at gmail.com  Wed Mar  2 17:29:43 2022
From: iurygregory at gmail.com (Iury Gregory)
Date: Wed, 2 Mar 2022 14:29:43 -0300
Subject: [ironic] Zed PTG etherpad
Message-ID: <CAJqPaj_mO+AO44bhXcPsDzd_oRfTPV2WFA2neoWFuX3MZSPGVA@mail.gmail.com>

Hello ironicers!

I've created an etherpad to collect topics for our Zed PTG [1]
Feel free to add any topics on it =)

Later tomorrow I will be sharing the ideas for possible PTG slots and in
the upstream meeting on Monday (March 7) we will announce.

[1] https://etherpad.opendev.org/p/ironic-zed-ptg

-- 


*Att[]'sIury Gregory Melo Ferreira *
*MSc in Computer Science at UFCG*
*Part of the ironic-core and puppet-manager-core team in OpenStack*
*Software Engineer at Red Hat Czech*
*Social*: https://www.linkedin.com/in/iurygregory
*E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220302/351d9403/attachment.htm>

From gmann at ghanshyammann.com  Wed Mar  2 18:14:04 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 02 Mar 2022 12:14:04 -0600
Subject: [QA][OpenStackSDK][release] Cycle With Intermediary without
 recent deliverables
In-Reply-To: <a9d3acc2-5d1a-8aff-dc3a-0a632a1b0067@est.tech>
References: <a9d3acc2-5d1a-8aff-dc3a-0a632a1b0067@est.tech>
Message-ID: <17f4bd6d4b0.b231163971144.6913564304480452809@ghanshyammann.com>

 ---- On Wed, 02 Mar 2022 08:50:51 -0600 El?d Ill?s <elod.illes at est.tech> wrote ----
 >         Hi,Quick reminder that for deliverables following the cycle-with-intermediarymodel, the release team will use the latest Yoga release available onrelease week.The following deliverables have done a Yoga release, but it was notrefreshed in the last two months: tempest patrole (this was not yet released at all in Yoga) python-openstackclient (I remember that openstacksdk cannot do another   release in Yoga due to issues on master branch. Is this also valid for   python-openstackclient?)You should consider making a new one very soon, so that we don't use anoutdated version for the final release.El?d Ill?sirc: elodilles    

Thanks for reminder, I have proposed the Patrole release - https://review.opendev.org/c/openstack/releases/+/831565

-gmann

 >     
 >     
 >     
 >   


From adivya1.singh at gmail.com  Wed Mar  2 20:52:41 2022
From: adivya1.singh at gmail.com (Adivya Singh)
Date: Thu, 3 Mar 2022 02:22:41 +0530
Subject: Neutron issue in current Xena Version of openstack
Message-ID: <CA+ykd61bxKfPX5FmOptSCB9PsaaUaMm8An1JK75yAi9106MyQg@mail.gmail.com>

hi Team,

i am facing issue after installing XENA version of Openstack, where in the
Same hosted Network node, some routers work, and some not, The real issue
is the router which are not working, All floating IP assigned to the router
does not work, but other routers hosted on same L3 agent Works

I am seeing this king of error " "Could not generate persistent MAC: No
data" , but i am not sure this is impacting the issue

Regards
Adivya Singh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220303/2c4cd23f/attachment.htm>

From dsmigiel at redhat.com  Wed Mar  2 22:41:08 2022
From: dsmigiel at redhat.com (Dariusz Smigiel)
Date: Wed, 2 Mar 2022 14:41:08 -0800
Subject: [TripleO] Gate blocker for Centos 9 Wallaby
Message-ID: <CAA16v18N+tr2VSBTVt3AA_jY92HacjUpMu=5vn8Y3Cg49O_kOg@mail.gmail.com>

Currently TripleO gate is experiencing issues with building images [1]
We're aware of the problem, and we're trying to resolve this issue.

Please withhold from rechecking RDO Third Party CI.

Thank you,
Dariusz Smigiel (dasm)

[1]: https://bugs.launchpad.net/tripleo/+bug/1962786



From zbitter at redhat.com  Thu Mar  3 03:03:57 2022
From: zbitter at redhat.com (Zane Bitter)
Date: Wed, 2 Mar 2022 22:03:57 -0500
Subject: [election][heat][ptl] PTL non-candidacy
In-Reply-To: <CA+WCyyoZ=5TSJE=CaUggXfYMe8Arn0w+pcNy7mgg9soLa6i0+A@mail.gmail.com>
References: <CA+WCyyoZ=5TSJE=CaUggXfYMe8Arn0w+pcNy7mgg9soLa6i0+A@mail.gmail.com>
Message-ID: <d5b48aaf-5ec7-f6f6-5857-d1d0b6436a6e@redhat.com>

On 8/02/22 00:50, Rico Lin wrote:
> Hi all,
> 
> As the PTL election will soon start, I would like to share my statement 
> on not planning?to run another term?of Heat PTL. And Instead, I 
> encourage anyone (core reviewer or not) who is interested to put their 
> name on.
> I will definitely still stay around and help with reviews and patches.

Hey Rico,
Thanks so much for all your work as PTL over many years now.

cheers,
Zane.



From gmann at ghanshyammann.com  Thu Mar  3 03:36:22 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 02 Mar 2022 21:36:22 -0600
Subject: [all][tc] Technical Committee next weekly meeting on Mar 3rd
 (not 4th) at 1500 UTC
In-Reply-To: <17f42dbbe35.e38a85b0295421.3903320940743592043@ghanshyammann.com>
References: <17f413dc13b.1112c1076280164.9078145143439661308@ghanshyammann.com>
 <17f42dbbe35.e38a85b0295421.3903320940743592043@ghanshyammann.com>
Message-ID: <17f4dd9a157.12637a06483289.7671218897587973192@ghanshyammann.com>

Hello Everyone,

Below is the agenda for Tomorrow's TC IRC meeting schedule at 1500 UTC.

https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

== Agenda for tomorrow's TC meeting ==

* Roll call

* Follow up on past action items

* Welcome new TC members
** http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027412.html

* Weekly meeting time check
** https://doodle.com/meeting/organize/id/mep9mGma

* Gate health check
** Fixing Zuul config error in OpenStack
*** https://etherpad.opendev.org/p/zuul-config-error-openstack

* Next step for release cadence
** https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html

* Z cycle Leaderless projects
** https://etherpad.opendev.org/p/zed-leaderless

* PTG Preparation
** http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027381.html
** https://etherpad.opendev.org/p/tc-zed-ptg
** TC + Community Leaders Interaction
*** http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027382.html

*Dropping tags framework - next steps (yoctozepto)

* newsletter
** https://etherpad.opendev.org/p/newsletter-openstack-news

* Open Reviews
** https://review.opendev.org/q/projects:openstack/governance+is:open

-gmann


 ---- On Mon, 28 Feb 2022 18:22:51 -0600 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > Sorry I mentioned Mar 4th as the next meeting but it is on Mar 3rd Thursday 15:00 UTC
 > 
 > -gmann
 > 
 >  ---- On Mon, 28 Feb 2022 10:50:40 -0600 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 >  > Hello Everyone,
 >  > 
 >  > Technical Committee's next weekly meeting is scheduled for Mar 4th at 1500 UTC.
 >  > 
 >  > If you would like to add topics for discussion, please add them to the below wiki page by
 >  > Wednesday, Mar 3rd, at 2100 UTC.
 >  > 
 >  > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting
 >  > 
 >  > -gmann
 >  > 
 >  > 
 > 
 > 


From satish.txt at gmail.com  Thu Mar  3 03:47:08 2022
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 2 Mar 2022 22:47:08 -0500
Subject: Openstack HPC storage suggestion
Message-ID: <CAPgF-frsHAHKWfYqDjYmFqEYv1D7R4QgzRKM_+_oyDNEjt5OaQ@mail.gmail.com>

Folks,

I built a 30 node HPC environment on openstack using mellanox infiniband
nic for high speed MPI messaging. So far everything works. Now I am looking
for a HPC PFS (parallel file system)  similar to Luster which I can mount
on all HPC vms to run MPI jobs.

I was reading on google and saw some CERN videos and they are using Ceph
(cephfs) for PFS. Also i was reading CephFS + Manila is a good choice for
HPC on openstack design.

Does anyone have any experience with HPC storage for Openstack? Please
advice or share your experience :)  Thanks in advance.

~S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220302/d7b0fe63/attachment.htm>

From vikarnatathe at gmail.com  Thu Mar  3 04:07:00 2022
From: vikarnatathe at gmail.com (Vikarna Tathe)
Date: Thu, 3 Mar 2022 09:37:00 +0530
Subject: nvidia gpu
Message-ID: <CAE2S1+6DCrogC3=vXSkFmnXNvo22qxiZ8ittkPg23XgwOWffUQ@mail.gmail.com>

Hello All,

Can somebody help me with the procedure for GPU integration with openstack
wallaby, Ubuntu 20.04.

Below are the card details:
da:00.0 VGA compatible controller: NVIDIA Corporation TU102GL [Quadro RTX
6000/8000]

Vikarna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220303/b1b41810/attachment.htm>

From jerome.pansanel at iphc.cnrs.fr  Thu Mar  3 08:00:49 2022
From: jerome.pansanel at iphc.cnrs.fr (Jerome Pansanel)
Date: Thu, 3 Mar 2022 09:00:49 +0100
Subject: nvidia gpu
In-Reply-To: <CAE2S1+6DCrogC3=vXSkFmnXNvo22qxiZ8ittkPg23XgwOWffUQ@mail.gmail.com>
References: <CAE2S1+6DCrogC3=vXSkFmnXNvo22qxiZ8ittkPg23XgwOWffUQ@mail.gmail.com>
Message-ID: <e7992872-5802-76dc-a617-9dd462447bd0@iphc.cnrs.fr>

Dear Virkana,

There is an official documentation here:
https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/wallaby/app-pci-passthrough-gpu.html

Here are additional links:
* 
https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/wallaby/app-pci-passthrough-gpu.html
* https://gist.github.com/claudiok/890ab6dfe76fa45b30081e58038a9215

Best,

Jerome

Le 03/03/2022 ? 05:07, Vikarna Tathe a ?crit?:
> Hello All,
> 
> Can somebody help me with the procedure for GPU integration with 
> openstack wallaby, Ubuntu 20.04.
> 
> Below are the card details:
> da:00.0 VGA compatible controller: NVIDIA Corporation TU102GL [Quadro 
> RTX 6000/8000]
> 
> Vikarna


-- 
Jerome Pansanel, PhD
Technical Director at IPHC
Technical Coordinator at France Grilles
Head of Scientific Cloud Infrastructure (SCIGNE) at IPHC
IPHC                        ||  GSM: +33 (0)6 25 19 24 43
23 rue du Loess, BP 28      ||  Tel: +33 (0)3 88 10 66 24
F-67037 STRASBOURG Cedex 2  ||  Fax: +33 (0)3 88 10 62 34


From rdhasman at redhat.com  Thu Mar  3 08:11:02 2022
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Thu, 3 Mar 2022 13:41:02 +0530
Subject: [cinder] PTG Planning Etherpad
Message-ID: <CAARK8KT3EYtV4gOChyZsdVKsvkWTPcrcbDQmTiOpcY5y1WXNDw@mail.gmail.com>

Hello Argonauts,

As you might be aware that the Zed PTG is approaching so I've created an
etherpad for the details of the PTG and adding topics.
To summarize, PTG will take place from 4-8 April, 2022 and below are the
details for Cinder PTG:

Date: 5-8 April, 2022
TIme: 1300-1700 UTC

Connection info will be shared prior to the meeting on the etherpad and the
cinder channel on IRC. Most probably it will be on BlueJeans
(as has been in the past) but suggestions are welcome.

Etherpad: https://etherpad.opendev.org/p/zed-ptg-cinder-planning

Regarding the timings, as discussed in the cinder meeting twice, the
attendees had no concern and it is the preferred time for the
PTG since past 3 virtual PTGs. If there are any concerns, do let me know
and we can also schedule your topic as convenient for
your timezone. Lastly, I would encourage everyone to add topics as soon as
they can since it makes the planning/arranging of topics
easier and better.

Thanks and regards
Rajat Dhasmana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220303/800d93da/attachment.htm>

From mahendra.paipuri at cnrs.fr  Thu Mar  3 08:23:29 2022
From: mahendra.paipuri at cnrs.fr (Mahendra Paipuri)
Date: Thu, 3 Mar 2022 09:23:29 +0100
Subject: Openstack HPC storage suggestion
In-Reply-To: <CAPgF-frsHAHKWfYqDjYmFqEYv1D7R4QgzRKM_+_oyDNEjt5OaQ@mail.gmail.com>
References: <CAPgF-frsHAHKWfYqDjYmFqEYv1D7R4QgzRKM_+_oyDNEjt5OaQ@mail.gmail.com>
Message-ID: <11fc1add-94f4-94a9-c47b-d50672708da0@cnrs.fr>

Hello,

We are quite interested in this too. When we were looking into existing 
solutions, we found there has been some work in integrating LUSTRE into 
OpenStack [1], [2]. I remember coming across some Openinfra talks on 
developing a manila backend driver for LUSTRE. I am not quite sure if 
this project is still ongoing. Manila already provides a backend driver 
for GPFS [3] (unfortunately GPFS is not opensource) to readily integrate 
it into Openstack. Manila supports GlusterFS and CephFS as well but they 
do not have RDMA support (if I am not wrong).

This is pretty much what we found. Would be glad explore more solutions 
if someone knows any.

Cheers

-

Mahendra

[1] 
https://docs.google.com/presentation/d/1kGRzcdVQX95abei1bDVoRzxyC02i89_m5_sOfp8Aq6o/htmlpresent

[2] 
https://www.openstack.org/videos/summits/barcelona-2016/lustre-integration-for-hpc-on-openstack-at-cambridge-and-monash

[3] https://docs.openstack.org/manila/latest/admin/gpfs_driver.html

On 03/03/2022 04:47, Satish Patel wrote:
> Folks,
>
> I built a 30 node HPC environment on openstack using mellanox 
> infiniband nic for high speed MPI messaging. So far everything works. 
> Now I am looking for a HPC PFS (parallel file system)? similar to 
> Luster which I can mount on all HPC vms to run MPI jobs.
>
> I was reading on google and saw some CERN videos and they are using 
> Ceph (cephfs) for PFS. Also i was reading CephFS?+ Manila is a good 
> choice for HPC on openstack design.
>
> Does anyone have any experience with HPC storage for Openstack? Please 
> advice or share your experience :)? Thanks in advance.
>
> ~S


From mark at stackhpc.com  Thu Mar  3 09:11:24 2022
From: mark at stackhpc.com (Mark Goddard)
Date: Thu, 3 Mar 2022 09:11:24 +0000
Subject: Openstack HPC storage suggestion
In-Reply-To: <11fc1add-94f4-94a9-c47b-d50672708da0@cnrs.fr>
References: <CAPgF-frsHAHKWfYqDjYmFqEYv1D7R4QgzRKM_+_oyDNEjt5OaQ@mail.gmail.com>
 <11fc1add-94f4-94a9-c47b-d50672708da0@cnrs.fr>
Message-ID: <CAFHSqWri5svPJW4hj0WwiJY1C_A2Jt13uYraDB4VXAyaacurRA@mail.gmail.com>

I would recommend attending the Scientific SIG meetings if you are
looking for people with this kind of information.

https://wiki.openstack.org/wiki/Scientific_SIG

Mark

On Thu, 3 Mar 2022 at 08:28, Mahendra Paipuri <mahendra.paipuri at cnrs.fr> wrote:
>
> Hello,
>
> We are quite interested in this too. When we were looking into existing
> solutions, we found there has been some work in integrating LUSTRE into
> OpenStack [1], [2]. I remember coming across some Openinfra talks on
> developing a manila backend driver for LUSTRE. I am not quite sure if
> this project is still ongoing. Manila already provides a backend driver
> for GPFS [3] (unfortunately GPFS is not opensource) to readily integrate
> it into Openstack. Manila supports GlusterFS and CephFS as well but they
> do not have RDMA support (if I am not wrong).
>
> This is pretty much what we found. Would be glad explore more solutions
> if someone knows any.
>
> Cheers
>
> -
>
> Mahendra
>
> [1]
> https://docs.google.com/presentation/d/1kGRzcdVQX95abei1bDVoRzxyC02i89_m5_sOfp8Aq6o/htmlpresent
>
> [2]
> https://www.openstack.org/videos/summits/barcelona-2016/lustre-integration-for-hpc-on-openstack-at-cambridge-and-monash
>
> [3] https://docs.openstack.org/manila/latest/admin/gpfs_driver.html
>
> On 03/03/2022 04:47, Satish Patel wrote:
> > Folks,
> >
> > I built a 30 node HPC environment on openstack using mellanox
> > infiniband nic for high speed MPI messaging. So far everything works.
> > Now I am looking for a HPC PFS (parallel file system)  similar to
> > Luster which I can mount on all HPC vms to run MPI jobs.
> >
> > I was reading on google and saw some CERN videos and they are using
> > Ceph (cephfs) for PFS. Also i was reading CephFS + Manila is a good
> > choice for HPC on openstack design.
> >
> > Does anyone have any experience with HPC storage for Openstack? Please
> > advice or share your experience :)  Thanks in advance.
> >
> > ~S
>


From Molka.Gharbaoui at santannapisa.it  Thu Mar  3 09:29:15 2022
From: Molka.Gharbaoui at santannapisa.it (Molka Gharbaoui)
Date: Thu, 3 Mar 2022 09:29:15 +0000
Subject: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using
 ceilometer and gnocchi
In-Reply-To: <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
Message-ID: <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>

Thank you Matthias for your reply.

Unfortunately, from the logs I still cannot understand what is the issue.

Could someone kindly indicate me how ceilometer and gnocchi should be configured to get the data?

For example in this link: https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html the endpoints should use the following URL: http://controller:8041 while in my case the 8041 port is not even listening and the API indicated in the dashboard for Gnocchi is http://<http://controller:8041>x.x.x.x/metric.

Thank you in advance.



________________________________
Da: Matthias Runge <mrunge at matthias-runge.de>
Inviato: luned? 28 febbraio 2022 19:37
A: openstack-discuss at lists.openstack.org <openstack-discuss at lists.openstack.org>
Oggetto: Re: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi

On 2/28/22 17:58, Molka Gharbaoui wrote:
> Hi all,
>
> I installed devstack and ceilometer by adding the following lines in the
> local.conf file:
>
> enable_plugin ceilometer https://opendev.org/openstack/ceilometer.git
> CEILOMETER_BACKEND=gnocchi
>
> Devstack (yoga) works correctly (I am able to create images, instances,
> etc.). The problem is that I cannot visualize the metrics. Using
> "gnocchi metric list" and "gnocchi resource list" commands the result is
> empty.
>
> When I use the "--debug" option, no errors are plotted but the body
> response is empty.
>
> "ceilometer-upgrade" gives the following error: DEBUG
> ceilometer.cmd.storage Upgrade Gnocchi resource types upgrade
> /opt/stack/ceilometer/ceilometer/cmd/storage.py:42
>
> "ceilometer-polling" prints "The resource could not be found".
>
> I have a running instance.
>
> Could you help me in retrieving the metrics from openstack?

That means, that ceilometer apparently either doesn't get any updates
from the underlying services OR it doesn't send the metrics over to gnocchi.

You should check the ceilometer logs for errors. Also gnocchi logs could
reveal issues.

Matthias


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220303/f267893f/attachment-0001.htm>

From zyklenfrei at gmail.com  Thu Mar  3 09:30:52 2022
From: zyklenfrei at gmail.com (Manuel Holtgrewe)
Date: Thu, 3 Mar 2022 10:30:52 +0100
Subject: Openstack HPC storage suggestion
In-Reply-To: <11fc1add-94f4-94a9-c47b-d50672708da0@cnrs.fr>
References: <CAPgF-frsHAHKWfYqDjYmFqEYv1D7R4QgzRKM_+_oyDNEjt5OaQ@mail.gmail.com>
 <11fc1add-94f4-94a9-c47b-d50672708da0@cnrs.fr>
Message-ID: <CACRvWAtO+_uBjSrDOVyysSVMOVyRa1jX3nRtvxpSO=WryYYD2Q@mail.gmail.com>

Hi,

I guess it really depends on what HPC means to you ;-)

Do your users schedule nova instances? Can you actually do Infiniband
RDMA between nova VMs? Or are your users scheduling ironic instances
via nova?

We have an openstack setup based on kayobe/kolla where we:

- Deploy 8 hyperconverged OpenStack nova libvirt compute+Ceph storage
(mostly for block storage and cephfs comes in handy for shared file
systems, e.g., for shared state in Slurm) servers.
- Deploy 300+ bare metal compute nodes via ironic.
- Use Slurm for the job scheduler.
- Setup everything after the bare OS with Ansible.
- Have login nodes and slurm scheduler etc. run in nova VMs.
- Only have Ethernet interconnect (100/25GbE for central switches and
recent servers and 40/10GbE for older servers).

So we are using OpenStack nova+libvirt as a unified way of deploying
virtual and physical machines and then install them as we would do
with normal servers. That's a bit non-cloudy (as far as I have
learned) but works really well for us.

Now to your HPC storage question... that I hope to answer a bit indirectly.

The main advantage for using manila with CephFS (that I can see) is
that you get the openstack goodies of API and Horizon clients for
managing shares. I guess this is mostly useful if you want to have
cloud features for your HPC such as users allocating storage in
self-service to their nova/ironic machines. We come from a classic HPC
setting where the partitioning of the system is not done by creating
multiple nodes/clusters by users in self-service, but rather
administration provides a bare metal cluster with Slurm scheduler.
Users log in to head nodes and submit jobs to the compute nodes to
Slurm. Thus Slurm does the managing of resources and users can
allocate single cores up to the whole cluster. So in our use case
there would not be a major advantage of using manila for our storage
as we would primarily have one export that gives access to the whole
storage ;-).

We currently have an old GPFS storage that we mount on all nodes via
Ansible. We are currently migrating to using an additional, dedicated
NVME-based ceph cluster (that is not hyperconverged with our compute)
and that we would also mount via Ansible. As we essentially only have
a single share on this storage managing the share with manila would be
more trouble than work. The much more important part will be setting
up Ceph appropriately and tuning it to perform well (e.g., using the
IO500 benchmark as the croit people demonstrate here [1]).

I guess that does not really answer your question but I hope that it
gives useful perspective to you and maybe others.

You can look at the work of the wonderful people of StackHPC that
provide commercial services around Openstack/Kayobe/Kolla/Ironic for
HPC setups. There are a couple of interesting videos involving their
staff and they have very useful information on the web site as well.
And as Mark Goddard just wrote you can have a look at the Scientific
SIG where they are involved as well. (I'm not in any way related to
StackHPC, I just really like their work).

Best wishes,
Manuel

[1] https://croit.io/blog/ceph-performance-test-and-optimization

On Thu, Mar 3, 2022 at 9:25 AM Mahendra Paipuri
<mahendra.paipuri at cnrs.fr> wrote:
>
> Hello,
>
> We are quite interested in this too. When we were looking into existing
> solutions, we found there has been some work in integrating LUSTRE into
> OpenStack [1], [2]. I remember coming across some Openinfra talks on
> developing a manila backend driver for LUSTRE. I am not quite sure if
> this project is still ongoing. Manila already provides a backend driver
> for GPFS [3] (unfortunately GPFS is not opensource) to readily integrate
> it into Openstack. Manila supports GlusterFS and CephFS as well but they
> do not have RDMA support (if I am not wrong).
>
> This is pretty much what we found. Would be glad explore more solutions
> if someone knows any.
>
> Cheers
>
> -
>
> Mahendra
>
> [1]
> https://docs.google.com/presentation/d/1kGRzcdVQX95abei1bDVoRzxyC02i89_m5_sOfp8Aq6o/htmlpresent
>
> [2]
> https://www.openstack.org/videos/summits/barcelona-2016/lustre-integration-for-hpc-on-openstack-at-cambridge-and-monash
>
> [3] https://docs.openstack.org/manila/latest/admin/gpfs_driver.html
>
> On 03/03/2022 04:47, Satish Patel wrote:
> > Folks,
> >
> > I built a 30 node HPC environment on openstack using mellanox
> > infiniband nic for high speed MPI messaging. So far everything works.
> > Now I am looking for a HPC PFS (parallel file system)  similar to
> > Luster which I can mount on all HPC vms to run MPI jobs.
> >
> > I was reading on google and saw some CERN videos and they are using
> > Ceph (cephfs) for PFS. Also i was reading CephFS + Manila is a good
> > choice for HPC on openstack design.
> >
> > Does anyone have any experience with HPC storage for Openstack? Please
> > advice or share your experience :)  Thanks in advance.
> >
> > ~S
>


From rafaelweingartner at gmail.com  Thu Mar  3 10:24:37 2022
From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=)
Date: Thu, 3 Mar 2022 07:24:37 -0300
Subject: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics
 using ceilometer and gnocchi
In-Reply-To: <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
Message-ID: <CAG97rafcMNtc2nSX36PoJ-GtoKukU+rzVZjfmyPyXMsPfXHeyg@mail.gmail.com>

This situation can be caused by a lot of different things.

   - "gnocchi resource-type list" will show you the resource-types
   configured. Make sure you have configured the resource types that
   Ceilometer is pushing resources to
   - Make sure you have enabled metrics to be collected via polling.yml file
   - Make sure you have configured the "gnocchi_resources.yaml" file, and
   that the link between metrics, resources, and attributes to be pushed are
   correctly created
   - If want to generate metrics based on events, you then need to check :
   meters.yaml file, to see if everything is fine there
   - Make sure Ceilometer is pushing metrics and resource attributes to
   gnocchi. When the push is executed you will see the following DEBUG log
   messages:
      - Processing sample [%s] for resource ID [%s]
      - %d measures posted against %d metrics through %d resources
      - metric %s is not handled by Gnocchi (this one will appear if the
      metric is not configured to be pushed in the "gnocchi_resources.yaml")


On Thu, Mar 3, 2022 at 6:33 AM Molka Gharbaoui <
Molka.Gharbaoui at santannapisa.it> wrote:

> Thank you Matthias for your reply.
>
> Unfortunately, from the logs I still cannot understand what is the issue.
>
> Could someone kindly indicate me how ceilometer and gnocchi should be
> configured to get the data?
>
> For example in this link:
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html the
> endpoints should use the following URL: http://controller:8041 while in
> my case the 8041 port is not even listening and the API indicated in the
> dashboard for Gnocchi is http:// <http://controller:8041>x.x.x.x/metric.
>
> Thank you in advance.
>
>
>
> ------------------------------
> *Da:* Matthias Runge <mrunge at matthias-runge.de>
> *Inviato:* luned? 28 febbraio 2022 19:37
> *A:* openstack-discuss at lists.openstack.org <
> openstack-discuss at lists.openstack.org>
> *Oggetto:* Re: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> metrics using ceilometer and gnocchi
>
> On 2/28/22 17:58, Molka Gharbaoui wrote:
> > Hi all,
> >
> > I installed devstack and ceilometer by adding the following lines in the
> > local.conf file:
> >
> > enable_plugin ceilometer https://opendev.org/openstack/ceilometer.git
> > CEILOMETER_BACKEND=gnocchi
> >
> > Devstack (yoga) works correctly (I am able to create images, instances,
> > etc.). The problem is that I cannot visualize the metrics. Using
> > "gnocchi metric list" and "gnocchi resource list" commands the result is
> > empty.
> >
> > When I use the "--debug" option, no errors are plotted but the body
> > response is empty.
> >
> > "ceilometer-upgrade" gives the following error: DEBUG
> > ceilometer.cmd.storage Upgrade Gnocchi resource types upgrade
> > /opt/stack/ceilometer/ceilometer/cmd/storage.py:42
> >
> > "ceilometer-polling" prints "The resource could not be found".
> >
> > I have a running instance.
> >
> > Could you help me in retrieving the metrics from openstack?
>
> That means, that ceilometer apparently either doesn't get any updates
> from the underlying services OR it doesn't send the metrics over to
> gnocchi.
>
> You should check the ceilometer logs for errors. Also gnocchi logs could
> reveal issues.
>
> Matthias
>
>
>

-- 
Rafael Weing?rtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220303/4e37c71b/attachment.htm>

From dtantsur at redhat.com  Thu Mar  3 10:26:54 2022
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Thu, 3 Mar 2022 11:26:54 +0100
Subject: [hwsig] sushy-oem-idrac for Hardware Vendor SIG
In-Reply-To: <MWHPR19MB0077B909F3CD8A7BEFBCC532FE3E9@MWHPR19MB0077.namprd19.prod.outlook.com>
References: <MWHPR19MB0077B909F3CD8A7BEFBCC532FE3E9@MWHPR19MB0077.namprd19.prod.outlook.com>
Message-ID: <CACNgkFxOEOKNbx-GvwdjQQJEYXNvDzLjs1UXH8w4kQq59EciCQ@mail.gmail.com>

Hi,

I'm not a hardware vendor SIG member, but with my ironic hat on, it does
make sense.

Dmitry

On Fri, Feb 25, 2022 at 12:46 PM Jaunteva, Aija <Aija.Jaunteva at dell.com>
wrote:

> Hi,
>
>
>
> I would like to propose moving sushy-oem-idrac [1] that is used in Ironic
> project to Hardware Vendor SIG. sushy-oem-idrac is iDRAC specific OEM
> extension of vendor-independent sushy [2] library and both use Redfish to
> communicate with BMCs.
>
>
>
> Any feedback welcome.
>
>
>
> Regards,
>
> Aija
>
>
>
> [1] https://opendev.org/x/sushy-oem-idrac/
>
> [2] https://opendev.org/openstack/sushy
>
> Internal Use - Confidential
>


-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
O'Neill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220303/3aa22fb6/attachment.htm>

From katonalala at gmail.com  Thu Mar  3 10:31:44 2022
From: katonalala at gmail.com (Lajos Katona)
Date: Thu, 3 Mar 2022 11:31:44 +0100
Subject: Neutron issue in current Xena Version of openstack
In-Reply-To: <CA+ykd61bxKfPX5FmOptSCB9PsaaUaMm8An1JK75yAi9106MyQg@mail.gmail.com>
References: <CA+ykd61bxKfPX5FmOptSCB9PsaaUaMm8An1JK75yAi9106MyQg@mail.gmail.com>
Message-ID: <CALg0jKn32wb7Osehfvq5W2PpJqb_tUHbUrZO7NjMDhkrUyABsw@mail.gmail.com>

Hi,
Could you give some more details how do you use Neutron, with OVN, or OVS?
The error you pasted seems to be from syslog, am I right?

Regards
Lajos Katona (lajoskatona)

Adivya Singh <adivya1.singh at gmail.com> ezt ?rta (id?pont: 2022. m?rc. 2.,
Sze, 21:59):

> hi Team,
>
> i am facing issue after installing XENA version of Openstack, where in the
> Same hosted Network node, some routers work, and some not, The real issue
> is the router which are not working, All floating IP assigned to the router
> does not work, but other routers hosted on same L3 agent Works
>
> I am seeing this king of error " "Could not generate persistent MAC: No
> data" , but i am not sure this is impacting the issue
>
> Regards
> Adivya Singh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220303/1eaa3c24/attachment-0001.htm>

From mrunge at matthias-runge.de  Thu Mar  3 10:59:10 2022
From: mrunge at matthias-runge.de (Matthias Runge)
Date: Thu, 3 Mar 2022 11:59:10 +0100
Subject: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics
 using ceilometer and gnocchi
In-Reply-To: <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
Message-ID: <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>

On 3/3/22 10:29, Molka Gharbaoui wrote:
> Thank you Matthias for your reply.
> 
> Unfortunately, from the logs I still cannot understand what is the issue.
> 
> Could someone kindly indicate me how ceilometer and gnocchi should be 
> configured to get the data?
> 
> For example in this link: 
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html 
> <https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html>?the 
> endpoints should use the following URL: http://controller:8041 
> <http://controller:8041>?while in my case the 8041 port is not even 
> listening and the API indicated in the dashboard for Gnocchi is http:// 
> <http://controller:8041>x.x.x.x/metric.
> 
> Thank you in advance.
> 

OpenStack configuration is complex. The guide does not remotely touch on 
production environments. Please do not confuse devstack with production 
envionments. Also the doc you linked is not for devstack itself.

The flow in general is: data is generated by the services like nova or 
glance. Ceilometer listens on the bus and also polls for information. 
The info is sent then over (as configured in publishers.yaml) to gnocchi.
Gnocchi has an api, ceilometer has not. Reading your response, this 
makes me suspicious if there is gnocchi running. From the initial 
question it suggests it is, from your most recent response, it is not.


Matthias


From Molka.Gharbaoui at santannapisa.it  Thu Mar  3 12:23:27 2022
From: Molka.Gharbaoui at santannapisa.it (Molka Gharbaoui)
Date: Thu, 3 Mar 2022 12:23:27 +0000
Subject: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics
 using ceilometer and gnocchi
In-Reply-To: <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
Message-ID: <VE1PR03MB5550D1E11BBBFE191473B67EEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>

Hi Matthias,

Sorry for the confusion. Gnocchi is running and I am able to execute commands like "gnocchi metric list" and "gnocchi resource list" without errors even though the response is empty. Also checking mysql, the gnocchi database is correctly created.

By the link I previously shared I wanted just to highlight that there are some differences between what was written there and between the environemnt I installed. I was searching there because I would have expected that Devstack installs and configures every component in automatic with no or minimum external intervention (in fact if I don't consider the Telemetry aspect, the rest works perfectly fine).

I will follow Rafael guidelines to better undrstand where is the issue.

Thanks.

________________________________
Da: Matthias Runge <mrunge at matthias-runge.de>
Inviato: gioved? 3 marzo 2022 11:59
A: openstack-discuss at lists.openstack.org <openstack-discuss at lists.openstack.org>
Oggetto: Re: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi

On 3/3/22 10:29, Molka Gharbaoui wrote:
> Thank you Matthias for your reply.
>
> Unfortunately, from the logs I still cannot understand what is the issue.
>
> Could someone kindly indicate me how ceilometer and gnocchi should be
> configured to get the data?
>
> For example in this link:
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html
> <https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html> the
> endpoints should use the following URL: http://controller:8041
> <http://controller:8041> while in my case the 8041 port is not even
> listening and the API indicated in the dashboard for Gnocchi is http://
> <http://controller:8041>x.x.x.x/metric.
>
> Thank you in advance.
>

OpenStack configuration is complex. The guide does not remotely touch on
production environments. Please do not confuse devstack with production
envionments. Also the doc you linked is not for devstack itself.

The flow in general is: data is generated by the services like nova or
glance. Ceilometer listens on the bus and also polls for information.
The info is sent then over (as configured in publishers.yaml) to gnocchi.
Gnocchi has an api, ceilometer has not. Reading your response, this
makes me suspicious if there is gnocchi running. From the initial
question it suggests it is, from your most recent response, it is not.


Matthias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220303/d6d1fcda/attachment.htm>

From dsmigiel at redhat.com  Thu Mar  3 13:32:33 2022
From: dsmigiel at redhat.com (Dariusz Smigiel)
Date: Thu, 3 Mar 2022 05:32:33 -0800
Subject: [TripleO] Gate blocker for Centos 9 Wallaby
In-Reply-To: <CAA16v18N+tr2VSBTVt3AA_jY92HacjUpMu=5vn8Y3Cg49O_kOg@mail.gmail.com>
References: <CAA16v18N+tr2VSBTVt3AA_jY92HacjUpMu=5vn8Y3Cg49O_kOg@mail.gmail.com>
Message-ID: <CAA16v1_dZwxf3yb8rhG3Mw4CZOsLNCBGcU=0-Vd4iCOKGU-T7g@mail.gmail.com>

> Currently TripleO gate is experiencing issues with building images [1]
> We're aware of the problem, and we're trying to resolve this issue.
>
> Please withhold from rechecking RDO Third Party CI.
>

The fix has been merged. [2[
We should be out of the woods now.

[2]: https://review.opendev.org/c/openstack/tripleo-common/+/831580

Thanks,
dasm


>
> [1]: https://bugs.launchpad.net/tripleo/+bug/1962786



From satish.txt at gmail.com  Thu Mar  3 14:58:43 2022
From: satish.txt at gmail.com (Satish Patel)
Date: Thu, 3 Mar 2022 09:58:43 -0500
Subject: Openstack HPC storage suggestion
In-Reply-To: <CACRvWAtO+_uBjSrDOVyysSVMOVyRa1jX3nRtvxpSO=WryYYD2Q@mail.gmail.com>
References: <CAPgF-frsHAHKWfYqDjYmFqEYv1D7R4QgzRKM_+_oyDNEjt5OaQ@mail.gmail.com>
 <11fc1add-94f4-94a9-c47b-d50672708da0@cnrs.fr>
 <CACRvWAtO+_uBjSrDOVyysSVMOVyRa1jX3nRtvxpSO=WryYYD2Q@mail.gmail.com>
Message-ID: <CAPgF-fosP7Wz_sf4+ZKPaoJHorKKGWWze2Xo3oNpT-FP=nKbcQ@mail.gmail.com>

Thank you folks,

Your inputs are very valuable. Yes, StackHPC is a great source and whenever
I search anything about HPC i endup on their website :)  Thank you Mark for
great work. I would sure like to come and listen to the SIG meetup.

8 year ago I was part of a large HPC project where we had 2000 physical
compute nodes coupled with Infiniband fabric (no openstack) and we were
using an LSF scheduler with Luster and ZFS for backend storage.

This is what I am trying to do with openstack HPC. We built kolla-ansible
using 40 compute nodes which include 20 IB nodes which have infiniband
fabric, 10 GPU nodes and the remaining Memory nodes which have lots of
memory. My clients are students so mostly they are looking for virtualized
HPC where they can reserve resources and build their own cluster using
Slurm, Condor or Spark whatever they want. We are using all virtualized so
Infiniband mellanox configure for SRIOV passthrough to expose directly to
VM. We have a VM-to-VM infiniband network for high speed messaging.

I have put all those stuff in my blog here:
https://satishdotpatel.github.io/HPC-on-openstack/

Now I want to use storage to meet my needs, i don't know at present
because I don't know how and what application they are going to use. let's
say i start with CephFS and folk are not happy then i have to change
storage to Luster or maybe something else. Another question: what people
use from scratch for HPC ( assuming it's going to be a local disk because
of high I/O rate).



On Thu, Mar 3, 2022 at 4:33 AM Manuel Holtgrewe <zyklenfrei at gmail.com>
wrote:

> Hi,
>
> I guess it really depends on what HPC means to you ;-)
>
> Do your users schedule nova instances? Can you actually do Infiniband
> RDMA between nova VMs? Or are your users scheduling ironic instances
> via nova?
>
> We have an openstack setup based on kayobe/kolla where we:
>
> - Deploy 8 hyperconverged OpenStack nova libvirt compute+Ceph storage
> (mostly for block storage and cephfs comes in handy for shared file
> systems, e.g., for shared state in Slurm) servers.
> - Deploy 300+ bare metal compute nodes via ironic.
> - Use Slurm for the job scheduler.
> - Setup everything after the bare OS with Ansible.
> - Have login nodes and slurm scheduler etc. run in nova VMs.
> - Only have Ethernet interconnect (100/25GbE for central switches and
> recent servers and 40/10GbE for older servers).
>
> So we are using OpenStack nova+libvirt as a unified way of deploying
> virtual and physical machines and then install them as we would do
> with normal servers. That's a bit non-cloudy (as far as I have
> learned) but works really well for us.
>
> Now to your HPC storage question... that I hope to answer a bit indirectly.
>
> The main advantage for using manila with CephFS (that I can see) is
> that you get the openstack goodies of API and Horizon clients for
> managing shares. I guess this is mostly useful if you want to have
> cloud features for your HPC such as users allocating storage in
> self-service to their nova/ironic machines. We come from a classic HPC
> setting where the partitioning of the system is not done by creating
> multiple nodes/clusters by users in self-service, but rather
> administration provides a bare metal cluster with Slurm scheduler.
> Users log in to head nodes and submit jobs to the compute nodes to
> Slurm. Thus Slurm does the managing of resources and users can
> allocate single cores up to the whole cluster. So in our use case
> there would not be a major advantage of using manila for our storage
> as we would primarily have one export that gives access to the whole
> storage ;-).
>
> We currently have an old GPFS storage that we mount on all nodes via
> Ansible. We are currently migrating to using an additional, dedicated
> NVME-based ceph cluster (that is not hyperconverged with our compute)
> and that we would also mount via Ansible. As we essentially only have
> a single share on this storage managing the share with manila would be
> more trouble than work. The much more important part will be setting
> up Ceph appropriately and tuning it to perform well (e.g., using the
> IO500 benchmark as the croit people demonstrate here [1]).
>
> I guess that does not really answer your question but I hope that it
> gives useful perspective to you and maybe others.
>
> You can look at the work of the wonderful people of StackHPC that
> provide commercial services around Openstack/Kayobe/Kolla/Ironic for
> HPC setups. There are a couple of interesting videos involving their
> staff and they have very useful information on the web site as well.
> And as Mark Goddard just wrote you can have a look at the Scientific
> SIG where they are involved as well. (I'm not in any way related to
> StackHPC, I just really like their work).
>
> Best wishes,
> Manuel
>
> [1] https://croit.io/blog/ceph-performance-test-and-optimization
>
> On Thu, Mar 3, 2022 at 9:25 AM Mahendra Paipuri
> <mahendra.paipuri at cnrs.fr> wrote:
> >
> > Hello,
> >
> > We are quite interested in this too. When we were looking into existing
> > solutions, we found there has been some work in integrating LUSTRE into
> > OpenStack [1], [2]. I remember coming across some Openinfra talks on
> > developing a manila backend driver for LUSTRE. I am not quite sure if
> > this project is still ongoing. Manila already provides a backend driver
> > for GPFS [3] (unfortunately GPFS is not opensource) to readily integrate
> > it into Openstack. Manila supports GlusterFS and CephFS as well but they
> > do not have RDMA support (if I am not wrong).
> >
> > This is pretty much what we found. Would be glad explore more solutions
> > if someone knows any.
> >
> > Cheers
> >
> > -
> >
> > Mahendra
> >
> > [1]
> >
> https://docs.google.com/presentation/d/1kGRzcdVQX95abei1bDVoRzxyC02i89_m5_sOfp8Aq6o/htmlpresent
> >
> > [2]
> >
> https://www.openstack.org/videos/summits/barcelona-2016/lustre-integration-for-hpc-on-openstack-at-cambridge-and-monash
> >
> > [3] https://docs.openstack.org/manila/latest/admin/gpfs_driver.html
> >
> > On 03/03/2022 04:47, Satish Patel wrote:
> > > Folks,
> > >
> > > I built a 30 node HPC environment on openstack using mellanox
> > > infiniband nic for high speed MPI messaging. So far everything works.
> > > Now I am looking for a HPC PFS (parallel file system)  similar to
> > > Luster which I can mount on all HPC vms to run MPI jobs.
> > >
> > > I was reading on google and saw some CERN videos and they are using
> > > Ceph (cephfs) for PFS. Also i was reading CephFS + Manila is a good
> > > choice for HPC on openstack design.
> > >
> > > Does anyone have any experience with HPC storage for Openstack? Please
> > > advice or share your experience :)  Thanks in advance.
> > >
> > > ~S
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220303/07355a59/attachment-0001.htm>

From katonalala at gmail.com  Thu Mar  3 20:44:51 2022
From: katonalala at gmail.com (Lajos Katona)
Date: Thu, 3 Mar 2022 21:44:51 +0100
Subject: [neutron] Drivers meeting agenda - 04.03.2022.
Message-ID: <CALg0jKnAVuz_tHa3VdSgc5BSvZX21wAKGBfY-b=duST9aGeLVw@mail.gmail.com>

Hi Neutron Drivers,

The agenda for tomorrow's drivers meeting is at [1].
* Gratuitous ARPs are not sent during master transition: (
https://bugs.launchpad.net/neutron/+bug/1952907)
** For this one there are a few wip patches:
** https://review.opendev.org/c/openstack/neutron/+/821434
** https://review.opendev.org/c/openstack/neutron/+/821433
** https://review.opendev.org/c/openstack/neutron/+/712474

* On Demand agenda:
(ralonsoh): https://bugs.launchpad.net/neutron/+bug/1962465. I want to
discuss the scope of this bug and the possible fix.

[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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220303/2fa7b4c3/attachment.htm>

From iurygregory at gmail.com  Fri Mar  4 03:23:04 2022
From: iurygregory at gmail.com (Iury Gregory)
Date: Fri, 4 Mar 2022 03:23:04 +0000
Subject: [ironic] Zed PTG slots
Message-ID: <CAJqPaj8M4BgPpsQPG9mtvnXkbHPVtSeK3cG1Ws+aaeC1skRsgw@mail.gmail.com>

Hello Ironicers!

For the Zed PTG I'm planning to have some slots that will allow APAC
contributors to participate in the discussions.

Keep in mind that we have some guidelines we should try to follow:
1. Cross project discussions (like SIGs or support project teams) should be
scheduled towards the start of the week so that any discussions that might
shape those of other teams happen first.
2. No team should sign up for more than 4 hours per UTC day to help keep
participants actively engaged.
3. No team should sign up for more than 16 hours across all time slots to
avoid burning out our contributors and to enable participation in multiple
teams discussions.

Based on this I have the following proposals: (Feel free to provide more
ideas also) =)
 *Option  #1* *16hrs* Monday till Thursday
1h (APAC night + EMEA morning)
2hrs (EMEA afternoon + NA morning)
1hr (NA afternoon/night + APAC morning)

*Option  #2* *15hrs* Tuesday till Friday
1h (APAC night + EMEA morning)
2hrs (EMEA afternoon + NA morning)
1hr (NA afternoon/night + APAC morning)
* On Friday the NA + APAC session won't happen because is saturday for APAC
contributors *

*Option #3* *16hrs* Monday till Thursday
3hrs (EMEA afternoon + NA morning)
1hr (NA afternoon/night + APAC morning)

*Option #4* *15hrs* Tuesday till Friday
3hrs (EMEA afternoon + NA morning)
1hr (NA afternoon/night + APAC morning)
* On Friday the NA + APAC session won't happen because is saturday for APAC
contributors *

Please choose two options and we will vote during our upstream meeting on
March 7th.

Thank you!

-- 


*Att[]'sIury Gregory Melo Ferreira *
*MSc in Computer Science at UFCG*
*Part of the ironic-core and puppet-manager-core team in OpenStack*
*Software Engineer at Red Hat Czech*
*Social*: https://www.linkedin.com/in/iurygregory
*E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/1247336d/attachment.htm>

From hanguangyu2 at gmail.com  Fri Mar  4 07:54:18 2022
From: hanguangyu2 at gmail.com (=?UTF-8?B?6Z+p5YWJ5a6H?=)
Date: Fri, 4 Mar 2022 15:54:18 +0800
Subject: [Ironic] No suitable device was found for deployment
In-Reply-To: <CAF7gwdhXXWA_Q0ZO57w24oCY7FoeuxMwah7shRj_tEdpeBPiMw@mail.gmail.com>
References: <CAOirdiX4RuYYdzmDWBp0Ofua0B6BV0mGat0YWnwZZwebmMOeQQ@mail.gmail.com>
 <fbcd7e11-e4b4-6022-0b5e-df42b1d9b998@cern.ch>
 <CAOirdiV8s80SYcbtZ8G4-VCMs9OGvfeVy=CF-d8V0Fw0N9xO0g@mail.gmail.com>
 <04af20bb-143b-9b56-6787-d5ac6ab0d38c@cern.ch>
 <CAF7gwdgkJiXShCM0z1ZyERj0=Z63713Xy6JXctwazNobqvxqVw@mail.gmail.com>
 <CAOirdiUPkXOVZDg8DgrOMDeK8xJxPGcbsu4Y+XPVCbbjJOGCDg@mail.gmail.com>
 <ca926b29-9dff-cceb-5734-7d510a48a045@cern.ch>
 <CAOirdiUEO+yE1=KN-kEVLR3sRBY15weFjc_kRzMEboS=UjZ-gA@mail.gmail.com>
 <3209d9fc-8db1-6dca-5736-402c6f082fcc@cern.ch>
 <CAF7gwdhXXWA_Q0ZO57w24oCY7FoeuxMwah7shRj_tEdpeBPiMw@mail.gmail.com>
Message-ID: <CAOirdiW8x0pdjSKXYoY6D-hkj5gHQsS9NPUvn_nao0A-2zZ-jg@mail.gmail.com>

Hi Julia and Arne,

> Did cleaning fail at any given point with these machines?
Sorry that I didn't describe it clearly. Actually, clean is alway
success in ironic log, deploying is failed.  I just wonder if the
cleaning phase did something that caused disk identification problems.

And I have found the RAID config menu. In my machine, I need to prase
"Ctrl + R"  when  RAID interface appear in machine boot.
Thank you very much~! In RAID config menu, I found that the state of
three disk is UB(unconfig bad).

So, if I use the Ironic service to install an operating system for a
server that has three hard disks in the 'JBOD' state, is there
anything I should pay attention to or operate? If I don't do something
for this, deploying stage give me an error 'No suitable device was
found for deployment' and 'lslbk' is empty. After clean successed and
deploy faided, the disk state is "Unconfigured bad".

best wishes to you,
Han Guangyu

Julia Kreger <juliaashleykreger at gmail.com> ?2022?3?1??? 22:06???


>
> On Mon, Feb 28, 2022 at 1:12 AM Arne Wiebalck <arne.wiebalck at cern.ch> wrote:
> >
> > Hi Guangyu,
> >
> > I am not aware of anything in the Ironic Python Agent that
> > would remove disks from the system in a way that they would
> > not be visible after a reboot (apart from, as mentioned before,
> > the clean up of a hardware RAID in a way the IPA is not able
> > to see any devices after).
> >
> > How about trying to access and configure the hardware RAID with
> > the corresponding tool from the RAM disk you booted into from the
> > USB stick? Install the tool and see if it detects the controller.
> >
> > The very first step before doing anything with Ironic is to
> > get the disks back or understand why they are not visible.
> >
>
> Did cleaning fail at any given point with these machines?
>
> If you have physical access, try disconnecting all of the drives, and
> then powering up the machine and see if you can get into the firmware
> configuration screen with control-h. If you can, remove all of the
> prior configuration or disk volumes. They will look like they are in
> error states most likely. If your unable to get into this screen, I
> would be worried about your disk controller card. If your able to
> clear everything out of the controller, power off, try re-inserting
> drives, and see what happens. See if the controller can view/interact
> with the drives. If it sees no drives, then my next paragraph is
> likely the case.
>
> The disks sound like they might be in security locked state which will
> likely require a desktop SATA disk controller to remedy by attaching
> and manually removing from a security locked state. Megaraid
> controllers can't recognize security locked devices (most controllers
> and especially ones labeled "raid controllers" can't handle it) when
> in pass-through mode, but I've never heard of security lock commands
> actually getting through to the device with those controllers in
> pass-through mode. If the card was in raid mode to begin with, then it
> likely never did anything involving secure erase as the controller
> should not be offering that as a feature of provided disks to the OS.
>
> > Cheers,
> >   Arne
> >
> > On 28.02.22 09:28, ??? wrote:
> > > Hi Arne,
> > >
> > > I didn't find hardware RAID config option during the initial boot
> > > sequence. Ctrl+H is unresponsive in this computer. I just saw "Press
> > > Del to enter firmware configuration, press F3 to enter boot menu, and
> > > press F12 to enter network boot". And I press 'Del' to enter the BIOS.
> > > But I didn't find RAID config menu in BIOS. Sorry that I have poor
> > > knowledge about this.
> > >
> > > And now, even though I installed the operating system manually using a
> > > USB stick, I still couldn't find the hard drive. Is there anything
> > > that ironic-agent did in the clean phase that would have caused this
> > > problem?
> > >
> > > I wonder if this is a thinking pointto solve the problem. Now, my idea
> > > is to first find a way to manually configure RAID.  Do you agree with
> > > this?  And than, whether RAID configurations are still cleared in the
> > > Clean phase if clean phase will do this?
> > >
> > > Sorry that I have so much confuse.
> > >
> > > love you,
> > > Guangyu
> > >
> > > Arne Wiebalck <arne.wiebalck at cern.ch> ?2022?2?14??? 15:59???
> > >>
> > >> Hi Guangyu,
> > >>
> > >> It seems like Julia had the right idea and the disks
> > >> are not visible since the RAID controller does not
> > >> expose anything to the operating system. This seems
> > >> to be confirmed by you booting into the CentOS7 image.
> > >>
> > >> What I would suggest to try next is to look for the
> > >> hardware RAID config option during the initial boot
> > >> sequence to enter the RAID config menu (there should be
> > >> a message quite early on, and maybe Ctrl-H is needed
> > >> to enter the menu).
> > >>
> > >> Once there, manually configure the disks as JBODs or
> > >> create a RAID device. Upon reboot this should be visible
> > >> and accessible as a device. Maybe check from your CentOS7
> > >> image again. If the devices are there, Ironic should
> > >> also be able to deploy on them (for this you can remove
> > >> the RAID config you added).
> > >>
> > >> It depends a little on what your goal is, but I would
> > >> try this first to see if you can make a device visible
> > >> and if the Ironic deploy bit works, before trying to
> > >> configure the hardware RAID via Ironic.
> > >>
> > >> Cheers,
> > >>    Arne
> > >>
> > >> On 14.02.22 03:20, ??? wrote:
> > >>> Hi Arne and Julia,
> > >>>
> > >>> You make me feel so warm. Best wishes to you.
> > >>>
> > >>> I have tried to boot the node into a CentOS7, but it still coundnot to
> > >>> find disk. And sorry that I didn't notice the RAID card.
> > >>>
> > >>> # lspci -v
> > >>> ...
> > >>> 23:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS-3 3108
> > >>> [Invader] (rev 02)
> > >>>           Subsystem: Broadcom / LSI MegaRAID SAS 9361-8i
> > >>>           Flags: bus master, fast devsel, latency 0, IRQ -2147483648, NUMA node 1
> > >>>           I/O ports at 3000 [size=256]
> > >>>           Memory at e9900000 (64-bit, non-prefetchable) [size=64K]
> > >>>           Memory at e9700000 (64-bit, non-prefetchable) [size=1M]
> > >>>           Expansion ROM at e9800000 [disabled] [size=1M]
> > >>>           Capabilities: [50] Power Management version 3
> > >>>           Capabilities: [68] Express Endpoint, MSI 00
> > >>>           Capabilities: [d0] Vital Product Data
> > >>>           Capabilities: [a8] MSI: Enable- Count=1/1 Maskable+ 64bit+
> > >>>           Capabilities: [c0] MSI-X: Enable+ Count=97 Masked-
> > >>>           Capabilities: [100] Advanced Error Reporting
> > >>>           Capabilities: [1e0] #19
> > >>>           Capabilities: [1c0] Power Budgeting <?>
> > >>>           Capabilities: [148] Alternative Routing-ID Interpretation (ARI)
> > >>>           Kernel driver in use: megaraid_sas
> > >>>           Kernel modules: megaraid_sas
> > >>> ...
> > >>>
> > >>> I try to config raid fallowing
> > >>> https://docs.openstack.org/ironic/latest/admin/raid.html
> > >>> by `baremetal node set $NODE_UUID --target-raid-config raid.json`. The
> > >>> server have  three same disk(Western Digital DC HA210 2TB SATA 6GB/s)
> > >>> # cat raid.json
> > >>> {
> > >>>     "logical_disks": [
> > >>>       {
> > >>>         "size_gb": "MAX",
> > >>>         "raid_level": "0",
> > >>>         "is_root_volume": true
> > >>>       }
> > >>>     ]
> > >>> }
> > >>>
> > >>> But Ironic still coundn't see disk. I still got
> > >>> ```
> > >>> ## In deploy images
> > >>> # journalctl -fxeu ironic-python-agent
> > >>> Feb 14 02:17:22 host-10-12-22-74 ironic-python-agent[2329]: 2022-02-14
> > >>> 02:17:22.863 2329 WARNING root [-] Path /dev/disk/by-path is
> > >>> inaccessible, /dev/disk/by-path/* version of block device name is
> > >>> unavailable Cause: [Errno 2] No such file or directory:
> > >>> '/dev/disk/by-path': FileNotFoundError: [Errno 2] No such file or
> > >>> directory: '/dev/disk/by-path'
> > >>> Feb 14 02:17:44 host-10-12-22-74 ironic-python-agent[2329]: 2022-02-14
> > >>> 02:17:44.391 2329 ERROR root [-] Unexpected error dispatching
> > >>> get_os_install_device to manager
> > >>> <ironic_python_agent.hardware.GenericHardwareManager object at
> > >>> 0x7efbf4da2208>: Error finding the disk or partition device to deploy
> > >>> the image onto: No suitable device was found for deployment - root
> > >>> device hints were not provided and all found block devices are smaller
> > >>> than 4294967296B.: ironic_python_agent.errors.DeviceNotFound: Error
> > >>> finding the disk or partition device to deploy the image onto: No
> > >>> suitable device was found for deployment - root device hints were not
> > >>> provided and all found block devices are smaller than 4294967296B.
> > >>> ```
> > >>>
> > >>> I don't know if it's a lack of a RAID card driver or a lack of a disk
> > >>> driver or a lack of RAID configuration. Could you have some idea about
> > >>> this question?
> > >>>
> > >>> love you,
> > >>> Han Guangyu
> > >>>
> > >>>
> > >>> Julia Kreger <juliaashleykreger at gmail.com> ?2022?2?10??? 23:11???
> > >>>
> > >>>>
> > >>>> If the disk controllers *are* enumerated in the kernel log, which is
> > >>>> something to also look for, then the disks themselves may be in some
> > >>>> weird state like security locked. Generally this shows up as the
> > >>>> operating system kind of sees the disk and the SATA port connected but
> > >>>> can't really access it. This is also an exceptionally rare state to
> > >>>> find one's self in.
> > >>>>
> > >>>> More common, especially in enterprise grade hardware: If the disk
> > >>>> controller is actually a raid controller, and there are no raid
> > >>>> volumes configured, then the operating system likely cannot see the
> > >>>> underlying disks and turn that into a usable block device. I've seen a
> > >>>> couple drivers over the years which expose hints of disks in the
> > >>>> kernel log and without raid configuration in the cards, the drivers
> > >>>> can't present usable block devices to the operating system system.
> > >>>>
> > >>>> -Julia
> > >>>>
> > >>>> On Thu, Feb 10, 2022 at 3:17 AM Arne Wiebalck <arne.wiebalck at cern.ch> wrote:
> > >>>>>
> > >>>>> Hi Guangyu,
> > >>>>>
> > >>>>> No worries about asking questions, this is what the mailing
> > >>>>> list is for :)
> > >>>>>
> > >>>>> Just to clarify, you do not have to set root device hints,
> > >>>>> it also works without (with the algorithm I mentioned).
> > >>>>> However, hints help to define the exact device and/or make
> > >>>>> deployment more predictable/repeatable.
> > >>>>>
> > >>>>> If it is really a driver problem, it is an issue with the
> > >>>>> operating system of the image you use, i.e. CentOS8. Some
> > >>>>> drivers were removed from 7 to 8, and we have seen issues
> > >>>>> with specific drive models as well.
> > >>>>>
> > >>>>> You can try to build your own IPA images as described in
> > >>>>> [1], e.g. to add your ssh key to be able to log into the
> > >>>>> IPA to debug further, and to eventually include drivers
> > >>>>> (if you can identify them and they are available for CentOS8).
> > >>>>>
> > >>>>> Another option may be to add another (newer) disk model to
> > >>>>> the server, just to confirm it is the disk model/driver which
> > >>>>> is the cause.
> > >>>>>
> > >>>>> You could also try to boot the node into a CentOS7 (and then
> > >>>>> a CentOS8) live image to confirm it can see the disks at all.
> > >>>>>
> > >>>>> Hope this helps!
> > >>>>>     Arne
> > >>>>>
> > >>>>> [1]
> > >>>>> https://docs.openstack.org/ironic-python-agent-builder/latest/admin/dib.html
> > >>>>>
> > >>>>>
> > >>>>> On 10.02.22 11:15, ??? wrote:
> > >>>>>> Hi Arne,
> > >>>>>>
> > >>>>>> Thank you very much for your response. Love you. You take away a lot
> > >>>>>> of my confusion.
> > >>>>>>
> > >>>>>> You are right, I didn't set 'root device'. And Ironic also can not see
> > >>>>>> disk, the content of the 'lsblk' file in the deploy los is emply.
> > >>>>>> I tried to set 'root device', but because ironic can't find any disk,
> > >>>>>> the deploy still filed.
> > >>>>>>
> > >>>>>> Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
> > >>>>>> 09:51:55.045 2324 WARNING root [-] Path /dev/disk/by-path is
> > >>>>>> inaccessible, /dev/disk/by-path/* version of block device name is
> > >>>>>> unavailable Cause: [Errno 2] No such file or directory:
> > >>>>>> '/dev/disk/by-path': FileNotFoundError: [Errno 2] No such file or
> > >>>>>> directory: '/dev/disk/by-path'
> > >>>>>> Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
> > >>>>>> 09:51:55.056 2324 WARNING ironic_lib.utils [-] No device found that
> > >>>>>> matches the root device hints {'wwn': '0x50014EE2691D724C'}:
> > >>>>>> StopIteration
> > >>>>>>
> > >>>>>> Sorry to bother you, I'm a newcomer of Ironic and I didn't find
> > >>>>>> information about it on google.
> > >>>>>>
> > >>>>>> The bare metal node have three same disk(Western Digital DC HA210 2TB
> > >>>>>> SATA 6GB/s). Where I can confirm whether ironic-python-agent supports
> > >>>>>> this disk?
> > >>>>>>
> > >>>>>> And If Ironic cannot find disk since the corresponding drivers in the
> > >>>>>> IPA image are missing, do you know how to resolve it? I have used the
> > >>>>>> latest deploy images in
> > >>>>>> https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/
> > >>>>>> .  Do I need to find and manually add driver in the source code or
> > >>>>>> ramdisk(That was difficult tome)?
> > >>>>>>
> > >>>>>> Love you.
> > >>>>>>
> > >>>>>> Cheers,
> > >>>>>> Guangyu
> > >>>>>>
> > >>>>>> Arne Wiebalck <arne.wiebalck at cern.ch> ?2022?2?10??? 15:51???
> > >>>>>>>
> > >>>>>>> Hi Guangyu,
> > >>>>>>>
> > >>>>>>> The error indicates that Ironic was not able to find
> > >>>>>>> a device where it could deploy the image to.
> > >>>>>>>
> > >>>>>>> To find a device, Ironic will use 'root device'
> > >>>>>>> hints [1], usually set by the admin on a node. If that
> > >>>>>>> does not yield anything, Ironic will loop over all
> > >>>>>>> block devices and pick the smallest which is larger
> > >>>>>>> than 4GB (and order them alphabetically).
> > >>>>>>>
> > >>>>>>> If you have disks in your server which are larger than
> > >>>>>>> 4GB, one potential explanation is that Ironic cannot see them,
> > >>>>>>> e.g. since the corresponding drivers in the IPA image are missing.
> > >>>>>>> The logs you posted seem to confirm something along those
> > >>>>>>> lines.
> > >>>>>>>
> > >>>>>>> Check the content of the 'lsblk' file in the deploy logs which
> > >>>>>>> you can find in the tar archive in /var/log/ironic/deploy/
> > >>>>>>> on the controller for your deployment attempt to see what
> > >>>>>>> devices Ironic has access to.
> > >>>>>>>
> > >>>>>>> Cheers,
> > >>>>>>>      Arne
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> [1] https://docs.openstack.org/ironic/latest/install/advanced.html#root-device-hints
> > >>>>>>>
> > >>>>>>> On 10.02.22 02:50, ??? wrote:
> > >>>>>>>> Dear all,
> > >>>>>>>>
> > >>>>>>>> I have a OpenStack Victoria environment, and tried to use ironic
> > >>>>>>>> manage bare metal. But I got "- root device hints were not provided
> > >>>>>>>> and all found block devices are smaller than 4294967296B." in deploy
> > >>>>>>>> stage.
> > >>>>>>>>
> > >>>>>>>> 2022-02-09 17:57:56.492 3908982 ERROR
> > >>>>>>>> ironic.drivers.modules.agent_base [-] Agent returned error for deploy
> > >>>>>>>> step {'step': 'write_image', 'priority': 80, 'argsinfo': None,
> > >>>>>>>> 'interface': 'deploy'} on node cc68c450-ce54-4e1c-be04-8b0a6169ef92 :
> > >>>>>>>> No suitable device was found for deployment - root device hints were
> > >>>>>>>> not provided and all found block devices are smaller than
> > >>>>>>>> 4294967296B..
> > >>>>>>>>
> > >>>>>>>> I used "openstack server create --flavor my-baremetal-flavor --nic
> > >>>>>>>> net-id=$net_id --image $image testing" to deploy bare metal node.  I
> > >>>>>>>> download deploy images(ipa-centos8-master.kernel and
> > >>>>>>>> ipa-centos8-master.initramfs) in
> > >>>>>>>> https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/.
> > >>>>>>>>
> > >>>>>>>> The baremetal node info and flavor info as following:
> > >>>>>>>> https://paste.opendev.org/show/bV7lgO6RkNQY6ZGPbT2e/
> > >>>>>>>> Ironic configure file as following:
> > >>>>>>>> https://paste.opendev.org/show/bTgY9Kpn7KWqwQl73aEa/
> > >>>>>>>> Ironic-conductor log:    https://paste.opendev.org/show/bFKZYlXmccxNxU8lEogk/
> > >>>>>>>> The log of ironic-python-agent in bare metal node:
> > >>>>>>>> https://paste.opendev.org/show/btAuaMuV2IutV2Pa7YIa/
> > >>>>>>>>
> > >>>>>>>> I see some old discussion about this, such as:
> > >>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1312187. But those
> > >>>>>>>> discussions took place a long time ago, not version V, and no solution
> > >>>>>>>> was seen.
> > >>>>>>>>
> > >>>>>>>> Does anyone know how to solve this problem? I would appreciate any
> > >>>>>>>> kind of guidance or help.
> > >>>>>>>>
> > >>>>>>>> Thank you,
> > >>>>>>>> Han Guangyu
> > >>>>>>>>
> > >>>>>


From arne.wiebalck at cern.ch  Fri Mar  4 08:37:19 2022
From: arne.wiebalck at cern.ch (Arne Wiebalck)
Date: Fri, 4 Mar 2022 09:37:19 +0100
Subject: [Ironic] No suitable device was found for deployment
In-Reply-To: <CAOirdiW8x0pdjSKXYoY6D-hkj5gHQsS9NPUvn_nao0A-2zZ-jg@mail.gmail.com>
References: <CAOirdiX4RuYYdzmDWBp0Ofua0B6BV0mGat0YWnwZZwebmMOeQQ@mail.gmail.com>
 <fbcd7e11-e4b4-6022-0b5e-df42b1d9b998@cern.ch>
 <CAOirdiV8s80SYcbtZ8G4-VCMs9OGvfeVy=CF-d8V0Fw0N9xO0g@mail.gmail.com>
 <04af20bb-143b-9b56-6787-d5ac6ab0d38c@cern.ch>
 <CAF7gwdgkJiXShCM0z1ZyERj0=Z63713Xy6JXctwazNobqvxqVw@mail.gmail.com>
 <CAOirdiUPkXOVZDg8DgrOMDeK8xJxPGcbsu4Y+XPVCbbjJOGCDg@mail.gmail.com>
 <ca926b29-9dff-cceb-5734-7d510a48a045@cern.ch>
 <CAOirdiUEO+yE1=KN-kEVLR3sRBY15weFjc_kRzMEboS=UjZ-gA@mail.gmail.com>
 <3209d9fc-8db1-6dca-5736-402c6f082fcc@cern.ch>
 <CAF7gwdhXXWA_Q0ZO57w24oCY7FoeuxMwah7shRj_tEdpeBPiMw@mail.gmail.com>
 <CAOirdiW8x0pdjSKXYoY6D-hkj5gHQsS9NPUvn_nao0A-2zZ-jg@mail.gmail.com>
Message-ID: <3542bf93-7e9c-9af6-88e5-99ec6a3fe34f@cern.ch>

Hi Guangyu,

I would think cleaning succeeds even if there are no disks:
the loop to clean the disks is simply empty, so nothing to
do, success! :) Deployment then fails since it needs a disk
to deploy on.

For my understanding:
You reconfigured the disks into JBOD state and then retried
to deploy (which failed and the disks fell back into UB state)?

JBOD mode should work, but is usually not the main mode h/w
RAID controllers work in. One thing to try is to actually
configure a RAID-0 or RAID-1 device from your three disks and
retry to deploy.

I am not totally sure if Ironic would try to remove such a h/w
RAID config during cleaning, but Julia will be able to tell.

Cheers,
  Arne

On 04.03.22 08:54, ??? wrote:
> Hi Julia and Arne,
> 
>> Did cleaning fail at any given point with these machines?
> Sorry that I didn't describe it clearly. Actually, clean is alway
> success in ironic log, deploying is failed.  I just wonder if the
> cleaning phase did something that caused disk identification problems.
> 
> And I have found the RAID config menu. In my machine, I need to prase
> "Ctrl + R"  when  RAID interface appear in machine boot.
> Thank you very much~! In RAID config menu, I found that the state of
> three disk is UB(unconfig bad).
> 
> So, if I use the Ironic service to install an operating system for a
> server that has three hard disks in the 'JBOD' state, is there
> anything I should pay attention to or operate? If I don't do something
> for this, deploying stage give me an error 'No suitable device was
> found for deployment' and 'lslbk' is empty. After clean successed and
> deploy faided, the disk state is "Unconfigured bad".
> 
> best wishes to you,
> Han Guangyu
> 
> Julia Kreger <juliaashleykreger at gmail.com> ?2022?3?1??? 22:06???
> 
> 
>>
>> On Mon, Feb 28, 2022 at 1:12 AM Arne Wiebalck <arne.wiebalck at cern.ch> wrote:
>>>
>>> Hi Guangyu,
>>>
>>> I am not aware of anything in the Ironic Python Agent that
>>> would remove disks from the system in a way that they would
>>> not be visible after a reboot (apart from, as mentioned before,
>>> the clean up of a hardware RAID in a way the IPA is not able
>>> to see any devices after).
>>>
>>> How about trying to access and configure the hardware RAID with
>>> the corresponding tool from the RAM disk you booted into from the
>>> USB stick? Install the tool and see if it detects the controller.
>>>
>>> The very first step before doing anything with Ironic is to
>>> get the disks back or understand why they are not visible.
>>>
>>
>> Did cleaning fail at any given point with these machines?
>>
>> If you have physical access, try disconnecting all of the drives, and
>> then powering up the machine and see if you can get into the firmware
>> configuration screen with control-h. If you can, remove all of the
>> prior configuration or disk volumes. They will look like they are in
>> error states most likely. If your unable to get into this screen, I
>> would be worried about your disk controller card. If your able to
>> clear everything out of the controller, power off, try re-inserting
>> drives, and see what happens. See if the controller can view/interact
>> with the drives. If it sees no drives, then my next paragraph is
>> likely the case.
>>
>> The disks sound like they might be in security locked state which will
>> likely require a desktop SATA disk controller to remedy by attaching
>> and manually removing from a security locked state. Megaraid
>> controllers can't recognize security locked devices (most controllers
>> and especially ones labeled "raid controllers" can't handle it) when
>> in pass-through mode, but I've never heard of security lock commands
>> actually getting through to the device with those controllers in
>> pass-through mode. If the card was in raid mode to begin with, then it
>> likely never did anything involving secure erase as the controller
>> should not be offering that as a feature of provided disks to the OS.
>>
>>> Cheers,
>>>    Arne
>>>
>>> On 28.02.22 09:28, ??? wrote:
>>>> Hi Arne,
>>>>
>>>> I didn't find hardware RAID config option during the initial boot
>>>> sequence. Ctrl+H is unresponsive in this computer. I just saw "Press
>>>> Del to enter firmware configuration, press F3 to enter boot menu, and
>>>> press F12 to enter network boot". And I press 'Del' to enter the BIOS.
>>>> But I didn't find RAID config menu in BIOS. Sorry that I have poor
>>>> knowledge about this.
>>>>
>>>> And now, even though I installed the operating system manually using a
>>>> USB stick, I still couldn't find the hard drive. Is there anything
>>>> that ironic-agent did in the clean phase that would have caused this
>>>> problem?
>>>>
>>>> I wonder if this is a thinking pointto solve the problem. Now, my idea
>>>> is to first find a way to manually configure RAID.  Do you agree with
>>>> this?  And than, whether RAID configurations are still cleared in the
>>>> Clean phase if clean phase will do this?
>>>>
>>>> Sorry that I have so much confuse.
>>>>
>>>> love you,
>>>> Guangyu
>>>>
>>>> Arne Wiebalck <arne.wiebalck at cern.ch> ?2022?2?14??? 15:59???
>>>>>
>>>>> Hi Guangyu,
>>>>>
>>>>> It seems like Julia had the right idea and the disks
>>>>> are not visible since the RAID controller does not
>>>>> expose anything to the operating system. This seems
>>>>> to be confirmed by you booting into the CentOS7 image.
>>>>>
>>>>> What I would suggest to try next is to look for the
>>>>> hardware RAID config option during the initial boot
>>>>> sequence to enter the RAID config menu (there should be
>>>>> a message quite early on, and maybe Ctrl-H is needed
>>>>> to enter the menu).
>>>>>
>>>>> Once there, manually configure the disks as JBODs or
>>>>> create a RAID device. Upon reboot this should be visible
>>>>> and accessible as a device. Maybe check from your CentOS7
>>>>> image again. If the devices are there, Ironic should
>>>>> also be able to deploy on them (for this you can remove
>>>>> the RAID config you added).
>>>>>
>>>>> It depends a little on what your goal is, but I would
>>>>> try this first to see if you can make a device visible
>>>>> and if the Ironic deploy bit works, before trying to
>>>>> configure the hardware RAID via Ironic.
>>>>>
>>>>> Cheers,
>>>>>     Arne
>>>>>
>>>>> On 14.02.22 03:20, ??? wrote:
>>>>>> Hi Arne and Julia,
>>>>>>
>>>>>> You make me feel so warm. Best wishes to you.
>>>>>>
>>>>>> I have tried to boot the node into a CentOS7, but it still coundnot to
>>>>>> find disk. And sorry that I didn't notice the RAID card.
>>>>>>
>>>>>> # lspci -v
>>>>>> ...
>>>>>> 23:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS-3 3108
>>>>>> [Invader] (rev 02)
>>>>>>            Subsystem: Broadcom / LSI MegaRAID SAS 9361-8i
>>>>>>            Flags: bus master, fast devsel, latency 0, IRQ -2147483648, NUMA node 1
>>>>>>            I/O ports at 3000 [size=256]
>>>>>>            Memory at e9900000 (64-bit, non-prefetchable) [size=64K]
>>>>>>            Memory at e9700000 (64-bit, non-prefetchable) [size=1M]
>>>>>>            Expansion ROM at e9800000 [disabled] [size=1M]
>>>>>>            Capabilities: [50] Power Management version 3
>>>>>>            Capabilities: [68] Express Endpoint, MSI 00
>>>>>>            Capabilities: [d0] Vital Product Data
>>>>>>            Capabilities: [a8] MSI: Enable- Count=1/1 Maskable+ 64bit+
>>>>>>            Capabilities: [c0] MSI-X: Enable+ Count=97 Masked-
>>>>>>            Capabilities: [100] Advanced Error Reporting
>>>>>>            Capabilities: [1e0] #19
>>>>>>            Capabilities: [1c0] Power Budgeting <?>
>>>>>>            Capabilities: [148] Alternative Routing-ID Interpretation (ARI)
>>>>>>            Kernel driver in use: megaraid_sas
>>>>>>            Kernel modules: megaraid_sas
>>>>>> ...
>>>>>>
>>>>>> I try to config raid fallowing
>>>>>> https://docs.openstack.org/ironic/latest/admin/raid.html
>>>>>> by `baremetal node set $NODE_UUID --target-raid-config raid.json`. The
>>>>>> server have  three same disk(Western Digital DC HA210 2TB SATA 6GB/s)
>>>>>> # cat raid.json
>>>>>> {
>>>>>>      "logical_disks": [
>>>>>>        {
>>>>>>          "size_gb": "MAX",
>>>>>>          "raid_level": "0",
>>>>>>          "is_root_volume": true
>>>>>>        }
>>>>>>      ]
>>>>>> }
>>>>>>
>>>>>> But Ironic still coundn't see disk. I still got
>>>>>> ```
>>>>>> ## In deploy images
>>>>>> # journalctl -fxeu ironic-python-agent
>>>>>> Feb 14 02:17:22 host-10-12-22-74 ironic-python-agent[2329]: 2022-02-14
>>>>>> 02:17:22.863 2329 WARNING root [-] Path /dev/disk/by-path is
>>>>>> inaccessible, /dev/disk/by-path/* version of block device name is
>>>>>> unavailable Cause: [Errno 2] No such file or directory:
>>>>>> '/dev/disk/by-path': FileNotFoundError: [Errno 2] No such file or
>>>>>> directory: '/dev/disk/by-path'
>>>>>> Feb 14 02:17:44 host-10-12-22-74 ironic-python-agent[2329]: 2022-02-14
>>>>>> 02:17:44.391 2329 ERROR root [-] Unexpected error dispatching
>>>>>> get_os_install_device to manager
>>>>>> <ironic_python_agent.hardware.GenericHardwareManager object at
>>>>>> 0x7efbf4da2208>: Error finding the disk or partition device to deploy
>>>>>> the image onto: No suitable device was found for deployment - root
>>>>>> device hints were not provided and all found block devices are smaller
>>>>>> than 4294967296B.: ironic_python_agent.errors.DeviceNotFound: Error
>>>>>> finding the disk or partition device to deploy the image onto: No
>>>>>> suitable device was found for deployment - root device hints were not
>>>>>> provided and all found block devices are smaller than 4294967296B.
>>>>>> ```
>>>>>>
>>>>>> I don't know if it's a lack of a RAID card driver or a lack of a disk
>>>>>> driver or a lack of RAID configuration. Could you have some idea about
>>>>>> this question?
>>>>>>
>>>>>> love you,
>>>>>> Han Guangyu
>>>>>>
>>>>>>
>>>>>> Julia Kreger <juliaashleykreger at gmail.com> ?2022?2?10??? 23:11???
>>>>>>
>>>>>>>
>>>>>>> If the disk controllers *are* enumerated in the kernel log, which is
>>>>>>> something to also look for, then the disks themselves may be in some
>>>>>>> weird state like security locked. Generally this shows up as the
>>>>>>> operating system kind of sees the disk and the SATA port connected but
>>>>>>> can't really access it. This is also an exceptionally rare state to
>>>>>>> find one's self in.
>>>>>>>
>>>>>>> More common, especially in enterprise grade hardware: If the disk
>>>>>>> controller is actually a raid controller, and there are no raid
>>>>>>> volumes configured, then the operating system likely cannot see the
>>>>>>> underlying disks and turn that into a usable block device. I've seen a
>>>>>>> couple drivers over the years which expose hints of disks in the
>>>>>>> kernel log and without raid configuration in the cards, the drivers
>>>>>>> can't present usable block devices to the operating system system.
>>>>>>>
>>>>>>> -Julia
>>>>>>>
>>>>>>> On Thu, Feb 10, 2022 at 3:17 AM Arne Wiebalck <arne.wiebalck at cern.ch> wrote:
>>>>>>>>
>>>>>>>> Hi Guangyu,
>>>>>>>>
>>>>>>>> No worries about asking questions, this is what the mailing
>>>>>>>> list is for :)
>>>>>>>>
>>>>>>>> Just to clarify, you do not have to set root device hints,
>>>>>>>> it also works without (with the algorithm I mentioned).
>>>>>>>> However, hints help to define the exact device and/or make
>>>>>>>> deployment more predictable/repeatable.
>>>>>>>>
>>>>>>>> If it is really a driver problem, it is an issue with the
>>>>>>>> operating system of the image you use, i.e. CentOS8. Some
>>>>>>>> drivers were removed from 7 to 8, and we have seen issues
>>>>>>>> with specific drive models as well.
>>>>>>>>
>>>>>>>> You can try to build your own IPA images as described in
>>>>>>>> [1], e.g. to add your ssh key to be able to log into the
>>>>>>>> IPA to debug further, and to eventually include drivers
>>>>>>>> (if you can identify them and they are available for CentOS8).
>>>>>>>>
>>>>>>>> Another option may be to add another (newer) disk model to
>>>>>>>> the server, just to confirm it is the disk model/driver which
>>>>>>>> is the cause.
>>>>>>>>
>>>>>>>> You could also try to boot the node into a CentOS7 (and then
>>>>>>>> a CentOS8) live image to confirm it can see the disks at all.
>>>>>>>>
>>>>>>>> Hope this helps!
>>>>>>>>      Arne
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://docs.openstack.org/ironic-python-agent-builder/latest/admin/dib.html
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10.02.22 11:15, ??? wrote:
>>>>>>>>> Hi Arne,
>>>>>>>>>
>>>>>>>>> Thank you very much for your response. Love you. You take away a lot
>>>>>>>>> of my confusion.
>>>>>>>>>
>>>>>>>>> You are right, I didn't set 'root device'. And Ironic also can not see
>>>>>>>>> disk, the content of the 'lsblk' file in the deploy los is emply.
>>>>>>>>> I tried to set 'root device', but because ironic can't find any disk,
>>>>>>>>> the deploy still filed.
>>>>>>>>>
>>>>>>>>> Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
>>>>>>>>> 09:51:55.045 2324 WARNING root [-] Path /dev/disk/by-path is
>>>>>>>>> inaccessible, /dev/disk/by-path/* version of block device name is
>>>>>>>>> unavailable Cause: [Errno 2] No such file or directory:
>>>>>>>>> '/dev/disk/by-path': FileNotFoundError: [Errno 2] No such file or
>>>>>>>>> directory: '/dev/disk/by-path'
>>>>>>>>> Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
>>>>>>>>> 09:51:55.056 2324 WARNING ironic_lib.utils [-] No device found that
>>>>>>>>> matches the root device hints {'wwn': '0x50014EE2691D724C'}:
>>>>>>>>> StopIteration
>>>>>>>>>
>>>>>>>>> Sorry to bother you, I'm a newcomer of Ironic and I didn't find
>>>>>>>>> information about it on google.
>>>>>>>>>
>>>>>>>>> The bare metal node have three same disk(Western Digital DC HA210 2TB
>>>>>>>>> SATA 6GB/s). Where I can confirm whether ironic-python-agent supports
>>>>>>>>> this disk?
>>>>>>>>>
>>>>>>>>> And If Ironic cannot find disk since the corresponding drivers in the
>>>>>>>>> IPA image are missing, do you know how to resolve it? I have used the
>>>>>>>>> latest deploy images in
>>>>>>>>> https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/
>>>>>>>>> .  Do I need to find and manually add driver in the source code or
>>>>>>>>> ramdisk(That was difficult tome)?
>>>>>>>>>
>>>>>>>>> Love you.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Guangyu
>>>>>>>>>
>>>>>>>>> Arne Wiebalck <arne.wiebalck at cern.ch> ?2022?2?10??? 15:51???
>>>>>>>>>>
>>>>>>>>>> Hi Guangyu,
>>>>>>>>>>
>>>>>>>>>> The error indicates that Ironic was not able to find
>>>>>>>>>> a device where it could deploy the image to.
>>>>>>>>>>
>>>>>>>>>> To find a device, Ironic will use 'root device'
>>>>>>>>>> hints [1], usually set by the admin on a node. If that
>>>>>>>>>> does not yield anything, Ironic will loop over all
>>>>>>>>>> block devices and pick the smallest which is larger
>>>>>>>>>> than 4GB (and order them alphabetically).
>>>>>>>>>>
>>>>>>>>>> If you have disks in your server which are larger than
>>>>>>>>>> 4GB, one potential explanation is that Ironic cannot see them,
>>>>>>>>>> e.g. since the corresponding drivers in the IPA image are missing.
>>>>>>>>>> The logs you posted seem to confirm something along those
>>>>>>>>>> lines.
>>>>>>>>>>
>>>>>>>>>> Check the content of the 'lsblk' file in the deploy logs which
>>>>>>>>>> you can find in the tar archive in /var/log/ironic/deploy/
>>>>>>>>>> on the controller for your deployment attempt to see what
>>>>>>>>>> devices Ironic has access to.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>       Arne
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [1] https://docs.openstack.org/ironic/latest/install/advanced.html#root-device-hints
>>>>>>>>>>
>>>>>>>>>> On 10.02.22 02:50, ??? wrote:
>>>>>>>>>>> Dear all,
>>>>>>>>>>>
>>>>>>>>>>> I have a OpenStack Victoria environment, and tried to use ironic
>>>>>>>>>>> manage bare metal. But I got "- root device hints were not provided
>>>>>>>>>>> and all found block devices are smaller than 4294967296B." in deploy
>>>>>>>>>>> stage.
>>>>>>>>>>>
>>>>>>>>>>> 2022-02-09 17:57:56.492 3908982 ERROR
>>>>>>>>>>> ironic.drivers.modules.agent_base [-] Agent returned error for deploy
>>>>>>>>>>> step {'step': 'write_image', 'priority': 80, 'argsinfo': None,
>>>>>>>>>>> 'interface': 'deploy'} on node cc68c450-ce54-4e1c-be04-8b0a6169ef92 :
>>>>>>>>>>> No suitable device was found for deployment - root device hints were
>>>>>>>>>>> not provided and all found block devices are smaller than
>>>>>>>>>>> 4294967296B..
>>>>>>>>>>>
>>>>>>>>>>> I used "openstack server create --flavor my-baremetal-flavor --nic
>>>>>>>>>>> net-id=$net_id --image $image testing" to deploy bare metal node.  I
>>>>>>>>>>> download deploy images(ipa-centos8-master.kernel and
>>>>>>>>>>> ipa-centos8-master.initramfs) in
>>>>>>>>>>> https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/.
>>>>>>>>>>>
>>>>>>>>>>> The baremetal node info and flavor info as following:
>>>>>>>>>>> https://paste.opendev.org/show/bV7lgO6RkNQY6ZGPbT2e/
>>>>>>>>>>> Ironic configure file as following:
>>>>>>>>>>> https://paste.opendev.org/show/bTgY9Kpn7KWqwQl73aEa/
>>>>>>>>>>> Ironic-conductor log:    https://paste.opendev.org/show/bFKZYlXmccxNxU8lEogk/
>>>>>>>>>>> The log of ironic-python-agent in bare metal node:
>>>>>>>>>>> https://paste.opendev.org/show/btAuaMuV2IutV2Pa7YIa/
>>>>>>>>>>>
>>>>>>>>>>> I see some old discussion about this, such as:
>>>>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1312187. But those
>>>>>>>>>>> discussions took place a long time ago, not version V, and no solution
>>>>>>>>>>> was seen.
>>>>>>>>>>>
>>>>>>>>>>> Does anyone know how to solve this problem? I would appreciate any
>>>>>>>>>>> kind of guidance or help.
>>>>>>>>>>>
>>>>>>>>>>> Thank you,
>>>>>>>>>>> Han Guangyu
>>>>>>>>>>>
>>>>>>>>


From hanguangyu2 at gmail.com  Fri Mar  4 09:25:11 2022
From: hanguangyu2 at gmail.com (=?UTF-8?B?6Z+p5YWJ5a6H?=)
Date: Fri, 4 Mar 2022 17:25:11 +0800
Subject: [Ironic] No suitable device was found for deployment
In-Reply-To: <CAF7gwdhXXWA_Q0ZO57w24oCY7FoeuxMwah7shRj_tEdpeBPiMw@mail.gmail.com>
References: <CAOirdiX4RuYYdzmDWBp0Ofua0B6BV0mGat0YWnwZZwebmMOeQQ@mail.gmail.com>
 <fbcd7e11-e4b4-6022-0b5e-df42b1d9b998@cern.ch>
 <CAOirdiV8s80SYcbtZ8G4-VCMs9OGvfeVy=CF-d8V0Fw0N9xO0g@mail.gmail.com>
 <04af20bb-143b-9b56-6787-d5ac6ab0d38c@cern.ch>
 <CAF7gwdgkJiXShCM0z1ZyERj0=Z63713Xy6JXctwazNobqvxqVw@mail.gmail.com>
 <CAOirdiUPkXOVZDg8DgrOMDeK8xJxPGcbsu4Y+XPVCbbjJOGCDg@mail.gmail.com>
 <ca926b29-9dff-cceb-5734-7d510a48a045@cern.ch>
 <CAOirdiUEO+yE1=KN-kEVLR3sRBY15weFjc_kRzMEboS=UjZ-gA@mail.gmail.com>
 <3209d9fc-8db1-6dca-5736-402c6f082fcc@cern.ch>
 <CAF7gwdhXXWA_Q0ZO57w24oCY7FoeuxMwah7shRj_tEdpeBPiMw@mail.gmail.com>
Message-ID: <CAOirdiXE13w8LGpcnqzMjgn2JdawSYmY2f_r72rSu-CuLXQgFw@mail.gmail.com>

Hi Julia,

Sorry that my last email didn't reploy some question in your email.
When I get into RAID config menu, I said disk state is "unconfig bad".
And the more info is that Virtual Drive Management displayed "No
Configuration Present!". But I cound not modify disk state in RAID
confug menu. Even if I moved the disk to other server, and used the
software in operating system to modify it, it still coudn't to be
modify. such as:
```shell
# MegaCli -PDList -a0

Adapter #0

Enclosure Device ID: 252
Slot Number: 1
Enclosure position: 0
Device Id: 9
WWN: 50014EE2BE72FEBF
Sequence Number: 2
Media Error Count: 0
Other Error Count: 0
Predictive Failure Count: 0
Last Predictive Failure Event Seq Number: 0
PD Type: SATA
Raw Size: 0 KB [0x0 Sectors]
Non Coerced Size: 0 KB [0x0 Sectors]
Coerced Size: 0 KB [0x0 Sectors]
Firmware state: Unconfigured(bad)
Device Firmware Level: WA09
Shield Counter: 0
Successful diagnostics completion on :  N/A
SAS Address(0): 0x4433221101000000
Connected Port Number: 0(path0)
Inquiry Data: ATA     HGST HUS722T2TALWA09WCC6N4HZV9SX
FDE Enable: Disable
Secured: Unsecured
Locked: Unlocked
Needs EKM Attention: No
Foreign State: None
Device Speed: Unknown
Link Speed: 6.0Gb/s
Media Type: Hard Disk Device
Drive Temperature :0C (32.00 F)
PI Eligibility:  No
Drive is formatted for PI information:  No
PI: No PI
Drive's write cache : Disabled
Drive's NCQ setting : Enabled
Port-0 :
Port status: Active
Port's Linkspeed: 6.0Gb/s
Drive has flagged a S.M.A.R.T alert : No



Enclosure Device ID: 252
Slot Number: 2
Enclosure position: 0
Device Id: 10
WWN: 50014EE2691D724C
Sequence Number: 2
Media Error Count: 0
Other Error Count: 0
Predictive Failure Count: 0
Last Predictive Failure Event Seq Number: 0
PD Type: SATA
Raw Size: 0 KB [0x0 Sectors]
Non Coerced Size: 0 KB [0x0 Sectors]
Coerced Size: 0 KB [0x0 Sectors]
Firmware state: Unconfigured(bad)
Device Firmware Level: WA09
Shield Counter: 0
Successful diagnostics completion on :  N/A
SAS Address(0): 0x4433221102000000
Connected Port Number: 1(path0)
Inquiry Data: ATA     HGST HUS722T2TALWA09WCC6N4HZVTV5
FDE Enable: Disable
Secured: Unsecured
Locked: Unlocked
Needs EKM Attention: No
Foreign State: None
Device Speed: Unknown
Link Speed: 6.0Gb/s
Media Type: Hard Disk Device
Drive Temperature :0C (32.00 F)
PI Eligibility:  No
Drive is formatted for PI information:  No
PI: No PI
Drive's write cache : Disabled
Drive's NCQ setting : Enabled
Port-0 :
Port status: Active
Port's Linkspeed: 6.0Gb/s
Drive has flagged a S.M.A.R.T alert : No



Enclosure Device ID: 252
Slot Number: 3
Enclosure position: 0
Device Id: 11
WWN: 50014EE2BE733A5E
Sequence Number: 2
Media Error Count: 0
Other Error Count: 0
Predictive Failure Count: 0
Last Predictive Failure Event Seq Number: 0
PD Type: SATA
Raw Size: 1.819 TB [0xe8e088b0 Sectors]
Non Coerced Size: 1.818 TB [0xe8d088b0 Sectors]
Coerced Size: 1.818 TB [0xe8d00000 Sectors]
Firmware state: JBOD
Device Firmware Level: WA09
Shield Counter: 0
Successful diagnostics completion on :  N/A
SAS Address(0): 0x4433221103000000
Connected Port Number: 2(path0)
Inquiry Data: WCC6N0KX0HJD        HGST HUS722T2TALA604
   RAGNWA09
FDE Enable: Disable
Secured: Unsecured
Locked: Unlocked
Needs EKM Attention: No
Foreign State: None
Device Speed: 6.0Gb/s
Link Speed: 6.0Gb/s
Media Type: Hard Disk Device
Drive Temperature :34C (93.20 F)
PI Eligibility:  No
Drive is formatted for PI information:  No
PI: No PI
Drive's write cache : Enabled
Drive's NCQ setting : Enabled
Port-0 :
Port status: Active
Port's Linkspeed: 6.0Gb/s
Drive has flagged a S.M.A.R.T alert : No




Exit Code: 0x00
```
```shell
# MegaCli -PDList -a0 | grep state
Firmware state: Unconfigured(bad)
Firmware state: Unconfigured(bad)
Firmware state: JBOD
# MegaCli -PDMakeGood -PhysDrv[252:2] -a0

Adapter: 0: Failed to change PD state at EnclId-252 SlotId-2.

Exit Code: 0x01
```

And the "security locked state" is a idea that I continue. I will try
to determine if it is in this state and find a way to disarm it.

Thank you very much Julia,
cheers,
Han Guangyu

Julia Kreger <juliaashleykreger at gmail.com> ?2022?3?1??? 22:06???
>
> On Mon, Feb 28, 2022 at 1:12 AM Arne Wiebalck <arne.wiebalck at cern.ch> wrote:
> >
> > Hi Guangyu,
> >
> > I am not aware of anything in the Ironic Python Agent that
> > would remove disks from the system in a way that they would
> > not be visible after a reboot (apart from, as mentioned before,
> > the clean up of a hardware RAID in a way the IPA is not able
> > to see any devices after).
> >
> > How about trying to access and configure the hardware RAID with
> > the corresponding tool from the RAM disk you booted into from the
> > USB stick? Install the tool and see if it detects the controller.
> >
> > The very first step before doing anything with Ironic is to
> > get the disks back or understand why they are not visible.
> >
>
> Did cleaning fail at any given point with these machines?
>
> If you have physical access, try disconnecting all of the drives, and
> then powering up the machine and see if you can get into the firmware
> configuration screen with control-h. If you can, remove all of the
> prior configuration or disk volumes. They will look like they are in
> error states most likely. If your unable to get into this screen, I
> would be worried about your disk controller card. If your able to
> clear everything out of the controller, power off, try re-inserting
> drives, and see what happens. See if the controller can view/interact
> with the drives. If it sees no drives, then my next paragraph is
> likely the case.
>
> The disks sound like they might be in security locked state which will
> likely require a desktop SATA disk controller to remedy by attaching
> and manually removing from a security locked state. Megaraid
> controllers can't recognize security locked devices (most controllers
> and especially ones labeled "raid controllers" can't handle it) when
> in pass-through mode, but I've never heard of security lock commands
> actually getting through to the device with those controllers in
> pass-through mode. If the card was in raid mode to begin with, then it
> likely never did anything involving secure erase as the controller
> should not be offering that as a feature of provided disks to the OS.
>
> > Cheers,
> >   Arne
> >
> > On 28.02.22 09:28, ??? wrote:
> > > Hi Arne,
> > >
> > > I didn't find hardware RAID config option during the initial boot
> > > sequence. Ctrl+H is unresponsive in this computer. I just saw "Press
> > > Del to enter firmware configuration, press F3 to enter boot menu, and
> > > press F12 to enter network boot". And I press 'Del' to enter the BIOS.
> > > But I didn't find RAID config menu in BIOS. Sorry that I have poor
> > > knowledge about this.
> > >
> > > And now, even though I installed the operating system manually using a
> > > USB stick, I still couldn't find the hard drive. Is there anything
> > > that ironic-agent did in the clean phase that would have caused this
> > > problem?
> > >
> > > I wonder if this is a thinking pointto solve the problem. Now, my idea
> > > is to first find a way to manually configure RAID.  Do you agree with
> > > this?  And than, whether RAID configurations are still cleared in the
> > > Clean phase if clean phase will do this?
> > >
> > > Sorry that I have so much confuse.
> > >
> > > love you,
> > > Guangyu
> > >
> > > Arne Wiebalck <arne.wiebalck at cern.ch> ?2022?2?14??? 15:59???
> > >>
> > >> Hi Guangyu,
> > >>
> > >> It seems like Julia had the right idea and the disks
> > >> are not visible since the RAID controller does not
> > >> expose anything to the operating system. This seems
> > >> to be confirmed by you booting into the CentOS7 image.
> > >>
> > >> What I would suggest to try next is to look for the
> > >> hardware RAID config option during the initial boot
> > >> sequence to enter the RAID config menu (there should be
> > >> a message quite early on, and maybe Ctrl-H is needed
> > >> to enter the menu).
> > >>
> > >> Once there, manually configure the disks as JBODs or
> > >> create a RAID device. Upon reboot this should be visible
> > >> and accessible as a device. Maybe check from your CentOS7
> > >> image again. If the devices are there, Ironic should
> > >> also be able to deploy on them (for this you can remove
> > >> the RAID config you added).
> > >>
> > >> It depends a little on what your goal is, but I would
> > >> try this first to see if you can make a device visible
> > >> and if the Ironic deploy bit works, before trying to
> > >> configure the hardware RAID via Ironic.
> > >>
> > >> Cheers,
> > >>    Arne
> > >>
> > >> On 14.02.22 03:20, ??? wrote:
> > >>> Hi Arne and Julia,
> > >>>
> > >>> You make me feel so warm. Best wishes to you.
> > >>>
> > >>> I have tried to boot the node into a CentOS7, but it still coundnot to
> > >>> find disk. And sorry that I didn't notice the RAID card.
> > >>>
> > >>> # lspci -v
> > >>> ...
> > >>> 23:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS-3 3108
> > >>> [Invader] (rev 02)
> > >>>           Subsystem: Broadcom / LSI MegaRAID SAS 9361-8i
> > >>>           Flags: bus master, fast devsel, latency 0, IRQ -2147483648, NUMA node 1
> > >>>           I/O ports at 3000 [size=256]
> > >>>           Memory at e9900000 (64-bit, non-prefetchable) [size=64K]
> > >>>           Memory at e9700000 (64-bit, non-prefetchable) [size=1M]
> > >>>           Expansion ROM at e9800000 [disabled] [size=1M]
> > >>>           Capabilities: [50] Power Management version 3
> > >>>           Capabilities: [68] Express Endpoint, MSI 00
> > >>>           Capabilities: [d0] Vital Product Data
> > >>>           Capabilities: [a8] MSI: Enable- Count=1/1 Maskable+ 64bit+
> > >>>           Capabilities: [c0] MSI-X: Enable+ Count=97 Masked-
> > >>>           Capabilities: [100] Advanced Error Reporting
> > >>>           Capabilities: [1e0] #19
> > >>>           Capabilities: [1c0] Power Budgeting <?>
> > >>>           Capabilities: [148] Alternative Routing-ID Interpretation (ARI)
> > >>>           Kernel driver in use: megaraid_sas
> > >>>           Kernel modules: megaraid_sas
> > >>> ...
> > >>>
> > >>> I try to config raid fallowing
> > >>> https://docs.openstack.org/ironic/latest/admin/raid.html
> > >>> by `baremetal node set $NODE_UUID --target-raid-config raid.json`. The
> > >>> server have  three same disk(Western Digital DC HA210 2TB SATA 6GB/s)
> > >>> # cat raid.json
> > >>> {
> > >>>     "logical_disks": [
> > >>>       {
> > >>>         "size_gb": "MAX",
> > >>>         "raid_level": "0",
> > >>>         "is_root_volume": true
> > >>>       }
> > >>>     ]
> > >>> }
> > >>>
> > >>> But Ironic still coundn't see disk. I still got
> > >>> ```
> > >>> ## In deploy images
> > >>> # journalctl -fxeu ironic-python-agent
> > >>> Feb 14 02:17:22 host-10-12-22-74 ironic-python-agent[2329]: 2022-02-14
> > >>> 02:17:22.863 2329 WARNING root [-] Path /dev/disk/by-path is
> > >>> inaccessible, /dev/disk/by-path/* version of block device name is
> > >>> unavailable Cause: [Errno 2] No such file or directory:
> > >>> '/dev/disk/by-path': FileNotFoundError: [Errno 2] No such file or
> > >>> directory: '/dev/disk/by-path'
> > >>> Feb 14 02:17:44 host-10-12-22-74 ironic-python-agent[2329]: 2022-02-14
> > >>> 02:17:44.391 2329 ERROR root [-] Unexpected error dispatching
> > >>> get_os_install_device to manager
> > >>> <ironic_python_agent.hardware.GenericHardwareManager object at
> > >>> 0x7efbf4da2208>: Error finding the disk or partition device to deploy
> > >>> the image onto: No suitable device was found for deployment - root
> > >>> device hints were not provided and all found block devices are smaller
> > >>> than 4294967296B.: ironic_python_agent.errors.DeviceNotFound: Error
> > >>> finding the disk or partition device to deploy the image onto: No
> > >>> suitable device was found for deployment - root device hints were not
> > >>> provided and all found block devices are smaller than 4294967296B.
> > >>> ```
> > >>>
> > >>> I don't know if it's a lack of a RAID card driver or a lack of a disk
> > >>> driver or a lack of RAID configuration. Could you have some idea about
> > >>> this question?
> > >>>
> > >>> love you,
> > >>> Han Guangyu
> > >>>
> > >>>
> > >>> Julia Kreger <juliaashleykreger at gmail.com> ?2022?2?10??? 23:11???
> > >>>
> > >>>>
> > >>>> If the disk controllers *are* enumerated in the kernel log, which is
> > >>>> something to also look for, then the disks themselves may be in some
> > >>>> weird state like security locked. Generally this shows up as the
> > >>>> operating system kind of sees the disk and the SATA port connected but
> > >>>> can't really access it. This is also an exceptionally rare state to
> > >>>> find one's self in.
> > >>>>
> > >>>> More common, especially in enterprise grade hardware: If the disk
> > >>>> controller is actually a raid controller, and there are no raid
> > >>>> volumes configured, then the operating system likely cannot see the
> > >>>> underlying disks and turn that into a usable block device. I've seen a
> > >>>> couple drivers over the years which expose hints of disks in the
> > >>>> kernel log and without raid configuration in the cards, the drivers
> > >>>> can't present usable block devices to the operating system system.
> > >>>>
> > >>>> -Julia
> > >>>>
> > >>>> On Thu, Feb 10, 2022 at 3:17 AM Arne Wiebalck <arne.wiebalck at cern.ch> wrote:
> > >>>>>
> > >>>>> Hi Guangyu,
> > >>>>>
> > >>>>> No worries about asking questions, this is what the mailing
> > >>>>> list is for :)
> > >>>>>
> > >>>>> Just to clarify, you do not have to set root device hints,
> > >>>>> it also works without (with the algorithm I mentioned).
> > >>>>> However, hints help to define the exact device and/or make
> > >>>>> deployment more predictable/repeatable.
> > >>>>>
> > >>>>> If it is really a driver problem, it is an issue with the
> > >>>>> operating system of the image you use, i.e. CentOS8. Some
> > >>>>> drivers were removed from 7 to 8, and we have seen issues
> > >>>>> with specific drive models as well.
> > >>>>>
> > >>>>> You can try to build your own IPA images as described in
> > >>>>> [1], e.g. to add your ssh key to be able to log into the
> > >>>>> IPA to debug further, and to eventually include drivers
> > >>>>> (if you can identify them and they are available for CentOS8).
> > >>>>>
> > >>>>> Another option may be to add another (newer) disk model to
> > >>>>> the server, just to confirm it is the disk model/driver which
> > >>>>> is the cause.
> > >>>>>
> > >>>>> You could also try to boot the node into a CentOS7 (and then
> > >>>>> a CentOS8) live image to confirm it can see the disks at all.
> > >>>>>
> > >>>>> Hope this helps!
> > >>>>>     Arne
> > >>>>>
> > >>>>> [1]
> > >>>>> https://docs.openstack.org/ironic-python-agent-builder/latest/admin/dib.html
> > >>>>>
> > >>>>>
> > >>>>> On 10.02.22 11:15, ??? wrote:
> > >>>>>> Hi Arne,
> > >>>>>>
> > >>>>>> Thank you very much for your response. Love you. You take away a lot
> > >>>>>> of my confusion.
> > >>>>>>
> > >>>>>> You are right, I didn't set 'root device'. And Ironic also can not see
> > >>>>>> disk, the content of the 'lsblk' file in the deploy los is emply.
> > >>>>>> I tried to set 'root device', but because ironic can't find any disk,
> > >>>>>> the deploy still filed.
> > >>>>>>
> > >>>>>> Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
> > >>>>>> 09:51:55.045 2324 WARNING root [-] Path /dev/disk/by-path is
> > >>>>>> inaccessible, /dev/disk/by-path/* version of block device name is
> > >>>>>> unavailable Cause: [Errno 2] No such file or directory:
> > >>>>>> '/dev/disk/by-path': FileNotFoundError: [Errno 2] No such file or
> > >>>>>> directory: '/dev/disk/by-path'
> > >>>>>> Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
> > >>>>>> 09:51:55.056 2324 WARNING ironic_lib.utils [-] No device found that
> > >>>>>> matches the root device hints {'wwn': '0x50014EE2691D724C'}:
> > >>>>>> StopIteration
> > >>>>>>
> > >>>>>> Sorry to bother you, I'm a newcomer of Ironic and I didn't find
> > >>>>>> information about it on google.
> > >>>>>>
> > >>>>>> The bare metal node have three same disk(Western Digital DC HA210 2TB
> > >>>>>> SATA 6GB/s). Where I can confirm whether ironic-python-agent supports
> > >>>>>> this disk?
> > >>>>>>
> > >>>>>> And If Ironic cannot find disk since the corresponding drivers in the
> > >>>>>> IPA image are missing, do you know how to resolve it? I have used the
> > >>>>>> latest deploy images in
> > >>>>>> https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/
> > >>>>>> .  Do I need to find and manually add driver in the source code or
> > >>>>>> ramdisk(That was difficult tome)?
> > >>>>>>
> > >>>>>> Love you.
> > >>>>>>
> > >>>>>> Cheers,
> > >>>>>> Guangyu
> > >>>>>>
> > >>>>>> Arne Wiebalck <arne.wiebalck at cern.ch> ?2022?2?10??? 15:51???
> > >>>>>>>
> > >>>>>>> Hi Guangyu,
> > >>>>>>>
> > >>>>>>> The error indicates that Ironic was not able to find
> > >>>>>>> a device where it could deploy the image to.
> > >>>>>>>
> > >>>>>>> To find a device, Ironic will use 'root device'
> > >>>>>>> hints [1], usually set by the admin on a node. If that
> > >>>>>>> does not yield anything, Ironic will loop over all
> > >>>>>>> block devices and pick the smallest which is larger
> > >>>>>>> than 4GB (and order them alphabetically).
> > >>>>>>>
> > >>>>>>> If you have disks in your server which are larger than
> > >>>>>>> 4GB, one potential explanation is that Ironic cannot see them,
> > >>>>>>> e.g. since the corresponding drivers in the IPA image are missing.
> > >>>>>>> The logs you posted seem to confirm something along those
> > >>>>>>> lines.
> > >>>>>>>
> > >>>>>>> Check the content of the 'lsblk' file in the deploy logs which
> > >>>>>>> you can find in the tar archive in /var/log/ironic/deploy/
> > >>>>>>> on the controller for your deployment attempt to see what
> > >>>>>>> devices Ironic has access to.
> > >>>>>>>
> > >>>>>>> Cheers,
> > >>>>>>>      Arne
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> [1] https://docs.openstack.org/ironic/latest/install/advanced.html#root-device-hints
> > >>>>>>>
> > >>>>>>> On 10.02.22 02:50, ??? wrote:
> > >>>>>>>> Dear all,
> > >>>>>>>>
> > >>>>>>>> I have a OpenStack Victoria environment, and tried to use ironic
> > >>>>>>>> manage bare metal. But I got "- root device hints were not provided
> > >>>>>>>> and all found block devices are smaller than 4294967296B." in deploy
> > >>>>>>>> stage.
> > >>>>>>>>
> > >>>>>>>> 2022-02-09 17:57:56.492 3908982 ERROR
> > >>>>>>>> ironic.drivers.modules.agent_base [-] Agent returned error for deploy
> > >>>>>>>> step {'step': 'write_image', 'priority': 80, 'argsinfo': None,
> > >>>>>>>> 'interface': 'deploy'} on node cc68c450-ce54-4e1c-be04-8b0a6169ef92 :
> > >>>>>>>> No suitable device was found for deployment - root device hints were
> > >>>>>>>> not provided and all found block devices are smaller than
> > >>>>>>>> 4294967296B..
> > >>>>>>>>
> > >>>>>>>> I used "openstack server create --flavor my-baremetal-flavor --nic
> > >>>>>>>> net-id=$net_id --image $image testing" to deploy bare metal node.  I
> > >>>>>>>> download deploy images(ipa-centos8-master.kernel and
> > >>>>>>>> ipa-centos8-master.initramfs) in
> > >>>>>>>> https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/.
> > >>>>>>>>
> > >>>>>>>> The baremetal node info and flavor info as following:
> > >>>>>>>> https://paste.opendev.org/show/bV7lgO6RkNQY6ZGPbT2e/
> > >>>>>>>> Ironic configure file as following:
> > >>>>>>>> https://paste.opendev.org/show/bTgY9Kpn7KWqwQl73aEa/
> > >>>>>>>> Ironic-conductor log:    https://paste.opendev.org/show/bFKZYlXmccxNxU8lEogk/
> > >>>>>>>> The log of ironic-python-agent in bare metal node:
> > >>>>>>>> https://paste.opendev.org/show/btAuaMuV2IutV2Pa7YIa/
> > >>>>>>>>
> > >>>>>>>> I see some old discussion about this, such as:
> > >>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1312187. But those
> > >>>>>>>> discussions took place a long time ago, not version V, and no solution
> > >>>>>>>> was seen.
> > >>>>>>>>
> > >>>>>>>> Does anyone know how to solve this problem? I would appreciate any
> > >>>>>>>> kind of guidance or help.
> > >>>>>>>>
> > >>>>>>>> Thank you,
> > >>>>>>>> Han Guangyu
> > >>>>>>>>
> > >>>>>


From lokendrarathour at gmail.com  Fri Mar  4 09:40:13 2022
From: lokendrarathour at gmail.com (Lokendra Rathour)
Date: Fri, 4 Mar 2022 15:10:13 +0530
Subject: Fwd: [Triple0] Upgrade Error
In-Reply-To: <87333433-63c3-6b52-ab36-8de16dff277d@redhat.com>
References: <CAJm6b-42betLA4CfYW_cTjg_cBuHeeyAxVxG=tzPY_nm08OXWQ@mail.gmail.com>
 <CAJm6b-6cySYDODgFUknQWMgA_KxwCopoeQ+cpPRsqwhtYVec=A@mail.gmail.com>
 <87333433-63c3-6b52-ab36-8de16dff277d@redhat.com>
Message-ID: <CAJm6b-7RgJe7-jayFfihwX0P=1uYjghHQoPdNxo4CC_mNdoNyQ@mail.gmail.com>

Hi Harald / Team,
Thanks for the support here.
It did help in the classification of the issue and we saw that we need to
re-render the templates for an upgrade to proceed.
After re-rendering we saw the diff of DNS related in the templates.

Now we have completed the next few steps and are facing issues when running
the below commands:

openstack overcloud upgrade run --limit Controller --playbook
upgrade_steps_playbook.yaml


It gives the error as :

*2022-03-04 14:29:56.571690 | 525400cb-2e90-4086-e760-00000000009b |
TASK | Ensure DNF modules have the right stream*
*2022-03-04 14:29:57.723661 | 525400cb-2e90-4086-e760-00000000009b |
 FATAL | Ensure DNF modules have the right stream | overcloud-novacompute-0
| item={'module': 'container-tools', 'stream': '3.0'} |
error={"ansible_loop_var": "item", "changed": false, "item": {"module":
"container-tools", "stream": "3.0"}, "module_stderr": "Traceback (most
recent call last):\n  File \"<stdin>\", line 102, in <module>\n  File
\"<stdin>\", line 94, in _ansiballz_main\n  File \"<stdin>\", line 40, in
invoke_module\n  File \"/usr/lib64/python3.6/runpy.py\", line 205, in
run_module\n    return _run_module_code(code, init_globals, run_name,
mod_spec)\n  File \"/usr/lib64/python3.6/runpy.py\", line 96, in
_run_module_code\n    mod_name, mod_spec, pkg_name, script_name)\n  File
\"/usr/lib64/python3.6/runpy.py\", line 85, in _run_code\n    exec(code,
run_globals)\n  File
\"/tmp/ansible_dnf_payload_3lb54omj/ansible_dnf_payload.zip/ansible/modules/packaging/os/dnf.py\",
line 1370, in <module>\n  File
\"/tmp/ansible_dnf_payload_3lb54omj/ansible_dnf_payload.zip/ansible/modules/packaging/os/dnf.py\",
line 1359, in main\n  File
\"/tmp/ansible_dnf_payload_3lb54omj/ansible_dnf_payload.zip/ansible/modules/packaging/os/dnf.py\",
line 1338, in run\n  File
\"/tmp/ansible_dnf_payload_3lb54omj/ansible_dnf_payload.zip/ansible/modules/packaging/os/dnf.py\",
line 996, in ensure\n  File
\"/usr/lib/python3.6/site-packages/dnf/module/module_base.py\", line 144,
in install\n    \"Installing module from Fail-Safe repository is not
allowed\"))\ndnf.exceptions.Error: Installing module from Fail-Safe
repository is not allowed\n", "module_stdout": "", "msg": "MODULE
FAILURE\nSee stdout/stderr for the exact error", "rc": 1}*

*Few things to note:*

   - *the document followed * Upgrading to a Next Major Release ? TripleO
   3.0.0 documentation (openstack.org)
   <https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/post_deployment/upgrade/major_upgrade.html>
   - The command which was executed to run upgrade prepare:
      -











*openstack overcloud upgrade prepare --templates \     -n
      /home/stack/templates/network_data.yaml \     -r
      /home/stack/templates/roles_data.yaml \     -e
      /home/stack/templates/environment.yaml \     -e
      /home/stack/templates/environments/network-isolation.yaml \     -e
      /home/stack/templates/environments/network-environment.yaml \     -e
      /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
      \     -e
      /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
      \     -e
      /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
      \     -e /home/stack/templates/ironic-config.yaml \     -e
      /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml
\
        -e /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml
\
          -e /home/stack/containers-prepare-parameter.yaml*

Please advice over the same issue.

Best Regards,
Lokendra


On Sun, Feb 27, 2022 at 6:50 AM Harald Jensas <hjensas at redhat.com> wrote:

> On 2/25/22 12:21, Lokendra Rathour wrote:
> > Hi Team,
> >
> > we are trying to upgrade *Triple0 Train to Ussuri.*
> > Undercloud upgrade is done successfully.
> > *_OverCloud Upgrade:_*
> > As a first step in overcloud upgrade, we are running " *openstack
> > overcloud upgrade prepare*  "  command.
> > which is throwing following error:
> >
>
> > overcloud: ERROR: Property error:
> > resources.InternalApiVirtualIP.properties: Unknown Property DnsName\n
> >   File \"/usr/lib/python3.6/site-packages/heat/common/wsgi.py\", line
> > 891, in __call__\n    request, **action_args)\n  File
> > \"/usr/lib/python3.6/site-packages/heat/common/wsgi.py\", line 964, in
> > dispatch\n    return method(*args, **kwargs)\n  File
> > \"/usr/lib/python3.6/site-packages/heat/api/openstack/v1/util.py\", line
> > 56, in handle_stack_method\n    return handler(controller, req,
> > **kwargs)\n  File
> > \"/usr/lib/python3.6/site-packages/heat/api/openstack/v1/stacks.py\",
> > line 633, in validate_template\n    raise
> > exc.HTTPBadRequest(result['Error'])\n", "success": false}*
> >
>
> The DnsName property was added to templats in Ussuri, this change:
> https://review.opendev.org/c/openstack/tripleo-heat-templates/+/715883
>
>
> Somewhere in you environment files you are mapping
> `OS::TripleO::Network::Ports::InternalApiVipPort` to a local template
> file instead of using the in-tree template.
>
> You either need to add DnsName paramter to your local VipPort template,
> or change the resource_registry so that you map to the in-tree port
> template.
> `/usr/share/openstack-tripleo-heat-template/network/ports/internal_api.yaml`
>
> is the in-tree template you want.
>
>
> > *_Command used to run the overcloud upgrade prepare:_*
> >
> > *(undercloud) [stack at undercloud ~]$ cat upgrade_overcloud_prepare.sh
> > openstack overcloud upgrade prepare --templates \
> >      -r /home/stack/templates/roles_data.yaml \
> >      -n /home/stack/templates/network_data.yaml \
> >      -e /home/stack/templates/environment.yaml \
> >      -e /home/stack/templates/environments/network-isolation.yaml \
>
> Most likely the mapping is in this network-isolation.yaml.
> If you use the in-tree environment
> `/usr/share/openstack-tripleo-heat-tempaltes/envioronments/network-isolation.yaml`
>
> instead you should not run into these type of issues on upgrade.
>
> >      -e /home/stack/templates/environments/network-environment.yaml \
>
> I would also recommend to use the in-tree network-environment.yaml
>   -e
>
> /usr/share/openstack-tripleo-heat-tempaltes/envioronments/network-environment.yaml
>
> Then add another file to override anything in the in-tree
> network-environment.yaml.
>   -e /home/stack/templates/environments/network-environment-overrides.yaml
>
> >      -e
> >
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
>
> > \
> >      -e
> >
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
>
> > \
> >      -e
> >
> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
>
> > \
> >      -e /home/stack/templates/ironic-config.yaml \
> >      -e
> > /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \
> >      -e
> > /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
> >      -e /home/stack/templates/init-repo.yaml \
> >      -e /home/stack/containers-prepare-parameter.yaml
>
>
> --
> Harald
>
>

-- 
~ Lokendra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/ffa56483/attachment.htm>

From elfosardo at gmail.com  Fri Mar  4 10:36:47 2022
From: elfosardo at gmail.com (Riccardo Pittau)
Date: Fri, 4 Mar 2022 11:36:47 +0100
Subject: [ironic] Zed PTG slots
In-Reply-To: <CAJqPaj8M4BgPpsQPG9mtvnXkbHPVtSeK3cG1Ws+aaeC1skRsgw@mail.gmail.com>
References: <CAJqPaj8M4BgPpsQPG9mtvnXkbHPVtSeK3cG1Ws+aaeC1skRsgw@mail.gmail.com>
Message-ID: <CAORRS=nacYs+yiVRzto=TgvRJPnzXR_u3XAuGkJsmgd+-R3=vg@mail.gmail.com>

Thanks Iury!

My choices are for options #1 and #3

Ciao!
Riccardo

On Fri, Mar 4, 2022 at 4:28 AM Iury Gregory <iurygregory at gmail.com> wrote:

> Hello Ironicers!
>
> For the Zed PTG I'm planning to have some slots that will allow APAC
> contributors to participate in the discussions.
>
> Keep in mind that we have some guidelines we should try to follow:
> 1. Cross project discussions (like SIGs or support project teams) should
> be scheduled towards the start of the week so that any discussions that
> might shape those of other teams happen first.
> 2. No team should sign up for more than 4 hours per UTC day to help keep
> participants actively engaged.
> 3. No team should sign up for more than 16 hours across all time slots to
> avoid burning out our contributors and to enable participation in multiple
> teams discussions.
>
> Based on this I have the following proposals: (Feel free to provide more
> ideas also) =)
>  *Option  #1* *16hrs* Monday till Thursday
> 1h (APAC night + EMEA morning)
> 2hrs (EMEA afternoon + NA morning)
> 1hr (NA afternoon/night + APAC morning)
>
> *Option  #2* *15hrs* Tuesday till Friday
> 1h (APAC night + EMEA morning)
> 2hrs (EMEA afternoon + NA morning)
> 1hr (NA afternoon/night + APAC morning)
> * On Friday the NA + APAC session won't happen because is saturday for
> APAC contributors *
>
> *Option #3* *16hrs* Monday till Thursday
> 3hrs (EMEA afternoon + NA morning)
> 1hr (NA afternoon/night + APAC morning)
>
> *Option #4* *15hrs* Tuesday till Friday
> 3hrs (EMEA afternoon + NA morning)
> 1hr (NA afternoon/night + APAC morning)
> * On Friday the NA + APAC session won't happen because is saturday for
> APAC contributors *
>
> Please choose two options and we will vote during our upstream meeting on
> March 7th.
>
> Thank you!
>
> --
>
>
> *Att[]'sIury Gregory Melo Ferreira *
> *MSc in Computer Science at UFCG*
> *Part of the ironic-core and puppet-manager-core team in OpenStack*
> *Software Engineer at Red Hat Czech*
> *Social*: https://www.linkedin.com/in/iurygregory
> *E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/54c662e9/attachment-0001.htm>

From sbauza at redhat.com  Fri Mar  4 10:51:36 2022
From: sbauza at redhat.com (Sylvain Bauza)
Date: Fri, 4 Mar 2022 11:51:36 +0100
Subject: [nova][placement] Zed PTG preparation
Message-ID: <CALOCmunC+kKyu3g6sN+UyOJeEa=+aH9+15x5BodhF9R7p5rBdQ@mail.gmail.com>

Hey folks,

We have until Mar 11th [1]to communicate about our needs for the Zed PTG
(I've already signed up our presence by the survey) .As you can see in [2],
there are already projects that booked some timeslots.

This time, I won't ask you to tell me over Doodle which times you can be
around, but I'd rather propose you 3 options :

Option A "The short one"  : we ask for 3 days from Wednesday to Friday with
4 hours each (13UTC-17UTC)
Option B "The week used": we ask for 4 days from Tuesday to Friday with 3
hours each (14UTC-17UTC)
Option C "The largest one" : we ask for 4 days from Tuesday to Friday with
4 hours each (13UTC-17UTC)
Option D "The Asian-nice one" : we ask for Wed to Friday with 3 hours each
(14UTC-17UTC) but we also ask for Thursday with 2 hours (6UTC-8UTC)

Please start to think about those options as we'll discuss this on next
Tuesday meeting [3] and eventually we will vote on it.

I also created a new etherpad for our PTG :
https://etherpad.opendev.org/p/nova-zed-ptg
If you want, you can start to collect some topics but also if you aren't
able to attend next Nova meeting, you can also start to vote on the option
above in there.

Voila, that's it.
Thanks and let's discuss it again on next meeting,
-Sylvain

[1]
http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027051.html
[2] https://ethercalc.openstack.org/7yxdas7suqnd
[3] https://meetings.opendev.org/#Nova_Team_Meeting
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/fed208f4/attachment.htm>

From juliaashleykreger at gmail.com  Fri Mar  4 14:03:09 2022
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Fri, 4 Mar 2022 06:03:09 -0800
Subject: [Ironic] No suitable device was found for deployment
In-Reply-To: <CAOirdiXE13w8LGpcnqzMjgn2JdawSYmY2f_r72rSu-CuLXQgFw@mail.gmail.com>
References: <CAOirdiX4RuYYdzmDWBp0Ofua0B6BV0mGat0YWnwZZwebmMOeQQ@mail.gmail.com>
 <fbcd7e11-e4b4-6022-0b5e-df42b1d9b998@cern.ch>
 <CAOirdiV8s80SYcbtZ8G4-VCMs9OGvfeVy=CF-d8V0Fw0N9xO0g@mail.gmail.com>
 <04af20bb-143b-9b56-6787-d5ac6ab0d38c@cern.ch>
 <CAF7gwdgkJiXShCM0z1ZyERj0=Z63713Xy6JXctwazNobqvxqVw@mail.gmail.com>
 <CAOirdiUPkXOVZDg8DgrOMDeK8xJxPGcbsu4Y+XPVCbbjJOGCDg@mail.gmail.com>
 <ca926b29-9dff-cceb-5734-7d510a48a045@cern.ch>
 <CAOirdiUEO+yE1=KN-kEVLR3sRBY15weFjc_kRzMEboS=UjZ-gA@mail.gmail.com>
 <3209d9fc-8db1-6dca-5736-402c6f082fcc@cern.ch>
 <CAF7gwdhXXWA_Q0ZO57w24oCY7FoeuxMwah7shRj_tEdpeBPiMw@mail.gmail.com>
 <CAOirdiXE13w8LGpcnqzMjgn2JdawSYmY2f_r72rSu-CuLXQgFw@mail.gmail.com>
Message-ID: <CAF7gwdj2jbJh+rYRnkORDgj2UnCbhvc8e1_DxYWbaQmOY3bcSw@mail.gmail.com>

Seems like your issue is in raid controller configuration. And based
on the MegaCli output, I doubt the disks  are security locked. I would
remove the disks, get into the bios/firmware menus, and try to delete
them, then try to re-import the disks. Alternatively, it may be
worthwhile to take the disks and attempt to use them in a desktop or
something where a MegaRAID controller is not in the mix in case it is
something with configuration on the disk as well. Examining outside of
a MegaRAID controller would hopefully give you an idea of operational
state as well.

-Julia

On Fri, Mar 4, 2022 at 1:25 AM ??? <hanguangyu2 at gmail.com> wrote:
>
> Hi Julia,
>
> Sorry that my last email didn't reploy some question in your email.
> When I get into RAID config menu, I said disk state is "unconfig bad".
> And the more info is that Virtual Drive Management displayed "No
> Configuration Present!". But I cound not modify disk state in RAID
> confug menu. Even if I moved the disk to other server, and used the
> software in operating system to modify it, it still coudn't to be
> modify. such as:
> ```shell
> # MegaCli -PDList -a0
>
> Adapter #0
>
> Enclosure Device ID: 252
> Slot Number: 1
> Enclosure position: 0
> Device Id: 9
> WWN: 50014EE2BE72FEBF
> Sequence Number: 2
> Media Error Count: 0
> Other Error Count: 0
> Predictive Failure Count: 0
> Last Predictive Failure Event Seq Number: 0
> PD Type: SATA
> Raw Size: 0 KB [0x0 Sectors]
> Non Coerced Size: 0 KB [0x0 Sectors]
> Coerced Size: 0 KB [0x0 Sectors]
> Firmware state: Unconfigured(bad)
> Device Firmware Level: WA09
> Shield Counter: 0
> Successful diagnostics completion on :  N/A
> SAS Address(0): 0x4433221101000000
> Connected Port Number: 0(path0)
> Inquiry Data: ATA     HGST HUS722T2TALWA09WCC6N4HZV9SX
> FDE Enable: Disable
> Secured: Unsecured
> Locked: Unlocked
> Needs EKM Attention: No
> Foreign State: None
> Device Speed: Unknown
> Link Speed: 6.0Gb/s
> Media Type: Hard Disk Device
> Drive Temperature :0C (32.00 F)
> PI Eligibility:  No
> Drive is formatted for PI information:  No
> PI: No PI
> Drive's write cache : Disabled
> Drive's NCQ setting : Enabled
> Port-0 :
> Port status: Active
> Port's Linkspeed: 6.0Gb/s
> Drive has flagged a S.M.A.R.T alert : No
>
>
>
> Enclosure Device ID: 252
> Slot Number: 2
> Enclosure position: 0
> Device Id: 10
> WWN: 50014EE2691D724C
> Sequence Number: 2
> Media Error Count: 0
> Other Error Count: 0
> Predictive Failure Count: 0
> Last Predictive Failure Event Seq Number: 0
> PD Type: SATA
> Raw Size: 0 KB [0x0 Sectors]
> Non Coerced Size: 0 KB [0x0 Sectors]
> Coerced Size: 0 KB [0x0 Sectors]
> Firmware state: Unconfigured(bad)
> Device Firmware Level: WA09
> Shield Counter: 0
> Successful diagnostics completion on :  N/A
> SAS Address(0): 0x4433221102000000
> Connected Port Number: 1(path0)
> Inquiry Data: ATA     HGST HUS722T2TALWA09WCC6N4HZVTV5
> FDE Enable: Disable
> Secured: Unsecured
> Locked: Unlocked
> Needs EKM Attention: No
> Foreign State: None
> Device Speed: Unknown
> Link Speed: 6.0Gb/s
> Media Type: Hard Disk Device
> Drive Temperature :0C (32.00 F)
> PI Eligibility:  No
> Drive is formatted for PI information:  No
> PI: No PI
> Drive's write cache : Disabled
> Drive's NCQ setting : Enabled
> Port-0 :
> Port status: Active
> Port's Linkspeed: 6.0Gb/s
> Drive has flagged a S.M.A.R.T alert : No
>
>
>
> Enclosure Device ID: 252
> Slot Number: 3
> Enclosure position: 0
> Device Id: 11
> WWN: 50014EE2BE733A5E
> Sequence Number: 2
> Media Error Count: 0
> Other Error Count: 0
> Predictive Failure Count: 0
> Last Predictive Failure Event Seq Number: 0
> PD Type: SATA
> Raw Size: 1.819 TB [0xe8e088b0 Sectors]
> Non Coerced Size: 1.818 TB [0xe8d088b0 Sectors]
> Coerced Size: 1.818 TB [0xe8d00000 Sectors]
> Firmware state: JBOD
> Device Firmware Level: WA09
> Shield Counter: 0
> Successful diagnostics completion on :  N/A
> SAS Address(0): 0x4433221103000000
> Connected Port Number: 2(path0)
> Inquiry Data: WCC6N0KX0HJD        HGST HUS722T2TALA604
>    RAGNWA09
> FDE Enable: Disable
> Secured: Unsecured
> Locked: Unlocked
> Needs EKM Attention: No
> Foreign State: None
> Device Speed: 6.0Gb/s
> Link Speed: 6.0Gb/s
> Media Type: Hard Disk Device
> Drive Temperature :34C (93.20 F)
> PI Eligibility:  No
> Drive is formatted for PI information:  No
> PI: No PI
> Drive's write cache : Enabled
> Drive's NCQ setting : Enabled
> Port-0 :
> Port status: Active
> Port's Linkspeed: 6.0Gb/s
> Drive has flagged a S.M.A.R.T alert : No
>
>
>
>
> Exit Code: 0x00
> ```
> ```shell
> # MegaCli -PDList -a0 | grep state
> Firmware state: Unconfigured(bad)
> Firmware state: Unconfigured(bad)
> Firmware state: JBOD
> # MegaCli -PDMakeGood -PhysDrv[252:2] -a0
>
> Adapter: 0: Failed to change PD state at EnclId-252 SlotId-2.
>
> Exit Code: 0x01
> ```
>
> And the "security locked state" is a idea that I continue. I will try
> to determine if it is in this state and find a way to disarm it.
>
> Thank you very much Julia,
> cheers,
> Han Guangyu
>
> Julia Kreger <juliaashleykreger at gmail.com> ?2022?3?1??? 22:06???
> >
> > On Mon, Feb 28, 2022 at 1:12 AM Arne Wiebalck <arne.wiebalck at cern.ch> wrote:
> > >
> > > Hi Guangyu,
> > >
> > > I am not aware of anything in the Ironic Python Agent that
> > > would remove disks from the system in a way that they would
> > > not be visible after a reboot (apart from, as mentioned before,
> > > the clean up of a hardware RAID in a way the IPA is not able
> > > to see any devices after).
> > >
> > > How about trying to access and configure the hardware RAID with
> > > the corresponding tool from the RAM disk you booted into from the
> > > USB stick? Install the tool and see if it detects the controller.
> > >
> > > The very first step before doing anything with Ironic is to
> > > get the disks back or understand why they are not visible.
> > >
> >
> > Did cleaning fail at any given point with these machines?
> >
> > If you have physical access, try disconnecting all of the drives, and
> > then powering up the machine and see if you can get into the firmware
> > configuration screen with control-h. If you can, remove all of the
> > prior configuration or disk volumes. They will look like they are in
> > error states most likely. If your unable to get into this screen, I
> > would be worried about your disk controller card. If your able to
> > clear everything out of the controller, power off, try re-inserting
> > drives, and see what happens. See if the controller can view/interact
> > with the drives. If it sees no drives, then my next paragraph is
> > likely the case.
> >
> > The disks sound like they might be in security locked state which will
> > likely require a desktop SATA disk controller to remedy by attaching
> > and manually removing from a security locked state. Megaraid
> > controllers can't recognize security locked devices (most controllers
> > and especially ones labeled "raid controllers" can't handle it) when
> > in pass-through mode, but I've never heard of security lock commands
> > actually getting through to the device with those controllers in
> > pass-through mode. If the card was in raid mode to begin with, then it
> > likely never did anything involving secure erase as the controller
> > should not be offering that as a feature of provided disks to the OS.
> >
> > > Cheers,
> > >   Arne
> > >
> > > On 28.02.22 09:28, ??? wrote:
> > > > Hi Arne,
> > > >
> > > > I didn't find hardware RAID config option during the initial boot
> > > > sequence. Ctrl+H is unresponsive in this computer. I just saw "Press
> > > > Del to enter firmware configuration, press F3 to enter boot menu, and
> > > > press F12 to enter network boot". And I press 'Del' to enter the BIOS.
> > > > But I didn't find RAID config menu in BIOS. Sorry that I have poor
> > > > knowledge about this.
> > > >
> > > > And now, even though I installed the operating system manually using a
> > > > USB stick, I still couldn't find the hard drive. Is there anything
> > > > that ironic-agent did in the clean phase that would have caused this
> > > > problem?
> > > >
> > > > I wonder if this is a thinking pointto solve the problem. Now, my idea
> > > > is to first find a way to manually configure RAID.  Do you agree with
> > > > this?  And than, whether RAID configurations are still cleared in the
> > > > Clean phase if clean phase will do this?
> > > >
> > > > Sorry that I have so much confuse.
> > > >
> > > > love you,
> > > > Guangyu
> > > >
> > > > Arne Wiebalck <arne.wiebalck at cern.ch> ?2022?2?14??? 15:59???
> > > >>
> > > >> Hi Guangyu,
> > > >>
> > > >> It seems like Julia had the right idea and the disks
> > > >> are not visible since the RAID controller does not
> > > >> expose anything to the operating system. This seems
> > > >> to be confirmed by you booting into the CentOS7 image.
> > > >>
> > > >> What I would suggest to try next is to look for the
> > > >> hardware RAID config option during the initial boot
> > > >> sequence to enter the RAID config menu (there should be
> > > >> a message quite early on, and maybe Ctrl-H is needed
> > > >> to enter the menu).
> > > >>
> > > >> Once there, manually configure the disks as JBODs or
> > > >> create a RAID device. Upon reboot this should be visible
> > > >> and accessible as a device. Maybe check from your CentOS7
> > > >> image again. If the devices are there, Ironic should
> > > >> also be able to deploy on them (for this you can remove
> > > >> the RAID config you added).
> > > >>
> > > >> It depends a little on what your goal is, but I would
> > > >> try this first to see if you can make a device visible
> > > >> and if the Ironic deploy bit works, before trying to
> > > >> configure the hardware RAID via Ironic.
> > > >>
> > > >> Cheers,
> > > >>    Arne
> > > >>
> > > >> On 14.02.22 03:20, ??? wrote:
> > > >>> Hi Arne and Julia,
> > > >>>
> > > >>> You make me feel so warm. Best wishes to you.
> > > >>>
> > > >>> I have tried to boot the node into a CentOS7, but it still coundnot to
> > > >>> find disk. And sorry that I didn't notice the RAID card.
> > > >>>
> > > >>> # lspci -v
> > > >>> ...
> > > >>> 23:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS-3 3108
> > > >>> [Invader] (rev 02)
> > > >>>           Subsystem: Broadcom / LSI MegaRAID SAS 9361-8i
> > > >>>           Flags: bus master, fast devsel, latency 0, IRQ -2147483648, NUMA node 1
> > > >>>           I/O ports at 3000 [size=256]
> > > >>>           Memory at e9900000 (64-bit, non-prefetchable) [size=64K]
> > > >>>           Memory at e9700000 (64-bit, non-prefetchable) [size=1M]
> > > >>>           Expansion ROM at e9800000 [disabled] [size=1M]
> > > >>>           Capabilities: [50] Power Management version 3
> > > >>>           Capabilities: [68] Express Endpoint, MSI 00
> > > >>>           Capabilities: [d0] Vital Product Data
> > > >>>           Capabilities: [a8] MSI: Enable- Count=1/1 Maskable+ 64bit+
> > > >>>           Capabilities: [c0] MSI-X: Enable+ Count=97 Masked-
> > > >>>           Capabilities: [100] Advanced Error Reporting
> > > >>>           Capabilities: [1e0] #19
> > > >>>           Capabilities: [1c0] Power Budgeting <?>
> > > >>>           Capabilities: [148] Alternative Routing-ID Interpretation (ARI)
> > > >>>           Kernel driver in use: megaraid_sas
> > > >>>           Kernel modules: megaraid_sas
> > > >>> ...
> > > >>>
> > > >>> I try to config raid fallowing
> > > >>> https://docs.openstack.org/ironic/latest/admin/raid.html
> > > >>> by `baremetal node set $NODE_UUID --target-raid-config raid.json`. The
> > > >>> server have  three same disk(Western Digital DC HA210 2TB SATA 6GB/s)
> > > >>> # cat raid.json
> > > >>> {
> > > >>>     "logical_disks": [
> > > >>>       {
> > > >>>         "size_gb": "MAX",
> > > >>>         "raid_level": "0",
> > > >>>         "is_root_volume": true
> > > >>>       }
> > > >>>     ]
> > > >>> }
> > > >>>
> > > >>> But Ironic still coundn't see disk. I still got
> > > >>> ```
> > > >>> ## In deploy images
> > > >>> # journalctl -fxeu ironic-python-agent
> > > >>> Feb 14 02:17:22 host-10-12-22-74 ironic-python-agent[2329]: 2022-02-14
> > > >>> 02:17:22.863 2329 WARNING root [-] Path /dev/disk/by-path is
> > > >>> inaccessible, /dev/disk/by-path/* version of block device name is
> > > >>> unavailable Cause: [Errno 2] No such file or directory:
> > > >>> '/dev/disk/by-path': FileNotFoundError: [Errno 2] No such file or
> > > >>> directory: '/dev/disk/by-path'
> > > >>> Feb 14 02:17:44 host-10-12-22-74 ironic-python-agent[2329]: 2022-02-14
> > > >>> 02:17:44.391 2329 ERROR root [-] Unexpected error dispatching
> > > >>> get_os_install_device to manager
> > > >>> <ironic_python_agent.hardware.GenericHardwareManager object at
> > > >>> 0x7efbf4da2208>: Error finding the disk or partition device to deploy
> > > >>> the image onto: No suitable device was found for deployment - root
> > > >>> device hints were not provided and all found block devices are smaller
> > > >>> than 4294967296B.: ironic_python_agent.errors.DeviceNotFound: Error
> > > >>> finding the disk or partition device to deploy the image onto: No
> > > >>> suitable device was found for deployment - root device hints were not
> > > >>> provided and all found block devices are smaller than 4294967296B.
> > > >>> ```
> > > >>>
> > > >>> I don't know if it's a lack of a RAID card driver or a lack of a disk
> > > >>> driver or a lack of RAID configuration. Could you have some idea about
> > > >>> this question?
> > > >>>
> > > >>> love you,
> > > >>> Han Guangyu
> > > >>>
> > > >>>
> > > >>> Julia Kreger <juliaashleykreger at gmail.com> ?2022?2?10??? 23:11???
> > > >>>
> > > >>>>
> > > >>>> If the disk controllers *are* enumerated in the kernel log, which is
> > > >>>> something to also look for, then the disks themselves may be in some
> > > >>>> weird state like security locked. Generally this shows up as the
> > > >>>> operating system kind of sees the disk and the SATA port connected but
> > > >>>> can't really access it. This is also an exceptionally rare state to
> > > >>>> find one's self in.
> > > >>>>
> > > >>>> More common, especially in enterprise grade hardware: If the disk
> > > >>>> controller is actually a raid controller, and there are no raid
> > > >>>> volumes configured, then the operating system likely cannot see the
> > > >>>> underlying disks and turn that into a usable block device. I've seen a
> > > >>>> couple drivers over the years which expose hints of disks in the
> > > >>>> kernel log and without raid configuration in the cards, the drivers
> > > >>>> can't present usable block devices to the operating system system.
> > > >>>>
> > > >>>> -Julia
> > > >>>>
> > > >>>> On Thu, Feb 10, 2022 at 3:17 AM Arne Wiebalck <arne.wiebalck at cern.ch> wrote:
> > > >>>>>
> > > >>>>> Hi Guangyu,
> > > >>>>>
> > > >>>>> No worries about asking questions, this is what the mailing
> > > >>>>> list is for :)
> > > >>>>>
> > > >>>>> Just to clarify, you do not have to set root device hints,
> > > >>>>> it also works without (with the algorithm I mentioned).
> > > >>>>> However, hints help to define the exact device and/or make
> > > >>>>> deployment more predictable/repeatable.
> > > >>>>>
> > > >>>>> If it is really a driver problem, it is an issue with the
> > > >>>>> operating system of the image you use, i.e. CentOS8. Some
> > > >>>>> drivers were removed from 7 to 8, and we have seen issues
> > > >>>>> with specific drive models as well.
> > > >>>>>
> > > >>>>> You can try to build your own IPA images as described in
> > > >>>>> [1], e.g. to add your ssh key to be able to log into the
> > > >>>>> IPA to debug further, and to eventually include drivers
> > > >>>>> (if you can identify them and they are available for CentOS8).
> > > >>>>>
> > > >>>>> Another option may be to add another (newer) disk model to
> > > >>>>> the server, just to confirm it is the disk model/driver which
> > > >>>>> is the cause.
> > > >>>>>
> > > >>>>> You could also try to boot the node into a CentOS7 (and then
> > > >>>>> a CentOS8) live image to confirm it can see the disks at all.
> > > >>>>>
> > > >>>>> Hope this helps!
> > > >>>>>     Arne
> > > >>>>>
> > > >>>>> [1]
> > > >>>>> https://docs.openstack.org/ironic-python-agent-builder/latest/admin/dib.html
> > > >>>>>
> > > >>>>>
> > > >>>>> On 10.02.22 11:15, ??? wrote:
> > > >>>>>> Hi Arne,
> > > >>>>>>
> > > >>>>>> Thank you very much for your response. Love you. You take away a lot
> > > >>>>>> of my confusion.
> > > >>>>>>
> > > >>>>>> You are right, I didn't set 'root device'. And Ironic also can not see
> > > >>>>>> disk, the content of the 'lsblk' file in the deploy los is emply.
> > > >>>>>> I tried to set 'root device', but because ironic can't find any disk,
> > > >>>>>> the deploy still filed.
> > > >>>>>>
> > > >>>>>> Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
> > > >>>>>> 09:51:55.045 2324 WARNING root [-] Path /dev/disk/by-path is
> > > >>>>>> inaccessible, /dev/disk/by-path/* version of block device name is
> > > >>>>>> unavailable Cause: [Errno 2] No such file or directory:
> > > >>>>>> '/dev/disk/by-path': FileNotFoundError: [Errno 2] No such file or
> > > >>>>>> directory: '/dev/disk/by-path'
> > > >>>>>> Feb 10 09:51:55 host-10-12-22-59 ironic-python-agent[2324]: 2022-02-10
> > > >>>>>> 09:51:55.056 2324 WARNING ironic_lib.utils [-] No device found that
> > > >>>>>> matches the root device hints {'wwn': '0x50014EE2691D724C'}:
> > > >>>>>> StopIteration
> > > >>>>>>
> > > >>>>>> Sorry to bother you, I'm a newcomer of Ironic and I didn't find
> > > >>>>>> information about it on google.
> > > >>>>>>
> > > >>>>>> The bare metal node have three same disk(Western Digital DC HA210 2TB
> > > >>>>>> SATA 6GB/s). Where I can confirm whether ironic-python-agent supports
> > > >>>>>> this disk?
> > > >>>>>>
> > > >>>>>> And If Ironic cannot find disk since the corresponding drivers in the
> > > >>>>>> IPA image are missing, do you know how to resolve it? I have used the
> > > >>>>>> latest deploy images in
> > > >>>>>> https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/
> > > >>>>>> .  Do I need to find and manually add driver in the source code or
> > > >>>>>> ramdisk(That was difficult tome)?
> > > >>>>>>
> > > >>>>>> Love you.
> > > >>>>>>
> > > >>>>>> Cheers,
> > > >>>>>> Guangyu
> > > >>>>>>
> > > >>>>>> Arne Wiebalck <arne.wiebalck at cern.ch> ?2022?2?10??? 15:51???
> > > >>>>>>>
> > > >>>>>>> Hi Guangyu,
> > > >>>>>>>
> > > >>>>>>> The error indicates that Ironic was not able to find
> > > >>>>>>> a device where it could deploy the image to.
> > > >>>>>>>
> > > >>>>>>> To find a device, Ironic will use 'root device'
> > > >>>>>>> hints [1], usually set by the admin on a node. If that
> > > >>>>>>> does not yield anything, Ironic will loop over all
> > > >>>>>>> block devices and pick the smallest which is larger
> > > >>>>>>> than 4GB (and order them alphabetically).
> > > >>>>>>>
> > > >>>>>>> If you have disks in your server which are larger than
> > > >>>>>>> 4GB, one potential explanation is that Ironic cannot see them,
> > > >>>>>>> e.g. since the corresponding drivers in the IPA image are missing.
> > > >>>>>>> The logs you posted seem to confirm something along those
> > > >>>>>>> lines.
> > > >>>>>>>
> > > >>>>>>> Check the content of the 'lsblk' file in the deploy logs which
> > > >>>>>>> you can find in the tar archive in /var/log/ironic/deploy/
> > > >>>>>>> on the controller for your deployment attempt to see what
> > > >>>>>>> devices Ironic has access to.
> > > >>>>>>>
> > > >>>>>>> Cheers,
> > > >>>>>>>      Arne
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> [1] https://docs.openstack.org/ironic/latest/install/advanced.html#root-device-hints
> > > >>>>>>>
> > > >>>>>>> On 10.02.22 02:50, ??? wrote:
> > > >>>>>>>> Dear all,
> > > >>>>>>>>
> > > >>>>>>>> I have a OpenStack Victoria environment, and tried to use ironic
> > > >>>>>>>> manage bare metal. But I got "- root device hints were not provided
> > > >>>>>>>> and all found block devices are smaller than 4294967296B." in deploy
> > > >>>>>>>> stage.
> > > >>>>>>>>
> > > >>>>>>>> 2022-02-09 17:57:56.492 3908982 ERROR
> > > >>>>>>>> ironic.drivers.modules.agent_base [-] Agent returned error for deploy
> > > >>>>>>>> step {'step': 'write_image', 'priority': 80, 'argsinfo': None,
> > > >>>>>>>> 'interface': 'deploy'} on node cc68c450-ce54-4e1c-be04-8b0a6169ef92 :
> > > >>>>>>>> No suitable device was found for deployment - root device hints were
> > > >>>>>>>> not provided and all found block devices are smaller than
> > > >>>>>>>> 4294967296B..
> > > >>>>>>>>
> > > >>>>>>>> I used "openstack server create --flavor my-baremetal-flavor --nic
> > > >>>>>>>> net-id=$net_id --image $image testing" to deploy bare metal node.  I
> > > >>>>>>>> download deploy images(ipa-centos8-master.kernel and
> > > >>>>>>>> ipa-centos8-master.initramfs) in
> > > >>>>>>>> https://tarballs.opendev.org/openstack/ironic-python-agent/dib/files/.
> > > >>>>>>>>
> > > >>>>>>>> The baremetal node info and flavor info as following:
> > > >>>>>>>> https://paste.opendev.org/show/bV7lgO6RkNQY6ZGPbT2e/
> > > >>>>>>>> Ironic configure file as following:
> > > >>>>>>>> https://paste.opendev.org/show/bTgY9Kpn7KWqwQl73aEa/
> > > >>>>>>>> Ironic-conductor log:    https://paste.opendev.org/show/bFKZYlXmccxNxU8lEogk/
> > > >>>>>>>> The log of ironic-python-agent in bare metal node:
> > > >>>>>>>> https://paste.opendev.org/show/btAuaMuV2IutV2Pa7YIa/
> > > >>>>>>>>
> > > >>>>>>>> I see some old discussion about this, such as:
> > > >>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1312187. But those
> > > >>>>>>>> discussions took place a long time ago, not version V, and no solution
> > > >>>>>>>> was seen.
> > > >>>>>>>>
> > > >>>>>>>> Does anyone know how to solve this problem? I would appreciate any
> > > >>>>>>>> kind of guidance or help.
> > > >>>>>>>>
> > > >>>>>>>> Thank you,
> > > >>>>>>>> Han Guangyu
> > > >>>>>>>>
> > > >>>>>


From iurygregory at gmail.com  Fri Mar  4 15:05:40 2022
From: iurygregory at gmail.com (Iury Gregory)
Date: Fri, 4 Mar 2022 12:05:40 -0300
Subject: [requirements][release][rfe] sushy 4.1.1 for Yoga
Message-ID: <CAJqPaj9vtMLGMEoyh34VAG8HxsQjmdiNdDtoLqG8QxPBkryHBg@mail.gmail.com>

Hello Stackers,

I would like to request a new release for sushy before creating the yoga
branch, It contains some important fixes (e.g it will fix a problem when
build sushy in Debian). The sushy lib is only used by ironic, so it
shouldn't cause any problems updating the version in requirements.

Thanks!

-- 


*Att[]'sIury Gregory Melo Ferreira *
*MSc in Computer Science at UFCG*
*Part of the ironic-core and puppet-manager-core team in OpenStack*
*Software Engineer at Red Hat Czech*
*Social*: https://www.linkedin.com/in/iurygregory
*E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/c7811278/attachment-0001.htm>

From iurygregory at gmail.com  Fri Mar  4 16:11:51 2022
From: iurygregory at gmail.com (Iury Gregory)
Date: Fri, 4 Mar 2022 13:11:51 -0300
Subject: [requirements][release][rfe] sushy 4.1.1 for Yoga
In-Reply-To: <20220304152607.tkkvd7qhyl6o5ppu@domaintools.com>
References: <CAJqPaj9vtMLGMEoyh34VAG8HxsQjmdiNdDtoLqG8QxPBkryHBg@mail.gmail.com>
 <20220304152607.tkkvd7qhyl6o5ppu@domaintools.com>
Message-ID: <CAJqPaj-YOPLYDbarpgo-BA-SVHAMOQWp4Qc9JvByU3kg3QRG0Q@mail.gmail.com>

Hi Matthew

You can find the diff in [1], thanks!

[1]
https://zuul.opendev.org/t/openstack/build/4894a7e4d02e4892adab5ca4cefc8e89/log/tox/list-changes-results.log#280-408


Em sex., 4 de mar. de 2022 ?s 12:26, Matthew Thode <mthode at domaintools.com>
escreveu:

> On 22-03-04 12:05:40, Iury Gregory wrote:
> > Hello Stackers,
> >
> > I would like to request a new release for sushy before creating the yoga
> > branch, It contains some important fixes (e.g it will fix a problem when
> > build sushy in Debian). The sushy lib is only used by ironic, so it
> > shouldn't cause any problems updating the version in requirements.
> >
> > Thanks!
> >
> > --
> >
> >
> > *Att[]'sIury Gregory Melo Ferreira *
> > *MSc in Computer Science at UFCG*
> > *Part of the ironic-core and puppet-manager-core team in OpenStack*
> > *Software Engineer at Red Hat Czech*
> > *Social*: https://www.linkedin.com/in/iurygregory
> > *E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*
>
> Hi, can you link to the diff?
>
> --
> Matthew Thode
>


-- 


*Att[]'sIury Gregory Melo Ferreira *
*MSc in Computer Science at UFCG*
*Part of the ironic-core and puppet-manager-core team in OpenStack*
*Software Engineer at Red Hat Czech*
*Social*: https://www.linkedin.com/in/iurygregory
*E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/c412d912/attachment.htm>

From Molka.Gharbaoui at santannapisa.it  Fri Mar  4 16:21:45 2022
From: Molka.Gharbaoui at santannapisa.it (Molka Gharbaoui)
Date: Fri, 4 Mar 2022 16:21:45 +0000
Subject: R: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics
 using ceilometer and gnocchi
In-Reply-To: <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
 <VE1PR03MB55500139D4A8F6C4447C167FEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
Message-ID: <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>

Unfortunately, the local.conf file shared by Matthias gives the same result: no metrics are pushed to gnocchi.

Gnocchi database is empty: I can create metrics and resources manually but nothing is pushed from ceilometer to the database. So I guess the problem is at the ceilometer level.

Here is an extract of the ceilometer-polling logs:

2022-03-04 16:13:07.904 679128 INFO ceilometer.polling.manager [-] Polling pollster disk.device.usage in the context of all_pollsters
2022-03-04 16:13:07.904 679128 DEBUG ceilometer.compute.pollsters [-] afcf32c4-e7c2-40fd-8f75-fdf0bfdb5ef9/disk.device.usage volume: 5368709120 _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108
2022-03-04 16:13:07.907 679128 INFO ceilometer.polling.manager [-] Polling pollster disk.device.read.requests in the context of all_pollsters
2022-03-04 16:13:07.908 679128 DEBUG ceilometer.compute.pollsters [-] afcf32c4-e7c2-40fd-8f75-fdf0bfdb5ef9/disk.device.read.requests volume: 6138 _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108
2022-03-04 16:13:08.038 679128 WARNING ceilometer.neutron_client [-] The resource could not be found.: neutronclient.common.exceptions.NotFound: The resource could not be found.
2022-03-04 16:13:08.038 679128 DEBUG ceilometer.polling.manager [-] Skip pollster network.services.lb.pool, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.162 679128 WARNING ceilometer.neutron_client [-] The resource could not be found.: neutronclient.common.exceptions.NotFound: The resource could not be found.
2022-03-04 16:13:08.162 679128 DEBUG ceilometer.polling.manager [-] Skip pollster network.services.lb.vip, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.163 679128 DEBUG ceilometer.polling.manager [-] Skip pollster network.services.lb.outgoing.bytes, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.164 679128 ERROR ceilometer.polling.manager [-] Skipping tenant, keystone issue: admin endpoint for identity service in RegionOne region not found: keystoneauth1.exceptions.catalog.EndpointNotFound: admin endpoint for identity service in RegionOne region not found
2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip pollster radosgw.containers.objects.size, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip pollster port.receive.packets, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip pollster hardware.network.ip.outgoing.datagrams, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.355 679128 WARNING ceilometer.neutron_client [-] The resource could not be found.: neutronclient.common.exceptions.NotFound: The resource could not be found.
2022-03-04 16:13:08.355 679128 DEBUG ceilometer.polling.manager [-] Skip pollster network.services.lb.listener, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177

And here I report the content of the ceilometer.conf file:
[DEFAULT]
debug = True
transport_url = rabbit://stackrabbit:admin at 10.30.2.194:5672/<http://stackrabbit:admin at 10.30.2.194:5672/>

[oslo_messaging_notifications]
topics = notifications

[coordination]
backend_url = redis://localhost:6379

[notification]
workers = 2

[cache]
backend_argument = url:redis://localhost:6379
backend_argument = distributed_lock:True
backend_argument = db:0
backend_argument = redis_expiration_time:600
backend = dogpile.cache.redis
enabled = True

[service_credentials]
auth_url = http://10.30.2.194/identity<http://10.30.2.194/identity/v3/>
region_name = RegionOne
password = admin
username = ceilometer
project_name = service
project_domain_name = default
user_domain_id = default
auth_type = password

[keystone_authtoken]
memcached_servers = localhost:11211
cafile = /opt/stack/data/ca-bundle.pem
project_domain_name = default
project_name = admin
user_domain_name = default
password = admin
username = ceilometer
auth_url = http://10.30.2.194/identity<http://10.30.2.194/identity/v3/>
interface = public
auth_type = password

I believe nothing should be changed in the configuration files since Devstack should configure every components automatically. I also checked pipeline.yaml and polling.yaml files and they seem correct.

Do you have any idea on how to make ceilometer push metrics to the gnocchi database??

Thanks.


________________________________
Da: Matthias Runge <mrunge at matthias-runge.de>
Inviato: gioved? 3 marzo 2022 13:58
A: Molka Gharbaoui <Molka.Gharbaoui at santannapisa.it>
Oggetto: Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi

On 3/3/22 12:31, Molka Gharbaoui wrote:
> Hi Matthias,
>
> Sorry for the confusion. Gnocchi is running and I am able to execute
> commands like "gnocchi metric list" and "gnocchi resource list" without
> errors even though the response is empty. Also checking mysql, the
> gnocchi database is correctly created.
>
> By the link I previously shared I wanted just to highlight that there
> are some differences between what was written there and between the
> environemnt I installed. I was searching there because I would have
> expected that Devstack installs and configures every component in
> automatic with no or minimum external intervention (in fact if I don't
> consider the Telemetry aspect, the rest works perfectly fine).
>
> I will follow Rafael guidelines to better undrstand where is the issue.
>
> Thanks.


Something I have used in the past is a local.conf like this:

[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD

IMAGE_URL_SITE="https://download.fedoraproject.org"
IMAGE_URL_PATH="/pub/fedora/linux/releases/33/Cloud/x86_64/images/"
IMAGE_URL_FILE="Fedora-Cloud-Base-33-1.2.x86_64.qcow2"
IMAGE_URLS+=","$IMAGE_URL_SITE$IMAGE_URL_PATH$IMAGE_URL_FILE

CEILOMETER_BACKEND=gnocchi
USE_PYTHON3="True"

VERBOSE="True"

VERBOSE_NO_TIMESTAMP="True"

#
LIBS_FROM_GIT=aodh,ceilometer,cinder,devstack,devstack-gate,dib-utils,diskimage-builder,glance,heat,keystone,neutron,nova,placement,requirements,swift

enable_plugin aodh https://opendev.org/openstack/aodh
enable_plugin ceilometer https://opendev.org/openstack/ceilometer
enable_plugin heat https://opendev.org/openstack/heat


INSTALL_TEMPEST=False


Hope that helps. The IMAGE_URL_FILE needs probably adjustment, fedora 33
is not supported anymore.

Matthias



>
>
> ------------------------------------------------------------------------
> *Da:* Matthias Runge <mrunge at matthias-runge.de>
> *Inviato:* gioved? 3 marzo 2022 11:59
> *A:* openstack-discuss at lists.openstack.org
> <openstack-discuss at lists.openstack.org>
> *Oggetto:* Re: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> metrics using ceilometer and gnocchi
> On 3/3/22 10:29, Molka Gharbaoui wrote:
>> Thank you Matthias for your reply.
>>
>> Unfortunately, from the logs I still cannot understand what is the issue.
>>
>> Could someone kindly indicate me how ceilometer and gnocchi should be
>> configured to get the data?
>>
>> For example in this link:
>> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html
> <https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html>
>
>> <https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html
> <https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html>> the
>
>> endpoints should use the following URL: http://controller:8041 <http://controller:8041>
>> <http://controller:8041 <http://controller:8041>> while in my case the
> 8041 port is not even
>> listening and the API indicated in the dashboard for Gnocchi is http://
>> <http://controller:8041 <http://controller:8041>>x.x.x.x/metric.
>>
>> Thank you in advance.
>>
>
> OpenStack configuration is complex. The guide does not remotely touch on
> production environments. Please do not confuse devstack with production
> envionments. Also the doc you linked is not for devstack itself.
>
> The flow in general is: data is generated by the services like nova or
> glance. Ceilometer listens on the bus and also polls for information.
> The info is sent then over (as configured in publishers.yaml) to gnocchi.
> Gnocchi has an api, ceilometer has not. Reading your response, this
> makes me suspicious if there is gnocchi running. From the initial
> question it suggests it is, from your most recent response, it is not.
>
>
> Matthias
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/4e9c09ca/attachment-0001.htm>

From rafaelweingartner at gmail.com  Fri Mar  4 16:28:50 2022
From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=)
Date: Fri, 4 Mar 2022 13:28:50 -0300
Subject: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
 metrics using ceilometer and gnocchi
In-Reply-To: <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
 <VE1PR03MB55500139D4A8F6C4447C167FEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
 <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
Message-ID: <CAG97radzOiX6vL64L-ug2+a7Y5B5x84soMJ=Dg=dBN7ON5wNrQ@mail.gmail.com>

What do you or what would you expect to see in Gnocchi being pushed by
Ceilometer?
What are the resources (volumes, VMs, and so) that you created in the
OpenStack environment in DevStack?


On Fri, Mar 4, 2022 at 1:26 PM Molka Gharbaoui <
Molka.Gharbaoui at santannapisa.it> wrote:

> Unfortunately, the local.conf file shared by Matthias gives the same
> result: no metrics are pushed to gnocchi.
>
> Gnocchi database is empty: I can create metrics and resources manually but
> nothing is pushed from ceilometer to the database. So I guess the problem
> is at the ceilometer level.
>
> Here is an extract of the ceilometer-polling logs:
>
> 2022-03-04 16:13:07.904 679128 INFO ceilometer.polling.manager [-] Polling
> pollster disk.device.usage in the context of all_pollsters
> 2022-03-04 16:13:07.904 679128 DEBUG ceilometer.compute.pollsters [-]
> afcf32c4-e7c2-40fd-8f75-fdf0bfdb5ef9/disk.device.usage volume: 5368709120
> _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/_
> _init__.py:108
> 2022-03-04 16:13:07.907 679128 INFO ceilometer.polling.manager [-] Polling
> pollster disk.device.read.requests in the context of all_pollsters
> 2022-03-04 16:13:07.908 679128 DEBUG ceilometer.compute.pollsters [-]
> afcf32c4-e7c2-40fd-8f75-fdf0bfdb5ef9/disk.device.read.requests volume:
> 6138 _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/_
> _init__.py:108
> 2022-03-04 16:13:08.038 679128 WARNING ceilometer.neutron_client [-] The
> resource could not be found.: neutronclient.common.exceptions.NotFound:
> The resource could not be found.
> 2022-03-04 16:13:08.038 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster network.services.lb.pool, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
> 2022-03-04 16:13:08.162 679128 WARNING ceilometer.neutron_client [-] The
> resource could not be found.: neutronclient.common.exceptions.NotFound:
> The resource could not be found.
> 2022-03-04 16:13:08.162 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster network.services.lb.vip, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
> 2022-03-04 16:13:08.163 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster network.services.lb.outgoing.bytes, no  resources found this
> cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:
> 177
> 2022-03-04 16:13:08.164 679128 ERROR ceilometer.polling.manager [-]
> Skipping tenant, keystone issue: admin endpoint for identity service in
> RegionOne region not found: keystoneauth1.exceptions.catalog.EndpointNotFound:
> admin endpoint for identity service in RegionOne region not found
> 2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster radosgw.containers.objects.size, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
> 2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster port.receive.packets, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
> 2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster hardware.network.ip.outgoing.datagrams, no  resources found this
> cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:
> 177
> 2022-03-04 16:13:08.355 679128 WARNING ceilometer.neutron_client [-] The
> resource could not be found.: neutronclient.common.exceptions.NotFound:
> The resource could not be found.
> 2022-03-04 16:13:08.355 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster network.services.lb.listener, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
>
> And here I report the content of the ceilometer.conf file:
> [DEFAULT]
>
> debug = True
> transport_url = rabbit://stackrabbit:admin at 10.30.2.194:5672/
>
> [oslo_messaging_notifications]
> topics = notifications
>
> [coordination]
> backend_url = redis://localhost:6379
>
> [notification]
> workers = 2
>
> [cache]
> backend_argument = url:redis://localhost:6379
> backend_argument = distributed_lock:True
> backend_argument = db:0
> backend_argument = redis_expiration_time:600
> backend = dogpile.cache.redis
> enabled = True
>
> [service_credentials]
> auth_url = http://10.30.2.194/identity <http://10.30.2.194/identity/v3/>
> region_name = RegionOne
> password = admin
> username = ceilometer
> project_name = service
> project_domain_name = default
> user_domain_id = default
> auth_type = password
>
> [keystone_authtoken]
> memcached_servers = localhost:11211
> cafile = /opt/stack/data/ca-bundle.pem
> project_domain_name = default
> project_name = admin
> user_domain_name = default
> password = admin
> username = ceilometer
> auth_url = http://10.30.2.194/identity <http://10.30.2.194/identity/v3/>
> interface = public
> auth_type = password
>
> I believe nothing should be changed in the configuration files since
> Devstack should configure every components automatically. I also checked
> pipeline.yaml and polling.yaml files and they seem correct.
>
> Do you have any idea on how to make ceilometer push metrics to the gnocchi
> database??
>
> Thanks.
>
>
> ------------------------------
> *Da:* Matthias Runge <mrunge at matthias-runge.de>
> *Inviato:* gioved? 3 marzo 2022 13:58
> *A:* Molka Gharbaoui <Molka.Gharbaoui at santannapisa.it>
> *Oggetto:* Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> metrics using ceilometer and gnocchi
>
> On 3/3/22 12:31, Molka Gharbaoui wrote:
> > Hi Matthias,
> >
> > Sorry for the confusion. Gnocchi is running and I am able to execute
> > commands like "gnocchi metric list" and "gnocchi resource list" without
> > errors even though the response is empty. Also checking mysql, the
> > gnocchi database is correctly created.
> >
> > By the link I previously shared I wanted just to highlight that there
> > are some differences between what was written there and between the
> > environemnt I installed. I was searching there because I would have
> > expected that Devstack installs and configures every component in
> > automatic with no or minimum external intervention (in fact if I don't
> > consider the Telemetry aspect, the rest works perfectly fine).
> >
> > I will follow Rafael guidelines to better undrstand where is the issue.
> >
> > Thanks.
>
>
> Something I have used in the past is a local.conf like this:
>
> [[local|localrc]]
> ADMIN_PASSWORD=secret
> DATABASE_PASSWORD=$ADMIN_PASSWORD
> RABBIT_PASSWORD=$ADMIN_PASSWORD
> SERVICE_PASSWORD=$ADMIN_PASSWORD
>
> IMAGE_URL_SITE="https://download.fedoraproject.org"
> IMAGE_URL_PATH="/pub/fedora/linux/releases/33/Cloud/x86_64/images/"
> IMAGE_URL_FILE="Fedora-Cloud-Base-33-1.2.x86_64.qcow2"
> IMAGE_URLS+=","$IMAGE_URL_SITE$IMAGE_URL_PATH$IMAGE_URL_FILE
>
> CEILOMETER_BACKEND=gnocchi
> USE_PYTHON3="True"
>
> VERBOSE="True"
>
> VERBOSE_NO_TIMESTAMP="True"
>
> #
>
> LIBS_FROM_GIT=aodh,ceilometer,cinder,devstack,devstack-gate,dib-utils,diskimage-builder,glance,heat,keystone,neutron,nova,placement,requirements,swift
>
> enable_plugin aodh https://opendev.org/openstack/aodh
> enable_plugin ceilometer https://opendev.org/openstack/ceilometer
> enable_plugin heat https://opendev.org/openstack/heat
>
>
> INSTALL_TEMPEST=False
>
>
> Hope that helps. The IMAGE_URL_FILE needs probably adjustment, fedora 33
> is not supported anymore.
>
> Matthias
>
>
>
> >
> >
> > ------------------------------------------------------------------------
> > *Da:* Matthias Runge <mrunge at matthias-runge.de>
> > *Inviato:* gioved? 3 marzo 2022 11:59
> > *A:* openstack-discuss at lists.openstack.org
> > <openstack-discuss at lists.openstack.org>
> > *Oggetto:* Re: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> > metrics using ceilometer and gnocchi
> > On 3/3/22 10:29, Molka Gharbaoui wrote:
> >> Thank you Matthias for your reply.
> >>
> >> Unfortunately, from the logs I still cannot understand what is the
> issue.
> >>
> >> Could someone kindly indicate me how ceilometer and gnocchi should be
> >> configured to get the data?
> >>
> >> For example in this link:
> >>
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html
> > <
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html>
>
> >
> >> <
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html
> > <
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html>> the
>
> >
> >> endpoints should use the following URL: http://controller:8041 <
> http://controller:8041>
> >> <http://controller:8041 <http://controller:8041>> while in my case the
> > 8041 port is not even
> >> listening and the API indicated in the dashboard for Gnocchi is http://
> >> <http://controller:8041 <http://controller:8041>>x.x.x.x/metric.
> >>
> >> Thank you in advance.
> >>
> >
> > OpenStack configuration is complex. The guide does not remotely touch on
> > production environments. Please do not confuse devstack with production
> > envionments. Also the doc you linked is not for devstack itself.
> >
> > The flow in general is: data is generated by the services like nova or
> > glance. Ceilometer listens on the bus and also polls for information.
> > The info is sent then over (as configured in publishers.yaml) to gnocchi.
> > Gnocchi has an api, ceilometer has not. Reading your response, this
> > makes me suspicious if there is gnocchi running. From the initial
> > question it suggests it is, from your most recent response, it is not.
> >
> >
> > Matthias
> >
>
>

-- 
Rafael Weing?rtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/a9f5f024/attachment-0001.htm>

From pierre at stackhpc.com  Fri Mar  4 16:36:33 2022
From: pierre at stackhpc.com (Pierre Riteau)
Date: Fri, 4 Mar 2022 17:36:33 +0100
Subject: [blazar][release][requirements] blazar-nova and nova requirements
Message-ID: <CA+ny2sxjdBV8_fL4ZGGiwGHUHjDuFsXdFTaL28Ze6JREh1LtRg@mail.gmail.com>

Hello release team,

blazar-nova is a package including a nova scheduler filter, which must be
installed together with nova to be used.

The blazar-nova deliverable for Yoga was tagged with 2.4.0 at the time of
the final release for non-client libraries. A few days ago, stable/yoga
patches were automatically proposed. This is when I discovered that the
lower-constraints job was broken because nova bumped some requirements /
lower-constraints after we released [1] [2]. Because blazar-nova and nova
are installed together, we keep our requirements in sync for testing
purposes.

Now, I believe it is just the lower-constraints testing that is broken,
since nova requirements are still compatible with what blazar-nova
requires: nova just requires more recent versions of some packages. I can
run "pip install blazar-nova git+
https://opendev.org/openstack/nova.git at master#egg=nova" fine.

I fixed the issue on the blazar-nova master branch [3] and proposed a
backport to stable/yoga [4], but realised this was probably breaking
release policy.
Should we leave stable/yoga as released and just drop the lower-constraints
job?

As an aside, would it be possible to requalify blazar-nova as a
cycle-with-rc deliverable for the next release? It is typed as a library
but nothing depends on it: if anything, it depends on nova itself.

Thanks,
Pierre Riteau (priteau)

[1] https://review.opendev.org/c/openstack/nova/+/712139
[2] https://review.opendev.org/c/openstack/nova/+/821606
[3] https://review.opendev.org/c/openstack/blazar-nova/+/831741
[4] https://review.opendev.org/c/openstack/blazar-nova/+/831832
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/7d779f44/attachment.htm>

From mthode at mthode.org  Fri Mar  4 16:37:29 2022
From: mthode at mthode.org (Matthew Thode)
Date: Fri, 4 Mar 2022 10:37:29 -0600
Subject: [requirements][release][rfe] sushy 4.1.1 for Yoga
In-Reply-To: <CAJqPaj-YOPLYDbarpgo-BA-SVHAMOQWp4Qc9JvByU3kg3QRG0Q@mail.gmail.com>
References: <CAJqPaj9vtMLGMEoyh34VAG8HxsQjmdiNdDtoLqG8QxPBkryHBg@mail.gmail.com>
 <20220304152607.tkkvd7qhyl6o5ppu@domaintools.com>
 <CAJqPaj-YOPLYDbarpgo-BA-SVHAMOQWp4Qc9JvByU3kg3QRG0Q@mail.gmail.com>
Message-ID: <20220304163729.piv3pggsfc5ppvb7@mthode.org>

On 22-03-04 13:11:51, Iury Gregory wrote:
> Hi Matthew
> 
> You can find the diff in [1], thanks!
> 
> [1]
> https://zuul.opendev.org/t/openstack/build/4894a7e4d02e4892adab5ca4cefc8e89/log/tox/list-changes-results.log#280-408
> 
> 
> Em sex., 4 de mar. de 2022 ?s 12:26, Matthew Thode <mthode at domaintools.com>
> escreveu:
> 
> > On 22-03-04 12:05:40, Iury Gregory wrote:
> > > Hello Stackers,
> > >
> > > I would like to request a new release for sushy before creating the yoga
> > > branch, It contains some important fixes (e.g it will fix a problem when
> > > build sushy in Debian). The sushy lib is only used by ironic, so it
> > > shouldn't cause any problems updating the version in requirements.
> > >
> > > Thanks!
> > >
> > > --
> > >
> > >
> > > *Att[]'sIury Gregory Melo Ferreira *
> > > *MSc in Computer Science at UFCG*
> > > *Part of the ironic-core and puppet-manager-core team in OpenStack*
> > > *Software Engineer at Red Hat Czech*
> > > *Social*: https://www.linkedin.com/in/iurygregory
> > > *E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*
> >
> > Hi, can you link to the diff?
> >
> > --
> > Matthew Thode
> >
> 
> 
> -- 
> 
> 
> *Att[]'sIury Gregory Melo Ferreira *
> *MSc in Computer Science at UFCG*
> *Part of the ironic-core and puppet-manager-core team in OpenStack*
> *Software Engineer at Red Hat Czech*
> *Social*: https://www.linkedin.com/in/iurygregory
> *E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*

Looks good, thanks.

-- 
Matthew Thode


From elod.illes at est.tech  Fri Mar  4 16:41:16 2022
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Fri, 4 Mar 2022 17:41:16 +0100
Subject: [release] Release countdown for week R-3, Mar 07 - 11
Message-ID: <e4997b65-cad4-a6e8-e6ed-6d329f36d5c8@est.tech>

Development Focus
-----------------

The Release Candidate (RC) deadline is next Thursday, March 10th, 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/yoga
branch will be cut. This branch will track the Yoga release.

Once stable/yoga has been created, the master branch will be ready to
switch to Zed development. While the master branch will no longer
be feature-frozen, please prioritize any work necessary for completing
Yoga plans.? Release-critical bugfixes will need to be merged in the
master branch first, then backported to the stable/yoga 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/yoga 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 Zed) 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 Yoga
release so far.

Finally, now is a good time to finalize release highlights if you have not
already done so. Release highlights help shape the messaging around the
release and make sure that your work is properly represented.

Upcoming Deadlines & Dates
--------------------------

RC1 deadline: March 10th, 2022 (R-3 week)
Final RC deadline: March 24th, 2022 (R-1 week)
Final Yoga release: March 30th, 2022
Next PTG: April 4 - 8, 2022 (virtual)


El?d Ill?s
irc: elodilles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/d3ff7319/attachment.htm>

From Molka.Gharbaoui at santannapisa.it  Fri Mar  4 16:49:34 2022
From: Molka.Gharbaoui at santannapisa.it (Molka Gharbaoui)
Date: Fri, 4 Mar 2022 16:49:34 +0000
Subject: R: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics
 using ceilometer and gnocchi
In-Reply-To: <CAG97radzOiX6vL64L-ug2+a7Y5B5x84soMJ=Dg=dBN7ON5wNrQ@mail.gmail.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
 <VE1PR03MB55500139D4A8F6C4447C167FEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
 <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97radzOiX6vL64L-ug2+a7Y5B5x84soMJ=Dg=dBN7ON5wNrQ@mail.gmail.com>
Message-ID: <VE1PR03MB555093FE01A603C3289B5BF5EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>

I have a running instance and I would like to retrieve some statistics on it like cpu usage, memory usage, packets received and sent.
________________________________
Da: Rafael Weing?rtner <rafaelweingartner at gmail.com>
Inviato: venerd? 4 marzo 2022 17:28
A: Molka Gharbaoui <molka.gharbaoui at santannapisa.it>
Cc: Openstack Discuss List <openstack-discuss at lists.openstack.org>
Oggetto: Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi

What do you or what would you expect to see in Gnocchi being pushed by Ceilometer?
What are the resources (volumes, VMs, and so) that you created in the OpenStack environment in DevStack?


On Fri, Mar 4, 2022 at 1:26 PM Molka Gharbaoui <Molka.Gharbaoui at santannapisa.it<mailto:Molka.Gharbaoui at santannapisa.it>> wrote:
Unfortunately, the local.conf file shared by Matthias gives the same result: no metrics are pushed to gnocchi.

Gnocchi database is empty: I can create metrics and resources manually but nothing is pushed from ceilometer to the database. So I guess the problem is at the ceilometer level.

Here is an extract of the ceilometer-polling logs:

2022-03-04 16:13:07.904 679128 INFO ceilometer.polling.manager [-] Polling pollster disk.device.usage in the context of all_pollsters
2022-03-04 16:13:07.904 679128 DEBUG ceilometer.compute.pollsters [-] afcf32c4-e7c2-40fd-8f75-fdf0bfdb5ef9/disk.device.usage volume: 5368709120 _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108
2022-03-04 16:13:07.907 679128 INFO ceilometer.polling.manager [-] Polling pollster disk.device.read.requests in the context of all_pollsters
2022-03-04 16:13:07.908 679128 DEBUG ceilometer.compute.pollsters [-] afcf32c4-e7c2-40fd-8f75-fdf0bfdb5ef9/disk.device.read.requests volume: 6138 _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108
2022-03-04 16:13:08.038 679128 WARNING ceilometer.neutron_client [-] The resource could not be found.: neutronclient.common.exceptions.NotFound: The resource could not be found.
2022-03-04 16:13:08.038 679128 DEBUG ceilometer.polling.manager [-] Skip pollster network.services.lb.pool, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.162 679128 WARNING ceilometer.neutron_client [-] The resource could not be found.: neutronclient.common.exceptions.NotFound: The resource could not be found.
2022-03-04 16:13:08.162 679128 DEBUG ceilometer.polling.manager [-] Skip pollster network.services.lb.vip, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.163 679128 DEBUG ceilometer.polling.manager [-] Skip pollster network.services.lb.outgoing.bytes, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.164 679128 ERROR ceilometer.polling.manager [-] Skipping tenant, keystone issue: admin endpoint for identity service in RegionOne region not found: keystoneauth1.exceptions.catalog.EndpointNotFound: admin endpoint for identity service in RegionOne region not found
2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip pollster radosgw.containers.objects.size, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip pollster port.receive.packets, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip pollster hardware.network.ip.outgoing.datagrams, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.355 679128 WARNING ceilometer.neutron_client [-] The resource could not be found.: neutronclient.common.exceptions.NotFound: The resource could not be found.
2022-03-04 16:13:08.355 679128 DEBUG ceilometer.polling.manager [-] Skip pollster network.services.lb.listener, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177

And here I report the content of the ceilometer.conf file:
[DEFAULT]
debug = True
transport_url = rabbit://stackrabbit:admin at 10.30.2.194:5672/<http://stackrabbit:admin at 10.30.2.194:5672/>

[oslo_messaging_notifications]
topics = notifications

[coordination]
backend_url = redis://localhost:6379

[notification]
workers = 2

[cache]
backend_argument = url:redis://localhost:6379
backend_argument = distributed_lock:True
backend_argument = db:0
backend_argument = redis_expiration_time:600
backend = dogpile.cache.redis
enabled = True

[service_credentials]
auth_url = http://10.30.2.194/identity<http://10.30.2.194/identity/v3/>
region_name = RegionOne
password = admin
username = ceilometer
project_name = service
project_domain_name = default
user_domain_id = default
auth_type = password

[keystone_authtoken]
memcached_servers = localhost:11211
cafile = /opt/stack/data/ca-bundle.pem
project_domain_name = default
project_name = admin
user_domain_name = default
password = admin
username = ceilometer
auth_url = http://10.30.2.194/identity<http://10.30.2.194/identity/v3/>
interface = public
auth_type = password

I believe nothing should be changed in the configuration files since Devstack should configure every components automatically. I also checked pipeline.yaml and polling.yaml files and they seem correct.

Do you have any idea on how to make ceilometer push metrics to the gnocchi database??

Thanks.


________________________________
Da: Matthias Runge <mrunge at matthias-runge.de<mailto:mrunge at matthias-runge.de>>
Inviato: gioved? 3 marzo 2022 13:58
A: Molka Gharbaoui <Molka.Gharbaoui at santannapisa.it<mailto:Molka.Gharbaoui at santannapisa.it>>
Oggetto: Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi

On 3/3/22 12:31, Molka Gharbaoui wrote:
> Hi Matthias,
>
> Sorry for the confusion. Gnocchi is running and I am able to execute
> commands like "gnocchi metric list" and "gnocchi resource list" without
> errors even though the response is empty. Also checking mysql, the
> gnocchi database is correctly created.
>
> By the link I previously shared I wanted just to highlight that there
> are some differences between what was written there and between the
> environemnt I installed. I was searching there because I would have
> expected that Devstack installs and configures every component in
> automatic with no or minimum external intervention (in fact if I don't
> consider the Telemetry aspect, the rest works perfectly fine).
>
> I will follow Rafael guidelines to better undrstand where is the issue.
>
> Thanks.


Something I have used in the past is a local.conf like this:

[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD

IMAGE_URL_SITE="https://download.fedoraproject.org"
IMAGE_URL_PATH="/pub/fedora/linux/releases/33/Cloud/x86_64/images/"
IMAGE_URL_FILE="Fedora-Cloud-Base-33-1.2.x86_64.qcow2"
IMAGE_URLS+=","$IMAGE_URL_SITE$IMAGE_URL_PATH$IMAGE_URL_FILE

CEILOMETER_BACKEND=gnocchi
USE_PYTHON3="True"

VERBOSE="True"

VERBOSE_NO_TIMESTAMP="True"

#
LIBS_FROM_GIT=aodh,ceilometer,cinder,devstack,devstack-gate,dib-utils,diskimage-builder,glance,heat,keystone,neutron,nova,placement,requirements,swift

enable_plugin aodh https://opendev.org/openstack/aodh
enable_plugin ceilometer https://opendev.org/openstack/ceilometer
enable_plugin heat https://opendev.org/openstack/heat


INSTALL_TEMPEST=False


Hope that helps. The IMAGE_URL_FILE needs probably adjustment, fedora 33
is not supported anymore.

Matthias



>
>
> ------------------------------------------------------------------------
> *Da:* Matthias Runge <mrunge at matthias-runge.de<mailto:mrunge at matthias-runge.de>>
> *Inviato:* gioved? 3 marzo 2022 11:59
> *A:* openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>
> <openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>>
> *Oggetto:* Re: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> metrics using ceilometer and gnocchi
> On 3/3/22 10:29, Molka Gharbaoui wrote:
>> Thank you Matthias for your reply.
>>
>> Unfortunately, from the logs I still cannot understand what is the issue.
>>
>> Could someone kindly indicate me how ceilometer and gnocchi should be
>> configured to get the data?
>>
>> For example in this link:
>> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html
> <https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html>
>
>> <https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html
> <https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html>> the
>
>> endpoints should use the following URL: http://controller:8041 <http://controller:8041>
>> <http://controller:8041 <http://controller:8041>> while in my case the
> 8041 port is not even
>> listening and the API indicated in the dashboard for Gnocchi is http://
>> <http://controller:8041 <http://controller:8041>>x.x.x.x/metric.
>>
>> Thank you in advance.
>>
>
> OpenStack configuration is complex. The guide does not remotely touch on
> production environments. Please do not confuse devstack with production
> envionments. Also the doc you linked is not for devstack itself.
>
> The flow in general is: data is generated by the services like nova or
> glance. Ceilometer listens on the bus and also polls for information.
> The info is sent then over (as configured in publishers.yaml) to gnocchi.
> Gnocchi has an api, ceilometer has not. Reading your response, this
> makes me suspicious if there is gnocchi running. From the initial
> question it suggests it is, from your most recent response, it is not.
>
>
> Matthias
>



--
Rafael Weing?rtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/5180bf8d/attachment-0001.htm>

From rafaelweingartner at gmail.com  Fri Mar  4 16:56:01 2022
From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=)
Date: Fri, 4 Mar 2022 13:56:01 -0300
Subject: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
 metrics using ceilometer and gnocchi
In-Reply-To: <VE1PR03MB555093FE01A603C3289B5BF5EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
 <VE1PR03MB55500139D4A8F6C4447C167FEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
 <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97radzOiX6vL64L-ug2+a7Y5B5x84soMJ=Dg=dBN7ON5wNrQ@mail.gmail.com>
 <VE1PR03MB555093FE01A603C3289B5BF5EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
Message-ID: <CAG97rafnksd==DBiqnGDY3DtQcTZnGn+_KiyEB4tqLJ2hw-g8A@mail.gmail.com>

I see. Is the Ceilometer compute agent up and running?

On Fri, Mar 4, 2022 at 1:54 PM Molka Gharbaoui <
Molka.Gharbaoui at santannapisa.it> wrote:

> I have a running instance and I would like to retrieve some statistics on
> it like cpu usage, memory usage, packets received and sent.
> ------------------------------
> *Da:* Rafael Weing?rtner <rafaelweingartner at gmail.com>
> *Inviato:* venerd? 4 marzo 2022 17:28
> *A:* Molka Gharbaoui <molka.gharbaoui at santannapisa.it>
> *Cc:* Openstack Discuss List <openstack-discuss at lists.openstack.org>
> *Oggetto:* Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> metrics using ceilometer and gnocchi
>
> What do you or what would you expect to see in Gnocchi being pushed by
> Ceilometer?
> What are the resources (volumes, VMs, and so) that you created in the
> OpenStack environment in DevStack?
>
>
> On Fri, Mar 4, 2022 at 1:26 PM Molka Gharbaoui <
> Molka.Gharbaoui at santannapisa.it> wrote:
>
> Unfortunately, the local.conf file shared by Matthias gives the same
> result: no metrics are pushed to gnocchi.
>
> Gnocchi database is empty: I can create metrics and resources manually but
> nothing is pushed from ceilometer to the database. So I guess the problem
> is at the ceilometer level.
>
> Here is an extract of the ceilometer-polling logs:
>
> 2022-03-04 16:13:07.904 679128 INFO ceilometer.polling.manager [-] Polling
> pollster disk.device.usage in the context of all_pollsters
> 2022-03-04 16:13:07.904 679128 DEBUG ceilometer.compute.pollsters [-]
> afcf32c4-e7c2-40fd-8f75-fdf0bfdb5ef9/disk.device.usage volume: 5368709120
> _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/_
> _init__.py:108
> 2022-03-04 16:13:07.907 679128 INFO ceilometer.polling.manager [-] Polling
> pollster disk.device.read.requests in the context of all_pollsters
> 2022-03-04 16:13:07.908 679128 DEBUG ceilometer.compute.pollsters [-]
> afcf32c4-e7c2-40fd-8f75-fdf0bfdb5ef9/disk.device.read.requests volume:
> 6138 _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/_
> _init__.py:108
> 2022-03-04 16:13:08.038 679128 WARNING ceilometer.neutron_client [-] The
> resource could not be found.: neutronclient.common.exceptions.NotFound:
> The resource could not be found.
> 2022-03-04 16:13:08.038 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster network.services.lb.pool, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
> 2022-03-04 16:13:08.162 679128 WARNING ceilometer.neutron_client [-] The
> resource could not be found.: neutronclient.common.exceptions.NotFound:
> The resource could not be found.
> 2022-03-04 16:13:08.162 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster network.services.lb.vip, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
> 2022-03-04 16:13:08.163 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster network.services.lb.outgoing.bytes, no  resources found this
> cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:
> 177
> 2022-03-04 16:13:08.164 679128 ERROR ceilometer.polling.manager [-]
> Skipping tenant, keystone issue: admin endpoint for identity service in
> RegionOne region not found: keystoneauth1.exceptions.catalog.EndpointNotFound:
> admin endpoint for identity service in RegionOne region not found
> 2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster radosgw.containers.objects.size, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
> 2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster port.receive.packets, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
> 2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster hardware.network.ip.outgoing.datagrams, no  resources found this
> cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:
> 177
> 2022-03-04 16:13:08.355 679128 WARNING ceilometer.neutron_client [-] The
> resource could not be found.: neutronclient.common.exceptions.NotFound:
> The resource could not be found.
> 2022-03-04 16:13:08.355 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster network.services.lb.listener, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
>
> And here I report the content of the ceilometer.conf file:
> [DEFAULT]
>
> debug = True
> transport_url = rabbit://stackrabbit:admin at 10.30.2.194:5672/
>
> [oslo_messaging_notifications]
> topics = notifications
>
> [coordination]
> backend_url = redis://localhost:6379
>
> [notification]
> workers = 2
>
> [cache]
> backend_argument = url:redis://localhost:6379
> backend_argument = distributed_lock:True
> backend_argument = db:0
> backend_argument = redis_expiration_time:600
> backend = dogpile.cache.redis
> enabled = True
>
> [service_credentials]
> auth_url = http://10.30.2.194/identity <http://10.30.2.194/identity/v3/>
> region_name = RegionOne
> password = admin
> username = ceilometer
> project_name = service
> project_domain_name = default
> user_domain_id = default
> auth_type = password
>
> [keystone_authtoken]
> memcached_servers = localhost:11211
> cafile = /opt/stack/data/ca-bundle.pem
> project_domain_name = default
> project_name = admin
> user_domain_name = default
> password = admin
> username = ceilometer
> auth_url = http://10.30.2.194/identity <http://10.30.2.194/identity/v3/>
> interface = public
> auth_type = password
>
> I believe nothing should be changed in the configuration files since
> Devstack should configure every components automatically. I also checked
> pipeline.yaml and polling.yaml files and they seem correct.
>
> Do you have any idea on how to make ceilometer push metrics to the gnocchi
> database??
>
> Thanks.
>
>
> ------------------------------
> *Da:* Matthias Runge <mrunge at matthias-runge.de>
> *Inviato:* gioved? 3 marzo 2022 13:58
> *A:* Molka Gharbaoui <Molka.Gharbaoui at santannapisa.it>
> *Oggetto:* Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> metrics using ceilometer and gnocchi
>
> On 3/3/22 12:31, Molka Gharbaoui wrote:
> > Hi Matthias,
> >
> > Sorry for the confusion. Gnocchi is running and I am able to execute
> > commands like "gnocchi metric list" and "gnocchi resource list" without
> > errors even though the response is empty. Also checking mysql, the
> > gnocchi database is correctly created.
> >
> > By the link I previously shared I wanted just to highlight that there
> > are some differences between what was written there and between the
> > environemnt I installed. I was searching there because I would have
> > expected that Devstack installs and configures every component in
> > automatic with no or minimum external intervention (in fact if I don't
> > consider the Telemetry aspect, the rest works perfectly fine).
> >
> > I will follow Rafael guidelines to better undrstand where is the issue.
> >
> > Thanks.
>
>
> Something I have used in the past is a local.conf like this:
>
> [[local|localrc]]
> ADMIN_PASSWORD=secret
> DATABASE_PASSWORD=$ADMIN_PASSWORD
> RABBIT_PASSWORD=$ADMIN_PASSWORD
> SERVICE_PASSWORD=$ADMIN_PASSWORD
>
> IMAGE_URL_SITE="https://download.fedoraproject.org"
> IMAGE_URL_PATH="/pub/fedora/linux/releases/33/Cloud/x86_64/images/"
> IMAGE_URL_FILE="Fedora-Cloud-Base-33-1.2.x86_64.qcow2"
> IMAGE_URLS+=","$IMAGE_URL_SITE$IMAGE_URL_PATH$IMAGE_URL_FILE
>
> CEILOMETER_BACKEND=gnocchi
> USE_PYTHON3="True"
>
> VERBOSE="True"
>
> VERBOSE_NO_TIMESTAMP="True"
>
> #
>
> LIBS_FROM_GIT=aodh,ceilometer,cinder,devstack,devstack-gate,dib-utils,diskimage-builder,glance,heat,keystone,neutron,nova,placement,requirements,swift
>
> enable_plugin aodh https://opendev.org/openstack/aodh
> enable_plugin ceilometer https://opendev.org/openstack/ceilometer
> enable_plugin heat https://opendev.org/openstack/heat
>
>
> INSTALL_TEMPEST=False
>
>
> Hope that helps. The IMAGE_URL_FILE needs probably adjustment, fedora 33
> is not supported anymore.
>
> Matthias
>
>
>
> >
> >
> > ------------------------------------------------------------------------
> > *Da:* Matthias Runge <mrunge at matthias-runge.de>
> > *Inviato:* gioved? 3 marzo 2022 11:59
> > *A:* openstack-discuss at lists.openstack.org
> > <openstack-discuss at lists.openstack.org>
> > *Oggetto:* Re: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> > metrics using ceilometer and gnocchi
> > On 3/3/22 10:29, Molka Gharbaoui wrote:
> >> Thank you Matthias for your reply.
> >>
> >> Unfortunately, from the logs I still cannot understand what is the
> issue.
> >>
> >> Could someone kindly indicate me how ceilometer and gnocchi should be
> >> configured to get the data?
> >>
> >> For example in this link:
> >>
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html
> > <
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html>
>
> >
> >> <
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html
> > <
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html>> the
>
> >
> >> endpoints should use the following URL: http://controller:8041 <
> http://controller:8041>
> >> <http://controller:8041 <http://controller:8041>> while in my case the
> > 8041 port is not even
> >> listening and the API indicated in the dashboard for Gnocchi is http://
> >> <http://controller:8041 <http://controller:8041>>x.x.x.x/metric.
> >>
> >> Thank you in advance.
> >>
> >
> > OpenStack configuration is complex. The guide does not remotely touch on
> > production environments. Please do not confuse devstack with production
> > envionments. Also the doc you linked is not for devstack itself.
> >
> > The flow in general is: data is generated by the services like nova or
> > glance. Ceilometer listens on the bus and also polls for information.
> > The info is sent then over (as configured in publishers.yaml) to gnocchi.
> > Gnocchi has an api, ceilometer has not. Reading your response, this
> > makes me suspicious if there is gnocchi running. From the initial
> > question it suggests it is, from your most recent response, it is not.
> >
> >
> > Matthias
> >
>
>
>
> --
> Rafael Weing?rtner
>


-- 
Rafael Weing?rtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/c1f65140/attachment-0001.htm>

From Molka.Gharbaoui at santannapisa.it  Fri Mar  4 16:58:46 2022
From: Molka.Gharbaoui at santannapisa.it (Molka Gharbaoui)
Date: Fri, 4 Mar 2022 16:58:46 +0000
Subject: R: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics
 using ceilometer and gnocchi
In-Reply-To: <CAG97rafnksd==DBiqnGDY3DtQcTZnGn+_KiyEB4tqLJ2hw-g8A@mail.gmail.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
 <VE1PR03MB55500139D4A8F6C4447C167FEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
 <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97radzOiX6vL64L-ug2+a7Y5B5x84soMJ=Dg=dBN7ON5wNrQ@mail.gmail.com>
 <VE1PR03MB555093FE01A603C3289B5BF5EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97rafnksd==DBiqnGDY3DtQcTZnGn+_KiyEB4tqLJ2hw-g8A@mail.gmail.com>
Message-ID: <VE1PR03MB5550E8A87742A68E38EBDF9FEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>

Yes, all ceilometer services are up and running: ceilometer-agent, ceilometer-notification. Actually, all devstack services are up and running.
________________________________
Da: Rafael Weing?rtner <rafaelweingartner at gmail.com>
Inviato: venerd? 4 marzo 2022 17:56
A: Molka Gharbaoui <molka.gharbaoui at santannapisa.it>
Cc: Openstack Discuss List <openstack-discuss at lists.openstack.org>
Oggetto: Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi

I see. Is the Ceilometer compute agent up and running?

On Fri, Mar 4, 2022 at 1:54 PM Molka Gharbaoui <Molka.Gharbaoui at santannapisa.it<mailto:Molka.Gharbaoui at santannapisa.it>> wrote:
I have a running instance and I would like to retrieve some statistics on it like cpu usage, memory usage, packets received and sent.
________________________________
Da: Rafael Weing?rtner <rafaelweingartner at gmail.com<mailto:rafaelweingartner at gmail.com>>
Inviato: venerd? 4 marzo 2022 17:28
A: Molka Gharbaoui <molka.gharbaoui at santannapisa.it<mailto:molka.gharbaoui at santannapisa.it>>
Cc: Openstack Discuss List <openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>>
Oggetto: Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi

What do you or what would you expect to see in Gnocchi being pushed by Ceilometer?
What are the resources (volumes, VMs, and so) that you created in the OpenStack environment in DevStack?


On Fri, Mar 4, 2022 at 1:26 PM Molka Gharbaoui <Molka.Gharbaoui at santannapisa.it<mailto:Molka.Gharbaoui at santannapisa.it>> wrote:
Unfortunately, the local.conf file shared by Matthias gives the same result: no metrics are pushed to gnocchi.

Gnocchi database is empty: I can create metrics and resources manually but nothing is pushed from ceilometer to the database. So I guess the problem is at the ceilometer level.

Here is an extract of the ceilometer-polling logs:

2022-03-04 16:13:07.904 679128 INFO ceilometer.polling.manager [-] Polling pollster disk.device.usage in the context of all_pollsters
2022-03-04 16:13:07.904 679128 DEBUG ceilometer.compute.pollsters [-] afcf32c4-e7c2-40fd-8f75-fdf0bfdb5ef9/disk.device.usage volume: 5368709120 _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108
2022-03-04 16:13:07.907 679128 INFO ceilometer.polling.manager [-] Polling pollster disk.device.read.requests in the context of all_pollsters
2022-03-04 16:13:07.908 679128 DEBUG ceilometer.compute.pollsters [-] afcf32c4-e7c2-40fd-8f75-fdf0bfdb5ef9/disk.device.read.requests volume: 6138 _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108
2022-03-04 16:13:08.038 679128 WARNING ceilometer.neutron_client [-] The resource could not be found.: neutronclient.common.exceptions.NotFound: The resource could not be found.
2022-03-04 16:13:08.038 679128 DEBUG ceilometer.polling.manager [-] Skip pollster network.services.lb.pool, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.162 679128 WARNING ceilometer.neutron_client [-] The resource could not be found.: neutronclient.common.exceptions.NotFound: The resource could not be found.
2022-03-04 16:13:08.162 679128 DEBUG ceilometer.polling.manager [-] Skip pollster network.services.lb.vip, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.163 679128 DEBUG ceilometer.polling.manager [-] Skip pollster network.services.lb.outgoing.bytes, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.164 679128 ERROR ceilometer.polling.manager [-] Skipping tenant, keystone issue: admin endpoint for identity service in RegionOne region not found: keystoneauth1.exceptions.catalog.EndpointNotFound: admin endpoint for identity service in RegionOne region not found
2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip pollster radosgw.containers.objects.size, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip pollster port.receive.packets, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip pollster hardware.network.ip.outgoing.datagrams, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.355 679128 WARNING ceilometer.neutron_client [-] The resource could not be found.: neutronclient.common.exceptions.NotFound: The resource could not be found.
2022-03-04 16:13:08.355 679128 DEBUG ceilometer.polling.manager [-] Skip pollster network.services.lb.listener, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177

And here I report the content of the ceilometer.conf file:
[DEFAULT]
debug = True
transport_url = rabbit://stackrabbit:admin at 10.30.2.194:5672/<http://stackrabbit:admin at 10.30.2.194:5672/>

[oslo_messaging_notifications]
topics = notifications

[coordination]
backend_url = redis://localhost:6379

[notification]
workers = 2

[cache]
backend_argument = url:redis://localhost:6379
backend_argument = distributed_lock:True
backend_argument = db:0
backend_argument = redis_expiration_time:600
backend = dogpile.cache.redis
enabled = True

[service_credentials]
auth_url = http://10.30.2.194/identity<http://10.30.2.194/identity/v3/>
region_name = RegionOne
password = admin
username = ceilometer
project_name = service
project_domain_name = default
user_domain_id = default
auth_type = password

[keystone_authtoken]
memcached_servers = localhost:11211
cafile = /opt/stack/data/ca-bundle.pem
project_domain_name = default
project_name = admin
user_domain_name = default
password = admin
username = ceilometer
auth_url = http://10.30.2.194/identity<http://10.30.2.194/identity/v3/>
interface = public
auth_type = password

I believe nothing should be changed in the configuration files since Devstack should configure every components automatically. I also checked pipeline.yaml and polling.yaml files and they seem correct.

Do you have any idea on how to make ceilometer push metrics to the gnocchi database??

Thanks.


________________________________
Da: Matthias Runge <mrunge at matthias-runge.de<mailto:mrunge at matthias-runge.de>>
Inviato: gioved? 3 marzo 2022 13:58
A: Molka Gharbaoui <Molka.Gharbaoui at santannapisa.it<mailto:Molka.Gharbaoui at santannapisa.it>>
Oggetto: Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi

On 3/3/22 12:31, Molka Gharbaoui wrote:
> Hi Matthias,
>
> Sorry for the confusion. Gnocchi is running and I am able to execute
> commands like "gnocchi metric list" and "gnocchi resource list" without
> errors even though the response is empty. Also checking mysql, the
> gnocchi database is correctly created.
>
> By the link I previously shared I wanted just to highlight that there
> are some differences between what was written there and between the
> environemnt I installed. I was searching there because I would have
> expected that Devstack installs and configures every component in
> automatic with no or minimum external intervention (in fact if I don't
> consider the Telemetry aspect, the rest works perfectly fine).
>
> I will follow Rafael guidelines to better undrstand where is the issue.
>
> Thanks.


Something I have used in the past is a local.conf like this:

[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD

IMAGE_URL_SITE="https://download.fedoraproject.org"
IMAGE_URL_PATH="/pub/fedora/linux/releases/33/Cloud/x86_64/images/"
IMAGE_URL_FILE="Fedora-Cloud-Base-33-1.2.x86_64.qcow2"
IMAGE_URLS+=","$IMAGE_URL_SITE$IMAGE_URL_PATH$IMAGE_URL_FILE

CEILOMETER_BACKEND=gnocchi
USE_PYTHON3="True"

VERBOSE="True"

VERBOSE_NO_TIMESTAMP="True"

#
LIBS_FROM_GIT=aodh,ceilometer,cinder,devstack,devstack-gate,dib-utils,diskimage-builder,glance,heat,keystone,neutron,nova,placement,requirements,swift

enable_plugin aodh https://opendev.org/openstack/aodh
enable_plugin ceilometer https://opendev.org/openstack/ceilometer
enable_plugin heat https://opendev.org/openstack/heat


INSTALL_TEMPEST=False


Hope that helps. The IMAGE_URL_FILE needs probably adjustment, fedora 33
is not supported anymore.

Matthias



>
>
> ------------------------------------------------------------------------
> *Da:* Matthias Runge <mrunge at matthias-runge.de<mailto:mrunge at matthias-runge.de>>
> *Inviato:* gioved? 3 marzo 2022 11:59
> *A:* openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>
> <openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>>
> *Oggetto:* Re: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> metrics using ceilometer and gnocchi
> On 3/3/22 10:29, Molka Gharbaoui wrote:
>> Thank you Matthias for your reply.
>>
>> Unfortunately, from the logs I still cannot understand what is the issue.
>>
>> Could someone kindly indicate me how ceilometer and gnocchi should be
>> configured to get the data?
>>
>> For example in this link:
>> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html
> <https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html>
>
>> <https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html
> <https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html>> the
>
>> endpoints should use the following URL: http://controller:8041 <http://controller:8041>
>> <http://controller:8041 <http://controller:8041>> while in my case the
> 8041 port is not even
>> listening and the API indicated in the dashboard for Gnocchi is http://
>> <http://controller:8041 <http://controller:8041>>x.x.x.x/metric.
>>
>> Thank you in advance.
>>
>
> OpenStack configuration is complex. The guide does not remotely touch on
> production environments. Please do not confuse devstack with production
> envionments. Also the doc you linked is not for devstack itself.
>
> The flow in general is: data is generated by the services like nova or
> glance. Ceilometer listens on the bus and also polls for information.
> The info is sent then over (as configured in publishers.yaml) to gnocchi.
> Gnocchi has an api, ceilometer has not. Reading your response, this
> makes me suspicious if there is gnocchi running. From the initial
> question it suggests it is, from your most recent response, it is not.
>
>
> Matthias
>



--
Rafael Weing?rtner


--
Rafael Weing?rtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/b156a6f0/attachment-0001.htm>

From arnaud.morin at gmail.com  Fri Mar  4 17:07:51 2022
From: arnaud.morin at gmail.com (Arnaud Morin)
Date: Fri, 4 Mar 2022 17:07:51 +0000
Subject: [nova][neutron] os-vif params
Message-ID: <YiJHZ5PklI8NXIkf@sync2>

Hey all,

When I take a look at [1], I can see some parameters, such as
network_device_mtu, isolate_vif, etc.

As far as I can tell, nova is using these params when plugging the port
in OVS (if using OVS as ml2 plugin of course).

But I cannot find the config params in the documentation: [2]

Am I missing something?

Cheers,
Arnaud.

[1] https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py
[2] https://docs.openstack.org/nova/latest/configuration/config.html


From franck.vedel at univ-grenoble-alpes.fr  Fri Mar  4 17:08:44 2022
From: franck.vedel at univ-grenoble-alpes.fr (Franck VEDEL)
Date: Fri, 4 Mar 2022 18:08:44 +0100
Subject: [kolla-ansible][wallaby][centos][horizon-dashboard] Changing logo.svg
Message-ID: <60FB6A20-20EA-4CF7-A962-3CF8AA9C88AA@univ-grenoble-alpes.fr>

Hello,
I come back to ask for some help with a new problem on my Openstack platform. For once, it's a small problem.
I take this opportunity to thank those who helped me solve my problem which was the following: the instances were not created regularly on the 3 nova servers. Nova-scheduler was malfunctioning. I fixed the problem by setting build_failure_weight_multiplier=0
Since then, in DEBUG mode, we can clearly see the calculation of the weight and the distribution of the instances. It's beautiful.

My new problem is: I'm using kolla-ansible, centos (stream) and Wallaby.
In the directory /usr/local/lib/python3.6/site-packages/openstack_dashboard/static/dashboard/img/   I modified the 3 files logo.svg, logo-splash.svg, favicon.ico.

I thought doing a "kolla-ansible -i multinode reconfigure horizon" would update the logos and favicon.ico....but no, it does nothing.
How do I change these logos with kolla-ansible? Is it difficult?

thank you in advance


Franck VEDEL


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/2f508543/attachment.htm>

From ralonsoh at redhat.com  Fri Mar  4 17:33:52 2022
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Fri, 4 Mar 2022 18:33:52 +0100
Subject: [nova][neutron] os-vif params
In-Reply-To: <YiJHZ5PklI8NXIkf@sync2>
References: <YiJHZ5PklI8NXIkf@sync2>
Message-ID: <CAECr9X4Fg8iNZkYsxicYHZh2pvWBMrd=+E7+nqVY=EPwv-e6VQ@mail.gmail.com>

Hi Arnaud:

Those parameters should be set in nova.conf, in the "os_vif_XXX" section
[1].

"network_device_mtu" is deprecated. The interface MTU is retrieved from the
network MTU. "ovs_vsctl_timeout" is deprecated too, we don't use vsctl
commands anymore.

Maybe Nova folks can extend my answer.

Regards.

[1]
https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/releasenotes/notes/libvirt-uses-os-vif-plugins-31a0617de0c248b9.yaml


On Fri, Mar 4, 2022 at 6:18 PM Arnaud Morin <arnaud.morin at gmail.com> wrote:

> Hey all,
>
> When I take a look at [1], I can see some parameters, such as
> network_device_mtu, isolate_vif, etc.
>
> As far as I can tell, nova is using these params when plugging the port
> in OVS (if using OVS as ml2 plugin of course).
>
> But I cannot find the config params in the documentation: [2]
>
> Am I missing something?
>
> Cheers,
> Arnaud.
>
> [1] https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py
> [2] https://docs.openstack.org/nova/latest/configuration/config.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/2e5396af/attachment.htm>

From smooney at redhat.com  Fri Mar  4 17:37:05 2022
From: smooney at redhat.com (Sean Mooney)
Date: Fri, 04 Mar 2022 17:37:05 +0000
Subject: [nova][neutron] os-vif params
In-Reply-To: <YiJHZ5PklI8NXIkf@sync2>
References: <YiJHZ5PklI8NXIkf@sync2>
Message-ID: <eb788755d30c1ed8b1d3f5f8380adaba0e5b6658.camel@redhat.com>

On Fri, 2022-03-04 at 17:07 +0000, Arnaud Morin wrote:
> Hey all,
> 
> When I take a look at [1], I can see some parameters, such as
> network_device_mtu, isolate_vif, etc.
> 
> As far as I can tell, nova is using these params when plugging the port
> in OVS (if using OVS as ml2 plugin of course).
> 
> But I cannot find the config params in the documentation: [2]
> 
> Am I missing something?

no we dont currently generate that documenation currntly
https://docs.openstack.org/nova/latest/configuration/config.html should list it but we have not added
the appropriate namespaces to the list of namespaces for nova to generate.

to use these option today you create a [os_vif_ovs] section in your nova.conf
we do that in devstack today 
https://github.com/openstack/devstack/blob/master/lib/os-vif

so if you look at the nova-cpu.conf form one of our jobs you can see it set to false in this case since we are using ovn
https://zuul.openstack.org/build/7ea68106815e492a8de73c28afffaa0a/log/controller/logs/etc/nova/nova-cpu_conf.txt#134-137

network_device_mtu is not used anymore that was for nova network and should be delete in the future.

ovsdb_connection = tcp:[::1]:6640
isolate_vif = False
ovsdb_interface = vsctl

are all valid to configure still.

i think we just need to add os-vif here
https://github.com/openstack/nova/blob/a74bced0eb3232c0c3384e26db1838bbc26c2d82/doc/source/conf.py#L179-L197
although i coudl be wrong.
i know there is something we need to tweek to include options form opther project likel the messaging option in the config ref
the os-vif docs are located here but we do not generate a sperate config ref
https://docs.openstack.org/os-vif/xena/index.html
> 
> Cheers,
> Arnaud.
> 
> [1] https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py
> [2] https://docs.openstack.org/nova/latest/configuration/config.html
> 



From smooney at redhat.com  Fri Mar  4 17:40:48 2022
From: smooney at redhat.com (Sean Mooney)
Date: Fri, 04 Mar 2022 17:40:48 +0000
Subject: [nova][neutron] os-vif params
In-Reply-To: <eb788755d30c1ed8b1d3f5f8380adaba0e5b6658.camel@redhat.com>
References: <YiJHZ5PklI8NXIkf@sync2>
 <eb788755d30c1ed8b1d3f5f8380adaba0e5b6658.camel@redhat.com>
Message-ID: <20490cbeda70bdd8515656934d4fa157589b1278.camel@redhat.com>

On Fri, 2022-03-04 at 17:37 +0000, Sean Mooney wrote:
> On Fri, 2022-03-04 at 17:07 +0000, Arnaud Morin wrote:
> > Hey all,
> > 
> > When I take a look at [1], I can see some parameters, such as
> > network_device_mtu, isolate_vif, etc.
> > 
> > As far as I can tell, nova is using these params when plugging the port
> > in OVS (if using OVS as ml2 plugin of course).
> > 
> > But I cannot find the config params in the documentation: [2]
> > 
> > Am I missing something?
> 
> no we dont currently generate that documenation currntly
> https://docs.openstack.org/nova/latest/configuration/config.html should list it but we have not added
> the appropriate namespaces to the list of namespaces for nova to generate.
> 
> to use these option today you create a [os_vif_ovs] section in your nova.conf
> we do that in devstack today 
> https://github.com/openstack/devstack/blob/master/lib/os-vif
> 
> so if you look at the nova-cpu.conf form one of our jobs you can see it set to false in this case since we are using ovn
> https://zuul.openstack.org/build/7ea68106815e492a8de73c28afffaa0a/log/controller/logs/etc/nova/nova-cpu_conf.txt#134-137
> 
> network_device_mtu is not used anymore that was for nova network and should be delete in the future.
> 
> ovsdb_connection = tcp:[::1]:6640
> isolate_vif = False
> ovsdb_interface = vsctl
> 
> are all valid to configure still.
> 
> i think we just need to add os-vif here
> https://github.com/openstack/nova/blob/a74bced0eb3232c0c3384e26db1838bbc26c2d82/doc/source/conf.py#L179-L197
> although i coudl be wrong.

actully i think we need to list the namespce here
https://github.com/openstack/nova/blob/a74bced0eb3232c0c3384e26db1838bbc26c2d82/etc/nova/nova-config-generator.conf#L17
in the sample nova-config generator config

i dont think its hard to fix that you just need to find the right place and added it but no one has done the work to figure it out
and push a patch.
> i know there is something we need to tweek to include options form opther project likel the messaging option in the config ref
> the os-vif docs are located here but we do not generate a sperate config ref
> https://docs.openstack.org/os-vif/xena/index.html
> > 
> > Cheers,
> > Arnaud.
> > 
> > [1] https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py
> > [2] https://docs.openstack.org/nova/latest/configuration/config.html
> > 
> 



From mthode at domaintools.com  Fri Mar  4 15:26:07 2022
From: mthode at domaintools.com (Matthew Thode)
Date: Fri, 4 Mar 2022 09:26:07 -0600
Subject: [requirements][release][rfe] sushy 4.1.1 for Yoga
In-Reply-To: <CAJqPaj9vtMLGMEoyh34VAG8HxsQjmdiNdDtoLqG8QxPBkryHBg@mail.gmail.com>
References: <CAJqPaj9vtMLGMEoyh34VAG8HxsQjmdiNdDtoLqG8QxPBkryHBg@mail.gmail.com>
Message-ID: <20220304152607.tkkvd7qhyl6o5ppu@domaintools.com>

On 22-03-04 12:05:40, Iury Gregory wrote:
> Hello Stackers,
> 
> I would like to request a new release for sushy before creating the yoga
> branch, It contains some important fixes (e.g it will fix a problem when
> build sushy in Debian). The sushy lib is only used by ironic, so it
> shouldn't cause any problems updating the version in requirements.
> 
> Thanks!
> 
> -- 
> 
> 
> *Att[]'sIury Gregory Melo Ferreira *
> *MSc in Computer Science at UFCG*
> *Part of the ironic-core and puppet-manager-core team in OpenStack*
> *Software Engineer at Red Hat Czech*
> *Social*: https://www.linkedin.com/in/iurygregory
> *E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*

Hi, can you link to the diff?

-- 
Matthew Thode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/d878284b/attachment.sig>

From smooney at redhat.com  Fri Mar  4 17:57:40 2022
From: smooney at redhat.com (Sean Mooney)
Date: Fri, 04 Mar 2022 17:57:40 +0000
Subject: [nova][neutron] os-vif params
In-Reply-To: <CAECr9X4Fg8iNZkYsxicYHZh2pvWBMrd=+E7+nqVY=EPwv-e6VQ@mail.gmail.com>
References: <YiJHZ5PklI8NXIkf@sync2>
 <CAECr9X4Fg8iNZkYsxicYHZh2pvWBMrd=+E7+nqVY=EPwv-e6VQ@mail.gmail.com>
Message-ID: <3457d3040994053d4ecec879ef33c9b09758774b.camel@redhat.com>

On Fri, 2022-03-04 at 18:33 +0100, Rodolfo Alonso Hernandez wrote:
> Hi Arnaud:
> 
> Those parameters should be set in nova.conf, in the "os_vif_XXX" section
> [1].
> 
> "network_device_mtu" is deprecated. The interface MTU is retrieved from the
> network MTU. "ovs_vsctl_timeout" is deprecated too, we don't use vsctl
> commands anymore.
actully we do use vsctl at least in ci but it is deprecated.
we are currently using it in ci to workaround a bug in the ovs python bindings.

after the RC period is clear i might revert that since i think the ovs python bidnign are
fixed but im not sure they are fixed in ubuntu 20.04 so i dont want to regress the ci stablity
currently by reverting to the native bindings.

https://review.opendev.org/c/openstack/devstack/+/796826

ill update https://github.com/openstack/devstack/blob/master/lib/os-vif#L6 to native
once we are sure https://bugs.launchpad.net/os-vif/+bug/1929446 is fixed in the ovs python bindings.


> 
> Maybe Nova folks can extend my answer.
> 
> Regards.
> 
> [1]
> https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/releasenotes/notes/libvirt-uses-os-vif-plugins-31a0617de0c248b9.yaml
> 
> 
> On Fri, Mar 4, 2022 at 6:18 PM Arnaud Morin <arnaud.morin at gmail.com> wrote:
> 
> > Hey all,
> > 
> > When I take a look at [1], I can see some parameters, such as
> > network_device_mtu, isolate_vif, etc.
> > 
> > As far as I can tell, nova is using these params when plugging the port
> > in OVS (if using OVS as ml2 plugin of course).
> > 
> > But I cannot find the config params in the documentation: [2]
> > 
> > Am I missing something?
> > 
> > Cheers,
> > Arnaud.
> > 
> > [1] https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py
> > [2] https://docs.openstack.org/nova/latest/configuration/config.html
> > 
> > 



From gmann at ghanshyammann.com  Fri Mar  4 18:32:50 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Fri, 04 Mar 2022 12:32:50 -0600
Subject: [tc][ptl] TC + Community Leaders interaction in Zed Virtual PTG
In-Reply-To: <17f22bcdbf2.b05d02e2454544.7809265565474276350@ghanshyammann.com>
References: <17f22bcdbf2.b05d02e2454544.7809265565474276350@ghanshyammann.com>
Message-ID: <17f5634b96d.f2d285d0223727.6162405599807850471@ghanshyammann.com>

 ---- On Tue, 22 Feb 2022 12:41:16 -0600 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > Hello Everyone,
 > 
 > We had successful TC+Community leaders interaction sessions in the last PTG, and we will
 > continue the same for Zed cycle PTG 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-ptl-interaction-zed
 > 
 > Also, I have created the doodle 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://doodle.com/poll/dcer6i3wk2b8eim3

Thanks Everyone for adding your availability in poll. I have booked the Monday 14-16 UTC slot for
this session.

- https://ethercalc.openstack.org/7yxdas7suqnd

-gmann

 > 
 > -gmann
 >     
 > 
 > 


From rafaelweingartner at gmail.com  Fri Mar  4 18:48:47 2022
From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=)
Date: Fri, 4 Mar 2022 15:48:47 -0300
Subject: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
 metrics using ceilometer and gnocchi
In-Reply-To: <VE1PR03MB5550E8A87742A68E38EBDF9FEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
 <VE1PR03MB55500139D4A8F6C4447C167FEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
 <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97radzOiX6vL64L-ug2+a7Y5B5x84soMJ=Dg=dBN7ON5wNrQ@mail.gmail.com>
 <VE1PR03MB555093FE01A603C3289B5BF5EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97rafnksd==DBiqnGDY3DtQcTZnGn+_KiyEB4tqLJ2hw-g8A@mail.gmail.com>
 <VE1PR03MB5550E8A87742A68E38EBDF9FEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
Message-ID: <CAG97raeheZcfwfpNyFi83oEBP5iMgUr9UNTY38xFng25rnqLfA@mail.gmail.com>

And, what about ceilometer-compute?

On Fri, Mar 4, 2022 at 2:04 PM Molka Gharbaoui <
Molka.Gharbaoui at santannapisa.it> wrote:

> Yes, all ceilometer services are up and running: ceilometer-agent,
> ceilometer-notification. Actually, all devstack services are up and running.
> ------------------------------
> *Da:* Rafael Weing?rtner <rafaelweingartner at gmail.com>
> *Inviato:* venerd? 4 marzo 2022 17:56
> *A:* Molka Gharbaoui <molka.gharbaoui at santannapisa.it>
> *Cc:* Openstack Discuss List <openstack-discuss at lists.openstack.org>
> *Oggetto:* Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> metrics using ceilometer and gnocchi
>
> I see. Is the Ceilometer compute agent up and running?
>
> On Fri, Mar 4, 2022 at 1:54 PM Molka Gharbaoui <
> Molka.Gharbaoui at santannapisa.it> wrote:
>
> I have a running instance and I would like to retrieve some statistics on
> it like cpu usage, memory usage, packets received and sent.
> ------------------------------
> *Da:* Rafael Weing?rtner <rafaelweingartner at gmail.com>
> *Inviato:* venerd? 4 marzo 2022 17:28
> *A:* Molka Gharbaoui <molka.gharbaoui at santannapisa.it>
> *Cc:* Openstack Discuss List <openstack-discuss at lists.openstack.org>
> *Oggetto:* Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> metrics using ceilometer and gnocchi
>
> What do you or what would you expect to see in Gnocchi being pushed by
> Ceilometer?
> What are the resources (volumes, VMs, and so) that you created in the
> OpenStack environment in DevStack?
>
>
> On Fri, Mar 4, 2022 at 1:26 PM Molka Gharbaoui <
> Molka.Gharbaoui at santannapisa.it> wrote:
>
> Unfortunately, the local.conf file shared by Matthias gives the same
> result: no metrics are pushed to gnocchi.
>
> Gnocchi database is empty: I can create metrics and resources manually but
> nothing is pushed from ceilometer to the database. So I guess the problem
> is at the ceilometer level.
>
> Here is an extract of the ceilometer-polling logs:
>
> 2022-03-04 16:13:07.904 679128 INFO ceilometer.polling.manager [-] Polling
> pollster disk.device.usage in the context of all_pollsters
> 2022-03-04 16:13:07.904 679128 DEBUG ceilometer.compute.pollsters [-]
> afcf32c4-e7c2-40fd-8f75-fdf0bfdb5ef9/disk.device.usage volume: 5368709120
> _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/_
> _init__.py:108
> 2022-03-04 16:13:07.907 679128 INFO ceilometer.polling.manager [-] Polling
> pollster disk.device.read.requests in the context of all_pollsters
> 2022-03-04 16:13:07.908 679128 DEBUG ceilometer.compute.pollsters [-]
> afcf32c4-e7c2-40fd-8f75-fdf0bfdb5ef9/disk.device.read.requests volume:
> 6138 _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/_
> _init__.py:108
> 2022-03-04 16:13:08.038 679128 WARNING ceilometer.neutron_client [-] The
> resource could not be found.: neutronclient.common.exceptions.NotFound:
> The resource could not be found.
> 2022-03-04 16:13:08.038 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster network.services.lb.pool, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
> 2022-03-04 16:13:08.162 679128 WARNING ceilometer.neutron_client [-] The
> resource could not be found.: neutronclient.common.exceptions.NotFound:
> The resource could not be found.
> 2022-03-04 16:13:08.162 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster network.services.lb.vip, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
> 2022-03-04 16:13:08.163 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster network.services.lb.outgoing.bytes, no  resources found this
> cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:
> 177
> 2022-03-04 16:13:08.164 679128 ERROR ceilometer.polling.manager [-]
> Skipping tenant, keystone issue: admin endpoint for identity service in
> RegionOne region not found: keystoneauth1.exceptions.catalog.EndpointNotFound:
> admin endpoint for identity service in RegionOne region not found
> 2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster radosgw.containers.objects.size, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
> 2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster port.receive.packets, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
> 2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster hardware.network.ip.outgoing.datagrams, no  resources found this
> cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:
> 177
> 2022-03-04 16:13:08.355 679128 WARNING ceilometer.neutron_client [-] The
> resource could not be found.: neutronclient.common.exceptions.NotFound:
> The resource could not be found.
> 2022-03-04 16:13:08.355 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster network.services.lb.listener, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
>
> And here I report the content of the ceilometer.conf file:
> [DEFAULT]
>
> debug = True
> transport_url = rabbit://stackrabbit:admin at 10.30.2.194:5672/
>
> [oslo_messaging_notifications]
> topics = notifications
>
> [coordination]
> backend_url = redis://localhost:6379
>
> [notification]
> workers = 2
>
> [cache]
> backend_argument = url:redis://localhost:6379
> backend_argument = distributed_lock:True
> backend_argument = db:0
> backend_argument = redis_expiration_time:600
> backend = dogpile.cache.redis
> enabled = True
>
> [service_credentials]
> auth_url = http://10.30.2.194/identity <http://10.30.2.194/identity/v3/>
> region_name = RegionOne
> password = admin
> username = ceilometer
> project_name = service
> project_domain_name = default
> user_domain_id = default
> auth_type = password
>
> [keystone_authtoken]
> memcached_servers = localhost:11211
> cafile = /opt/stack/data/ca-bundle.pem
> project_domain_name = default
> project_name = admin
> user_domain_name = default
> password = admin
> username = ceilometer
> auth_url = http://10.30.2.194/identity <http://10.30.2.194/identity/v3/>
> interface = public
> auth_type = password
>
> I believe nothing should be changed in the configuration files since
> Devstack should configure every components automatically. I also checked
> pipeline.yaml and polling.yaml files and they seem correct.
>
> Do you have any idea on how to make ceilometer push metrics to the gnocchi
> database??
>
> Thanks.
>
>
> ------------------------------
> *Da:* Matthias Runge <mrunge at matthias-runge.de>
> *Inviato:* gioved? 3 marzo 2022 13:58
> *A:* Molka Gharbaoui <Molka.Gharbaoui at santannapisa.it>
> *Oggetto:* Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> metrics using ceilometer and gnocchi
>
> On 3/3/22 12:31, Molka Gharbaoui wrote:
> > Hi Matthias,
> >
> > Sorry for the confusion. Gnocchi is running and I am able to execute
> > commands like "gnocchi metric list" and "gnocchi resource list" without
> > errors even though the response is empty. Also checking mysql, the
> > gnocchi database is correctly created.
> >
> > By the link I previously shared I wanted just to highlight that there
> > are some differences between what was written there and between the
> > environemnt I installed. I was searching there because I would have
> > expected that Devstack installs and configures every component in
> > automatic with no or minimum external intervention (in fact if I don't
> > consider the Telemetry aspect, the rest works perfectly fine).
> >
> > I will follow Rafael guidelines to better undrstand where is the issue.
> >
> > Thanks.
>
>
> Something I have used in the past is a local.conf like this:
>
> [[local|localrc]]
> ADMIN_PASSWORD=secret
> DATABASE_PASSWORD=$ADMIN_PASSWORD
> RABBIT_PASSWORD=$ADMIN_PASSWORD
> SERVICE_PASSWORD=$ADMIN_PASSWORD
>
> IMAGE_URL_SITE="https://download.fedoraproject.org"
> IMAGE_URL_PATH="/pub/fedora/linux/releases/33/Cloud/x86_64/images/"
> IMAGE_URL_FILE="Fedora-Cloud-Base-33-1.2.x86_64.qcow2"
> IMAGE_URLS+=","$IMAGE_URL_SITE$IMAGE_URL_PATH$IMAGE_URL_FILE
>
> CEILOMETER_BACKEND=gnocchi
> USE_PYTHON3="True"
>
> VERBOSE="True"
>
> VERBOSE_NO_TIMESTAMP="True"
>
> #
>
> LIBS_FROM_GIT=aodh,ceilometer,cinder,devstack,devstack-gate,dib-utils,diskimage-builder,glance,heat,keystone,neutron,nova,placement,requirements,swift
>
> enable_plugin aodh https://opendev.org/openstack/aodh
> enable_plugin ceilometer https://opendev.org/openstack/ceilometer
> enable_plugin heat https://opendev.org/openstack/heat
>
>
> INSTALL_TEMPEST=False
>
>
> Hope that helps. The IMAGE_URL_FILE needs probably adjustment, fedora 33
> is not supported anymore.
>
> Matthias
>
>
>
> >
> >
> > ------------------------------------------------------------------------
> > *Da:* Matthias Runge <mrunge at matthias-runge.de>
> > *Inviato:* gioved? 3 marzo 2022 11:59
> > *A:* openstack-discuss at lists.openstack.org
> > <openstack-discuss at lists.openstack.org>
> > *Oggetto:* Re: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> > metrics using ceilometer and gnocchi
> > On 3/3/22 10:29, Molka Gharbaoui wrote:
> >> Thank you Matthias for your reply.
> >>
> >> Unfortunately, from the logs I still cannot understand what is the
> issue.
> >>
> >> Could someone kindly indicate me how ceilometer and gnocchi should be
> >> configured to get the data?
> >>
> >> For example in this link:
> >>
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html
> > <
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html>
>
> >
> >> <
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html
> > <
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html>> the
>
> >
> >> endpoints should use the following URL: http://controller:8041 <
> http://controller:8041>
> >> <http://controller:8041 <http://controller:8041>> while in my case the
> > 8041 port is not even
> >> listening and the API indicated in the dashboard for Gnocchi is http://
> >> <http://controller:8041 <http://controller:8041>>x.x.x.x/metric.
> >>
> >> Thank you in advance.
> >>
> >
> > OpenStack configuration is complex. The guide does not remotely touch on
> > production environments. Please do not confuse devstack with production
> > envionments. Also the doc you linked is not for devstack itself.
> >
> > The flow in general is: data is generated by the services like nova or
> > glance. Ceilometer listens on the bus and also polls for information.
> > The info is sent then over (as configured in publishers.yaml) to gnocchi.
> > Gnocchi has an api, ceilometer has not. Reading your response, this
> > makes me suspicious if there is gnocchi running. From the initial
> > question it suggests it is, from your most recent response, it is not.
> >
> >
> > Matthias
> >
>
>
>
> --
> Rafael Weing?rtner
>
>
>
> --
> Rafael Weing?rtner
>


-- 
Rafael Weing?rtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/b5c0bd0d/attachment-0001.htm>

From arnaud.morin at gmail.com  Fri Mar  4 18:57:02 2022
From: arnaud.morin at gmail.com (Arnaud)
Date: Fri, 04 Mar 2022 19:57:02 +0100
Subject: [nova][neutron] os-vif params
In-Reply-To: <3457d3040994053d4ecec879ef33c9b09758774b.camel@redhat.com>
References: <YiJHZ5PklI8NXIkf@sync2>
 <CAECr9X4Fg8iNZkYsxicYHZh2pvWBMrd=+E7+nqVY=EPwv-e6VQ@mail.gmail.com>
 <3457d3040994053d4ecec879ef33c9b09758774b.camel@redhat.com>
Message-ID: <45AC4BA4-DA72-42A1-8E7B-4DAD3870CF0B@gmail.com>

Hi Sean, Rodolfo,

Thanks for your answers.
I will try to do the patch next week so these parameters are included in the nova config sample and documentation.

About the isolated_vif params. It seems like a security enhancement to set it to True when using ovs? Do you confirm that?

Regards,
Arnaud

Le 4 mars 2022 18:57:40 GMT+01:00, Sean Mooney <smooney at redhat.com> a ?crit?:
>On Fri, 2022-03-04 at 18:33 +0100, Rodolfo Alonso Hernandez wrote:
>> Hi Arnaud:
>> 
>> Those parameters should be set in nova.conf, in the "os_vif_XXX" section
>> [1].
>> 
>> "network_device_mtu" is deprecated. The interface MTU is retrieved from the
>> network MTU. "ovs_vsctl_timeout" is deprecated too, we don't use vsctl
>> commands anymore.
>actully we do use vsctl at least in ci but it is deprecated.
>we are currently using it in ci to workaround a bug in the ovs python bindings.
>
>after the RC period is clear i might revert that since i think the ovs python bidnign are
>fixed but im not sure they are fixed in ubuntu 20.04 so i dont want to regress the ci stablity
>currently by reverting to the native bindings.
>
>https://review.opendev.org/c/openstack/devstack/+/796826
>
>ill update https://github.com/openstack/devstack/blob/master/lib/os-vif#L6 to native
>once we are sure https://bugs.launchpad.net/os-vif/+bug/1929446 is fixed in the ovs python bindings.
>
>
>> 
>> Maybe Nova folks can extend my answer.
>> 
>> Regards.
>> 
>> [1]
>> https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/releasenotes/notes/libvirt-uses-os-vif-plugins-31a0617de0c248b9.yaml
>> 
>> 
>> On Fri, Mar 4, 2022 at 6:18 PM Arnaud Morin <arnaud.morin at gmail.com> wrote:
>> 
>> > Hey all,
>> > 
>> > When I take a look at [1], I can see some parameters, such as
>> > network_device_mtu, isolate_vif, etc.
>> > 
>> > As far as I can tell, nova is using these params when plugging the port
>> > in OVS (if using OVS as ml2 plugin of course).
>> > 
>> > But I cannot find the config params in the documentation: [2]
>> > 
>> > Am I missing something?
>> > 
>> > Cheers,
>> > Arnaud.
>> > 
>> > [1] https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py
>> > [2] https://docs.openstack.org/nova/latest/configuration/config.html
>> > 
>> > 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/10054e51/attachment.htm>

From Molka.Gharbaoui at santannapisa.it  Fri Mar  4 18:57:30 2022
From: Molka.Gharbaoui at santannapisa.it (Molka Gharbaoui)
Date: Fri, 4 Mar 2022 18:57:30 +0000
Subject: R: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics
 using ceilometer and gnocchi
In-Reply-To: <CAG97raeheZcfwfpNyFi83oEBP5iMgUr9UNTY38xFng25rnqLfA@mail.gmail.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
 <VE1PR03MB55500139D4A8F6C4447C167FEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
 <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97radzOiX6vL64L-ug2+a7Y5B5x84soMJ=Dg=dBN7ON5wNrQ@mail.gmail.com>
 <VE1PR03MB555093FE01A603C3289B5BF5EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97rafnksd==DBiqnGDY3DtQcTZnGn+_KiyEB4tqLJ2hw-g8A@mail.gmail.com>
 <VE1PR03MB5550E8A87742A68E38EBDF9FEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97raeheZcfwfpNyFi83oEBP5iMgUr9UNTY38xFng25rnqLfA@mail.gmail.com>
Message-ID: <VE1PR03MB5550C23A81F22EB55D95A00EEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>

Yes sorry, I forgot to mention it but it is also running.
________________________________
Da: Rafael Weing?rtner <rafaelweingartner at gmail.com>
Inviato: venerd? 4 marzo 2022 19:48
A: Molka Gharbaoui <molka.gharbaoui at santannapisa.it>
Cc: Openstack Discuss List <openstack-discuss at lists.openstack.org>
Oggetto: Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi

And, what about ceilometer-compute?

On Fri, Mar 4, 2022 at 2:04 PM Molka Gharbaoui <Molka.Gharbaoui at santannapisa.it<mailto:Molka.Gharbaoui at santannapisa.it>> wrote:
Yes, all ceilometer services are up and running: ceilometer-agent, ceilometer-notification. Actually, all devstack services are up and running.
________________________________
Da: Rafael Weing?rtner <rafaelweingartner at gmail.com<mailto:rafaelweingartner at gmail.com>>
Inviato: venerd? 4 marzo 2022 17:56
A: Molka Gharbaoui <molka.gharbaoui at santannapisa.it<mailto:molka.gharbaoui at santannapisa.it>>
Cc: Openstack Discuss List <openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>>
Oggetto: Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi

I see. Is the Ceilometer compute agent up and running?

On Fri, Mar 4, 2022 at 1:54 PM Molka Gharbaoui <Molka.Gharbaoui at santannapisa.it<mailto:Molka.Gharbaoui at santannapisa.it>> wrote:
I have a running instance and I would like to retrieve some statistics on it like cpu usage, memory usage, packets received and sent.
________________________________
Da: Rafael Weing?rtner <rafaelweingartner at gmail.com<mailto:rafaelweingartner at gmail.com>>
Inviato: venerd? 4 marzo 2022 17:28
A: Molka Gharbaoui <molka.gharbaoui at santannapisa.it<mailto:molka.gharbaoui at santannapisa.it>>
Cc: Openstack Discuss List <openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>>
Oggetto: Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi

What do you or what would you expect to see in Gnocchi being pushed by Ceilometer?
What are the resources (volumes, VMs, and so) that you created in the OpenStack environment in DevStack?


On Fri, Mar 4, 2022 at 1:26 PM Molka Gharbaoui <Molka.Gharbaoui at santannapisa.it<mailto:Molka.Gharbaoui at santannapisa.it>> wrote:
Unfortunately, the local.conf file shared by Matthias gives the same result: no metrics are pushed to gnocchi.

Gnocchi database is empty: I can create metrics and resources manually but nothing is pushed from ceilometer to the database. So I guess the problem is at the ceilometer level.

Here is an extract of the ceilometer-polling logs:

2022-03-04 16:13:07.904 679128 INFO ceilometer.polling.manager [-] Polling pollster disk.device.usage in the context of all_pollsters
2022-03-04 16:13:07.904 679128 DEBUG ceilometer.compute.pollsters [-] afcf32c4-e7c2-40fd-8f75-fdf0bfdb5ef9/disk.device.usage volume: 5368709120 _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108
2022-03-04 16:13:07.907 679128 INFO ceilometer.polling.manager [-] Polling pollster disk.device.read.requests in the context of all_pollsters
2022-03-04 16:13:07.908 679128 DEBUG ceilometer.compute.pollsters [-] afcf32c4-e7c2-40fd-8f75-fdf0bfdb5ef9/disk.device.read.requests volume: 6138 _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108
2022-03-04 16:13:08.038 679128 WARNING ceilometer.neutron_client [-] The resource could not be found.: neutronclient.common.exceptions.NotFound: The resource could not be found.
2022-03-04 16:13:08.038 679128 DEBUG ceilometer.polling.manager [-] Skip pollster network.services.lb.pool, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.162 679128 WARNING ceilometer.neutron_client [-] The resource could not be found.: neutronclient.common.exceptions.NotFound: The resource could not be found.
2022-03-04 16:13:08.162 679128 DEBUG ceilometer.polling.manager [-] Skip pollster network.services.lb.vip, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.163 679128 DEBUG ceilometer.polling.manager [-] Skip pollster network.services.lb.outgoing.bytes, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.164 679128 ERROR ceilometer.polling.manager [-] Skipping tenant, keystone issue: admin endpoint for identity service in RegionOne region not found: keystoneauth1.exceptions.catalog.EndpointNotFound: admin endpoint for identity service in RegionOne region not found
2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip pollster radosgw.containers.objects.size, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip pollster port.receive.packets, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip pollster hardware.network.ip.outgoing.datagrams, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
2022-03-04 16:13:08.355 679128 WARNING ceilometer.neutron_client [-] The resource could not be found.: neutronclient.common.exceptions.NotFound: The resource could not be found.
2022-03-04 16:13:08.355 679128 DEBUG ceilometer.polling.manager [-] Skip pollster network.services.lb.listener, no  resources found this cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177

And here I report the content of the ceilometer.conf file:
[DEFAULT]
debug = True
transport_url = rabbit://stackrabbit:admin at 10.30.2.194:5672/<http://stackrabbit:admin at 10.30.2.194:5672/>

[oslo_messaging_notifications]
topics = notifications

[coordination]
backend_url = redis://localhost:6379

[notification]
workers = 2

[cache]
backend_argument = url:redis://localhost:6379
backend_argument = distributed_lock:True
backend_argument = db:0
backend_argument = redis_expiration_time:600
backend = dogpile.cache.redis
enabled = True

[service_credentials]
auth_url = http://10.30.2.194/identity<http://10.30.2.194/identity/v3/>
region_name = RegionOne
password = admin
username = ceilometer
project_name = service
project_domain_name = default
user_domain_id = default
auth_type = password

[keystone_authtoken]
memcached_servers = localhost:11211
cafile = /opt/stack/data/ca-bundle.pem
project_domain_name = default
project_name = admin
user_domain_name = default
password = admin
username = ceilometer
auth_url = http://10.30.2.194/identity<http://10.30.2.194/identity/v3/>
interface = public
auth_type = password

I believe nothing should be changed in the configuration files since Devstack should configure every components automatically. I also checked pipeline.yaml and polling.yaml files and they seem correct.

Do you have any idea on how to make ceilometer push metrics to the gnocchi database??

Thanks.


________________________________
Da: Matthias Runge <mrunge at matthias-runge.de<mailto:mrunge at matthias-runge.de>>
Inviato: gioved? 3 marzo 2022 13:58
A: Molka Gharbaoui <Molka.Gharbaoui at santannapisa.it<mailto:Molka.Gharbaoui at santannapisa.it>>
Oggetto: Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi

On 3/3/22 12:31, Molka Gharbaoui wrote:
> Hi Matthias,
>
> Sorry for the confusion. Gnocchi is running and I am able to execute
> commands like "gnocchi metric list" and "gnocchi resource list" without
> errors even though the response is empty. Also checking mysql, the
> gnocchi database is correctly created.
>
> By the link I previously shared I wanted just to highlight that there
> are some differences between what was written there and between the
> environemnt I installed. I was searching there because I would have
> expected that Devstack installs and configures every component in
> automatic with no or minimum external intervention (in fact if I don't
> consider the Telemetry aspect, the rest works perfectly fine).
>
> I will follow Rafael guidelines to better undrstand where is the issue.
>
> Thanks.


Something I have used in the past is a local.conf like this:

[[local|localrc]]
ADMIN_PASSWORD=secret
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD

IMAGE_URL_SITE="https://download.fedoraproject.org"
IMAGE_URL_PATH="/pub/fedora/linux/releases/33/Cloud/x86_64/images/"
IMAGE_URL_FILE="Fedora-Cloud-Base-33-1.2.x86_64.qcow2"
IMAGE_URLS+=","$IMAGE_URL_SITE$IMAGE_URL_PATH$IMAGE_URL_FILE

CEILOMETER_BACKEND=gnocchi
USE_PYTHON3="True"

VERBOSE="True"

VERBOSE_NO_TIMESTAMP="True"

#
LIBS_FROM_GIT=aodh,ceilometer,cinder,devstack,devstack-gate,dib-utils,diskimage-builder,glance,heat,keystone,neutron,nova,placement,requirements,swift

enable_plugin aodh https://opendev.org/openstack/aodh
enable_plugin ceilometer https://opendev.org/openstack/ceilometer
enable_plugin heat https://opendev.org/openstack/heat


INSTALL_TEMPEST=False


Hope that helps. The IMAGE_URL_FILE needs probably adjustment, fedora 33
is not supported anymore.

Matthias



>
>
> ------------------------------------------------------------------------
> *Da:* Matthias Runge <mrunge at matthias-runge.de<mailto:mrunge at matthias-runge.de>>
> *Inviato:* gioved? 3 marzo 2022 11:59
> *A:* openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>
> <openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>>
> *Oggetto:* Re: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> metrics using ceilometer and gnocchi
> On 3/3/22 10:29, Molka Gharbaoui wrote:
>> Thank you Matthias for your reply.
>>
>> Unfortunately, from the logs I still cannot understand what is the issue.
>>
>> Could someone kindly indicate me how ceilometer and gnocchi should be
>> configured to get the data?
>>
>> For example in this link:
>> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html
> <https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html>
>
>> <https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html
> <https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html>> the
>
>> endpoints should use the following URL: http://controller:8041 <http://controller:8041>
>> <http://controller:8041 <http://controller:8041>> while in my case the
> 8041 port is not even
>> listening and the API indicated in the dashboard for Gnocchi is http://
>> <http://controller:8041 <http://controller:8041>>x.x.x.x/metric.
>>
>> Thank you in advance.
>>
>
> OpenStack configuration is complex. The guide does not remotely touch on
> production environments. Please do not confuse devstack with production
> envionments. Also the doc you linked is not for devstack itself.
>
> The flow in general is: data is generated by the services like nova or
> glance. Ceilometer listens on the bus and also polls for information.
> The info is sent then over (as configured in publishers.yaml) to gnocchi.
> Gnocchi has an api, ceilometer has not. Reading your response, this
> makes me suspicious if there is gnocchi running. From the initial
> question it suggests it is, from your most recent response, it is not.
>
>
> Matthias
>



--
Rafael Weing?rtner


--
Rafael Weing?rtner


--
Rafael Weing?rtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/845aa62a/attachment-0001.htm>

From senrique at redhat.com  Fri Mar  4 19:47:39 2022
From: senrique at redhat.com (Sofia Enriquez)
Date: Fri, 4 Mar 2022 16:47:39 -0300
Subject: Xena and CEPH RBD backend (show_image_direct_url status )
In-Reply-To: <20220228140433.Horde.HqHowF97yyXPEK-I97zzVWP@webmail.nde.ag>
References: <PAYP264MB42561803BD94515768D5F356C43D9@PAYP264MB4256.FRAP264.PROD.OUTLOOK.COM>
 <20220228140433.Horde.HqHowF97yyXPEK-I97zzVWP@webmail.nde.ag>
Message-ID: <CANtmtpFsxExuJsqddSLnHpTYHva0fuxstx=4P3oBNEatcWwQZw@mail.gmail.com>

Greetings,

Have you opened a bug report for this issue? If not, It would be a great
help if you could file a bug: https://bugs.launchpad.net/cinder/.

The cinder team holds a bug meeting every week. In order to reproduce and
discuss this issue further we need a bug report with all the context of a
bug. It's also really good to track fixes. Please at least provide the next
information on it: description, version details, crystal clear details to
reproduce the bug (steps), environment details and actual results like
cinder logs if any. [1]

Thanks,
Sofia

[1] https://wiki.openstack.org/wiki/BugFilingRecommendations


On Mon, Feb 28, 2022 at 11:07 AM Eugen Block <eblock at nde.ag> wrote:

> Hi,
>
> it's disappointing that this is still an issue.
> We're currently using OpenStack Ussuri with Ceph Nautilus (we plan the
> Upgrade to Octopus soon) which works fine without enabling
> show_image_direct_url. The same goes for Victoria and Octopus (one of
> our customers uses this combination).
>
>
> > How is the noted GRAVE Security RISK  of enabling
> > Show_image_direct_url mitigated  ?  (i.e I think , for CEPH RBD, it
> > needs to  be True to get cloning to work efficiently)
>
> I'm also wondering in which case the location contains credentials, I
> haven't seen that yet. Depending on how your cloud is used (is it a
> public or private cloud) maybe enabling the option is not that big of
> a risk?
>
> Regards,
> Eugen
>
>
> Zitat von "west, andrew" <andrew.west-contractor at cgg.com>:
>
> > Hello experts
> >
> > Currently using openstack Xena and Ceph backend (Pacific 16.2.7)
> >
> > It seems there is a bug (since Wallaby?) where the efficient use of
> > a CEPH Pacific RBD backend (i.e with copy-on-write-cloning) is not
> > working .
> > Show_image_direct_url needs to be False to create volumes (or
> > ephemeral volumes for nova)
> >
> > This can of course be tremendously slow (Nova  , ephemeral root
> > disk) without copy-on-write cloning feature of Ceph.
> >
> > As Ceph RBD is THE most favourite  backend for block storage in
> > openstack I am wondering how others are coping (or workarounds found
> > ?)
> > Which combinations of Openstack and Ceph  are known to work well
> > with copy-on-write-cloning?
> >
> > How is the noted GRAVE Security RISK  of enabling
> > Show_image_direct_url mitigated  ?  (i.e I think , for CEPH RBD, it
> > needs to  be True to get cloning to work efficiently)
> >
> >
> > See another report of this issue here:
> > Re: Ceph Pacifif and Openstack Wallaby - ERROR
> > cinder.scheduler.flows.create_volume - CEPH Filesystem Users
> > (spinics.net)<https://www.spinics.net/lists/ceph-users/msg66016.html>
> >
> > Thanks for any help or pointers,
> >
> > Andrew West
> > Openstack consulting
> > CGG France
> >
> >
> > ________________________________
> > "This e-mail and any accompanying attachments are confidential. The
> > information is intended solely for the use of the individual to whom
> > it is addressed. Any review, disclosure, copying, distribution, or
> > use of the email by others is strictly prohibited. If you are not
> > the intended recipient, you must not review, disclose, copy,
> > distribute or use this e-mail; please delete it from your system and
> > notify the sender immediately."
>
>
>
>
>

-- 

Sof?a Enriquez

she/her

Software Engineer

Red Hat PnT <https://www.redhat.com>

IRC: @enriquetaso
@RedHat <https://twitter.com/redhat>   Red Hat
<https://www.linkedin.com/company/red-hat>  Red Hat
<https://www.facebook.com/RedHatInc>
<https://www.redhat.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/1a116601/attachment.htm>

From rafaelweingartner at gmail.com  Fri Mar  4 20:54:28 2022
From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=)
Date: Fri, 4 Mar 2022 17:54:28 -0300
Subject: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
 metrics using ceilometer and gnocchi
In-Reply-To: <VE1PR03MB5550C23A81F22EB55D95A00EEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
 <VE1PR03MB55500139D4A8F6C4447C167FEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
 <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97radzOiX6vL64L-ug2+a7Y5B5x84soMJ=Dg=dBN7ON5wNrQ@mail.gmail.com>
 <VE1PR03MB555093FE01A603C3289B5BF5EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97rafnksd==DBiqnGDY3DtQcTZnGn+_KiyEB4tqLJ2hw-g8A@mail.gmail.com>
 <VE1PR03MB5550E8A87742A68E38EBDF9FEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97raeheZcfwfpNyFi83oEBP5iMgUr9UNTY38xFng25rnqLfA@mail.gmail.com>
 <VE1PR03MB5550C23A81F22EB55D95A00EEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
Message-ID: <CAG97racCjO2CzMw+k7ow-2-UA0f9RDGKaMux1uYN5Kb2Td-VNA@mail.gmail.com>

Did you check Gnocchi log files? Is there some error or something happening
there?

On Fri, Mar 4, 2022 at 4:02 PM Molka Gharbaoui <
Molka.Gharbaoui at santannapisa.it> wrote:

> Yes sorry, I forgot to mention it but it is also running.
> ------------------------------
> *Da:* Rafael Weing?rtner <rafaelweingartner at gmail.com>
> *Inviato:* venerd? 4 marzo 2022 19:48
> *A:* Molka Gharbaoui <molka.gharbaoui at santannapisa.it>
> *Cc:* Openstack Discuss List <openstack-discuss at lists.openstack.org>
> *Oggetto:* Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> metrics using ceilometer and gnocchi
>
> And, what about ceilometer-compute?
>
> On Fri, Mar 4, 2022 at 2:04 PM Molka Gharbaoui <
> Molka.Gharbaoui at santannapisa.it> wrote:
>
> Yes, all ceilometer services are up and running: ceilometer-agent,
> ceilometer-notification. Actually, all devstack services are up and running.
> ------------------------------
> *Da:* Rafael Weing?rtner <rafaelweingartner at gmail.com>
> *Inviato:* venerd? 4 marzo 2022 17:56
> *A:* Molka Gharbaoui <molka.gharbaoui at santannapisa.it>
> *Cc:* Openstack Discuss List <openstack-discuss at lists.openstack.org>
> *Oggetto:* Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> metrics using ceilometer and gnocchi
>
> I see. Is the Ceilometer compute agent up and running?
>
> On Fri, Mar 4, 2022 at 1:54 PM Molka Gharbaoui <
> Molka.Gharbaoui at santannapisa.it> wrote:
>
> I have a running instance and I would like to retrieve some statistics on
> it like cpu usage, memory usage, packets received and sent.
> ------------------------------
> *Da:* Rafael Weing?rtner <rafaelweingartner at gmail.com>
> *Inviato:* venerd? 4 marzo 2022 17:28
> *A:* Molka Gharbaoui <molka.gharbaoui at santannapisa.it>
> *Cc:* Openstack Discuss List <openstack-discuss at lists.openstack.org>
> *Oggetto:* Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> metrics using ceilometer and gnocchi
>
> What do you or what would you expect to see in Gnocchi being pushed by
> Ceilometer?
> What are the resources (volumes, VMs, and so) that you created in the
> OpenStack environment in DevStack?
>
>
> On Fri, Mar 4, 2022 at 1:26 PM Molka Gharbaoui <
> Molka.Gharbaoui at santannapisa.it> wrote:
>
> Unfortunately, the local.conf file shared by Matthias gives the same
> result: no metrics are pushed to gnocchi.
>
> Gnocchi database is empty: I can create metrics and resources manually but
> nothing is pushed from ceilometer to the database. So I guess the problem
> is at the ceilometer level.
>
> Here is an extract of the ceilometer-polling logs:
>
> 2022-03-04 16:13:07.904 679128 INFO ceilometer.polling.manager [-] Polling
> pollster disk.device.usage in the context of all_pollsters
> 2022-03-04 16:13:07.904 679128 DEBUG ceilometer.compute.pollsters [-]
> afcf32c4-e7c2-40fd-8f75-fdf0bfdb5ef9/disk.device.usage volume: 5368709120
> _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/_
> _init__.py:108
> 2022-03-04 16:13:07.907 679128 INFO ceilometer.polling.manager [-] Polling
> pollster disk.device.read.requests in the context of all_pollsters
> 2022-03-04 16:13:07.908 679128 DEBUG ceilometer.compute.pollsters [-]
> afcf32c4-e7c2-40fd-8f75-fdf0bfdb5ef9/disk.device.read.requests volume:
> 6138 _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/_
> _init__.py:108
> 2022-03-04 16:13:08.038 679128 WARNING ceilometer.neutron_client [-] The
> resource could not be found.: neutronclient.common.exceptions.NotFound:
> The resource could not be found.
> 2022-03-04 16:13:08.038 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster network.services.lb.pool, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
> 2022-03-04 16:13:08.162 679128 WARNING ceilometer.neutron_client [-] The
> resource could not be found.: neutronclient.common.exceptions.NotFound:
> The resource could not be found.
> 2022-03-04 16:13:08.162 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster network.services.lb.vip, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
> 2022-03-04 16:13:08.163 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster network.services.lb.outgoing.bytes, no  resources found this
> cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:
> 177
> 2022-03-04 16:13:08.164 679128 ERROR ceilometer.polling.manager [-]
> Skipping tenant, keystone issue: admin endpoint for identity service in
> RegionOne region not found: keystoneauth1.exceptions.catalog.EndpointNotFound:
> admin endpoint for identity service in RegionOne region not found
> 2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster radosgw.containers.objects.size, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
> 2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster port.receive.packets, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
> 2022-03-04 16:13:08.164 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster hardware.network.ip.outgoing.datagrams, no  resources found this
> cycle poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:
> 177
> 2022-03-04 16:13:08.355 679128 WARNING ceilometer.neutron_client [-] The
> resource could not be found.: neutronclient.common.exceptions.NotFound:
> The resource could not be found.
> 2022-03-04 16:13:08.355 679128 DEBUG ceilometer.polling.manager [-] Skip
> pollster network.services.lb.listener, no  resources found this cycle
> poll_and_notify /opt/stack/ceilometer/ceilometer/polling/manager.py:177
>
> And here I report the content of the ceilometer.conf file:
> [DEFAULT]
>
> debug = True
> transport_url = rabbit://stackrabbit:admin at 10.30.2.194:5672/
>
> [oslo_messaging_notifications]
> topics = notifications
>
> [coordination]
> backend_url = redis://localhost:6379
>
> [notification]
> workers = 2
>
> [cache]
> backend_argument = url:redis://localhost:6379
> backend_argument = distributed_lock:True
> backend_argument = db:0
> backend_argument = redis_expiration_time:600
> backend = dogpile.cache.redis
> enabled = True
>
> [service_credentials]
> auth_url = http://10.30.2.194/identity <http://10.30.2.194/identity/v3/>
> region_name = RegionOne
> password = admin
> username = ceilometer
> project_name = service
> project_domain_name = default
> user_domain_id = default
> auth_type = password
>
> [keystone_authtoken]
> memcached_servers = localhost:11211
> cafile = /opt/stack/data/ca-bundle.pem
> project_domain_name = default
> project_name = admin
> user_domain_name = default
> password = admin
> username = ceilometer
> auth_url = http://10.30.2.194/identity <http://10.30.2.194/identity/v3/>
> interface = public
> auth_type = password
>
> I believe nothing should be changed in the configuration files since
> Devstack should configure every components automatically. I also checked
> pipeline.yaml and polling.yaml files and they seem correct.
>
> Do you have any idea on how to make ceilometer push metrics to the gnocchi
> database??
>
> Thanks.
>
>
> ------------------------------
> *Da:* Matthias Runge <mrunge at matthias-runge.de>
> *Inviato:* gioved? 3 marzo 2022 13:58
> *A:* Molka Gharbaoui <Molka.Gharbaoui at santannapisa.it>
> *Oggetto:* Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> metrics using ceilometer and gnocchi
>
> On 3/3/22 12:31, Molka Gharbaoui wrote:
> > Hi Matthias,
> >
> > Sorry for the confusion. Gnocchi is running and I am able to execute
> > commands like "gnocchi metric list" and "gnocchi resource list" without
> > errors even though the response is empty. Also checking mysql, the
> > gnocchi database is correctly created.
> >
> > By the link I previously shared I wanted just to highlight that there
> > are some differences between what was written there and between the
> > environemnt I installed. I was searching there because I would have
> > expected that Devstack installs and configures every component in
> > automatic with no or minimum external intervention (in fact if I don't
> > consider the Telemetry aspect, the rest works perfectly fine).
> >
> > I will follow Rafael guidelines to better undrstand where is the issue.
> >
> > Thanks.
>
>
> Something I have used in the past is a local.conf like this:
>
> [[local|localrc]]
> ADMIN_PASSWORD=secret
> DATABASE_PASSWORD=$ADMIN_PASSWORD
> RABBIT_PASSWORD=$ADMIN_PASSWORD
> SERVICE_PASSWORD=$ADMIN_PASSWORD
>
> IMAGE_URL_SITE="https://download.fedoraproject.org"
> IMAGE_URL_PATH="/pub/fedora/linux/releases/33/Cloud/x86_64/images/"
> IMAGE_URL_FILE="Fedora-Cloud-Base-33-1.2.x86_64.qcow2"
> IMAGE_URLS+=","$IMAGE_URL_SITE$IMAGE_URL_PATH$IMAGE_URL_FILE
>
> CEILOMETER_BACKEND=gnocchi
> USE_PYTHON3="True"
>
> VERBOSE="True"
>
> VERBOSE_NO_TIMESTAMP="True"
>
> #
>
> LIBS_FROM_GIT=aodh,ceilometer,cinder,devstack,devstack-gate,dib-utils,diskimage-builder,glance,heat,keystone,neutron,nova,placement,requirements,swift
>
> enable_plugin aodh https://opendev.org/openstack/aodh
> enable_plugin ceilometer https://opendev.org/openstack/ceilometer
> enable_plugin heat https://opendev.org/openstack/heat
>
>
> INSTALL_TEMPEST=False
>
>
> Hope that helps. The IMAGE_URL_FILE needs probably adjustment, fedora 33
> is not supported anymore.
>
> Matthias
>
>
>
> >
> >
> > ------------------------------------------------------------------------
> > *Da:* Matthias Runge <mrunge at matthias-runge.de>
> > *Inviato:* gioved? 3 marzo 2022 11:59
> > *A:* openstack-discuss at lists.openstack.org
> > <openstack-discuss at lists.openstack.org>
> > *Oggetto:* Re: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> > metrics using ceilometer and gnocchi
> > On 3/3/22 10:29, Molka Gharbaoui wrote:
> >> Thank you Matthias for your reply.
> >>
> >> Unfortunately, from the logs I still cannot understand what is the
> issue.
> >>
> >> Could someone kindly indicate me how ceilometer and gnocchi should be
> >> configured to get the data?
> >>
> >> For example in this link:
> >>
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html
> > <
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html>
>
> >
> >> <
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html
> > <
> https://docs.openstack.org/ceilometer/latest/install/install-base-ubuntu.html>> the
>
> >
> >> endpoints should use the following URL: http://controller:8041 <
> http://controller:8041>
> >> <http://controller:8041 <http://controller:8041>> while in my case the
> > 8041 port is not even
> >> listening and the API indicated in the dashboard for Gnocchi is http://
> >> <http://controller:8041 <http://controller:8041>>x.x.x.x/metric.
> >>
> >> Thank you in advance.
> >>
> >
> > OpenStack configuration is complex. The guide does not remotely touch on
> > production environments. Please do not confuse devstack with production
> > envionments. Also the doc you linked is not for devstack itself.
> >
> > The flow in general is: data is generated by the services like nova or
> > glance. Ceilometer listens on the bus and also polls for information.
> > The info is sent then over (as configured in publishers.yaml) to gnocchi.
> > Gnocchi has an api, ceilometer has not. Reading your response, this
> > makes me suspicious if there is gnocchi running. From the initial
> > question it suggests it is, from your most recent response, it is not.
> >
> >
> > Matthias
> >
>
>
>
> --
> Rafael Weing?rtner
>
>
>
> --
> Rafael Weing?rtner
>
>
>
> --
> Rafael Weing?rtner
>


-- 
Rafael Weing?rtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220304/8a02ba18/attachment-0001.htm>

From Molka.Gharbaoui at santannapisa.it  Sat Mar  5 14:12:53 2022
From: Molka.Gharbaoui at santannapisa.it (Molka Gharbaoui)
Date: Sat, 5 Mar 2022 14:12:53 +0000
Subject: R: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics
 using ceilometer and gnocchi
In-Reply-To: <CAG97racCjO2CzMw+k7ow-2-UA0f9RDGKaMux1uYN5Kb2Td-VNA@mail.gmail.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
 <VE1PR03MB55500139D4A8F6C4447C167FEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
 <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97radzOiX6vL64L-ug2+a7Y5B5x84soMJ=Dg=dBN7ON5wNrQ@mail.gmail.com>
 <VE1PR03MB555093FE01A603C3289B5BF5EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97rafnksd==DBiqnGDY3DtQcTZnGn+_KiyEB4tqLJ2hw-g8A@mail.gmail.com>
 <VE1PR03MB5550E8A87742A68E38EBDF9FEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97raeheZcfwfpNyFi83oEBP5iMgUr9UNTY38xFng25rnqLfA@mail.gmail.com>
 <VE1PR03MB5550C23A81F22EB55D95A00EEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97racCjO2CzMw+k7ow-2-UA0f9RDGKaMux1uYN5Kb2Td-VNA@mail.gmail.com>
Message-ID: <AM6PR03MB5542A9478BA137A27F578382EC069@AM6PR03MB5542.eurprd03.prod.outlook.com>

No errors in the gnocchi log files.

Here is part of the output of the "gnocchi metric list --debug":

http://10.30.2.194:80 "GET /metric/v1/metric HTTP/1.1" 200 2
RESP: [200] Connection: close Content-Length: 2 Content-Type: application/json Date: Sat, 05 Mar 2022 09:33:24 GMT Server: Apache/2.4.41 (Ubuntu)
RESP BODY: []

The response  body is empty since the database is empty. Other output from the log files:

[697660] DEBUG    gnocchi.chef: Processing measures for sack incoming128-123
2022-03-05 10:17:59,042 [697663] DEBUG    gnocchi.chef: Processing measures for sack incoming128-23
[697660] DEBUG    gnocchi.cli.metricd: Full scan of sacks has been done

There is only one error in all the log files and it regards ceilometer logs. I report it here:

2022-03-04 16:13:08.164 679128 ERROR ceilometer.polling.manager [-] Skipping tenant, keystone issue: admin endpoint for identity service in RegionOne region not found: keystoneauth1.exceptions.catalog.EndpointNotFound: admin endpoint for identity service in RegionOne region not found

Thank you for your help!

________________________________
Da: Rafael Weing?rtner <rafaelweingartner at gmail.com>
Inviato: venerd? 4 marzo 2022 21:54
A: Molka Gharbaoui <molka.gharbaoui at santannapisa.it>
Cc: Openstack Discuss List <openstack-discuss at lists.openstack.org>
Oggetto: Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi

Did you check Gnocchi log files? Is there some error or something happening there?

--
Rafael Weing?rtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220305/e513c983/attachment.htm>

From rafaelweingartner at gmail.com  Sat Mar  5 15:00:19 2022
From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=)
Date: Sat, 5 Mar 2022 12:00:19 -0300
Subject: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
 metrics using ceilometer and gnocchi
In-Reply-To: <AM6PR03MB5542A9478BA137A27F578382EC069@AM6PR03MB5542.eurprd03.prod.outlook.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
 <VE1PR03MB55500139D4A8F6C4447C167FEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
 <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97radzOiX6vL64L-ug2+a7Y5B5x84soMJ=Dg=dBN7ON5wNrQ@mail.gmail.com>
 <VE1PR03MB555093FE01A603C3289B5BF5EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97rafnksd==DBiqnGDY3DtQcTZnGn+_KiyEB4tqLJ2hw-g8A@mail.gmail.com>
 <VE1PR03MB5550E8A87742A68E38EBDF9FEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97raeheZcfwfpNyFi83oEBP5iMgUr9UNTY38xFng25rnqLfA@mail.gmail.com>
 <VE1PR03MB5550C23A81F22EB55D95A00EEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97racCjO2CzMw+k7ow-2-UA0f9RDGKaMux1uYN5Kb2Td-VNA@mail.gmail.com>
 <AM6PR03MB5542A9478BA137A27F578382EC069@AM6PR03MB5542.eurprd03.prod.outlook.com>
Message-ID: <CAG97rae0UC1JqT-iT9cgpVKR_8L92_Cfj_Y=eZa3Ghb9Bpp_ig@mail.gmail.com>

The messages: "%d measures posted against %d metrics through %d resources"
appear in the log files of Ceilometer?

On Sat, Mar 5, 2022 at 11:12 AM Molka Gharbaoui <
Molka.Gharbaoui at santannapisa.it> wrote:

> No errors in the gnocchi log files.
>
> Here is part of the output of the "gnocchi metric list --debug":
>
> http://10.30.2.194:80 "GET /metric/v1/metric HTTP/1.1" 200 2
> RESP: [200] Connection: close Content-Length: 2 Content-Type:
> application/json Date: Sat, 05 Mar 2022 09:33:24 GMT Server: Apache/2.4.41
> (Ubuntu)
> RESP BODY: []
>
> The response  body is empty since the database is empty. Other output from
> the log files:
>
> [697660] DEBUG    gnocchi.chef: Processing measures for sack
> incoming128-123
> 2022-03-05 10:17:59,042 [697663] DEBUG    gnocchi.chef: Processing
> measures for sack incoming128-23
> [697660] DEBUG    gnocchi.cli.metricd: Full scan of sacks has been done
>
> There is only one error in all the log files and it regards ceilometer
> logs. I report it here:
>
> 2022-03-04 16:13:08.164 679128 ERROR ceilometer.polling.manager [-]
> Skipping tenant, keystone issue: admin endpoint for identity service in
> RegionOne region not found:
> keystoneauth1.exceptions.catalog.EndpointNotFound: admin endpoint for
> identity service in RegionOne region not found
>
> Thank you for your help!
>
> ------------------------------
> *Da:* Rafael Weing?rtner <rafaelweingartner at gmail.com>
> *Inviato:* venerd? 4 marzo 2022 21:54
> *A:* Molka Gharbaoui <molka.gharbaoui at santannapisa.it>
> *Cc:* Openstack Discuss List <openstack-discuss at lists.openstack.org>
> *Oggetto:* Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> metrics using ceilometer and gnocchi
>
> Did you check Gnocchi log files? Is there some error or something
> happening there?
>
> --
> Rafael Weing?rtner
>


-- 
Rafael Weing?rtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220305/b032c97b/attachment.htm>

From Molka.Gharbaoui at santannapisa.it  Sat Mar  5 15:19:24 2022
From: Molka.Gharbaoui at santannapisa.it (Molka Gharbaoui)
Date: Sat, 5 Mar 2022 15:19:24 +0000
Subject: R: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics
 using ceilometer and gnocchi
In-Reply-To: <CAG97rae0UC1JqT-iT9cgpVKR_8L92_Cfj_Y=eZa3Ghb9Bpp_ig@mail.gmail.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
 <VE1PR03MB55500139D4A8F6C4447C167FEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
 <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97radzOiX6vL64L-ug2+a7Y5B5x84soMJ=Dg=dBN7ON5wNrQ@mail.gmail.com>
 <VE1PR03MB555093FE01A603C3289B5BF5EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97rafnksd==DBiqnGDY3DtQcTZnGn+_KiyEB4tqLJ2hw-g8A@mail.gmail.com>
 <VE1PR03MB5550E8A87742A68E38EBDF9FEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97raeheZcfwfpNyFi83oEBP5iMgUr9UNTY38xFng25rnqLfA@mail.gmail.com>
 <VE1PR03MB5550C23A81F22EB55D95A00EEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97racCjO2CzMw+k7ow-2-UA0f9RDGKaMux1uYN5Kb2Td-VNA@mail.gmail.com>
 <AM6PR03MB5542A9478BA137A27F578382EC069@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <CAG97rae0UC1JqT-iT9cgpVKR_8L92_Cfj_Y=eZa3Ghb9Bpp_ig@mail.gmail.com>
Message-ID: <VE1PR03MB5550C9EFAFA20EE8D9B3B05BEC069@VE1PR03MB5550.eurprd03.prod.outlook.com>

No, the message: "%d measures posted against %d metrics through %d resources" does not appear in ceilometer logs.

I executed: ceilometer-upgrade, ceilometer-polling and ceilometer-agent-notification commands.

________________________________
Da: Rafael Weing?rtner <rafaelweingartner at gmail.com>
Inviato: sabato 5 marzo 2022 16:00
A: Molka Gharbaoui <molka.gharbaoui at santannapisa.it>
Cc: Openstack Discuss List <openstack-discuss at lists.openstack.org>
Oggetto: Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi

The messages: "%d measures posted against %d metrics through %d resources" appear in the log files of Ceilometer?



On Sat, Mar 5, 2022 at 11:12 AM Molka Gharbaoui <Molka.Gharbaoui at santannapisa.it<mailto:Molka.Gharbaoui at santannapisa.it>> wrote:
No errors in the gnocchi log files.

Here is part of the output of the "gnocchi metric list --debug":

http://10.30.2.194:80 "GET /metric/v1/metric HTTP/1.1" 200 2
RESP: [200] Connection: close Content-Length: 2 Content-Type: application/json Date: Sat, 05 Mar 2022 09:33:24 GMT Server: Apache/2.4.41 (Ubuntu)
RESP BODY: []

The response  body is empty since the database is empty. Other output from the log files:

[697660] DEBUG    gnocchi.chef: Processing measures for sack incoming128-123
2022-03-05 10:17:59,042 [697663] DEBUG    gnocchi.chef: Processing measures for sack incoming128-23
[697660] DEBUG    gnocchi.cli.metricd: Full scan of sacks has been done

There is only one error in all the log files and it regards ceilometer logs. I report it here:

2022-03-04 16:13:08.164 679128 ERROR ceilometer.polling.manager [-] Skipping tenant, keystone issue: admin endpoint for identity service in RegionOne region not found: keystoneauth1.exceptions.catalog.EndpointNotFound: admin endpoint for identity service in RegionOne region not found

Thank you for your help!

________________________________
Da: Rafael Weing?rtner <rafaelweingartner at gmail.com<mailto:rafaelweingartner at gmail.com>>
Inviato: venerd? 4 marzo 2022 21:54
A: Molka Gharbaoui <molka.gharbaoui at santannapisa.it<mailto:molka.gharbaoui at santannapisa.it>>
Cc: Openstack Discuss List <openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>>
Oggetto: Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi

Did you check Gnocchi log files? Is there some error or something happening there?

--
Rafael Weing?rtner


--
Rafael Weing?rtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220305/0a67fefb/attachment-0001.htm>

From skaplons at redhat.com  Sat Mar  5 17:20:18 2022
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Sat, 05 Mar 2022 18:20:18 +0100
Subject: [adjutant][tc][all] Call for volunteers to be a PTL and maintainers
Message-ID: <4381995.LvFx2qVVIh@p1>

Hi,

After last PTL elections [1] Adjutant project don't have any PTL. It also didn't had PTL in the Yoga cycle already.
So this is call for maintainters for Adjutant. If You are using it or interested in it, and if You are willing to help maintaining this project, please contact TC members through this mailing list or directly on the #openstack-tc channel @OFTC. We can talk possibilities to make someone a PTL of the project or going with this project to the Distributed Project Leadership [2] model.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027411.html
[2] https://governance.openstack.org/tc/resolutions/20200803-distributed-project-leadership.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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220305/855d1780/attachment.sig>

From skaplons at redhat.com  Sat Mar  5 17:25:42 2022
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Sat, 05 Mar 2022 18:25:42 +0100
Subject: [trove][tc][all] Call for volunteers to be a PTL and maintainers
Message-ID: <2095127.irdbgypaU6@p1>

Hi,

After last PTL elections [1] Trove project still don't have any PTL elected.
So this is call for maintainers for Trove. If You are using it or interested in it, and if You are willing to help maintaining this project, please contact TC members through this mailing list or directly on the #openstack-tc channel @OFTC. We can talk possibilities to make someone a PTL of the project or going with this project to the Distributed Project Leadership [2] model.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027411.html
[2] https://governance.openstack.org/tc/resolutions/20200803-distributed-project-leadership.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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220305/ab27ef95/attachment.sig>

From lokendrarathour at gmail.com  Sun Mar  6 04:20:26 2022
From: lokendrarathour at gmail.com (Lokendra Rathour)
Date: Sun, 6 Mar 2022 09:50:26 +0530
Subject: Fwd: [Triple0] Upgrade Error
In-Reply-To: <CAJm6b-7RgJe7-jayFfihwX0P=1uYjghHQoPdNxo4CC_mNdoNyQ@mail.gmail.com>
References: <CAJm6b-42betLA4CfYW_cTjg_cBuHeeyAxVxG=tzPY_nm08OXWQ@mail.gmail.com>
 <CAJm6b-6cySYDODgFUknQWMgA_KxwCopoeQ+cpPRsqwhtYVec=A@mail.gmail.com>
 <87333433-63c3-6b52-ab36-8de16dff277d@redhat.com>
 <CAJm6b-7RgJe7-jayFfihwX0P=1uYjghHQoPdNxo4CC_mNdoNyQ@mail.gmail.com>
Message-ID: <CAJm6b-7PwVzDEHgrSt_WMjBVuMiiG_xpeoeMvfh7-isRG31n=Q@mail.gmail.com>

Hi Team/Harald,
Any input possible on this please?
Thanks.


On Fri, 4 Mar 2022, 15:10 Lokendra Rathour, <lokendrarathour at gmail.com>
wrote:

> Hi Harald / Team,
> Thanks for the support here.
> It did help in the classification of the issue and we saw that we need to
> re-render the templates for an upgrade to proceed.
> After re-rendering we saw the diff of DNS related in the templates.
>
> Now we have completed the next few steps and are facing issues when
> running the below commands:
>
> openstack overcloud upgrade run --limit Controller --playbook upgrade_steps_playbook.yaml
>
>
> It gives the error as :
>
> *2022-03-04 14:29:56.571690 | 525400cb-2e90-4086-e760-00000000009b |
> TASK | Ensure DNF modules have the right stream*
> *2022-03-04 14:29:57.723661 | 525400cb-2e90-4086-e760-00000000009b |
>  FATAL | Ensure DNF modules have the right stream | overcloud-novacompute-0
> | item={'module': 'container-tools', 'stream': '3.0'} |
> error={"ansible_loop_var": "item", "changed": false, "item": {"module":
> "container-tools", "stream": "3.0"}, "module_stderr": "Traceback (most
> recent call last):\n  File \"<stdin>\", line 102, in <module>\n  File
> \"<stdin>\", line 94, in _ansiballz_main\n  File \"<stdin>\", line 40, in
> invoke_module\n  File \"/usr/lib64/python3.6/runpy.py\", line 205, in
> run_module\n    return _run_module_code(code, init_globals, run_name,
> mod_spec)\n  File \"/usr/lib64/python3.6/runpy.py\", line 96, in
> _run_module_code\n    mod_name, mod_spec, pkg_name, script_name)\n  File
> \"/usr/lib64/python3.6/runpy.py\", line 85, in _run_code\n    exec(code,
> run_globals)\n  File
> \"/tmp/ansible_dnf_payload_3lb54omj/ansible_dnf_payload.zip/ansible/modules/packaging/os/dnf.py\",
> line 1370, in <module>\n  File
> \"/tmp/ansible_dnf_payload_3lb54omj/ansible_dnf_payload.zip/ansible/modules/packaging/os/dnf.py\",
> line 1359, in main\n  File
> \"/tmp/ansible_dnf_payload_3lb54omj/ansible_dnf_payload.zip/ansible/modules/packaging/os/dnf.py\",
> line 1338, in run\n  File
> \"/tmp/ansible_dnf_payload_3lb54omj/ansible_dnf_payload.zip/ansible/modules/packaging/os/dnf.py\",
> line 996, in ensure\n  File
> \"/usr/lib/python3.6/site-packages/dnf/module/module_base.py\", line 144,
> in install\n    \"Installing module from Fail-Safe repository is not
> allowed\"))\ndnf.exceptions.Error: Installing module from Fail-Safe
> repository is not allowed\n", "module_stdout": "", "msg": "MODULE
> FAILURE\nSee stdout/stderr for the exact error", "rc": 1}*
>
> *Few things to note:*
>
>    - *the document followed * Upgrading to a Next Major Release ? TripleO
>    3.0.0 documentation (openstack.org)
>    <https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/post_deployment/upgrade/major_upgrade.html>
>    - The command which was executed to run upgrade prepare:
>       -
>
>
>
>
>
>
>
>
>
>
>
> *openstack overcloud upgrade prepare --templates \     -n
>       /home/stack/templates/network_data.yaml \     -r
>       /home/stack/templates/roles_data.yaml \     -e
>       /home/stack/templates/environment.yaml \     -e
>       /home/stack/templates/environments/network-isolation.yaml \     -e
>       /home/stack/templates/environments/network-environment.yaml \     -e
>       /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
>       \     -e
>       /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
>       \     -e
>       /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
>       \     -e /home/stack/templates/ironic-config.yaml \     -e
>       /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml \
>         -e /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
>           -e /home/stack/containers-prepare-parameter.yaml*
>
> Please advice over the same issue.
>
> Best Regards,
> Lokendra
>
>
> On Sun, Feb 27, 2022 at 6:50 AM Harald Jensas <hjensas at redhat.com> wrote:
>
>> On 2/25/22 12:21, Lokendra Rathour wrote:
>> > Hi Team,
>> >
>> > we are trying to upgrade *Triple0 Train to Ussuri.*
>> > Undercloud upgrade is done successfully.
>> > *_OverCloud Upgrade:_*
>> > As a first step in overcloud upgrade, we are running " *openstack
>> > overcloud upgrade prepare*  "  command.
>> > which is throwing following error:
>> >
>>
>> > overcloud: ERROR: Property error:
>> > resources.InternalApiVirtualIP.properties: Unknown Property DnsName\n
>> >   File \"/usr/lib/python3.6/site-packages/heat/common/wsgi.py\", line
>> > 891, in __call__\n    request, **action_args)\n  File
>> > \"/usr/lib/python3.6/site-packages/heat/common/wsgi.py\", line 964, in
>> > dispatch\n    return method(*args, **kwargs)\n  File
>> > \"/usr/lib/python3.6/site-packages/heat/api/openstack/v1/util.py\",
>> line
>> > 56, in handle_stack_method\n    return handler(controller, req,
>> > **kwargs)\n  File
>> > \"/usr/lib/python3.6/site-packages/heat/api/openstack/v1/stacks.py\",
>> > line 633, in validate_template\n    raise
>> > exc.HTTPBadRequest(result['Error'])\n", "success": false}*
>> >
>>
>> The DnsName property was added to templats in Ussuri, this change:
>> https://review.opendev.org/c/openstack/tripleo-heat-templates/+/715883
>>
>>
>> Somewhere in you environment files you are mapping
>> `OS::TripleO::Network::Ports::InternalApiVipPort` to a local template
>> file instead of using the in-tree template.
>>
>> You either need to add DnsName paramter to your local VipPort template,
>> or change the resource_registry so that you map to the in-tree port
>> template.
>> `/usr/share/openstack-tripleo-heat-template/network/ports/internal_api.yaml`
>>
>> is the in-tree template you want.
>>
>>
>> > *_Command used to run the overcloud upgrade prepare:_*
>> >
>> > *(undercloud) [stack at undercloud ~]$ cat upgrade_overcloud_prepare.sh
>> > openstack overcloud upgrade prepare --templates \
>> >      -r /home/stack/templates/roles_data.yaml \
>> >      -n /home/stack/templates/network_data.yaml \
>> >      -e /home/stack/templates/environment.yaml \
>> >      -e /home/stack/templates/environments/network-isolation.yaml \
>>
>> Most likely the mapping is in this network-isolation.yaml.
>> If you use the in-tree environment
>> `/usr/share/openstack-tripleo-heat-tempaltes/envioronments/network-isolation.yaml`
>>
>> instead you should not run into these type of issues on upgrade.
>>
>> >      -e /home/stack/templates/environments/network-environment.yaml \
>>
>> I would also recommend to use the in-tree network-environment.yaml
>>   -e
>>
>> /usr/share/openstack-tripleo-heat-tempaltes/envioronments/network-environment.yaml
>>
>> Then add another file to override anything in the in-tree
>> network-environment.yaml.
>>   -e /home/stack/templates/environments/network-environment-overrides.yaml
>>
>> >      -e
>> >
>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-conductor.yaml
>>
>> > \
>> >      -e
>> >
>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-inspector.yaml
>>
>> > \
>> >      -e
>> >
>> /usr/share/openstack-tripleo-heat-templates/environments/services/ironic-overcloud.yaml
>>
>> > \
>> >      -e /home/stack/templates/ironic-config.yaml \
>> >      -e
>> > /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml
>> \
>> >      -e
>> > /usr/share/openstack-tripleo-heat-templates/environments/podman.yaml \
>> >      -e /home/stack/templates/init-repo.yaml \
>> >      -e /home/stack/containers-prepare-parameter.yaml
>>
>>
>> --
>> Harald
>>
>>
>
> --
> ~ Lokendra
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220306/0dc6b7d8/attachment-0001.htm>

From radoslaw.piliszek at gmail.com  Sun Mar  6 08:46:48 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Sun, 6 Mar 2022 09:46:48 +0100
Subject: [ironic][tripleo][kayobe][tenks][vbmc] Do you also experience random
 issues with vbmc?
Message-ID: <CAKZ_x791SgysTu=PRqiXLhngA+0W-Yf0P4E8xOOkWV2FG-v_wA@mail.gmail.com>

Dear fellow upstream OpenStackers,

I tagged the main projects that use vbmc intensively because I have a
question regarding the stability of vbmc.
I have been working on adding baremetal testing in Kolla Ansible using
Tenks and thus also VirtualBMC.
I am encountering random failures that I am at the moment unable to debug.
It seems vbmc likes to reject the "chassis bootdev pxe" ipmitool
command from time to time (the command is issued when trying to deploy
a host).
This seems permanent per case as ironic retries this call several
times only to fail.
The error message is "Error setting Chassis Boot Parameter 5".
I can't see any trace in vbmc logs (with DEBUG enabled).
Other ipmitool commands seem to work fine (like periodic power status).
I was wondering if any of you also experienced this issue.
I am providing a link to an excerpt from the logs. [1]
It also shows a raw ipmitool command succeeding only to let the next one fail.

[1] https://paste.ubuntu.com/p/MgHHpDvVGf/

-yoctozepto


From marc-antoine.godde at viarezo.fr  Mon Mar  7 01:36:24 2022
From: marc-antoine.godde at viarezo.fr (Marc-Antoine Godde)
Date: Mon, 7 Mar 2022 02:36:24 +0100
Subject: IPv6 deployment on OpenStack
Message-ID: <B30F2915-674E-4029-9F1A-D25589FFF056@viarezo.fr>

Hello.

We are progressively adding support for IPv6 in my company. We decided to use SLAAC only for laptops, phones, ? since DHCPv6 isn?t supported on Android. RDNSS support will also increase. We are now planning our deployment on OpenStack. We already know that we'll rely only on neutron but we are not yet fixed between DHCPv6 and SLAAC ? Do you have any arguments for one these for VMs ?

Thanks,
Marc-Antoine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220307/6b3555ee/attachment.htm>

From skaplons at redhat.com  Mon Mar  7 08:12:27 2022
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Mon, 07 Mar 2022 09:12:27 +0100
Subject: IPv6 deployment on OpenStack
In-Reply-To: <B30F2915-674E-4029-9F1A-D25589FFF056@viarezo.fr>
References: <B30F2915-674E-4029-9F1A-D25589FFF056@viarezo.fr>
Message-ID: <14575046.tv2OnDr8pf@p1>

Hi,

On poniedzia?ek, 7 marca 2022 02:36:24 CET Marc-Antoine Godde wrote:
> Hello.
> 
> We are progressively adding support for IPv6 in my company. We decided to use SLAAC only for laptops, phones, ? since DHCPv6 isn?t supported on Android. RDNSS support will also increase. We are now planning our deployment on OpenStack. We already know that we'll rely only on neutron but we are not yet fixed between DHCPv6 and SLAAC ? Do you have any arguments for one these for VMs ?
> 
> Thanks,
> Marc-Antoine.
> 

With SLAAC You need to have Your network connected to the router in Neutron and You can only configure IP address on the VM. With DHCPv6 You can configure other things, like some static-routes, etc. 
Neutron supports DHCPv6 in the stateful and stateless variants. With stateless, You are using RA for address configuration and DHCP server for other configation. Please see [1] for more details.

[1] https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports

-- 
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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220307/db30a4ea/attachment.sig>

From mark at stackhpc.com  Mon Mar  7 08:51:12 2022
From: mark at stackhpc.com (Mark Goddard)
Date: Mon, 7 Mar 2022 08:51:12 +0000
Subject: [ironic][tripleo][kayobe][tenks][vbmc] Do you also experience
 random issues with vbmc?
In-Reply-To: <CAKZ_x791SgysTu=PRqiXLhngA+0W-Yf0P4E8xOOkWV2FG-v_wA@mail.gmail.com>
References: <CAKZ_x791SgysTu=PRqiXLhngA+0W-Yf0P4E8xOOkWV2FG-v_wA@mail.gmail.com>
Message-ID: <CAFHSqWrCHWCmq53dVOOvct7bj=UwbMFtmtso1PFKQWQswQq4Wg@mail.gmail.com>

On Sun, 6 Mar 2022 at 08:51, Rados?aw Piliszek
<radoslaw.piliszek at gmail.com> wrote:
>
> Dear fellow upstream OpenStackers,
>
> I tagged the main projects that use vbmc intensively because I have a
> question regarding the stability of vbmc.
> I have been working on adding baremetal testing in Kolla Ansible using
> Tenks and thus also VirtualBMC.
> I am encountering random failures that I am at the moment unable to debug.
> It seems vbmc likes to reject the "chassis bootdev pxe" ipmitool
> command from time to time (the command is issued when trying to deploy
> a host).
> This seems permanent per case as ironic retries this call several
> times only to fail.
> The error message is "Error setting Chassis Boot Parameter 5".
> I can't see any trace in vbmc logs (with DEBUG enabled).
> Other ipmitool commands seem to work fine (like periodic power status).
> I was wondering if any of you also experienced this issue.
> I am providing a link to an excerpt from the logs. [1]
> It also shows a raw ipmitool command succeeding only to let the next one fail.
>
> [1] https://paste.ubuntu.com/p/MgHHpDvVGf/

Radek,

Try this on for size:
https://review.opendev.org/c/openstack/kayobe-config-dev/+/829006

Mark

>
> -yoctozepto
>


From mark at stackhpc.com  Mon Mar  7 08:56:34 2022
From: mark at stackhpc.com (Mark Goddard)
Date: Mon, 7 Mar 2022 08:56:34 +0000
Subject: [kolla-ansible][wallaby][centos][horizon-dashboard] Changing
 logo.svg
In-Reply-To: <60FB6A20-20EA-4CF7-A962-3CF8AA9C88AA@univ-grenoble-alpes.fr>
References: <60FB6A20-20EA-4CF7-A962-3CF8AA9C88AA@univ-grenoble-alpes.fr>
Message-ID: <CAFHSqWrDReFiwzA_p5jv9MhKZV8RE5A2o3SPvt8mLHQouRopZA@mail.gmail.com>

Hi Franck,

Are you sure you're using the new image? If you don't change the tag,
you'll need to explicitly pull the image from your registry.

Mark

On Fri, 4 Mar 2022 at 17:14, Franck VEDEL
<franck.vedel at univ-grenoble-alpes.fr> wrote:
>
> Hello,
> I come back to ask for some help with a new problem on my Openstack platform. For once, it's a small problem.
> I take this opportunity to thank those who helped me solve my problem which was the following: the instances were not created regularly on the 3 nova servers. Nova-scheduler was malfunctioning. I fixed the problem by setting build_failure_weight_multiplier=0
> Since then, in DEBUG mode, we can clearly see the calculation of the weight and the distribution of the instances. It's beautiful.
>
> My new problem is: I'm using kolla-ansible, centos (stream) and Wallaby.
> In the directory /usr/local/lib/python3.6/site-packages/openstack_dashboard/static/dashboard/img/   I modified the 3 files logo.svg, logo-splash.svg, favicon.ico.
>
> I thought doing a "kolla-ansible -i multinode reconfigure horizon" would update the logos and favicon.ico....but no, it does nothing.
> How do I change these logos with kolla-ansible? Is it difficult?
>
> thank you in advance
>
>
> Franck VEDEL
>
>


From radoslaw.piliszek at gmail.com  Mon Mar  7 09:24:48 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Mon, 7 Mar 2022 10:24:48 +0100
Subject: [ironic][tripleo][kayobe][tenks][vbmc] Do you also experience
 random issues with vbmc?
In-Reply-To: <CAFHSqWrCHWCmq53dVOOvct7bj=UwbMFtmtso1PFKQWQswQq4Wg@mail.gmail.com>
References: <CAKZ_x791SgysTu=PRqiXLhngA+0W-Yf0P4E8xOOkWV2FG-v_wA@mail.gmail.com>
 <CAFHSqWrCHWCmq53dVOOvct7bj=UwbMFtmtso1PFKQWQswQq4Wg@mail.gmail.com>
Message-ID: <CAKZ_x7-tNUaVyu4H5SYwfneFg051Gi-C3FOnz8WjN5+O6+Or9w@mail.gmail.com>

On Mon, 7 Mar 2022 at 09:51, Mark Goddard <mark at stackhpc.com> wrote:
>
> On Sun, 6 Mar 2022 at 08:51, Rados?aw Piliszek
> <radoslaw.piliszek at gmail.com> wrote:
> >
> > Dear fellow upstream OpenStackers,
> >
> > I tagged the main projects that use vbmc intensively because I have a
> > question regarding the stability of vbmc.
> > I have been working on adding baremetal testing in Kolla Ansible using
> > Tenks and thus also VirtualBMC.
> > I am encountering random failures that I am at the moment unable to debug.
> > It seems vbmc likes to reject the "chassis bootdev pxe" ipmitool
> > command from time to time (the command is issued when trying to deploy
> > a host).
> > This seems permanent per case as ironic retries this call several
> > times only to fail.
> > The error message is "Error setting Chassis Boot Parameter 5".
> > I can't see any trace in vbmc logs (with DEBUG enabled).
> > Other ipmitool commands seem to work fine (like periodic power status).
> > I was wondering if any of you also experienced this issue.
> > I am providing a link to an excerpt from the logs. [1]
> > It also shows a raw ipmitool command succeeding only to let the next one fail.
> >
> > [1] https://paste.ubuntu.com/p/MgHHpDvVGf/
>
> Radek,
>
> Try this on for size:
> https://review.opendev.org/c/openstack/kayobe-config-dev/+/829006

Thanks, Mark! Trying it out now in [2].

[2] https://review.opendev.org/c/openstack/kolla-ansible/+/832204

-yoctozepto


From marc-antoine.godde at viarezo.fr  Mon Mar  7 09:36:30 2022
From: marc-antoine.godde at viarezo.fr (Marc-Antoine Godde)
Date: Mon, 7 Mar 2022 10:36:30 +0100
Subject: IPv6 deployment on OpenStack
In-Reply-To: <14575046.tv2OnDr8pf@p1>
References: <B30F2915-674E-4029-9F1A-D25589FFF056@viarezo.fr>
 <14575046.tv2OnDr8pf@p1>
Message-ID: <8195F0AD-5FE8-432C-A1A7-8EB287B13C64@viarezo.fr>

Hello,

Thanks for your answer.

If I?m correct, we can just use a virtual router with SLAAC since RADVD can deal with RS and emit RA (with support for RFC6106), right ? More generally, aren?t we suppose to have a virtual router every time, even in DHCPv6 (stateless and statefull), to answer RS ? I have to admit that I?m not very familiar at the moment with the implementations of RFCs in OpenStack.

Currently, we prefer the idea of adding IPv6 through SLAAC to have a uniform network. If we do so, we?d like to avoid sending RA from our physical router to limit its load. Yet, we do not any other arguments to support this choice.
Do you have any recommendations on what to do in latest versions of OpenStack ? What is usually done ?

Thanks,
Marc-Antoine

> Le 7 mars 2022 ? 09:12, Slawek Kaplonski <skaplons at redhat.com> a ?crit :
> 
> Hi,
> 
> On poniedzia?ek, 7 marca 2022 02:36:24 CET Marc-Antoine Godde wrote:
>> Hello.
>> 
>> We are progressively adding support for IPv6 in my company. We decided to use SLAAC only for laptops, phones, ? since DHCPv6 isn?t supported on Android. RDNSS support will also increase. We are now planning our deployment on OpenStack. We already know that we'll rely only on neutron but we are not yet fixed between DHCPv6 and SLAAC ? Do you have any arguments for one these for VMs ?
>> 
>> Thanks,
>> Marc-Antoine.
>> 
> 
> With SLAAC You need to have Your network connected to the router in Neutron and You can only configure IP address on the VM. With DHCPv6 You can configure other things, like some static-routes, etc. 
> Neutron supports DHCPv6 in the stateful and stateless variants. With stateless, You are using RA for address configuration and DHCP server for other configation. Please see [1] for more details.
> 
> [1] https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports
> 
> -- 
> Slawek Kaplonski
> Principal Software Engineer
> Red Hat



From ignaziocassano at gmail.com  Mon Mar  7 09:47:19 2022
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Mon, 7 Mar 2022 10:47:19 +0100
Subject: [openstack][queens][cinder] volume retype errors
Message-ID: <CAB7j8cWCrGLoNQwHw_ekM1D0LBkToLhdgwEG4eOuJTLJpTr58g@mail.gmail.com>

Hello, sometimes the volume retype from a netapp nfs storage to another
netapp nfs storage does not work.
I do not know the reason but I think something is going wrong in nova:

/var/log/nova/nova-compute.log:2022-02-02 14:23:39.992 194288 ERROR root
[req-ebbf749f-359f-4282-94c5-0913cffe97a3 66adb965bef64eaaab2af93ade87e2ca
68feefdf7c5847388534e9214dc13366 - default default] Original exception
being dropped: ['Traceback (most recent call last):\n', '  File
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 5655, in
_swap_volume\n    mountpoint, resize_to)\n', '  File
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 1647,
in swap_volume\n    self._disconnect_volume(context, new_connection_info,
instance)\n', '  File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in
__exit__\n    self.force_reraise()\n', '  File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
force_reraise\n    six.reraise(self.type_, self.value, self.tb)\n', '  File
"/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 1644,
in swap_volume\n    self._swap_volume(guest, disk_dev, conf, resize_to)\n',
'  File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
line 1593, in _swap_volume\n    raise
exception.VolumeRebaseFailed(reason=six.text_type(exc))\n',
"VolumeRebaseFailed: Volume rebase failed: Requested operation is not
valid: pivot of disk 'vda' requires an active copy job\n"]:
VolumeAttachmentNotFound: Volume attachment
2cd820e0-85e8-498d-a62a-800260d0cf31 could not be found


Must I try to change some parameters in nova.conf on compute nodes about
volume attachment ?

Thanks
Ignazio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220307/c595dca6/attachment.htm>

From amonster369 at gmail.com  Mon Mar  7 11:06:31 2022
From: amonster369 at gmail.com (A Monster)
Date: Mon, 7 Mar 2022 12:06:31 +0100
Subject: Use idle backup servers
Message-ID: <CAEc0zit5bT=_z=hyOm8wgLD4TKrJVzs0TEK+45+485yWeNKrTA@mail.gmail.com>

Is there a way to use multiple servers as backup  but these servers stay
idle until the main server fails
for example two controller servers but only one of them which is running
services, and in case this main server fails, the cloud switches to the
other server.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220307/fff17ee8/attachment.htm>

From mdemaced at redhat.com  Mon Mar  7 11:07:09 2022
From: mdemaced at redhat.com (Maysa De Macedo Souza)
Date: Mon, 7 Mar 2022 12:07:09 +0100
Subject: [kuryr] Zed PTG planning
Message-ID: <CAEn0wJX=_WmAGDf1XUzWzjqjW2iRgnJ_tXZi9Z981ueYOx90hg@mail.gmail.com>

Hello everyone,

The virtual PTG will happen between 4th-8th April. I've created a doodle[1]
to try finding a time slot that works for most of us. There is also an
etherpad[2] to propose topics to be discussed, feel free to fill it if you
have one.

Thank you.

Kind regards,
Maysa Macedo.

[1] https://doodle.com/meeting/participate/id/0dN1Movb
[2] https://etherpad.opendev.org/p/kuryr-zed-ptg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220307/6d90716e/attachment.htm>

From smooney at redhat.com  Mon Mar  7 11:09:48 2022
From: smooney at redhat.com (Sean Mooney)
Date: Mon, 07 Mar 2022 11:09:48 +0000
Subject: [nova][neutron] os-vif params
In-Reply-To: <45AC4BA4-DA72-42A1-8E7B-4DAD3870CF0B@gmail.com>
References: <YiJHZ5PklI8NXIkf@sync2>
 <CAECr9X4Fg8iNZkYsxicYHZh2pvWBMrd=+E7+nqVY=EPwv-e6VQ@mail.gmail.com>
 <3457d3040994053d4ecec879ef33c9b09758774b.camel@redhat.com>
 <45AC4BA4-DA72-42A1-8E7B-4DAD3870CF0B@gmail.com>
Message-ID: <4010df1ac7cdbae603e767aaf6d6c1d3cc26a29b.camel@redhat.com>

On Fri, 2022-03-04 at 19:57 +0100, Arnaud wrote:
> Hi Sean, Rodolfo,
> 
> Thanks for your answers.
> I will try to do the patch next week so these parameters are included in the nova config sample and documentation.
> 
> About the isolated_vif params. It seems like a security enhancement to set it to True when using ovs? Do you confirm that?
yes if you are usging ovs with ml2/ovs and the l2 agent then you shoudl enable isolated_vif to enaure that the port are added to the
"dead" vlan 4095 which will drop all packets until the l2 agent moves the port onto the correct local vlan for the neutron netowrk.
this impoves tenant isolation during move operations.

it is not requried/tested with ovn, odl or other sdn contolers that use ovs as a switch.
they do not use vlans for local tenant isolation or the normal action. they use ovs in secure
mode which will drop packets by default if there are no openflow rules to process the packet.
as such they shoudl not have isolated_vif enabled.
> 
> Regards,
> Arnaud
> 
> Le 4 mars 2022 18:57:40 GMT+01:00, Sean Mooney <smooney at redhat.com> a ?crit?:
> > On Fri, 2022-03-04 at 18:33 +0100, Rodolfo Alonso Hernandez wrote:
> > > Hi Arnaud:
> > > 
> > > Those parameters should be set in nova.conf, in the "os_vif_XXX" section
> > > [1].
> > > 
> > > "network_device_mtu" is deprecated. The interface MTU is retrieved from the
> > > network MTU. "ovs_vsctl_timeout" is deprecated too, we don't use vsctl
> > > commands anymore.
> > actully we do use vsctl at least in ci but it is deprecated.
> > we are currently using it in ci to workaround a bug in the ovs python bindings.
> > 
> > after the RC period is clear i might revert that since i think the ovs python bidnign are
> > fixed but im not sure they are fixed in ubuntu 20.04 so i dont want to regress the ci stablity
> > currently by reverting to the native bindings.
> > 
> > https://review.opendev.org/c/openstack/devstack/+/796826
> > 
> > ill update https://github.com/openstack/devstack/blob/master/lib/os-vif#L6 to native
> > once we are sure https://bugs.launchpad.net/os-vif/+bug/1929446 is fixed in the ovs python bindings.
> > 
> > 
> > > 
> > > Maybe Nova folks can extend my answer.
> > > 
> > > Regards.
> > > 
> > > [1]
> > > https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/releasenotes/notes/libvirt-uses-os-vif-plugins-31a0617de0c248b9.yaml
> > > 
> > > 
> > > On Fri, Mar 4, 2022 at 6:18 PM Arnaud Morin <arnaud.morin at gmail.com> wrote:
> > > 
> > > > Hey all,
> > > > 
> > > > When I take a look at [1], I can see some parameters, such as
> > > > network_device_mtu, isolate_vif, etc.
> > > > 
> > > > As far as I can tell, nova is using these params when plugging the port
> > > > in OVS (if using OVS as ml2 plugin of course).
> > > > 
> > > > But I cannot find the config params in the documentation: [2]
> > > > 
> > > > Am I missing something?
> > > > 
> > > > Cheers,
> > > > Arnaud.
> > > > 
> > > > [1] https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py
> > > > [2] https://docs.openstack.org/nova/latest/configuration/config.html
> > > > 
> > > > 
> > 



From janders at redhat.com  Mon Mar  7 12:13:16 2022
From: janders at redhat.com (Jacob Anders)
Date: Mon, 7 Mar 2022 22:13:16 +1000
Subject: [ironic] Zed PTG slots
In-Reply-To: <CAORRS=nacYs+yiVRzto=TgvRJPnzXR_u3XAuGkJsmgd+-R3=vg@mail.gmail.com>
References: <CAJqPaj8M4BgPpsQPG9mtvnXkbHPVtSeK3cG1Ws+aaeC1skRsgw@mail.gmail.com>
 <CAORRS=nacYs+yiVRzto=TgvRJPnzXR_u3XAuGkJsmgd+-R3=vg@mail.gmail.com>
Message-ID: <CAFB36U1zi7hQVh9K5GLZpmxYaN3akzkN9qzzCN0P5HHcAL8Pbg@mail.gmail.com>

Thank you Iury and Riccardo.

I also vote for 1 and 3.

Thank you,
Jacob

On Fri, Mar 4, 2022 at 8:39 PM Riccardo Pittau <elfosardo at gmail.com> wrote:

> Thanks Iury!
>
> My choices are for options #1 and #3
>
> Ciao!
> Riccardo
>
> On Fri, Mar 4, 2022 at 4:28 AM Iury Gregory <iurygregory at gmail.com> wrote:
>
>> Hello Ironicers!
>>
>> For the Zed PTG I'm planning to have some slots that will allow APAC
>> contributors to participate in the discussions.
>>
>> Keep in mind that we have some guidelines we should try to follow:
>> 1. Cross project discussions (like SIGs or support project teams) should
>> be scheduled towards the start of the week so that any discussions that
>> might shape those of other teams happen first.
>> 2. No team should sign up for more than 4 hours per UTC day to help keep
>> participants actively engaged.
>> 3. No team should sign up for more than 16 hours across all time slots to
>> avoid burning out our contributors and to enable participation in multiple
>> teams discussions.
>>
>> Based on this I have the following proposals: (Feel free to provide more
>> ideas also) =)
>>  *Option  #1* *16hrs* Monday till Thursday
>> 1h (APAC night + EMEA morning)
>> 2hrs (EMEA afternoon + NA morning)
>> 1hr (NA afternoon/night + APAC morning)
>>
>> *Option  #2* *15hrs* Tuesday till Friday
>> 1h (APAC night + EMEA morning)
>> 2hrs (EMEA afternoon + NA morning)
>> 1hr (NA afternoon/night + APAC morning)
>> * On Friday the NA + APAC session won't happen because is saturday for
>> APAC contributors *
>>
>> *Option #3* *16hrs* Monday till Thursday
>> 3hrs (EMEA afternoon + NA morning)
>> 1hr (NA afternoon/night + APAC morning)
>>
>> *Option #4* *15hrs* Tuesday till Friday
>> 3hrs (EMEA afternoon + NA morning)
>> 1hr (NA afternoon/night + APAC morning)
>> * On Friday the NA + APAC session won't happen because is saturday for
>> APAC contributors *
>>
>> Please choose two options and we will vote during our upstream meeting on
>> March 7th.
>>
>> Thank you!
>>
>> --
>>
>>
>> *Att[]'sIury Gregory Melo Ferreira *
>> *MSc in Computer Science at UFCG*
>> *Part of the ironic-core and puppet-manager-core team in OpenStack*
>> *Software Engineer at Red Hat Czech*
>> *Social*: https://www.linkedin.com/in/iurygregory
>> *E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220307/5bbf071a/attachment.htm>

From sshnaidm at redhat.com  Mon Mar  7 14:38:49 2022
From: sshnaidm at redhat.com (Sagi Shnaidman)
Date: Mon, 7 Mar 2022 16:38:49 +0200
Subject: [ansible openstack collections/modules] Core team clean up
Message-ID: <CAGHQP9yU+e6MjMH-1hss-xZvsJzNUnkV6FBdjB2R4VBPRSazCg@mail.gmail.com>

Hello,

I took a look at our core team ansible-collections-openstack-core in
Gerrit.[1]
There are people that might be not participating in the development of
Ansible Openstack collections anymore:[2]

Jesse Pretorius
Julia Kreger
Kevin Carter
Mohammed Naser
Monty Taylor

If there are no objections from them, I'd like to propose we remove these
folks from our core team, while thanking them for their contributions.
If anyone still wants to resume their work on collections or just want to
help in reviews and merges, please let me know. Same if you are sure you
don't plan to participate in collections development in the next future and
would like to be removed from the list for now.

Please reply and let me know any agreements or concerns.

[1]
https://review.opendev.org/admin/groups/0e01228e912733e8b9a8d957631e41665aa0ffbd,members
[2]
https://www.stackalytics.io/report/contribution?module=opendev.org/openstack/ansible-collections-openstack&project_type=openstack-others&days=180
-- 
Best regards
Sagi Shnaidman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220307/2324359b/attachment.htm>

From andrew.west-contractor at CGG.COM  Mon Mar  7 14:53:54 2022
From: andrew.west-contractor at CGG.COM (west, andrew)
Date: Mon, 7 Mar 2022 14:53:54 +0000
Subject: [openstack-ansible] bootstap-aio.sh is failing with error
 :jinja2.exceptions.TemplateRuntimeError: No filter named 'ipaddr' found
Message-ID: <PAYP264MB4256AC4659CBA76AEE1BD650C4089@PAYP264MB4256.FRAP264.PROD.OUTLOOK.COM>

Am trying to install openstack-ansible AIO (24.0.0.0rc1) on a recent  ubuntu focal (20.04) cloud image VM
kernel 5.4.0-99-generic
ansible core 2.12.2
jinja 3.0.3
python 3.8.10

the bootstap-aio.sh script  is failing with error
jinja2.exceptions.TemplateRuntimeError: No filter named 'ipaddr' found

(I see the ipaddr filter  moved (big changes separating modules > ansible2.10 I think)   to the ansible.netcommon collection
So following google:
ansible galaxy collection install ansible.netcommon
Also needs
pip install netaddr


However this still doesn't solve it, add traceback to playbook:

Seems some of core ansible_collections plugins need updating ?  (sorry, I'm fairly new to ansible)

<localhost> EXEC /bin/sh -c 'echo ~root && sleep 0'
<localhost> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo /root/.ansible/tmp `"&& mkdir "` echo /root/.ansible/tmp/ansible-tmp-1646414479.2525613-38683-223155148734113 `" && echo ansible-tmp-1646414479.2525613-38683-223155148734113="` echo /root/.ansible/tmp/ansible-tmp-1646414479.2525613-38683-223155148734113 `" ) && sleep 0'
redirecting filter ansible.builtin.ipaddr to ansible.netcommon.ipaddr
redirecting filter ansible.builtin.ipaddr to ansible.netcommon.ipaddr
redirecting filter ansible.builtin.ipaddr to ansible.netcommon.ipaddr
<localhost> EXEC /bin/sh -c 'rm -f -r /root/.ansible/tmp/ansible-tmp-1646414479.2525613-38683-223155148734113/ > /dev/null 2>&1 && sleep 0'
The full traceback is:
Traceback (most recent call last):
  File "/opt/ansible-runtime/lib/python3.8/site-packages/ansible/executor/task_executor.py", line 119, in run
    item_results = self._run_loop(items)
  File "/opt/ansible-runtime/lib/python3.8/site-packages/ansible/executor/task_executor.py", line 354, in _run_loop
    res = self._execute(variables=task_vars)
  File "/opt/ansible-runtime/lib/python3.8/site-packages/ansible/executor/task_executor.py", line 589, in _execute
    result = self._handler.run(task_vars=variables)
  File "/etc/ansible/ansible_collections/openstack/config_template/plugins/action/config_template.py", line 869, in run
    resultant = self._check_templar(data=template_data)
  File "/etc/ansible/ansible_collections/openstack/config_template/plugins/action/config_template.py", line 768, in _check_templar
    return self._templar.template(
  File "/opt/ansible-runtime/lib/python3.8/site-packages/ansible/template/__init__.py", line 869, in template
    result = self.do_template(
  File "/opt/ansible-runtime/lib/python3.8/site-packages/ansible/template/__init__.py", line 1139, in do_template
    res = j2_concat(rf)
  File "<template>", line 111, in root
  File "<template>", line 30, in t_3
jinja2.exceptions.TemplateRuntimeError: No filter named 'ipaddr' found.
fatal: [localhost]: FAILED! => {
    "msg": "Unexpected failure during module execution.",
    "stdout": ""
}

RUNNING HANDLER [systemd_networkd : Restart networkd] *****************************************************************************************************************
task path: /etc/ansible/roles/systemd_networkd/handlers/main.yml:16
Read vars_file '{{ playbook_dir }}/../playbooks/defaults/repo_packages/openstack_services.yml'
<localhost> ESTABLISH LOCAL CONNECTION FOR USER: root
<localhost> EXEC /bin/sh -c 'echo ~root && sleep 0'
<localhost> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo /root/.ansible/tmp `"&& mkdir "` echo /root/.ansible/tmp/ansible-tmp-1646414479.331306-38764-149355553789280 `" && echo ansible-tmp-1646414479.331306-38764-149355553789280="` echo /root/.ansible/tmp/ansible-tmp-1646414479.331306-38764-149355553789280 `" ) && sleep 0'
Using module file /opt/ansible-runtime/lib/python3.8/site-packages/ansible/modules/systemd.py
<localhost> PUT /root/.ansible/tmp/ansible-local-36177dradb42n/tmpeyfb1i4v TO /root/.ansible/tmp/ansible-tmp-1646414479.331306-38764-149355553789280/AnsiballZ_systemd.py
<localhost> PUT /root/.ansible/tmp/ansible-local-36177dradb42n/tmpdkb43zb8 TO /root/.ansible/tmp/ansible-tmp-1646414479.331306-38764-149355553789280/async_wrapper.py
<localhost> EXEC /bin/sh -c 'chmod u+x /root/.ansible/tmp/ansible-tmp-1646414479.331306-38764-149355553789280/ /root/.ansible/tmp/ansible-tmp-1646414479.331306-38764-149355553789280/AnsiballZ_systemd.py /root/.ansible/tmp/ansible-tmp-1646414479.331306-38764-149355553789280/async_wrapper.py && sleep 0'
<localhost> EXEC /bin/sh -c 'ANSIBLE_ASYNC_DIR='"'"'~/.ansible_async'"'"' /usr/bin/python3 /root/.ansible/tmp/ansible-tmp-1646414479.331306-38764-149355553789280/async_wrapper.py 6737658312 45 /root/.ansible/tmp/ansible-tmp-1646414479.331306-38764-149355553789280/AnsiballZ_systemd.py _ && sleep 0'
changed: [localhost] => {
    "ansible_job_id": "6737658312.38783",
    "changed": true,
    "finished": 0,
    "results_file": "/root/.ansible_async/6737658312.38783",
    "started": 1
}

RUNNING HANDLER [systemd_networkd : (RE)Gather facts post setup] ******************************************************************************************************
task path: /etc/ansible/roles/systemd_networkd/handlers/main.yml:29
Read vars_file '{{ playbook_dir }}/../playbooks/defaults/repo_packages/openstack_services.yml'
Using module file /opt/ansible-runtime/lib/python3.8/site-packages/ansible/modules/setup.py
Pipelining is enabled.
<localhost> ESTABLISH LOCAL CONNECTION FOR USER: root
<localhost> EXEC /bin/sh -c '/usr/bin/python3 && sleep 0'
ok: [localhost]

PLAY RECAP ************************************************************************************************************************************************************
localhost                  : ok=105  changed=7    unreachable=0    failed=1    skipped=26   rescued=0    ignored=0


thanks for any help


________________________________
"This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of the email by others is strictly prohibited. If you are not the intended recipient, you must not review, disclose, copy, distribute or use this e-mail; please delete it from your system and notify the sender immediately."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220307/d26dd57b/attachment-0001.htm>

From juliaashleykreger at gmail.com  Mon Mar  7 14:58:55 2022
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Mon, 7 Mar 2022 06:58:55 -0800
Subject: [ansible openstack collections/modules] Core team clean up
In-Reply-To: <CAGHQP9yU+e6MjMH-1hss-xZvsJzNUnkV6FBdjB2R4VBPRSazCg@mail.gmail.com>
References: <CAGHQP9yU+e6MjMH-1hss-xZvsJzNUnkV6FBdjB2R4VBPRSazCg@mail.gmail.com>
Message-ID: <CAF7gwdjrFm1TpouU+aZ=Wg=bmwJLnA8fViDKE3GUCONo_GfOaA@mail.gmail.com>

Wow, I didn't know I had access or even membership to that group.

I guess the only thing with reducing down the contributor list is some
of those contributors are still active in openstack and can be
available, if requested, to review a module or change.

Just thinking that if we aggressively manage the core memberships (as
we once did in the early days) but don't add individuals, then we may
run into undesirable situations getting code merged or maintained.

-Julia

On Mon, Mar 7, 2022 at 6:44 AM Sagi Shnaidman <sshnaidm at redhat.com> wrote:
>
>
> Hello,
>
> I took a look at our core team ansible-collections-openstack-core in Gerrit.[1]
> There are people that might be not participating in the development of Ansible Openstack collections anymore:[2]
>
> Jesse Pretorius
> Julia Kreger
> Kevin Carter
> Mohammed Naser
> Monty Taylor
>
> If there are no objections from them, I'd like to propose we remove these folks from our core team, while thanking them for their contributions.
> If anyone still wants to resume their work on collections or just want to help in reviews and merges, please let me know. Same if you are sure you don't plan to participate in collections development in the next future and would like to be removed from the list for now.
>
> Please reply and let me know any agreements or concerns.
>
> [1] https://review.opendev.org/admin/groups/0e01228e912733e8b9a8d957631e41665aa0ffbd,members
> [2] https://www.stackalytics.io/report/contribution?module=opendev.org/openstack/ansible-collections-openstack&project_type=openstack-others&days=180
> --
> Best regards
> Sagi Shnaidman


From anyrude10 at gmail.com  Mon Mar  7 13:59:13 2022
From: anyrude10 at gmail.com (Anirudh Gupta)
Date: Mon, 7 Mar 2022 19:29:13 +0530
Subject: [TripleO] Major Release Upgrade Issue
Message-ID: <CAKxkTi3_+k9nFo7g0T8zuJmshuXWLP0Z2dgM4gaPE5n36uEQfw@mail.gmail.com>

Hi Team

I have deployed Openstack USSURI using TripleO. It was successfully done,
after which I started Upgrading the setup to Victoria.

The Undercloud was successfully upgraded and there was no issue, but when I
tried upgrading the Overcloud Nodes (starting with the Controller), some
issues were encountered while executing the below command

openstack overcloud upgrade run --limit Controller --playbook
upgrade_steps_playbook.yaml


Issue:

TASK | Ensure DNF modules have the right stream

*2022-03-04 14:29:57.723661 | 525400cb-2e90-4086-e760-00000000009b |
 FATAL | Ensure DNF modules have the right stream | overcloud-novacompute-0
|* item={'module': 'container-tools', 'stream': '3.0'} |*

*...*

*...*

*Installing module from Fail-Safe repository is not*

*allowed\"))\ndnf.exceptions.Error: Installing module from Fail-Safe
repository is not allowed\n", "module_stdout": "", "msg": "MODULE
FAILURE\nSee stdout/stderr for the exact error", "rc": 1}**


*Can someone please help in resolving this.*

Thanks in Advance


Regards

Anirudh Gupta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220307/3d5240af/attachment.htm>

From eblock at nde.ag  Mon Mar  7 16:23:03 2022
From: eblock at nde.ag (Eugen Block)
Date: Mon, 07 Mar 2022 16:23:03 +0000
Subject: [openstack][queens][cinder] volume retype errors
In-Reply-To: <CAB7j8cWCrGLoNQwHw_ekM1D0LBkToLhdgwEG4eOuJTLJpTr58g@mail.gmail.com>
Message-ID: <20220307162303.Horde.VExGf9Y0xDD_Kjz3lCeaSje@webmail.nde.ag>

Hi,

since you're retyping a volume, what do the cinder logs reveal?


Zitat von Ignazio Cassano <ignaziocassano at gmail.com>:

> Hello, sometimes the volume retype from a netapp nfs storage to another
> netapp nfs storage does not work.
> I do not know the reason but I think something is going wrong in nova:
>
> /var/log/nova/nova-compute.log:2022-02-02 14:23:39.992 194288 ERROR root
> [req-ebbf749f-359f-4282-94c5-0913cffe97a3 66adb965bef64eaaab2af93ade87e2ca
> 68feefdf7c5847388534e9214dc13366 - default default] Original exception
> being dropped: ['Traceback (most recent call last):\n', '  File
> "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 5655, in
> _swap_volume\n    mountpoint, resize_to)\n', '  File
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 1647,
> in swap_volume\n    self._disconnect_volume(context, new_connection_info,
> instance)\n', '  File
> "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in
> __exit__\n    self.force_reraise()\n', '  File
> "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
> force_reraise\n    six.reraise(self.type_, self.value, self.tb)\n', '  File
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 1644,
> in swap_volume\n    self._swap_volume(guest, disk_dev, conf, resize_to)\n',
> '  File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
> line 1593, in _swap_volume\n    raise
> exception.VolumeRebaseFailed(reason=six.text_type(exc))\n',
> "VolumeRebaseFailed: Volume rebase failed: Requested operation is not
> valid: pivot of disk 'vda' requires an active copy job\n"]:
> VolumeAttachmentNotFound: Volume attachment
> 2cd820e0-85e8-498d-a62a-800260d0cf31 could not be found
>
>
> Must I try to change some parameters in nova.conf on compute nodes about
> volume attachment ?
>
> Thanks
> Ignazio





From ignaziocassano at gmail.com  Mon Mar  7 16:44:40 2022
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Mon, 7 Mar 2022 17:44:40 +0100
Subject: [openstack][queens][cinder] volume retype errors
In-Reply-To: <20220307162303.Horde.VExGf9Y0xDD_Kjz3lCeaSje@webmail.nde.ag>
References: <CAB7j8cWCrGLoNQwHw_ekM1D0LBkToLhdgwEG4eOuJTLJpTr58g@mail.gmail.com>
 <20220307162303.Horde.VExGf9Y0xDD_Kjz3lCeaSje@webmail.nde.ag>
Message-ID: <CAB7j8cUwdWYV2RUdkDopOzh9yivGhMta0A+1B2Ydwdr9rmTtzA@mail.gmail.com>

Hello, volume.log does not report errors:
2022-03-07 15:41:44.435 159559 INFO cinder.volume.manager
[req-68444973-24eb-4b21-95b2-626c9b2e2aa0 5134ed3b93284af5ba2f05d7361edf53
0e760ccde5d24af5a571de40220fbf80 - default default] Created volume
successfully.
2022-03-07 15:41:45.358 159099 INFO cinder.volume.manager
[req-68444973-24eb-4b21-95b2-626c9b2e2aa0 5134ed3b93284af5ba2f05d7361edf53
0e760ccde5d24af5a571de40220fbf80 - default default] Migrate volume
completed successfully.
2022-03-07 15:41:48.970 159559 INFO cinder.volume.manager
[req-72ca9242-25e9-4bb0-9bd6-9857f42805ee 5134ed3b93284af5ba2f05d7361edf53
0e760ccde5d24af5a571de40220fbf80 - default default] attachment_update
complete

Il giorno lun 7 mar 2022 alle ore 17:25 Eugen Block <eblock at nde.ag> ha
scritto:

> Hi,
>
> since you're retyping a volume, what do the cinder logs reveal?
>
>
> Zitat von Ignazio Cassano <ignaziocassano at gmail.com>:
>
> > Hello, sometimes the volume retype from a netapp nfs storage to another
> > netapp nfs storage does not work.
> > I do not know the reason but I think something is going wrong in nova:
> >
> > /var/log/nova/nova-compute.log:2022-02-02 14:23:39.992 194288 ERROR root
> > [req-ebbf749f-359f-4282-94c5-0913cffe97a3
> 66adb965bef64eaaab2af93ade87e2ca
> > 68feefdf7c5847388534e9214dc13366 - default default] Original exception
> > being dropped: ['Traceback (most recent call last):\n', '  File
> > "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 5655, in
> > _swap_volume\n    mountpoint, resize_to)\n', '  File
> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> 1647,
> > in swap_volume\n    self._disconnect_volume(context, new_connection_info,
> > instance)\n', '  File
> > "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in
> > __exit__\n    self.force_reraise()\n', '  File
> > "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
> > force_reraise\n    six.reraise(self.type_, self.value, self.tb)\n', '
> File
> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> 1644,
> > in swap_volume\n    self._swap_volume(guest, disk_dev, conf,
> resize_to)\n',
> > '  File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
> > line 1593, in _swap_volume\n    raise
> > exception.VolumeRebaseFailed(reason=six.text_type(exc))\n',
> > "VolumeRebaseFailed: Volume rebase failed: Requested operation is not
> > valid: pivot of disk 'vda' requires an active copy job\n"]:
> > VolumeAttachmentNotFound: Volume attachment
> > 2cd820e0-85e8-498d-a62a-800260d0cf31 could not be found
> >
> >
> > Must I try to change some parameters in nova.conf on compute nodes about
> > volume attachment ?
> >
> > Thanks
> > Ignazio
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220307/fb4e5a96/attachment-0001.htm>

From ignaziocassano at gmail.com  Mon Mar  7 16:50:39 2022
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Mon, 7 Mar 2022 17:50:39 +0100
Subject: [openstack][queens][cinder] volume retype errors
In-Reply-To: <CAB7j8cUwdWYV2RUdkDopOzh9yivGhMta0A+1B2Ydwdr9rmTtzA@mail.gmail.com>
References: <CAB7j8cWCrGLoNQwHw_ekM1D0LBkToLhdgwEG4eOuJTLJpTr58g@mail.gmail.com>
 <20220307162303.Horde.VExGf9Y0xDD_Kjz3lCeaSje@webmail.nde.ag>
 <CAB7j8cUwdWYV2RUdkDopOzh9yivGhMta0A+1B2Ydwdr9rmTtzA@mail.gmail.com>
Message-ID: <CAB7j8cVdqgQWkfn=y6MG5jeR1tWfbmq=BVv=cPBPw4OUCbuuKA@mail.gmail.com>

Hello again I found the error but it is in cinder api log:
2022-03-07 15:42:57.330 156916 INFO cinder.api.openstack.wsgi
[req-01eb2613-4aad-4809-ac91-037de3148fbb 5134ed3b93284af5ba2f05d7361edf53
0e760ccde5d24af5a571de40220fbf80 - default default]
http://10.138.144.16:8776/v3/0e760ccde5d24af5a571de40220fbf80/attachments/04ae01f6-e164-40cb-8d31-63f78e69c8db
returned with HTTP 404

and in nova compute log:
15:42:57.502 280431 ERROR oslo_messaging.rpc.server
[req-dfeac1f0-870b-4aef-af40-cda52f4552e0 5134ed3b93284af5ba2f05d7361edf53
0e760ccde5d24af5a571de40220fbf80 - default default] Exception during
message handling: VolumeAttachmentNotFound: Volume attachment
04ae01f6-e164-40cb-8d31-63f78e69c8db could not be found.

Il giorno lun 7 mar 2022 alle ore 17:44 Ignazio Cassano <
ignaziocassano at gmail.com> ha scritto:

> Hello, volume.log does not report errors:
> 2022-03-07 15:41:44.435 159559 INFO cinder.volume.manager
> [req-68444973-24eb-4b21-95b2-626c9b2e2aa0 5134ed3b93284af5ba2f05d7361edf53
> 0e760ccde5d24af5a571de40220fbf80 - default default] Created volume
> successfully.
> 2022-03-07 15:41:45.358 159099 INFO cinder.volume.manager
> [req-68444973-24eb-4b21-95b2-626c9b2e2aa0 5134ed3b93284af5ba2f05d7361edf53
> 0e760ccde5d24af5a571de40220fbf80 - default default] Migrate volume
> completed successfully.
> 2022-03-07 15:41:48.970 159559 INFO cinder.volume.manager
> [req-72ca9242-25e9-4bb0-9bd6-9857f42805ee 5134ed3b93284af5ba2f05d7361edf53
> 0e760ccde5d24af5a571de40220fbf80 - default default] attachment_update
> complete
>
> Il giorno lun 7 mar 2022 alle ore 17:25 Eugen Block <eblock at nde.ag> ha
> scritto:
>
>> Hi,
>>
>> since you're retyping a volume, what do the cinder logs reveal?
>>
>>
>> Zitat von Ignazio Cassano <ignaziocassano at gmail.com>:
>>
>> > Hello, sometimes the volume retype from a netapp nfs storage to another
>> > netapp nfs storage does not work.
>> > I do not know the reason but I think something is going wrong in nova:
>> >
>> > /var/log/nova/nova-compute.log:2022-02-02 14:23:39.992 194288 ERROR root
>> > [req-ebbf749f-359f-4282-94c5-0913cffe97a3
>> 66adb965bef64eaaab2af93ade87e2ca
>> > 68feefdf7c5847388534e9214dc13366 - default default] Original exception
>> > being dropped: ['Traceback (most recent call last):\n', '  File
>> > "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 5655,
>> in
>> > _swap_volume\n    mountpoint, resize_to)\n', '  File
>> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
>> 1647,
>> > in swap_volume\n    self._disconnect_volume(context,
>> new_connection_info,
>> > instance)\n', '  File
>> > "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in
>> > __exit__\n    self.force_reraise()\n', '  File
>> > "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
>> > force_reraise\n    six.reraise(self.type_, self.value, self.tb)\n', '
>> File
>> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
>> 1644,
>> > in swap_volume\n    self._swap_volume(guest, disk_dev, conf,
>> resize_to)\n',
>> > '  File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
>> > line 1593, in _swap_volume\n    raise
>> > exception.VolumeRebaseFailed(reason=six.text_type(exc))\n',
>> > "VolumeRebaseFailed: Volume rebase failed: Requested operation is not
>> > valid: pivot of disk 'vda' requires an active copy job\n"]:
>> > VolumeAttachmentNotFound: Volume attachment
>> > 2cd820e0-85e8-498d-a62a-800260d0cf31 could not be found
>> >
>> >
>> > Must I try to change some parameters in nova.conf on compute nodes about
>> > volume attachment ?
>> >
>> > Thanks
>> > Ignazio
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220307/55d44269/attachment.htm>

From franck.vedel at univ-grenoble-alpes.fr  Mon Mar  7 16:58:48 2022
From: franck.vedel at univ-grenoble-alpes.fr (Franck VEDEL)
Date: Mon, 7 Mar 2022 17:58:48 +0100
Subject: [kolla-ansible][wallaby][centos][horizon-dashboard] Changing
 logo.svg
In-Reply-To: <CAFHSqWrDReFiwzA_p5jv9MhKZV8RE5A2o3SPvt8mLHQouRopZA@mail.gmail.com>
References: <60FB6A20-20EA-4CF7-A962-3CF8AA9C88AA@univ-grenoble-alpes.fr>
 <CAFHSqWrDReFiwzA_p5jv9MhKZV8RE5A2o3SPvt8mLHQouRopZA@mail.gmail.com>
Message-ID: <E169B443-086F-43B9-BB45-DDCAB9505850@univ-grenoble-alpes.fr>

i Mark,
thank?s for your help.

I don't know if I'm doing things right, but with the help of Vishal Manchanda, I managed to modify the logo files (and favicon.ico), to place them in the 2 horizon containers (2 servers have the role), then to using the "manage.py" command to use these new logos. I had to do it in both containers, which I find weird but it works and it's easy and fast with this method.
Thanks again


Franck


> Le 7 mars 2022 ? 09:56, Mark Goddard <mark at stackhpc.com> a ?crit :
> 
> Hi Franck,
> 
> Are you sure you're using the new image? If you don't change the tag,
> you'll need to explicitly pull the image from your registry.
> 
> Mark
> 
> On Fri, 4 Mar 2022 at 17:14, Franck VEDEL
> <franck.vedel at univ-grenoble-alpes.fr> wrote:
>> 
>> Hello,
>> I come back to ask for some help with a new problem on my Openstack platform. For once, it's a small problem.
>> I take this opportunity to thank those who helped me solve my problem which was the following: the instances were not created regularly on the 3 nova servers. Nova-scheduler was malfunctioning. I fixed the problem by setting build_failure_weight_multiplier=0
>> Since then, in DEBUG mode, we can clearly see the calculation of the weight and the distribution of the instances. It's beautiful.
>> 
>> My new problem is: I'm using kolla-ansible, centos (stream) and Wallaby.
>> In the directory /usr/local/lib/python3.6/site-packages/openstack_dashboard/static/dashboard/img/   I modified the 3 files logo.svg, logo-splash.svg, favicon.ico.
>> 
>> I thought doing a "kolla-ansible -i multinode reconfigure horizon" would update the logos and favicon.ico....but no, it does nothing.
>> How do I change these logos with kolla-ansible? Is it difficult?
>> 
>> thank you in advance
>> 
>> 
>> Franck VEDEL
>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220307/f8ec6608/attachment.htm>

From haleyb.dev at gmail.com  Mon Mar  7 17:02:55 2022
From: haleyb.dev at gmail.com (Brian Haley)
Date: Mon, 7 Mar 2022 12:02:55 -0500
Subject: [neutron] Bug deputy report for week of February 28th
Message-ID: <43f2a1b5-e525-1e37-24c2-2529112fdb12@gmail.com>

Hi,

I was Neutron bug deputy last week. Below is a short summary about the 
reported bugs.

-Brian


Critical bugs
-------------

* None

High bugs
---------

* https://bugs.launchpad.net/neutron/+bug/1962594
   - [FT] Test class "TestIsSessionActiveMySQL" failing randomly
   - https://review.opendev.org/c/openstack/neutron/+/831409

* https://bugs.launchpad.net/neutron/+bug/1962589
   - [FT] Method "_router_lifecycle" failing when checking if router is 
"primary"
   - Needs owner

* https://bugs.launchpad.net/neutron/+bug/1962854
   - Fullstack connectivity issues in tests
   - Slawek assigned to himself

Medium bugs
-----------

* https://bugs.launchpad.net/neutron/+bug/1962465
   - [L3][QoS] FIP QoS extension cannot handle duplicated FIP addresses
   - https://review.opendev.org/c/openstack/neutron/+/831238

* https://bugs.launchpad.net/neutron/+bug/1962714
   - disable ipv6 breaks several unit tests
   - https://review.opendev.org/c/openstack/neutron/+/831490

* https://bugs.launchpad.net/neutron/+bug/1962608
   - [FT] Test "test_show" failing randomly
   - Needs owner

* https://bugs.launchpad.net/neutron/+bug/1962713
   - Race between loadbalancer creation and FIP association with 
ovn-octavia provider
   - stable/train issue only, related to 
https://review.opendev.org/c/openstack/ovn-octavia-provider/+/718203/

* https://bugs.launchpad.net/neutron/+bug/1962844
   - [SR-IOV] QoS extension doesn't set max-tx-rate and min-tx-rate in 
the same port
   - https://review.opendev.org/c/openstack/neutron/+/831830

Low bugs
--------

* https://bugs.launchpad.net/neutron/+bug/1962497
   - Open vSwitch: High availability using DVR in Neutron doesn't 
reflect environments using ovs firewall driver w/out qbr

Misc bugs
---------

* None

Wishlist bugs
-------------

* https://bugs.launchpad.net/neutron/+bug/1962821
   - Support binding floating ip to smart-nic port in the dvr mode.
   - https://review.opendev.org/c/openstack/neutron-lib/+/831639
   - Needs further review of change


From gmann at ghanshyammann.com  Mon Mar  7 19:47:13 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 07 Mar 2022 13:47:13 -0600
Subject: [all][tc] What's happening in Technical Committee: summary Mar 4th,
 21: Reading: 10 min
Message-ID: <17f65ebe883.10b335c29384370.6510340336122574804@ghanshyammann.com>

Hello Everyone,

Here is this week's summary of the Technical Committee activities. Sorry, I missed to click send button on Friday and it stuck in my draft.

1. TC Meetings:
============
* We had this week's meeting on Mar 3rd. Most of the meeting discussions are summarized below (Completed
or in-progress activities section).
This was a video call and recording are available @ https://www.youtube.com/watch?v=AAVSHvguxWU
Meeting summary logs are available @https://meetings.opendev.org/meetings/tc/2022/tc.2022-03-03-15.04.log.html

* As we have new TC members, we checked on the weekly meeting time as per new members availability and decided
to keep the same time (considering the daylight saving change in coming weeks)

* Next week's meeting is on Mar 10th Thursday 15:00 UTC, feel free to add the topic on
the agenda[1] by Mar 9th.


2. What we completed this week:
=========================
TC resolution on release cadence adjustment [2]
---------------------------------------------------------
TC has merged the resolution on release cadence which is discussed in this[3] ML thread.
Dan is planning to update the required documentation and also the communication. We will
talk about the details and next things to do (testing, document updates etc) in PTG also. But
you can read the resolution to know the details.

Defined Zed cycle testing runtime[4]
-------------------------------------------
Testing runtime for Zed cycle is defined. Zuul job template is also merged[5]. Below are the changes
for quick ref:
Dropped:
- CentOS Stream 8
- Python 3.6
Updated:
- Testing py3.8 and py3.9 as voting. (we will add py3.10 as non-voting[6])
- nodejs14 -> nodejs16


3. Activities In progress:
==================
TC Tracker for Yoga cycle
------------------------------
* This etherpad includes the Yoga cycle targets/working items for TC[7].
2 out of 9 items are completed and many are in progress.

Open Reviews
-----------------
* Eight open reviews for ongoing activities[8].

OpenStack news in OIF newsletter
-----------------------------------------
This is newsletter week and I have added a few items for the OpenStack Community news[9]. Please note,
this is not limited to TC only instead if you would like to communicate some news from your project, feel
fee to add in etherpad. 

Zed cycle Leaderless projects
----------------------------------
Out of 17, we have leaders for 15 projects. I have started the PTL appointments for
those 15 projects[10]. We are left with two projects Adjutant and Trove to identify the
leaders[11], if you would like to maintain either of them, please reply here or ping is on
#openstack-tc. Slawek will also start the separate email to call for these projects leaders.

PTG Preparation
--------------------
I have started the etherpad for TC PTG[12] preparation as well as doodle poll to select the
slots[13].
Also, selected the TC+Community Leaders sessions for Monday 14-16UTC[14].

Release identification and release name
-----------------------------------------------
The proposal is under review and updates [15].

Dropping tags framework
------------------------------
part1 of this is merged[16], part-2 of updating release script and other tags
migration is under-progress.

TC position on release cadence
-------------------------------------
TC resolution is merged and Dan will work on the next steps of documentation update
and communication part.

Fixing Zuul config error
----------------------------
Requesting projects with zuul config error to look into those and fix them which should
not take much time[17].

Project updates
-------------------
* Retire js-openstack-lib (waiting on Adjutant to have new PTL/maintainer) [18]


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[19].
2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [20]
3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel.


[1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting
[2] https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html
[3] http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025684.html
[4] https://governance.openstack.org/tc/reference/runtimes/zed.html
[5] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/831826
[6] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/831633
[7] https://etherpad.opendev.org/p/tc-yoga-tracker
[8] https://review.opendev.org/q/projects:openstack/governance+status:open
[9] https://etherpad.opendev.org/p/newsletter-openstack-news
[10] https://review.opendev.org/q/projects:openstack/governance+status:open+Appoint
[11] https://etherpad.opendev.org/p/zed-leaderless
[12] https://etherpad.opendev.org/p/tc-zed-ptg
[13] https://doodle.com/poll/gz4dy67vmew5wmn9 
[14] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027548.html
[15] https://review.opendev.org/c/openstack/governance/+/829563
[16] https://review.opendev.org/c/openstack/governance/+/822900
[17] https://etherpad.opendev.org/p/zuul-config-error-openstack
[18] https://review.opendev.org/c/openstack/governance/+/798540
[19] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[20] http://eavesdrop.openstack.org/#Technical_Committee_Meeting

-gmann
    
                    


From kennelson11 at gmail.com  Mon Mar  7 19:57:34 2022
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Mon, 7 Mar 2022 11:57:34 -0800
Subject: Reminder! PTG April 2022 Team Signup Deadline
Message-ID: <CAJ6yrQhTyxYO-VWOy4tyN6GjwTMrpJvh_tQZ0V=Jrq9osJntaQ@mail.gmail.com>

Hello Everyone,

Don't forget to sign your team up for the next Project Teams Gathering
(PTG), which will be held virtually from Monday, April 4 to Friday, April
8, 2022!

If you haven't already done so and your team is interested in
participating, please complete BOTH the survey[1] AND reserve time in the
ethercalc[2] by end of day March 11.

Then make sure to register[3] for the PTG because that's how you'll receive
event details, passwords, and other relevant information about the PTG.

Thanks!

-Kendall (diablo_rojo)

[1] Team Survey:
https://openinfrafoundation.formstack.com/forms/april2022_vptg_survey
[2] Ethercalc Signup: https://ethercalc.openstack.org/7yxdas7suqnd
[3] PTG Registration: https://openinfra-ptg.eventbrite.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220307/49df1753/attachment.htm>

From gmann at ghanshyammann.com  Mon Mar  7 20:15:57 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 07 Mar 2022 14:15:57 -0600
Subject: [all][tc] Technical Committee next weekly meeting on Mar 10th at
 1500 UTC
Message-ID: <17f660636b4.eeeb3593385325.4356497671912212953@ghanshyammann.com>


Hello Everyone,

Technical Committee's next weekly meeting is scheduled for Mar 10th at 1500 UTC.

If you would like to add topics for discussion, please add them to the below wiki page by
Wednesday, Mar 9th , at 2100 UTC.

https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

-gmann


From gmann at ghanshyammann.com  Mon Mar  7 21:05:00 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 07 Mar 2022 15:05:00 -0600
Subject: [all][tc] Zed TC-PTG Planning
In-Reply-To: <17f22bcc50d.dc214987454540.4578480937628902952@ghanshyammann.com>
References: <17f22bcc50d.dc214987454540.4578480937628902952@ghanshyammann.com>
Message-ID: <17f66331e29.fda178e1386814.8033979575523031096@ghanshyammann.com>

 ---- On Tue, 22 Feb 2022 12:41:10 -0600 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > Hello Everyone,
 > 
 > As you already know that the Zed cycle virtual PTG will be held between 4th - 8th April[1].
 > 
 > I have started the preparation for the Technical Committee PTG sessions. Please do the following:
 > 
 > 1. Fill the below doodle poll as per your availability. Please fill it in soon as the deadline to book the slot is March 11th.
 > 
 > - https://doodle.com/poll/gz4dy67vmew5wmn9 
 > 
 > 2. Add the topics you would like to discuss to the below etherpad.
 > 
 > - https://etherpad.opendev.org/p/tc-zed-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.

As discussed on IRC, I have booked below slots for TC discussion:

* Monday 14 - 16 UTC (TC + PTLfor 2 hrs )
* Thursday 13-17 UTC (TC discussion for 4 hrs)
* Friday 13-17 UTC (TC discussion for 4 hrs )

-gmann

 > 
 > [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027051.html
 > 
 > -gmann
 >     
 > 
 > 


From pramchan at yahoo.com  Mon Mar  7 21:35:19 2022
From: pramchan at yahoo.com (prakash RAMCHANDRAN)
Date: Mon, 7 Mar 2022 21:35:19 +0000 (UTC)
Subject: Mistral: Questions on Mistral  stability & Its scaling
References: <1551442100.482589.1646688919663.ref@mail.yahoo.com>
Message-ID: <1551442100.482589.1646688919663@mail.yahoo.com>

Hi all,
I am trying to find out from PTL or anyone using versions of? stable Mistral beyond Train upto Yoga about their use cases for Managing Workflows, Tasks and Action-Executions etc. Are there any scalability and reliability issues in general.??
Would some one like to present if we organize a PTG session? We can also consider it as part of Tacker if they still use it for Workflow scheduling.
Let me hear your practical experience and recommended bestpratices to use Mistral.Is there any new features planned in Z-Relase
ThanksR.PrakasheOTF

Sent from Yahoo Mail on Android
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220307/f7bf20df/attachment.htm>

From laurentfdumont at gmail.com  Tue Mar  8 00:58:37 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Mon, 7 Mar 2022 19:58:37 -0500
Subject: Use idle backup servers
In-Reply-To: <CAEc0zit5bT=_z=hyOm8wgLD4TKrJVzs0TEK+45+485yWeNKrTA@mail.gmail.com>
References: <CAEc0zit5bT=_z=hyOm8wgLD4TKrJVzs0TEK+45+485yWeNKrTA@mail.gmail.com>
Message-ID: <CAOAKi8wRsQv3HDF9eRLn5k0RapZWwH_2RT8Dwv4g8GNd=mrTBQ@mail.gmail.com>

Yes

   - keepalived for the VIP failover
   - haproxy for the load balancer portion

Openstack works the same way. Depending on the deployment scenario, some
services are active on all three and others are active on only one
controller. They will dynamically failover between controllers if one of
them stops working.

On Mon, Mar 7, 2022 at 6:09 AM A Monster <amonster369 at gmail.com> wrote:

> Is there a way to use multiple servers as backup  but these servers stay
> idle until the main server fails
> for example two controller servers but only one of them which is running
> services, and in case this main server fails, the cloud switches to the
> other server.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220307/70bfbfeb/attachment.htm>

From satish.txt at gmail.com  Tue Mar  8 05:06:03 2022
From: satish.txt at gmail.com (Satish Patel)
Date: Tue, 8 Mar 2022 00:06:03 -0500
Subject: [kolla-ansible][manila] mount.glusterfs is not installed
Message-ID: <CAPgF-fotat45LDZ=eoq62LBBOTAJ_cq5R8=zL5+4SJAoTJGvgA@mail.gmail.com>

Folks,

I am trying to configure Manila with kolla-ansible using glusterfs with
ganesha-nfs server, I am running glusterfs and ganesha-nfs on the
same server and getting the following error messages in manila-share.log
service file. What am I missing here?

2022-03-08 04:39:32.940 17 INFO paramiko.transport [-] Connected (version
2.0, client OpenSSH_8.2p1)
2022-03-08 04:39:32.982 17 INFO paramiko.transport [-] Authentication
(password) successful!
2022-03-08 04:39:33.815 17 ERROR manila.share.manager
[req-c2925794-b62a-47b9-8f44-90939d417329 - - - - -] Error encountered
during initialization of driver GlusterfsShareDriver at kolla@ganesha:
manila.exception.GlusterfsException: mount.glusterfs is not installed.
2022-03-08 04:39:33.815 17 ERROR manila.share.manager Traceback (most
recent call last):
2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File
"/usr/lib/python3/dist-packages/manila/share/drivers/glusterfs/layout.py",
line 216, in _check_mount_glusterfs
2022-03-08 04:39:33.815 17 ERROR manila.share.manager
self.driver._execute('mount.glusterfs', check_exit_code=False)
2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File
"/usr/lib/python3/dist-packages/manila/utils.py", line 101, in execute
2022-03-08 04:39:33.815 17 ERROR manila.share.manager     return
processutils.execute(*cmd, **kwargs)
2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File
"/usr/lib/python3/dist-packages/oslo_concurrency/processutils.py", line
395, in execute
2022-03-08 04:39:33.815 17 ERROR manila.share.manager     obj =
subprocess.Popen(cmd,
2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File
"/usr/lib/python3/dist-packages/eventlet/green/subprocess.py", line 58, in
__init__
2022-03-08 04:39:33.815 17 ERROR manila.share.manager
subprocess_orig.Popen.__init__(self, args, 0, *argss, **kwds)
2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File
"/usr/lib/python3.8/subprocess.py", line 858, in __init__
2022-03-08 04:39:33.815 17 ERROR manila.share.manager
self._execute_child(args, executable, preexec_fn, close_fds,
2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File
"/usr/lib/python3.8/subprocess.py", line 1704, in _execute_child
2022-03-08 04:39:33.815 17 ERROR manila.share.manager     raise
child_exception_type(errno_num, err_msg, err_filename)
2022-03-08 04:39:33.815 17 ERROR manila.share.manager FileNotFoundError:
[Errno 2] No such file or directory: 'mount.glusterfs'


My manila Config

[DEFAULT]
enabled_share_backends=ganesha
enabled_share_protocols = NFS,CIFS,GLUSTERFS

[ganesha]
share_backend_name = ganesha
glusterfs_nfs_server_type = Ganesha
glusterfs_target=root at 10.30.1.206:/myshare/brick1/brick
glusterfs_server_password=XXXXXXXXXXX
share_driver = manila.share.drivers.glusterfs.GlusterfsShareDriver
ganesha_service_name = nfs-ganesha
driver_handles_share_servers = False
glusterfs_ganesha_server_ip=10.30.1.206
glusterfs_ganesha_server_username=root
glusterfs_ganesha_server_password=XXXXXXXXXX


My share

root at kolla-gluster:~# showmount -e localhost
Export list for localhost:
/myshare/brick1/brick (everyone)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/73d642fd/attachment-0001.htm>

From eblock at nde.ag  Tue Mar  8 07:56:31 2022
From: eblock at nde.ag (Eugen Block)
Date: Tue, 08 Mar 2022 07:56:31 +0000
Subject: [openstack][queens][cinder] volume retype errors
In-Reply-To: <CAB7j8cVdqgQWkfn=y6MG5jeR1tWfbmq=BVv=cPBPw4OUCbuuKA@mail.gmail.com>
References: <CAB7j8cWCrGLoNQwHw_ekM1D0LBkToLhdgwEG4eOuJTLJpTr58g@mail.gmail.com>
 <20220307162303.Horde.VExGf9Y0xDD_Kjz3lCeaSje@webmail.nde.ag>
 <CAB7j8cUwdWYV2RUdkDopOzh9yivGhMta0A+1B2Ydwdr9rmTtzA@mail.gmail.com>
 <CAB7j8cVdqgQWkfn=y6MG5jeR1tWfbmq=BVv=cPBPw4OUCbuuKA@mail.gmail.com>
Message-ID: <20220308075631.Horde.OP1HVo5W6KLLG7kickvvxO0@webmail.nde.ag>

Unfortunately, I'm not familiar with NetApp so I can just ask for more  
details, hopefully other users can help you. What exactly do you mean  
that it fails only sometimes? The stack trace you provided shows the  
attempt to retype a swap volume, is it always a swap volume when it  
fails or are other volumes affected, too?


Zitat von Ignazio Cassano <ignaziocassano at gmail.com>:

> Hello again I found the error but it is in cinder api log:
> 2022-03-07 15:42:57.330 156916 INFO cinder.api.openstack.wsgi
> [req-01eb2613-4aad-4809-ac91-037de3148fbb 5134ed3b93284af5ba2f05d7361edf53
> 0e760ccde5d24af5a571de40220fbf80 - default default]
> http://10.138.144.16:8776/v3/0e760ccde5d24af5a571de40220fbf80/attachments/04ae01f6-e164-40cb-8d31-63f78e69c8db
> returned with HTTP 404
>
> and in nova compute log:
> 15:42:57.502 280431 ERROR oslo_messaging.rpc.server
> [req-dfeac1f0-870b-4aef-af40-cda52f4552e0 5134ed3b93284af5ba2f05d7361edf53
> 0e760ccde5d24af5a571de40220fbf80 - default default] Exception during
> message handling: VolumeAttachmentNotFound: Volume attachment
> 04ae01f6-e164-40cb-8d31-63f78e69c8db could not be found.
>
> Il giorno lun 7 mar 2022 alle ore 17:44 Ignazio Cassano <
> ignaziocassano at gmail.com> ha scritto:
>
>> Hello, volume.log does not report errors:
>> 2022-03-07 15:41:44.435 159559 INFO cinder.volume.manager
>> [req-68444973-24eb-4b21-95b2-626c9b2e2aa0 5134ed3b93284af5ba2f05d7361edf53
>> 0e760ccde5d24af5a571de40220fbf80 - default default] Created volume
>> successfully.
>> 2022-03-07 15:41:45.358 159099 INFO cinder.volume.manager
>> [req-68444973-24eb-4b21-95b2-626c9b2e2aa0 5134ed3b93284af5ba2f05d7361edf53
>> 0e760ccde5d24af5a571de40220fbf80 - default default] Migrate volume
>> completed successfully.
>> 2022-03-07 15:41:48.970 159559 INFO cinder.volume.manager
>> [req-72ca9242-25e9-4bb0-9bd6-9857f42805ee 5134ed3b93284af5ba2f05d7361edf53
>> 0e760ccde5d24af5a571de40220fbf80 - default default] attachment_update
>> complete
>>
>> Il giorno lun 7 mar 2022 alle ore 17:25 Eugen Block <eblock at nde.ag> ha
>> scritto:
>>
>>> Hi,
>>>
>>> since you're retyping a volume, what do the cinder logs reveal?
>>>
>>>
>>> Zitat von Ignazio Cassano <ignaziocassano at gmail.com>:
>>>
>>> > Hello, sometimes the volume retype from a netapp nfs storage to another
>>> > netapp nfs storage does not work.
>>> > I do not know the reason but I think something is going wrong in nova:
>>> >
>>> > /var/log/nova/nova-compute.log:2022-02-02 14:23:39.992 194288 ERROR root
>>> > [req-ebbf749f-359f-4282-94c5-0913cffe97a3
>>> 66adb965bef64eaaab2af93ade87e2ca
>>> > 68feefdf7c5847388534e9214dc13366 - default default] Original exception
>>> > being dropped: ['Traceback (most recent call last):\n', '  File
>>> > "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 5655,
>>> in
>>> > _swap_volume\n    mountpoint, resize_to)\n', '  File
>>> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
>>> 1647,
>>> > in swap_volume\n    self._disconnect_volume(context,
>>> new_connection_info,
>>> > instance)\n', '  File
>>> > "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in
>>> > __exit__\n    self.force_reraise()\n', '  File
>>> > "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
>>> > force_reraise\n    six.reraise(self.type_, self.value, self.tb)\n', '
>>> File
>>> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
>>> 1644,
>>> > in swap_volume\n    self._swap_volume(guest, disk_dev, conf,
>>> resize_to)\n',
>>> > '  File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
>>> > line 1593, in _swap_volume\n    raise
>>> > exception.VolumeRebaseFailed(reason=six.text_type(exc))\n',
>>> > "VolumeRebaseFailed: Volume rebase failed: Requested operation is not
>>> > valid: pivot of disk 'vda' requires an active copy job\n"]:
>>> > VolumeAttachmentNotFound: Volume attachment
>>> > 2cd820e0-85e8-498d-a62a-800260d0cf31 could not be found
>>> >
>>> >
>>> > Must I try to change some parameters in nova.conf on compute nodes about
>>> > volume attachment ?
>>> >
>>> > Thanks
>>> > Ignazio
>>>
>>>
>>>
>>>
>>>





From skaplons at redhat.com  Tue Mar  8 07:59:49 2022
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Tue, 08 Mar 2022 08:59:49 +0100
Subject: IPv6 deployment on OpenStack
In-Reply-To: <8195F0AD-5FE8-432C-A1A7-8EB287B13C64@viarezo.fr>
References: <B30F2915-674E-4029-9F1A-D25589FFF056@viarezo.fr>
 <14575046.tv2OnDr8pf@p1> <8195F0AD-5FE8-432C-A1A7-8EB287B13C64@viarezo.fr>
Message-ID: <2536429.7s5MMGUR32@p1>

Hi,

On poniedzia?ek, 7 marca 2022 10:36:30 CET Marc-Antoine Godde wrote:
> Hello,
> 
> Thanks for your answer.
> 
> If I?m correct, we can just use a virtual router with SLAAC since RADVD can deal with RS and emit RA (with support for RFC6106), right ? 

Yes, virtual router created in the Neutron is enough there. It will spawn radvd in the qrouter namespace and will send RA to the Vms.
Please note that Neutron don't supports privacy extension [1] so You will need to make sure that it's disabled it on Your vms.

> More generally, aren?t we suppose to have a virtual router every time, even in DHCPv6 (stateless and statefull), to answer RS ? I have to admit that I?m not very familiar at the moment with the implementations of RFCs in OpenStack.
> 
> Currently, we prefer the idea of adding IPv6 through SLAAC to have a uniform network. If we do so, we?d like to avoid sending RA from our physical router to limit its load. Yet, we do not any other arguments to support this choice.
> Do you have any recommendations on what to do in latest versions of OpenStack ? What is usually done ?

TBH I don't have such experience. That's more question to operators of OpenStack.

> 
> Thanks,
> Marc-Antoine
> 
> > Le 7 mars 2022 ? 09:12, Slawek Kaplonski <skaplons at redhat.com> a ?crit :
> > 
> > Hi,
> > 
> > On poniedzia?ek, 7 marca 2022 02:36:24 CET Marc-Antoine Godde wrote:
> >> Hello.
> >> 
> >> We are progressively adding support for IPv6 in my company. We decided to use SLAAC only for laptops, phones, ? since DHCPv6 isn?t supported on Android. RDNSS support will also increase. We are now planning our deployment on OpenStack. We already know that we'll rely only on neutron but we are not yet fixed between DHCPv6 and SLAAC ? Do you have any arguments for one these for VMs ?
> >> 
> >> Thanks,
> >> Marc-Antoine.
> >> 
> > 
> > With SLAAC You need to have Your network connected to the router in Neutron and You can only configure IP address on the VM. With DHCPv6 You can configure other things, like some static-routes, etc. 
> > Neutron supports DHCPv6 in the stateful and stateless variants. With stateless, You are using RA for address configuration and DHCP server for other configation. Please see [1] for more details.
> > 
> > [1] https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports
> > 
> 
> 

[1] https://datatracker.ietf.org/doc/html/rfc4941

-- 
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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/1a55e425/attachment.sig>

From jonathan.rosser at rd.bbc.co.uk  Tue Mar  8 09:11:49 2022
From: jonathan.rosser at rd.bbc.co.uk (Jonathan Rosser)
Date: Tue, 8 Mar 2022 09:11:49 +0000
Subject: [openstack-ansible] bootstap-aio.sh is failing with error
 :jinja2.exceptions.TemplateRuntimeError: No filter named 'ipaddr' found
In-Reply-To: <PAYP264MB4256AC4659CBA76AEE1BD650C4089@PAYP264MB4256.FRAP264.PROD.OUTLOOK.COM>
References: <PAYP264MB4256AC4659CBA76AEE1BD650C4089@PAYP264MB4256.FRAP264.PROD.OUTLOOK.COM>
Message-ID: <a11374be-af45-3d65-2383-129238c73d5c@rd.bbc.co.uk>

Hi Andrew,

Unfortunately it seems that the splitting out of ansible components into 
collections opens us up to another set of external moving parts which 
can break the deployment. Although we specify the precise version of 
ansible and highest level collections (see 
ansible-collection-requirements.yml) that we use on each branch of 
openstack-ansible - this has not covered second-level dependencies such 
as the one we encounter here.

There are already patches to fix this on all of our branches 
https://review.opendev.org/q/topic:ipaddr_filter

You can run the latest stable branch code today including that fix by 
checking out the stable/xena branch rather than the most recent tag.

If you are still stuck please join the #openstack-ansible IRC channel 
where there should be some real time help available.

Jonathan.

On 07/03/2022 14:53, west, andrew wrote:
>
> Am trying to install openstack-ansible AIO (24.0.0.0rc1) on a recent 
> ?ubuntu focal (20.04) cloud image VM
>
> kernel 5.4.0-99-generic
>
> ansible core 2.12.2
>
> jinja 3.0.3
>
> python 3.8.10
>
> the bootstap-aio.sh script ?is failing with error
>
> jinja2.exceptions.TemplateRuntimeError: No filter named 'ipaddr' found
>
> (I see the ipaddr filter ?moved (big changes separating modules > 
> ansible2.10 I think)?? to the ansible.netcommon collection
>
> So following google:
>
> /ansible galaxy collection install ansible.netcommon /
>
> Also needs
>
> /pip install netaddr/
>
> //
>
> //
>
> However this still doesn?t solve it, add traceback to playbook:
>
> Seems some of core ansible_collections plugins need updating ?? 
> (sorry, I?m fairly new to ansible)
>
> <localhost> EXEC /bin/sh -c 'echo ~root && sleep 0'
>
> <localhost> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo 
> /root/.ansible/tmp `"&& mkdir "` echo 
> /root/.ansible/tmp/ansible-tmp-1646414479.2525613-38683-223155148734113 
> `" && echo ansible-tmp-1646414479.2525613-38683-223155148734113="` 
> echo 
> /root/.ansible/tmp/ansible-tmp-1646414479.2525613-38683-223155148734113 
> `" ) && sleep 0'
>
> redirecting filter ansible.builtin.ipaddr to ansible.netcommon.ipaddr
>
> redirecting filter ansible.builtin.ipaddr to ansible.netcommon.ipaddr
>
> redirecting filter ansible.builtin.ipaddr to ansible.netcommon.ipaddr
>
> <localhost> EXEC /bin/sh -c 'rm -f -r 
> /root/.ansible/tmp/ansible-tmp-1646414479.2525613-38683-223155148734113/ 
> > /dev/null 2>&1 && sleep 0'
>
> The full traceback is:
>
> Traceback (most recent call last):
>
> ? File 
> "/opt/ansible-runtime/lib/python3.8/site-packages/ansible/executor/task_executor.py", 
> line 119, in run
>
> ??? item_results = self._run_loop(items)
>
> ? File 
> "/opt/ansible-runtime/lib/python3.8/site-packages/ansible/executor/task_executor.py", 
> line 354, in _run_loop
>
> ??? res = self._execute(variables=task_vars)
>
> ? File 
> "/opt/ansible-runtime/lib/python3.8/site-packages/ansible/executor/task_executor.py", 
> line 589, in _execute
>
> ??? result = self._handler.run(task_vars=variables)
>
> ? File 
> "/etc/ansible/ansible_collections/openstack/config_template/plugins/action/config_template.py", 
> line 869, in run
>
> ??? resultant = self._check_templar(data=template_data)
>
> ? File 
> "/etc/ansible/ansible_collections/openstack/config_template/plugins/action/config_template.py", 
> line 768, in _check_templar
>
> ??? return self._templar.template(
>
> ? File 
> "/opt/ansible-runtime/lib/python3.8/site-packages/ansible/template/__init__.py", 
> line 869, in template
>
> ??? result = self.do_template(
>
> ? File 
> "/opt/ansible-runtime/lib/python3.8/site-packages/ansible/template/__init__.py", 
> line 1139, in do_template
>
> ??? res = j2_concat(rf)
>
> ? File "<template>", line 111, in root
>
> ? File "<template>", line 30, in t_3
>
> *jinja2.exceptions.TemplateRuntimeError: No filter named 'ipaddr' found*.
>
> fatal: [localhost]: FAILED! => {
>
> ??? "msg": "Unexpected failure during module execution.",
>
> ??? "stdout": ""
>
> }
>
> RUNNING HANDLER [systemd_networkd : Restart networkd] 
> *****************************************************************************************************************
>
> task path: /etc/ansible/roles/systemd_networkd/handlers/main.yml:16
>
> Read vars_file '{{ playbook_dir 
> }}/../playbooks/defaults/repo_packages/openstack_services.yml'
>
> <localhost> ESTABLISH LOCAL CONNECTION FOR USER: root
>
> <localhost> EXEC /bin/sh -c 'echo ~root && sleep 0'
>
> <localhost> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo 
> /root/.ansible/tmp `"&& mkdir "` echo 
> /root/.ansible/tmp/ansible-tmp-1646414479.331306-38764-149355553789280 
> `" && echo ansible-tmp-1646414479.331306-38764-149355553789280="` echo 
> /root/.ansible/tmp/ansible-tmp-1646414479.331306-38764-149355553789280 
> `" ) && sleep 0'
>
> Using module file 
> /opt/ansible-runtime/lib/python3.8/site-packages/ansible/modules/systemd.py
>
> <localhost> PUT 
> /root/.ansible/tmp/ansible-local-36177dradb42n/tmpeyfb1i4v TO 
> /root/.ansible/tmp/ansible-tmp-1646414479.331306-38764-149355553789280/AnsiballZ_systemd.py
>
> <localhost> PUT 
> /root/.ansible/tmp/ansible-local-36177dradb42n/tmpdkb43zb8 TO 
> /root/.ansible/tmp/ansible-tmp-1646414479.331306-38764-149355553789280/async_wrapper.py
>
> <localhost> EXEC /bin/sh -c 'chmod u+x 
> /root/.ansible/tmp/ansible-tmp-1646414479.331306-38764-149355553789280/ 
> /root/.ansible/tmp/ansible-tmp-1646414479.331306-38764-149355553789280/AnsiballZ_systemd.py 
> /root/.ansible/tmp/ansible-tmp-1646414479.331306-38764-149355553789280/async_wrapper.py 
> && sleep 0'
>
> <localhost> EXEC /bin/sh -c 
> 'ANSIBLE_ASYNC_DIR='"'"'~/.ansible_async'"'"' /usr/bin/python3 
> /root/.ansible/tmp/ansible-tmp-1646414479.331306-38764-149355553789280/async_wrapper.py 
> 6737658312 45 
> /root/.ansible/tmp/ansible-tmp-1646414479.331306-38764-149355553789280/AnsiballZ_systemd.py 
> _ && sleep 0'
>
> changed: [localhost] => {
>
> "ansible_job_id": "6737658312.38783",
>
> ??? "changed": true,
>
> ??? "finished": 0,
>
> "results_file": "/root/.ansible_async/6737658312.38783",
>
> ??? "started": 1
>
> }
>
> RUNNING HANDLER [systemd_networkd : (RE)Gather facts post setup] 
> ******************************************************************************************************
>
> task path: /etc/ansible/roles/systemd_networkd/handlers/main.yml:29
>
> Read vars_file '{{ playbook_dir 
> }}/../playbooks/defaults/repo_packages/openstack_services.yml'
>
> Using module file 
> /opt/ansible-runtime/lib/python3.8/site-packages/ansible/modules/setup.py
>
> Pipelining is enabled.
>
> <localhost> ESTABLISH LOCAL CONNECTION FOR USER: root
>
> <localhost> EXEC /bin/sh -c '/usr/bin/python3 && sleep 0'
>
> ok: [localhost]
>
> PLAY RECAP 
> ************************************************************************************************************************************************************
>
> localhost ????????????????: ok=105 changed=7??? unreachable=0 failed=1 
> skipped=26 rescued=0 ignored=0
>
> thanks for any help
>
> ------------------------------------------------------------------------
> ?This e-mail and any accompanying attachments are confidential. The 
> information is intended solely for the use of the individual to whom 
> it is addressed. Any review, disclosure, copying, distribution, or use 
> of the email by others is strictly prohibited. If you are not the 
> intended recipient, you must not review, disclose, copy, distribute or 
> use this e-mail; please delete it from your system and notify the 
> sender immediately.? 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/d6b502bb/attachment-0001.htm>

From ignaziocassano at gmail.com  Tue Mar  8 09:40:54 2022
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Tue, 8 Mar 2022 10:40:54 +0100
Subject: [openstack][queens][cinder] volume retype errors
In-Reply-To: <20220308075631.Horde.OP1HVo5W6KLLG7kickvvxO0@webmail.nde.ag>
References: <CAB7j8cWCrGLoNQwHw_ekM1D0LBkToLhdgwEG4eOuJTLJpTr58g@mail.gmail.com>
 <20220307162303.Horde.VExGf9Y0xDD_Kjz3lCeaSje@webmail.nde.ag>
 <CAB7j8cUwdWYV2RUdkDopOzh9yivGhMta0A+1B2Ydwdr9rmTtzA@mail.gmail.com>
 <CAB7j8cVdqgQWkfn=y6MG5jeR1tWfbmq=BVv=cPBPw4OUCbuuKA@mail.gmail.com>
 <20220308075631.Horde.OP1HVo5W6KLLG7kickvvxO0@webmail.nde.ag>
Message-ID: <CAB7j8cWY=nJiH4As7OZCac3QGDfH_17dK1mtyGwv9wynxBaRQw@mail.gmail.com>

Hello, other volumes are not affected
Ignazio

Il giorno mar 8 mar 2022 alle ore 08:59 Eugen Block <eblock at nde.ag> ha
scritto:

> Unfortunately, I'm not familiar with NetApp so I can just ask for more
> details, hopefully other users can help you. What exactly do you mean
> that it fails only sometimes? The stack trace you provided shows the
> attempt to retype a swap volume, is it always a swap volume when it
> fails or are other volumes affected, too?
>
>
> Zitat von Ignazio Cassano <ignaziocassano at gmail.com>:
>
> > Hello again I found the error but it is in cinder api log:
> > 2022-03-07 15:42:57.330 156916 INFO cinder.api.openstack.wsgi
> > [req-01eb2613-4aad-4809-ac91-037de3148fbb
> 5134ed3b93284af5ba2f05d7361edf53
> > 0e760ccde5d24af5a571de40220fbf80 - default default]
> >
> http://10.138.144.16:8776/v3/0e760ccde5d24af5a571de40220fbf80/attachments/04ae01f6-e164-40cb-8d31-63f78e69c8db
> > returned with HTTP 404
> >
> > and in nova compute log:
> > 15:42:57.502 280431 ERROR oslo_messaging.rpc.server
> > [req-dfeac1f0-870b-4aef-af40-cda52f4552e0
> 5134ed3b93284af5ba2f05d7361edf53
> > 0e760ccde5d24af5a571de40220fbf80 - default default] Exception during
> > message handling: VolumeAttachmentNotFound: Volume attachment
> > 04ae01f6-e164-40cb-8d31-63f78e69c8db could not be found.
> >
> > Il giorno lun 7 mar 2022 alle ore 17:44 Ignazio Cassano <
> > ignaziocassano at gmail.com> ha scritto:
> >
> >> Hello, volume.log does not report errors:
> >> 2022-03-07 15:41:44.435 159559 INFO cinder.volume.manager
> >> [req-68444973-24eb-4b21-95b2-626c9b2e2aa0
> 5134ed3b93284af5ba2f05d7361edf53
> >> 0e760ccde5d24af5a571de40220fbf80 - default default] Created volume
> >> successfully.
> >> 2022-03-07 15:41:45.358 159099 INFO cinder.volume.manager
> >> [req-68444973-24eb-4b21-95b2-626c9b2e2aa0
> 5134ed3b93284af5ba2f05d7361edf53
> >> 0e760ccde5d24af5a571de40220fbf80 - default default] Migrate volume
> >> completed successfully.
> >> 2022-03-07 15:41:48.970 159559 INFO cinder.volume.manager
> >> [req-72ca9242-25e9-4bb0-9bd6-9857f42805ee
> 5134ed3b93284af5ba2f05d7361edf53
> >> 0e760ccde5d24af5a571de40220fbf80 - default default] attachment_update
> >> complete
> >>
> >> Il giorno lun 7 mar 2022 alle ore 17:25 Eugen Block <eblock at nde.ag> ha
> >> scritto:
> >>
> >>> Hi,
> >>>
> >>> since you're retyping a volume, what do the cinder logs reveal?
> >>>
> >>>
> >>> Zitat von Ignazio Cassano <ignaziocassano at gmail.com>:
> >>>
> >>> > Hello, sometimes the volume retype from a netapp nfs storage to
> another
> >>> > netapp nfs storage does not work.
> >>> > I do not know the reason but I think something is going wrong in
> nova:
> >>> >
> >>> > /var/log/nova/nova-compute.log:2022-02-02 14:23:39.992 194288 ERROR
> root
> >>> > [req-ebbf749f-359f-4282-94c5-0913cffe97a3
> >>> 66adb965bef64eaaab2af93ade87e2ca
> >>> > 68feefdf7c5847388534e9214dc13366 - default default] Original
> exception
> >>> > being dropped: ['Traceback (most recent call last):\n', '  File
> >>> > "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line
> 5655,
> >>> in
> >>> > _swap_volume\n    mountpoint, resize_to)\n', '  File
> >>> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> >>> 1647,
> >>> > in swap_volume\n    self._disconnect_volume(context,
> >>> new_connection_info,
> >>> > instance)\n', '  File
> >>> > "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220,
> in
> >>> > __exit__\n    self.force_reraise()\n', '  File
> >>> > "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196,
> in
> >>> > force_reraise\n    six.reraise(self.type_, self.value, self.tb)\n', '
> >>> File
> >>> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> >>> 1644,
> >>> > in swap_volume\n    self._swap_volume(guest, disk_dev, conf,
> >>> resize_to)\n',
> >>> > '  File
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
> >>> > line 1593, in _swap_volume\n    raise
> >>> > exception.VolumeRebaseFailed(reason=six.text_type(exc))\n',
> >>> > "VolumeRebaseFailed: Volume rebase failed: Requested operation is not
> >>> > valid: pivot of disk 'vda' requires an active copy job\n"]:
> >>> > VolumeAttachmentNotFound: Volume attachment
> >>> > 2cd820e0-85e8-498d-a62a-800260d0cf31 could not be found
> >>> >
> >>> >
> >>> > Must I try to change some parameters in nova.conf on compute nodes
> about
> >>> > volume attachment ?
> >>> >
> >>> > Thanks
> >>> > Ignazio
> >>>
> >>>
> >>>
> >>>
> >>>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/1f28a170/attachment.htm>

From wmy1604it at 163.com  Tue Mar  8 01:57:34 2022
From: wmy1604it at 163.com (Engrave Powerful Fortune Sun)
Date: Tue, 8 Mar 2022 09:57:34 +0800 (GMT+08:00)
Subject: Kolla-Ansible Deploy
Message-ID: <64eebae6.6b98.17f673ef9af.Coremail.wmy1604it@163.com>

Kolla-Ansible Deploy ??


| |
Engrave Powerful Fortune Sun
|
|
wmy1604it at 163.com
|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/a2e2b227/attachment.htm>

From Molka.Gharbaoui at santannapisa.it  Tue Mar  8 14:56:29 2022
From: Molka.Gharbaoui at santannapisa.it (Molka Gharbaoui)
Date: Tue, 8 Mar 2022 14:56:29 +0000
Subject: R: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics
 using ceilometer and gnocchi
In-Reply-To: <VE1PR03MB5550C9EFAFA20EE8D9B3B05BEC069@VE1PR03MB5550.eurprd03.prod.outlook.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
 <VE1PR03MB55500139D4A8F6C4447C167FEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
 <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97radzOiX6vL64L-ug2+a7Y5B5x84soMJ=Dg=dBN7ON5wNrQ@mail.gmail.com>
 <VE1PR03MB555093FE01A603C3289B5BF5EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97rafnksd==DBiqnGDY3DtQcTZnGn+_KiyEB4tqLJ2hw-g8A@mail.gmail.com>
 <VE1PR03MB5550E8A87742A68E38EBDF9FEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97raeheZcfwfpNyFi83oEBP5iMgUr9UNTY38xFng25rnqLfA@mail.gmail.com>
 <VE1PR03MB5550C23A81F22EB55D95A00EEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97racCjO2CzMw+k7ow-2-UA0f9RDGKaMux1uYN5Kb2Td-VNA@mail.gmail.com>
 <AM6PR03MB5542A9478BA137A27F578382EC069@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <CAG97rae0UC1JqT-iT9cgpVKR_8L92_Cfj_Y=eZa3Ghb9Bpp_ig@mail.gmail.com>
 <VE1PR03MB5550C9EFAFA20EE8D9B3B05BEC069@VE1PR03MB5550.eurprd03.prod.outlook.com>
Message-ID: <VE1PR03MB5550EC67657B11B5354BC292EC099@VE1PR03MB5550.eurprd03.prod.outlook.com>

I left the instance running for more than 1 hour and now when I check the logs of "ceilometer-polling" I can see the following messages:

DEBUG ceilometer.compute.pollsters [-] 3ef0373a-558c-4818-b693-7536ee70d283/network.outgoing.bytes volume: 3608 _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108
DEBUG ceilometer.compute.pollsters [-] 3ef0373a-558c-4818-b693-7536ee70d283/network.outgoing.packets volume: 25 _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108
DEBUG ceilometer.compute.pollsters [-] 3ef0373a-558c-4818-b693-7536ee70d283/disk.device.write.requests volume: 4568 _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108

So I guess that Ceilometer is starting to poll some statistics.

The "gnocchi resource list" also now gives the following output:
ID                                                                   Type
3ef0373a-558c-4818-b693-7536ee70d283 | instance

However, the "gnocchi metric list" is still empty.

Looking in the logs of "ceilometer-agent-notification", I found the following error:
ERROR ceilometer.pipeline.sample [-] Pipeline meter_sink: Continue after error from publisher <ceilometer.publisher.gnocchi.GnocchiPublisher object at 0x7fc9800f9ee0>: gnocchiclient.exceptions.Conflict: <html>
 <head>
  <title>409 Conflict</title>
 </head>
 <body>
  <h1>409 Conflict</h1>
  There was a conflict when trying to complete your request.<br /><br />
Archive policy ceilometer-low already exists
 </body>
</html> (HTTP 409)

Do you know how to resolve this?

Thanks.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/be3cc5b4/attachment.htm>

From radoslaw.piliszek at gmail.com  Tue Mar  8 15:17:03 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Tue, 8 Mar 2022 16:17:03 +0100
Subject: [kolla-ansible][manila] mount.glusterfs is not installed
In-Reply-To: <CAPgF-fotat45LDZ=eoq62LBBOTAJ_cq5R8=zL5+4SJAoTJGvgA@mail.gmail.com>
References: <CAPgF-fotat45LDZ=eoq62LBBOTAJ_cq5R8=zL5+4SJAoTJGvgA@mail.gmail.com>
Message-ID: <CAKZ_x7_CPcbfVyOe=vBLORRZ_X0kV6uxtb4_Kt47=uhPDaYDFQ@mail.gmail.com>

As we have discussed on IRC - this is a discrepancy in Debuntu images.
I have reported the issue for you and will see to it getting fixed as
it's a simple and obvious bug. [1]

[1] https://bugs.launchpad.net/kolla/+bug/1964140

-yoctozepto

On Tue, 8 Mar 2022 at 06:07, Satish Patel <satish.txt at gmail.com> wrote:
>
> Folks,
>
> I am trying to configure Manila with kolla-ansible using glusterfs with ganesha-nfs server, I am running glusterfs and ganesha-nfs on the same server and getting the following error messages in manila-share.log service file. What am I missing here?
>
> 2022-03-08 04:39:32.940 17 INFO paramiko.transport [-] Connected (version 2.0, client OpenSSH_8.2p1)
> 2022-03-08 04:39:32.982 17 INFO paramiko.transport [-] Authentication (password) successful!
> 2022-03-08 04:39:33.815 17 ERROR manila.share.manager [req-c2925794-b62a-47b9-8f44-90939d417329 - - - - -] Error encountered during initialization of driver GlusterfsShareDriver at kolla@ganesha: manila.exception.GlusterfsException: mount.glusterfs is not installed.
> 2022-03-08 04:39:33.815 17 ERROR manila.share.manager Traceback (most recent call last):
> 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File "/usr/lib/python3/dist-packages/manila/share/drivers/glusterfs/layout.py", line 216, in _check_mount_glusterfs
> 2022-03-08 04:39:33.815 17 ERROR manila.share.manager     self.driver._execute('mount.glusterfs', check_exit_code=False)
> 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File "/usr/lib/python3/dist-packages/manila/utils.py", line 101, in execute
> 2022-03-08 04:39:33.815 17 ERROR manila.share.manager     return processutils.execute(*cmd, **kwargs)
> 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File "/usr/lib/python3/dist-packages/oslo_concurrency/processutils.py", line 395, in execute
> 2022-03-08 04:39:33.815 17 ERROR manila.share.manager     obj = subprocess.Popen(cmd,
> 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File "/usr/lib/python3/dist-packages/eventlet/green/subprocess.py", line 58, in __init__
> 2022-03-08 04:39:33.815 17 ERROR manila.share.manager     subprocess_orig.Popen.__init__(self, args, 0, *argss, **kwds)
> 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File "/usr/lib/python3.8/subprocess.py", line 858, in __init__
> 2022-03-08 04:39:33.815 17 ERROR manila.share.manager     self._execute_child(args, executable, preexec_fn, close_fds,
> 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File "/usr/lib/python3.8/subprocess.py", line 1704, in _execute_child
> 2022-03-08 04:39:33.815 17 ERROR manila.share.manager     raise child_exception_type(errno_num, err_msg, err_filename)
> 2022-03-08 04:39:33.815 17 ERROR manila.share.manager FileNotFoundError: [Errno 2] No such file or directory: 'mount.glusterfs'
>
>
> My manila Config
>
> [DEFAULT]
> enabled_share_backends=ganesha
> enabled_share_protocols = NFS,CIFS,GLUSTERFS
>
> [ganesha]
> share_backend_name = ganesha
> glusterfs_nfs_server_type = Ganesha
> glusterfs_target=root at 10.30.1.206:/myshare/brick1/brick
> glusterfs_server_password=XXXXXXXXXXX
> share_driver = manila.share.drivers.glusterfs.GlusterfsShareDriver
> ganesha_service_name = nfs-ganesha
> driver_handles_share_servers = False
> glusterfs_ganesha_server_ip=10.30.1.206
> glusterfs_ganesha_server_username=root
> glusterfs_ganesha_server_password=XXXXXXXXXX
>
>
> My share
>
> root at kolla-gluster:~# showmount -e localhost
> Export list for localhost:
> /myshare/brick1/brick (everyone)
>
>


From rafaelweingartner at gmail.com  Tue Mar  8 15:56:05 2022
From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=)
Date: Tue, 8 Mar 2022 12:56:05 -0300
Subject: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
 metrics using ceilometer and gnocchi
In-Reply-To: <VE1PR03MB5550EC67657B11B5354BC292EC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
 <VE1PR03MB55500139D4A8F6C4447C167FEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
 <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97radzOiX6vL64L-ug2+a7Y5B5x84soMJ=Dg=dBN7ON5wNrQ@mail.gmail.com>
 <VE1PR03MB555093FE01A603C3289B5BF5EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97rafnksd==DBiqnGDY3DtQcTZnGn+_KiyEB4tqLJ2hw-g8A@mail.gmail.com>
 <VE1PR03MB5550E8A87742A68E38EBDF9FEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97raeheZcfwfpNyFi83oEBP5iMgUr9UNTY38xFng25rnqLfA@mail.gmail.com>
 <VE1PR03MB5550C23A81F22EB55D95A00EEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97racCjO2CzMw+k7ow-2-UA0f9RDGKaMux1uYN5Kb2Td-VNA@mail.gmail.com>
 <AM6PR03MB5542A9478BA137A27F578382EC069@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <CAG97rae0UC1JqT-iT9cgpVKR_8L92_Cfj_Y=eZa3Ghb9Bpp_ig@mail.gmail.com>
 <VE1PR03MB5550C9EFAFA20EE8D9B3B05BEC069@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <VE1PR03MB5550EC67657B11B5354BC292EC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
Message-ID: <CAG97racNAiL8NVujibH=EC8=Ekk5TgJeXWtHM8nPAcw4f5XDkw@mail.gmail.com>

What does "gnocchi resource show 3ef0373a-558c-4818-b693-7536ee70d283"
display?

On Tue, Mar 8, 2022 at 12:00 PM Molka Gharbaoui <
Molka.Gharbaoui at santannapisa.it> wrote:

> I left the instance running for more than 1 hour and now when I check the
> logs of "ceilometer-polling" I can see the following messages:
>
> DEBUG ceilometer.compute.pollsters [-]
> 3ef0373a-558c-4818-b693-7536ee70d283/network.outgoing.bytes volume: 3608
> _stats_to_sample
> /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108
> DEBUG ceilometer.compute.pollsters [-]
> 3ef0373a-558c-4818-b693-7536ee70d283/network.outgoing.packets volume: 25
> _stats_to_sample
> /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108
> DEBUG ceilometer.compute.pollsters [-]
> 3ef0373a-558c-4818-b693-7536ee70d283/disk.device.write.requests volume:
> 4568 _stats_to_sample
> /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108
>
> So I guess that Ceilometer is starting to poll some statistics.
>
> The "gnocchi resource list" also now gives the following output:
> ID                                                                   Type
> 3ef0373a-558c-4818-b693-7536ee70d283 | instance
>
> However, the "gnocchi metric list" is still empty.
>
> Looking in the logs of "ceilometer-agent-notification", I found the
> following error:
> ERROR ceilometer.pipeline.sample [-] Pipeline meter_sink: Continue after
> error from publisher <ceilometer.publisher.gnocchi.GnocchiPublisher
> object at 0x7fc9800f9ee0>: gnocchiclient.exceptions.Conflict: <html>
>  <head>
>   <title>409 Conflict</title>
>  </head>
>  <body>
>   <h1>409 Conflict</h1>
>   There was a conflict when trying to complete your request.<br /><br />
> Archive policy ceilometer-low already exists
>  </body>
> </html> (HTTP 409)
>
> Do you know how to resolve this?
>
> Thanks.
>
>
>
>

-- 
Rafael Weing?rtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/fb631bee/attachment.htm>

From elfosardo at gmail.com  Tue Mar  8 16:01:01 2022
From: elfosardo at gmail.com (Riccardo Pittau)
Date: Tue, 8 Mar 2022 17:01:01 +0100
Subject: [ironic] Moving weekly meeting time
Message-ID: <CAORRS==7RoGwr+kLU6C2CmQLLxcxDJgYhWm2rj0PMzNcgXqrDQ@mail.gmail.com>

Hello ironicers!

We're close to time change, again (Sunday March 13th for US, and Sunday
March 27th for EU).

For this reason, if there are no objections, we'd like to move the weekly
ironic Monday meeting one hour earlier starting Monday March 28th.

Thanks!

Ciao
Riccardo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/12eeb623/attachment.htm>

From Molka.Gharbaoui at santannapisa.it  Tue Mar  8 16:02:44 2022
From: Molka.Gharbaoui at santannapisa.it (Molka Gharbaoui)
Date: Tue, 8 Mar 2022 16:02:44 +0000
Subject: R: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics
 using ceilometer and gnocchi
In-Reply-To: <CAG97racNAiL8NVujibH=EC8=Ekk5TgJeXWtHM8nPAcw4f5XDkw@mail.gmail.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
 <VE1PR03MB55500139D4A8F6C4447C167FEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
 <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97radzOiX6vL64L-ug2+a7Y5B5x84soMJ=Dg=dBN7ON5wNrQ@mail.gmail.com>
 <VE1PR03MB555093FE01A603C3289B5BF5EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97rafnksd==DBiqnGDY3DtQcTZnGn+_KiyEB4tqLJ2hw-g8A@mail.gmail.com>
 <VE1PR03MB5550E8A87742A68E38EBDF9FEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97raeheZcfwfpNyFi83oEBP5iMgUr9UNTY38xFng25rnqLfA@mail.gmail.com>
 <VE1PR03MB5550C23A81F22EB55D95A00EEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97racCjO2CzMw+k7ow-2-UA0f9RDGKaMux1uYN5Kb2Td-VNA@mail.gmail.com>
 <AM6PR03MB5542A9478BA137A27F578382EC069@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <CAG97rae0UC1JqT-iT9cgpVKR_8L92_Cfj_Y=eZa3Ghb9Bpp_ig@mail.gmail.com>
 <VE1PR03MB5550C9EFAFA20EE8D9B3B05BEC069@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <VE1PR03MB5550EC67657B11B5354BC292EC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97racNAiL8NVujibH=EC8=Ekk5TgJeXWtHM8nPAcw4f5XDkw@mail.gmail.com>
Message-ID: <VE1PR03MB5550CA251929F64B6F8C1D72EC099@VE1PR03MB5550.eurprd03.prod.outlook.com>

+-----------------------+-------------------------------------------------------------------+
| Field                 | Value                                                             |
+-----------------------+-------------------------------------------------------------------+
| created_by_project_id | ce87d288bf5846f1b54d3664802fd06d                                  |
| created_by_user_id    | f8619bc10b584e3d9365ca201d00c9e6                                  |
| creator               | f8619bc10b584e3d9365ca201d00c9e6:ce87d288bf5846f1b54d3664802fd06d |
| ended_at              | None                                                              |
| id                    | 3ef0373a-558c-4818-b693-7536ee70d283                              |
| metrics               |                                                                   |
| original_resource_id  | 3ef0373a-558c-4818-b693-7536ee70d283                              |
| project_id            | f25dced0e26947dd924fc2c9984282ad                                  |
| revision_end          | None                                                              |
| revision_start        | 2022-03-08T15:46:36.110838+00:00                                  |
| started_at            | 2022-03-08T15:46:36.110825+00:00                                  |
| type                  | instance                                                          |
| user_id               | 4d36e9b17ff04d55853cddf111a0d4dd                                  |
+-----------------------+-------------------------------------------------------------------+
________________________________
Da: Rafael Weing?rtner <rafaelweingartner at gmail.com>
Inviato: marted? 8 marzo 2022 16:56
A: Molka Gharbaoui <molka.gharbaoui at santannapisa.it>
Cc: Openstack Discuss List <openstack-discuss at lists.openstack.org>
Oggetto: Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics using ceilometer and gnocchi

What does "gnocchi resource show 3ef0373a-558c-4818-b693-7536ee70d283" display?

On Tue, Mar 8, 2022 at 12:00 PM Molka Gharbaoui <Molka.Gharbaoui at santannapisa.it<mailto:Molka.Gharbaoui at santannapisa.it>> wrote:
I left the instance running for more than 1 hour and now when I check the logs of "ceilometer-polling" I can see the following messages:

DEBUG ceilometer.compute.pollsters [-] 3ef0373a-558c-4818-b693-7536ee70d283/network.outgoing.bytes volume: 3608 _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108
DEBUG ceilometer.compute.pollsters [-] 3ef0373a-558c-4818-b693-7536ee70d283/network.outgoing.packets volume: 25 _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108
DEBUG ceilometer.compute.pollsters [-] 3ef0373a-558c-4818-b693-7536ee70d283/disk.device.write.requests volume: 4568 _stats_to_sample /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108

So I guess that Ceilometer is starting to poll some statistics.

The "gnocchi resource list" also now gives the following output:
ID                                                                   Type
3ef0373a-558c-4818-b693-7536ee70d283 | instance

However, the "gnocchi metric list" is still empty.

Looking in the logs of "ceilometer-agent-notification", I found the following error:
ERROR ceilometer.pipeline.sample [-] Pipeline meter_sink: Continue after error from publisher <ceilometer.publisher.gnocchi.GnocchiPublisher object at 0x7fc9800f9ee0>: gnocchiclient.exceptions.Conflict: <html>
 <head>
  <title>409 Conflict</title>
 </head>
 <body>
  <h1>409 Conflict</h1>
  There was a conflict when trying to complete your request.<br /><br />
Archive policy ceilometer-low already exists
 </body>
</html> (HTTP 409)

Do you know how to resolve this?

Thanks.





--
Rafael Weing?rtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/720dfa88/attachment-0001.htm>

From marc-antoine.godde at viarezo.fr  Tue Mar  8 16:18:05 2022
From: marc-antoine.godde at viarezo.fr (Marc-Antoine Godde)
Date: Tue, 8 Mar 2022 17:18:05 +0100
Subject: IPv6 deployment on OpenStack
In-Reply-To: <2536429.7s5MMGUR32@p1>
References: <B30F2915-674E-4029-9F1A-D25589FFF056@viarezo.fr>
 <14575046.tv2OnDr8pf@p1> <8195F0AD-5FE8-432C-A1A7-8EB287B13C64@viarezo.fr>
 <2536429.7s5MMGUR32@p1>
Message-ID: <BA82712D-C40D-4B22-899B-6FBEDB52920B@viarezo.fr>

Hi,

Here?s what we?ve done.

We created a network:

Name
ipv6-testing-network
ID
9d5ca309-1861-4422-bcff-8818f9762a6f
Project ID
653f5a2e60d34768a8629e5d4fca0738
Status
Active
Admin State
UP
Shared
Yes
External Network
Yes
MTU
1500
Provider Network
Network Type: vlan
Physical Network: vlan
Segmentation ID: 51

We created a subnet:

Name
ipv6-testing-v6
ID
763771d4-b9d7-419a-ba04-97ce3abaf152
Project ID
653f5a2e60d34768a8629e5d4fca0738
Network Name
ipv6-testing-network
Network ID
9d5ca309-1861-4422-bcff-8818f9762a6f <https://openstack.viarezo.fr/project/networks/9d5ca309-1861-4422-bcff-8818f9762a6f/detail>Subnet Pool
None
IP Version
IPv6
CIDR
xxxx:xxxx:2f1:aaaa::/64
IP Allocation Pools
Start xxxx:xxxx:2f1:aaaa::2 - End xxxx:xxxx:2f1:aaaa:ffff:ffff:ffff:ffff
Gateway IP
xxxx:xxxx:2f1:aaaa::1
DHCP Enabled
Yes
IPv6 Address Configuration Mode
SLAAC: Address discovered from OpenStack Router
Additional Routes
None
DNS Name Servers
None


We created Ubuntu and Debian instances. According to Horizon, the instance IPv6 is xxxx:xxxx:2f1:aaaa:f816:3eff:fe6d:c41a. Yet, we only have a link local address which is fe80::f816:3eff:fe6d:c41a/64. TCPdump indicates no Router Advertisement. We tried with and without adding a router on the Network in Horizon. ICMPv6 is authorized in INGRESS from ::/0.

We checked on the controllers, the computes and in the Neutron containers, systemctl indicated no instance of RADVD. Maybe we checked incorrectly...

Do you have any suggestions ? I add that we are working with OpenStack Ussuri deployed with OpenStack-ansible.

Thanks,
Marc-Antoine


> Le 8 mars 2022 ? 08:59, Slawek Kaplonski <skaplons at redhat.com> a ?crit :
> 
> Hi,
> 
> On poniedzia?ek, 7 marca 2022 10:36:30 CET Marc-Antoine Godde wrote:
>> Hello,
>> 
>> Thanks for your answer.
>> 
>> If I?m correct, we can just use a virtual router with SLAAC since RADVD can deal with RS and emit RA (with support for RFC6106), right ? 
> 
> Yes, virtual router created in the Neutron is enough there. It will spawn radvd in the qrouter namespace and will send RA to the Vms.
> Please note that Neutron don't supports privacy extension [1] so You will need to make sure that it's disabled it on Your vms.
> 
>> More generally, aren?t we suppose to have a virtual router every time, even in DHCPv6 (stateless and statefull), to answer RS ? I have to admit that I?m not very familiar at the moment with the implementations of RFCs in OpenStack.
>> 
>> Currently, we prefer the idea of adding IPv6 through SLAAC to have a uniform network. If we do so, we?d like to avoid sending RA from our physical router to limit its load. Yet, we do not any other arguments to support this choice.
>> Do you have any recommendations on what to do in latest versions of OpenStack ? What is usually done ?
> 
> TBH I don't have such experience. That's more question to operators of OpenStack.
> 
>> 
>> Thanks,
>> Marc-Antoine
>> 
>>> Le 7 mars 2022 ? 09:12, Slawek Kaplonski <skaplons at redhat.com> a ?crit :
>>> 
>>> Hi,
>>> 
>>> On poniedzia?ek, 7 marca 2022 02:36:24 CET Marc-Antoine Godde wrote:
>>>> Hello.
>>>> 
>>>> We are progressively adding support for IPv6 in my company. We decided to use SLAAC only for laptops, phones, ? since DHCPv6 isn?t supported on Android. RDNSS support will also increase. We are now planning our deployment on OpenStack. We already know that we'll rely only on neutron but we are not yet fixed between DHCPv6 and SLAAC ? Do you have any arguments for one these for VMs ?
>>>> 
>>>> Thanks,
>>>> Marc-Antoine.
>>>> 
>>> 
>>> With SLAAC You need to have Your network connected to the router in Neutron and You can only configure IP address on the VM. With DHCPv6 You can configure other things, like some static-routes, etc. 
>>> Neutron supports DHCPv6 in the stateful and stateless variants. With stateless, You are using RA for address configuration and DHCP server for other configation. Please see [1] for more details.
>>> 
>>> [1] https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports
>>> 
>> 
>> 
> 
> [1] https://datatracker.ietf.org/doc/html/rfc4941 <https://datatracker.ietf.org/doc/html/rfc4941>
> 
> -- 
> Slawek Kaplonski
> Principal Software Engineer
> Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/b78a9b15/attachment-0001.htm>

From gagehugo at gmail.com  Tue Mar  8 16:23:58 2022
From: gagehugo at gmail.com (Gage Hugo)
Date: Tue, 8 Mar 2022 10:23:58 -0600
Subject: [openstack][keystone] Stepping down from core
Message-ID: <CAE4Awf_WpipFpn4F5ZdwmAQdfmXNxr_wO-1ZpnLXSM09CzgzNA@mail.gmail.com>

After some consideration and my focus shifting to other priorities, I
cannot reliably devote enough time to keystone so I'll be stepping down
from keystone core. I greatly appreciate the experiences I had to learn and
grow thanks to everyone's help.

Thanks to you all and I'm grateful for the opportunities I've had with the
project and openstack as a whole. Hopefully we will get to collaborate
again more in the future.

Gage Hugo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/0a3ee12c/attachment.htm>

From rafaelweingartner at gmail.com  Tue Mar  8 16:42:45 2022
From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=)
Date: Tue, 8 Mar 2022 13:42:45 -0300
Subject: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
 metrics using ceilometer and gnocchi
In-Reply-To: <VE1PR03MB5550CA251929F64B6F8C1D72EC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
 <VE1PR03MB55500139D4A8F6C4447C167FEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
 <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97radzOiX6vL64L-ug2+a7Y5B5x84soMJ=Dg=dBN7ON5wNrQ@mail.gmail.com>
 <VE1PR03MB555093FE01A603C3289B5BF5EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97rafnksd==DBiqnGDY3DtQcTZnGn+_KiyEB4tqLJ2hw-g8A@mail.gmail.com>
 <VE1PR03MB5550E8A87742A68E38EBDF9FEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97raeheZcfwfpNyFi83oEBP5iMgUr9UNTY38xFng25rnqLfA@mail.gmail.com>
 <VE1PR03MB5550C23A81F22EB55D95A00EEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97racCjO2CzMw+k7ow-2-UA0f9RDGKaMux1uYN5Kb2Td-VNA@mail.gmail.com>
 <AM6PR03MB5542A9478BA137A27F578382EC069@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <CAG97rae0UC1JqT-iT9cgpVKR_8L92_Cfj_Y=eZa3Ghb9Bpp_ig@mail.gmail.com>
 <VE1PR03MB5550C9EFAFA20EE8D9B3B05BEC069@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <VE1PR03MB5550EC67657B11B5354BC292EC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97racNAiL8NVujibH=EC8=Ekk5TgJeXWtHM8nPAcw4f5XDkw@mail.gmail.com>
 <VE1PR03MB5550CA251929F64B6F8C1D72EC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
Message-ID: <CAG97racOBBv31sYN8yug=WUtZ-HTLAE_PHnxSQh-xX-Gvp2zeg@mail.gmail.com>

It seems that Ceilometer is trying to re-create the archive-policy, but it
already exists. Can you check the archive policy in Gnocchi?

On Tue, Mar 8, 2022 at 1:02 PM Molka Gharbaoui <
Molka.Gharbaoui at santannapisa.it> wrote:

> +-----------------------+-----------------------------------
> --------------------------------+
> | Field                 | Value
>                   |
> +-----------------------+-----------------------------------
> --------------------------------+
> | created_by_project_id | ce87d288bf5846f1b54d3664802fd06d
>                    |
> | created_by_user_id    | f8619bc10b584e3d9365ca201d00c9e6
>                    |
> | creator               | f8619bc10b584e3d9365ca201d00c9e6:
> ce87d288bf5846f1b54d3664802fd06d |
> | ended_at              | None
>                  |
> | id                    | 3ef0373a-558c-4818-b693-7536ee70d283
>                    |
> | metrics               |
>                   |
> | original_resource_id  | 3ef0373a-558c-4818-b693-7536ee70d283
>                    |
> | project_id            | f25dced0e26947dd924fc2c9984282ad
>                    |
> | revision_end          | None
>                  |
> | revision_start        | 2022-03-08T15:46:36.110838+00:00
>                    |
> | started_at            | 2022-03-08T15:46:36.110825+00:00
>                    |
> | type                  | instance
>                  |
> | user_id               | 4d36e9b17ff04d55853cddf111a0d4dd
>                    |
> +-----------------------+-----------------------------------
> --------------------------------+
> ------------------------------
> *Da:* Rafael Weing?rtner <rafaelweingartner at gmail.com>
> *Inviato:* marted? 8 marzo 2022 16:56
> *A:* Molka Gharbaoui <molka.gharbaoui at santannapisa.it>
> *Cc:* Openstack Discuss List <openstack-discuss at lists.openstack.org>
> *Oggetto:* Re: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
> metrics using ceilometer and gnocchi
>
> What does "gnocchi resource show 3ef0373a-558c-4818-b693-7536ee70d283"
> display?
>
> On Tue, Mar 8, 2022 at 12:00 PM Molka Gharbaoui <
> Molka.Gharbaoui at santannapisa.it> wrote:
>
> I left the instance running for more than 1 hour and now when I check the
> logs of "ceilometer-polling" I can see the following messages:
>
> DEBUG ceilometer.compute.pollsters [-]
> 3ef0373a-558c-4818-b693-7536ee70d283/network.outgoing.bytes volume: 3608
> _stats_to_sample
> /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108
> DEBUG ceilometer.compute.pollsters [-]
> 3ef0373a-558c-4818-b693-7536ee70d283/network.outgoing.packets volume: 25
> _stats_to_sample
> /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108
> DEBUG ceilometer.compute.pollsters [-]
> 3ef0373a-558c-4818-b693-7536ee70d283/disk.device.write.requests volume:
> 4568 _stats_to_sample
> /opt/stack/ceilometer/ceilometer/compute/pollsters/__init__.py:108
>
> So I guess that Ceilometer is starting to poll some statistics.
>
> The "gnocchi resource list" also now gives the following output:
> ID                                                                   Type
> 3ef0373a-558c-4818-b693-7536ee70d283 | instance
>
> However, the "gnocchi metric list" is still empty.
>
> Looking in the logs of "ceilometer-agent-notification", I found the
> following error:
> ERROR ceilometer.pipeline.sample [-] Pipeline meter_sink: Continue after
> error from publisher <ceilometer.publisher.gnocchi.GnocchiPublisher
> object at 0x7fc9800f9ee0>: gnocchiclient.exceptions.Conflict: <html>
>  <head>
>   <title>409 Conflict</title>
>  </head>
>  <body>
>   <h1>409 Conflict</h1>
>   There was a conflict when trying to complete your request.<br /><br />
> Archive policy ceilometer-low already exists
>  </body>
> </html> (HTTP 409)
>
> Do you know how to resolve this?
>
> Thanks.
>
>
>
>
>
> --
> Rafael Weing?rtner
>


-- 
Rafael Weing?rtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/c85eaa8c/attachment-0001.htm>

From Molka.Gharbaoui at santannapisa.it  Tue Mar  8 16:49:02 2022
From: Molka.Gharbaoui at santannapisa.it (Molka Gharbaoui)
Date: Tue, 8 Mar 2022 16:49:02 +0000
Subject: R: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics
 using ceilometer and gnocchi
In-Reply-To: <VE1PR03MB5550D2D89AD1D38A708799EDEC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
 <VE1PR03MB55500139D4A8F6C4447C167FEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
 <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97radzOiX6vL64L-ug2+a7Y5B5x84soMJ=Dg=dBN7ON5wNrQ@mail.gmail.com>
 <VE1PR03MB555093FE01A603C3289B5BF5EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97rafnksd==DBiqnGDY3DtQcTZnGn+_KiyEB4tqLJ2hw-g8A@mail.gmail.com>
 <VE1PR03MB5550E8A87742A68E38EBDF9FEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97raeheZcfwfpNyFi83oEBP5iMgUr9UNTY38xFng25rnqLfA@mail.gmail.com>
 <VE1PR03MB5550C23A81F22EB55D95A00EEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97racCjO2CzMw+k7ow-2-UA0f9RDGKaMux1uYN5Kb2Td-VNA@mail.gmail.com>
 <AM6PR03MB5542A9478BA137A27F578382EC069@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <CAG97rae0UC1JqT-iT9cgpVKR_8L92_Cfj_Y=eZa3Ghb9Bpp_ig@mail.gmail.com>
 <VE1PR03MB5550C9EFAFA20EE8D9B3B05BEC069@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <VE1PR03MB5550EC67657B11B5354BC292EC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97racNAiL8NVujibH=EC8=Ekk5TgJeXWtHM8nPAcw4f5XDkw@mail.gmail.com>
 <VE1PR03MB5550CA251929F64B6F8C1D72EC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97racOBBv31sYN8yug=WUtZ-HTLAE_PHnxSQh-xX-Gvp2zeg@mail.gmail.com>
 <VE1PR03MB5550D2D89AD1D38A708799EDEC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
Message-ID: <VE1PR03MB55508291BB96BC28540C02ACEC099@VE1PR03MB5550.eurprd03.prod.outlook.com>


This is the outcome of the gnocchi archive-policy list. All are created "automatically" during the Devstack configuration

stack at ubuntu-VirtualBox:~/devstack$ gnocchi archive-policy list
+----------------------+-------------+-----------------------------------------------------------------------+---------------------------------+
| name                 | back_window | definition                                                            | aggregation_methods             |
+----------------------+-------------+-----------------------------------------------------------------------+---------------------------------+
| bool                 |        3600 | - timespan: 365 days, 0:00:00, granularity: 0:00:01, points: 31536000 | last                            |
| ceilometer-high      |           0 | - timespan: 1:00:00, granularity: 0:00:01, points: 3600               | mean                            |
|                      |             | - timespan: 1 day, 0:00:00, granularity: 0:01:00, points: 1440        |                                 |
|                      |             | - timespan: 365 days, 0:00:00, granularity: 1:00:00, points: 8760     |                                 |
| ceilometer-high-rate |           0 | - timespan: 1:00:00, granularity: 0:00:01, points: 3600               | rate:mean, mean                 |
|                      |             | - timespan: 1 day, 0:00:00, granularity: 0:01:00, points: 1440        |                                 |
|                      |             | - timespan: 365 days, 0:00:00, granularity: 1:00:00, points: 8760     |                                 |
| ceilometer-low       |           0 | - timespan: 30 days, 0:00:00, granularity: 0:05:00, points: 8640      | mean                            |
| ceilometer-low-rate  |           0 | - timespan: 30 days, 0:00:00, granularity: 0:05:00, points: 8640      | rate:mean, mean                 |
| high                 |           0 | - timespan: 1:00:00, granularity: 0:00:01, points: 3600               | count, min, mean, max, sum, std |
|                      |             | - timespan: 7 days, 0:00:00, granularity: 0:01:00, points: 10080      |                                 |
|                      |             | - timespan: 365 days, 0:00:00, granularity: 1:00:00, points: 8760     |                                 |
| low                  |           0 | - timespan: 30 days, 0:00:00, granularity: 0:05:00, points: 8640      | count, min, mean, max, sum, std |
| medium               |           0 | - timespan: 7 days, 0:00:00, granularity: 0:01:00, points: 10080      | count, min, mean, max, sum, std |
|                      |             | - timespan: 365 days, 0:00:00, granularity: 1:00:00, points: 8760     |                                 |
+----------------------+-------------+-----------------------------------------------------------------------+---------------------------------+

Shall I delete them??

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/6b94e0d3/attachment.htm>

From rafaelweingartner at gmail.com  Tue Mar  8 16:51:52 2022
From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=)
Date: Tue, 8 Mar 2022 13:51:52 -0300
Subject: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve
 metrics using ceilometer and gnocchi
In-Reply-To: <VE1PR03MB55508291BB96BC28540C02ACEC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
 <VE1PR03MB55500139D4A8F6C4447C167FEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
 <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97radzOiX6vL64L-ug2+a7Y5B5x84soMJ=Dg=dBN7ON5wNrQ@mail.gmail.com>
 <VE1PR03MB555093FE01A603C3289B5BF5EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97rafnksd==DBiqnGDY3DtQcTZnGn+_KiyEB4tqLJ2hw-g8A@mail.gmail.com>
 <VE1PR03MB5550E8A87742A68E38EBDF9FEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97raeheZcfwfpNyFi83oEBP5iMgUr9UNTY38xFng25rnqLfA@mail.gmail.com>
 <VE1PR03MB5550C23A81F22EB55D95A00EEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97racCjO2CzMw+k7ow-2-UA0f9RDGKaMux1uYN5Kb2Td-VNA@mail.gmail.com>
 <AM6PR03MB5542A9478BA137A27F578382EC069@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <CAG97rae0UC1JqT-iT9cgpVKR_8L92_Cfj_Y=eZa3Ghb9Bpp_ig@mail.gmail.com>
 <VE1PR03MB5550C9EFAFA20EE8D9B3B05BEC069@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <VE1PR03MB5550EC67657B11B5354BC292EC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97racNAiL8NVujibH=EC8=Ekk5TgJeXWtHM8nPAcw4f5XDkw@mail.gmail.com>
 <VE1PR03MB5550CA251929F64B6F8C1D72EC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97racOBBv31sYN8yug=WUtZ-HTLAE_PHnxSQh-xX-Gvp2zeg@mail.gmail.com>
 <VE1PR03MB5550D2D89AD1D38A708799EDEC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <VE1PR03MB55508291BB96BC28540C02ACEC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
Message-ID: <CAG97raftmBtS3jEW5cT8jFOUceS=CZh95TwjkgEqsmHW-KDmYg@mail.gmail.com>

can you try it? Not all of them, but the "ceilometer-low" that is causing
the conflict

On Tue, Mar 8, 2022 at 1:49 PM Molka Gharbaoui <
Molka.Gharbaoui at santannapisa.it> wrote:

>
> This is the outcome of the gnocchi archive-policy list. All are created
> "automatically" during the Devstack configuration
>
> stack at ubuntu-VirtualBox:~/devstack$ gnocchi archive-policy list
> +----------------------+-------------+----------------------
> -------------------------------------------------+----------
> -----------------------+
> | name                 | back_window | definition
>                                    | aggregation_methods             |
> +----------------------+-------------+----------------------
> -------------------------------------------------+----------
> -----------------------+
> | bool                 |        3600 | - timespan: 365 days, 0:00:00,
> granularity: 0:00:01, points: 31536000 | last                            |
> | ceilometer-high      |           0 | - timespan: 1:00:00, granularity:
> 0:00:01, points: 3600               | mean                            |
> |                      |             | - timespan: 1 day, 0:00:00,
> granularity: 0:01:00, points: 1440        |
> |
> |                      |             | - timespan: 365 days, 0:00:00,
> granularity: 1:00:00, points: 8760     |                                 |
> | ceilometer-high-rate |           0 | - timespan: 1:00:00, granularity:
> 0:00:01, points: 3600               | rate:mean, mean                 |
> |                      |             | - timespan: 1 day, 0:00:00,
> granularity: 0:01:00, points: 1440        |
> |
> |                      |             | - timespan: 365 days, 0:00:00,
> granularity: 1:00:00, points: 8760     |                                 |
> | ceilometer-low       |           0 | - timespan: 30 days, 0:00:00,
> granularity: 0:05:00, points: 8640      | mean                            |
> | ceilometer-low-rate  |           0 | - timespan: 30 days, 0:00:00,
> granularity: 0:05:00, points: 8640      | rate:mean, mean                 |
> | high                 |           0 | - timespan: 1:00:00, granularity:
> 0:00:01, points: 3600               | count, min, mean, max, sum, std |
> |                      |             | - timespan: 7 days, 0:00:00,
> granularity: 0:01:00, points: 10080      |                                 |
> |                      |             | - timespan: 365 days, 0:00:00,
> granularity: 1:00:00, points: 8760     |                                 |
> | low                  |           0 | - timespan: 30 days, 0:00:00,
> granularity: 0:05:00, points: 8640      | count, min, mean, max, sum, std |
> | medium               |           0 | - timespan: 7 days, 0:00:00,
> granularity: 0:01:00, points: 10080      | count, min, mean, max, sum, std |
> |                      |             | - timespan: 365 days, 0:00:00,
> granularity: 1:00:00, points: 8760     |                                 |
> +----------------------+-------------+----------------------
> -------------------------------------------------+----------
> -----------------------+
>
> Shall I delete them??
>
>

-- 
Rafael Weing?rtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/5080fbf5/attachment-0001.htm>

From satish.txt at gmail.com  Tue Mar  8 19:19:46 2022
From: satish.txt at gmail.com (Satish Patel)
Date: Tue, 8 Mar 2022 14:19:46 -0500
Subject: [kolla-ansible][manila] mount.glusterfs is not installed
In-Reply-To: <CAKZ_x7_CPcbfVyOe=vBLORRZ_X0kV6uxtb4_Kt47=uhPDaYDFQ@mail.gmail.com>
References: <CAPgF-fotat45LDZ=eoq62LBBOTAJ_cq5R8=zL5+4SJAoTJGvgA@mail.gmail.com>
 <CAKZ_x7_CPcbfVyOe=vBLORRZ_X0kV6uxtb4_Kt47=uhPDaYDFQ@mail.gmail.com>
Message-ID: <CAPgF-fojyUd-Bq_jKMum_q08D9HcAr7P0Xa0gfiGWFZZFQyL7w@mail.gmail.com>

Thank you!!

We have to push this patch also because Manila had issue related
policy.json file which i have to delete in order to make it work properly.
https://review.opendev.org/c/openstack/kolla/+/812479

On Tue, Mar 8, 2022 at 10:17 AM Rados?aw Piliszek <
radoslaw.piliszek at gmail.com> wrote:

> As we have discussed on IRC - this is a discrepancy in Debuntu images.
> I have reported the issue for you and will see to it getting fixed as
> it's a simple and obvious bug. [1]
>
> [1] https://bugs.launchpad.net/kolla/+bug/1964140
>
> -yoctozepto
>
> On Tue, 8 Mar 2022 at 06:07, Satish Patel <satish.txt at gmail.com> wrote:
> >
> > Folks,
> >
> > I am trying to configure Manila with kolla-ansible using glusterfs with
> ganesha-nfs server, I am running glusterfs and ganesha-nfs on the same
> server and getting the following error messages in manila-share.log service
> file. What am I missing here?
> >
> > 2022-03-08 04:39:32.940 17 INFO paramiko.transport [-] Connected
> (version 2.0, client OpenSSH_8.2p1)
> > 2022-03-08 04:39:32.982 17 INFO paramiko.transport [-] Authentication
> (password) successful!
> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager
> [req-c2925794-b62a-47b9-8f44-90939d417329 - - - - -] Error encountered
> during initialization of driver GlusterfsShareDriver at kolla@ganesha:
> manila.exception.GlusterfsException: mount.glusterfs is not installed.
> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager Traceback (most
> recent call last):
> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File
> "/usr/lib/python3/dist-packages/manila/share/drivers/glusterfs/layout.py",
> line 216, in _check_mount_glusterfs
> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager
>  self.driver._execute('mount.glusterfs', check_exit_code=False)
> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File
> "/usr/lib/python3/dist-packages/manila/utils.py", line 101, in execute
> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager     return
> processutils.execute(*cmd, **kwargs)
> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File
> "/usr/lib/python3/dist-packages/oslo_concurrency/processutils.py", line
> 395, in execute
> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager     obj =
> subprocess.Popen(cmd,
> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File
> "/usr/lib/python3/dist-packages/eventlet/green/subprocess.py", line 58, in
> __init__
> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager
>  subprocess_orig.Popen.__init__(self, args, 0, *argss, **kwds)
> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File
> "/usr/lib/python3.8/subprocess.py", line 858, in __init__
> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager
>  self._execute_child(args, executable, preexec_fn, close_fds,
> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File
> "/usr/lib/python3.8/subprocess.py", line 1704, in _execute_child
> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager     raise
> child_exception_type(errno_num, err_msg, err_filename)
> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager FileNotFoundError:
> [Errno 2] No such file or directory: 'mount.glusterfs'
> >
> >
> > My manila Config
> >
> > [DEFAULT]
> > enabled_share_backends=ganesha
> > enabled_share_protocols = NFS,CIFS,GLUSTERFS
> >
> > [ganesha]
> > share_backend_name = ganesha
> > glusterfs_nfs_server_type = Ganesha
> > glusterfs_target=root at 10.30.1.206:/myshare/brick1/brick
> > glusterfs_server_password=XXXXXXXXXXX
> > share_driver = manila.share.drivers.glusterfs.GlusterfsShareDriver
> > ganesha_service_name = nfs-ganesha
> > driver_handles_share_servers = False
> > glusterfs_ganesha_server_ip=10.30.1.206
> > glusterfs_ganesha_server_username=root
> > glusterfs_ganesha_server_password=XXXXXXXXXX
> >
> >
> > My share
> >
> > root at kolla-gluster:~# showmount -e localhost
> > Export list for localhost:
> > /myshare/brick1/brick (everyone)
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/5bb2b195/attachment.htm>

From radoslaw.piliszek at gmail.com  Tue Mar  8 19:26:08 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Tue, 8 Mar 2022 20:26:08 +0100
Subject: [kolla-ansible][manila] mount.glusterfs is not installed
In-Reply-To: <CAPgF-fojyUd-Bq_jKMum_q08D9HcAr7P0Xa0gfiGWFZZFQyL7w@mail.gmail.com>
References: <CAPgF-fotat45LDZ=eoq62LBBOTAJ_cq5R8=zL5+4SJAoTJGvgA@mail.gmail.com>
 <CAKZ_x7_CPcbfVyOe=vBLORRZ_X0kV6uxtb4_Kt47=uhPDaYDFQ@mail.gmail.com>
 <CAPgF-fojyUd-Bq_jKMum_q08D9HcAr7P0Xa0gfiGWFZZFQyL7w@mail.gmail.com>
Message-ID: <CAKZ_x79OUoQGvqzzya_J7MTcuEXyr+2uRsjhNXLoNiZi74JMXg@mail.gmail.com>

If you are using "binary" images, then the recommendation is to switch
to "source" images.
"binary" images are deprecated and will only receive minimal fixing.
I replied on the change as well.

-yoctozepto

On Tue, 8 Mar 2022 at 20:19, Satish Patel <satish.txt at gmail.com> wrote:
>
>
> Thank you!!
>
> We have to push this patch also because Manila had issue related policy.json file which i have to delete in order to make it work properly. https://review.opendev.org/c/openstack/kolla/+/812479
>
> On Tue, Mar 8, 2022 at 10:17 AM Rados?aw Piliszek <radoslaw.piliszek at gmail.com> wrote:
>>
>> As we have discussed on IRC - this is a discrepancy in Debuntu images.
>> I have reported the issue for you and will see to it getting fixed as
>> it's a simple and obvious bug. [1]
>>
>> [1] https://bugs.launchpad.net/kolla/+bug/1964140
>>
>> -yoctozepto
>>
>> On Tue, 8 Mar 2022 at 06:07, Satish Patel <satish.txt at gmail.com> wrote:
>> >
>> > Folks,
>> >
>> > I am trying to configure Manila with kolla-ansible using glusterfs with ganesha-nfs server, I am running glusterfs and ganesha-nfs on the same server and getting the following error messages in manila-share.log service file. What am I missing here?
>> >
>> > 2022-03-08 04:39:32.940 17 INFO paramiko.transport [-] Connected (version 2.0, client OpenSSH_8.2p1)
>> > 2022-03-08 04:39:32.982 17 INFO paramiko.transport [-] Authentication (password) successful!
>> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager [req-c2925794-b62a-47b9-8f44-90939d417329 - - - - -] Error encountered during initialization of driver GlusterfsShareDriver at kolla@ganesha: manila.exception.GlusterfsException: mount.glusterfs is not installed.
>> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager Traceback (most recent call last):
>> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File "/usr/lib/python3/dist-packages/manila/share/drivers/glusterfs/layout.py", line 216, in _check_mount_glusterfs
>> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager     self.driver._execute('mount.glusterfs', check_exit_code=False)
>> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File "/usr/lib/python3/dist-packages/manila/utils.py", line 101, in execute
>> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager     return processutils.execute(*cmd, **kwargs)
>> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File "/usr/lib/python3/dist-packages/oslo_concurrency/processutils.py", line 395, in execute
>> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager     obj = subprocess.Popen(cmd,
>> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File "/usr/lib/python3/dist-packages/eventlet/green/subprocess.py", line 58, in __init__
>> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager     subprocess_orig.Popen.__init__(self, args, 0, *argss, **kwds)
>> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File "/usr/lib/python3.8/subprocess.py", line 858, in __init__
>> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager     self._execute_child(args, executable, preexec_fn, close_fds,
>> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File "/usr/lib/python3.8/subprocess.py", line 1704, in _execute_child
>> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager     raise child_exception_type(errno_num, err_msg, err_filename)
>> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager FileNotFoundError: [Errno 2] No such file or directory: 'mount.glusterfs'
>> >
>> >
>> > My manila Config
>> >
>> > [DEFAULT]
>> > enabled_share_backends=ganesha
>> > enabled_share_protocols = NFS,CIFS,GLUSTERFS
>> >
>> > [ganesha]
>> > share_backend_name = ganesha
>> > glusterfs_nfs_server_type = Ganesha
>> > glusterfs_target=root at 10.30.1.206:/myshare/brick1/brick
>> > glusterfs_server_password=XXXXXXXXXXX
>> > share_driver = manila.share.drivers.glusterfs.GlusterfsShareDriver
>> > ganesha_service_name = nfs-ganesha
>> > driver_handles_share_servers = False
>> > glusterfs_ganesha_server_ip=10.30.1.206
>> > glusterfs_ganesha_server_username=root
>> > glusterfs_ganesha_server_password=XXXXXXXXXX
>> >
>> >
>> > My share
>> >
>> > root at kolla-gluster:~# showmount -e localhost
>> > Export list for localhost:
>> > /myshare/brick1/brick (everyone)
>> >
>> >


From satish.txt at gmail.com  Tue Mar  8 19:31:53 2022
From: satish.txt at gmail.com (Satish Patel)
Date: Tue, 8 Mar 2022 14:31:53 -0500
Subject: [kolla-ansible][manila] mount.glusterfs is not installed
In-Reply-To: <CAKZ_x79OUoQGvqzzya_J7MTcuEXyr+2uRsjhNXLoNiZi74JMXg@mail.gmail.com>
References: <CAPgF-fotat45LDZ=eoq62LBBOTAJ_cq5R8=zL5+4SJAoTJGvgA@mail.gmail.com>
 <CAKZ_x7_CPcbfVyOe=vBLORRZ_X0kV6uxtb4_Kt47=uhPDaYDFQ@mail.gmail.com>
 <CAPgF-fojyUd-Bq_jKMum_q08D9HcAr7P0Xa0gfiGWFZZFQyL7w@mail.gmail.com>
 <CAKZ_x79OUoQGvqzzya_J7MTcuEXyr+2uRsjhNXLoNiZi74JMXg@mail.gmail.com>
Message-ID: <CAPgF-frkfmds+TD7ng8Zgi-PdGH0xBrSS06u3DGjFgdX9mOSAQ@mail.gmail.com>

Thanks for the tip! I will switch images to sources then :)

On Tue, Mar 8, 2022 at 2:26 PM Rados?aw Piliszek <
radoslaw.piliszek at gmail.com> wrote:

> If you are using "binary" images, then the recommendation is to switch
> to "source" images.
> "binary" images are deprecated and will only receive minimal fixing.
> I replied on the change as well.
>
> -yoctozepto
>
> On Tue, 8 Mar 2022 at 20:19, Satish Patel <satish.txt at gmail.com> wrote:
> >
> >
> > Thank you!!
> >
> > We have to push this patch also because Manila had issue related
> policy.json file which i have to delete in order to make it work properly.
> https://review.opendev.org/c/openstack/kolla/+/812479
> >
> > On Tue, Mar 8, 2022 at 10:17 AM Rados?aw Piliszek <
> radoslaw.piliszek at gmail.com> wrote:
> >>
> >> As we have discussed on IRC - this is a discrepancy in Debuntu images.
> >> I have reported the issue for you and will see to it getting fixed as
> >> it's a simple and obvious bug. [1]
> >>
> >> [1] https://bugs.launchpad.net/kolla/+bug/1964140
> >>
> >> -yoctozepto
> >>
> >> On Tue, 8 Mar 2022 at 06:07, Satish Patel <satish.txt at gmail.com> wrote:
> >> >
> >> > Folks,
> >> >
> >> > I am trying to configure Manila with kolla-ansible using glusterfs
> with ganesha-nfs server, I am running glusterfs and ganesha-nfs on the same
> server and getting the following error messages in manila-share.log service
> file. What am I missing here?
> >> >
> >> > 2022-03-08 04:39:32.940 17 INFO paramiko.transport [-] Connected
> (version 2.0, client OpenSSH_8.2p1)
> >> > 2022-03-08 04:39:32.982 17 INFO paramiko.transport [-] Authentication
> (password) successful!
> >> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager
> [req-c2925794-b62a-47b9-8f44-90939d417329 - - - - -] Error encountered
> during initialization of driver GlusterfsShareDriver at kolla@ganesha:
> manila.exception.GlusterfsException: mount.glusterfs is not installed.
> >> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager Traceback (most
> recent call last):
> >> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File
> "/usr/lib/python3/dist-packages/manila/share/drivers/glusterfs/layout.py",
> line 216, in _check_mount_glusterfs
> >> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager
>  self.driver._execute('mount.glusterfs', check_exit_code=False)
> >> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File
> "/usr/lib/python3/dist-packages/manila/utils.py", line 101, in execute
> >> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager     return
> processutils.execute(*cmd, **kwargs)
> >> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File
> "/usr/lib/python3/dist-packages/oslo_concurrency/processutils.py", line
> 395, in execute
> >> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager     obj =
> subprocess.Popen(cmd,
> >> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File
> "/usr/lib/python3/dist-packages/eventlet/green/subprocess.py", line 58, in
> __init__
> >> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager
>  subprocess_orig.Popen.__init__(self, args, 0, *argss, **kwds)
> >> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File
> "/usr/lib/python3.8/subprocess.py", line 858, in __init__
> >> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager
>  self._execute_child(args, executable, preexec_fn, close_fds,
> >> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager   File
> "/usr/lib/python3.8/subprocess.py", line 1704, in _execute_child
> >> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager     raise
> child_exception_type(errno_num, err_msg, err_filename)
> >> > 2022-03-08 04:39:33.815 17 ERROR manila.share.manager
> FileNotFoundError: [Errno 2] No such file or directory: 'mount.glusterfs'
> >> >
> >> >
> >> > My manila Config
> >> >
> >> > [DEFAULT]
> >> > enabled_share_backends=ganesha
> >> > enabled_share_protocols = NFS,CIFS,GLUSTERFS
> >> >
> >> > [ganesha]
> >> > share_backend_name = ganesha
> >> > glusterfs_nfs_server_type = Ganesha
> >> > glusterfs_target=root at 10.30.1.206:/myshare/brick1/brick
> >> > glusterfs_server_password=XXXXXXXXXXX
> >> > share_driver = manila.share.drivers.glusterfs.GlusterfsShareDriver
> >> > ganesha_service_name = nfs-ganesha
> >> > driver_handles_share_servers = False
> >> > glusterfs_ganesha_server_ip=10.30.1.206
> >> > glusterfs_ganesha_server_username=root
> >> > glusterfs_ganesha_server_password=XXXXXXXXXX
> >> >
> >> >
> >> > My share
> >> >
> >> > root at kolla-gluster:~# showmount -e localhost
> >> > Export list for localhost:
> >> > /myshare/brick1/brick (everyone)
> >> >
> >> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/f0316ae7/attachment-0001.htm>

From Molka.Gharbaoui at santannapisa.it  Tue Mar  8 20:02:12 2022
From: Molka.Gharbaoui at santannapisa.it (Molka Gharbaoui)
Date: Tue, 8 Mar 2022 20:02:12 +0000
Subject: R: R: R: [Devstack][Gnocchi][Ceilometer] Not able to retrieve metrics
 using ceilometer and gnocchi
In-Reply-To: <CAG97raftmBtS3jEW5cT8jFOUceS=CZh95TwjkgEqsmHW-KDmYg@mail.gmail.com>
References: <AM6PR03MB554235BD7DA6AA27D45589E1EC019@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <2a04ab06-1651-eb25-f0f7-29b3a4805541@matthias-runge.de>
 <VE1PR03MB5550BE070D91FD64AD0835A2EC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <414fa552-988a-48a7-c331-c58df442617f@matthias-runge.de>
 <VE1PR03MB55500139D4A8F6C4447C167FEC049@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <d9bc69dc-ecce-823b-1047-1c7272e2752d@matthias-runge.de>
 <VE1PR03MB555049093B561ACA24E6CA74EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97radzOiX6vL64L-ug2+a7Y5B5x84soMJ=Dg=dBN7ON5wNrQ@mail.gmail.com>
 <VE1PR03MB555093FE01A603C3289B5BF5EC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97rafnksd==DBiqnGDY3DtQcTZnGn+_KiyEB4tqLJ2hw-g8A@mail.gmail.com>
 <VE1PR03MB5550E8A87742A68E38EBDF9FEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97raeheZcfwfpNyFi83oEBP5iMgUr9UNTY38xFng25rnqLfA@mail.gmail.com>
 <VE1PR03MB5550C23A81F22EB55D95A00EEC059@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97racCjO2CzMw+k7ow-2-UA0f9RDGKaMux1uYN5Kb2Td-VNA@mail.gmail.com>
 <AM6PR03MB5542A9478BA137A27F578382EC069@AM6PR03MB5542.eurprd03.prod.outlook.com>
 <CAG97rae0UC1JqT-iT9cgpVKR_8L92_Cfj_Y=eZa3Ghb9Bpp_ig@mail.gmail.com>
 <VE1PR03MB5550C9EFAFA20EE8D9B3B05BEC069@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <VE1PR03MB5550EC67657B11B5354BC292EC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97racNAiL8NVujibH=EC8=Ekk5TgJeXWtHM8nPAcw4f5XDkw@mail.gmail.com>
 <VE1PR03MB5550CA251929F64B6F8C1D72EC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97racOBBv31sYN8yug=WUtZ-HTLAE_PHnxSQh-xX-Gvp2zeg@mail.gmail.com>
 <VE1PR03MB5550D2D89AD1D38A708799EDEC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <VE1PR03MB55508291BB96BC28540C02ACEC099@VE1PR03MB5550.eurprd03.prod.outlook.com>
 <CAG97raftmBtS3jEW5cT8jFOUceS=CZh95TwjkgEqsmHW-KDmYg@mail.gmail.com>
Message-ID: <VE1PR03MB5550E97D3C346F4AE743B3D7EC099@VE1PR03MB5550.eurprd03.prod.outlook.com>

I removed manually "ceilometer-low" and "ceilometer-high" from archive-policy list (both were creating a conflict) however nothing changes:

If I execute ceilometer-upgrade/ceilometer-polling nothing "new" happens.

When I execute ceilometer-agent-notification, ceilometer-low/ceilometer-high are readded to the archive-policy list and the error reappears.

I guess I should not execute those commands manually but I cannot find a way to push the metrics to the database.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/e1cfdd77/attachment.htm>

From gael.therond at bitswalk.com  Tue Mar  8 20:04:43 2022
From: gael.therond at bitswalk.com (=?UTF-8?Q?Ga=C3=ABl_THEROND?=)
Date: Tue, 8 Mar 2022 21:04:43 +0100
Subject: [VICTORIA] Not working SNAT over VXLAN?
Message-ID: <CABNe=Utwt0dVuzzyCbVw63WoSr4s9w0kfUNkPLsDJp7fNt97mA@mail.gmail.com>

Hi everyone!

I?m facing a weird situation on a tenant of one of our Openstack cluster
based on Victoria.

On this tenant, the network topology is as follow:

One DMZ network (192.168.0.0/24) linked to our public network through a
neutron router where there is a VM acting as a bastion/router for the MGMT
network.

One MGMT network (172.16.31.0/24) where all VMs are linked to.

On the DMZ network, there is a linux Debian 11, let?s call it VM-A with a
Floating IP from the public pool, this VM is both attached to the DMZ
network (ens3 / 192.168.0.12) AND the MGMT network (ens4 / 172.16.31.23).

All other VMs, let?s call them VM-X are exclusively attached to the MGMT
network (ens4).

I?ve setup VM-A with ip_forward kernel module and the following iptables
rule:

# iptables -t nat -A POSTROUTING -o ens3 -J SNAT ?to-source 192.168.0.12

My VM-X are on their own setup with a default gateway via VM-A:

# ip route add default via 172.31.16.23

The setup seems to be working as if I don?t put the iptables rule and the
kernel forwarding I can?t see any packets on my DMZ interface (ens3) on
VM-A from VM-X.

Ok so now that you get the whole schema, let dive into the issue.

So when all rules, modules and gateway are set, I can fully see my VM-X
traffic (ICMP ping to a dns server) going from VM-X (ens4) to VM-A (ens4)
then forwarded to VM-A (ens3) and finally going to our public IP targeted
service.

What?s not working however is the response not reaching back to VM-X.

I?ve tcpdump the whole traffic from VM-X to VM-A on each point of the
platfrom:

from inside the VM-X nic, on the tap device, on the qbr bridge, on the qvb
veth, on the qvo second side of the veth through the ovs bridges and
vice-versa.

However the response packets aren?t reaching back further than on the VM-A
qvo veth.
Once it exit the VM-A the traffic never reaches the VM-X.

What?s really suspicious in here is that a direct ping from VM-X
(172.16.31.54) to VM-A (172.16.31.23) is coming back correctly, so it looks
like if ovs detected that the response on a SNAT case isn?t legit or
something similar.

Is anyone able to get such setup working?

Here are few additional information:
Host runs on CentOS 8.5 latest update.
Our platform is a Openstack Victoria deployed using kolla-ansible.
We are using a OVS based deployment.
Our tunnels are VXLAN.
All VMs have a fully open secgroup applied and all ports have it (I checked
it twice and even on host iptables).

If you ever need additional information feel free to let me know !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/22646df7/attachment.htm>

From laurentfdumont at gmail.com  Tue Mar  8 21:13:25 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Tue, 8 Mar 2022 16:13:25 -0500
Subject: [VICTORIA] Not working SNAT over VXLAN?
In-Reply-To: <CABNe=Utwt0dVuzzyCbVw63WoSr4s9w0kfUNkPLsDJp7fNt97mA@mail.gmail.com>
References: <CABNe=Utwt0dVuzzyCbVw63WoSr4s9w0kfUNkPLsDJp7fNt97mA@mail.gmail.com>
Message-ID: <CAOAKi8wA=bk2v2iHZgQT6Yp2baEx40a8AytBbe2cJtF6gwL-6Q@mail.gmail.com>

You might want to look at port-security on the bastion host VM. If it's
enabled, it means that Openstack will drop any outgoing packets that are
not sourced using the ip address + mac AND/OR the allowed_pairs defined on
the port.

On Tue, Mar 8, 2022 at 3:07 PM Ga?l THEROND <gael.therond at bitswalk.com>
wrote:

> Hi everyone!
>
> I?m facing a weird situation on a tenant of one of our Openstack cluster
> based on Victoria.
>
> On this tenant, the network topology is as follow:
>
> One DMZ network (192.168.0.0/24) linked to our public network through a
> neutron router where there is a VM acting as a bastion/router for the MGMT
> network.
>
> One MGMT network (172.16.31.0/24) where all VMs are linked to.
>
> On the DMZ network, there is a linux Debian 11, let?s call it VM-A with a
> Floating IP from the public pool, this VM is both attached to the DMZ
> network (ens3 / 192.168.0.12) AND the MGMT network (ens4 / 172.16.31.23).
>
> All other VMs, let?s call them VM-X are exclusively attached to the MGMT
> network (ens4).
>
> I?ve setup VM-A with ip_forward kernel module and the following iptables
> rule:
>
> # iptables -t nat -A POSTROUTING -o ens3 -J SNAT ?to-source 192.168.0.12
>
> My VM-X are on their own setup with a default gateway via VM-A:
>
> # ip route add default via 172.31.16.23
>
> The setup seems to be working as if I don?t put the iptables rule and the
> kernel forwarding I can?t see any packets on my DMZ interface (ens3) on
> VM-A from VM-X.
>
> Ok so now that you get the whole schema, let dive into the issue.
>
> So when all rules, modules and gateway are set, I can fully see my VM-X
> traffic (ICMP ping to a dns server) going from VM-X (ens4) to VM-A (ens4)
> then forwarded to VM-A (ens3) and finally going to our public IP targeted
> service.
>
> What?s not working however is the response not reaching back to VM-X.
>
> I?ve tcpdump the whole traffic from VM-X to VM-A on each point of the
> platfrom:
>
> from inside the VM-X nic, on the tap device, on the qbr bridge, on the qvb
> veth, on the qvo second side of the veth through the ovs bridges and
> vice-versa.
>
> However the response packets aren?t reaching back further than on the VM-A
> qvo veth.
> Once it exit the VM-A the traffic never reaches the VM-X.
>
> What?s really suspicious in here is that a direct ping from VM-X
> (172.16.31.54) to VM-A (172.16.31.23) is coming back correctly, so it looks
> like if ovs detected that the response on a SNAT case isn?t legit or
> something similar.
>
> Is anyone able to get such setup working?
>
> Here are few additional information:
> Host runs on CentOS 8.5 latest update.
> Our platform is a Openstack Victoria deployed using kolla-ansible.
> We are using a OVS based deployment.
> Our tunnels are VXLAN.
> All VMs have a fully open secgroup applied and all ports have it (I
> checked it twice and even on host iptables).
>
> If you ever need additional information feel free to let me know !
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/1fc03c2c/attachment-0001.htm>

From gael.therond at bitswalk.com  Tue Mar  8 21:59:23 2022
From: gael.therond at bitswalk.com (=?UTF-8?Q?Ga=C3=ABl_THEROND?=)
Date: Tue, 8 Mar 2022 22:59:23 +0100
Subject: [VICTORIA] Not working SNAT over VXLAN?
In-Reply-To: <CAOAKi8wA=bk2v2iHZgQT6Yp2baEx40a8AytBbe2cJtF6gwL-6Q@mail.gmail.com>
References: <CABNe=Utwt0dVuzzyCbVw63WoSr4s9w0kfUNkPLsDJp7fNt97mA@mail.gmail.com>
 <CAOAKi8wA=bk2v2iHZgQT6Yp2baEx40a8AytBbe2cJtF6gwL-6Q@mail.gmail.com>
Message-ID: <CABNe=UvCDXmhx0iD9CHtKPpiuDe=cLjw-66a9oUNStMyGwxn0g@mail.gmail.com>

Interesting I?ve thought about especially because of the anti-spoofing
features but I had the feeling that Security-groups if assigned to the port
would have allowed it.

Additionally, what?s really weird is that one of our k8s clusters using
flannel and/or calico (depends on the user needs) is actually putting those
exact rules (SNAT+FORWARD rules) automatically for pods services ingress
access but I?m wondering if it works because the traffic is on a tunnel
that the host can?t see.

I?ll have a look at your idea by disabling the port security and check if
it work like that. If it works then I?ll re-enable it and work with the
allowed-pairs.

Many thanks!

Le mar. 8 mars 2022 ? 22:13, Laurent Dumont <laurentfdumont at gmail.com> a
?crit :

> You might want to look at port-security on the bastion host VM. If it's
> enabled, it means that Openstack will drop any outgoing packets that are
> not sourced using the ip address + mac AND/OR the allowed_pairs defined on
> the port.
>
> On Tue, Mar 8, 2022 at 3:07 PM Ga?l THEROND <gael.therond at bitswalk.com>
> wrote:
>
>> Hi everyone!
>>
>> I?m facing a weird situation on a tenant of one of our Openstack cluster
>> based on Victoria.
>>
>> On this tenant, the network topology is as follow:
>>
>> One DMZ network (192.168.0.0/24) linked to our public network through a
>> neutron router where there is a VM acting as a bastion/router for the MGMT
>> network.
>>
>> One MGMT network (172.16.31.0/24) where all VMs are linked to.
>>
>> On the DMZ network, there is a linux Debian 11, let?s call it VM-A with a
>> Floating IP from the public pool, this VM is both attached to the DMZ
>> network (ens3 / 192.168.0.12) AND the MGMT network (ens4 / 172.16.31.23).
>>
>> All other VMs, let?s call them VM-X are exclusively attached to the MGMT
>> network (ens4).
>>
>> I?ve setup VM-A with ip_forward kernel module and the following iptables
>> rule:
>>
>> # iptables -t nat -A POSTROUTING -o ens3 -J SNAT ?to-source 192.168.0.12
>>
>> My VM-X are on their own setup with a default gateway via VM-A:
>>
>> # ip route add default via 172.31.16.23
>>
>> The setup seems to be working as if I don?t put the iptables rule and the
>> kernel forwarding I can?t see any packets on my DMZ interface (ens3) on
>> VM-A from VM-X.
>>
>> Ok so now that you get the whole schema, let dive into the issue.
>>
>> So when all rules, modules and gateway are set, I can fully see my VM-X
>> traffic (ICMP ping to a dns server) going from VM-X (ens4) to VM-A (ens4)
>> then forwarded to VM-A (ens3) and finally going to our public IP targeted
>> service.
>>
>> What?s not working however is the response not reaching back to VM-X.
>>
>> I?ve tcpdump the whole traffic from VM-X to VM-A on each point of the
>> platfrom:
>>
>> from inside the VM-X nic, on the tap device, on the qbr bridge, on the
>> qvb veth, on the qvo second side of the veth through the ovs bridges and
>> vice-versa.
>>
>> However the response packets aren?t reaching back further than on the
>> VM-A qvo veth.
>> Once it exit the VM-A the traffic never reaches the VM-X.
>>
>> What?s really suspicious in here is that a direct ping from VM-X
>> (172.16.31.54) to VM-A (172.16.31.23) is coming back correctly, so it looks
>> like if ovs detected that the response on a SNAT case isn?t legit or
>> something similar.
>>
>> Is anyone able to get such setup working?
>>
>> Here are few additional information:
>> Host runs on CentOS 8.5 latest update.
>> Our platform is a Openstack Victoria deployed using kolla-ansible.
>> We are using a OVS based deployment.
>> Our tunnels are VXLAN.
>> All VMs have a fully open secgroup applied and all ports have it (I
>> checked it twice and even on host iptables).
>>
>> If you ever need additional information feel free to let me know !
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/31abc9de/attachment.htm>

From haleyb.dev at gmail.com  Tue Mar  8 22:47:06 2022
From: haleyb.dev at gmail.com (Brian Haley)
Date: Tue, 8 Mar 2022 17:47:06 -0500
Subject: IPv6 deployment on OpenStack
In-Reply-To: <BA82712D-C40D-4B22-899B-6FBEDB52920B@viarezo.fr>
References: <B30F2915-674E-4029-9F1A-D25589FFF056@viarezo.fr>
 <14575046.tv2OnDr8pf@p1> <8195F0AD-5FE8-432C-A1A7-8EB287B13C64@viarezo.fr>
 <2536429.7s5MMGUR32@p1> <BA82712D-C40D-4B22-899B-6FBEDB52920B@viarezo.fr>
Message-ID: <a821fd11-e88b-28f5-d2d3-705e52ee3823@gmail.com>

Hi Marc-Antoine,

See inline...

On 3/8/22 11:18, Marc-Antoine Godde wrote:
> Hi,
> 
> Here?s what we?ve done.
> 
> We created a network:
> 
> Name
>     ipv6-testing-network
> ID
>     9d5ca309-1861-4422-bcff-8818f9762a6f
> Project ID
>     653f5a2e60d34768a8629e5d4fca0738
> Status
>     Active
> Admin State
>     UP
> Shared
>     Yes
> External Network
>     Yes
> MTU
>     1500
> Provider Network
>     Network Type: vlan
>     Physical Network: vlan
>     Segmentation ID: 51

So this is an external provider network connected to your datacenter 
network, correct? In the case Slawek was describing I believe he was 
talking about an internal private network, which when a neutron router 
is attached will trigger radvd to be spawned, etc.

In this case VMs booted on this network should be seeing RAs from your 
datacenter router, if it's sending them. If it's not that would explain 
why they only have a link-local IPv6 address since the neutron router 
will not spawn radvd to run on the external network.

BTW, I'm trying to compare this to my local setup, but since I'm not 
running Horizon just using 'openstack network show...', 'openstack 
subnet show...' output, which is slightly different, but looks to match 
what you're doing.

Is your plan to have private IPv6 subnets that are then routed to your 
external network or is this just a test?

-Brian


> We created a subnet:
> 
> Name
>     ipv6-testing-v6
> ID
>     763771d4-b9d7-419a-ba04-97ce3abaf152
> Project ID
>     653f5a2e60d34768a8629e5d4fca0738
> Network Name
>     ipv6-testing-network
> Network ID
>     9d5ca309-1861-4422-bcff-8818f9762a6f
>     <https://openstack.viarezo.fr/project/networks/9d5ca309-1861-4422-bcff-8818f9762a6f/detail>
> Subnet Pool
>     None
> IP Version
>     IPv6
> CIDR
>     xxxx:xxxx:2f1:aaaa::/64
> IP Allocation Pools
>     Start xxxx:xxxx:2f1:aaaa::2 - End xxxx:xxxx:2f1:aaaa:ffff:ffff:ffff:ffff
> Gateway IP
>     xxxx:xxxx:2f1:aaaa::1
> DHCP Enabled
>     Yes
> IPv6 Address Configuration Mode
>     SLAAC: Address discovered from OpenStack Router
> Additional Routes
>     None
> DNS Name Servers
>     None
> 
> 
> We created Ubuntu and Debian instances. According to Horizon, the 
> instance IPv6 is xxxx:xxxx:2f1:aaaa:f816:3eff:fe6d:c41a. Yet, we only 
> have a link local?address which is fe80::f816:3eff:fe6d:c41a/64. TCPdump 
> indicates no Router Advertisement. We tried with and without adding a 
> router on the Network in Horizon. ICMPv6 is authorized in INGRESS from ::/0.
> 
> We checked on the controllers, the computes and in the Neutron 
> containers, systemctl indicated no instance of RADVD. Maybe we checked 
> incorrectly...
> 
> Do you have any?suggestions ? I add that we are working with OpenStack 
> Ussuri deployed with OpenStack-ansible.
> 
> Thanks,
> Marc-Antoine
> 
> 
>> Le 8 mars 2022 ? 08:59, Slawek Kaplonski <skaplons at redhat.com 
>> <mailto:skaplons at redhat.com>> a ?crit :
>>
>> Hi,
>>
>> On poniedzia?ek, 7 marca 2022 10:36:30 CET Marc-Antoine Godde wrote:
>>> Hello,
>>>
>>> Thanks for your answer.
>>>
>>> If I?m correct, we can just use a virtual router with SLAAC since 
>>> RADVD can deal with RS and emit RA (with support for RFC6106), right ?
>>
>> Yes, virtual router created in the Neutron is enough there. It will 
>> spawn radvd in the qrouter namespace and will send RA to the Vms.
>> Please note that Neutron don't supports privacy extension [1] so You 
>> will need to make sure that it's disabled it on Your vms.
>>
>>> More generally, aren?t we suppose to have a virtual router every 
>>> time, even in DHCPv6 (stateless and statefull), to answer RS ? I have 
>>> to admit that I?m not very familiar at the moment with the 
>>> implementations of RFCs in OpenStack.
>>>
>>> Currently, we prefer the idea of adding IPv6 through SLAAC to have a 
>>> uniform network. If we do so, we?d like to avoid sending RA from our 
>>> physical router to limit its load. Yet, we do not any other arguments 
>>> to support this choice.
>>> Do you have any recommendations on what to do in latest versions of 
>>> OpenStack ? What is usually done ?
>>
>> TBH I don't have such experience. That's more question to operators of 
>> OpenStack.
>>
>>>
>>> Thanks,
>>> Marc-Antoine
>>>
>>>> Le 7 mars 2022 ? 09:12, Slawek Kaplonski <skaplons at redhat.com 
>>>> <mailto:skaplons at redhat.com>> a ?crit :
>>>>
>>>> Hi,
>>>>
>>>> On poniedzia?ek, 7 marca 2022 02:36:24 CET Marc-Antoine Godde wrote:
>>>>> Hello.
>>>>>
>>>>> We are progressively adding support for IPv6 in my company. We 
>>>>> decided to use SLAAC only for laptops, phones, ? since DHCPv6 isn?t 
>>>>> supported on Android. RDNSS support will also increase. We are now 
>>>>> planning our deployment on OpenStack. We already know that we'll 
>>>>> rely only on neutron but we are not yet fixed between DHCPv6 and 
>>>>> SLAAC ? Do you have any arguments for one these for VMs ?
>>>>>
>>>>> Thanks,
>>>>> Marc-Antoine.
>>>>>
>>>>
>>>> With SLAAC You need to have Your network connected to the router in 
>>>> Neutron and You can only configure IP address on the VM. With DHCPv6 
>>>> You can configure other things, like some static-routes, etc.
>>>> Neutron supports DHCPv6 in the stateful and stateless variants. With 
>>>> stateless, You are using RA for address configuration and DHCP 
>>>> server for other configation. Please see [1] for more details.
>>>>
>>>> [1] 
>>>> https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports 
>>>> <https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports>
>>>>
>>>
>>>
>>
>> [1]https://datatracker.ietf.org/doc/html/rfc4941 
>> <https://datatracker.ietf.org/doc/html/rfc4941>
>>
>> --
>> Slawek Kaplonski
>> Principal Software Engineer
>> Red Hat
> 


From marc-antoine.godde at viarezo.fr  Wed Mar  9 02:08:39 2022
From: marc-antoine.godde at viarezo.fr (Marc-Antoine Godde)
Date: Wed, 9 Mar 2022 03:08:39 +0100
Subject: IPv6 deployment on OpenStack
In-Reply-To: <a821fd11-e88b-28f5-d2d3-705e52ee3823@gmail.com>
References: <B30F2915-674E-4029-9F1A-D25589FFF056@viarezo.fr>
 <14575046.tv2OnDr8pf@p1> <8195F0AD-5FE8-432C-A1A7-8EB287B13C64@viarezo.fr>
 <2536429.7s5MMGUR32@p1> <BA82712D-C40D-4B22-899B-6FBEDB52920B@viarezo.fr>
 <a821fd11-e88b-28f5-d2d3-705e52ee3823@gmail.com>
Message-ID: <9F9D2AF2-6C76-45F2-8227-51DB2623BEFC@viarezo.fr>

Hello,

Indeed, this network is connected to our physical network (VLAN 51 for testing), xxxx:xxxx:2f1:aaaa::1 is an interface on our physical router.

Finally, we successfully started RADVD by adding a network interface in the subnet to a virtual router in OpenStack. This gave IPs to VMs, they were able to communicate between each other. Obviously, this network topology isn?t making any sense, we can?t route traffic outside. It was just for testing.

Now, the goal is route the traffic of VMs. I see two paradigms. The first one, we use our physical router to send RA directly to VMs. The second one, we use a private subnet (xxxx:xxxx:2f1:bbbb::/64 for instance) in a non external network of OpenStack. We add a virtual router to that subnet, we now have RADVD. We use that router to route traffic to an external network of OpenStack. What is best ?

Marc-Antoine

> Le 8 mars 2022 ? 23:47, Brian Haley <haleyb.dev at gmail.com> a ?crit :
> 
> Hi Marc-Antoine,
> 
> See inline...
> 
> On 3/8/22 11:18, Marc-Antoine Godde wrote:
>> Hi,
>> Here?s what we?ve done.
>> We created a network:
>> Name
>>    ipv6-testing-network
>> ID
>>    9d5ca309-1861-4422-bcff-8818f9762a6f
>> Project ID
>>    653f5a2e60d34768a8629e5d4fca0738
>> Status
>>    Active
>> Admin State
>>    UP
>> Shared
>>    Yes
>> External Network
>>    Yes
>> MTU
>>    1500
>> Provider Network
>>    Network Type: vlan
>>    Physical Network: vlan
>>    Segmentation ID: 51
> 
> So this is an external provider network connected to your datacenter network, correct? In the case Slawek was describing I believe he was talking about an internal private network, which when a neutron router is attached will trigger radvd to be spawned, etc.
> 
> In this case VMs booted on this network should be seeing RAs from your datacenter router, if it's sending them. If it's not that would explain why they only have a link-local IPv6 address since the neutron router will not spawn radvd to run on the external network.
> 
> BTW, I'm trying to compare this to my local setup, but since I'm not running Horizon just using 'openstack network show...', 'openstack subnet show...' output, which is slightly different, but looks to match what you're doing.
> 
> Is your plan to have private IPv6 subnets that are then routed to your external network or is this just a test?
> 
> -Brian
> 
> 
>> We created a subnet:
>> Name
>>    ipv6-testing-v6
>> ID
>>    763771d4-b9d7-419a-ba04-97ce3abaf152
>> Project ID
>>    653f5a2e60d34768a8629e5d4fca0738
>> Network Name
>>    ipv6-testing-network
>> Network ID
>>    9d5ca309-1861-4422-bcff-8818f9762a6f
>>    <https://openstack.viarezo.fr/project/networks/9d5ca309-1861-4422-bcff-8818f9762a6f/detail <https://openstack.viarezo.fr/project/networks/9d5ca309-1861-4422-bcff-8818f9762a6f/detail>>
>> Subnet Pool
>>    None
>> IP Version
>>    IPv6
>> CIDR
>>    xxxx:xxxx:2f1:aaaa::/64
>> IP Allocation Pools
>>    Start xxxx:xxxx:2f1:aaaa::2 - End xxxx:xxxx:2f1:aaaa:ffff:ffff:ffff:ffff
>> Gateway IP
>>    xxxx:xxxx:2f1:aaaa::1
>> DHCP Enabled
>>    Yes
>> IPv6 Address Configuration Mode
>>    SLAAC: Address discovered from OpenStack Router
>> Additional Routes
>>    None
>> DNS Name Servers
>>    None
>> We created Ubuntu and Debian instances. According to Horizon, the instance IPv6 is xxxx:xxxx:2f1:aaaa:f816:3eff:fe6d:c41a. Yet, we only have a link local address which is fe80::f816:3eff:fe6d:c41a/64. TCPdump indicates no Router Advertisement. We tried with and without adding a router on the Network in Horizon. ICMPv6 is authorized in INGRESS from ::/0.
>> We checked on the controllers, the computes and in the Neutron containers, systemctl indicated no instance of RADVD. Maybe we checked incorrectly...
>> Do you have any suggestions ? I add that we are working with OpenStack Ussuri deployed with OpenStack-ansible.
>> Thanks,
>> Marc-Antoine
>>> Le 8 mars 2022 ? 08:59, Slawek Kaplonski <skaplons at redhat.com <mailto:skaplons at redhat.com> <mailto:skaplons at redhat.com <mailto:skaplons at redhat.com>>> a ?crit :
>>> 
>>> Hi,
>>> 
>>> On poniedzia?ek, 7 marca 2022 10:36:30 CET Marc-Antoine Godde wrote:
>>>> Hello,
>>>> 
>>>> Thanks for your answer.
>>>> 
>>>> If I?m correct, we can just use a virtual router with SLAAC since RADVD can deal with RS and emit RA (with support for RFC6106), right ?
>>> 
>>> Yes, virtual router created in the Neutron is enough there. It will spawn radvd in the qrouter namespace and will send RA to the Vms.
>>> Please note that Neutron don't supports privacy extension [1] so You will need to make sure that it's disabled it on Your vms.
>>> 
>>>> More generally, aren?t we suppose to have a virtual router every time, even in DHCPv6 (stateless and statefull), to answer RS ? I have to admit that I?m not very familiar at the moment with the implementations of RFCs in OpenStack.
>>>> 
>>>> Currently, we prefer the idea of adding IPv6 through SLAAC to have a uniform network. If we do so, we?d like to avoid sending RA from our physical router to limit its load. Yet, we do not any other arguments to support this choice.
>>>> Do you have any recommendations on what to do in latest versions of OpenStack ? What is usually done ?
>>> 
>>> TBH I don't have such experience. That's more question to operators of OpenStack.
>>> 
>>>> 
>>>> Thanks,
>>>> Marc-Antoine
>>>> 
>>>>> Le 7 mars 2022 ? 09:12, Slawek Kaplonski <skaplons at redhat.com <mailto:skaplons at redhat.com> <mailto:skaplons at redhat.com <mailto:skaplons at redhat.com>>> a ?crit :
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> On poniedzia?ek, 7 marca 2022 02:36:24 CET Marc-Antoine Godde wrote:
>>>>>> Hello.
>>>>>> 
>>>>>> We are progressively adding support for IPv6 in my company. We decided to use SLAAC only for laptops, phones, ? since DHCPv6 isn?t supported on Android. RDNSS support will also increase. We are now planning our deployment on OpenStack. We already know that we'll rely only on neutron but we are not yet fixed between DHCPv6 and SLAAC ? Do you have any arguments for one these for VMs ?
>>>>>> 
>>>>>> Thanks,
>>>>>> Marc-Antoine.
>>>>>> 
>>>>> 
>>>>> With SLAAC You need to have Your network connected to the router in Neutron and You can only configure IP address on the VM. With DHCPv6 You can configure other things, like some static-routes, etc.
>>>>> Neutron supports DHCPv6 in the stateful and stateless variants. With stateless, You are using RA for address configuration and DHCP server for other configation. Please see [1] for more details.
>>>>> 
>>>>> [1] https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports <https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports><https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports <https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports>>
>>>>> 
>>>> 
>>>> 
>>> 
>>> [1]https://datatracker.ietf.org/doc/html/rfc4941 <https://datatracker.ietf.org/doc/html/rfc4941> <https://datatracker.ietf.org/doc/html/rfc4941 <https://datatracker.ietf.org/doc/html/rfc4941>>
>>> 
>>> --
>>> Slawek Kaplonski
>>> Principal Software Engineer
>>> Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220309/ebfc760f/attachment-0001.htm>

From laurentfdumont at gmail.com  Wed Mar  9 02:20:08 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Tue, 8 Mar 2022 21:20:08 -0500
Subject: [VICTORIA] Not working SNAT over VXLAN?
In-Reply-To: <CABNe=UvCDXmhx0iD9CHtKPpiuDe=cLjw-66a9oUNStMyGwxn0g@mail.gmail.com>
References: <CABNe=Utwt0dVuzzyCbVw63WoSr4s9w0kfUNkPLsDJp7fNt97mA@mail.gmail.com>
 <CAOAKi8wA=bk2v2iHZgQT6Yp2baEx40a8AytBbe2cJtF6gwL-6Q@mail.gmail.com>
 <CABNe=UvCDXmhx0iD9CHtKPpiuDe=cLjw-66a9oUNStMyGwxn0g@mail.gmail.com>
Message-ID: <CAOAKi8zHqtkuNg=Wyhai0JajiJXweB00e38avnJULM2_YtS8xA@mail.gmail.com>

Any overlay inside the vxlan overlay should work. Since it encapsulates the
actual pod/service traffic, Openstack has no clue and happily forwards the
traffic since it matches the spec (mac + IP) of the port.

Using only security groups will not let you spoof traffic/act as a router.

   - If you want to keep using security groups, you will need allowed-pairs.
      - You can use a subnet as a wildcard / or use the IP address
      specifically.
   - If you dont mind very permissive rules, then disabling port-security
   will require you to remove security groups + allowed-ip-pairs.


On Tue, Mar 8, 2022 at 4:59 PM Ga?l THEROND <gael.therond at bitswalk.com>
wrote:

> Interesting I?ve thought about especially because of the anti-spoofing
> features but I had the feeling that Security-groups if assigned to the port
> would have allowed it.
>
> Additionally, what?s really weird is that one of our k8s clusters using
> flannel and/or calico (depends on the user needs) is actually putting those
> exact rules (SNAT+FORWARD rules) automatically for pods services ingress
> access but I?m wondering if it works because the traffic is on a tunnel
> that the host can?t see.
>
> I?ll have a look at your idea by disabling the port security and check if
> it work like that. If it works then I?ll re-enable it and work with the
> allowed-pairs.
>
> Many thanks!
>
> Le mar. 8 mars 2022 ? 22:13, Laurent Dumont <laurentfdumont at gmail.com> a
> ?crit :
>
>> You might want to look at port-security on the bastion host VM. If it's
>> enabled, it means that Openstack will drop any outgoing packets that are
>> not sourced using the ip address + mac AND/OR the allowed_pairs defined on
>> the port.
>>
>> On Tue, Mar 8, 2022 at 3:07 PM Ga?l THEROND <gael.therond at bitswalk.com>
>> wrote:
>>
>>> Hi everyone!
>>>
>>> I?m facing a weird situation on a tenant of one of our Openstack cluster
>>> based on Victoria.
>>>
>>> On this tenant, the network topology is as follow:
>>>
>>> One DMZ network (192.168.0.0/24) linked to our public network through a
>>> neutron router where there is a VM acting as a bastion/router for the MGMT
>>> network.
>>>
>>> One MGMT network (172.16.31.0/24) where all VMs are linked to.
>>>
>>> On the DMZ network, there is a linux Debian 11, let?s call it VM-A with
>>> a Floating IP from the public pool, this VM is both attached to the DMZ
>>> network (ens3 / 192.168.0.12) AND the MGMT network (ens4 / 172.16.31.23).
>>>
>>> All other VMs, let?s call them VM-X are exclusively attached to the MGMT
>>> network (ens4).
>>>
>>> I?ve setup VM-A with ip_forward kernel module and the following iptables
>>> rule:
>>>
>>> # iptables -t nat -A POSTROUTING -o ens3 -J SNAT ?to-source 192.168.0.12
>>>
>>> My VM-X are on their own setup with a default gateway via VM-A:
>>>
>>> # ip route add default via 172.31.16.23
>>>
>>> The setup seems to be working as if I don?t put the iptables rule and
>>> the kernel forwarding I can?t see any packets on my DMZ interface (ens3) on
>>> VM-A from VM-X.
>>>
>>> Ok so now that you get the whole schema, let dive into the issue.
>>>
>>> So when all rules, modules and gateway are set, I can fully see my VM-X
>>> traffic (ICMP ping to a dns server) going from VM-X (ens4) to VM-A (ens4)
>>> then forwarded to VM-A (ens3) and finally going to our public IP targeted
>>> service.
>>>
>>> What?s not working however is the response not reaching back to VM-X.
>>>
>>> I?ve tcpdump the whole traffic from VM-X to VM-A on each point of the
>>> platfrom:
>>>
>>> from inside the VM-X nic, on the tap device, on the qbr bridge, on the
>>> qvb veth, on the qvo second side of the veth through the ovs bridges and
>>> vice-versa.
>>>
>>> However the response packets aren?t reaching back further than on the
>>> VM-A qvo veth.
>>> Once it exit the VM-A the traffic never reaches the VM-X.
>>>
>>> What?s really suspicious in here is that a direct ping from VM-X
>>> (172.16.31.54) to VM-A (172.16.31.23) is coming back correctly, so it looks
>>> like if ovs detected that the response on a SNAT case isn?t legit or
>>> something similar.
>>>
>>> Is anyone able to get such setup working?
>>>
>>> Here are few additional information:
>>> Host runs on CentOS 8.5 latest update.
>>> Our platform is a Openstack Victoria deployed using kolla-ansible.
>>> We are using a OVS based deployment.
>>> Our tunnels are VXLAN.
>>> All VMs have a fully open secgroup applied and all ports have it (I
>>> checked it twice and even on host iptables).
>>>
>>> If you ever need additional information feel free to let me know !
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/ded60387/attachment.htm>

From laurentfdumont at gmail.com  Wed Mar  9 02:25:28 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Tue, 8 Mar 2022 21:25:28 -0500
Subject: IPv6 deployment on OpenStack
In-Reply-To: <9F9D2AF2-6C76-45F2-8227-51DB2623BEFC@viarezo.fr>
References: <B30F2915-674E-4029-9F1A-D25589FFF056@viarezo.fr>
 <14575046.tv2OnDr8pf@p1> <8195F0AD-5FE8-432C-A1A7-8EB287B13C64@viarezo.fr>
 <2536429.7s5MMGUR32@p1> <BA82712D-C40D-4B22-899B-6FBEDB52920B@viarezo.fr>
 <a821fd11-e88b-28f5-d2d3-705e52ee3823@gmail.com>
 <9F9D2AF2-6C76-45F2-8227-51DB2623BEFC@viarezo.fr>
Message-ID: <CAOAKi8z+W8K+upWkLf1R+MYQpgnOMN4jLN2=s7amaJNpVVECzg@mail.gmail.com>

That really depends on if you want Openstack to play an active role.

If the VMs are only connected to the Provider/External network on VLAN51,
than SLAAC should happen without Openstack being involved. If you tcpdump
on those VM, you should have seen the RA or some kind of traffic arrive.

If the VMs are getting the RA for the qrouter in Openstack, I do believe
that your gateway might become the link-local on that qrouter. This means
that the qrouter is now processing the out of subnet traffic for those VMs.
That might not be the expected flow.

On Tue, Mar 8, 2022 at 9:14 PM Marc-Antoine Godde <
marc-antoine.godde at viarezo.fr> wrote:

> Hello,
>
> Indeed, this network is connected to our physical network (VLAN 51 for
> testing), xxxx:xxxx:2f1:aaaa::1 is an interface on our physical router.
>
> Finally, we successfully started RADVD by adding a network interface in
> the subnet to a virtual router in OpenStack. This gave IPs to VMs, they
> were able to communicate between each other. Obviously, this network
> topology isn?t making any sense, we can?t route traffic outside. It was
> just for testing.
>
> Now, the goal is route the traffic of VMs. I see two paradigms. The first
> one, we use our physical router to send RA directly to VMs. The second one,
> we use a private subnet (xxxx:xxxx:2f1:bbbb::/64 for instance) in a non
> external network of OpenStack. We add a virtual router to that subnet, we
> now have RADVD. We use that router to route traffic to an external network
> of OpenStack. What is best ?
>
> Marc-Antoine
>
> Le 8 mars 2022 ? 23:47, Brian Haley <haleyb.dev at gmail.com> a ?crit :
>
> Hi Marc-Antoine,
>
> See inline...
>
> On 3/8/22 11:18, Marc-Antoine Godde wrote:
>
> Hi,
> Here?s what we?ve done.
> We created a network:
> Name
>    ipv6-testing-network
> ID
>    9d5ca309-1861-4422-bcff-8818f9762a6f
> Project ID
>    653f5a2e60d34768a8629e5d4fca0738
> Status
>    Active
> Admin State
>    UP
> Shared
>    Yes
> External Network
>    Yes
> MTU
>    1500
> Provider Network
>    Network Type: vlan
>    Physical Network: vlan
>    Segmentation ID: 51
>
>
> So this is an external provider network connected to your datacenter
> network, correct? In the case Slawek was describing I believe he was
> talking about an internal private network, which when a neutron router is
> attached will trigger radvd to be spawned, etc.
>
> In this case VMs booted on this network should be seeing RAs from your
> datacenter router, if it's sending them. If it's not that would explain why
> they only have a link-local IPv6 address since the neutron router will not
> spawn radvd to run on the external network.
>
> BTW, I'm trying to compare this to my local setup, but since I'm not
> running Horizon just using 'openstack network show...', 'openstack subnet
> show...' output, which is slightly different, but looks to match what
> you're doing.
>
> Is your plan to have private IPv6 subnets that are then routed to your
> external network or is this just a test?
>
> -Brian
>
>
> We created a subnet:
> Name
>    ipv6-testing-v6
> ID
>    763771d4-b9d7-419a-ba04-97ce3abaf152
> Project ID
>    653f5a2e60d34768a8629e5d4fca0738
> Network Name
>    ipv6-testing-network
> Network ID
>    9d5ca309-1861-4422-bcff-8818f9762a6f
>    <
> https://openstack.viarezo.fr/project/networks/9d5ca309-1861-4422-bcff-8818f9762a6f/detail
> >
> Subnet Pool
>    None
> IP Version
>    IPv6
> CIDR
>    xxxx:xxxx:2f1:aaaa::/64
> IP Allocation Pools
>    Start xxxx:xxxx:2f1:aaaa::2 - End xxxx:xxxx:2f1:aaaa:ffff:ffff:ffff:ffff
> Gateway IP
>    xxxx:xxxx:2f1:aaaa::1
> DHCP Enabled
>    Yes
> IPv6 Address Configuration Mode
>    SLAAC: Address discovered from OpenStack Router
> Additional Routes
>    None
> DNS Name Servers
>    None
> We created Ubuntu and Debian instances. According to Horizon, the instance
> IPv6 is xxxx:xxxx:2f1:aaaa:f816:3eff:fe6d:c41a. Yet, we only have a link
> local address which is fe80::f816:3eff:fe6d:c41a/64. TCPdump indicates no
> Router Advertisement. We tried with and without adding a router on the
> Network in Horizon. ICMPv6 is authorized in INGRESS from ::/0.
> We checked on the controllers, the computes and in the Neutron containers,
> systemctl indicated no instance of RADVD. Maybe we checked incorrectly...
> Do you have any suggestions ? I add that we are working with OpenStack
> Ussuri deployed with OpenStack-ansible.
> Thanks,
> Marc-Antoine
>
> Le 8 mars 2022 ? 08:59, Slawek Kaplonski <skaplons at redhat.com <
> mailto:skaplons at redhat.com <skaplons at redhat.com>>> a ?crit :
>
> Hi,
>
> On poniedzia?ek, 7 marca 2022 10:36:30 CET Marc-Antoine Godde wrote:
>
> Hello,
>
> Thanks for your answer.
>
> If I?m correct, we can just use a virtual router with SLAAC since RADVD
> can deal with RS and emit RA (with support for RFC6106), right ?
>
>
> Yes, virtual router created in the Neutron is enough there. It will spawn
> radvd in the qrouter namespace and will send RA to the Vms.
> Please note that Neutron don't supports privacy extension [1] so You will
> need to make sure that it's disabled it on Your vms.
>
> More generally, aren?t we suppose to have a virtual router every time,
> even in DHCPv6 (stateless and statefull), to answer RS ? I have to admit
> that I?m not very familiar at the moment with the implementations of RFCs
> in OpenStack.
>
> Currently, we prefer the idea of adding IPv6 through SLAAC to have a
> uniform network. If we do so, we?d like to avoid sending RA from our
> physical router to limit its load. Yet, we do not any other arguments to
> support this choice.
> Do you have any recommendations on what to do in latest versions of
> OpenStack ? What is usually done ?
>
>
> TBH I don't have such experience. That's more question to operators of
> OpenStack.
>
>
> Thanks,
> Marc-Antoine
>
> Le 7 mars 2022 ? 09:12, Slawek Kaplonski <skaplons at redhat.com <
> mailto:skaplons at redhat.com <skaplons at redhat.com>>> a ?crit :
>
> Hi,
>
> On poniedzia?ek, 7 marca 2022 02:36:24 CET Marc-Antoine Godde wrote:
>
> Hello.
>
> We are progressively adding support for IPv6 in my company. We decided to
> use SLAAC only for laptops, phones, ? since DHCPv6 isn?t supported on
> Android. RDNSS support will also increase. We are now planning our
> deployment on OpenStack. We already know that we'll rely only on neutron
> but we are not yet fixed between DHCPv6 and SLAAC ? Do you have any
> arguments for one these for VMs ?
>
> Thanks,
> Marc-Antoine.
>
>
> With SLAAC You need to have Your network connected to the router in
> Neutron and You can only configure IP address on the VM. With DHCPv6 You
> can configure other things, like some static-routes, etc.
> Neutron supports DHCPv6 in the stateful and stateless variants. With
> stateless, You are using RA for address configuration and DHCP server for
> other configation. Please see [1] for more details.
>
> [1]
> https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports
> <
> https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports
> >
>
>
>
>
> [1]https://datatracker.ietf.org/doc/html/rfc4941 <
> https://datatracker.ietf.org/doc/html/rfc4941>
>
> --
> Slawek Kaplonski
> Principal Software Engineer
> Red Hat
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220308/c2d4e178/attachment-0001.htm>

From tkajinam at redhat.com  Wed Mar  9 05:46:21 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Wed, 9 Mar 2022 14:46:21 +0900
Subject: [heat][rbac] Management of "system resources" with SRBAC enforced
Message-ID: <CAL_crJSy6_-+0oLZC1PP=RoE-2fNMn0jytsv9UxJOZ2BxYbeeQ@mail.gmail.com>

Hello,


I've been working on updating policy rules in heat according to the latest
guideline for SRBAC implementation.

Based on the recent direction change[1], now only project users are allowed
to create project-based resources like instances or networks. I'm updating
policy rules in heat so that only project users can manage project resources
in Heat like stacks or resources.

 [1]
https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#direction-change

However this change reveals one potential issue with system resources.

In heat there are some resource types like OS::Nova::Flavor or
OS::Keystone::User
which is allowed for only system users. (I'll call these resources as
"system resources" here)

Because heat uses user credentials to create resources in backend services,
if we require
project scope for stack/resource management then we are no longer able to
create these system
resources as part of stack. (*1)

There are some options I can think of at this moment.

1. Deprecate and remove all resources which require system scope
Pros
- This is most easy solution to be implemented
Cons
- This one has the biggest user impact

2. Use service credential for resource creation
Pros:
- This might have smallest user impact
Cons:
- This requires a relatively big change in heat's architecture, which I've
not yet evaluated.
- We need to determine the project scope role to be allowed to do system
operation.

3. Implement additional project-role in each service to allow creation via
stack creation.
Pros:
- This would avoid user impact.
Cons:
- requires work in multiple components.
- We need to determine the project scope role to be allowed to do system
operation.

I'm not quite sure which one would be the best. If I can ask for some
feedback about these options
(or any other new options) from heat's perspective and rbac's perspective
then it would be nice.

(*1)
As of now, nova and neutron no longer allow creating system users to create
project resources,
so system users are no longer able to create stacks with project resources
like instances or networks
with default "new" policies.

Thank you,
Takashi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220309/c4b1f704/attachment.htm>

From tkajinam at redhat.com  Wed Mar  9 06:01:46 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Wed, 9 Mar 2022 15:01:46 +0900
Subject: [puppet] Gate blocker: CentOS 9 integration jobs are broken
In-Reply-To: <CAL_crJTJz+BjSsg+NyTAdhvC9HL_F2WR3-TtUs1nWGY30ZN3Tg@mail.gmail.com>
References: <CAL_crJSq8sfwqybc9CC_iQ6sqHFSQNaFnE6uReNfyofch=icKg@mail.gmail.com>
 <CAL_crJTJz+BjSsg+NyTAdhvC9HL_F2WR3-TtUs1nWGY30ZN3Tg@mail.gmail.com>
Message-ID: <CAL_crJTrYvHcUHK+QBB0qgPGP6y632VmT+AuYkir+64PX-fXqA@mail.gmail.com>

Both of the two issues have been resolved and c9s integration jobs are
voting again.

As a side note, It seems the second issue within tempest tests was caused
by recent
change in openssl in CentOS9 Stream repo and rsa key is no longer allowed
for ssh.
We worked around the issue by the feature in tempest to use a different
format but
I've submitted a feedback to know about current usage of rsa key[1].
 [1] https://bugs.launchpad.net/nova/+bug/1962726


On Tue, Mar 1, 2022 at 10:47 PM Takashi Kajinami <tkajinam at redhat.com>
wrote:

> Unfortunately I've not yet managed to implement a workaround and it's
> likely
> I need some more time to fix it, I'm merging the patch to make c9s jobs
> non-voting.
>
> https://review.opendev.org/c/openstack/puppet-openstack-integration/+/831183
>
> I'll revert that change once we can implement workaround/solution.
>
> On Tue, Mar 1, 2022 at 11:11 AM Takashi Kajinami <tkajinam at redhat.com>
> wrote:
>
>> Hi,
>>
>> Please be aware that currently CentOS 9 integration jobs are broken
>> because of the two problems caused by recent updates in c9s repos.
>>  https://bugs.launchpad.net/puppet-openstack-integration/+bug/1962506
>>  https://bugs.launchpad.net/puppet-openstack-integration/+bug/1962507
>>
>> I'm currently working on implementing workaround[1], but in case it would
>> take
>> some time, I'll make c9s integration jobs non-voting again to unblock our
>> gate.
>> [1]
>> https://review.opendev.org/c/openstack/puppet-openstack-integration/+/831197
>>
>> Please avoid approving changes which require integration jobs.
>>
>> Thank you,
>> Takashi
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220309/c78836a1/attachment.htm>

From mkopec at redhat.com  Wed Mar  9 07:00:00 2022
From: mkopec at redhat.com (Martin Kopec)
Date: Wed, 9 Mar 2022 08:00:00 +0100
Subject: [qa] Zed PTG slots
Message-ID: <CAKZGdE3yMk_UA2+jqo7-Jh56xtpKrT6nA-eqaAGR2-t-LOHhrw@mail.gmail.com>

Hello everyone,

based on the doodle poll [1], we have booked the following time slots:
- Monday (April 4th) 13-14 UTC (1 hour) @ Liberty room
- Tuesday (April 5th) 15-17 UTC (2 hours) @ Liberty room
- Thursday (April 7th)  13-14 UTC (1 hour) @ Liberty room

The topics we are going to cover are gathered in this etherpad [2].

If you have anything you would like to discuss with us, please, feel free
to write it to [2].

[1] https://doodle.com/poll/q5yzatzh45brt5v2
[2] https://etherpad.opendev.org/p/qa-zed-ptg

Thank you,
-- 
Martin Kopec
Senior Software Quality Engineer
Red Hat EMEA
IM: kopecmartin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220309/d53a1de1/attachment.htm>

From openstack at a.spamming.party  Wed Mar  9 08:24:18 2022
From: openstack at a.spamming.party (Jean-Philippe Evrard)
Date: Wed, 09 Mar 2022 09:24:18 +0100
Subject: [designate] Architecture help for designate on multi-region/multi-AZ
 deployments
Message-ID: <5c6de844-c996-4140-95a9-380f48a5d3b2@www.fastmail.com>

Hello folks,

I currently have designate installed in a single region in a cloud.
Now we are thinking about the next steps: A multi-region designate for a simple use case: Bring your own domain, have A/AAAA records for your instances regardless of the region.
Side note: That requirement can be modified if what I am asking is impossible.

I didn't find anything in the ML, nor in the bug tracker [1] outside a neutron bug [2] (am I blind?). 
I had a look at the designate documentation, but there are no best practices for multi-region (or am I blind again?)
The only relevant part for integration with neutron is in [3], which is not region related.

I am looking for advice from designate experts here, to see what we can do.

Right now, we are thinking about two ways to deal with this:
A) Install a separate openstack with designate, and make all the regions's neutrons configuration point to a single designate. Neutron would work, designate would be simple to manage (as we have a single designate).
The downside here is the clear-cut separation of regions: I am afraid of how records are stored in the central designate, and if there won't be multi-tenancy issues (uuid could technically overlap, as different regions means different keystones here).
B) Install a designate in each region, with DNS servers in each region. We have strict region separation this way.
The downside is the user friendliness: A customer _can_ decide which region in  which the domain will be hosted. That means that we now need to worry about synchronizing region's state (if you have created a domain in that region, you can't do it elsewhere).

Am I misunderstanding/not seeing something obvious here?

Thank you in advance.

Jean-Philippe Evrard (evrardjp)

[0]: https://www.google.com/search?q=designate+multi+region+site%3Ahttp%3A%2F%2Flists.openstack.org%2Fpipermail%2Fopenstack-discuss%2F
[1]: https://bugs.launchpad.net/designate?field.searchtext=region
[2]:  https://review.opendev.org/c/openstack/neutron/+/684854/  
[3]: https://docs.openstack.org/neutron/latest/admin/config-dns-int-ext-serv.html 












From katonalala at gmail.com  Wed Mar  9 08:25:49 2022
From: katonalala at gmail.com (Lajos Katona)
Date: Wed, 9 Mar 2022 09:25:49 +0100
Subject: [Neutron][Octavia][ovn-octavia-provider] proposing Luis Tomas
 Bolivar for ovn-octavia-provider core reviewer
In-Reply-To: <CAB1EZBrAsQiLC__EmwuBp-EHOYQfummYh-EEgP8ihKDGoZzEwg@mail.gmail.com>
References: <CALg0jKmGBwSPowJRmcwukit1P26NvGeei8ay2VyDaM2BS2wUTg@mail.gmail.com>
 <CAB1EZBrAsQiLC__EmwuBp-EHOYQfummYh-EEgP8ihKDGoZzEwg@mail.gmail.com>
Message-ID: <CALg0jKkk6a-Tve6H4QvGOP1MPyQ8pDuesPKdTTDr20_Fm4SC=w@mail.gmail.com>

Hi,
I added Luis to ovn-octavia-provider-core group, sorry for sending this
mail so late.
Welcome Luis, and thanks for your work !

Lajos Katona (lajoskatona)

Lucas Alvares Gomes <lucasagomes at gmail.com> ezt ?rta (id?pont: 2022. m?rc.
1., K, 9:49):

> +1 from me!
>
> On Mon, Feb 28, 2022 at 2:42 PM Lajos Katona <katonalala at gmail.com> wrote:
> >
> > Hi
> >
> > I would like to propose Luis Tomas Bolivar (ltomasbo) as a core reviewer
> to the ovn-octavia-provider project.
> > Luis is very active in the project (see [1] and [2]) and has experience
> with Kuryr side also which uses ovn-octavia-provider.
> >
> > As ovn-octavia-provider is a link between Neutron and Octavia I ask both
> Neutron and Octavia cores to vote by answering to this thread, to have a
> final decision.
> > Thanks for your consideration
> >
> > [1]:
> https://review.opendev.org/q/owner:ltomasbo%2540redhat.com+branch:master
> > [2]:
> https://www.stackalytics.io/report/contribution?module=neutron-group&project_type=openstack&days=60
> >
> > Cheers
> > Lajos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220309/b52c2e3d/attachment.htm>

From ricolin at ricolky.com  Wed Mar  9 09:20:02 2022
From: ricolin at ricolky.com (Rico Lin)
Date: Wed, 9 Mar 2022 17:20:02 +0800
Subject: [heat][rbac] Management of "system resources" with SRBAC enforced
In-Reply-To: <CAL_crJSy6_-+0oLZC1PP=RoE-2fNMn0jytsv9UxJOZ2BxYbeeQ@mail.gmail.com>
References: <CAL_crJSy6_-+0oLZC1PP=RoE-2fNMn0jytsv9UxJOZ2BxYbeeQ@mail.gmail.com>
Message-ID: <CA+WCyyovVWVhudrs0RGzoKedH7DdRCjgR1dEF5icK9Epr7XOEQ@mail.gmail.com>

On Wed, Mar 9, 2022 at 1:57 PM Takashi Kajinami <tkajinam at redhat.com> wrote:
>
> Hello,
>
>
> I've been working on updating policy rules in heat according to the latest
> guideline for SRBAC implementation.

Thanks so much for working on it, definitely +1 on enhancing security.

>
>  [1]
https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#direction-change
>
> However this change reveals one potential issue with system resources.
>
> In heat there are some resource types like OS::Nova::Flavor or
OS::Keystone::User
> which is allowed for only system users. (I'll call these resources as
"system resources" here)

We create those resources based on checking `role:admin`, so project admin
is accepted.
This means a user under that project with role:admin, can operate those
resources.
I'm not sure what system user means here, so correct me if I'm wrong.

>
> Because heat uses user credentials to create resources in backend
services, if we require
> project scope for stack/resource management then we are no longer able to
create these system
> resources as part of stack. (*1)
>
> There are some options I can think of at this moment.
>
> 1. Deprecate and remove all resources which require system scope
> Pros
> - This is most easy solution to be implemented
> Cons
> - This one has the biggest user impact

Don't :)

> 2. Use service credential for resource creation
> Pros:
> - This might have smallest user impact
> Cons:
> - This requires a relatively big change in heat's architecture, which
I've not yet evaluated.
> - We need to determine the project scope role to be allowed to do system
operation.
>

I think this is something we can discuss more.

> 3. Implement additional project-role in each service to allow creation
via stack creation.
> Pros:
> - This would avoid user impact.
> Cons:
> - requires work in multiple components.
> - We need to determine the project scope role to be allowed to do system
operation


Indeed current stack operation require `(role:admin and system_scope:all)
OR (role:member and project_id:%(project_id)s)`.
And if we remove the system part and keep `(role:member and
project_id:%(project_id)s)`, will mean only a user in that project with a
member role can operate stack, and if the user got also admin role, that
user can manage User/Flavor resources through stack too.

Also, note that
For the case of Nova::Flavor, both policies from Nova and Heat resource
will be enforced here, so it only accepts the intersection part of rules.

So if we go with removing the system admin, that means it's time to also
remove some deprecated global scope operation.

IMO, to accept Project Admin or member make more reasonable (like you
proposed in option 3)

>
> Thank you,
> Takashi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220309/1b86748b/attachment.htm>

From gael.therond at bitswalk.com  Wed Mar  9 09:51:41 2022
From: gael.therond at bitswalk.com (=?UTF-8?Q?Ga=C3=ABl_THEROND?=)
Date: Wed, 9 Mar 2022 10:51:41 +0100
Subject: [VICTORIA] Not working SNAT over VXLAN?
In-Reply-To: <CAOAKi8zHqtkuNg=Wyhai0JajiJXweB00e38avnJULM2_YtS8xA@mail.gmail.com>
References: <CABNe=Utwt0dVuzzyCbVw63WoSr4s9w0kfUNkPLsDJp7fNt97mA@mail.gmail.com>
 <CAOAKi8wA=bk2v2iHZgQT6Yp2baEx40a8AytBbe2cJtF6gwL-6Q@mail.gmail.com>
 <CABNe=UvCDXmhx0iD9CHtKPpiuDe=cLjw-66a9oUNStMyGwxn0g@mail.gmail.com>
 <CAOAKi8zHqtkuNg=Wyhai0JajiJXweB00e38avnJULM2_YtS8xA@mail.gmail.com>
Message-ID: <CABNe=UvROiFnipaLCSJ+fzW7xo-JriuDWsdGJQnU5YMw3C0c6w@mail.gmail.com>

I?ve made few test this morning, disabling port security on the MGMT port
of VM-A (bastion) indeed did the trick and the traffic started to flow
correctly.

I?ve then tested to enable it back and set the allowed_pairs with subnet,
it works too, so the issue is definitely what you were pointing out so big
shout out to you as this options is so deeply burried on the config/ui that
I didn?t thought of it more than that.

Yeah regarding k8s that what I was suspecting, thanks for the confirmation.

However, there is one thing that I can?t get my head around with my simple
router installation.

If VM-X send a ping for let say google.com on its gateway (VM-A), the
packet goes with VM-X mac/ip header, then VM-A thanks to the ip_forward
know that this packet is belonging to another nic which is having the
appropriate default gareway. At this point, we didn?t touched anything on
the packet (to my knowledge) so once we reach the SNAT our packet header
source IP is changed with the external router connected nic IP, then it
flow through dns resolver that answer this IP, once the nic get this
response, it just forward it back to the MGMT nic of the bastion which in
turn answer to the VM-X mgmt nic without doing any spoofing etc.

I?m feeling that I miss something on the way in here, what did I missed on
this flow? At which step VM-A is breaking the law? At forward step?

Le mer. 9 mars 2022 ? 03:20, Laurent Dumont <laurentfdumont at gmail.com> a
?crit :

> Any overlay inside the vxlan overlay should work. Since it encapsulates
> the actual pod/service traffic, Openstack has no clue and happily forwards
> the traffic since it matches the spec (mac + IP) of the port.
>
> Using only security groups will not let you spoof traffic/act as a router.
>
>    - If you want to keep using security groups, you will need
>    allowed-pairs.
>       - You can use a subnet as a wildcard / or use the IP address
>       specifically.
>    - If you dont mind very permissive rules, then disabling port-security
>    will require you to remove security groups + allowed-ip-pairs.
>
>
> On Tue, Mar 8, 2022 at 4:59 PM Ga?l THEROND <gael.therond at bitswalk.com>
> wrote:
>
>> Interesting I?ve thought about especially because of the anti-spoofing
>> features but I had the feeling that Security-groups if assigned to the port
>> would have allowed it.
>>
>> Additionally, what?s really weird is that one of our k8s clusters using
>> flannel and/or calico (depends on the user needs) is actually putting those
>> exact rules (SNAT+FORWARD rules) automatically for pods services ingress
>> access but I?m wondering if it works because the traffic is on a tunnel
>> that the host can?t see.
>>
>> I?ll have a look at your idea by disabling the port security and check if
>> it work like that. If it works then I?ll re-enable it and work with the
>> allowed-pairs.
>>
>> Many thanks!
>>
>> Le mar. 8 mars 2022 ? 22:13, Laurent Dumont <laurentfdumont at gmail.com> a
>> ?crit :
>>
>>> You might want to look at port-security on the bastion host VM. If it's
>>> enabled, it means that Openstack will drop any outgoing packets that are
>>> not sourced using the ip address + mac AND/OR the allowed_pairs defined on
>>> the port.
>>>
>>> On Tue, Mar 8, 2022 at 3:07 PM Ga?l THEROND <gael.therond at bitswalk.com>
>>> wrote:
>>>
>>>> Hi everyone!
>>>>
>>>> I?m facing a weird situation on a tenant of one of our Openstack
>>>> cluster based on Victoria.
>>>>
>>>> On this tenant, the network topology is as follow:
>>>>
>>>> One DMZ network (192.168.0.0/24) linked to our public network through
>>>> a neutron router where there is a VM acting as a bastion/router for the
>>>> MGMT network.
>>>>
>>>> One MGMT network (172.16.31.0/24) where all VMs are linked to.
>>>>
>>>> On the DMZ network, there is a linux Debian 11, let?s call it VM-A with
>>>> a Floating IP from the public pool, this VM is both attached to the DMZ
>>>> network (ens3 / 192.168.0.12) AND the MGMT network (ens4 / 172.16.31.23).
>>>>
>>>> All other VMs, let?s call them VM-X are exclusively attached to the
>>>> MGMT network (ens4).
>>>>
>>>> I?ve setup VM-A with ip_forward kernel module and the following
>>>> iptables rule:
>>>>
>>>> # iptables -t nat -A POSTROUTING -o ens3 -J SNAT ?to-source 192.168.0.12
>>>>
>>>> My VM-X are on their own setup with a default gateway via VM-A:
>>>>
>>>> # ip route add default via 172.31.16.23
>>>>
>>>> The setup seems to be working as if I don?t put the iptables rule and
>>>> the kernel forwarding I can?t see any packets on my DMZ interface (ens3) on
>>>> VM-A from VM-X.
>>>>
>>>> Ok so now that you get the whole schema, let dive into the issue.
>>>>
>>>> So when all rules, modules and gateway are set, I can fully see my VM-X
>>>> traffic (ICMP ping to a dns server) going from VM-X (ens4) to VM-A (ens4)
>>>> then forwarded to VM-A (ens3) and finally going to our public IP targeted
>>>> service.
>>>>
>>>> What?s not working however is the response not reaching back to VM-X.
>>>>
>>>> I?ve tcpdump the whole traffic from VM-X to VM-A on each point of the
>>>> platfrom:
>>>>
>>>> from inside the VM-X nic, on the tap device, on the qbr bridge, on the
>>>> qvb veth, on the qvo second side of the veth through the ovs bridges and
>>>> vice-versa.
>>>>
>>>> However the response packets aren?t reaching back further than on the
>>>> VM-A qvo veth.
>>>> Once it exit the VM-A the traffic never reaches the VM-X.
>>>>
>>>> What?s really suspicious in here is that a direct ping from VM-X
>>>> (172.16.31.54) to VM-A (172.16.31.23) is coming back correctly, so it looks
>>>> like if ovs detected that the response on a SNAT case isn?t legit or
>>>> something similar.
>>>>
>>>> Is anyone able to get such setup working?
>>>>
>>>> Here are few additional information:
>>>> Host runs on CentOS 8.5 latest update.
>>>> Our platform is a Openstack Victoria deployed using kolla-ansible.
>>>> We are using a OVS based deployment.
>>>> Our tunnels are VXLAN.
>>>> All VMs have a fully open secgroup applied and all ports have it (I
>>>> checked it twice and even on host iptables).
>>>>
>>>> If you ever need additional information feel free to let me know !
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220309/d1e91f01/attachment-0001.htm>

From jmeng at redhat.com  Wed Mar  9 10:13:31 2022
From: jmeng at redhat.com (Jakob Meng)
Date: Wed, 9 Mar 2022 11:13:31 +0100
Subject: [ansible-openstack-modules] Zed PTG for Ansible OpenStack collection
Message-ID: <2bb719f4-fb04-870d-21b7-d942850d1a17@redhat.com>

Hi everyone,

we have scheduled a vPTG session for the Ansible OpenStack collection 
[1] project

at 13:00 - 15:00 UTC
on Thursday April 7, 2022
in Essex room.

Please add your name to our etherpad [2] if you plan to attend. Also do 
not hesitate to add any questions and topics you want to address in our 
PTG session. Thank you!

Looking forward to meet you :)

[1] https://opendev.org/openstack/ansible-collections-openstack
[2] https://etherpad.opendev.org/p/aom-zed-ptg

Best regards,
Sagi Shnaidman & Jakob Meng



From tkajinam at redhat.com  Wed Mar  9 12:43:03 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Wed, 9 Mar 2022 21:43:03 +0900
Subject: [heat][rbac] Management of "system resources" with SRBAC enforced
In-Reply-To: <CA+WCyyovVWVhudrs0RGzoKedH7DdRCjgR1dEF5icK9Epr7XOEQ@mail.gmail.com>
References: <CAL_crJSy6_-+0oLZC1PP=RoE-2fNMn0jytsv9UxJOZ2BxYbeeQ@mail.gmail.com>
 <CA+WCyyovVWVhudrs0RGzoKedH7DdRCjgR1dEF5icK9Epr7XOEQ@mail.gmail.com>
Message-ID: <CAL_crJSPv3pmJ31DVJKSurVOLGZM5MOtfapKN1s+DxA-Yhr7AQ@mail.gmail.com>

Hi Rico.

Thank you for your insights.
Please find my replies inline.

On Wed, Mar 9, 2022 at 6:22 PM Rico Lin <ricolin at ricolky.com> wrote:

>
>
> On Wed, Mar 9, 2022 at 1:57 PM Takashi Kajinami <tkajinam at redhat.com>
> wrote:
> >
> > Hello,
> >
> >
> > I've been working on updating policy rules in heat according to the
> latest
> > guideline for SRBAC implementation.
>
> Thanks so much for working on it, definitely +1 on enhancing security.
>
> >
> >  [1]
> https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#direction-change
> >
> > However this change reveals one potential issue with system resources.
> >
> > In heat there are some resource types like OS::Nova::Flavor or
> OS::Keystone::User
> > which is allowed for only system users. (I'll call these resources as
> "system resources" here)
>
> We create those resources based on checking `role:admin`, so project admin
> is accepted.
> This means a user under that project with role:admin, can operate those
> resources.
> I'm not sure what system user means here, so correct me if I'm wrong.
>

The core problem is that backend services like nova enforces different
policies from just role:admin when
SRBAC is enforced. I reported that a while ago as
https://storyboard.openstack.org/#!/story/2009787 .

The main problem here is that heat currently supports resources which
require different scopes of credentials.
For example, once all deprecated policy rules are removed, nova allows
project users to create instances(OS::Nova::Server)[1],
while nova allows only system admins to create
flavors(OS::Nova::Flavor)[2]. Currently Heat leverages the user credential
used to create a stack when Heat requests backend services to create its
resources, and it's "impossible" to create a stack
with these two resources by a single credential (as each token can be
scoped by project or system.

[1]
https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/servers.py#L210
[2]
https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/flavor_manage.py#L28-L36

If we keep allowing system users to create stacks, then it would allow
users to create system resources
like flavors. But this never solves the problem with the "mixed" pattern
which I described above.
Hope this will explain these three options more clearly.


>
> >
> > Because heat uses user credentials to create resources in backend
> services, if we require
> > project scope for stack/resource management then we are no longer able
> to create these system
> > resources as part of stack. (*1)
> >
> > There are some options I can think of at this moment.
> >
> > 1. Deprecate and remove all resources which require system scope
> > Pros
> > - This is most easy solution to be implemented
> > Cons
> > - This one has the biggest user impact
>
> Don't :)
>
> > 2. Use service credential for resource creation
> > Pros:
> > - This might have smallest user impact
> > Cons:
> > - This requires a relatively big change in heat's architecture, which
> I've not yet evaluated.
> > - We need to determine the project scope role to be allowed to do system
> operation.
> >
>
> I think this is something we can discuss more.
>
> > 3. Implement additional project-role in each service to allow creation
> via stack creation.
> > Pros:
> > - This would avoid user impact.
> > Cons:
> > - requires work in multiple components.
> > - We need to determine the project scope role to be allowed to do system
> operation
>
>
> Indeed current stack operation require `(role:admin and system_scope:all)
> OR (role:member and project_id:%(project_id)s)`.
> And if we remove the system part and keep `(role:member and
> project_id:%(project_id)s)`, will mean only a user in that project with a
> member role can operate stack, and if the user got also admin role, that
> user can manage User/Flavor resources through stack too.
>
The main problem here is that nova will no longer allow project admins to
create flavors,
and it will require system admin when SRBAC is enforced(which means all
deprecated rules
are disabled)


>
> Also, note that
> For the case of Nova::Flavor, both policies from Nova and Heat resource
> will be enforced here, so it only accepts the intersection part of rules.
>

> So if we go with removing the system admin, that means it's time to also
> remove some deprecated global scope operation.
>
> IMO, to accept Project Admin or member make more reasonable (like you
> proposed in option 3)
>
> >
> > Thank you,
> > Takashi
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220309/1a7a5a95/attachment.htm>

From tkajinam at redhat.com  Wed Mar  9 13:06:22 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Wed, 9 Mar 2022 22:06:22 +0900
Subject: [puppet][tripleo][neutron][ops] Deprecating support for
 networking-bigswitch
In-Reply-To: <CAL_crJT_2ZHNds7Fp8HM_VMx=JKn1y01uF0c-JxCe6b8qkYbMA@mail.gmail.com>
References: <CAL_crJT_2ZHNds7Fp8HM_VMx=JKn1y01uF0c-JxCe6b8qkYbMA@mail.gmail.com>
Message-ID: <CAL_crJRe1zvReqimQdNLjU6gUdVstykHwJHGtyX_ALLJHQ35tQ@mail.gmail.com>

I'd like to follow up my previous email and let you know that relevant
patches have been merged.
If you have any concerns, please reach out to me or the team in
#puppet-openstack or #tripleo in OFTC.

On Tue, Mar 1, 2022 at 10:58 PM Takashi Kajinami <tkajinam at redhat.com>
wrote:

> Hi,
>
>
> Today I noticed networking-bigswitch has been unmaintained recently.
> The repos have not been updated for 2 years and no release has been made
> since stable/train.
>  https://opendev.org/x/networking-bigswitch
>
> Based on the above observation, I assume no users would be using the plugin
> with recent OpenStack releases and I've proposed deprecating support for
> the plugin
> in puppet-neutron.
>  https://review.opendev.org/c/openstack/puppet-neutron/+/831376
>
> In case if anyone has concern with this, please post your thoughts in the
> above review.
>
> Once this deprecation is approved/merged, I'll remove support for the
> plugin from TripleO
> because implementation in TripleO depends on puppet-neutron.
>
> Thank you,
> Takashi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220309/62cb39e8/attachment.htm>

From tkajinam at redhat.com  Wed Mar  9 13:11:25 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Wed, 9 Mar 2022 22:11:25 +0900
Subject: [puppet][tripleo][neutron][ops] Removing support for Nuage "core"
 plugin
Message-ID: <CAL_crJTEs0JiifJ9dY50brauMbuAr_3fwKvf1QFw_Lz_NHEisw@mail.gmail.com>

Hello,


As part of the clean-up effort in puppet-neutron, I was looking at the git
repository
for nuage plugin and got the observation that Nuage core plugin no longer
exists
and only ml2 plugin is available.

https://github.com/nuagenetworks/nuage-openstack-neutron/commit/06b5fe68630c3ef84f146c14461d8ff6f6091108

Based on that observation, I've proposed some patches to deprecate/remove
support
for Nuage core plugin, which can be found by the following link.
 https://review.opendev.org/q/topic:nuage-core-plugin

Unfortunately I'm not fully familiar with the integration of neutron +
Nuage.
I'd appreciate it if anybody familiar with it can share any concerns here
or in these patches.

Thank you,
Takashi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220309/7fbf6dc5/attachment.htm>

From senrique at redhat.com  Wed Mar  9 13:15:14 2022
From: senrique at redhat.com (Sofia Enriquez)
Date: Wed, 9 Mar 2022 10:15:14 -0300
Subject: [cinder] Bug deputy report for week of 03-09-2022
Message-ID: <CANtmtpH5hPfZVj0JPnFkyC6sVuHe7p0W+sWSU_nw4-rT1ugjyw@mail.gmail.com>

This is a bug report from 03-02-2022 to 03-09-2022.
Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting
-----------------------------------------------------------------------------------------
Low

   - https://bugs.launchpad.net/cinder/+bug/1964145 "Don't require
   control-location for creating encrypted volume types." Fixed proposed to
   master.
   - https://bugs.launchpad.net/cinder/+bug/1962824 "[powerstore driver]:
   no volume caching after 35 volumes." Unassigned.

Cheers
-- 

Sof?a Enriquez

she/her

Software Engineer

Red Hat PnT <https://www.redhat.com>

IRC: @enriquetaso
@RedHat <https://twitter.com/redhat>   Red Hat
<https://www.linkedin.com/company/red-hat>  Red Hat
<https://www.facebook.com/RedHatInc>
<https://www.redhat.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220309/11a14876/attachment-0001.htm>

From ozzzo at yahoo.com  Wed Mar  9 14:58:37 2022
From: ozzzo at yahoo.com (Albert Braden)
Date: Wed, 9 Mar 2022 14:58:37 +0000 (UTC)
Subject: [adjutant][tc][all] Call for volunteers to be a PTL and
 maintainers
In-Reply-To: <4381995.LvFx2qVVIh@p1>
References: <4381995.LvFx2qVVIh@p1>
Message-ID: <1915566590.650011.1646837917079@mail.yahoo.com>

 I'm still waiting for permission to work on Adjutant. My contract ends this month and I'm taking 2 months off before I start fulltime. I have hope that permission will be granted while I'm out. I expect that I will be able to start working on Adjutant in June.
     On Saturday, March 5, 2022, 01:32:13 PM EST, Slawek Kaplonski <skaplons at redhat.com> wrote:  
 
 Hi,

After last PTL elections [1] Adjutant project don't have any PTL. It also didn't had PTL in the Yoga cycle already.
So this is call for maintainters for Adjutant. If You are using it or interested in it, and if You are willing to help maintaining this project, please contact TC members through this mailing list or directly on the #openstack-tc channel @OFTC. We can talk possibilities to make someone a PTL of the project or going with this project to the Distributed Project Leadership [2] model.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027411.html
[2] https://governance.openstack.org/tc/resolutions/20200803-distributed-project-leadership.html

-- 
Slawek Kaplonski
Principal Software Engineer
Red Hat  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220309/dab92635/attachment.htm>

From marc-antoine.godde at viarezo.fr  Wed Mar  9 15:01:48 2022
From: marc-antoine.godde at viarezo.fr (Marc-Antoine Godde)
Date: Wed, 9 Mar 2022 16:01:48 +0100
Subject: IPv6 deployment on OpenStack
In-Reply-To: <CAOAKi8z+W8K+upWkLf1R+MYQpgnOMN4jLN2=s7amaJNpVVECzg@mail.gmail.com>
References: <CAOAKi8z+W8K+upWkLf1R+MYQpgnOMN4jLN2=s7amaJNpVVECzg@mail.gmail.com>
Message-ID: <70D0EFA8-DBC6-43CC-AAD0-2316BF313C4A@viarezo.fr>

Hello,

Thanks for these information. Indeed, we were obtaining link-local address for the gateway with the OpenStack router.

Even if it?s contrary to the RFC, do yo know if it?s possible to send RA from OpenStack on behalf of our datacenter router ? That way, we could limit the load on our datacenter router.

Thanks,
Marc-Antoine.

> 
> On 9 Mar 2022, at 03:28, Laurent Dumont <laurentfdumont at gmail.com> wrote:
> ?
> That really depends on if you want Openstack to play an active role.
> 
> If the VMs are only connected to the Provider/External network on VLAN51, than SLAAC should happen without Openstack being involved. If you tcpdump on those VM, you should have seen the RA or some kind of traffic arrive.
> 
> If the VMs are getting the RA for the qrouter in Openstack, I do believe that your gateway might become the link-local on that qrouter. This means that the qrouter is now processing the out of subnet traffic for those VMs. That might not be the expected flow.
> 
>> On Tue, Mar 8, 2022 at 9:14 PM Marc-Antoine Godde <marc-antoine.godde at viarezo.fr> wrote:
>> Hello,
>> 
>> Indeed, this network is connected to our physical network (VLAN 51 for testing), xxxx:xxxx:2f1:aaaa::1 is an interface on our physical router.
>> 
>> Finally, we successfully started RADVD by adding a network interface in the subnet to a virtual router in OpenStack. This gave IPs to VMs, they were able to communicate between each other. Obviously, this network topology isn?t making any sense, we can?t route traffic outside. It was just for testing.
>> 
>> Now, the goal is route the traffic of VMs. I see two paradigms. The first one, we use our physical router to send RA directly to VMs. The second one, we use a private subnet (xxxx:xxxx:2f1:bbbb::/64 for instance) in a non external network of OpenStack. We add a virtual router to that subnet, we now have RADVD. We use that router to route traffic to an external network of OpenStack. What is best ?
>> 
>> Marc-Antoine
>> 
>>> Le 8 mars 2022 ? 23:47, Brian Haley <haleyb.dev at gmail.com> a ?crit :
>>> 
>>> Hi Marc-Antoine,
>>> 
>>> See inline...
>>> 
>>>> On 3/8/22 11:18, Marc-Antoine Godde wrote:
>>>> Hi,
>>>> Here?s what we?ve done.
>>>> We created a network:
>>>> Name
>>>>    ipv6-testing-network
>>>> ID
>>>>    9d5ca309-1861-4422-bcff-8818f9762a6f
>>>> Project ID
>>>>    653f5a2e60d34768a8629e5d4fca0738
>>>> Status
>>>>    Active
>>>> Admin State
>>>>    UP
>>>> Shared
>>>>    Yes
>>>> External Network
>>>>    Yes
>>>> MTU
>>>>    1500
>>>> Provider Network
>>>>    Network Type: vlan
>>>>    Physical Network: vlan
>>>>    Segmentation ID: 51
>>> 
>>> So this is an external provider network connected to your datacenter network, correct? In the case Slawek was describing I believe he was talking about an internal private network, which when a neutron router is attached will trigger radvd to be spawned, etc.
>>> 
>>> In this case VMs booted on this network should be seeing RAs from your datacenter router, if it's sending them. If it's not that would explain why they only have a link-local IPv6 address since the neutron router will not spawn radvd to run on the external network.
>>> 
>>> BTW, I'm trying to compare this to my local setup, but since I'm not running Horizon just using 'openstack network show...', 'openstack subnet show...' output, which is slightly different, but looks to match what you're doing.
>>> 
>>> Is your plan to have private IPv6 subnets that are then routed to your external network or is this just a test?
>>> 
>>> -Brian
>>> 
>>> 
>>>> We created a subnet:
>>>> Name
>>>>    ipv6-testing-v6
>>>> ID
>>>>    763771d4-b9d7-419a-ba04-97ce3abaf152
>>>> Project ID
>>>>    653f5a2e60d34768a8629e5d4fca0738
>>>> Network Name
>>>>    ipv6-testing-network
>>>> Network ID
>>>>    9d5ca309-1861-4422-bcff-8818f9762a6f
>>>>    <https://openstack.viarezo.fr/project/networks/9d5ca309-1861-4422-bcff-8818f9762a6f/detail>
>>>> Subnet Pool
>>>>    None
>>>> IP Version
>>>>    IPv6
>>>> CIDR
>>>>    xxxx:xxxx:2f1:aaaa::/64
>>>> IP Allocation Pools
>>>>    Start xxxx:xxxx:2f1:aaaa::2 - End xxxx:xxxx:2f1:aaaa:ffff:ffff:ffff:ffff
>>>> Gateway IP
>>>>    xxxx:xxxx:2f1:aaaa::1
>>>> DHCP Enabled
>>>>    Yes
>>>> IPv6 Address Configuration Mode
>>>>    SLAAC: Address discovered from OpenStack Router
>>>> Additional Routes
>>>>    None
>>>> DNS Name Servers
>>>>    None
>>>> We created Ubuntu and Debian instances. According to Horizon, the instance IPv6 is xxxx:xxxx:2f1:aaaa:f816:3eff:fe6d:c41a. Yet, we only have a link local address which is fe80::f816:3eff:fe6d:c41a/64. TCPdump indicates no Router Advertisement. We tried with and without adding a router on the Network in Horizon. ICMPv6 is authorized in INGRESS from ::/0.
>>>> We checked on the controllers, the computes and in the Neutron containers, systemctl indicated no instance of RADVD. Maybe we checked incorrectly...
>>>> Do you have any suggestions ? I add that we are working with OpenStack Ussuri deployed with OpenStack-ansible.
>>>> Thanks,
>>>> Marc-Antoine
>>>>> Le 8 mars 2022 ? 08:59, Slawek Kaplonski <skaplons at redhat.com <mailto:skaplons at redhat.com>> a ?crit :
>>>>> 
>>>>> Hi,
>>>>> 
>>>>>> On poniedzia?ek, 7 marca 2022 10:36:30 CET Marc-Antoine Godde wrote:
>>>>>> Hello,
>>>>>> 
>>>>>> Thanks for your answer.
>>>>>> 
>>>>>> If I?m correct, we can just use a virtual router with SLAAC since RADVD can deal with RS and emit RA (with support for RFC6106), right ?
>>>>> 
>>>>> Yes, virtual router created in the Neutron is enough there. It will spawn radvd in the qrouter namespace and will send RA to the Vms.
>>>>> Please note that Neutron don't supports privacy extension [1] so You will need to make sure that it's disabled it on Your vms.
>>>>> 
>>>>>> More generally, aren?t we suppose to have a virtual router every time, even in DHCPv6 (stateless and statefull), to answer RS ? I have to admit that I?m not very familiar at the moment with the implementations of RFCs in OpenStack.
>>>>>> 
>>>>>> Currently, we prefer the idea of adding IPv6 through SLAAC to have a uniform network. If we do so, we?d like to avoid sending RA from our physical router to limit its load. Yet, we do not any other arguments to support this choice.
>>>>>> Do you have any recommendations on what to do in latest versions of OpenStack ? What is usually done ?
>>>>> 
>>>>> TBH I don't have such experience. That's more question to operators of OpenStack.
>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> Marc-Antoine
>>>>>> 
>>>>>>> Le 7 mars 2022 ? 09:12, Slawek Kaplonski <skaplons at redhat.com <mailto:skaplons at redhat.com>> a ?crit :
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>>> On poniedzia?ek, 7 marca 2022 02:36:24 CET Marc-Antoine Godde wrote:
>>>>>>>> Hello.
>>>>>>>> 
>>>>>>>> We are progressively adding support for IPv6 in my company. We decided to use SLAAC only for laptops, phones, ? since DHCPv6 isn?t supported on Android. RDNSS support will also increase. We are now planning our deployment on OpenStack. We already know that we'll rely only on neutron but we are not yet fixed between DHCPv6 and SLAAC ? Do you have any arguments for one these for VMs ?
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Marc-Antoine.
>>>>>>> 
>>>>>>> With SLAAC You need to have Your network connected to the router in Neutron and You can only configure IP address on the VM. With DHCPv6 You can configure other things, like some static-routes, etc.
>>>>>>> Neutron supports DHCPv6 in the stateful and stateless variants. With stateless, You are using RA for address configuration and DHCP server for other configation. Please see [1] for more details.
>>>>>>> 
>>>>>>> [1] https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports<https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports>
>>>>> 
>>>>> [1]https://datatracker.ietf.org/doc/html/rfc4941 <https://datatracker.ietf.org/doc/html/rfc4941>
>>>>> 
>>>>> --
>>>>> Slawek Kaplonski
>>>>> Principal Software Engineer
>>>>> Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220309/87aba20d/attachment-0001.htm>

From tkajinam at redhat.com  Wed Mar  9 15:11:46 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Thu, 10 Mar 2022 00:11:46 +0900
Subject: [puppet] Proposing Alan Bishop (abishop) for puppet-manila core
Message-ID: <CAL_crJQtgtBGG3KGjbqR7CuQH987B_9NqvJ9q63kTY5+t4LTzg@mail.gmail.com>

Hi Team,


Alan is currently a partial core reviewer in Puppet OpenStack and covers
puppet-cinder and puppet-glance.

He has made great reviews in these two modules since he joined the team, but
in addition,  he has been reviewing patches for puppet-manila and providing
good feedback for the past two cycle.
 https://www.stackalytics.io/?user_id=alan-bishop

Based on that fact, I'd like to propose extending his coverage and adding
Alan
to the puppet-manila core reviewers.

If you have any feedback please share it in this thread. I'll add him to
the group
if we don't hear any objections for 1 week.

I'd like to take this moment to thank Alan for his great work and help in
this project !

Thank you,
Takashi KAJINAMI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/7bb9c72f/attachment.htm>

From cboylan at sapwetik.org  Wed Mar  9 15:26:55 2022
From: cboylan at sapwetik.org (Clark Boylan)
Date: Wed, 09 Mar 2022 07:26:55 -0800
Subject: [puppet] Gate blocker: CentOS 9 integration jobs are broken
In-Reply-To: <CAL_crJTrYvHcUHK+QBB0qgPGP6y632VmT+AuYkir+64PX-fXqA@mail.gmail.com>
References: <CAL_crJSq8sfwqybc9CC_iQ6sqHFSQNaFnE6uReNfyofch=icKg@mail.gmail.com>
 <CAL_crJTJz+BjSsg+NyTAdhvC9HL_F2WR3-TtUs1nWGY30ZN3Tg@mail.gmail.com>
 <CAL_crJTrYvHcUHK+QBB0qgPGP6y632VmT+AuYkir+64PX-fXqA@mail.gmail.com>
Message-ID: <ab714de2-5492-458c-9ff2-8bd75ca60955@www.fastmail.com>

On Tue, Mar 8, 2022, at 10:01 PM, Takashi Kajinami wrote:
> Both of the two issues have been resolved and c9s integration jobs are 
> voting again.
>
> As a side note, It seems the second issue within tempest tests was 
> caused by recent
> change in openssl in CentOS9 Stream repo and rsa key is no longer 
> allowed for ssh.

To clarify this is RSA no longer allowed with SSH or is it just RSA + SHA1? The RSA + SHA1 problem has been known for a bit due to Fedora making that update a while back. But RSA + SHA2 does work on Fedora. The issue there is some servers like the dropbear server in Cirros and the MINA SSHD used by Gerrit either don't support RSA + SHA2 or lack the required negotation bits to allow RSA + SHA2.

Gerrit 3.6 should fix this, and I believe there is some effort to update Cirros to a newer version of dropbear which will support RSA + SHA2.

Separately, it might be a good idea to try and push back on these systems to stop defaulting to RSA + SHA1 if that combination is not allowed. They should default to RSA + SHA2 if that is the only version of RSA that will function on their platform. Then if the server supports it but cannot negotiate it properly (this is the case with Gerrit) it should continue to function.

> We worked around the issue by the feature in tempest to use a different 
> format but
> I've submitted a feedback to know about current usage of rsa key[1].
>  [1] https://bugs.launchpad.net/nova/+bug/1962726
>


From pstreander at deloitte.com  Wed Mar  9 17:02:48 2022
From: pstreander at deloitte.com (Streander, Paul)
Date: Wed, 9 Mar 2022 17:02:48 +0000
Subject: Why is Qinling no longer supported?
Message-ID: <SA0PR85MB0538E5C86E2CC527B15F5476A70A9@SA0PR85MB0538.NAMPRD85.PROD.OUTLOOK.COM>

Thanks

This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited.

Deloitte refers to a Deloitte member firm, one of its related entities, or Deloitte Touche Tohmatsu Limited ("DTTL"). Each Deloitte member firm is a separate legal entity and a member of DTTL. DTTL does not provide services to clients. Please see www.deloitte.com/about to learn more.

v.E.1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220309/157d05ec/attachment.htm>

From haleyb.dev at gmail.com  Wed Mar  9 17:13:54 2022
From: haleyb.dev at gmail.com (Brian Haley)
Date: Wed, 9 Mar 2022 12:13:54 -0500
Subject: IPv6 deployment on OpenStack
In-Reply-To: <9F9D2AF2-6C76-45F2-8227-51DB2623BEFC@viarezo.fr>
References: <B30F2915-674E-4029-9F1A-D25589FFF056@viarezo.fr>
 <14575046.tv2OnDr8pf@p1> <8195F0AD-5FE8-432C-A1A7-8EB287B13C64@viarezo.fr>
 <2536429.7s5MMGUR32@p1> <BA82712D-C40D-4B22-899B-6FBEDB52920B@viarezo.fr>
 <a821fd11-e88b-28f5-d2d3-705e52ee3823@gmail.com>
 <9F9D2AF2-6C76-45F2-8227-51DB2623BEFC@viarezo.fr>
Message-ID: <28d0b91b-d559-1f02-9133-28152a1dc02c@gmail.com>

Hi,

On 3/8/22 21:08, Marc-Antoine Godde wrote:
> Hello,
> 
> Indeed, this network is connected to our physical network (VLAN 51 for 
> testing), xxxx:xxxx:2f1:aaaa::1 is an interface on our physical router.
> 
> Finally, we successfully started RADVD by adding a network interface in 
> the subnet to a virtual router in OpenStack. This gave IPs to VMs, they 
> were able to communicate between each other. Obviously, this network 
> topology isn?t making any sense, we can?t route traffic outside. It was 
> just for testing.
> 
> Now, the goal is route the traffic of VMs. I see two paradigms. The 
> first one, we use our physical router to send RA directly to VMs.

This is going to be the quickest and easiest way to do this - having the 
VM directly attached to your infrastructure and having them create a 
SLAAC address based on the RA from that router.

> The 
> second one, we use a private subnet (xxxx:xxxx:2f1:bbbb::/64 for 
> instance) in a non external network of OpenStack. We add a virtual 
> router to that subnet, we now have RADVD. We use that router to route 
> traffic to an external network of OpenStack. What is best ?

This is possible, but requires using prefix delegation such that the 
private network gets an IPv6 prefix that is routeable in your 
datacenter. This is described on the docs page at [0] but does require 
that your infrastructure supports IPV6-PD.

-Brian

[0] https://docs.openstack.org/neutron/latest/admin/config-ipv6.html

>> Le 8 mars 2022 ? 23:47, Brian Haley <haleyb.dev at gmail.com 
>> <mailto:haleyb.dev at gmail.com>> a ?crit :
>>
>> Hi Marc-Antoine,
>>
>> See inline...
>>
>> On 3/8/22 11:18, Marc-Antoine Godde wrote:
>>> Hi,
>>> Here?s what we?ve done.
>>> We created a network:
>>> Name
>>> ???ipv6-testing-network
>>> ID
>>> ???9d5ca309-1861-4422-bcff-8818f9762a6f
>>> Project ID
>>> ???653f5a2e60d34768a8629e5d4fca0738
>>> Status
>>> ???Active
>>> Admin State
>>> ???UP
>>> Shared
>>> ???Yes
>>> External Network
>>> ???Yes
>>> MTU
>>> ???1500
>>> Provider Network
>>> ???Network Type: vlan
>>> ???Physical Network: vlan
>>> ???Segmentation ID: 51
>>
>> So this is an external provider network connected to your datacenter 
>> network, correct? In the case Slawek was describing I believe he was 
>> talking about an internal private network, which when a neutron router 
>> is attached will trigger radvd to be spawned, etc.
>>
>> In this case VMs booted on this network should be seeing RAs from your 
>> datacenter router, if it's sending them. If it's not that would 
>> explain why they only have a link-local IPv6 address since the neutron 
>> router will not spawn radvd to run on the external network.
>>
>> BTW, I'm trying to compare this to my local setup, but since I'm not 
>> running Horizon just using 'openstack network show...', 'openstack 
>> subnet show...' output, which is slightly different, but looks to 
>> match what you're doing.
>>
>> Is your plan to have private IPv6 subnets that are then routed to your 
>> external network or is this just a test?
>>
>> -Brian
>>
>>
>>> We created a subnet:
>>> Name
>>> ???ipv6-testing-v6
>>> ID
>>> ???763771d4-b9d7-419a-ba04-97ce3abaf152
>>> Project ID
>>> ???653f5a2e60d34768a8629e5d4fca0738
>>> Network Name
>>> ???ipv6-testing-network
>>> Network ID
>>> ???9d5ca309-1861-4422-bcff-8818f9762a6f
>>> ???<https://openstack.viarezo.fr/project/networks/9d5ca309-1861-4422-bcff-8818f9762a6f/detail 
>>> <https://openstack.viarezo.fr/project/networks/9d5ca309-1861-4422-bcff-8818f9762a6f/detail>>
>>> Subnet Pool
>>> ???None
>>> IP Version
>>> ???IPv6
>>> CIDR
>>> ???xxxx:xxxx:2f1:aaaa::/64
>>> IP Allocation Pools
>>> ???Start xxxx:xxxx:2f1:aaaa::2 - End 
>>> xxxx:xxxx:2f1:aaaa:ffff:ffff:ffff:ffff
>>> Gateway IP
>>> ???xxxx:xxxx:2f1:aaaa::1
>>> DHCP Enabled
>>> ???Yes
>>> IPv6 Address Configuration Mode
>>> ???SLAAC: Address discovered from OpenStack Router
>>> Additional Routes
>>> ???None
>>> DNS Name Servers
>>> ???None
>>> We created Ubuntu and Debian instances. According to Horizon, the 
>>> instance IPv6 is xxxx:xxxx:2f1:aaaa:f816:3eff:fe6d:c41a. Yet, we only 
>>> have a link local?address which is fe80::f816:3eff:fe6d:c41a/64. 
>>> TCPdump indicates no Router Advertisement. We tried with and without 
>>> adding a router on the Network in Horizon. ICMPv6 is authorized in 
>>> INGRESS from ::/0.
>>> We checked on the controllers, the computes and in the Neutron 
>>> containers, systemctl indicated no instance of RADVD. Maybe we 
>>> checked incorrectly...
>>> Do you have any?suggestions ? I add that we are working with 
>>> OpenStack Ussuri deployed with OpenStack-ansible.
>>> Thanks,
>>> Marc-Antoine
>>>> Le 8 mars 2022 ? 08:59, Slawek Kaplonski <skaplons at redhat.com 
>>>> <mailto:skaplons at redhat.com><mailto:skaplons at redhat.com 
>>>> <mailto:skaplons at redhat.com>>> a ?crit :
>>>>
>>>> Hi,
>>>>
>>>> On poniedzia?ek, 7 marca 2022 10:36:30 CET Marc-Antoine Godde wrote:
>>>>> Hello,
>>>>>
>>>>> Thanks for your answer.
>>>>>
>>>>> If I?m correct, we can just use a virtual router with SLAAC since 
>>>>> RADVD can deal with RS and emit RA (with support for RFC6106), right ?
>>>>
>>>> Yes, virtual router created in the Neutron is enough there. It will 
>>>> spawn radvd in the qrouter namespace and will send RA to the Vms.
>>>> Please note that Neutron don't supports privacy extension [1] so You 
>>>> will need to make sure that it's disabled it on Your vms.
>>>>
>>>>> More generally, aren?t we suppose to have a virtual router every 
>>>>> time, even in DHCPv6 (stateless and statefull), to answer RS ? I 
>>>>> have to admit that I?m not very familiar at the moment with the 
>>>>> implementations of RFCs in OpenStack.
>>>>>
>>>>> Currently, we prefer the idea of adding IPv6 through SLAAC to have 
>>>>> a uniform network. If we do so, we?d like to avoid sending RA from 
>>>>> our physical router to limit its load. Yet, we do not any other 
>>>>> arguments to support this choice.
>>>>> Do you have any recommendations on what to do in latest versions of 
>>>>> OpenStack ? What is usually done ?
>>>>
>>>> TBH I don't have such experience. That's more question to operators 
>>>> of OpenStack.
>>>>
>>>>>
>>>>> Thanks,
>>>>> Marc-Antoine
>>>>>
>>>>>> Le 7 mars 2022 ? 09:12, Slawek Kaplonski <skaplons at redhat.com 
>>>>>> <mailto:skaplons at redhat.com><mailto:skaplons at redhat.com 
>>>>>> <mailto:skaplons at redhat.com>>> a ?crit :
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On poniedzia?ek, 7 marca 2022 02:36:24 CET Marc-Antoine Godde wrote:
>>>>>>> Hello.
>>>>>>>
>>>>>>> We are progressively adding support for IPv6 in my company. We 
>>>>>>> decided to use SLAAC only for laptops, phones, ? since DHCPv6 
>>>>>>> isn?t supported on Android. RDNSS support will also increase. We 
>>>>>>> are now planning our deployment on OpenStack. We already know 
>>>>>>> that we'll rely only on neutron but we are not yet fixed between 
>>>>>>> DHCPv6 and SLAAC ? Do you have any arguments for one these for VMs ?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Marc-Antoine.
>>>>>>>
>>>>>>
>>>>>> With SLAAC You need to have Your network connected to the router 
>>>>>> in Neutron and You can only configure IP address on the VM. With 
>>>>>> DHCPv6 You can configure other things, like some static-routes, etc.
>>>>>> Neutron supports DHCPv6 in the stateful and stateless variants. 
>>>>>> With stateless, You are using RA for address configuration and 
>>>>>> DHCP server for other configation. Please see [1] for more details.
>>>>>>
>>>>>> [1]https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports 
>>>>>> <https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports><https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports 
>>>>>> <https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> [1]https://datatracker.ietf.org/doc/html/rfc4941 
>>>> <https://datatracker.ietf.org/doc/html/rfc4941><https://datatracker.ietf.org/doc/html/rfc4941 
>>>> <https://datatracker.ietf.org/doc/html/rfc4941>>
>>>>
>>>> --
>>>> Slawek Kaplonski
>>>> Principal Software Engineer
>>>> Red Hat
> 


From haleyb.dev at gmail.com  Wed Mar  9 17:14:20 2022
From: haleyb.dev at gmail.com (Brian Haley)
Date: Wed, 9 Mar 2022 12:14:20 -0500
Subject: IPv6 deployment on OpenStack
In-Reply-To: <70D0EFA8-DBC6-43CC-AAD0-2316BF313C4A@viarezo.fr>
References: <CAOAKi8z+W8K+upWkLf1R+MYQpgnOMN4jLN2=s7amaJNpVVECzg@mail.gmail.com>
 <70D0EFA8-DBC6-43CC-AAD0-2316BF313C4A@viarezo.fr>
Message-ID: <253dc27c-37df-58b7-888b-0e7b8c24561a@gmail.com>

Hi,

On 3/9/22 10:01, Marc-Antoine Godde wrote:
> Hello,
> 
> Thanks for these information. Indeed, we were obtaining link-local 
> address for the gateway with the OpenStack router.
> 
> Even if it?s contrary to the RFC, do yo know if it?s possible to send RA 
> from OpenStack on behalf of our datacenter router ? That way, we could 
> limit the load on our datacenter router.

 From my memory of the RFCs, the link-local of the sender is important 
in the RA message, but I could be remembering it wrong, or there could 
be an option to override that. I can't say I've seen it been done like this.

Is the load really that much to send periodic RAs and respond to RSs? 
Most routers have supported this for 15+ years by now so should be able 
to handle it.

-Brian

>> On 9 Mar 2022, at 03:28, Laurent Dumont <laurentfdumont at gmail.com> wrote:
>>
>> ?
>> That really depends on if you want Openstack to play an active role.
>>
>> If the VMs?are only connected to the Provider/External network on 
>> VLAN51, than SLAAC should happen without Openstack being involved. If 
>> you tcpdump on those VM, you should have seen the RA or some kind of 
>> traffic arrive.
>>
>> If the VMs are getting the RA for the qrouter in Openstack, I do 
>> believe that your gateway might become the link-local on that qrouter. 
>> This means that the qrouter is now processing the out of subnet 
>> traffic for those VMs. That might not be the expected flow.
>>
>> On Tue, Mar 8, 2022 at 9:14 PM Marc-Antoine Godde 
>> <marc-antoine.godde at viarezo.fr <mailto:marc-antoine.godde at viarezo.fr>> 
>> wrote:
>>
>>     Hello,
>>
>>     Indeed, this network is connected to our physical network (VLAN 51
>>     for testing), xxxx:xxxx:2f1:aaaa::1 is an interface on our
>>     physical router.
>>
>>     Finally, we successfully started RADVD by adding a network
>>     interface in the subnet to a virtual router in OpenStack. This
>>     gave IPs to VMs, they were able to communicate between each other.
>>     Obviously, this network topology isn?t making any sense, we can?t
>>     route traffic outside. It was just for testing.
>>
>>     Now, the goal is route the traffic of VMs. I see two paradigms.
>>     The first one, we use our physical router to send RA directly to
>>     VMs. The second one, we use a private subnet
>>     (xxxx:xxxx:2f1:bbbb::/64 for instance) in a non external network
>>     of OpenStack. We add a virtual router to that subnet, we now have
>>     RADVD. We use that router to route traffic to an external network
>>     of OpenStack. What is best ?
>>
>>     Marc-Antoine
>>
>>>     Le 8 mars 2022 ? 23:47, Brian Haley <haleyb.dev at gmail.com
>>>     <mailto:haleyb.dev at gmail.com>> a ?crit :
>>>
>>>     Hi Marc-Antoine,
>>>
>>>     See inline...
>>>
>>>     On 3/8/22 11:18, Marc-Antoine Godde wrote:
>>>>     Hi,
>>>>     Here?s what we?ve done.
>>>>     We created a network:
>>>>     Name
>>>>     ???ipv6-testing-network
>>>>     ID
>>>>     ???9d5ca309-1861-4422-bcff-8818f9762a6f
>>>>     Project ID
>>>>     ???653f5a2e60d34768a8629e5d4fca0738
>>>>     Status
>>>>     ???Active
>>>>     Admin State
>>>>     ???UP
>>>>     Shared
>>>>     ???Yes
>>>>     External Network
>>>>     ???Yes
>>>>     MTU
>>>>     ???1500
>>>>     Provider Network
>>>>     ???Network Type: vlan
>>>>     ???Physical Network: vlan
>>>>     ???Segmentation ID: 51
>>>
>>>     So this is an external provider network connected to your
>>>     datacenter network, correct? In the case Slawek was describing I
>>>     believe he was talking about an internal private network, which
>>>     when a neutron router is attached will trigger radvd to be
>>>     spawned, etc.
>>>
>>>     In this case VMs booted on this network should be seeing RAs from
>>>     your datacenter router, if it's sending them. If it's not that
>>>     would explain why they only have a link-local IPv6 address since
>>>     the neutron router will not spawn radvd to run on the external
>>>     network.
>>>
>>>     BTW, I'm trying to compare this to my local setup, but since I'm
>>>     not running Horizon just using 'openstack network show...',
>>>     'openstack subnet show...' output, which is slightly different,
>>>     but looks to match what you're doing.
>>>
>>>     Is your plan to have private IPv6 subnets that are then routed to
>>>     your external network or is this just a test?
>>>
>>>     -Brian
>>>
>>>
>>>>     We created a subnet:
>>>>     Name
>>>>     ???ipv6-testing-v6
>>>>     ID
>>>>     ???763771d4-b9d7-419a-ba04-97ce3abaf152
>>>>     Project ID
>>>>     ???653f5a2e60d34768a8629e5d4fca0738
>>>>     Network Name
>>>>     ???ipv6-testing-network
>>>>     Network ID
>>>>     ???9d5ca309-1861-4422-bcff-8818f9762a6f
>>>>     ???<https://openstack.viarezo.fr/project/networks/9d5ca309-1861-4422-bcff-8818f9762a6f/detail
>>>>     <https://openstack.viarezo.fr/project/networks/9d5ca309-1861-4422-bcff-8818f9762a6f/detail>>
>>>>     Subnet Pool
>>>>     ???None
>>>>     IP Version
>>>>     ???IPv6
>>>>     CIDR
>>>>     ???xxxx:xxxx:2f1:aaaa::/64
>>>>     IP Allocation Pools
>>>>     ???Start xxxx:xxxx:2f1:aaaa::2 - End
>>>>     xxxx:xxxx:2f1:aaaa:ffff:ffff:ffff:ffff
>>>>     Gateway IP
>>>>     ???xxxx:xxxx:2f1:aaaa::1
>>>>     DHCP Enabled
>>>>     ???Yes
>>>>     IPv6 Address Configuration Mode
>>>>     ???SLAAC: Address discovered from OpenStack Router
>>>>     Additional Routes
>>>>     ???None
>>>>     DNS Name Servers
>>>>     ???None
>>>>     We created Ubuntu and Debian instances. According to Horizon,
>>>>     the instance IPv6 is xxxx:xxxx:2f1:aaaa:f816:3eff:fe6d:c41a.
>>>>     Yet, we only have a link local?address which is
>>>>     fe80::f816:3eff:fe6d:c41a/64. TCPdump indicates no Router
>>>>     Advertisement. We tried with and without adding a router on the
>>>>     Network in Horizon. ICMPv6 is authorized in INGRESS from ::/0.
>>>>     We checked on the controllers, the computes and in the Neutron
>>>>     containers, systemctl indicated no instance of RADVD. Maybe we
>>>>     checked incorrectly...
>>>>     Do you have any?suggestions ? I add that we are working with
>>>>     OpenStack Ussuri deployed with OpenStack-ansible.
>>>>     Thanks,
>>>>     Marc-Antoine
>>>>>     Le 8 mars 2022 ? 08:59, Slawek Kaplonski <skaplons at redhat.com
>>>>>     <mailto:skaplons at redhat.com><mailto:skaplons at redhat.com
>>>>>     <mailto:skaplons at redhat.com>>> a ?crit :
>>>>>
>>>>>     Hi,
>>>>>
>>>>>     On poniedzia?ek, 7 marca 2022 10:36:30 CET Marc-Antoine Godde
>>>>>     wrote:
>>>>>>     Hello,
>>>>>>
>>>>>>     Thanks for your answer.
>>>>>>
>>>>>>     If I?m correct, we can just use a virtual router with SLAAC
>>>>>>     since RADVD can deal with RS and emit RA (with support for
>>>>>>     RFC6106), right ?
>>>>>
>>>>>     Yes, virtual router created in the Neutron is enough there. It
>>>>>     will spawn radvd in the qrouter namespace and will send RA to
>>>>>     the Vms.
>>>>>     Please note that Neutron don't supports privacy extension [1]
>>>>>     so You will need to make sure that it's disabled it on Your vms.
>>>>>
>>>>>>     More generally, aren?t we suppose to have a virtual router
>>>>>>     every time, even in DHCPv6 (stateless and statefull), to
>>>>>>     answer RS ? I have to admit that I?m not very familiar at the
>>>>>>     moment with the implementations of RFCs in OpenStack.
>>>>>>
>>>>>>     Currently, we prefer the idea of adding IPv6 through SLAAC to
>>>>>>     have a uniform network. If we do so, we?d like to avoid
>>>>>>     sending RA from our physical router to limit its load. Yet, we
>>>>>>     do not any other arguments to support this choice.
>>>>>>     Do you have any recommendations on what to do in latest
>>>>>>     versions of OpenStack ? What is usually done ?
>>>>>
>>>>>     TBH I don't have such experience. That's more question to
>>>>>     operators of OpenStack.
>>>>>
>>>>>>
>>>>>>     Thanks,
>>>>>>     Marc-Antoine
>>>>>>
>>>>>>>     Le 7 mars 2022 ? 09:12, Slawek Kaplonski <skaplons at redhat.com
>>>>>>>     <mailto:skaplons at redhat.com><mailto:skaplons at redhat.com
>>>>>>>     <mailto:skaplons at redhat.com>>> a ?crit :
>>>>>>>
>>>>>>>     Hi,
>>>>>>>
>>>>>>>     On poniedzia?ek, 7 marca 2022 02:36:24 CET Marc-Antoine Godde
>>>>>>>     wrote:
>>>>>>>>     Hello.
>>>>>>>>
>>>>>>>>     We are progressively adding support for IPv6 in my company.
>>>>>>>>     We decided to use SLAAC only for laptops, phones, ? since
>>>>>>>>     DHCPv6 isn?t supported on Android. RDNSS support will also
>>>>>>>>     increase. We are now planning our deployment on OpenStack.
>>>>>>>>     We already know that we'll rely only on neutron but we are
>>>>>>>>     not yet fixed between DHCPv6 and SLAAC ? Do you have any
>>>>>>>>     arguments for one these for VMs ?
>>>>>>>>
>>>>>>>>     Thanks,
>>>>>>>>     Marc-Antoine.
>>>>>>>>
>>>>>>>
>>>>>>>     With SLAAC You need to have Your network connected to the
>>>>>>>     router in Neutron and You can only configure IP address on
>>>>>>>     the VM. With DHCPv6 You can configure other things, like some
>>>>>>>     static-routes, etc.
>>>>>>>     Neutron supports DHCPv6 in the stateful and stateless
>>>>>>>     variants. With stateless, You are using RA for address
>>>>>>>     configuration and DHCP server for other configation. Please
>>>>>>>     see [1] for more details.
>>>>>>>
>>>>>>>     [1]https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports
>>>>>>>     <https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports><https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports
>>>>>>>     <https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>     [1]https://datatracker.ietf.org/doc/html/rfc4941
>>>>>     <https://datatracker.ietf.org/doc/html/rfc4941><https://datatracker.ietf.org/doc/html/rfc4941
>>>>>     <https://datatracker.ietf.org/doc/html/rfc4941>>
>>>>>
>>>>>     --
>>>>>     Slawek Kaplonski
>>>>>     Principal Software Engineer
>>>>>     Red Hat
>>


From fungi at yuggoth.org  Wed Mar  9 17:18:16 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 9 Mar 2022 17:18:16 +0000
Subject: Why is Qinling no longer supported?
In-Reply-To: <SA0PR85MB0538E5C86E2CC527B15F5476A70A9@SA0PR85MB0538.NAMPRD85.PROD.OUTLOOK.COM>
References: <SA0PR85MB0538E5C86E2CC527B15F5476A70A9@SA0PR85MB0538.NAMPRD85.PROD.OUTLOOK.COM>
Message-ID: <20220309171815.y7au3waaogd7bkdw@yuggoth.org>

On 2022-03-09 17:02:48 +0000 (+0000), Streander, Paul wrote:
> Thanks
[...]

According to https://review.opendev.org/764523 it was retired in
2020 because nobody was working on it any longer, eventually
culminating in there being no volunteer to lead the project.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220309/99cec3b4/attachment.sig>

From gmann at ghanshyammann.com  Wed Mar  9 17:25:17 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 09 Mar 2022 11:25:17 -0600
Subject: Why is Qinling no longer supported?
In-Reply-To: <SA0PR85MB0538E5C86E2CC527B15F5476A70A9@SA0PR85MB0538.NAMPRD85.PROD.OUTLOOK.COM>
References: <SA0PR85MB0538E5C86E2CC527B15F5476A70A9@SA0PR85MB0538.NAMPRD85.PROD.OUTLOOK.COM>
Message-ID: <17f6fb6af20.1171fe6b324208.7758919786978169783@ghanshyammann.com>

Hi,

I was confused with the body of this email but that is disclaimer I think.

For query in the subject line, we retired Qinling 1.5 years ago as there was no
maintainer to maintain it.

-  http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018638.html

If you are interested to maintain it, feel free to re-apply for adding it back to OpenStack, below
link will explain the requirements and steps for re-apply

- https://governance.openstack.org/tc/reference/new-projects-requirements.html

-gmann

 ---- On Wed, 09 Mar 2022 11:02:48 -0600 Streander, Paul <pstreander at deloitte.com> wrote ----
 > 
 > Thanks
 > This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited.
 > Deloitte refers to a Deloitte member firm, one of its related entities, or Deloitte Touche Tohmatsu Limited ("DTTL"). Each Deloitte member firm is a separate legal entity and a member of DTTL. DTTL does not provide services to clients. Please see www.deloitte.com/about to learn more.
 > v.E.1
 > 


From gmann at ghanshyammann.com  Wed Mar  9 17:32:55 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 09 Mar 2022 11:32:55 -0600
Subject: [adjutant][tc][all] Call for volunteers to be a PTL and
 maintainers
In-Reply-To: <1915566590.650011.1646837917079@mail.yahoo.com>
References: <4381995.LvFx2qVVIh@p1>
 <1915566590.650011.1646837917079@mail.yahoo.com>
Message-ID: <17f6fbdac13.b9412e8024567.8942750703608840822@ghanshyammann.com>

 ---- On Wed, 09 Mar 2022 08:58:37 -0600 Albert Braden <ozzzo at yahoo.com> wrote ----
 >                 I'm still waiting for permission to work on Adjutant. My contract ends this month and I'm taking 2 months off before I start fulltime. I have hope that permission will be granted while I'm out. I expect that I will be able to start working on Adjutant in June.

Thanks, Braden for your response. I am not sure if we can delay the PTL assignment by June which
is almost half of the Zed cycle. Another option is to go with the DPL model[1] but that is most useful
if there is more than one maintainer sharing the PTL responsibility. If you are the only one then DPL
model is no different than PTL model.

But I think we can wait until this month's end (which will be while we are in PTG), please let us know
as soon as you get permission so that we can assign you as PTL and you can start work in June which
should not be an issue. And if anyone wants to help then they can always do it anytime.

[1] https://governance.openstack.org/tc/resolutions/20200803-distributed-project-leadership.html

-gmann


 >                                                                                                     On Saturday, March 5, 2022, 01:32:13 PM EST, Slawek Kaplonski <skaplons at redhat.com> wrote:                                
 >                 
 >                 Hi,
 > 
 > After last PTL elections [1] Adjutant project don't have any PTL. It also didn't had PTL in the Yoga cycle already.
 > So this is call for maintainters for Adjutant. If You are using it or interested in it, and if You are willing to help maintaining this project, please contact TC members through this mailing list or directly on the #openstack-tc channel @OFTC. We can talk possibilities to make someone a PTL of the project or going with this project to the Distributed Project Leadership [2] model.
 > 
 > [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027411.html
 > [2] https://governance.openstack.org/tc/resolutions/20200803-distributed-project-leadership.html
 > 
 > -- 
 > Slawek Kaplonski
 > Principal Software Engineer
 > Red Hat                            


From gmann at ghanshyammann.com  Wed Mar  9 17:59:17 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 09 Mar 2022 11:59:17 -0600
Subject: [heat][rbac] Management of "system resources" with SRBAC enforced
In-Reply-To: <CAL_crJSPv3pmJ31DVJKSurVOLGZM5MOtfapKN1s+DxA-Yhr7AQ@mail.gmail.com>
References: <CAL_crJSy6_-+0oLZC1PP=RoE-2fNMn0jytsv9UxJOZ2BxYbeeQ@mail.gmail.com>
 <CA+WCyyovVWVhudrs0RGzoKedH7DdRCjgR1dEF5icK9Epr7XOEQ@mail.gmail.com>
 <CAL_crJSPv3pmJ31DVJKSurVOLGZM5MOtfapKN1s+DxA-Yhr7AQ@mail.gmail.com>
Message-ID: <17f6fd5cf65.b558d8a025830.2422670910290295781@ghanshyammann.com>

 ---- On Wed, 09 Mar 2022 06:43:03 -0600 Takashi Kajinami <tkajinam at redhat.com> wrote ----
 > Hi Rico.
 > Thank you for your insights.Please find my replies inline.
 > 
 > On Wed, Mar 9, 2022 at 6:22 PM Rico Lin <ricolin at ricolky.com> wrote:
 > 
 > 
 > On Wed, Mar 9, 2022 at 1:57 PM Takashi Kajinami <tkajinam at redhat.com> wrote:
 > >
 > > Hello,
 > >
 > >
 > > I've been working on updating policy rules in heat according to the latest
 > > guideline for SRBAC implementation.
 > 
 > Thanks so much for working on it, definitely +1 on enhancing security.
 > >
 > >  [1] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#direction-change
 > >
 > > However this change reveals one potential issue with system resources.
 > >
 > > In heat there are some resource types like OS::Nova::Flavor or OS::Keystone::User
 > > which is allowed for only system users. (I'll call these resources as "system resources" here)
 > We create those resources based on checking `role:admin`, so project admin is accepted.This means a user under that project with role:admin, can operate those resources.I'm not sure what system user means here, so correct me if I'm wrong.
 > The core problem is that backend services like nova enforces different policies from just role:admin whenSRBAC is enforced. I reported that a while ago as https://storyboard.openstack.org/#!/story/2009787 .
 > 
 > The main problem here is that heat currently supports resources which require different scopes of credentials.For example, once all deprecated policy rules are removed, nova allows project users to create instances(OS::Nova::Server)[1],while nova allows only system admins to create flavors(OS::Nova::Flavor)[2]. Currently Heat leverages the user credentialused to create a stack when Heat requests backend services to create its resources, and it's "impossible" to create a stackwith these two resources by a single credential (as each token can be scoped by project or system.
 > [1] https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/servers.py#L210[2] https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/flavor_manage.py#L28-L36
 > If we keep allowing system users to create stacks, then it would allow users to create system resourceslike flavors. But this never solves the problem with the "mixed" pattern which I described above.Hope this will explain these three options more clearly.
 >  
 > >
 > > Because heat uses user credentials to create resources in backend services, if we require
 > > project scope for stack/resource management then we are no longer able to create these system
 > > resources as part of stack. (*1)>
 > > There are some options I can think of at this moment.
 > >
 > > 1. Deprecate and remove all resources which require system scope
 > > Pros
 > > - This is most easy solution to be implemented
 > > Cons
 > > - This one has the biggest user impact
 > 
 > Don't :)

Yeah, not sure how removing will work.

 > > 2. Use service credential for resource creation
 > > Pros:
 > > - This might have smallest user impact
 > > Cons:
 > > - This requires a relatively big change in heat's architecture, which I've not yet evaluated.
 > > - We need to determine the project scope role to be allowed to do system operation.
 > >  
 > I think this is something we can discuss more.
 > > 3. Implement additional project-role in each service to allow creation via stack creation.
 > > Pros:
 > > - This would avoid user impact.
 > > Cons:
 > > - requires work in multiple components.
 > > - We need to determine the project scope role to be allowed to do system operation
 > 
 > 
 > Indeed current stack operation require `(role:admin and system_scope:all) OR (role:member and project_id:%(project_id)s)`.And if we remove the system part and keep `(role:member and project_id:%(project_id)s)`, will mean only a user in that project with a member role can operate stack, and if the user got also admin role, that user can manage User/Flavor resources through stack too.The main problem here is that nova will no longer allow project admins to create flavors,and it will require system admin when SRBAC is enforced(which means all deprecated rulesare disabled)
 >  
 > Also, note thatFor the case of Nova::Flavor, both policies from Nova and Heat resource will be enforced here, so it only accepts the intersection part of rules.
 > So if we go with removing the system admin, that means it's time to also remove some deprecated global scope operation.
 > IMO, to accept Project Admin or member make more reasonable (like you proposed in option 3)

This is a similar case that we discussed in the service role ML thread[1] or in the spec[2].

For such cases only, where services need to interact with another service we will have the 'service' as
a special role. In this case, the heat having the project scoped token will use the 'service' role token for
Nova Flavor APIs calls.  Now whether that 'service' role token needs to be system scoped or not is
open question Mark brought up in that discussion. IMO, we should use the scoped token even in case
of 'service' role and do not skip scope checks for 'service' role in oslo policy as it can be a valid role used
by any users at production. So with the new SRBAC, heat needs to use the system scoped 'service' role token.

But as 'service' role is not yet implemented by keystone[2], we can use the legacy admin token which is currently
used in heat or other service-to-service interaction. 

[1] http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026777.html
[2] https://review.opendev.org/c/openstack/keystone-specs/+/818616

-gmann

 > >
 > > Thank you,
 > > Takashi
 > >
 > 


From ces.eduardo98 at gmail.com  Wed Mar  9 18:11:53 2022
From: ces.eduardo98 at gmail.com (Carlos Silva)
Date: Wed, 9 Mar 2022 15:11:53 -0300
Subject: [manila] Zed PTG Planning
Message-ID: <CAE51gQ++F_S9yPwSRJ-RFKWhc__h_2XsxzkwJS9xm5PHOsiZdg@mail.gmail.com>

Hello dear Zorillas and interested stackers!

As you might be aware, the virtual PTG will be held between April 4th and
8th.
There is an etherpad to propose the topics to be discussed [1].
If you intend to participate, please add your name and your timezone to the
attendees list on the etherpad.

Please add your topics to the etherpad, and if you have a preference of
time for due to your timezone, please let me know.

[1] https://etherpad.opendev.org/p/zorilla-ptg-manila-planning

Thanks,
carloss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220309/3ad69331/attachment.htm>

From haiwu.us at gmail.com  Wed Mar  9 20:40:46 2022
From: haiwu.us at gmail.com (hai wu)
Date: Wed, 9 Mar 2022 14:40:46 -0600
Subject: [nova] VM ending up in a different availability zone after resizing
 vm instance
Message-ID: <CAJ1=nZdKoRjNd8OPiqSogYsg87EXSZCHY_pdS3gkMv4EG7JCgw@mail.gmail.com>

VM ends up in a different availability zone after resizing the vm
instance. The default openstack nova behavior should have prevented
this from happening, correct? What could have caused this?


From dms at danplanet.com  Wed Mar  9 22:30:23 2022
From: dms at danplanet.com (Dan Smith)
Date: Wed, 09 Mar 2022 14:30:23 -0800
Subject: [TC][PTL][ops][all] Release cadence, deprecation, and testing
Message-ID: <m2r17asqrk.fsf@caffeine.hv.danplanet.com>

Hi all,

As you probably already know from gmann's reporting, the TC recently
passed a resolution[1] regarding the release cadence. This, in response
to some discussion around moving to different release cycle lengths,
becomes mostly a change regarding our deprecation procedures, as well as
a call to support the ability to skip certain releases (designated
"tock" releases) while sticking on a yearly cycle (designated "tick"
releases).

In support of the goal of moving to this new cadence for the AA release
(i.e. the yet unnamed release to come after Zed), I have introduced[2] a
new grenade-skip-level job, which tests skipping "tock" releases and
going straight from one tick to the following. We intend this to be a
voting job in AA, making sure it works from Yoga->AA. Right now it tests
Wallaby->Yoga for informational purposes. We would recommend projects
enable that as voting, or define their own job to do similar testing as
soon as possible. Manila has already started[3] this. Note that existing
grenade testing between each adjacent release remains unchanged in this
scheme.

On the topic of deprecation, we moved the current definition of
deprecation procedures from the soon-to-be-removed tag definition to a
new document in project-team-guide[4]. This now describes the procedures
in terms of the tick-tock release arrangement, and is worth a read.

As the PTG is coming up, we will certainly discuss this topic in the PTL
Interaction[5] session. It would also be advisable to discuss the
project-specific details of this in the various project sessions. By
identifying this plan early and setting our goals for AA, we have a good
amount of time between now and then to get our heads wrapped around what
(if any) things we need to be doing. Luckily, the introduction of the
job to test this from wallaby to yoga required almost no project changes
to get working, which is a good indicator that it won't be too laborious
for most projects to adopt.

--Dan

1: https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html
2: https://review.opendev.org/c/openstack/grenade/+/826101
3: https://review.opendev.org/c/openstack/manila/+/830277
4: https://docs.openstack.org/project-team-guide/deprecation.html
5: https://etherpad.opendev.org/p/tc-ptl-interaction-zed


From smooney at redhat.com  Wed Mar  9 23:11:09 2022
From: smooney at redhat.com (Sean Mooney)
Date: Wed, 09 Mar 2022 23:11:09 +0000
Subject: [nova] VM ending up in a different availability zone after
 resizing vm instance
In-Reply-To: <CAJ1=nZdKoRjNd8OPiqSogYsg87EXSZCHY_pdS3gkMv4EG7JCgw@mail.gmail.com>
References: <CAJ1=nZdKoRjNd8OPiqSogYsg87EXSZCHY_pdS3gkMv4EG7JCgw@mail.gmail.com>
Message-ID: <e951c66b75ebc387a7e78b8ff80b97319ed49888.camel@redhat.com>

On Wed, 2022-03-09 at 14:40 -0600, hai wu wrote:
> VM ends up in a different availability zone after resizing the vm
> instance. The default openstack nova behavior should have prevented
> this from happening, correct? What could have caused this?
if the vm was created without a AZ requested tehn when it is resized i think it can change AZ
but that woudl only happen if you chagne the defautl AZ or have different AZ configured on different schedulers i think.

> 



From tkajinam at redhat.com  Wed Mar  9 23:14:02 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Thu, 10 Mar 2022 08:14:02 +0900
Subject: [heat][rbac] Management of "system resources" with SRBAC enforced
In-Reply-To: <17f6fd5cf65.b558d8a025830.2422670910290295781@ghanshyammann.com>
References: <CAL_crJSy6_-+0oLZC1PP=RoE-2fNMn0jytsv9UxJOZ2BxYbeeQ@mail.gmail.com>
 <CA+WCyyovVWVhudrs0RGzoKedH7DdRCjgR1dEF5icK9Epr7XOEQ@mail.gmail.com>
 <CAL_crJSPv3pmJ31DVJKSurVOLGZM5MOtfapKN1s+DxA-Yhr7AQ@mail.gmail.com>
 <17f6fd5cf65.b558d8a025830.2422670910290295781@ghanshyammann.com>
Message-ID: <CAL_crJR7rLqGoOe8oq=jiVvLQoeGq0Pe=3CPnUNaz6sV29wKUw@mail.gmail.com>

On Thu, Mar 10, 2022 at 2:59 AM Ghanshyam Mann <gmann at ghanshyammann.com>
wrote:

>  ---- On Wed, 09 Mar 2022 06:43:03 -0600 Takashi Kajinami <
> tkajinam at redhat.com> wrote ----
>  > Hi Rico.
>  > Thank you for your insights.Please find my replies inline.
>  >
>  > On Wed, Mar 9, 2022 at 6:22 PM Rico Lin <ricolin at ricolky.com> wrote:
>  >
>  >
>  > On Wed, Mar 9, 2022 at 1:57 PM Takashi Kajinami <tkajinam at redhat.com>
> wrote:
>  > >
>  > > Hello,
>  > >
>  > >
>  > > I've been working on updating policy rules in heat according to the
> latest
>  > > guideline for SRBAC implementation.
>  >
>  > Thanks so much for working on it, definitely +1 on enhancing security.
>  > >
>  > >  [1]
> https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#direction-change
>  > >
>  > > However this change reveals one potential issue with system resources.
>  > >
>  > > In heat there are some resource types like OS::Nova::Flavor or
> OS::Keystone::User
>  > > which is allowed for only system users. (I'll call these resources as
> "system resources" here)
>  > We create those resources based on checking `role:admin`, so project
> admin is accepted.This means a user under that project with role:admin, can
> operate those resources.I'm not sure what system user means here, so
> correct me if I'm wrong.
>  > The core problem is that backend services like nova enforces different
> policies from just role:admin whenSRBAC is enforced. I reported that a
> while ago as https://storyboard.openstack.org/#!/story/2009787 .
>  >
>  > The main problem here is that heat currently supports resources which
> require different scopes of credentials.For example, once all deprecated
> policy rules are removed, nova allows project users to create
> instances(OS::Nova::Server)[1],while nova allows only system admins to
> create flavors(OS::Nova::Flavor)[2]. Currently Heat leverages the user
> credentialused to create a stack when Heat requests backend services to
> create its resources, and it's "impossible" to create a stackwith these two
> resources by a single credential (as each token can be scoped by project or
> system.
>  > [1]
> https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/servers.py#L210[2]
> https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/flavor_manage.py#L28-L36
>  > If we keep allowing system users to create stacks, then it would allow
> users to create system resourceslike flavors. But this never solves the
> problem with the "mixed" pattern which I described above.Hope this will
> explain these three options more clearly.
>  >
>  > >
>  > > Because heat uses user credentials to create resources in backend
> services, if we require
>  > > project scope for stack/resource management then we are no longer
> able to create these system
>  > > resources as part of stack. (*1)>
>  > > There are some options I can think of at this moment.
>  > >
>  > > 1. Deprecate and remove all resources which require system scope
>  > > Pros
>  > > - This is most easy solution to be implemented
>  > > Cons
>  > > - This one has the biggest user impact
>  >
>  > Don't :)
>
> Yeah, not sure how removing will work.
>
>  > > 2. Use service credential for resource creation
>  > > Pros:
>  > > - This might have smallest user impact
>  > > Cons:
>  > > - This requires a relatively big change in heat's architecture, which
> I've not yet evaluated.
>  > > - We need to determine the project scope role to be allowed to do
> system operation.
>  > >
>  > I think this is something we can discuss more.
>  > > 3. Implement additional project-role in each service to allow
> creation via stack creation.
>  > > Pros:
>  > > - This would avoid user impact.
>  > > Cons:
>  > > - requires work in multiple components.
>  > > - We need to determine the project scope role to be allowed to do
> system operation
>  >
>  >
>  > Indeed current stack operation require `(role:admin and
> system_scope:all) OR (role:member and project_id:%(project_id)s)`.And if we
> remove the system part and keep `(role:member and
> project_id:%(project_id)s)`, will mean only a user in that project with a
> member role can operate stack, and if the user got also admin role, that
> user can manage User/Flavor resources through stack too.The main problem
> here is that nova will no longer allow project admins to create flavors,and
> it will require system admin when SRBAC is enforced(which means all
> deprecated rulesare disabled)
>  >
>  > Also, note thatFor the case of Nova::Flavor, both policies from Nova
> and Heat resource will be enforced here, so it only accepts the
> intersection part of rules.
>  > So if we go with removing the system admin, that means it's time to
> also remove some deprecated global scope operation.
>  > IMO, to accept Project Admin or member make more reasonable (like you
> proposed in option 3)
>
> This is a similar case that we discussed in the service role ML thread[1]
> or in the spec[2].
>
> For such cases only, where services need to interact with another service
> we will have the 'service' as
> a special role. In this case, the heat having the project scoped token
> will use the 'service' role token for
> Nova Flavor APIs calls.  Now whether that 'service' role token needs to be
> system scoped or not is
> open question Mark brought up in that discussion. IMO, we should use the
> scoped token even in case
> of 'service' role and do not skip scope checks for 'service' role in oslo
> policy as it can be a valid role used
> by any users at production. So with the new SRBAC, heat needs to use the
> system scoped 'service' role token.
>
> But as 'service' role is not yet implemented by keystone[2], we can use
> the legacy admin token which is currently
> used in heat or other service-to-service interaction.
>

Thanks gmann for inputs.

HoweverI think we still need a different role here.

The role I've mentioned here is not the role assigned to the Heat service
user but the project-role
assigned to users to allow them create stacks with system resources like
nova flavor or keystone user.
This role is assigned to actual cloud users so service would not be
appropriate.

I thought of using the admin role initially but this means that we provide
a way to "bypass" policy check
and expose system operations to project users.

As a side note, current heat does not use its own credential but user
credentials used for stack API calls.
We can introduce this mechanism and let heat manage system resources by its
service user but that is
the completely new feature we need to implement.


> [1]
> http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026777.html
> [2] https://review.opendev.org/c/openstack/keystone-specs/+/818616
>
> -gmann
>
>  > >
>  > > Thank you,
>  > > Takashi
>  > >
>  >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/7d4b64ae/attachment-0001.htm>

From tkajinam at redhat.com  Thu Mar 10 00:00:53 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Thu, 10 Mar 2022 09:00:53 +0900
Subject: [puppet] Gate blocker: CentOS 9 integration jobs are broken
In-Reply-To: <ab714de2-5492-458c-9ff2-8bd75ca60955@www.fastmail.com>
References: <CAL_crJSq8sfwqybc9CC_iQ6sqHFSQNaFnE6uReNfyofch=icKg@mail.gmail.com>
 <CAL_crJTJz+BjSsg+NyTAdhvC9HL_F2WR3-TtUs1nWGY30ZN3Tg@mail.gmail.com>
 <CAL_crJTrYvHcUHK+QBB0qgPGP6y632VmT+AuYkir+64PX-fXqA@mail.gmail.com>
 <ab714de2-5492-458c-9ff2-8bd75ca60955@www.fastmail.com>
Message-ID: <CAL_crJRJ3hrvbcATdXb2NJ=7p3DU8m=oA5cTfbGsSSB5quiSYw@mail.gmail.com>

Thanks Clark for follow-up.
My explanation was not correct, and I should have said RSA + SHA1 no longer
works.

Our problem was that the key generated by create keypair api in nova uses
RSA + SHA1
thus ssh by tempest with that key no longer works since SHA1 was disabled
in a recent update
in CentOS 9 Stream.

On Thu, Mar 10, 2022 at 12:31 AM Clark Boylan <cboylan at sapwetik.org> wrote:

> On Tue, Mar 8, 2022, at 10:01 PM, Takashi Kajinami wrote:
> > Both of the two issues have been resolved and c9s integration jobs are
> > voting again.
> >
> > As a side note, It seems the second issue within tempest tests was
> > caused by recent
> > change in openssl in CentOS9 Stream repo and rsa key is no longer
> > allowed for ssh.
>
> To clarify this is RSA no longer allowed with SSH or is it just RSA +
> SHA1? The RSA + SHA1 problem has been known for a bit due to Fedora making
> that update a while back. But RSA + SHA2 does work on Fedora. The issue
> there is some servers like the dropbear server in Cirros and the MINA SSHD
> used by Gerrit either don't support RSA + SHA2 or lack the required
> negotation bits to allow RSA + SHA2.
>
> Gerrit 3.6 should fix this, and I believe there is some effort to update
> Cirros to a newer version of dropbear which will support RSA + SHA2.
>
> Separately, it might be a good idea to try and push back on these systems
> to stop defaulting to RSA + SHA1 if that combination is not allowed. They
> should default to RSA + SHA2 if that is the only version of RSA that will
> function on their platform. Then if the server supports it but cannot
> negotiate it properly (this is the case with Gerrit) it should continue to
> function.
>
> > We worked around the issue by the feature in tempest to use a different
> > format but
> > I've submitted a feedback to know about current usage of rsa key[1].
> >  [1] https://bugs.launchpad.net/nova/+bug/1962726
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/b8726fa5/attachment.htm>

From gmann at ghanshyammann.com  Thu Mar 10 00:46:03 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 09 Mar 2022 18:46:03 -0600
Subject: [all][tc] Technical Committee next weekly meeting on Mar 10th
 at 1500 UTC
In-Reply-To: <17f660636b4.eeeb3593385325.4356497671912212953@ghanshyammann.com>
References: <17f660636b4.eeeb3593385325.4356497671912212953@ghanshyammann.com>
Message-ID: <17f714a36b8.d35c865134344.2721154290591453783@ghanshyammann.com>

Hello Everyone,

Below is the agenda for Tomorrow's TC IRC meeting schedule at 1500 UTC.

https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

== Agenda for tomorrow's TC meeting ==

* Roll call

* Follow up on past action items

* Gate health check
** Fixing Zuul config error in OpenStack
*** https://etherpad.opendev.org/p/zuul-config-error-openstack

* Z cycle Leaderless projects
** https://etherpad.opendev.org/p/zed-leaderless

* PTG Preparation
** http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027381.html
** https://etherpad.opendev.org/p/tc-zed-ptg
** TC + Community Leaders Interaction
*** http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027382.html

* Check on Yoga Tracker progress
** https://etherpad.opendev.org/p/tc-yoga-tracker

* Adding FIPs gate jobs and direction on how to run them in optimize way w.r.t. infra resource shortage.

* Open Reviews
** https://review.opendev.org/q/projects:openstack/governance+is:open

-gmann

 ---- On Mon, 07 Mar 2022 14:15:57 -0600 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > 
 > Hello Everyone,
 > 
 > Technical Committee's next weekly meeting is scheduled for Mar 10th at 1500 UTC.
 > 
 > If you would like to add topics for discussion, please add them to the below wiki page by
 > Wednesday, Mar 9th , at 2100 UTC.
 > 
 > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting
 > 
 > -gmann
 > 
 > 


From haiwu.us at gmail.com  Thu Mar 10 00:57:06 2022
From: haiwu.us at gmail.com (hai wu)
Date: Wed, 9 Mar 2022 18:57:06 -0600
Subject: [nova] VM ending up in a different availability zone after
 resizing vm instance
In-Reply-To: <e951c66b75ebc387a7e78b8ff80b97319ed49888.camel@redhat.com>
References: <CAJ1=nZdKoRjNd8OPiqSogYsg87EXSZCHY_pdS3gkMv4EG7JCgw@mail.gmail.com>
 <e951c66b75ebc387a7e78b8ff80b97319ed49888.camel@redhat.com>
Message-ID: <CAJ1=nZeBcd42+TXA_FZAH6AaHQE3BPb1J2uM5UWe-A7N9eRrmQ@mail.gmail.com>

Is it possible to add AZ information to existing VMs (not during VM
creation)? We did not configure AZ initially, so by default they are
with 'nova' default zone. AZ was added on a later stage.. I don't
think we have different AZ configured on different schedulers. we have
to toggle host's AZ all the time in order to be able to migrate VMs
around..

On Wed, Mar 9, 2022 at 5:11 PM Sean Mooney <smooney at redhat.com> wrote:
>
> On Wed, 2022-03-09 at 14:40 -0600, hai wu wrote:
> > VM ends up in a different availability zone after resizing the vm
> > instance. The default openstack nova behavior should have prevented
> > this from happening, correct? What could have caused this?
> if the vm was created without a AZ requested tehn when it is resized i think it can change AZ
> but that woudl only happen if you chagne the defautl AZ or have different AZ configured on different schedulers i think.
>
> >
>


From gmann at ghanshyammann.com  Thu Mar 10 01:13:42 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 09 Mar 2022 19:13:42 -0600
Subject: [heat][rbac] Management of "system resources" with SRBAC enforced
In-Reply-To: <CAL_crJR7rLqGoOe8oq=jiVvLQoeGq0Pe=3CPnUNaz6sV29wKUw@mail.gmail.com>
References: <CAL_crJSy6_-+0oLZC1PP=RoE-2fNMn0jytsv9UxJOZ2BxYbeeQ@mail.gmail.com>
 <CA+WCyyovVWVhudrs0RGzoKedH7DdRCjgR1dEF5icK9Epr7XOEQ@mail.gmail.com>
 <CAL_crJSPv3pmJ31DVJKSurVOLGZM5MOtfapKN1s+DxA-Yhr7AQ@mail.gmail.com>
 <17f6fd5cf65.b558d8a025830.2422670910290295781@ghanshyammann.com>
 <CAL_crJR7rLqGoOe8oq=jiVvLQoeGq0Pe=3CPnUNaz6sV29wKUw@mail.gmail.com>
Message-ID: <17f71638687.128ce54ec34578.5876409253282361143@ghanshyammann.com>

 ---- On Wed, 09 Mar 2022 17:14:02 -0600 Takashi Kajinami <tkajinam at redhat.com> wrote ----
 > 
 > 
 > On Thu, Mar 10, 2022 at 2:59 AM Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
 >  ---- On Wed, 09 Mar 2022 06:43:03 -0600 Takashi Kajinami <tkajinam at redhat.com> wrote ----
 >  > Hi Rico.
 >  > Thank you for your insights.Please find my replies inline.
 >  > 
 >  > On Wed, Mar 9, 2022 at 6:22 PM Rico Lin <ricolin at ricolky.com> wrote:
 >  > 
 >  > 
 >  > On Wed, Mar 9, 2022 at 1:57 PM Takashi Kajinami <tkajinam at redhat.com> wrote:
 >  > >
 >  > > Hello,
 >  > >
 >  > >
 >  > > I've been working on updating policy rules in heat according to the latest
 >  > > guideline for SRBAC implementation.
 >  > 
 >  > Thanks so much for working on it, definitely +1 on enhancing security.
 >  > >
 >  > >  [1] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#direction-change
 >  > >
 >  > > However this change reveals one potential issue with system resources.
 >  > >
 >  > > In heat there are some resource types like OS::Nova::Flavor or OS::Keystone::User
 >  > > which is allowed for only system users. (I'll call these resources as "system resources" here)
 >  > We create those resources based on checking `role:admin`, so project admin is accepted.This means a user under that project with role:admin, can operate those resources.I'm not sure what system user means here, so correct me if I'm wrong.
 >  > The core problem is that backend services like nova enforces different policies from just role:admin whenSRBAC is enforced. I reported that a while ago as https://storyboard.openstack.org/#!/story/2009787 .
 >  > 
 >  > The main problem here is that heat currently supports resources which require different scopes of credentials.For example, once all deprecated policy rules are removed, nova allows project users to create instances(OS::Nova::Server)[1],while nova allows only system admins to create flavors(OS::Nova::Flavor)[2]. Currently Heat leverages the user credentialused to create a stack when Heat requests backend services to create its resources, and it's "impossible" to create a stackwith these two resources by a single credential (as each token can be scoped by project or system.
 >  > [1] https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/servers.py#L210[2] https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/flavor_manage.py#L28-L36
 >  > If we keep allowing system users to create stacks, then it would allow users to create system resourceslike flavors. But this never solves the problem with the "mixed" pattern which I described above.Hope this will explain these three options more clearly.
 >  >  
 >  > >
 >  > > Because heat uses user credentials to create resources in backend services, if we require
 >  > > project scope for stack/resource management then we are no longer able to create these system
 >  > > resources as part of stack. (*1)>
 >  > > There are some options I can think of at this moment.
 >  > >
 >  > > 1. Deprecate and remove all resources which require system scope
 >  > > Pros
 >  > > - This is most easy solution to be implemented
 >  > > Cons
 >  > > - This one has the biggest user impact
 >  > 
 >  > Don't :)
 > 
 > Yeah, not sure how removing will work.
 > 
 >  > > 2. Use service credential for resource creation
 >  > > Pros:
 >  > > - This might have smallest user impact
 >  > > Cons:
 >  > > - This requires a relatively big change in heat's architecture, which I've not yet evaluated.
 >  > > - We need to determine the project scope role to be allowed to do system operation.
 >  > >  
 >  > I think this is something we can discuss more.
 >  > > 3. Implement additional project-role in each service to allow creation via stack creation.
 >  > > Pros:
 >  > > - This would avoid user impact.
 >  > > Cons:
 >  > > - requires work in multiple components.
 >  > > - We need to determine the project scope role to be allowed to do system operation
 >  > 
 >  > 
 >  > Indeed current stack operation require `(role:admin and system_scope:all) OR (role:member and project_id:%(project_id)s)`.And if we remove the system part and keep `(role:member and project_id:%(project_id)s)`, will mean only a user in that project with a member role can operate stack, and if the user got also admin role, that user can manage User/Flavor resources through stack too.The main problem here is that nova will no longer allow project admins to create flavors,and it will require system admin when SRBAC is enforced(which means all deprecated rulesare disabled)
 >  >  
 >  > Also, note thatFor the case of Nova::Flavor, both policies from Nova and Heat resource will be enforced here, so it only accepts the intersection part of rules.
 >  > So if we go with removing the system admin, that means it's time to also remove some deprecated global scope operation.
 >  > IMO, to accept Project Admin or member make more reasonable (like you proposed in option 3)
 > 
 > This is a similar case that we discussed in the service role ML thread[1] or in the spec[2].
 > 
 > For such cases only, where services need to interact with another service we will have the 'service' as
 > a special role. In this case, the heat having the project scoped token will use the 'service' role token for
 > Nova Flavor APIs calls.  Now whether that 'service' role token needs to be system scoped or not is
 > open question Mark brought up in that discussion. IMO, we should use the scoped token even in case
 > of 'service' role and do not skip scope checks for 'service' role in oslo policy as it can be a valid role used
 > by any users at production. So with the new SRBAC, heat needs to use the system scoped 'service' role token.
 > 
 > But as 'service' role is not yet implemented by keystone[2], we can use the legacy admin token which is currently
 > used in heat or other service-to-service interaction. 
 > 
 > Thanks gmann for inputs.
 > HoweverI think we still need a different role here.
 > The role I've mentioned here is not the role assigned to the Heat service user but the project-roleassigned to users to allow them create stacks with system resources like nova flavor or keystone user.This role is assigned to actual cloud users so service would not be appropriate.
 > 
 > I thought of using the admin role initially but this means that we provide a way to "bypass" policy checkand expose system operations to project users.
 > 
 > As a side note, current heat does not use its own credential but user credentials used for stack API calls. 
 > We can introduce this mechanism and let heat manage system resources by its service user but that isthe completely new feature we need to implement.

Thanks for the detailed information. For service to service interaction, I think heat needs to start using the configured
service user token instead of using actual user token.
 
For example nova use for neutron and similarly for other service interaction
- https://zuul.opendev.org/t/openstack/build/654ccb626d0e41a69308db1ed3328824/log/controller/logs/etc/nova/nova_conf.txt#40-51

-gmann

 >  [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026777.html
 > [2] https://review.opendev.org/c/openstack/keystone-specs/+/818616
 > 
 > -gmann
 > 
 >  > >
 >  > > Thank you,
 >  > > Takashi
 >  > >
 >  > 
 > 
 > 


From tkajinam at redhat.com  Thu Mar 10 01:28:03 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Thu, 10 Mar 2022 10:28:03 +0900
Subject: [heat][rbac] Management of "system resources" with SRBAC enforced
In-Reply-To: <17f71638687.128ce54ec34578.5876409253282361143@ghanshyammann.com>
References: <CAL_crJSy6_-+0oLZC1PP=RoE-2fNMn0jytsv9UxJOZ2BxYbeeQ@mail.gmail.com>
 <CA+WCyyovVWVhudrs0RGzoKedH7DdRCjgR1dEF5icK9Epr7XOEQ@mail.gmail.com>
 <CAL_crJSPv3pmJ31DVJKSurVOLGZM5MOtfapKN1s+DxA-Yhr7AQ@mail.gmail.com>
 <17f6fd5cf65.b558d8a025830.2422670910290295781@ghanshyammann.com>
 <CAL_crJR7rLqGoOe8oq=jiVvLQoeGq0Pe=3CPnUNaz6sV29wKUw@mail.gmail.com>
 <17f71638687.128ce54ec34578.5876409253282361143@ghanshyammann.com>
Message-ID: <CAL_crJShD7Th6Q0UQtmCwJfSgdKtDkcY_wBdYMc4CA+j6a0R8g@mail.gmail.com>

On Thu, Mar 10, 2022 at 10:13 AM Ghanshyam Mann <gmann at ghanshyammann.com>
wrote:

>  ---- On Wed, 09 Mar 2022 17:14:02 -0600 Takashi Kajinami <
> tkajinam at redhat.com> wrote ----
>  >
>  >
>  > On Thu, Mar 10, 2022 at 2:59 AM Ghanshyam Mann <gmann at ghanshyammann.com>
> wrote:
>  >  ---- On Wed, 09 Mar 2022 06:43:03 -0600 Takashi Kajinami <
> tkajinam at redhat.com> wrote ----
>  >  > Hi Rico.
>  >  > Thank you for your insights.Please find my replies inline.
>  >  >
>  >  > On Wed, Mar 9, 2022 at 6:22 PM Rico Lin <ricolin at ricolky.com> wrote:
>  >  >
>  >  >
>  >  > On Wed, Mar 9, 2022 at 1:57 PM Takashi Kajinami <tkajinam at redhat.com>
> wrote:
>  >  > >
>  >  > > Hello,
>  >  > >
>  >  > >
>  >  > > I've been working on updating policy rules in heat according to
> the latest
>  >  > > guideline for SRBAC implementation.
>  >  >
>  >  > Thanks so much for working on it, definitely +1 on enhancing
> security.
>  >  > >
>  >  > >  [1]
> https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#direction-change
>  >  > >
>  >  > > However this change reveals one potential issue with system
> resources.
>  >  > >
>  >  > > In heat there are some resource types like OS::Nova::Flavor or
> OS::Keystone::User
>  >  > > which is allowed for only system users. (I'll call these resources
> as "system resources" here)
>  >  > We create those resources based on checking `role:admin`, so project
> admin is accepted.This means a user under that project with role:admin, can
> operate those resources.I'm not sure what system user means here, so
> correct me if I'm wrong.
>  >  > The core problem is that backend services like nova enforces
> different policies from just role:admin whenSRBAC is enforced. I reported
> that a while ago as https://storyboard.openstack.org/#!/story/2009787 .
>  >  >
>  >  > The main problem here is that heat currently supports resources
> which require different scopes of credentials.For example, once all
> deprecated policy rules are removed, nova allows project users to create
> instances(OS::Nova::Server)[1],while nova allows only system admins to
> create flavors(OS::Nova::Flavor)[2]. Currently Heat leverages the user
> credentialused to create a stack when Heat requests backend services to
> create its resources, and it's "impossible" to create a stackwith these two
> resources by a single credential (as each token can be scoped by project or
> system.
>  >  > [1]
> https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/servers.py#L210[2]
> https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/flavor_manage.py#L28-L36
>  >  > If we keep allowing system users to create stacks, then it would
> allow users to create system resourceslike flavors. But this never solves
> the problem with the "mixed" pattern which I described above.Hope this will
> explain these three options more clearly.
>  >  >
>  >  > >
>  >  > > Because heat uses user credentials to create resources in backend
> services, if we require
>  >  > > project scope for stack/resource management then we are no longer
> able to create these system
>  >  > > resources as part of stack. (*1)>
>  >  > > There are some options I can think of at this moment.
>  >  > >
>  >  > > 1. Deprecate and remove all resources which require system scope
>  >  > > Pros
>  >  > > - This is most easy solution to be implemented
>  >  > > Cons
>  >  > > - This one has the biggest user impact
>  >  >
>  >  > Don't :)
>  >
>  > Yeah, not sure how removing will work.
>  >
>  >  > > 2. Use service credential for resource creation
>  >  > > Pros:
>  >  > > - This might have smallest user impact
>  >  > > Cons:
>  >  > > - This requires a relatively big change in heat's architecture,
> which I've not yet evaluated.
>  >  > > - We need to determine the project scope role to be allowed to do
> system operation.
>  >  > >
>  >  > I think this is something we can discuss more.
>  >  > > 3. Implement additional project-role in each service to allow
> creation via stack creation.
>  >  > > Pros:
>  >  > > - This would avoid user impact.
>  >  > > Cons:
>  >  > > - requires work in multiple components.
>  >  > > - We need to determine the project scope role to be allowed to do
> system operation
>  >  >
>  >  >
>  >  > Indeed current stack operation require `(role:admin and
> system_scope:all) OR (role:member and project_id:%(project_id)s)`.And if we
> remove the system part and keep `(role:member and
> project_id:%(project_id)s)`, will mean only a user in that project with a
> member role can operate stack, and if the user got also admin role, that
> user can manage User/Flavor resources through stack too.The main problem
> here is that nova will no longer allow project admins to create flavors,and
> it will require system admin when SRBAC is enforced(which means all
> deprecated rulesare disabled)
>  >  >
>  >  > Also, note thatFor the case of Nova::Flavor, both policies from Nova
> and Heat resource will be enforced here, so it only accepts the
> intersection part of rules.
>  >  > So if we go with removing the system admin, that means it's time to
> also remove some deprecated global scope operation.
>  >  > IMO, to accept Project Admin or member make more reasonable (like
> you proposed in option 3)
>  >
>  > This is a similar case that we discussed in the service role ML
> thread[1] or in the spec[2].
>  >
>  > For such cases only, where services need to interact with another
> service we will have the 'service' as
>  > a special role. In this case, the heat having the project scoped token
> will use the 'service' role token for
>  > Nova Flavor APIs calls.  Now whether that 'service' role token needs to
> be system scoped or not is
>  > open question Mark brought up in that discussion. IMO, we should use
> the scoped token even in case
>  > of 'service' role and do not skip scope checks for 'service' role in
> oslo policy as it can be a valid role used
>  > by any users at production. So with the new SRBAC, heat needs to use
> the system scoped 'service' role token.
>  >
>  > But as 'service' role is not yet implemented by keystone[2], we can use
> the legacy admin token which is currently
>  > used in heat or other service-to-service interaction.
>  >
>  > Thanks gmann for inputs.
>  > HoweverI think we still need a different role here.
>  > The role I've mentioned here is not the role assigned to the Heat
> service user but the project-roleassigned to users to allow them create
> stacks with system resources like nova flavor or keystone user.This role is
> assigned to actual cloud users so service would not be appropriate.
>  >
>  > I thought of using the admin role initially but this means that we
> provide a way to "bypass" policy checkand expose system operations to
> project users.
>  >
>  > As a side note, current heat does not use its own credential but user
> credentials used for stack API calls.
>  > We can introduce this mechanism and let heat manage system resources by
> its service user but that isthe completely new feature we need to implement.
>
> Thanks for the detailed information. For service to service interaction, I
> think heat needs to start using the configured
> service user token instead of using actual user token.
>
> For example nova use for neutron and similarly for other service
> interaction
> -
> https://zuul.opendev.org/t/openstack/build/654ccb626d0e41a69308db1ed3328824/log/controller/logs/etc/nova/nova_conf.txt#40-51
>

I'll look into that option but It might take some time because I've not yet
evaluated the impact of that change.
My current idea is to use service credentials for system resources only so
that we can keep using the user credential
for project resources.

As heat allows only project users to manage stacks, we need to determine
the project role to allow creating
stacks with such system resources. Does anyone have any suggestions about
this ?

Do we agree we can allow project-admin to create stacks with flavors or
keystone users as the previous policy rules
allow or should we implement a new role to restrict management of system
resources ?



> -gmann
>
>  >  [1]
> http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026777.html
>  > [2] https://review.opendev.org/c/openstack/keystone-specs/+/818616
>  >
>  > -gmann
>  >
>  >  > >
>  >  > > Thank you,
>  >  > > Takashi
>  >  > >
>  >  >
>  >
>  >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/4eb97c82/attachment-0001.htm>

From iurygregory at gmail.com  Thu Mar 10 03:11:01 2022
From: iurygregory at gmail.com (Iury Gregory)
Date: Thu, 10 Mar 2022 00:11:01 -0300
Subject: [ironic] Zed PTG slots
In-Reply-To: <CAFB36U1zi7hQVh9K5GLZpmxYaN3akzkN9qzzCN0P5HHcAL8Pbg@mail.gmail.com>
References: <CAJqPaj8M4BgPpsQPG9mtvnXkbHPVtSeK3cG1Ws+aaeC1skRsgw@mail.gmail.com>
 <CAORRS=nacYs+yiVRzto=TgvRJPnzXR_u3XAuGkJsmgd+-R3=vg@mail.gmail.com>
 <CAFB36U1zi7hQVh9K5GLZpmxYaN3akzkN9qzzCN0P5HHcAL8Pbg@mail.gmail.com>
Message-ID: <CAJqPaj_0r0WAaddxKTpEH8+4+h1RedmJkm5U9_5-G8=rTuopmw@mail.gmail.com>

Hello Ironicers and Stackers!

In our weekly meeting we decided to go with
*Option #3*
*16hrs Monday till Thursday*
--> 3hrs (EMEA afternoon + NA morning)
--> 1hr (NA afternoon/night + APAC morning)

On Monday it will be a bit complicated for me to have 3hrs of sessions for
EMEA/America, there is TC+PTL interaction from 14-16 UTC.
Here are my proposals, and feel free to provide other new formats!

*A.*
Monday:  16:00 - 17:00 UTC and 21:00 - 22:00 UTC
Tuesday Wednesday Thursday: 14:00 - 17:00 UTC  and 21:00 - 22:00 UTC
Friday: 14:00 - 16:00 UTC (in case we need the two hours from monday)

*B.*
Monday:  15:30 - 18:30 UTC and 21:00 - 22:00 UTC (Not 100% sure if we can
start/finish things half-past an hour)
Tuesday Wednesday Thursday: 14:00 - 17:00 UTC  and 21:00 - 22:00 UTC

*C.*
Monday:  14:00 - 17:00 UTC and 21:00 - 22:00 UTC
Tuesday Wednesday Thursday: 14:00 - 17:00 UTC  and 21:00 - 22:00 UTC

*D.*
Monday:  16:00 - 18:00 UTC and 21:00 - 22:00 UTC
Tuesday Wednesday Thursday: 14:00 - 17:00 UTC  and 21:00 - 22:00 UTC (We
can add the missing one hour in one of the days and have 14:00 - 18:00 UTC)

Please share your thoughts in this thread or in the #openstack-ironic
channel on OFTC =)

Thank you!

Em seg., 7 de mar. de 2022 ?s 09:13, Jacob Anders <janders at redhat.com>
escreveu:

> Thank you Iury and Riccardo.
>
> I also vote for 1 and 3.
>
> Thank you,
> Jacob
>
> On Fri, Mar 4, 2022 at 8:39 PM Riccardo Pittau <elfosardo at gmail.com>
> wrote:
>
>> Thanks Iury!
>>
>> My choices are for options #1 and #3
>>
>> Ciao!
>> Riccardo
>>
>> On Fri, Mar 4, 2022 at 4:28 AM Iury Gregory <iurygregory at gmail.com>
>> wrote:
>>
>>> Hello Ironicers!
>>>
>>> For the Zed PTG I'm planning to have some slots that will allow APAC
>>> contributors to participate in the discussions.
>>>
>>> Keep in mind that we have some guidelines we should try to follow:
>>> 1. Cross project discussions (like SIGs or support project teams) should
>>> be scheduled towards the start of the week so that any discussions that
>>> might shape those of other teams happen first.
>>> 2. No team should sign up for more than 4 hours per UTC day to help keep
>>> participants actively engaged.
>>> 3. No team should sign up for more than 16 hours across all time slots
>>> to avoid burning out our contributors and to enable participation in
>>> multiple teams discussions.
>>>
>>> Based on this I have the following proposals: (Feel free to provide more
>>> ideas also) =)
>>>  *Option  #1* *16hrs* Monday till Thursday
>>> 1h (APAC night + EMEA morning)
>>> 2hrs (EMEA afternoon + NA morning)
>>> 1hr (NA afternoon/night + APAC morning)
>>>
>>> *Option  #2* *15hrs* Tuesday till Friday
>>> 1h (APAC night + EMEA morning)
>>> 2hrs (EMEA afternoon + NA morning)
>>> 1hr (NA afternoon/night + APAC morning)
>>> * On Friday the NA + APAC session won't happen because is saturday for
>>> APAC contributors *
>>>
>>> *Option #3* *16hrs* Monday till Thursday
>>> 3hrs (EMEA afternoon + NA morning)
>>> 1hr (NA afternoon/night + APAC morning)
>>>
>>> *Option #4* *15hrs* Tuesday till Friday
>>> 3hrs (EMEA afternoon + NA morning)
>>> 1hr (NA afternoon/night + APAC morning)
>>> * On Friday the NA + APAC session won't happen because is saturday for
>>> APAC contributors *
>>>
>>> Please choose two options and we will vote during our upstream meeting
>>> on March 7th.
>>>
>>> Thank you!
>>>
>>> --
>>>
>>>
>>> *Att[]'sIury Gregory Melo Ferreira *
>>> *MSc in Computer Science at UFCG*
>>> *Part of the ironic-core and puppet-manager-core team in OpenStack*
>>> *Software Engineer at Red Hat Czech*
>>> *Social*: https://www.linkedin.com/in/iurygregory
>>> *E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*
>>>
>>

-- 


*Att[]'sIury Gregory Melo Ferreira *
*MSc in Computer Science at UFCG*
*Part of the ironic-core and puppet-manager-core team in OpenStack*
*Software Engineer at Red Hat Czech*
*Social*: https://www.linkedin.com/in/iurygregory
*E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/fc44bb0d/attachment.htm>

From ltomasbo at redhat.com  Thu Mar 10 07:12:09 2022
From: ltomasbo at redhat.com (Luis Tomas Bolivar)
Date: Thu, 10 Mar 2022 08:12:09 +0100
Subject: [Neutron][Octavia][ovn-octavia-provider] proposing Luis Tomas
 Bolivar for ovn-octavia-provider core reviewer
In-Reply-To: <CALg0jKkk6a-Tve6H4QvGOP1MPyQ8pDuesPKdTTDr20_Fm4SC=w@mail.gmail.com>
References: <CALg0jKmGBwSPowJRmcwukit1P26NvGeei8ay2VyDaM2BS2wUTg@mail.gmail.com>
 <CAB1EZBrAsQiLC__EmwuBp-EHOYQfummYh-EEgP8ihKDGoZzEwg@mail.gmail.com>
 <CALg0jKkk6a-Tve6H4QvGOP1MPyQ8pDuesPKdTTDr20_Fm4SC=w@mail.gmail.com>
Message-ID: <CAAxCcbtgWMhjpW_-w5DcL+v=AeLPs+J1Aa2ct4UjQO3v-Vc3aA@mail.gmail.com>

Thank you all!

On Wed, Mar 9, 2022 at 9:30 AM Lajos Katona <katonalala at gmail.com> wrote:

> Hi,
> I added Luis to ovn-octavia-provider-core group, sorry for sending this
> mail so late.
> Welcome Luis, and thanks for your work !
>
> Lajos Katona (lajoskatona)
>
> Lucas Alvares Gomes <lucasagomes at gmail.com> ezt ?rta (id?pont: 2022.
> m?rc. 1., K, 9:49):
>
>> +1 from me!
>>
>> On Mon, Feb 28, 2022 at 2:42 PM Lajos Katona <katonalala at gmail.com>
>> wrote:
>> >
>> > Hi
>> >
>> > I would like to propose Luis Tomas Bolivar (ltomasbo) as a core
>> reviewer to the ovn-octavia-provider project.
>> > Luis is very active in the project (see [1] and [2]) and has experience
>> with Kuryr side also which uses ovn-octavia-provider.
>> >
>> > As ovn-octavia-provider is a link between Neutron and Octavia I ask
>> both Neutron and Octavia cores to vote by answering to this thread, to have
>> a final decision.
>> > Thanks for your consideration
>> >
>> > [1]:
>> https://review.opendev.org/q/owner:ltomasbo%2540redhat.com+branch:master
>> > [2]:
>> https://www.stackalytics.io/report/contribution?module=neutron-group&project_type=openstack&days=60
>> >
>> > Cheers
>> > Lajos
>>
>

-- 
LUIS TOM?S BOL?VAR
Principal Software Engineer
Red Hat
Madrid, Spain
ltomasbo at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/48a00464/attachment-0001.htm>

From eblock at nde.ag  Thu Mar 10 08:17:05 2022
From: eblock at nde.ag (Eugen Block)
Date: Thu, 10 Mar 2022 08:17:05 +0000
Subject: Ussuri: Magnum
Message-ID: <20220310081705.Horde._2Ci8yL5UqYKhOHYL8diHRW@webmail.nde.ag>

Hi *,

I'm trying to get magnum to work in an Ussuri environment. There are  
some issues I'm facing and would like to ask you for some pointers  
what I might be doing wrong. The control nodes would have access to  
the internet through a proxy, I would like to avoid that but I don't  
know yet what my local registry needs to look like. So to get it  
working I'll go with the http_proxy. The first attempts failed due to  
various reasons, now I'm stuck at the invalid discovery_url. After  
some search I found that I need to create a new discovery_url like this:

controller02:~ # curl --silent -H "Accept: text/plain"  
https://discovery.etcd.io/new?size=1

Using that new URL I try to create a cluster like this:

controller02:~ # openstack coe cluster create kubernetes-cluster-8  
--cluster-template 9c7cfeff-3807-4b06-a4e6-a76f2ae0f612 --master-count  
1 --node-count 1 --keypair eblock --discovery-url  
https://discovery.etcd.io/<UUID>

The template contains the http and https proxy. The resulting error is this:

---snip---
HTTPSConnectionPool(host='discovery.etcd.io', port=443): Max retries  
exceeded with url: /<UUID>/_config/size (Caused by  
NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object  
at 0x7fd5e61dcfd0>: Failed to establish a new connection: [Errno 110]  
ETIMEDOUT',)): requests.exceptions.ConnectionError:  
HTTPSConnectionPool(host='discovery.etcd.io', port=443): Max retries  
exceeded with url: /<UUID>/_config/size (Caused by  
NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object  
at 0x7fd5e61dcfd0>: Failed to establish a new connection: [Errno 110]  
ETIMEDOUT',))
[...]
requests.exceptions.ConnectionError:  
HTTPSConnectionPool(host='discovery.etcd.io', port=443): Max retries  
exceeded with url: /<UUID>/_config/size (Caused by  
NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object  
at 0x7fd5e61dcfd0>: Failed to establish a new connection: [Errno 110]  
ETIMEDOUT',))
[...]
magnum.common.exception.GetClusterSizeFailed: Failed to get the size  
of cluster from 'https://discovery.etcd.io/<UUID>'.
---snip---

The stack trace is a little longer, of course, but this is the  
relevant part. Can anyone point me in the right direction? What am I  
missing? I also tried quay.io since discovery.etcd.io seems to be not  
maintained anymore, but there I can't even generate a new URL.

Any help is greatly appreciated!

Thanks
Eugen



From eblock at nde.ag  Thu Mar 10 08:18:32 2022
From: eblock at nde.ag (Eugen Block)
Date: Thu, 10 Mar 2022 08:18:32 +0000
Subject: Ussuri: Magnum failed to get the size of cluster
Message-ID: <20220310081832.Horde.F81FWTZI3cAtwykKwOwFCh7@webmail.nde.ag>

Hi *,

sorry for the repost, I forgot to edit the subject line.

I'm trying to get magnum to work in an Ussuri environment. There are  
some issues I'm facing and would like to ask you for some pointers  
what I might be doing wrong. The control nodes would have access to  
the internet through a proxy, I would like to avoid that but I don't  
know yet what my local registry needs to look like. So to get it  
working I'll go with the http_proxy. The first attempts failed due to  
various reasons, now I'm stuck at the invalid discovery_url. After  
some search I found that I need to create a new discovery_url like this:

controller02:~ # curl --silent -H "Accept: text/plain"  
https://discovery.etcd.io/new?size=1

Using that new URL I try to create a cluster like this:

controller02:~ # openstack coe cluster create kubernetes-cluster-8  
--cluster-template 9c7cfeff-3807-4b06-a4e6-a76f2ae0f612 --master-count  
1 --node-count 1 --keypair eblock --discovery-url  
https://discovery.etcd.io/<UUID>

The template contains the http and https proxy. The resulting error is this:

---snip---
HTTPSConnectionPool(host='discovery.etcd.io', port=443): Max retries  
exceeded with url: /<UUID>/_config/size (Caused by  
NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object  
at 0x7fd5e61dcfd0>: Failed to establish a new connection: [Errno 110]  
ETIMEDOUT',)): requests.exceptions.ConnectionError:  
HTTPSConnectionPool(host='discovery.etcd.io', port=443): Max retries  
exceeded with url: /<UUID>/_config/size (Caused by  
NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object  
at 0x7fd5e61dcfd0>: Failed to establish a new connection: [Errno 110]  
ETIMEDOUT',))
[...]
requests.exceptions.ConnectionError:  
HTTPSConnectionPool(host='discovery.etcd.io', port=443): Max retries  
exceeded with url: /<UUID>/_config/size (Caused by  
NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object  
at 0x7fd5e61dcfd0>: Failed to establish a new connection: [Errno 110]  
ETIMEDOUT',))
[...]
magnum.common.exception.GetClusterSizeFailed: Failed to get the size  
of cluster from 'https://discovery.etcd.io/<UUID>'.
---snip---

The stack trace is a little longer, of course, but this is the  
relevant part. Can anyone point me in the right direction? What am I  
missing? I also tried quay.io since discovery.etcd.io seems to be not  
maintained anymore, but there I can't even generate a new URL.

Any help is greatly appreciated!

Thanks
Eugen



From mark at stackhpc.com  Thu Mar 10 09:01:44 2022
From: mark at stackhpc.com (Mark Goddard)
Date: Thu, 10 Mar 2022 09:01:44 +0000
Subject: [TC][PTL][ops][all] Release cadence, deprecation, and testing
In-Reply-To: <m2r17asqrk.fsf@caffeine.hv.danplanet.com>
References: <m2r17asqrk.fsf@caffeine.hv.danplanet.com>
Message-ID: <CAFHSqWrkkW0XF_G0L8Av4h-V7mu=Wv2BwKLBz3QhspbOtQrmkg@mail.gmail.com>

On Wed, 9 Mar 2022 at 22:35, Dan Smith <dms at danplanet.com> wrote:
>
> Hi all,
>
> As you probably already know from gmann's reporting, the TC recently
> passed a resolution[1] regarding the release cadence. This, in response
> to some discussion around moving to different release cycle lengths,
> becomes mostly a change regarding our deprecation procedures, as well as
> a call to support the ability to skip certain releases (designated
> "tock" releases) while sticking on a yearly cycle (designated "tick"
> releases).
>
> In support of the goal of moving to this new cadence for the AA release
> (i.e. the yet unnamed release to come after Zed), I have introduced[2] a
> new grenade-skip-level job, which tests skipping "tock" releases and
> going straight from one tick to the following. We intend this to be a
> voting job in AA, making sure it works from Yoga->AA. Right now it tests
> Wallaby->Yoga for informational purposes. We would recommend projects
> enable that as voting, or define their own job to do similar testing as
> soon as possible. Manila has already started[3] this. Note that existing
> grenade testing between each adjacent release remains unchanged in this
> scheme.
>
> On the topic of deprecation, we moved the current definition of
> deprecation procedures from the soon-to-be-removed tag definition to a
> new document in project-team-guide[4]. This now describes the procedures
> in terms of the tick-tock release arrangement, and is worth a read.
>
> As the PTG is coming up, we will certainly discuss this topic in the PTL
> Interaction[5] session. It would also be advisable to discuss the
> project-specific details of this in the various project sessions. By
> identifying this plan early and setting our goals for AA, we have a good
> amount of time between now and then to get our heads wrapped around what
> (if any) things we need to be doing. Luckily, the introduction of the
> job to test this from wallaby to yoga required almost no project changes
> to get working, which is a good indicator that it won't be too laborious
> for most projects to adopt.
>
> --Dan
>
> 1: https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html
> 2: https://review.opendev.org/c/openstack/grenade/+/826101
> 3: https://review.opendev.org/c/openstack/manila/+/830277
> 4: https://docs.openstack.org/project-team-guide/deprecation.html
> 5: https://etherpad.opendev.org/p/tc-ptl-interaction-zed
>

Thanks for writing this up, Dan. Overall it seems sensible. One thing
that jumps out from the TC resolution is this:

"This scheme does not necessarily dictate that live or rolling
upgrades need to be supported between tick releases. Meaning RPC
compatibility between N to N-1 guarantees can remain, resulting in
deployments that are on a tick-tick release schedule requiring some
downtime during an upgrade because components will be spanning more
than two actual releases."

>From the perspective of deployment tools, this would mean needing to
support two different upgrade strategies. Given the constraints around
DB migrations, would it be too much effort for projects to also
support N-2 to N RPC compatibility?

Mark


From eblock at nde.ag  Thu Mar 10 10:07:16 2022
From: eblock at nde.ag (Eugen Block)
Date: Thu, 10 Mar 2022 10:07:16 +0000
Subject: Ussuri: Magnum failed to get the size of cluster
In-Reply-To: <20220310081832.Horde.F81FWTZI3cAtwykKwOwFCh7@webmail.nde.ag>
Message-ID: <20220310100716.Horde.1fltWO_9U1fpVuAil0-zqyu@webmail.nde.ag>

Replying to myself:
It was fixed by adding environment variables to the magnum-conductor service:

[Service]
Environment="HTTP_PROXY=http://<HOST>:<PORT>"
Environment="HTTPS_PROXY=http://<HOST>:<PORT>"

Now I'm waiting for the first cluster to be created, the first  
resources were created successfully, now it seems stuck. But that's a  
different issue, this one can be considered resolved.

Thanks,
Eugen


Zitat von Eugen Block <eblock at nde.ag>:

> Hi *,
>
> sorry for the repost, I forgot to edit the subject line.
>
> I'm trying to get magnum to work in an Ussuri environment. There are  
> some issues I'm facing and would like to ask you for some pointers  
> what I might be doing wrong. The control nodes would have access to  
> the internet through a proxy, I would like to avoid that but I don't  
> know yet what my local registry needs to look like. So to get it  
> working I'll go with the http_proxy. The first attempts failed due  
> to various reasons, now I'm stuck at the invalid discovery_url.  
> After some search I found that I need to create a new discovery_url  
> like this:
>
> controller02:~ # curl --silent -H "Accept: text/plain"  
> https://discovery.etcd.io/new?size=1
>
> Using that new URL I try to create a cluster like this:
>
> controller02:~ # openstack coe cluster create kubernetes-cluster-8  
> --cluster-template 9c7cfeff-3807-4b06-a4e6-a76f2ae0f612  
> --master-count 1 --node-count 1 --keypair eblock --discovery-url  
> https://discovery.etcd.io/<UUID>
>
> The template contains the http and https proxy. The resulting error is this:
>
> ---snip---
> HTTPSConnectionPool(host='discovery.etcd.io', port=443): Max retries  
> exceeded with url: /<UUID>/_config/size (Caused by  
> NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection  
> object at 0x7fd5e61dcfd0>: Failed to establish a new connection:  
> [Errno 110] ETIMEDOUT',)): requests.exceptions.ConnectionError:  
> HTTPSConnectionPool(host='discovery.etcd.io', port=443): Max retries  
> exceeded with url: /<UUID>/_config/size (Caused by  
> NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection  
> object at 0x7fd5e61dcfd0>: Failed to establish a new connection:  
> [Errno 110] ETIMEDOUT',))
> [...]
> requests.exceptions.ConnectionError:  
> HTTPSConnectionPool(host='discovery.etcd.io', port=443): Max retries  
> exceeded with url: /<UUID>/_config/size (Caused by  
> NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection  
> object at 0x7fd5e61dcfd0>: Failed to establish a new connection:  
> [Errno 110] ETIMEDOUT',))
> [...]
> magnum.common.exception.GetClusterSizeFailed: Failed to get the size  
> of cluster from 'https://discovery.etcd.io/<UUID>'.
> ---snip---
>
> The stack trace is a little longer, of course, but this is the  
> relevant part. Can anyone point me in the right direction? What am I  
> missing? I also tried quay.io since discovery.etcd.io seems to be  
> not maintained anymore, but there I can't even generate a new URL.
>
> Any help is greatly appreciated!
>
> Thanks
> Eugen





From mdemaced at redhat.com  Thu Mar 10 10:21:18 2022
From: mdemaced at redhat.com (Maysa De Macedo Souza)
Date: Thu, 10 Mar 2022 11:21:18 +0100
Subject: [kuryr] Zed PTG planning
In-Reply-To: <CAEn0wJX=_WmAGDf1XUzWzjqjW2iRgnJ_tXZi9Z981ueYOx90hg@mail.gmail.com>
References: <CAEn0wJX=_WmAGDf1XUzWzjqjW2iRgnJ_tXZi9Z981ueYOx90hg@mail.gmail.com>
Message-ID: <CAEn0wJXZKmOBjXJKQUwGCfv0Vp3b6fYZ1OwdzSB_xcvEi_CJdg@mail.gmail.com>

Hello,

Thanks to everyone that answered the doodle. I just booked the Kuryr
sessions for April 4 13UTC - 14UTC and April 5 7UTC - 8UTC.

Looking forward to meeting you.

Cheers,
Maysa.

On Mon, Mar 7, 2022 at 12:07 PM Maysa De Macedo Souza <mdemaced at redhat.com>
wrote:

> Hello everyone,
>
> The virtual PTG will happen between 4th-8th April. I've created a
> doodle[1] to try finding a time slot that works for most of us. There is
> also an etherpad[2] to propose topics to be discussed, feel free to fill it
> if you have one.
>
> Thank you.
>
> Kind regards,
> Maysa Macedo.
>
> [1] https://doodle.com/meeting/participate/id/0dN1Movb
> [2] https://etherpad.opendev.org/p/kuryr-zed-ptg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/7410d9de/attachment-0001.htm>

From wchy1001 at gmail.com  Thu Mar 10 10:46:11 2022
From: wchy1001 at gmail.com (W Ch)
Date: Thu, 10 Mar 2022 18:46:11 +0800
Subject: [trove][tc][all] Call for volunteers to be a PTL and maintainers
In-Reply-To: <2095127.irdbgypaU6@p1>
References: <2095127.irdbgypaU6@p1>
Message-ID: <CAA2OaxWcHHnobOQ0BoFodUegXN_3Yweieq94YCLAiYLFHc4BKg@mail.gmail.com>

hi, Is anyone elected  PTL for trove now ? If nobody,  I'd like to maintain
the trove project, since we are using it in our production.



wu.chunyang

Slawek Kaplonski <skaplons at redhat.com> ?2022?3?6??? 01:33???

> Hi,
>
> After last PTL elections [1] Trove project still don't have any PTL
> elected.
> So this is call for maintainers for Trove. If You are using it or
> interested in it, and if You are willing to help maintaining this project,
> please contact TC members through this mailing list or directly on the
> #openstack-tc channel @OFTC. We can talk possibilities to make someone a
> PTL of the project or going with this project to the Distributed Project
> Leadership [2] model.
>
> [1]
> http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027411.html
> [2]
> https://governance.openstack.org/tc/resolutions/20200803-distributed-project-leadership.html
>
> --
> Slawek Kaplonski
> Principal Software Engineer
> Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/770a1a1d/attachment.htm>

From skaplons at redhat.com  Thu Mar 10 11:06:43 2022
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Thu, 10 Mar 2022 12:06:43 +0100
Subject: [trove][tc][all] Call for volunteers to be a PTL and maintainers
In-Reply-To: <CAA2OaxWcHHnobOQ0BoFodUegXN_3Yweieq94YCLAiYLFHc4BKg@mail.gmail.com>
References: <2095127.irdbgypaU6@p1>
 <CAA2OaxWcHHnobOQ0BoFodUegXN_3Yweieq94YCLAiYLFHc4BKg@mail.gmail.com>
Message-ID: <2620315.mvXUDI8C0e@p1>

Hi,

On czwartek, 10 marca 2022 11:46:11 CET W Ch wrote:
> hi, Is anyone elected  PTL for trove now ? If nobody,  I'd like to maintain
> the trove project, since we are using it in our production.

Thx a lot for stepping up and willing to help with Trove. There are no other candidates yet AFAICT so we will discuss Your candidacy and will let You know about it soon.

> 
> 
> 
> wu.chunyang
> 
> Slawek Kaplonski <skaplons at redhat.com> ?2022?3?6??? 01:33???
> 
> > Hi,
> >
> > After last PTL elections [1] Trove project still don't have any PTL
> > elected.
> > So this is call for maintainers for Trove. If You are using it or
> > interested in it, and if You are willing to help maintaining this project,
> > please contact TC members through this mailing list or directly on the
> > #openstack-tc channel @OFTC. We can talk possibilities to make someone a
> > PTL of the project or going with this project to the Distributed Project
> > Leadership [2] model.
> >
> > [1]
> > http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027411.html
> > [2]
> > https://governance.openstack.org/tc/resolutions/20200803-distributed-project-leadership.html
> >
> > --
> > Slawek Kaplonski
> > Principal Software Engineer
> > Red Hat
> 



-- 
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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/e2cd191f/attachment.sig>

From james.slagle at gmail.com  Thu Mar 10 12:49:21 2022
From: james.slagle at gmail.com (James Slagle)
Date: Thu, 10 Mar 2022 07:49:21 -0500
Subject: [TripleO] TripleO Zed PTG topics Etherpad
Message-ID: <CAHV77z849Er-V1agvgL=td1=3PLwZRaeqS77jPEOMYa+w7z4nw@mail.gmail.com>

TripleO,
Please add your proposed topics for the PTG to this etherad:
https://etherpad.opendev.org/p/tripleo-zed-ptg-topics

I will reserve time allocation for TripleO based on the number of proposed
topics. Thanks!

-- 
-- James Slagle
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/5458c07c/attachment.htm>

From geguileo at redhat.com  Thu Mar 10 12:58:23 2022
From: geguileo at redhat.com (Gorka Eguileor)
Date: Thu, 10 Mar 2022 13:58:23 +0100
Subject: [openstack][queens][cinder] volume retype errors
In-Reply-To: <CAB7j8cVdqgQWkfn=y6MG5jeR1tWfbmq=BVv=cPBPw4OUCbuuKA@mail.gmail.com>
References: <CAB7j8cWCrGLoNQwHw_ekM1D0LBkToLhdgwEG4eOuJTLJpTr58g@mail.gmail.com>
 <20220307162303.Horde.VExGf9Y0xDD_Kjz3lCeaSje@webmail.nde.ag>
 <CAB7j8cUwdWYV2RUdkDopOzh9yivGhMta0A+1B2Ydwdr9rmTtzA@mail.gmail.com>
 <CAB7j8cVdqgQWkfn=y6MG5jeR1tWfbmq=BVv=cPBPw4OUCbuuKA@mail.gmail.com>
Message-ID: <20220310125823.vh3pqx4t3o2cm5xl@localhost>

On 07/03, Ignazio Cassano wrote:
> Hello again I found the error but it is in cinder api log:
> 2022-03-07 15:42:57.330 156916 INFO cinder.api.openstack.wsgi
> [req-01eb2613-4aad-4809-ac91-037de3148fbb 5134ed3b93284af5ba2f05d7361edf53
> 0e760ccde5d24af5a571de40220fbf80 - default default]
> http://10.138.144.16:8776/v3/0e760ccde5d24af5a571de40220fbf80/attachments/04ae01f6-e164-40cb-8d31-63f78e69c8db
> returned with HTTP 404
>
> and in nova compute log:
> 15:42:57.502 280431 ERROR oslo_messaging.rpc.server
> [req-dfeac1f0-870b-4aef-af40-cda52f4552e0 5134ed3b93284af5ba2f05d7361edf53
> 0e760ccde5d24af5a571de40220fbf80 - default default] Exception during
> message handling: VolumeAttachmentNotFound: Volume attachment
> 04ae01f6-e164-40cb-8d31-63f78e69c8db could not be found.
>

Hi,

Retyping with migration of attached volumes is a complex flow, so doing
the RCA usually requires full logs of ALL involved services:

- All nova-api, cinder-api, cinder-scheduler services
- nova-cpu of the host with the instance
- Cinder-volume service

For example in the logs you gave above we don't even know if it was a
GET or PUT operation and what was nova trying to do, and we also don't
have context, so we cannot tell at which stage of the whole process this
happened.

If I remember correctly the high level steps are something like:

- Cinder-volume receives request
- Creates new volume
- Calls nova to do the volume swap
- Nova attaches new volume with os-brick
- Nova asks the hypervisor to do the swap
- Nova disconnects the original volume
- Nova calls cinder telling it that the swap is completed
- Cinder detaches the original volume and makes DB changes

Since you are running a 4 years old code it's not easy to see the code
differences to see if there was a bug that has been fixed in a later
release.

Sorry for not being able to provide actual help.  :-(

Cheers,
Gorka.


> Il giorno lun 7 mar 2022 alle ore 17:44 Ignazio Cassano <
> ignaziocassano at gmail.com> ha scritto:
>
> > Hello, volume.log does not report errors:
> > 2022-03-07 15:41:44.435 159559 INFO cinder.volume.manager
> > [req-68444973-24eb-4b21-95b2-626c9b2e2aa0 5134ed3b93284af5ba2f05d7361edf53
> > 0e760ccde5d24af5a571de40220fbf80 - default default] Created volume
> > successfully.
> > 2022-03-07 15:41:45.358 159099 INFO cinder.volume.manager
> > [req-68444973-24eb-4b21-95b2-626c9b2e2aa0 5134ed3b93284af5ba2f05d7361edf53
> > 0e760ccde5d24af5a571de40220fbf80 - default default] Migrate volume
> > completed successfully.
> > 2022-03-07 15:41:48.970 159559 INFO cinder.volume.manager
> > [req-72ca9242-25e9-4bb0-9bd6-9857f42805ee 5134ed3b93284af5ba2f05d7361edf53
> > 0e760ccde5d24af5a571de40220fbf80 - default default] attachment_update
> > complete
> >
> > Il giorno lun 7 mar 2022 alle ore 17:25 Eugen Block <eblock at nde.ag> ha
> > scritto:
> >
> >> Hi,
> >>
> >> since you're retyping a volume, what do the cinder logs reveal?
> >>
> >>
> >> Zitat von Ignazio Cassano <ignaziocassano at gmail.com>:
> >>
> >> > Hello, sometimes the volume retype from a netapp nfs storage to another
> >> > netapp nfs storage does not work.
> >> > I do not know the reason but I think something is going wrong in nova:
> >> >
> >> > /var/log/nova/nova-compute.log:2022-02-02 14:23:39.992 194288 ERROR root
> >> > [req-ebbf749f-359f-4282-94c5-0913cffe97a3
> >> 66adb965bef64eaaab2af93ade87e2ca
> >> > 68feefdf7c5847388534e9214dc13366 - default default] Original exception
> >> > being dropped: ['Traceback (most recent call last):\n', '  File
> >> > "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 5655,
> >> in
> >> > _swap_volume\n    mountpoint, resize_to)\n', '  File
> >> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> >> 1647,
> >> > in swap_volume\n    self._disconnect_volume(context,
> >> new_connection_info,
> >> > instance)\n', '  File
> >> > "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in
> >> > __exit__\n    self.force_reraise()\n', '  File
> >> > "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in
> >> > force_reraise\n    six.reraise(self.type_, self.value, self.tb)\n', '
> >> File
> >> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> >> 1644,
> >> > in swap_volume\n    self._swap_volume(guest, disk_dev, conf,
> >> resize_to)\n',
> >> > '  File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
> >> > line 1593, in _swap_volume\n    raise
> >> > exception.VolumeRebaseFailed(reason=six.text_type(exc))\n',
> >> > "VolumeRebaseFailed: Volume rebase failed: Requested operation is not
> >> > valid: pivot of disk 'vda' requires an active copy job\n"]:
> >> > VolumeAttachmentNotFound: Volume attachment
> >> > 2cd820e0-85e8-498d-a62a-800260d0cf31 could not be found
> >> >
> >> >
> >> > Must I try to change some parameters in nova.conf on compute nodes about
> >> > volume attachment ?
> >> >
> >> > Thanks
> >> > Ignazio
> >>
> >>
> >>
> >>
> >>



From ignaziocassano at gmail.com  Thu Mar 10 13:39:18 2022
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Thu, 10 Mar 2022 14:39:18 +0100
Subject: [openstack][queens][cinder] volume retype errors
In-Reply-To: <20220310125823.vh3pqx4t3o2cm5xl@localhost>
References: <CAB7j8cWCrGLoNQwHw_ekM1D0LBkToLhdgwEG4eOuJTLJpTr58g@mail.gmail.com>
 <20220307162303.Horde.VExGf9Y0xDD_Kjz3lCeaSje@webmail.nde.ag>
 <CAB7j8cUwdWYV2RUdkDopOzh9yivGhMta0A+1B2Ydwdr9rmTtzA@mail.gmail.com>
 <CAB7j8cVdqgQWkfn=y6MG5jeR1tWfbmq=BVv=cPBPw4OUCbuuKA@mail.gmail.com>
 <20220310125823.vh3pqx4t3o2cm5xl@localhost>
Message-ID: <CAB7j8cXN_20NiXqoyAvr1Uragi9_8tjG7+f_CEC3vA+4zDz70A@mail.gmail.com>

Do not worry, I know queens is very old.
I am going to move volumes with another procedure.
Ignazio

Il giorno gio 10 mar 2022 alle ore 13:58 Gorka Eguileor <geguileo at redhat.com>
ha scritto:

> On 07/03, Ignazio Cassano wrote:
> > Hello again I found the error but it is in cinder api log:
> > 2022-03-07 15:42:57.330 156916 INFO cinder.api.openstack.wsgi
> > [req-01eb2613-4aad-4809-ac91-037de3148fbb
> 5134ed3b93284af5ba2f05d7361edf53
> > 0e760ccde5d24af5a571de40220fbf80 - default default]
> >
> http://10.138.144.16:8776/v3/0e760ccde5d24af5a571de40220fbf80/attachments/04ae01f6-e164-40cb-8d31-63f78e69c8db
> > returned with HTTP 404
> >
> > and in nova compute log:
> > 15:42:57.502 280431 ERROR oslo_messaging.rpc.server
> > [req-dfeac1f0-870b-4aef-af40-cda52f4552e0
> 5134ed3b93284af5ba2f05d7361edf53
> > 0e760ccde5d24af5a571de40220fbf80 - default default] Exception during
> > message handling: VolumeAttachmentNotFound: Volume attachment
> > 04ae01f6-e164-40cb-8d31-63f78e69c8db could not be found.
> >
>
> Hi,
>
> Retyping with migration of attached volumes is a complex flow, so doing
> the RCA usually requires full logs of ALL involved services:
>
> - All nova-api, cinder-api, cinder-scheduler services
> - nova-cpu of the host with the instance
> - Cinder-volume service
>
> For example in the logs you gave above we don't even know if it was a
> GET or PUT operation and what was nova trying to do, and we also don't
> have context, so we cannot tell at which stage of the whole process this
> happened.
>
> If I remember correctly the high level steps are something like:
>
> - Cinder-volume receives request
> - Creates new volume
> - Calls nova to do the volume swap
> - Nova attaches new volume with os-brick
> - Nova asks the hypervisor to do the swap
> - Nova disconnects the original volume
> - Nova calls cinder telling it that the swap is completed
> - Cinder detaches the original volume and makes DB changes
>
> Since you are running a 4 years old code it's not easy to see the code
> differences to see if there was a bug that has been fixed in a later
> release.
>
> Sorry for not being able to provide actual help.  :-(
>
> Cheers,
> Gorka.
>
>
> > Il giorno lun 7 mar 2022 alle ore 17:44 Ignazio Cassano <
> > ignaziocassano at gmail.com> ha scritto:
> >
> > > Hello, volume.log does not report errors:
> > > 2022-03-07 15:41:44.435 159559 INFO cinder.volume.manager
> > > [req-68444973-24eb-4b21-95b2-626c9b2e2aa0
> 5134ed3b93284af5ba2f05d7361edf53
> > > 0e760ccde5d24af5a571de40220fbf80 - default default] Created volume
> > > successfully.
> > > 2022-03-07 15:41:45.358 159099 INFO cinder.volume.manager
> > > [req-68444973-24eb-4b21-95b2-626c9b2e2aa0
> 5134ed3b93284af5ba2f05d7361edf53
> > > 0e760ccde5d24af5a571de40220fbf80 - default default] Migrate volume
> > > completed successfully.
> > > 2022-03-07 15:41:48.970 159559 INFO cinder.volume.manager
> > > [req-72ca9242-25e9-4bb0-9bd6-9857f42805ee
> 5134ed3b93284af5ba2f05d7361edf53
> > > 0e760ccde5d24af5a571de40220fbf80 - default default] attachment_update
> > > complete
> > >
> > > Il giorno lun 7 mar 2022 alle ore 17:25 Eugen Block <eblock at nde.ag> ha
> > > scritto:
> > >
> > >> Hi,
> > >>
> > >> since you're retyping a volume, what do the cinder logs reveal?
> > >>
> > >>
> > >> Zitat von Ignazio Cassano <ignaziocassano at gmail.com>:
> > >>
> > >> > Hello, sometimes the volume retype from a netapp nfs storage to
> another
> > >> > netapp nfs storage does not work.
> > >> > I do not know the reason but I think something is going wrong in
> nova:
> > >> >
> > >> > /var/log/nova/nova-compute.log:2022-02-02 14:23:39.992 194288 ERROR
> root
> > >> > [req-ebbf749f-359f-4282-94c5-0913cffe97a3
> > >> 66adb965bef64eaaab2af93ade87e2ca
> > >> > 68feefdf7c5847388534e9214dc13366 - default default] Original
> exception
> > >> > being dropped: ['Traceback (most recent call last):\n', '  File
> > >> > "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line
> 5655,
> > >> in
> > >> > _swap_volume\n    mountpoint, resize_to)\n', '  File
> > >> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> > >> 1647,
> > >> > in swap_volume\n    self._disconnect_volume(context,
> > >> new_connection_info,
> > >> > instance)\n', '  File
> > >> > "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line
> 220, in
> > >> > __exit__\n    self.force_reraise()\n', '  File
> > >> > "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line
> 196, in
> > >> > force_reraise\n    six.reraise(self.type_, self.value, self.tb)\n',
> '
> > >> File
> > >> > "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line
> > >> 1644,
> > >> > in swap_volume\n    self._swap_volume(guest, disk_dev, conf,
> > >> resize_to)\n',
> > >> > '  File
> "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py",
> > >> > line 1593, in _swap_volume\n    raise
> > >> > exception.VolumeRebaseFailed(reason=six.text_type(exc))\n',
> > >> > "VolumeRebaseFailed: Volume rebase failed: Requested operation is
> not
> > >> > valid: pivot of disk 'vda' requires an active copy job\n"]:
> > >> > VolumeAttachmentNotFound: Volume attachment
> > >> > 2cd820e0-85e8-498d-a62a-800260d0cf31 could not be found
> > >> >
> > >> >
> > >> > Must I try to change some parameters in nova.conf on compute nodes
> about
> > >> > volume attachment ?
> > >> >
> > >> > Thanks
> > >> > Ignazio
> > >>
> > >>
> > >>
> > >>
> > >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/7b476b2d/attachment-0001.htm>

From dpawlik at redhat.com  Thu Mar 10 13:48:49 2022
From: dpawlik at redhat.com (Daniel Pawlik)
Date: Thu, 10 Mar 2022 14:48:49 +0100
Subject: Opensearch service reinstallation - opensearch.logs.openstack.org
Message-ID: <CAEZjfK7zBeO1pMywEfe7GPoVkCPQ9x3HFApr=4reahZazLgLtg@mail.gmail.com>

Hi,

We plan to reinstall the Opensearch (opensearch.logs.openstack.org) service
on
Saturday, 2021-03-12.
The service will be unavailable for several hours.

If someone has any concerns, please contact me.

Regards,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/d93cd3da/attachment.htm>

From rosmaita.fossdev at gmail.com  Thu Mar 10 14:04:51 2022
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Thu, 10 Mar 2022 09:04:51 -0500
Subject: [ops][cinder] reminder: resource count survey - win fabulous prizes!
Message-ID: <552b3672-2907-bc01-a38c-10d66f47b184@gmail.com>

Hello operators,

Don't miss out on this chance to take the Cinder Resource Count Survey! 
Act now before the survey closes on Wednesday 30 March!
   https://rosmaita.wufoo.com/forms/cinder-resource-count-survey/

Details below:

The Cinder project is working on the cinder quotas system in an effort 
to improve its accuracy and remove the necessity for operators to go 
through and clean it up occasionally when it gets out of sync with reality.

One way to do this is to use dynamic database counting (instead of 
storing the usage info in a table where it can become outdated). Whether 
this will be a good change depends on how many records the database has 
to process during a transaction, which in turn depends on how many 
Cinder resources a project has.

So we need to get some information from you.

Please take this brief survey:
https://rosmaita.wufoo.com/forms/cinder-resource-count-survey/

The survey closes on Wednesday 30 March at 1200 UTC, so that we can have 
data to discuss during the Zed PTG.  But please don't procrastinate, 
it's only 6 questions and the answers are all positive integers. It 
shouldn't take long to fill out!


Thanks!
brian


From dms at danplanet.com  Thu Mar 10 14:50:26 2022
From: dms at danplanet.com (Dan Smith)
Date: Thu, 10 Mar 2022 06:50:26 -0800
Subject: [TC][PTL][ops][all] Release cadence, deprecation, and testing
In-Reply-To: <CAFHSqWrkkW0XF_G0L8Av4h-V7mu=Wv2BwKLBz3QhspbOtQrmkg@mail.gmail.com>
 (Mark Goddard's message of "Thu, 10 Mar 2022 09:01:44 +0000")
References: <m2r17asqrk.fsf@caffeine.hv.danplanet.com>
 <CAFHSqWrkkW0XF_G0L8Av4h-V7mu=Wv2BwKLBz3QhspbOtQrmkg@mail.gmail.com>
Message-ID: <m2mthxsvyl.fsf@caffeine.hv.danplanet.com>

> "This scheme does not necessarily dictate that live or rolling
> upgrades need to be supported between tick releases. Meaning RPC
> compatibility between N to N-1 guarantees can remain, resulting in
> deployments that are on a tick-tick release schedule requiring some
> downtime during an upgrade because components will be spanning more
> than two actual releases."
>
> From the perspective of deployment tools, this would mean needing to
> support two different upgrade strategies. Given the constraints around
> DB migrations, would it be too much effort for projects to also
> support N-2 to N RPC compatibility?

I can tell you it's much harder to do it for RPC than DB migrations. I
personally think it's too much to ask projects to move to that right
away, even though some may be able to do it now. It also has farther
reaches than you might expect, such as dependent components that change
over time (think OVS/OVN, libvirt, qemu).

It may just be the early morning and lack of caffeination, but I'm not
sure what the deployment concern is exactly. You rely entirely on live
rolling upgrades today? Presumably only for some of the services?

--Dan


From dtantsur at redhat.com  Thu Mar 10 15:16:11 2022
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Thu, 10 Mar 2022 16:16:11 +0100
Subject: [TC][PTL][ops][all] Release cadence, deprecation, and testing
In-Reply-To: <m2r17asqrk.fsf@caffeine.hv.danplanet.com>
References: <m2r17asqrk.fsf@caffeine.hv.danplanet.com>
Message-ID: <CACNgkFz+q4z9ttjBsgoci0=LyB9ikbLC3o0=E7PfyHGuV4MaYw@mail.gmail.com>

On Wed, Mar 9, 2022 at 11:36 PM Dan Smith <dms at danplanet.com> wrote:

> Hi all,
>
> As you probably already know from gmann's reporting, the TC recently
> passed a resolution[1] regarding the release cadence. This, in response
> to some discussion around moving to different release cycle lengths,
> becomes mostly a change regarding our deprecation procedures, as well as
> a call to support the ability to skip certain releases (designated
> "tock" releases) while sticking on a yearly cycle (designated "tick"
> releases).
>
> In support of the goal of moving to this new cadence for the AA release
> (i.e. the yet unnamed release to come after Zed), I have introduced[2] a
> new grenade-skip-level job, which tests skipping "tock" releases and
> going straight from one tick to the following. We intend this to be a
> voting job in AA, making sure it works from Yoga->AA. Right now it tests
> Wallaby->Yoga for informational purposes. We would recommend projects
> enable that as voting, or define their own job to do similar testing as
> soon as possible. Manila has already started[3] this. Note that existing
> grenade testing between each adjacent release remains unchanged in this
> scheme.
>

I don't think we have cycles in Ironic to do that. Unless somebody who
really cares wants to not just do the work on setting up such jobs, but
also maintaining them long-term.


>
> On the topic of deprecation, we moved the current definition of
> deprecation procedures from the soon-to-be-removed tag definition to a
> new document in project-team-guide[4]. This now describes the procedures
> in terms of the tick-tock release arrangement, and is worth a read.
>

Same. I don't want to keep deprecated features for a year.

Dmitry


>
> As the PTG is coming up, we will certainly discuss this topic in the PTL
> Interaction[5] session. It would also be advisable to discuss the
> project-specific details of this in the various project sessions. By
> identifying this plan early and setting our goals for AA, we have a good
> amount of time between now and then to get our heads wrapped around what
> (if any) things we need to be doing. Luckily, the introduction of the
> job to test this from wallaby to yoga required almost no project changes
> to get working, which is a good indicator that it won't be too laborious
> for most projects to adopt.
>
> --Dan
>
> 1:
> https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html
> 2: https://review.opendev.org/c/openstack/grenade/+/826101
> 3: https://review.opendev.org/c/openstack/manila/+/830277
> 4: https://docs.openstack.org/project-team-guide/deprecation.html
> 5: https://etherpad.opendev.org/p/tc-ptl-interaction-zed
>
>

-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
O'Neill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/11ff5397/attachment.htm>

From mark at stackhpc.com  Thu Mar 10 15:18:34 2022
From: mark at stackhpc.com (Mark Goddard)
Date: Thu, 10 Mar 2022 15:18:34 +0000
Subject: [TC][PTL][ops][all] Release cadence, deprecation, and testing
In-Reply-To: <m2mthxsvyl.fsf@caffeine.hv.danplanet.com>
References: <m2r17asqrk.fsf@caffeine.hv.danplanet.com>
 <CAFHSqWrkkW0XF_G0L8Av4h-V7mu=Wv2BwKLBz3QhspbOtQrmkg@mail.gmail.com>
 <m2mthxsvyl.fsf@caffeine.hv.danplanet.com>
Message-ID: <CAFHSqWqi0+xYLJsRXh+SMcOEyJqwBrCq2e-RMNfhGXugHjgcLw@mail.gmail.com>

On Thu, 10 Mar 2022 at 14:50, Dan Smith <dms at danplanet.com> wrote:
>
> > "This scheme does not necessarily dictate that live or rolling
> > upgrades need to be supported between tick releases. Meaning RPC
> > compatibility between N to N-1 guarantees can remain, resulting in
> > deployments that are on a tick-tick release schedule requiring some
> > downtime during an upgrade because components will be spanning more
> > than two actual releases."
> >
> > From the perspective of deployment tools, this would mean needing to
> > support two different upgrade strategies. Given the constraints around
> > DB migrations, would it be too much effort for projects to also
> > support N-2 to N RPC compatibility?
>
> I can tell you it's much harder to do it for RPC than DB migrations. I
> personally think it's too much to ask projects to move to that right
> away, even though some may be able to do it now. It also has farther
> reaches than you might expect, such as dependent components that change
> over time (think OVS/OVN, libvirt, qemu).
>
> It may just be the early morning and lack of caffeination, but I'm not
> sure what the deployment concern is exactly. You rely entirely on live
> rolling upgrades today? Presumably only for some of the services?

Kolla Ansible uses rolling upgrades for most services. It doesn't
support full stop upgrades. I expect it wouldn't be too difficult to
implement, but it would be a shame to have two different upgrade
paths.

>
> --Dan


From tobias.urdin at binero.com  Thu Mar 10 15:18:49 2022
From: tobias.urdin at binero.com (Tobias Urdin)
Date: Thu, 10 Mar 2022 15:18:49 +0000
Subject: =?utf-8?B?W29zbG9dwqBbdG9vel0gRGVwcmVjYXRpbmcgZXRjZDMgZHJpdmVy?=
Message-ID: <EB8DB8E7-F52D-4B5F-8C74-81A40CCA56FA@binero.com>

Hello,

I?m proposing that we deprecate the etcd3 driver
https://review.opendev.org/c/openstack/tooz/+/833107

I will include the commit message below that describes the situation with the
dependency the driver has on the python-etcd3 library.

Please let me know what you think about this action, we
would also like to know if you are using the driver.

Best regards
Tobias

???

Author: Tobias Urdin <tobias.urdin at binero.se<mailto:tobias.urdin at binero.se>>
Date:   Thu Mar 10 15:09:58 2022 +0000

    Deprecate the etcd3 driver

    The etcd3 driver depends on the python-etcd3 [1]
    library that is currently stale and no has no
    active maintenance [2] with a non-working CI
    that blocks all PRs.

    It's also currently blocking Tooz from supporting
    newer versions of tenacity [3] that a lot of
    projects is now pinning because newer version of
    tenacity dropped old legacy compatibility code
    that has been in there for years.

    We currently have etcd3gw as an alternative driver
    where the library the driver depends on is a
    deliverable that we maintain.

    [1] https://github.com/kragniz/python-etcd3
    [2] https://github.com/kragniz/python-etcd3/issues/1719
    [3] https://review.opendev.org/c/openstack/tooz/+/829412

    Change-Id: Iff0cd3b51cfc45ecbddc831c55267e80e9c79cac
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/8e5eabf3/attachment.htm>

From tobias.urdin at binero.com  Thu Mar 10 15:21:22 2022
From: tobias.urdin at binero.com (Tobias Urdin)
Date: Thu, 10 Mar 2022 15:21:22 +0000
Subject: [puppet] Proposing Alan Bishop (abishop) for puppet-manila core
In-Reply-To: <CAL_crJQtgtBGG3KGjbqR7CuQH987B_9NqvJ9q63kTY5+t4LTzg@mail.gmail.com>
References: <CAL_crJQtgtBGG3KGjbqR7CuQH987B_9NqvJ9q63kTY5+t4LTzg@mail.gmail.com>
Message-ID: <FF31E9C6-F917-4E4E-B164-A1CFDC98966F@binero.com>

+1 - Alan is doing great work!

On 9 Mar 2022, at 16:11, Takashi Kajinami <tkajinam at redhat.com<mailto:tkajinam at redhat.com>> wrote:

Hi Team,


Alan is currently a partial core reviewer in Puppet OpenStack and covers
puppet-cinder and puppet-glance.

He has made great reviews in these two modules since he joined the team, but
in addition,  he has been reviewing patches for puppet-manila and providing
good feedback for the past two cycle.
 https://www.stackalytics.io/?user_id=alan-bishop

Based on that fact, I'd like to propose extending his coverage and adding Alan
to the puppet-manila core reviewers.

If you have any feedback please share it in this thread. I'll add him to the group
if we don't hear any objections for 1 week.

I'd like to take this moment to thank Alan for his great work and help in this project !

Thank you,
Takashi KAJINAMI


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/c4c6b6c9/attachment.htm>

From dms at danplanet.com  Thu Mar 10 15:51:29 2022
From: dms at danplanet.com (Dan Smith)
Date: Thu, 10 Mar 2022 07:51:29 -0800
Subject: [TC][PTL][ops][all] Release cadence, deprecation, and testing
In-Reply-To: <CAFHSqWqi0+xYLJsRXh+SMcOEyJqwBrCq2e-RMNfhGXugHjgcLw@mail.gmail.com>
 (Mark Goddard's message of "Thu, 10 Mar 2022 15:18:34 +0000")
References: <m2r17asqrk.fsf@caffeine.hv.danplanet.com>
 <CAFHSqWrkkW0XF_G0L8Av4h-V7mu=Wv2BwKLBz3QhspbOtQrmkg@mail.gmail.com>
 <m2mthxsvyl.fsf@caffeine.hv.danplanet.com>
 <CAFHSqWqi0+xYLJsRXh+SMcOEyJqwBrCq2e-RMNfhGXugHjgcLw@mail.gmail.com>
Message-ID: <m2ilslst4u.fsf@caffeine.hv.danplanet.com>

> Kolla Ansible uses rolling upgrades for most services. It doesn't
> support full stop upgrades. I expect it wouldn't be too difficult to
> implement, but it would be a shame to have two different upgrade
> paths.

Okay, well, our method for testing RPC compatibility is grenade
multinode, so we'd need a multinode job that does the skip level
piece. I could try poking at that to see, but again, I think it's asking
a lot from the projects to make that leap right away. If I'm wrong about
that, then we could surely explore that route.

--Dan


From tobias.urdin at binero.com  Thu Mar 10 16:03:47 2022
From: tobias.urdin at binero.com (Tobias Urdin)
Date: Thu, 10 Mar 2022 16:03:47 +0000
Subject: [nova] VM ending up in a different availability zone after
 resizing vm instance
In-Reply-To: <CAJ1=nZeBcd42+TXA_FZAH6AaHQE3BPb1J2uM5UWe-A7N9eRrmQ@mail.gmail.com>
References: <CAJ1=nZdKoRjNd8OPiqSogYsg87EXSZCHY_pdS3gkMv4EG7JCgw@mail.gmail.com>
 <e951c66b75ebc387a7e78b8ff80b97319ed49888.camel@redhat.com>
 <CAJ1=nZeBcd42+TXA_FZAH6AaHQE3BPb1J2uM5UWe-A7N9eRrmQ@mail.gmail.com>
Message-ID: <3DD5D38D-1A91-4F81-A7BD-8E1AB61FB942@binero.com>

Hello,

Didn?t you ask this recenty in thread [1] ?
You have the answer there, it?s based on the request spec saved in the request_specs table in the database.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024007.html

> On 10 Mar 2022, at 01:57, hai wu <haiwu.us at gmail.com> wrote:
> 
> Is it possible to add AZ information to existing VMs (not during VM
> creation)? We did not configure AZ initially, so by default they are
> with 'nova' default zone. AZ was added on a later stage.. I don't
> think we have different AZ configured on different schedulers. we have
> to toggle host's AZ all the time in order to be able to migrate VMs
> around..
> 
> On Wed, Mar 9, 2022 at 5:11 PM Sean Mooney <smooney at redhat.com> wrote:
>> 
>> On Wed, 2022-03-09 at 14:40 -0600, hai wu wrote:
>>> VM ends up in a different availability zone after resizing the vm
>>> instance. The default openstack nova behavior should have prevented
>>> this from happening, correct? What could have caused this?
>> if the vm was created without a AZ requested tehn when it is resized i think it can change AZ
>> but that woudl only happen if you chagne the defautl AZ or have different AZ configured on different schedulers i think.
>> 
>>> 
>> 
> 


From abishop at redhat.com  Thu Mar 10 16:14:37 2022
From: abishop at redhat.com (Alan Bishop)
Date: Thu, 10 Mar 2022 08:14:37 -0800
Subject: [oslo] [tooz] Deprecating etcd3 driver
In-Reply-To: <EB8DB8E7-F52D-4B5F-8C74-81A40CCA56FA@binero.com>
References: <EB8DB8E7-F52D-4B5F-8C74-81A40CCA56FA@binero.com>
Message-ID: <CADO3vb5BYMv3--SgvppjnniOxOHEBO-4X67jp0qUDazXAmBzDQ@mail.gmail.com>

On Thu, Mar 10, 2022 at 7:20 AM Tobias Urdin <tobias.urdin at binero.com>
wrote:

> Hello,
>
> I?m proposing that we deprecate the etcd3 driver
> https://review.opendev.org/c/openstack/tooz/+/833107
>

Just to clarify, and for the benefit of other readers, tooz still supports
the etcd3gw
driver. Moreover, the etcd3gw driver does not depend on the etcd3 driver,
and so
there should be no impact on projects using the etcd3gw driver.

Alan


> I will include the commit message below that describes the situation with
> the
> dependency the driver has on the python-etcd3 library.
>
> Please let me know what you think about this action, we
> would also like to know if you are using the driver.
>
> Best regards
> Tobias
>
> ???
>
> Author: Tobias Urdin <tobias.urdin at binero.se>
> Date:   Thu Mar 10 15:09:58 2022 +0000
>
>     Deprecate the etcd3 driver
>
>     The etcd3 driver depends on the python-etcd3 [1]
>     library that is currently stale and no has no
>     active maintenance [2] with a non-working CI
>     that blocks all PRs.
>
>     It's also currently blocking Tooz from supporting
>     newer versions of tenacity [3] that a lot of
>     projects is now pinning because newer version of
>     tenacity dropped old legacy compatibility code
>     that has been in there for years.
>
>     We currently have etcd3gw as an alternative driver
>     where the library the driver depends on is a
>     deliverable that we maintain.
>
>     [1] https://github.com/kragniz/python-etcd3
>     [2] https://github.com/kragniz/python-etcd3/issues/1719
>     [3] https://review.opendev.org/c/openstack/tooz/+/829412
>
>     Change-Id: Iff0cd3b51cfc45ecbddc831c55267e80e9c79cac
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/8ab76939/attachment-0001.htm>

From haiwu.us at gmail.com  Thu Mar 10 16:32:05 2022
From: haiwu.us at gmail.com (hai wu)
Date: Thu, 10 Mar 2022 10:32:05 -0600
Subject: [nova] VM ending up in a different availability zone after
 resizing vm instance
In-Reply-To: <3DD5D38D-1A91-4F81-A7BD-8E1AB61FB942@binero.com>
References: <CAJ1=nZdKoRjNd8OPiqSogYsg87EXSZCHY_pdS3gkMv4EG7JCgw@mail.gmail.com>
 <e951c66b75ebc387a7e78b8ff80b97319ed49888.camel@redhat.com>
 <CAJ1=nZeBcd42+TXA_FZAH6AaHQE3BPb1J2uM5UWe-A7N9eRrmQ@mail.gmail.com>
 <3DD5D38D-1A91-4F81-A7BD-8E1AB61FB942@binero.com>
Message-ID: <CAJ1=nZeq4AcedoTsugPzP_qHOeNuy8JL5iVP-Z6XWmPXbOOupA@mail.gmail.com>

Does this mean that with request_specs populated with AZ information
for each existing VM, this particular issue would never happen again
later?

Also I never figured out how to use oslo_versionedobjects to update
request_specs table for each existing VM. Do you have any sample code
to do that?

On Thu, Mar 10, 2022 at 10:12 AM Tobias Urdin <tobias.urdin at binero.com> wrote:
>
> Hello,
>
> Didn?t you ask this recenty in thread [1] ?
> You have the answer there, it?s based on the request spec saved in the request_specs table in the database.
>
> [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024007.html
>
> > On 10 Mar 2022, at 01:57, hai wu <haiwu.us at gmail.com> wrote:
> >
> > Is it possible to add AZ information to existing VMs (not during VM
> > creation)? We did not configure AZ initially, so by default they are
> > with 'nova' default zone. AZ was added on a later stage.. I don't
> > think we have different AZ configured on different schedulers. we have
> > to toggle host's AZ all the time in order to be able to migrate VMs
> > around..
> >
> > On Wed, Mar 9, 2022 at 5:11 PM Sean Mooney <smooney at redhat.com> wrote:
> >>
> >> On Wed, 2022-03-09 at 14:40 -0600, hai wu wrote:
> >>> VM ends up in a different availability zone after resizing the vm
> >>> instance. The default openstack nova behavior should have prevented
> >>> this from happening, correct? What could have caused this?
> >> if the vm was created without a AZ requested tehn when it is resized i think it can change AZ
> >> but that woudl only happen if you chagne the defautl AZ or have different AZ configured on different schedulers i think.
> >>
> >>>
> >>
> >
>


From skaplons at redhat.com  Thu Mar 10 19:58:51 2022
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Thu, 10 Mar 2022 20:58:51 +0100
Subject: [trove][tc][all] Call for volunteers to be a PTL and maintainers
In-Reply-To: <CAA2OaxXqJ9QRPAwEhjcoWtEvU_=Bzbu3QC71mXNp7JJsTRxi0Q@mail.gmail.com>
References: <2095127.irdbgypaU6@p1> <2620315.mvXUDI8C0e@p1>
 <CAA2OaxXqJ9QRPAwEhjcoWtEvU_=Bzbu3QC71mXNp7JJsTRxi0Q@mail.gmail.com>
Message-ID: <5801108.lOV4Wx5bFT@p1>

Hi,

Once again thx for stepping up for this role in Trove. Patch for that is already proposed https://review.opendev.org/c/openstack/governance/+/833152[1] - we need now Your +1 on this patch to be able to approve it and to make You officially PTL of Trove.

On czwartek, 10 marca 2022 12:27:43 CET W Ch wrote:
> thanks
> 
> Slawek Kaplonski <skaplons at redhat.com> ?2022?3?10??? 19:06???
> 
> > Hi,
> >
> > On czwartek, 10 marca 2022 11:46:11 CET W Ch wrote:
> > > hi, Is anyone elected  PTL for trove now ? If nobody,  I'd like to
> > maintain
> > > the trove project, since we are using it in our production.
> >
> > Thx a lot for stepping up and willing to help with Trove. There are no
> > other candidates yet AFAICT so we will discuss Your candidacy and will let
> > You know about it soon.
> >
> > >
> > >
> > >
> > > wu.chunyang
> > >
> > > Slawek Kaplonski <skaplons at redhat.com> ?2022?3?6??? 01:33???
> > >
> > > > Hi,
> > > >
> > > > After last PTL elections [1] Trove project still don't have any PTL
> > > > elected.
> > > > So this is call for maintainers for Trove. If You are using it or
> > > > interested in it, and if You are willing to help maintaining this
> > project,
> > > > please contact TC members through this mailing list or directly on the
> > > > #openstack-tc channel @OFTC. We can talk possibilities to make someone
> > a
> > > > PTL of the project or going with this project to the Distributed
> > Project
> > > > Leadership [2] model.
> > > >
> > > > [1]
> > > >
> > http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027411.html
> > > > [2]
> > > >
> > https://governance.openstack.org/tc/resolutions/20200803-distributed-project-leadership.html
> > > >
> > > > --
> > > > Slawek Kaplonski
> > > > Principal Software Engineer
> > > > Red Hat
> > >
> >
> >
> >
> > --
> > Slawek Kaplonski
> > Principal Software Engineer
> > Red Hat
> 



-- 
Slawek Kaplonski
Principal Software Engineer
Red Hat

--------
[1] https://review.opendev.org/c/openstack/governance/+/833152
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/38f6f589/attachment.htm>
-------------- 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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/38f6f589/attachment.sig>

From katonalala at gmail.com  Thu Mar 10 20:43:55 2022
From: katonalala at gmail.com (Lajos Katona)
Date: Thu, 10 Mar 2022 21:43:55 +0100
Subject: [neutron] Drivers meeting - Friday 11.3.2022 - cancelled
Message-ID: <CALg0jKmkZDPN_Ev7Y9zumCFMyDK8GLvNuvHnUSaBq=LmW+ke5g@mail.gmail.com>

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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220310/ac347933/attachment.htm>

From johnsomor at gmail.com  Thu Mar 10 21:25:21 2022
From: johnsomor at gmail.com (Michael Johnson)
Date: Thu, 10 Mar 2022 13:25:21 -0800
Subject: [designate] Architecture help for designate on
 multi-region/multi-AZ deployments
In-Reply-To: <5c6de844-c996-4140-95a9-380f48a5d3b2@www.fastmail.com>
References: <5c6de844-c996-4140-95a9-380f48a5d3b2@www.fastmail.com>
Message-ID: <CAMH0MgKjYipHRid2x1Podi2G-icRnPHsdgpwjtKmLZy27qOCHg@mail.gmail.com>

Hey JP,

I was hanging out waiting to see if others had feedback for you. I
have not done a multi-region deployment, so I can't talk much to the
Keystone/Identity issues with a multi-region setup, but I can give you
some thoughts on DNS/Designate.

>From a DNS perspective, the zones are hierarchical in nature. This
means if you need resources in each region to share a zone,
example.com. for example, the zones will need to be managed via a
centralized control plane.  However, if you can clearly separate the
zones by region, deploying Designate in each region would provide
complete separation.

High availability is not really an issue as it's easy to setup
Designate pools to update multiple DNS server instances and you always
have the option of multiple secondary DNS servers distributed to the
regions. It's really a question of control plane (API) availability
should a region fail.

Personally, if it was my deployment, I would probably go down the path
of a Designate deployment for each region. This would mean that any
one DNS zone could not (automatically) be managed from multiple
regions, but aligns to my understanding of the spirit of a "region" in
OpenStack.

For non-bring-your-own-domain scenarios, this can be easily managed in
the DNS hierarchy by creating regional parent zones. I.e.
west.example.com., east.example.com., moon.example.com., etc. Since
it's also likely that routable IP address space will be unique per
region, the reverse zones would naturally be unique.

In the case of bring-your-own-domain, you would need a policy that any
one domain can only exist in one region. However, there would be
nothing stopping users from doing a similar regional breakdown of
sub-domains if they would like.

As for the synchronization question, I think that is more of an issue
that a customer would need to address if they feel they want a
multiple primary scenario. Technically there would be no reason they
could not create the zone in multiple regions, keep it in sync
themselves, and add the DNS servers for both regions as authoritative
for the zone.

If you want to provide a "premium" service where DNS HA is provided
across regions, this can be done using the Designate pools
configuration or via the normal secondary DNS server model configured
in your DNS servers. This would maintain DNS resolution should a
region go down, but if the zone was created in a specific region that
is unavailable, you would be unable to update it until the region is
restored.

Just some thoughts, please feel free to reach out if you want to chat
about it more or bounce ideas around,

Michael

On Wed, Mar 9, 2022 at 12:34 AM Jean-Philippe Evrard
<openstack at a.spamming.party> wrote:
>
> Hello folks,
>
> I currently have designate installed in a single region in a cloud.
> Now we are thinking about the next steps: A multi-region designate for a simple use case: Bring your own domain, have A/AAAA records for your instances regardless of the region.
> Side note: That requirement can be modified if what I am asking is impossible.
>
> I didn't find anything in the ML, nor in the bug tracker [1] outside a neutron bug [2] (am I blind?).
> I had a look at the designate documentation, but there are no best practices for multi-region (or am I blind again?)
> The only relevant part for integration with neutron is in [3], which is not region related.
>
> I am looking for advice from designate experts here, to see what we can do.
>
> Right now, we are thinking about two ways to deal with this:
> A) Install a separate openstack with designate, and make all the regions's neutrons configuration point to a single designate. Neutron would work, designate would be simple to manage (as we have a single designate).
> The downside here is the clear-cut separation of regions: I am afraid of how records are stored in the central designate, and if there won't be multi-tenancy issues (uuid could technically overlap, as different regions means different keystones here).
> B) Install a designate in each region, with DNS servers in each region. We have strict region separation this way.
> The downside is the user friendliness: A customer _can_ decide which region in  which the domain will be hosted. That means that we now need to worry about synchronizing region's state (if you have created a domain in that region, you can't do it elsewhere).
>
> Am I misunderstanding/not seeing something obvious here?
>
> Thank you in advance.
>
> Jean-Philippe Evrard (evrardjp)
>
> [0]: https://www.google.com/search?q=designate+multi+region+site%3Ahttp%3A%2F%2Flists.openstack.org%2Fpipermail%2Fopenstack-discuss%2F
> [1]: https://bugs.launchpad.net/designate?field.searchtext=region
> [2]:  https://review.opendev.org/c/openstack/neutron/+/684854/
> [3]: https://docs.openstack.org/neutron/latest/admin/config-dns-int-ext-serv.html
>
>
>
>
>
>
>
>
>
>
>


From marc-antoine.godde at viarezo.fr  Fri Mar 11 01:58:15 2022
From: marc-antoine.godde at viarezo.fr (Marc-Antoine Godde)
Date: Fri, 11 Mar 2022 02:58:15 +0100
Subject: IPv6 deployment on OpenStack
In-Reply-To: <28d0b91b-d559-1f02-9133-28152a1dc02c@gmail.com>
References: <B30F2915-674E-4029-9F1A-D25589FFF056@viarezo.fr>
 <14575046.tv2OnDr8pf@p1> <8195F0AD-5FE8-432C-A1A7-8EB287B13C64@viarezo.fr>
 <2536429.7s5MMGUR32@p1> <BA82712D-C40D-4B22-899B-6FBEDB52920B@viarezo.fr>
 <a821fd11-e88b-28f5-d2d3-705e52ee3823@gmail.com>
 <9F9D2AF2-6C76-45F2-8227-51DB2623BEFC@viarezo.fr>
 <28d0b91b-d559-1f02-9133-28152a1dc02c@gmail.com>
Message-ID: <397AB987-79F3-494F-914D-909722CFD86B@viarezo.fr>

Hello,

Here is a little feedback of what we did.

We kept our VMs connected to a VLAN network and we activated SLAAC on the corresponding IRB on our router. We then configured the subnet with SLAAC for external router : VMs receives RA (and RDNSS). They now have an IP, the gateway is a link local address of our datacenter router. Everything is working fine.

I have to add that we were having some issues: we couldn?t ping VMs from our router for instance. We added two rules in the default security group (INGRESS and EGRESS, All ICMP on ::/0). Now, it is working fine.

As you said, this paradigm is the most simple one and is working just fine. We?ll continue our testing with this.

For everything, thank you.

Marc-Antoine


> Le 9 mars 2022 ? 18:13, Brian Haley <haleyb.dev at gmail.com> a ?crit :
> 
> Hi,
> 
> On 3/8/22 21:08, Marc-Antoine Godde wrote:
>> Hello,
>> Indeed, this network is connected to our physical network (VLAN 51 for testing), xxxx:xxxx:2f1:aaaa::1 is an interface on our physical router.
>> Finally, we successfully started RADVD by adding a network interface in the subnet to a virtual router in OpenStack. This gave IPs to VMs, they were able to communicate between each other. Obviously, this network topology isn?t making any sense, we can?t route traffic outside. It was just for testing.
>> Now, the goal is route the traffic of VMs. I see two paradigms. The first one, we use our physical router to send RA directly to VMs.
> 
> This is going to be the quickest and easiest way to do this - having the VM directly attached to your infrastructure and having them create a SLAAC address based on the RA from that router.
> 
>> The second one, we use a private subnet (xxxx:xxxx:2f1:bbbb::/64 for instance) in a non external network of OpenStack. We add a virtual router to that subnet, we now have RADVD. We use that router to route traffic to an external network of OpenStack. What is best ?
> 
> This is possible, but requires using prefix delegation such that the private network gets an IPv6 prefix that is routeable in your datacenter. This is described on the docs page at [0] but does require that your infrastructure supports IPV6-PD.
> 
> -Brian
> 
> [0] https://docs.openstack.org/neutron/latest/admin/config-ipv6.html
> 
>>> Le 8 mars 2022 ? 23:47, Brian Haley <haleyb.dev at gmail.com <mailto:haleyb.dev at gmail.com>> a ?crit :
>>> 
>>> Hi Marc-Antoine,
>>> 
>>> See inline...
>>> 
>>> On 3/8/22 11:18, Marc-Antoine Godde wrote:
>>>> Hi,
>>>> Here?s what we?ve done.
>>>> We created a network:
>>>> Name
>>>>    ipv6-testing-network
>>>> ID
>>>>    9d5ca309-1861-4422-bcff-8818f9762a6f
>>>> Project ID
>>>>    653f5a2e60d34768a8629e5d4fca0738
>>>> Status
>>>>    Active
>>>> Admin State
>>>>    UP
>>>> Shared
>>>>    Yes
>>>> External Network
>>>>    Yes
>>>> MTU
>>>>    1500
>>>> Provider Network
>>>>    Network Type: vlan
>>>>    Physical Network: vlan
>>>>    Segmentation ID: 51
>>> 
>>> So this is an external provider network connected to your datacenter network, correct? In the case Slawek was describing I believe he was talking about an internal private network, which when a neutron router is attached will trigger radvd to be spawned, etc.
>>> 
>>> In this case VMs booted on this network should be seeing RAs from your datacenter router, if it's sending them. If it's not that would explain why they only have a link-local IPv6 address since the neutron router will not spawn radvd to run on the external network.
>>> 
>>> BTW, I'm trying to compare this to my local setup, but since I'm not running Horizon just using 'openstack network show...', 'openstack subnet show...' output, which is slightly different, but looks to match what you're doing.
>>> 
>>> Is your plan to have private IPv6 subnets that are then routed to your external network or is this just a test?
>>> 
>>> -Brian
>>> 
>>> 
>>>> We created a subnet:
>>>> Name
>>>>    ipv6-testing-v6
>>>> ID
>>>>    763771d4-b9d7-419a-ba04-97ce3abaf152
>>>> Project ID
>>>>    653f5a2e60d34768a8629e5d4fca0738
>>>> Network Name
>>>>    ipv6-testing-network
>>>> Network ID
>>>>    9d5ca309-1861-4422-bcff-8818f9762a6f
>>>>    <https://openstack.viarezo.fr/project/networks/9d5ca309-1861-4422-bcff-8818f9762a6f/detail <https://openstack.viarezo.fr/project/networks/9d5ca309-1861-4422-bcff-8818f9762a6f/detail>>
>>>> Subnet Pool
>>>>    None
>>>> IP Version
>>>>    IPv6
>>>> CIDR
>>>>    xxxx:xxxx:2f1:aaaa::/64
>>>> IP Allocation Pools
>>>>    Start xxxx:xxxx:2f1:aaaa::2 - End xxxx:xxxx:2f1:aaaa:ffff:ffff:ffff:ffff
>>>> Gateway IP
>>>>    xxxx:xxxx:2f1:aaaa::1
>>>> DHCP Enabled
>>>>    Yes
>>>> IPv6 Address Configuration Mode
>>>>    SLAAC: Address discovered from OpenStack Router
>>>> Additional Routes
>>>>    None
>>>> DNS Name Servers
>>>>    None
>>>> We created Ubuntu and Debian instances. According to Horizon, the instance IPv6 is xxxx:xxxx:2f1:aaaa:f816:3eff:fe6d:c41a. Yet, we only have a link local address which is fe80::f816:3eff:fe6d:c41a/64. TCPdump indicates no Router Advertisement. We tried with and without adding a router on the Network in Horizon. ICMPv6 is authorized in INGRESS from ::/0.
>>>> We checked on the controllers, the computes and in the Neutron containers, systemctl indicated no instance of RADVD. Maybe we checked incorrectly...
>>>> Do you have any suggestions ? I add that we are working with OpenStack Ussuri deployed with OpenStack-ansible.
>>>> Thanks,
>>>> Marc-Antoine
>>>>> Le 8 mars 2022 ? 08:59, Slawek Kaplonski <skaplons at redhat.com <mailto:skaplons at redhat.com><mailto:skaplons at redhat.com <mailto:skaplons at redhat.com>>> a ?crit :
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> On poniedzia?ek, 7 marca 2022 10:36:30 CET Marc-Antoine Godde wrote:
>>>>>> Hello,
>>>>>> 
>>>>>> Thanks for your answer.
>>>>>> 
>>>>>> If I?m correct, we can just use a virtual router with SLAAC since RADVD can deal with RS and emit RA (with support for RFC6106), right ?
>>>>> 
>>>>> Yes, virtual router created in the Neutron is enough there. It will spawn radvd in the qrouter namespace and will send RA to the Vms.
>>>>> Please note that Neutron don't supports privacy extension [1] so You will need to make sure that it's disabled it on Your vms.
>>>>> 
>>>>>> More generally, aren?t we suppose to have a virtual router every time, even in DHCPv6 (stateless and statefull), to answer RS ? I have to admit that I?m not very familiar at the moment with the implementations of RFCs in OpenStack.
>>>>>> 
>>>>>> Currently, we prefer the idea of adding IPv6 through SLAAC to have a uniform network. If we do so, we?d like to avoid sending RA from our physical router to limit its load. Yet, we do not any other arguments to support this choice.
>>>>>> Do you have any recommendations on what to do in latest versions of OpenStack ? What is usually done ?
>>>>> 
>>>>> TBH I don't have such experience. That's more question to operators of OpenStack.
>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> Marc-Antoine
>>>>>> 
>>>>>>> Le 7 mars 2022 ? 09:12, Slawek Kaplonski <skaplons at redhat.com <mailto:skaplons at redhat.com><mailto:skaplons at redhat.com <mailto:skaplons at redhat.com>>> a ?crit :
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> On poniedzia?ek, 7 marca 2022 02:36:24 CET Marc-Antoine Godde wrote:
>>>>>>>> Hello.
>>>>>>>> 
>>>>>>>> We are progressively adding support for IPv6 in my company. We decided to use SLAAC only for laptops, phones, ? since DHCPv6 isn?t supported on Android. RDNSS support will also increase. We are now planning our deployment on OpenStack. We already know that we'll rely only on neutron but we are not yet fixed between DHCPv6 and SLAAC ? Do you have any arguments for one these for VMs ?
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Marc-Antoine.
>>>>>>>> 
>>>>>>> 
>>>>>>> With SLAAC You need to have Your network connected to the router in Neutron and You can only configure IP address on the VM. With DHCPv6 You can configure other things, like some static-routes, etc.
>>>>>>> Neutron supports DHCPv6 in the stateful and stateless variants. With stateless, You are using RA for address configuration and DHCP server for other configation. Please see [1] for more details.
>>>>>>> 
>>>>>>> [1]https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports <https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports><https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports <https://docs.openstack.org/neutron/latest/admin/config-ipv6.html#address-modes-for-ports>>
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> [1]https://datatracker.ietf.org/doc/html/rfc4941 <https://datatracker.ietf.org/doc/html/rfc4941><https://datatracker.ietf.org/doc/html/rfc4941 <https://datatracker.ietf.org/doc/html/rfc4941>>
>>>>> 
>>>>> --
>>>>> Slawek Kaplonski
>>>>> Principal Software Engineer
>>>>> Red Hat
> 



From gouthampravi at gmail.com  Fri Mar 11 06:03:59 2022
From: gouthampravi at gmail.com (Goutham Pacha Ravi)
Date: Fri, 11 Mar 2022 11:33:59 +0530
Subject: [puppet] Proposing Alan Bishop (abishop) for puppet-manila core
In-Reply-To: <FF31E9C6-F917-4E4E-B164-A1CFDC98966F@binero.com>
References: <CAL_crJQtgtBGG3KGjbqR7CuQH987B_9NqvJ9q63kTY5+t4LTzg@mail.gmail.com>
 <FF31E9C6-F917-4E4E-B164-A1CFDC98966F@binero.com>
Message-ID: <CAKSuTPZ=FaN5Oyze9rKozrgBjeEnxa41cjxHw-nnOgKE2tcDrg@mail.gmail.com>

+.02 since I?m not core :)

Alan?s been super helpful to the Manila team regarding puppet and tripleo
integration; and he does great reviews. Thanks for the proposal Takashi!

On Thu, Mar 10, 2022 at 9:02 PM Tobias Urdin <tobias.urdin at binero.com>
wrote:

> +1 - Alan is doing great work!
>
>
> On 9 Mar 2022, at 16:11, Takashi Kajinami <tkajinam at redhat.com> wrote:
>
> Hi Team,
>
>
> Alan is currently a partial core reviewer in Puppet OpenStack and covers
> puppet-cinder and puppet-glance.
>
> He has made great reviews in these two modules since he joined the team,
> but
> in addition,  he has been reviewing patches for puppet-manila and providing
> good feedback for the past two cycle.
>  https://www.stackalytics.io/?user_id=alan-bishop
>
> Based on that fact, I'd like to propose extending his coverage and adding
> Alan
> to the puppet-manila core reviewers.
>
> If you have any feedback please share it in this thread. I'll add him to
> the group
> if we don't hear any objections for 1 week.
>
> I'd like to take this moment to thank Alan for his great work and help in
> this project !
>
> Thank you,
> Takashi KAJINAMI
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220311/ed2a11a6/attachment.htm>

From openstack at a.spamming.party  Fri Mar 11 10:32:59 2022
From: openstack at a.spamming.party (Jean-Philippe Evrard)
Date: Fri, 11 Mar 2022 11:32:59 +0100
Subject: [designate] Architecture help for designate on
 multi-region/multi-AZ deployments
In-Reply-To: <CAMH0MgKjYipHRid2x1Podi2G-icRnPHsdgpwjtKmLZy27qOCHg@mail.gmail.com>
References: <5c6de844-c996-4140-95a9-380f48a5d3b2@www.fastmail.com>
 <CAMH0MgKjYipHRid2x1Podi2G-icRnPHsdgpwjtKmLZy27qOCHg@mail.gmail.com>
Message-ID: <16eac61c-9028-4fce-915e-dc83b953b541@www.fastmail.com>

Hello,

On Thu, Mar 10, 2022, at 22:25, Michael Johnson wrote:
> Personally, if it was my deployment, I would probably go down the path
> of a Designate deployment for each region. This would mean that any
> one DNS zone could not (automatically) be managed from multiple
> regions, but aligns to my understanding of the spirit of a "region" in
> OpenStack.

Yes, that's what I was leaning towards. It makes it very clear.
In a way, anything that's "region specific" belongs to "region designate".

> For non-bring-your-own-domain scenarios, this can be easily managed in
> the DNS hierarchy by creating regional parent zones. I.e.
> west.example.com., east.example.com., moon.example.com., etc. Since
> it's also likely that routable IP address space will be unique per
> region, the reverse zones would naturally be unique.

Yes, that's what we thought of doing too. It's pretty easy for our domains and for many operational aspects.

> In the case of bring-your-own-domain, you would need a policy that any
> one domain can only exist in one region. However, there would be
> nothing stopping users from doing a similar regional breakdown of
> sub-domains if they would like.
That's where we were stopping. Is there a way to _technically enforce_ such kind of policy in an automated fashion?
That's the most important part for me, and (sadly) the part that's very fuzzy.

> As for the synchronization question, I think that is more of an issue
> that a customer would need to address if they feel they want a
> multiple primary scenario. Technically there would be no reason they
> could not create the zone in multiple regions, keep it in sync
> themselves, and add the DNS servers for both regions as authoritative
> for the zone.

I had the same argument, glad to see we are aligned :)
I still think this is more of a "hack".

> If you want to provide a "premium" service where DNS HA is provided
> across regions, this can be done using the Designate pools
> configuration or via the normal secondary DNS server model configured
> in your DNS servers. This would maintain DNS resolution should a
> region go down, but if the zone was created in a specific region that
> is unavailable, you would be unable to update it until the region is
> restored.

We were only thinking of secondary + anycast, and only in the case of a "central" model.
I will have a look at pools. Thanks for the pointer.


> Just some thoughts, please feel free to reach out if you want to chat
> about it more or bounce ideas around,

It's all what I was looking for, so really _thank you_ for doing that :)
I am more and more thinking about a "central model" + "region model" mixed together for covering all use cases, now.

Regards,
JP (evrardjp)


From stephenfin at redhat.com  Fri Mar 11 12:26:38 2022
From: stephenfin at redhat.com (Stephen Finucane)
Date: Fri, 11 Mar 2022 12:26:38 +0000
Subject: [release] Independent release jobs are still using old release job
 templates
Message-ID: <bf15986abdd062c6d97fe09d0656ffe9e584274b.camel@redhat.com>

tl;dr: How do we get projects using the independent release process to use the
openstack-python3 zuul job template corresponding to the latest release? I've
noticed a couple of patches like [1] popping up for oslo-affiliated projects.
These projects are currently using the python3 zuul job templates corresponding
to an older release (e.g. Wallaby) and the author is correctly updating them to
use the most recent release. These initially caught me off-guard since I'm used
to seeing a bot propose these changes but I've realized that all affected
projects are using the "independent" release process and therefore don't receive
a new stable branch nor related bot-proposed commits. This leaves us in a bit of
a pickle though. There are a lot of projects using this release process, and
there's effectively zero chance that someone is going to remember to bump the
jobs every single release.

While some could argue that this is "working as designed", it seems important to
me that we would be testing these projects against the supported runtimes for
the release currently under development. As such, how should we try to address
this? One option I see is to add a new generic 'openstack-python3-jobs' template
which would always duplicate the jobs used for the current release. I've
proposed that here [2]. There are some pros and cons to this approach:

 * PRO: Minimal effort from everyone.
 * CON: The HEAD of master for each project could be broken and we'd never know
   until some change was proposed to master (note: this is effectively the
   status quo right now, so it's not a big break)
 * CON: If those independent projects had an alternative to stable branches
   (i.e. semver branches), those would eventually break as the runtimes kept
   changing.

The other option is to extend the openstack bot to propose release bump patches
against these independent projects. This has the inverse pro/con balance:

 * PRO: We get a regular "check-up" on the health of the project whenever these
   patches are proposed.
 * PRO: Long-lived stable branches should stay working
 * CON: Lots of busy work for reviewers.

What are everyone's thoughts? I'm in favour of the first approach (generic
'openstack-python3-jobs' template) but the bot enhancement would also wfm. If we
go with the first approach, we'd probably want to script something to "fix" all
the existing independent projects rather than attempt to find and fix them
manually.

Cheers,
Stephen

PS: Apologies if this has been discussed previously. I clearly missed that
discussion.

[1] https://review.opendev.org/c/openstack/os-api-ref/+/831560
[2] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833286



From stephenfin at redhat.com  Fri Mar 11 12:34:45 2022
From: stephenfin at redhat.com (Stephen Finucane)
Date: Fri, 11 Mar 2022 12:34:45 +0000
Subject: [charms] Can we update the Python runtimes for the
 'openstack-python3-charms-jobs' template?
Message-ID: <11826ff2555e322d9d4022440d2065fabf53593e.camel@redhat.com>

Related to the "Independent release jobs are still using old release job
templates" email I just sent [1], I've proposed a change [2] that would modify
the 'openstack-python3-charms-jobs' job template so that it mimics the behaviour
of the proposed 'openstack-python3-jobs' template. That is, the 'openstack-
python3-charms-jobs' release will now be updated at the start of each new
release to test against the same runtimes proposed for this new release.
However, frickler has noted that the use of older runtimes for the charms jobs
may in fact be intentional. Could someone from the charms team please weigh in
on [2]. If this is in fact intentional, it would be good to add a note to the
job template indicating this fact to prevent people like me breaking it in the
future :)

Cheers,
Stephen

[1] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027676.html
[2] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833330/1



From fungi at yuggoth.org  Fri Mar 11 13:38:03 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 11 Mar 2022 13:38:03 +0000
Subject: [release] Independent release jobs are still using old release
 job templates
In-Reply-To: <bf15986abdd062c6d97fe09d0656ffe9e584274b.camel@redhat.com>
References: <bf15986abdd062c6d97fe09d0656ffe9e584274b.camel@redhat.com>
Message-ID: <20220311133803.l3rpuxb3k232nk7s@yuggoth.org>

On 2022-03-11 12:26:38 +0000 (+0000), Stephen Finucane wrote:
[...]
> These initially caught me off-guard since I'm used to seeing a bot
> propose these changes but I've realized that all affected projects
> are using the "independent" release process and therefore don't
> receive a new stable branch nor related bot-proposed commits.
[...]

It's more than this, the "independent" release model definition is
that projects have opted out of central release management entirely:

https://releases.openstack.org/reference/release_models.html#independent

If you want the OpenStack release managers coordinating cycle
activities for those projects, I suspect we may need to redefine the
relationship there.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220311/1f85560b/attachment.sig>

From elod.illes at est.tech  Fri Mar 11 15:43:55 2022
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Fri, 11 Mar 2022 16:43:55 +0100
Subject: [release] Release countdown for week R-2, Mar 14 - 18
Message-ID: <1493c1c9-6d8f-2fca-9b3c-8ac602cbe1c3@est.tech>

Development Focus
-----------------

At this point we should have release candidates (RC1 or recent intermediary
release) for all the Yoga 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/yoga branch
creation for all deliverables that have not branched yet, using the latest
available Yoga 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/yoga 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/yoga branch before releasing out of the
stable/yoga 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 Zed development, though the focus should still be on
finishing up Yoga 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 Yoga release.

Finally, now is a good time to finalize release notes, if it is not done 
yet. 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 Yoga version of your project.

Upcoming Deadlines & Dates
--------------------------

Final RC deadline: March 24th, 2022 (R-1 week)
Final Yoga release: March 30th, 2022
Next PTG: April 4 - 8, 2022 (virtual)


El?d Ill?s
irc: elodilles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220311/d0a70b1e/attachment-0001.htm>

From zigo at debian.org  Fri Mar 11 19:03:08 2022
From: zigo at debian.org (Thomas Goirand)
Date: Fri, 11 Mar 2022 20:03:08 +0100
Subject: [release] Release countdown for week R-2, Mar 14 - 18
In-Reply-To: <1493c1c9-6d8f-2fca-9b3c-8ac602cbe1c3@est.tech>
References: <1493c1c9-6d8f-2fca-9b3c-8ac602cbe1c3@est.tech>
Message-ID: <9181046f-31ab-bc0a-ddc0-a20dad14961c@debian.org>

On 3/11/22 16:43, El?d Ill?s wrote:
> Development Focus
> -----------------
> 
> At this point we should have release candidates (RC1 or recent intermediary
> release) for all the Yoga deliverables.

Well, at least Cinder is missing...

Thomas


From fungi at yuggoth.org  Fri Mar 11 19:28:31 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 11 Mar 2022 19:28:31 +0000
Subject: [release] Release countdown for week R-2, Mar 14 - 18
In-Reply-To: <9181046f-31ab-bc0a-ddc0-a20dad14961c@debian.org>
References: <1493c1c9-6d8f-2fca-9b3c-8ac602cbe1c3@est.tech>
 <9181046f-31ab-bc0a-ddc0-a20dad14961c@debian.org>
Message-ID: <20220311192830.tv4qkt2xgjwa2c2z@yuggoth.org>

On 2022-03-11 20:03:08 +0100 (+0100), Thomas Goirand wrote:
> On 3/11/22 16:43, El?d Ill?s wrote:
> > Development Focus
> > -----------------
> > 
> > At this point we should have release candidates (RC1 or recent
> > intermediary release) for all the Yoga deliverables.
> 
> Well, at least Cinder is missing...

Correct, https://review.opendev.org/832367 needs a second release
manager to approve. It came up in the release meeting earlier today
but I guess wasn't reflected in updates to the countdown template.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220311/a553aebf/attachment.sig>

From anyrude10 at gmail.com  Fri Mar 11 14:16:41 2022
From: anyrude10 at gmail.com (Anirudh Gupta)
Date: Fri, 11 Mar 2022 19:46:41 +0530
Subject: [TripleO] Upgrade overcloud Nodes with Puppet Pacemaker Issue on
 Controller-0
Message-ID: <CAKxkTi3Pg=kGg1cQkfCBwKeYNJSMQ88DWQKrC_nXthZdZ1WfxQ@mail.gmail.com>

Hi Team

I have deployed TripleO Train Undercloud and Overcloud in HA Mode.
After which I Upgraded TripleO Undercloud to Ussuri Release.

While upgrading the Overcloud Nodes, there were some minor hiccups
initially, but after enabling internet and enabling Centos repositories, we
resolved all the issues.

After executing openstack overcloud upgrade run command for only the
controllers, we get some puppet issues for pacemaker service for
Controller-0 (Active DC)

The same check passed for Controller-1 and Controller-2. All the overcloud
nodes have been spawned with the same image, so there must not be any issue.

Attaching the logs below:
2022-03-09 15:22:02.510128 | 525400f8-4aa7-5981-5af0-000000006a82 |
TASK | Gather podman infos
2022-03-09 15:22:02.869577 | 525400f8-4aa7-5981-5af0-000000006a0f |
 CHANGED | Enable and start netns-placeholder | overcloud-controller-1
2022-03-09 15:22:02.873413 | 525400f8-4aa7-5981-5af0-000000006a0f |
TIMING | tripleo_container_manage : Enable and start netns-placeholder |
overcloud-controller-1 | 0:14:39.816795 | 0.97s
2022-03-09 15:22:02.901485 | 525400f8-4aa7-5981-5af0-000000006940 |
TASK | Update container configs with new config hashes
2022-03-09 15:22:02.943620 | 525400f8-4aa7-5981-5af0-000000006940 |
TIMING | tripleo_container_manage : Update container configs with new
config hashes | overcloud-controller-1 | 0:14:39.887003 | 0.04s
2022-03-09 15:22:02.960739 | 1fecaf23-8a62-488a-87ab-a2ee3c307ae5 |
INCLUDED |
/usr/share/ansible/roles/tripleo_container_manage/tasks/puppet_config.yml |
overcloud-controller-1
2022-03-09 15:22:02.988374 | 525400f8-4aa7-5981-5af0-000000006ab5 |
TASK | Update config hashes for container startup configs
2022-03-09 15:22:03.380251 | 525400f8-4aa7-5981-5af0-000000006ab5 |
OK | Update config hashes for container startup configs |
overcloud-controller-1
2022-03-09 15:22:03.381768 | 525400f8-4aa7-5981-5af0-000000006ab5 |
TIMING | tripleo_container_manage : Update config hashes for container
startup configs | overcloud-controller-1 | 0:14:40.325159 | 0.39s
2022-03-09 15:22:03.409190 | 525400f8-4aa7-5981-5af0-000000006941 |
TASK | Delete orphan containers from
/var/lib/tripleo-config/container-startup-config/step_3
2022-03-09 15:22:03.453834 | 525400f8-4aa7-5981-5af0-000000006941 |
TIMING | tripleo_container_manage : Delete orphan containers from
/var/lib/tripleo-config/container-startup-config/step_3 |
overcloud-controller-1 | 0:14:40.397197 | 0.04s
2022-03-09 15:22:03.470413 | 8e8040a9-b1ed-498c-becb-4a25381f487f |
INCLUDED |
/usr/share/ansible/roles/tripleo_container_manage/tasks/delete_orphan.yml |
overcloud-controller-1
2022-03-09 15:22:03.498978 | 525400f8-4aa7-5981-5af0-000000006ad8 |
TASK | Gather podman infos
 instead.\nTraceback (most recent call last):\n  File
\"/usr/lib/python3.6/site-packages/pcs/resource.py\", line 1039, in
resource_update\n    resource.getAttribute(\"type\"),\n  File
\"/usr/lib/python3.6/site-packages/pcs/lib/resource_agent/facade.py\", line
200, in facade_from_parsed_name\n    parse_metadata(name,
load_metadata(self._runner, name))\n  File
\"/usr/lib/python3.6/site-packages/pcs/lib/resource_agent/xml.py\", line
114, in load_metadata\n    return
_metadata_xml_to_dom(_load_metadata_xml(runner, agent_name))\n  File
\"/usr/lib/python3.6/site-packages/pcs/lib/resource_agent/xml.py\", line
52, in _load_metadata_xml\n    raise
UnableToGetAgentMetadata(agent_name.full_name,
stderr.strip())\npcs.lib.resource_agent.error.UnableToGetAgentMetadata\n\nDuring
handling of the above exception, another exception occurred:\n\nTraceback
(most recent call last):\n  File \"/sbin/pcs\", line 11, in <module>\n
 load_entry_point('pcs===0.10.11.22-9d83b', 'console_scripts', 'pcs')()\n
 File \"/usr/lib/python3.6/site-packages/pcs/app.py\", line 278, in main\n
   utils.get_library_wrapper(), argv, utils.get_input_modifiers()\n  File
\"/usr/lib/python3.6/site-packages/pcs/cli/common/routing.py\", line 33, in
_router\n    return cmd_map[sub_cmd](lib, argv_next, modifiers)\n  File
\"/usr/lib/python3.6/site-packages/pcs/cli/common/routing.py\", line 33, in
_router\n    return cmd_map[sub_cmd](lib, argv_next, modifiers)\n  File
\"/usr/lib/python3.6/site-packages/pcs/resource.py\", line 1058, in
resource_update\n    [lib_ra.resource_agent_error_to_report_item(e,
severity)]\n  File
\"/usr/lib/python3.6/site-packages/pcs/cli/reports/output.py\", line 38, in
process_library_reports\n    report_dto = report_item.to_dto()\n  File
\"/usr/lib/python3.6/site-packages/pcs/common/reports/item.py\", line 182,
in to_dto\n    severity=self.severity.to_dto(),\nAttributeError: 'str'
object has no attribute 'to_dto'\nError:
/Stage[main]/Tripleo::Profile::Pacemaker::Ovn_dbs_bundle/Pacemaker::Resource::Ocf[ovndb_servers]/Pcmk_resource[ovndb_servers]:
Could not evaluate: pcmk_resource_has_changed? --force resource update
ovndb_servers ocf:ovn:ovndb-servers master_ip=[fd00:fd00:fd00:2000::53]
nb_master_port=6641 sb_master_port=6642 manage_northd=yes
inactive_probe_interval=180000 listen_on_master_ip_only=yes meta
notify=true container-attribute-target=host op start timeout=200s stop
timeout=200s monitor interval=10s role=Master timeout=60s monitor
interval=30s role=Slave timeout=60s bundle ovn-dbs-bundle returned error
ovndb_servers. This should never happen.\nWarning: This command is
deprecated and will be removed. Please use 'pcs constraint config'
instead.", "stderr_lines": ["Warning: /etc/puppet/hiera.yaml: Use of
'hiera.yaml' version 3 is deprecated. It should be converted to version 5",
"   (file: /etc/puppet/hiera.yaml)", "Warning: Undefined variable
'::deploy_config_name'; ", "   (file & line not available)", "Warning: The
function 'hiera' is deprecated in favor of using 'lookup'. See
https://puppet.com/docs/puppet/6.14/deprecated_language.html", "   (file &
line not available)", "*Warning: This method is deprecated, please use
match expressions with Stdlib::Compat::Ipv6 instead. They are described at
https://docs.puppet.com/puppet/latest/reference/lang_data_type.html#match-expressions
<https://docs.puppet.com/puppet/latest/reference/lang_data_type.html#match-expressions>.
at
[\"/etc/puppet/modules/tripleo/manifests/profile/pacemaker/ovn_dbs_bundle.pp\",
336]:[\"unknown\", 1]", "*   (location:
/etc/puppet/modules/stdlib/lib/puppet/functions/deprecation.rb:34:in
`deprecation')", "Warning: This command is deprecated and will be removed.
Please use 'pcs property config' instead.", "Warning: This command is
deprecated and will be removed. Please use 'pcs constraint config'
instead.", "Warning: This command is deprecated and will be removed. Please
use 'pcs constraint config' instead.", "Traceback (most recent call
last):", "  File \"/usr/lib/python3.6/site-packages/pcs/resource.py\", line
1039, in resource_update", "    resource.getAttribute(\"type\"),", "  File
\"/usr/lib/python3.6/site-packages/pcs/lib/resource_agent/facade.py\", line
200, in facade_from_parsed_name", "    parse_metadata(name,
load_metadata(self._runner, name))", "  File
\"/usr/lib/python3.6/site-packages/pcs/lib/resource_agent/xml.py\", line
114, in load_metadata", "    return
_metadata_xml_to_dom(_load_metadata_xml(runner, agent_name))", "  File
\"/usr/lib/python3.6/site-packages/pcs/lib/resource_agent/xml.py\", line
52, in _load_metadata_xml", "    raise
UnableToGetAgentMetadata(agent_name.full_name, stderr.strip())",
"pcs.lib.resource_agent.error.UnableToGetAgentMetadata", "", "During
handling of the above exception, another exception occurred:", "",
"Traceback (most recent call last):", "  File \"/sbin/pcs\", line 11, in
<module>", "    load_entry_point('pcs===0.10.11.22-9d83b',
'console_scripts', 'pcs')()", "  File
\"/usr/lib/python3.6/site-packages/pcs/app.py\", line 278, in main", "
 utils.get_library_wrapper(), argv, utils.get_input_modifiers()", "  File
\"/usr/lib/python3.6/site-packages/pcs/cli/common/routing.py\", line 33, in
_router", "    return cmd_map[sub_cmd](lib, argv_next, modifiers)", "  File
\"/usr/lib/python3.6/site-packages/pcs/cli/common/routing.py\", line 33, in
_router", "    return cmd_map[sub_cmd](lib, argv_next, modifiers)", "  File
\"/usr/lib/python3.6/site-packages/pcs/resource.py\", line 1058, in
resource_update", "    [lib_ra.resource_agent_error_to_report_item(e,
severity)]", "  File
\"/usr/lib/python3.6/site-packages/pcs/cli/reports/output.py\", line 38, in
process_library_reports", "    report_dto = report_item.to_dto()", "  File
\"/usr/lib/python3.6/site-packages/pcs/common/reports/item.py\", line 182,
in to_dto", "    severity=self.severity.to_dto(),", "AttributeError: 'str'
object has no attribute 'to_dto'", "Error:
/Stage[main]/Tripleo::Profile::Pacemaker::Ovn_dbs_bundle/Pacemaker::Resource::Ocf[ovndb_servers]/Pcmk_resource[ovndb_servers]:
Could not evaluate: pcmk_resource_has_changed? --force resource update
ovndb_servers ocf:ovn:ovndb-servers master_ip=[fd00:fd00:fd00:2000::53]
nb_master_port=6641 sb_master_port=6642 manage_northd=yes
inactive_probe_interval=180000 listen_on_master_ip_only=yes meta
notify=true container-attribute-target=host op start timeout=200s stop
timeout=200s monitor interval=10s role=Master timeout=60s monitor
interval=30s role=Slave timeout=60s bundle ovn-dbs-bundle returned error
ovndb_servers. This should never happen.", "Warning: This command is
deprecated and will be removed. Please use 'pcs constraint config'
instead."], "stdout": "Notice: Compiled catalog for
overcloud-controller-0.localdomain in environment production in 0.75
seconds\nNotice: Applied catalog in 30.15 seconds\nChanges:\nEvents:\n
     Failure: 1\n            Total: 1\nResources:\n           Failed: 1\n
   Out of sync: 1\n          Skipped: 26\n            Total: 35\nTime:\n
Config retrieval: 0.84\n    Pcmk resource: 11.39\n         Last run:
1646819523\n   Pcmk constraint: 2.86\n   Transaction evaluation: 30.09\n
Catalog application: 30.15\n      Pcmk bundle: 7.09\n    Pcmk property:
8.43\n            Total: 30.15\nVersion:\n           Config: 1646819492\n
        Puppet: 6.14.0", "stdout_lines": ["Notice: Compiled catalog for
overcloud-controller-0.localdomain in environment production in 0.75
seconds", "Notice: Applied catalog in 30.15 seconds", "Changes:",
"Events:", "          Failure: 1", "            Total: 1", "Resources:", "
          Failed: 1", "      Out of sync: 1", "          Skipped: 26", "
         Total: 35", "Time:", "   Config retrieval: 0.84", "    Pcmk
resource: 11.39", "         Last run: 1646819523", "   Pcmk constraint:
2.86", "   Transaction evaluation: 30.09", "   Catalog application: 30.15",
"      Pcmk bundle: 7.09", "    Pcmk property: 8.43", "            Total:
30.15", "Version:", "           Config: 1646819492", "           Puppet:
6.14.0"]}
2022-03-09 15:22:03.686083 | 525400f8-4aa7-5981-5af0-0000000067ae |
 FATAL | Run init bundle puppet on the host for ovn_dbs |
overcloud-controller-0 | error={"changed": false, "cmd": "puppet apply
 --detailed-exitcodes --summarize --color=false --modulepath
'/etc/puppet/modules:/opt/stack/puppet-modules:/usr/share/openstack-puppet/modules'
--tags
'pacemaker::resource::bundle,pacemaker::property,pacemaker::resource::ip,pacemaker::resource::ocf,pacemaker::constraint::order,pacemaker::constraint::colocation'
-e 'include ::tripleo::profile::base::pacemaker; include
::tripleo::profile::pacemaker::ovn_dbs_bundle'\n", "delta":
"0:00:36.507726", "end": "2022-03-09 15:22:03.635619",
"failed_when_result": true, "msg": "non-zero return code", "rc": 4,
"start": "2022-03-09 15:21:27.127893", "stderr": "Warning:
/etc/puppet/hiera.yaml: Use of 'hiera.yaml' version 3 is deprecated. It
should be converted to version 5\n   (file:
/etc/puppet/hiera.yaml)\nWarning: Undefined variable
'::deploy_config_name'; \n   (file & line not available)\nWarning: The
function 'hiera' is deprecated in favor of using 'lookup'. See
https://puppet.com/docs/puppet/6.14/deprecated_language.html\n   (file &
line not available)\nWarning: This method is deprecated, please use match
expressions with Stdlib::Compat::Ipv6 instead. They are described at
https://docs.puppet.com/puppet/latest/reference/lang_data_type.html#match-expressions.
at
[\"/etc/puppet/modules/tripleo/manifests/profile/pacemaker/ovn_dbs_bundle.pp\",
336]:[\"unknown\", 1]\n   (location:
/etc/puppet/modules/stdlib/lib/puppet/functions/deprecation.rb:34:in
`deprecation')\nWarning: This command is deprecated and will be removed.
Please use 'pcs property config' instead.\nWarning: This command is
deprecated and will be removed. Please use 'pcs constraint config'
instead.\nWarning: This command is deprecated and will be removed. Please
use 'pcs constraint config' instead.\nTraceback (most recent call last):\n
 File \"/usr/lib/python3.6/site-packages/pcs/resource.py\", line 1039, in
resource_update\n    resource.getAttribute(\"type\"),\n  File
\"/usr/lib/python3.6/site-packages/pcs/lib/resource_agent/facade.py\", line
200, in facade_from_parsed_name\n    parse_metadata(name,
load_metadata(self._runner, name))\n  File
\"/usr/lib/python3.6/site-packages/pcs/lib/resource_agent/xml.py\", line
114, in load_metadata\n    return
_metadata_xml_to_dom(_load_metadata_xml(runner, agent_name))\n  File
\"/usr/lib/python3.6/site-packages/pcs/lib/resource_agent/xml.py\", line
52, in _load_metadata_xml\n    raise
UnableToGetAgentMetadata(agent_name.full_name,
stderr.strip())\npcs.lib.resource_agent.error.UnableToGetAgentMetadata\n\nDuring
handling of the above exception, another exception occurred:\n\nTraceback
(most recent call last):\n  File \"/sbin/pcs\", line 11, in <module>\n
 load_entry_point('pcs===0.10.11.22-9d83b', 'console_scripts', 'pcs')()\n
 File \"/usr/lib/python3.6/site-packages/pcs/app.py\", line 278, in main\n
   utils.get_library_wrapper(), argv, utils.get_input_modifiers()\n  File
\"/usr/lib/python3.6/site-packages/pcs/cli/common/routing.py\", line 33, in
_router\n    return cmd_map[sub_cmd](lib, argv_next, modifiers)\n  File
\"/usr/lib/python3.6/site-packages/pcs/cli/common/routing.py\", line 33, in
_router\n    return cmd_map[sub_cmd](lib, argv_next, modifiers)\n  File
\"/usr/lib/python3.6/site-packages/pcs/resource.py\", line 1058, in
resource_update\n    [lib_ra.resource_agent_error_to_report_item(e,
severity)]\n  File
\"/usr/lib/python3.6/site-packages/pcs/cli/reports/output.py\", line 38, in
process_library_reports\n    report_dto = report_item.to_dto()\n  File
\"/usr/lib/python3.6/site-packages/pcs/common/reports/item.py\", line 182,
in to_dto\n    severity=self.severity.to_dto(),\nAttributeError: 'str'
object has no attribute 'to_dto'\nError:
/Stage[main]/Tripleo::Profile::Pacemaker::Ovn_dbs_bundle/Pacemaker::Resource::Ocf[ovndb_servers]/Pcmk_resource[ovndb_servers]:
Could not evaluate: pcmk_resource_has_changed? --force resource update
ovndb_servers ocf:ovn:ovndb-servers master_ip=[fd00:fd00:fd00:2000::53]
nb_master_port=6641 sb_master_port=6642 manage_northd=yes
inactive_probe_interval=180000 listen_on_master_ip_only=yes meta
notify=true container-attribute-target=host op start timeout=200s stop
timeout=200s monitor interval=10s role=Master timeout=60s monitor
interval=30s role=Slave timeout=60s bundle ovn-dbs-bundle returned error
ovndb_servers. This should never happen.\nWarning: This command is
deprecated and will be removed. Please use 'pcs constraint config'
instead.", "stderr_lines": ["Warning: /etc/puppet/hiera.yaml: Use of
'hiera.yaml' version 3 is deprecated. It should be converted to version 5",
"   (file: /etc/puppet/hiera.yaml)", "Warning: Undefined variable
'::deploy_config_name'; ", "   (file & line not available)", "Warning: The
function 'hiera' is deprecated in favor of using 'lookup'. See
https://puppet.com/docs/puppet/6.14/deprecated_language.html", "   (file &
line not available)", "Warning: This method is deprecated, please use match
expressions with Stdlib::Compat::Ipv6 instead. They are described at
https://docs.puppet.com/puppet/latest/reference/lang_data_type.html#match-expressions.
at
[\"/etc/puppet/modules/tripleo/manifests/profile/pacemaker/ovn_dbs_bundle.pp\",
336]:[\"unknown\", 1]", "   (location:
/etc/puppet/modules/stdlib/lib/puppet/functions/deprecation.rb:34:in
`deprecation')", "Warning: This command is deprecated and will be removed.
Please use 'pcs property config' instead.", "Warning: This command is
deprecated and will be removed. Please use 'pcs constraint config'
instead.", "Warning: This command is deprecated and will be removed. Please
use 'pcs constraint config' instead.", "Traceback (most recent call
last):", "  File \"/usr/lib/python3.6/site-packages/pcs/resource.py\", line
1039, in resource_update", "    resource.getAttribute(\"type\"),", "  File
\"/usr/lib/python3.6/site-packages/pcs/lib/resource_agent/facade.py\", line
200, in facade_from_parsed_name", "    parse_metadata(name,
load_metadata(self._runner, name))", "  File
\"/usr/lib/python3.6/site-packages/pcs/lib/resource_agent/xml.py\", line
114, in load_metadata", "    return
_metadata_xml_to_dom(_load_metadata_xml(runner, agent_name))", "  File
\"/usr/lib/python3.6/site-packages/pcs/lib/resource_agent/xml.py\", line
52, in _load_metadata_xml", "    raise
UnableToGetAgentMetadata(agent_name.full_name, stderr.strip())",
"pcs.lib.resource_agent.error.UnableToGetAgentMetadata", "", "During
handling of the above exception, another exception occurred:", "",
"Traceback (most recent call last):", "  File \"/sbin/pcs\", line 11, in
<module>", "    load_entry_point('pcs===0.10.11.22-9d83b',
'console_scripts', 'pcs')()", "  File
\"/usr/lib/python3.6/site-packages/pcs/app.py\", line 278, in main", "
 utils.get_library_wrapper(), argv, utils.get_input_modifiers()", "  File
\"/usr/lib/python3.6/site-packages/pcs/cli/common/routing.py\", line 33, in
_router", "    return cmd_map[sub_cmd](lib, argv_next, modifiers)", "  File
\"/usr/lib/python3.6/site-packages/pcs/cli/common/routing.py\", line 33, in
_router", "    return cmd_map[sub_cmd](lib, argv_next, modifiers)", "  File
\"/usr/lib/python3.6/site-packages/pcs/resource.py\", line 1058, in
resource_update", "    [lib_ra.resource_agent_error_to_report_item(e,
severity)]", "  File
\"/usr/lib/python3.6/site-packages/pcs/cli/reports/output.py\", line 38, in
process_library_reports", "    report_dto = report_item.to_dto()", "  File
\"/usr/lib/python3.6/site-packages/pcs/common/reports/item.py\", line 182,
in to_dto", "    severity=self.severity.to_dto(),", "AttributeError: 'str'
object has no attribute 'to_dto'", "Error:
/Stage[main]/Tripleo::Profile::Pacemaker::Ovn_dbs_bundle/Pacemaker::Resource::Ocf[ovndb_servers]/Pcmk_resource[ovndb_servers]:
Could not evaluate: pcmk_resource_has_changed? --force resource update
ovndb_servers ocf:ovn:ovndb-servers master_ip=[fd00:fd00:fd00:2000::53]
nb_master_port=6641 sb_master_port=6642 manage_northd=yes
inactive_probe_interval=180000 listen_on_master_ip_only=yes meta
notify=true container-attribute-target=host op start timeout=200s stop
timeout=200s monitor interval=10s role=Master timeout=60s monitor
interval=30s role=Slave timeout=60s bundle ovn-dbs-bundle returned error
ovndb_servers. This should never happen.", *"Warning: This command is
deprecated and will be removed. Please use 'pcs constraint config'
instead."], "stdout":* "Notice: Compiled catalog for
overcloud-controller-0.localdomain in environment production in 0.75
seconds\nNotice: Applied catalog in 30.15 seconds\nChanges:\nEvents:\n
     Failure: 1\n            Total: 1\nResources:\n           Failed: 1\n
   Out of sync: 1\n          Skipped: 26\n            Total: 35\nTime:\n
Config retrieval: 0.84\n    Pcmk resource: 11.39\n         Last run:
1646819523\n   Pcmk constraint: 2.86\n   Transaction evaluation: 30.09\n
Catalog application: 30.15\n      Pcmk bundle: 7.09\n    Pcmk property:
8.43\n            Total: 30.15\nVersion:\n           Config: 1646819492\n
        Puppet: 6.14.0", "stdout_lines": ["Notice: Compiled catalog for
overcloud-controller-0.localdomain in environment production in 0.75
seconds", "Notice: Applied catalog in 30.15 seconds", "Changes:",
"Events:", "          Failure: 1", "            Total: 1", "Resources:", "
          Failed: 1", "      Out of sync: 1", "          Skipped: 26", "
         Total: 35", "Time:", "   Config retrieval: 0.84", "    Pcmk
resource: 11.39", "         Last run: 1646819523", "   Pcmk constraint:
2.86", "   Transaction evaluation: 30.09", "   Catalog application: 30.15",
"      Pcmk bundle: 7.09", "    Pcmk property: 8.43", "            Total:
30.15", "Version:", "           Config: 1646819492", "           Puppet:
6.14.0"]}
2022-03-09 15:22:03.690015 | 525400f8-4aa7-5981-5af0-0000000067ae |
TIMING | tripleo_ha_wrapper : Run init bundle puppet on the host for
ovn_dbs | overcloud-controller-0 | 0:14:40.633394 | 36.87s
2022-03-09 15:22:05.269139 | 525400f8-4aa7-5981-5af0-000000006a82 |
OK | Gather podman infos | overcloud-controller-2
2022-03-09 15:22:05.270057 | 525400f8-4aa7-5981-5af0-000000006a82 |
TIMING | tripleo_container_manage : Gather podman infos |
overcloud-controller-2 | 0:14:42.213453 | 2.76s
2022-03-09 15:22:05.726794 | 525400f8-4aa7-5981-5af0-000000006a83 |
TASK | Delete orphan containers managed by Podman for
/var/lib/tripleo-config/container-startup-config/step_3
2022-03-09 15:22:05.786601 | 525400f8-4aa7-5981-5af0-000000006a83 |
TIMING | Delete orphan containers managed by Podman for
/var/lib/tripleo-config/container-startup-config/step_3 |
overcloud-controller-2 | 0:14:42.729983 | 0.06s
2022-03-09 15:22:06.038548 | 525400f8-4aa7-5981-5af0-000000006b27 |
TIMING | tripleo_container_rm : include_tasks | overcloud-controller-2 |
0:14:42.981908 | 0.19s
2022-03-09 15:22:06.068012 | 525400f8-4aa7-5981-5af0-000000006942 |
TASK | Create containers from
/var/lib/tripleo-config/container-startup-config/step_3
2022-03-09 15:22:06.119081 | 525400f8-4aa7-5981-5af0-000000006942 |
TIMING | tripleo_container_manage : Create containers from
/var/lib/tripleo-config/container-startup-config/step_3 |
overcloud-controller-2 | 0:14:43.062462 | 0.05s
2022-03-09 15:22:06.136762 | f2c26285-bf89-4ee3-a43f-cdf6e8722aaa |
INCLUDED |
/usr/share/ansible/roles/tripleo_container_manage/tasks/create.yml |
overcloud-controller-2

Regards
Anirudh Gupta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220311/957ad7f9/attachment-0001.htm>

From dmendiza at redhat.com  Fri Mar 11 21:44:09 2022
From: dmendiza at redhat.com (Douglas Mendizabal)
Date: Fri, 11 Mar 2022 15:44:09 -0600
Subject: [openstack][keystone] Stepping down from core
In-Reply-To: <CAE4Awf_WpipFpn4F5ZdwmAQdfmXNxr_wO-1ZpnLXSM09CzgzNA@mail.gmail.com>
References: <CAE4Awf_WpipFpn4F5ZdwmAQdfmXNxr_wO-1ZpnLXSM09CzgzNA@mail.gmail.com>
Message-ID: <c1ecf522-951a-b5a0-5a11-af6423b33846@redhat.com>

On 3/8/22 10:23, Gage Hugo wrote:
> After some consideration and my focus shifting to other priorities, I 
> cannot reliably devote enough time to keystone?so I'll be stepping down 
> from keystone core.?I greatly appreciate the experiences I had to learn 
> and grow thanks to everyone's help.
> 
> Thanks to you all and I'm grateful for the opportunities I've had with 
> the project and openstack as a whole. Hopefully we will get to 
> collaborate again more in the future.
> 
> Gage Hugo

Thank you for all the work you've done in the Keystone team.  You will 
definitely be missed.

I was wondering if you'll still be around in the Security SIG, or if 
you're stepping down from that as well?

Regards,
- Doug



From gmann at ghanshyammann.com  Fri Mar 11 21:58:28 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Fri, 11 Mar 2022 15:58:28 -0600
Subject: [all][tc] What's happening in Technical Committee: summary Mar
 11th, 21: Reading: 10 min
Message-ID: <17f7afd8105.e5e4e14272919.5980947388757019054@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 Mar 10th. Most of the meeting discussions are summarized below (Completed
or in-progress activities section). Meeting full logs are available
@https://meetings.opendev.org/meetings/tc/2022/tc.2022-03-10-15.00.log.html

* Next week's meeting is on Mar 17th Thursday 15:00 UTC, feel free to add the topic on
the agenda[1] by Mar 16th. Please note about the daylight time shift in US TZ happening this
Sunday.


2. What we completed this week:
=========================
* Release identification and release name
-----------------------------------------------
Release naming/identification new proposal is merged[2]. Currently, it is adding
the number in <year>.<1st or 2nd release of that year> format along with the release
name. Please check the release naming process page for complete detail[3]

* Add sushy-oem-idrac as Hardware Vendor SIG owned[4]


3. Activities In progress:
==================
TC Tracker for Yoga cycle
------------------------------
* This etherpad includes the Yoga cycle targets/working items for TC[5].
3 out of 9 items are completed and many are in progress.

Open Reviews
-----------------
* Six open reviews for ongoing activities[6].

Direction on running FIPs goal/jobs
------------------------------------------
As you might have seen the FIPs work from Ade_lee and adding FIPs jobs
in the check/gate pipeline which is not stable at this stage. We in TC meeting
along with Ade_lee discussed the direction on making jobs stable and until then
how we want to run jobs so that we do not overload infra resources with a lot of
non-voting/unstable jobs.

We agreed to run those as periodic (and experimental to trigger them manually) to
make/check their stability [7]. Based on the job run data, in PTG we will discuss further 
on adding them as voting and selecting it as a goal.
 
Zed cycle Leaderless projects
----------------------------------
We have 14 PTL assignments merged and 2 are in progress(Trove and Zaqar) [8]. With that
only one project left to assign a leader (Adjutant) and we will wait until the end of March for
Braden to get permission to maintain it[9].

PTG Preparation
--------------------
TC slots are selected for coming PTG[10], please continue adding the topics in etherpad[11].
* Monday 14 - 16 UTC (TC + PTL for 2 hrs )
* Thursday 13-17 UTC (TC discussion for 4 hrs)
* Friday 13-17 UTC (TC discussion for 4 hrs )

Dropping tags framework
------------------------------
part1 of this is merged[12], part-2 of updating release script and other tags
migration is under-progress.

TC position on release cadence
-------------------------------------
Dan has sent the overview and things changed as per the new release model [13]. The next plan is:

* Dan will explain/discuss it further in TC+PTL sessions on Monday [14].
* Projects can discuss it (from their project point of view) in their PTG sessions and collect the queries if any.
* Join TC sessions on Thursday/Friday (I will schedule and update the exact time slot) to discuss those
queries or plan the remaining work.

Fixing Zuul config error
----------------------------
Requesting projects with zuul config error to look into those and fix them which should
not take much time[15].

Project updates
-------------------
* None for this week.


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/+/829563
[3] https://governance.openstack.org/tc/reference/release-naming.html
[4] https://review.opendev.org/c/openstack/governance/+/832264
[5] https://etherpad.opendev.org/p/tc-yoga-tracker
[6] https://review.opendev.org/q/projects:openstack/governance+status:open
[7] https://meetings.opendev.org/meetings/tc/2022/tc.2022-03-10-15.00.log.html#l-145
[8] https://etherpad.opendev.org/p/zed-leaderless
[9] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027626.html
[10] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027584.html
[11] https://etherpad.opendev.org/p/tc-zed-ptg
[12] https://review.opendev.org/c/openstack/governance/+/822900
[13] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027639.html
[14] https://etherpad.opendev.org/p/tc-ptl-interaction-zed
[15] https://etherpad.opendev.org/p/zuul-config-error-openstack
[16] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[17] http://eavesdrop.openstack.org/#Technical_Committee_Meeting

-gmann

	


From laurentfdumont at gmail.com  Fri Mar 11 22:37:01 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Fri, 11 Mar 2022 17:37:01 -0500
Subject: [VICTORIA] Not working SNAT over VXLAN?
In-Reply-To: <CABNe=UvROiFnipaLCSJ+fzW7xo-JriuDWsdGJQnU5YMw3C0c6w@mail.gmail.com>
References: <CABNe=Utwt0dVuzzyCbVw63WoSr4s9w0kfUNkPLsDJp7fNt97mA@mail.gmail.com>
 <CAOAKi8wA=bk2v2iHZgQT6Yp2baEx40a8AytBbe2cJtF6gwL-6Q@mail.gmail.com>
 <CABNe=UvCDXmhx0iD9CHtKPpiuDe=cLjw-66a9oUNStMyGwxn0g@mail.gmail.com>
 <CAOAKi8zHqtkuNg=Wyhai0JajiJXweB00e38avnJULM2_YtS8xA@mail.gmail.com>
 <CABNe=UvROiFnipaLCSJ+fzW7xo-JriuDWsdGJQnU5YMw3C0c6w@mail.gmail.com>
Message-ID: <CAOAKi8wnduw+FZupKb8z8sZ6LeC10Wp+e-80fjkLeZCN0TC_NA@mail.gmail.com>

It's a bit hard to see without a diagram but here is my theory.

   - Packets from client-vm towards external endpoint exit from eth0.
   - Packets arrive to eth1 on router-vm and are allowed because
      - security-groups OK
      - mac-address + ip_address policy is only applicable to outgoing
      traffic (that's what I think for now...)
   - You have a SNAT in place for eth0.
   - Packets leave router-vm from eth0 with the source address becoming the
   IP of eth0. This is allowed because
      - security-groups OK
      - mac-address + ip_address policies are applied, but will match the
      packet since you are SNAT the traffic (and not just routing).
   - Packets arrive to ze-internet, traffic returns towards the router-vm.
   - Packets arrive to eth0, still valid.
   - Packets are processed by iptables which mangles the flow to correct
   the source IP to the source of the ze-internet.
   - Packets try to leave through eth1 but are now invalid because
      - security-groups OK
      - mac-address + ip_address policies are applied *but are now invalid.
      Source is ze-internet, which Openstack knows is not associated with eth1.*
      - If you tcpdump on eth1 of router-vm, you should see the traffic
   going out since it's before any filtering from ovs on the compute. Either
   ovs-flows are iptables are used for the actual filtering.


At least, that's what I think. I'll run some tests in the lab!
[image: image.png]

On Wed, Mar 9, 2022 at 4:51 AM Ga?l THEROND <gael.therond at bitswalk.com>
wrote:

> I?ve made few test this morning, disabling port security on the MGMT port
> of VM-A (bastion) indeed did the trick and the traffic started to flow
> correctly.
>
> I?ve then tested to enable it back and set the allowed_pairs with subnet,
> it works too, so the issue is definitely what you were pointing out so big
> shout out to you as this options is so deeply burried on the config/ui that
> I didn?t thought of it more than that.
>
> Yeah regarding k8s that what I was suspecting, thanks for the confirmation.
>
> However, there is one thing that I can?t get my head around with my simple
> router installation.
>
> If VM-X send a ping for let say google.com on its gateway (VM-A), the
> packet goes with VM-X mac/ip header, then VM-A thanks to the ip_forward
> know that this packet is belonging to another nic which is having the
> appropriate default gareway. At this point, we didn?t touched anything on
> the packet (to my knowledge) so once we reach the SNAT our packet header
> source IP is changed with the external router connected nic IP, then it
> flow through dns resolver that answer this IP, once the nic get this
> response, it just forward it back to the MGMT nic of the bastion which in
> turn answer to the VM-X mgmt nic without doing any spoofing etc.
>
> I?m feeling that I miss something on the way in here, what did I missed on
> this flow? At which step VM-A is breaking the law? At forward step?
>
> Le mer. 9 mars 2022 ? 03:20, Laurent Dumont <laurentfdumont at gmail.com> a
> ?crit :
>
>> Any overlay inside the vxlan overlay should work. Since it encapsulates
>> the actual pod/service traffic, Openstack has no clue and happily forwards
>> the traffic since it matches the spec (mac + IP) of the port.
>>
>> Using only security groups will not let you spoof traffic/act as a router.
>>
>>    - If you want to keep using security groups, you will need
>>    allowed-pairs.
>>       - You can use a subnet as a wildcard / or use the IP address
>>       specifically.
>>    - If you dont mind very permissive rules, then disabling
>>    port-security will require you to remove security groups + allowed-ip-pairs.
>>
>>
>> On Tue, Mar 8, 2022 at 4:59 PM Ga?l THEROND <gael.therond at bitswalk.com>
>> wrote:
>>
>>> Interesting I?ve thought about especially because of the anti-spoofing
>>> features but I had the feeling that Security-groups if assigned to the port
>>> would have allowed it.
>>>
>>> Additionally, what?s really weird is that one of our k8s clusters using
>>> flannel and/or calico (depends on the user needs) is actually putting those
>>> exact rules (SNAT+FORWARD rules) automatically for pods services ingress
>>> access but I?m wondering if it works because the traffic is on a tunnel
>>> that the host can?t see.
>>>
>>> I?ll have a look at your idea by disabling the port security and check
>>> if it work like that. If it works then I?ll re-enable it and work with the
>>> allowed-pairs.
>>>
>>> Many thanks!
>>>
>>> Le mar. 8 mars 2022 ? 22:13, Laurent Dumont <laurentfdumont at gmail.com>
>>> a ?crit :
>>>
>>>> You might want to look at port-security on the bastion host VM. If it's
>>>> enabled, it means that Openstack will drop any outgoing packets that are
>>>> not sourced using the ip address + mac AND/OR the allowed_pairs defined on
>>>> the port.
>>>>
>>>> On Tue, Mar 8, 2022 at 3:07 PM Ga?l THEROND <gael.therond at bitswalk.com>
>>>> wrote:
>>>>
>>>>> Hi everyone!
>>>>>
>>>>> I?m facing a weird situation on a tenant of one of our Openstack
>>>>> cluster based on Victoria.
>>>>>
>>>>> On this tenant, the network topology is as follow:
>>>>>
>>>>> One DMZ network (192.168.0.0/24) linked to our public network through
>>>>> a neutron router where there is a VM acting as a bastion/router for the
>>>>> MGMT network.
>>>>>
>>>>> One MGMT network (172.16.31.0/24) where all VMs are linked to.
>>>>>
>>>>> On the DMZ network, there is a linux Debian 11, let?s call it VM-A
>>>>> with a Floating IP from the public pool, this VM is both attached to the
>>>>> DMZ network (ens3 / 192.168.0.12) AND the MGMT network (ens4 /
>>>>> 172.16.31.23).
>>>>>
>>>>> All other VMs, let?s call them VM-X are exclusively attached to the
>>>>> MGMT network (ens4).
>>>>>
>>>>> I?ve setup VM-A with ip_forward kernel module and the following
>>>>> iptables rule:
>>>>>
>>>>> # iptables -t nat -A POSTROUTING -o ens3 -J SNAT ?to-source
>>>>> 192.168.0.12
>>>>>
>>>>> My VM-X are on their own setup with a default gateway via VM-A:
>>>>>
>>>>> # ip route add default via 172.31.16.23
>>>>>
>>>>> The setup seems to be working as if I don?t put the iptables rule and
>>>>> the kernel forwarding I can?t see any packets on my DMZ interface (ens3) on
>>>>> VM-A from VM-X.
>>>>>
>>>>> Ok so now that you get the whole schema, let dive into the issue.
>>>>>
>>>>> So when all rules, modules and gateway are set, I can fully see my
>>>>> VM-X traffic (ICMP ping to a dns server) going from VM-X (ens4) to VM-A
>>>>> (ens4) then forwarded to VM-A (ens3) and finally going to our public IP
>>>>> targeted service.
>>>>>
>>>>> What?s not working however is the response not reaching back to VM-X.
>>>>>
>>>>> I?ve tcpdump the whole traffic from VM-X to VM-A on each point of the
>>>>> platfrom:
>>>>>
>>>>> from inside the VM-X nic, on the tap device, on the qbr bridge, on the
>>>>> qvb veth, on the qvo second side of the veth through the ovs bridges and
>>>>> vice-versa.
>>>>>
>>>>> However the response packets aren?t reaching back further than on the
>>>>> VM-A qvo veth.
>>>>> Once it exit the VM-A the traffic never reaches the VM-X.
>>>>>
>>>>> What?s really suspicious in here is that a direct ping from VM-X
>>>>> (172.16.31.54) to VM-A (172.16.31.23) is coming back correctly, so it looks
>>>>> like if ovs detected that the response on a SNAT case isn?t legit or
>>>>> something similar.
>>>>>
>>>>> Is anyone able to get such setup working?
>>>>>
>>>>> Here are few additional information:
>>>>> Host runs on CentOS 8.5 latest update.
>>>>> Our platform is a Openstack Victoria deployed using kolla-ansible.
>>>>> We are using a OVS based deployment.
>>>>> Our tunnels are VXLAN.
>>>>> All VMs have a fully open secgroup applied and all ports have it (I
>>>>> checked it twice and even on host iptables).
>>>>>
>>>>> If you ever need additional information feel free to let me know !
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220311/d9c37c62/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 21446 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220311/d9c37c62/attachment-0001.png>

From gael.therond at bitswalk.com  Fri Mar 11 23:06:27 2022
From: gael.therond at bitswalk.com (=?UTF-8?Q?Ga=C3=ABl_THEROND?=)
Date: Sat, 12 Mar 2022 00:06:27 +0100
Subject: [VICTORIA] Not working SNAT over VXLAN?
In-Reply-To: <CAOAKi8wnduw+FZupKb8z8sZ6LeC10Wp+e-80fjkLeZCN0TC_NA@mail.gmail.com>
References: <CABNe=Utwt0dVuzzyCbVw63WoSr4s9w0kfUNkPLsDJp7fNt97mA@mail.gmail.com>
 <CAOAKi8wA=bk2v2iHZgQT6Yp2baEx40a8AytBbe2cJtF6gwL-6Q@mail.gmail.com>
 <CABNe=UvCDXmhx0iD9CHtKPpiuDe=cLjw-66a9oUNStMyGwxn0g@mail.gmail.com>
 <CAOAKi8zHqtkuNg=Wyhai0JajiJXweB00e38avnJULM2_YtS8xA@mail.gmail.com>
 <CABNe=UvROiFnipaLCSJ+fzW7xo-JriuDWsdGJQnU5YMw3C0c6w@mail.gmail.com>
 <CAOAKi8wnduw+FZupKb8z8sZ6LeC10Wp+e-80fjkLeZCN0TC_NA@mail.gmail.com>
Message-ID: <CABNe=UtQs-MVQUZ5bX2CgGe2W6RACjc-CJ94wDJ5RR1XvOVc1Q@mail.gmail.com>

I actually dig deeper and that?s exactly that, it?s filtered out by iptable
that get a special match rule when you don?t disable the security ports or
assign any allowed pairs :-)

TBN: Your explication and schema is perfect! I?ll use it to explain this to
my teammates that may face it at some point.

Le ven. 11 mars 2022 ? 23:37, Laurent Dumont <laurentfdumont at gmail.com> a
?crit :

> It's a bit hard to see without a diagram but here is my theory.
>
>    - Packets from client-vm towards external endpoint exit from eth0.
>    - Packets arrive to eth1 on router-vm and are allowed because
>       - security-groups OK
>       - mac-address + ip_address policy is only applicable to outgoing
>       traffic (that's what I think for now...)
>    - You have a SNAT in place for eth0.
>    - Packets leave router-vm from eth0 with the source address becoming
>    the IP of eth0. This is allowed because
>       - security-groups OK
>       - mac-address + ip_address policies are applied, but will match the
>       packet since you are SNAT the traffic (and not just routing).
>    - Packets arrive to ze-internet, traffic returns towards the router-vm.
>    - Packets arrive to eth0, still valid.
>    - Packets are processed by iptables which mangles the flow to correct
>    the source IP to the source of the ze-internet.
>    - Packets try to leave through eth1 but are now invalid because
>       - security-groups OK
>       - mac-address + ip_address policies are applied *but are now
>       invalid. Source is ze-internet, which Openstack knows is not associated
>       with eth1.*
>       - If you tcpdump on eth1 of router-vm, you should see the traffic
>    going out since it's before any filtering from ovs on the compute. Either
>    ovs-flows are iptables are used for the actual filtering.
>
>
> At least, that's what I think. I'll run some tests in the lab!
> [image: image.png]
>
> On Wed, Mar 9, 2022 at 4:51 AM Ga?l THEROND <gael.therond at bitswalk.com>
> wrote:
>
>> I?ve made few test this morning, disabling port security on the MGMT port
>> of VM-A (bastion) indeed did the trick and the traffic started to flow
>> correctly.
>>
>> I?ve then tested to enable it back and set the allowed_pairs with subnet,
>> it works too, so the issue is definitely what you were pointing out so big
>> shout out to you as this options is so deeply burried on the config/ui that
>> I didn?t thought of it more than that.
>>
>> Yeah regarding k8s that what I was suspecting, thanks for the
>> confirmation.
>>
>> However, there is one thing that I can?t get my head around with my
>> simple router installation.
>>
>> If VM-X send a ping for let say google.com on its gateway (VM-A), the
>> packet goes with VM-X mac/ip header, then VM-A thanks to the ip_forward
>> know that this packet is belonging to another nic which is having the
>> appropriate default gareway. At this point, we didn?t touched anything on
>> the packet (to my knowledge) so once we reach the SNAT our packet header
>> source IP is changed with the external router connected nic IP, then it
>> flow through dns resolver that answer this IP, once the nic get this
>> response, it just forward it back to the MGMT nic of the bastion which in
>> turn answer to the VM-X mgmt nic without doing any spoofing etc.
>>
>> I?m feeling that I miss something on the way in here, what did I missed
>> on this flow? At which step VM-A is breaking the law? At forward step?
>>
>> Le mer. 9 mars 2022 ? 03:20, Laurent Dumont <laurentfdumont at gmail.com> a
>> ?crit :
>>
>>> Any overlay inside the vxlan overlay should work. Since it encapsulates
>>> the actual pod/service traffic, Openstack has no clue and happily forwards
>>> the traffic since it matches the spec (mac + IP) of the port.
>>>
>>> Using only security groups will not let you spoof traffic/act as a
>>> router.
>>>
>>>    - If you want to keep using security groups, you will need
>>>    allowed-pairs.
>>>       - You can use a subnet as a wildcard / or use the IP address
>>>       specifically.
>>>    - If you dont mind very permissive rules, then disabling
>>>    port-security will require you to remove security groups + allowed-ip-pairs.
>>>
>>>
>>> On Tue, Mar 8, 2022 at 4:59 PM Ga?l THEROND <gael.therond at bitswalk.com>
>>> wrote:
>>>
>>>> Interesting I?ve thought about especially because of the anti-spoofing
>>>> features but I had the feeling that Security-groups if assigned to the port
>>>> would have allowed it.
>>>>
>>>> Additionally, what?s really weird is that one of our k8s clusters using
>>>> flannel and/or calico (depends on the user needs) is actually putting those
>>>> exact rules (SNAT+FORWARD rules) automatically for pods services ingress
>>>> access but I?m wondering if it works because the traffic is on a tunnel
>>>> that the host can?t see.
>>>>
>>>> I?ll have a look at your idea by disabling the port security and check
>>>> if it work like that. If it works then I?ll re-enable it and work with the
>>>> allowed-pairs.
>>>>
>>>> Many thanks!
>>>>
>>>> Le mar. 8 mars 2022 ? 22:13, Laurent Dumont <laurentfdumont at gmail.com>
>>>> a ?crit :
>>>>
>>>>> You might want to look at port-security on the bastion host VM. If
>>>>> it's enabled, it means that Openstack will drop any outgoing packets that
>>>>> are not sourced using the ip address + mac AND/OR the allowed_pairs defined
>>>>> on the port.
>>>>>
>>>>> On Tue, Mar 8, 2022 at 3:07 PM Ga?l THEROND <gael.therond at bitswalk.com>
>>>>> wrote:
>>>>>
>>>>>> Hi everyone!
>>>>>>
>>>>>> I?m facing a weird situation on a tenant of one of our Openstack
>>>>>> cluster based on Victoria.
>>>>>>
>>>>>> On this tenant, the network topology is as follow:
>>>>>>
>>>>>> One DMZ network (192.168.0.0/24) linked to our public network
>>>>>> through a neutron router where there is a VM acting as a bastion/router for
>>>>>> the MGMT network.
>>>>>>
>>>>>> One MGMT network (172.16.31.0/24) where all VMs are linked to.
>>>>>>
>>>>>> On the DMZ network, there is a linux Debian 11, let?s call it VM-A
>>>>>> with a Floating IP from the public pool, this VM is both attached to the
>>>>>> DMZ network (ens3 / 192.168.0.12) AND the MGMT network (ens4 /
>>>>>> 172.16.31.23).
>>>>>>
>>>>>> All other VMs, let?s call them VM-X are exclusively attached to the
>>>>>> MGMT network (ens4).
>>>>>>
>>>>>> I?ve setup VM-A with ip_forward kernel module and the following
>>>>>> iptables rule:
>>>>>>
>>>>>> # iptables -t nat -A POSTROUTING -o ens3 -J SNAT ?to-source
>>>>>> 192.168.0.12
>>>>>>
>>>>>> My VM-X are on their own setup with a default gateway via VM-A:
>>>>>>
>>>>>> # ip route add default via 172.31.16.23
>>>>>>
>>>>>> The setup seems to be working as if I don?t put the iptables rule and
>>>>>> the kernel forwarding I can?t see any packets on my DMZ interface (ens3) on
>>>>>> VM-A from VM-X.
>>>>>>
>>>>>> Ok so now that you get the whole schema, let dive into the issue.
>>>>>>
>>>>>> So when all rules, modules and gateway are set, I can fully see my
>>>>>> VM-X traffic (ICMP ping to a dns server) going from VM-X (ens4) to VM-A
>>>>>> (ens4) then forwarded to VM-A (ens3) and finally going to our public IP
>>>>>> targeted service.
>>>>>>
>>>>>> What?s not working however is the response not reaching back to VM-X.
>>>>>>
>>>>>> I?ve tcpdump the whole traffic from VM-X to VM-A on each point of the
>>>>>> platfrom:
>>>>>>
>>>>>> from inside the VM-X nic, on the tap device, on the qbr bridge, on
>>>>>> the qvb veth, on the qvo second side of the veth through the ovs bridges
>>>>>> and vice-versa.
>>>>>>
>>>>>> However the response packets aren?t reaching back further than on the
>>>>>> VM-A qvo veth.
>>>>>> Once it exit the VM-A the traffic never reaches the VM-X.
>>>>>>
>>>>>> What?s really suspicious in here is that a direct ping from VM-X
>>>>>> (172.16.31.54) to VM-A (172.16.31.23) is coming back correctly, so it looks
>>>>>> like if ovs detected that the response on a SNAT case isn?t legit or
>>>>>> something similar.
>>>>>>
>>>>>> Is anyone able to get such setup working?
>>>>>>
>>>>>> Here are few additional information:
>>>>>> Host runs on CentOS 8.5 latest update.
>>>>>> Our platform is a Openstack Victoria deployed using kolla-ansible.
>>>>>> We are using a OVS based deployment.
>>>>>> Our tunnels are VXLAN.
>>>>>> All VMs have a fully open secgroup applied and all ports have it (I
>>>>>> checked it twice and even on host iptables).
>>>>>>
>>>>>> If you ever need additional information feel free to let me know !
>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220312/85b80ba9/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 21446 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220312/85b80ba9/attachment-0001.png>

From vikarnatathe at gmail.com  Sat Mar 12 14:13:52 2022
From: vikarnatathe at gmail.com (Vikarna Tathe)
Date: Sat, 12 Mar 2022 19:43:52 +0530
Subject: nvidia gpu
In-Reply-To: <e7992872-5802-76dc-a617-9dd462447bd0@iphc.cnrs.fr>
References: <CAE2S1+6DCrogC3=vXSkFmnXNvo22qxiZ8ittkPg23XgwOWffUQ@mail.gmail.com>
 <e7992872-5802-76dc-a617-9dd462447bd0@iphc.cnrs.fr>
Message-ID: <CAE2S1+7xWq-OEwsLHQaUdqyS51ipENWo5ffAb-ATArOntdGHNA@mail.gmail.com>

Thanks Jerome.

I followed the last link and it worked. The only addition I did was add the
PCI ids to grub.

Vikarna

On Thu, 3 Mar 2022 at 13:38, Jerome Pansanel <jerome.pansanel at iphc.cnrs.fr>
wrote:

> Dear Virkana,
>
> There is an official documentation here:
>
> https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/wallaby/app-pci-passthrough-gpu.html
>
> Here are additional links:
> *
>
> https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/wallaby/app-pci-passthrough-gpu.html
> * https://gist.github.com/claudiok/890ab6dfe76fa45b30081e58038a9215
>
> Best,
>
> Jerome
>
> Le 03/03/2022 ? 05:07, Vikarna Tathe a ?crit :
> > Hello All,
> >
> > Can somebody help me with the procedure for GPU integration with
> > openstack wallaby, Ubuntu 20.04.
> >
> > Below are the card details:
> > da:00.0 VGA compatible controller: NVIDIA Corporation TU102GL [Quadro
> > RTX 6000/8000]
> >
> > Vikarna
>
>
> --
> Jerome Pansanel, PhD
> Technical Director at IPHC
> Technical Coordinator at France Grilles
> Head of Scientific Cloud Infrastructure (SCIGNE) at IPHC
> IPHC                        ||  GSM: +33 (0)6 25 19 24 43
> 23 rue du Loess, BP 28      ||  Tel: +33 (0)3 88 10 66 24
> F-67037 STRASBOURG Cedex 2  ||  Fax: +33 (0)3 88 10 62 34
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220312/fe36cee4/attachment.htm>

From tkajinam at redhat.com  Mon Mar 14 01:28:16 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Mon, 14 Mar 2022 10:28:16 +0900
Subject: [puppet] Proposing core team clean up
Message-ID: <CAL_crJS5OeWhbJ3RcgKTZ9ENHfpNZRy1ZQdzDXRKx=unRJiV-A@mail.gmail.com>

Hello,


I went through the current core reviewers and found out that the current
list includes
some people no longer working in the OpenStack community.

I'd like to propose removing the following persons from the core reviewer
team
as we haven't seen these people making any activity in the community
recently.

* Pradeep Kilambi
 - puppet-aodh, puppet-ceilometer, puppet-gnocchi, puppet-panko

* Richard Megginson
 - puppet-keystone

* Denis Egorenko
 - puppet-murano

* Serg Melikyan
 - puppet-murano

* Sergey Kolekonov
 - puppet-neutron

* David Moreau Simard
 - puppet-openstack-integration

* Yu xingchao
 - all modules

Also, I confirmed that Wes Hayutin is no longer working for OpenStack and
he agreed
to retire from the core reviewer position. Thus I'll remove him as well.

I'll be open for any feedback for one week to hear any thoughts/feedback
about this removal.

I'd like to take this moment to thank all people for their past work.
We always welcome them back if they resume their work in this project.

Thank you,
Takashi KAJINAMI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220314/11a48370/attachment.htm>

From kkchn.in at gmail.com  Mon Mar 14 08:28:27 2022
From: kkchn.in at gmail.com (KK CHN)
Date: Mon, 14 Mar 2022 13:58:27 +0530
Subject: virt-v2v conversion error
Message-ID: <CAKgGyB8vxwCB8=xzQSGTQHqkDXkrWaMGmCPpmOYyry99SyDysw@mail.gmail.com>

Hi ,

I am performing a migration of Windows 10 VM running on HyperV to OpenStack
setup with Ussuri(qemu KVM) on Debian 10 nodes.

I got the Windows VM exported disks as    disk1.VHDX and disk2.avhdx files
from my WIndows cloud Vendor.

1. As my understanding  I need to convert these VM disks from HyperV using
virt-v2v  tool.  ( Could someone explain what is the relevance of this step
and is it mandatory for importing it to  my Ussuri Openstack cloud which
uses qemu-kvm hypervisor.

2.  As I've read   I tried to convert this   disk1.VHDX file with the
follwoing step

#virt-v2v -i disk disk1.VHDX -o local -os /home/cloud

this step fails with virt-v2v error :

// Files system was mounted read only . even though we sked for it to be
mounted read-write. This usually means that file system was not cleanly
unmounted. Possible causes include trying to convert a guest which is
running. or use Windows hibernation or Fast Restart .
Original error message touch: open /8imepyi7: Read only file system ...

Can anyone guide what causes this error and Is there a fix or work around
available to solve this error in vrit-v2v conversion ?

Thanks in advance
krish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220314/7b5b0175/attachment.htm>

From dpawlik at redhat.com  Mon Mar 14 09:58:39 2022
From: dpawlik at redhat.com (Daniel Pawlik)
Date: Mon, 14 Mar 2022 10:58:39 +0100
Subject: Opensearch service reinstallation - opensearch.logs.openstack.org
In-Reply-To: <CAEZjfK7zBeO1pMywEfe7GPoVkCPQ9x3HFApr=4reahZazLgLtg@mail.gmail.com>
References: <CAEZjfK7zBeO1pMywEfe7GPoVkCPQ9x3HFApr=4reahZazLgLtg@mail.gmail.com>
Message-ID: <CAEZjfK73x0b3mds8fC1bs8=gg-2BYv4wM9JAuTUiUkq=XLrV=g@mail.gmail.com>

Hello,

The reinstallation completed successfully.
Currently the Opensearch service is indexing basic job results logs. In the
future, other logs
will be included [1].
If you would like to check the current state of that service, you can use
this url [2].
Credentials for readonly user are:

    username: openstack
    password: openstack
    tenant: global

If someone is interested in improving the log workflow tools, feel free to
contribute to the
openstack/ci-log-processing project [3].

Dan

[1] https://review.opendev.org/c/openstack/ci-log-processing/+/833011
[2]
https://opensearch.logs.openstack.org/_dashboards/app/discover/?security_tenant=global
[3] https://review.opendev.org/q/project:openstack%252Fci-log-processing

On Thu, Mar 10, 2022 at 2:48 PM Daniel Pawlik <dpawlik at redhat.com> wrote:

> Hi,
>
> We plan to reinstall the Opensearch (opensearch.logs.openstack.org)
> service on
> Saturday, 2021-03-12.
> The service will be unavailable for several hours.
>
> If someone has any concerns, please contact me.
>
> Regards,
> Dan
>


-- 
Regards,
Daniel Pawlik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220314/a9955335/attachment.htm>

From amonster369 at gmail.com  Mon Mar 14 10:11:14 2022
From: amonster369 at gmail.com (A Monster)
Date: Mon, 14 Mar 2022 11:11:14 +0100
Subject: VM instances too slow
Message-ID: <CAEc0ziuidyFbzFreb1++3ELKiB9SZs2fu+V-kGY4Byemwa0eOw@mail.gmail.com>

After deploying openstack using Kolla ansible, the vm instances are too
slow
I'm using one node as controller and two nodes for compute
Nodes have 64GB ram and two intel xeon e5 2660 CPUs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220314/bb4a666c/attachment-0001.htm>

From stephenfin at redhat.com  Mon Mar 14 12:07:31 2022
From: stephenfin at redhat.com (Stephen Finucane)
Date: Mon, 14 Mar 2022 12:07:31 +0000
Subject: [release] Independent release jobs are still using old release
 job templates
In-Reply-To: <20220311133803.l3rpuxb3k232nk7s@yuggoth.org>
References: <bf15986abdd062c6d97fe09d0656ffe9e584274b.camel@redhat.com>
 <20220311133803.l3rpuxb3k232nk7s@yuggoth.org>
Message-ID: <aec491434d8a61aa0fdf182a9ea3df89a5b23635.camel@redhat.com>

On Fri, 2022-03-11 at 13:38 +0000, Jeremy Stanley wrote:
> On 2022-03-11 12:26:38 +0000 (+0000), Stephen Finucane wrote:
> [...]
> > These initially caught me off-guard since I'm used to seeing a bot
> > propose these changes but I've realized that all affected projects
> > are using the "independent" release process and therefore don't
> > receive a new stable branch nor related bot-proposed commits.
> [...]
> 
> It's more than this, the "independent" release model definition is
> that projects have opted out of central release management entirely:
> 
> https://releases.openstack.org/reference/release_models.html#independent
> 
> If you want the OpenStack release managers coordinating cycle
> activities for those projects, I suspect we may need to redefine the
> relationship there.

Yes, this would be a big disadvantage of the second option I proposed. I suspect
"option A" will allow us to maintain the existing relationship with the sole
change of "we can now potentially break your project's CI when we bump the
runtimes used by the unversioned job template at the start of a cycle (but you
can opt out by using the versioned job templates)". This seems a reasonably
uncontroversial change from my perspective, particularly given the alternatives.

Stephen



From thierry at openstack.org  Mon Mar 14 12:42:43 2022
From: thierry at openstack.org (Thierry Carrez)
Date: Mon, 14 Mar 2022 13:42:43 +0100
Subject: [largescale-sig] Next meeting: Mar 16th, 15utc
Message-ID: <4b409c02-f496-abd7-912f-42c4d41214d3@openstack.org>

Hi everyone,

The Large Scale SIG will be meeting this Wednesday in 
#openstack-operators on OFTC IRC, at 15UTC.

Note that this means the meeting is one hour later than usual for people 
based in the US! You can doublecheck how that time translates locally at:
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20220316T15

Feel free to add topics to the agenda:
https://etherpad.openstack.org/p/large-scale-sig-meeting

Regards,

-- 
Thierry Carrez


From hberaud at redhat.com  Mon Mar 14 13:50:06 2022
From: hberaud at redhat.com (Herve Beraud)
Date: Mon, 14 Mar 2022 14:50:06 +0100
Subject: [release] Independent release jobs are still using old release
 job templates
In-Reply-To: <aec491434d8a61aa0fdf182a9ea3df89a5b23635.camel@redhat.com>
References: <bf15986abdd062c6d97fe09d0656ffe9e584274b.camel@redhat.com>
 <20220311133803.l3rpuxb3k232nk7s@yuggoth.org>
 <aec491434d8a61aa0fdf182a9ea3df89a5b23635.camel@redhat.com>
Message-ID: <CAFDq9gVaM-4s2u9viRX4jXSMgyPQCFMtYY-tWoWdGNQ23U4jWQ@mail.gmail.com>

Hello,

For now +1 for the option A.

The goal of moving those Oslo deliverables as independent deliverables was
to reduce our workload so instead of voting for a time consuming option
(the option B) I'd rather suggest an option C that would be moving back
those deliverables as coordinated deliverables.

This is not the first time that switching those deliverables to the
independent model causes us problems.

Thoughts?



Le lun. 14 mars 2022 ? 13:08, Stephen Finucane <stephenfin at redhat.com> a
?crit :

> On Fri, 2022-03-11 at 13:38 +0000, Jeremy Stanley wrote:
> > On 2022-03-11 12:26:38 +0000 (+0000), Stephen Finucane wrote:
> > [...]
> > > These initially caught me off-guard since I'm used to seeing a bot
> > > propose these changes but I've realized that all affected projects
> > > are using the "independent" release process and therefore don't
> > > receive a new stable branch nor related bot-proposed commits.
> > [...]
> >
> > It's more than this, the "independent" release model definition is
> > that projects have opted out of central release management entirely:
> >
> > https://releases.openstack.org/reference/release_models.html#independent
> >
> > If you want the OpenStack release managers coordinating cycle
> > activities for those projects, I suspect we may need to redefine the
> > relationship there.
>
> Yes, this would be a big disadvantage of the second option I proposed. I
> suspect
> "option A" will allow us to maintain the existing relationship with the
> sole
> change of "we can now potentially break your project's CI when we bump the
> runtimes used by the unversioned job template at the start of a cycle (but
> you
> can opt out by using the versioned job templates)". This seems a reasonably
> uncontroversial change from my perspective, particularly given the
> alternatives.
>
> Stephen
>
>
>

-- 
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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220314/deff617a/attachment.htm>

From johnsomor at gmail.com  Mon Mar 14 15:27:26 2022
From: johnsomor at gmail.com (Michael Johnson)
Date: Mon, 14 Mar 2022 08:27:26 -0700
Subject: VM instances too slow
In-Reply-To: <CAEc0ziuidyFbzFreb1++3ELKiB9SZs2fu+V-kGY4Byemwa0eOw@mail.gmail.com>
References: <CAEc0ziuidyFbzFreb1++3ELKiB9SZs2fu+V-kGY4Byemwa0eOw@mail.gmail.com>
Message-ID: <CAMH0MgJNXUFHbXSK2t1wAa7ChsTk=GKPXQf=k66H3wEuwrok9g@mail.gmail.com>

I don't have a direct answer, but something you should check.

On your compute host with a slow VM, do a process list, find the qemu
process for the VM(s) and check the "accel=" setting on the command
line. If it is "accel=tcg" you are running your VMs under software
emulation and they will be slow. You want to see "accel=kvm" on the
qemu processes.

If you have tcg, you need to set up your hosts for kvm. This may
include BIOS settings to enable the hardware virtualization features
of your processor/platform.
Refer to your host operating system documentation for the required
steps to enable KVM.

Michael

On Mon, Mar 14, 2022 at 3:18 AM A Monster <amonster369 at gmail.com> wrote:
>
> After deploying openstack using Kolla ansible, the vm instances are too slow
> I'm using one node as controller and two nodes for compute
> Nodes have 64GB ram and two intel xeon e5 2660 CPUs.


From alex.kavanagh at canonical.com  Mon Mar 14 15:42:46 2022
From: alex.kavanagh at canonical.com (Alex Kavanagh)
Date: Mon, 14 Mar 2022 15:42:46 +0000
Subject: [charms] Can we update the Python runtimes for the
 'openstack-python3-charms-jobs' template?
In-Reply-To: <11826ff2555e322d9d4022440d2065fabf53593e.camel@redhat.com>
References: <11826ff2555e322d9d4022440d2065fabf53593e.camel@redhat.com>
Message-ID: <CAO3V+OmN34RwJGqcWeVXB61FJJDUX-dgnkV12bMMwzcX4Ge67A@mail.gmail.com>

Hi Stephen

Your email/patch comes at an interesting moment for us.  We currently
updating our charms from a time-series release, which happens just after
the main OpenStack releases, to an OpenStack version released charm.  e.g.
in April we would 'normally' have released a charm set called 22.04 which
covered everything from bionic-queens (really!) to focal/jammy-yoga.
Instead, we will be releasing a 'yoga' release of the charms set, that
supports focal-wallaby, focal-yoga and jammy-yoga.

Therefore:

> That is, the 'openstack-python3-charms-jobs' release will now be updated
at the start of each new
release to test against the same runtimes proposed for this new release.

This will be ideal for the charms project, I think.  This means that the
next cycle of charms will support the runtimes that the next cycle of
OpenStack supports, which in principle lines up nicely.  The only caveat is
that each release of charms needs to support the previous release (from an
upgrade perspective) which makes it a little more complex to consider -
e.g. ussuri 'straddles' bionic and focal, so would need to test against
py36, py37, py38.

I'll add some comments to the review.  Thanks very much for raising this,
and for the patch going forward.

Cheers
Alex.






On Fri, Mar 11, 2022 at 12:39 PM Stephen Finucane <stephenfin at redhat.com>
wrote:

> Related to the "Independent release jobs are still using old release job
> templates" email I just sent [1], I've proposed a change [2] that would
> modify
> the 'openstack-python3-charms-jobs' job template so that it mimics the
> behaviour
> of the proposed 'openstack-python3-jobs' template. That is, the 'openstack-
> python3-charms-jobs' release will now be updated at the start of each new
> release to test against the same runtimes proposed for this new release.
> However, frickler has noted that the use of older runtimes for the charms
> jobs
> may in fact be intentional. Could someone from the charms team please
> weigh in
> on [2]. If this is in fact intentional, it would be good to add a note to
> the
> job template indicating this fact to prevent people like me breaking it in
> the
> future :)
>
> Cheers,
> Stephen
>
> [1]
> http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027676.html
> [2] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833330/1
>
>
>

-- 
Alex Kavanagh - Software Engineer
OpenStack Engineering - Data Centre Development - Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220314/6d5ac1dc/attachment-0001.htm>

From zigo at debian.org  Mon Mar 14 16:10:04 2022
From: zigo at debian.org (Thomas Goirand)
Date: Mon, 14 Mar 2022 17:10:04 +0100
Subject: VM instances too slow
In-Reply-To: <CAEc0ziuidyFbzFreb1++3ELKiB9SZs2fu+V-kGY4Byemwa0eOw@mail.gmail.com>
References: <CAEc0ziuidyFbzFreb1++3ELKiB9SZs2fu+V-kGY4Byemwa0eOw@mail.gmail.com>
Message-ID: <af7be784-5eeb-58f8-2292-849b2f9eae6d@debian.org>

On 3/14/22 11:11, A Monster wrote:
> After deploying openstack using Kolla ansible, the vm instances are too 
> slow
> I'm using one node as controller and two nodes for compute
> Nodes have 64GB ram and two intel xeon e5 2660 CPUs.

Hi,

I believe the right answer is: OpenStack has no relationship with the 
slowness of your VMs. The only thing it does is spawning KVM/Qemu 
processes, that's all. So if your server is slow, VMs are slow. Are you 
sure you've enabled KVM though, and that you're not just running with 
Qemu instead?

Cheers,

Thomas Goirand (zigo)


From kennelson11 at gmail.com  Mon Mar 14 19:40:00 2022
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Mon, 14 Mar 2022 12:40:00 -0700
Subject: Forum Brainstorming & Committee Setup
Message-ID: <CAJ6yrQi-55g6LEJZNwfsptk9nBQixRd1SJv-tQsYgS=+-J0a-g@mail.gmail.com>

Hello Everyone!

As the OpenInfra Summit approaches, so does the Forum!  We would love 1
volunteer from the community for the Forum Selection Committee.  Ideally,
the volunteer would already be serving in some capacity in a governance
role for your project.

Please reach out to knelson at openinfra.dev if you're interested. Volunteers
should respond on or before April 8, 2022.

In addition to calling for volunteers for the Forum selection committee,
this email kicks off the brainstorming period before the CFP tool opens for
formal Forum submissions. The categories for brainstorming etherpads have
already been setup here[1].  Please add your etherpads and ideas there!

The CFP tool will open on March 21st and will close April 8th.

For information on the upcoming Summit[2].
For more information on the Forum[3].

Thanks!
- Kendall Nelson (diablo_rojo)

[1] Forum 2022 Wiki: https://wiki.openstack.org/wiki/Forum/Berlin2022
[2] OpenInfra Summit Site:  https://openinfra.dev/summit
[3] General Forum Wiki: https://wiki.openstack.org/wiki/Forum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220314/c96bc067/attachment.htm>

From laurentfdumont at gmail.com  Mon Mar 14 21:48:57 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Mon, 14 Mar 2022 17:48:57 -0400
Subject: VM instances too slow
In-Reply-To: <CAEc0ziuidyFbzFreb1++3ELKiB9SZs2fu+V-kGY4Byemwa0eOw@mail.gmail.com>
References: <CAEc0ziuidyFbzFreb1++3ELKiB9SZs2fu+V-kGY4Byemwa0eOw@mail.gmail.com>
Message-ID: <CAOAKi8w4mQUebUHQoQmH-ModLgtoW-8cC=W+evZix8TWZRKuug@mail.gmail.com>

Slow could mean a lot of things :

   - Are you seeing a lot of CPU usage?
   - Is it disk IO?
   - Is it RAM usage saturation leading to swap usage? (even if you should
   not really have a swap for a VM)


On Mon, Mar 14, 2022 at 6:13 AM A Monster <amonster369 at gmail.com> wrote:

> After deploying openstack using Kolla ansible, the vm instances are too
> slow
> I'm using one node as controller and two nodes for compute
> Nodes have 64GB ram and two intel xeon e5 2660 CPUs.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220314/9abb7114/attachment.htm>

From hiwkby at yahoo.com  Tue Mar 15 00:28:52 2022
From: hiwkby at yahoo.com (Hirotaka Wakabayashi)
Date: Tue, 15 Mar 2022 00:28:52 +0000 (UTC)
Subject: [dev][trove] Self-introduction and request to merge PRs
References: <453135864.1607721.1647304132753.ref@mail.yahoo.com>
Message-ID: <453135864.1607721.1647304132753@mail.yahoo.com>

Hello, I am Hirotaka Wakabayashi from Tokyo. This is my first post to
openstack-discuss.

My goal in OpenStack Project is to learn the OpenStack Infrastructures anddevelop them together and to enlarge the community in Japan if I could.
I am a software engineer. In this 10 years, I have been a backend developer
in Yahoo Japan Corporation. I have been using FreeBSD, Fedora-based Linux
Distros. I mostly use C/C++ and sometime use python recently.

I am a Trove contributor from two years ago and I submitted the following 
PRs? last week, but does anybody kindly merge them? I think they are verysmall code changes and easy to understand, but the #832786 and #833497are very important to make Trove on master branch work correctly.

https://review.opendev.org/c/openstack/trove/+/832786
https://review.opendev.org/c/openstack/trove-dashboard/+/833497
https://review.opendev.org/c/openstack/trove/+/833361
https://review.opendev.org/c/openstack/trove/+/833501

I asked to merge them in #openstack-trove yesterday, but I got no response.
So I posted this email here. Any questions are welcome!

Thanks in advance,
Hirotaka Wakabayashi

GPG Key UID: "Hirotaka Wakabayashi <hiwkby at yahoo.com>"
GPG fingerprint: "3F54 9D91 A73A 1F31 8CA8? 8A9F 050F 5312 F0D7 DBCD"


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220315/f94cbdce/attachment.htm>

From gmann at ghanshyammann.com  Tue Mar 15 02:48:46 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 14 Mar 2022 21:48:46 -0500
Subject: [all][tc] Technical Committee next weekly meeting on Mar 17th at
 1500 UTC
Message-ID: <17f8b7a5e4e.dced0167214057.6183832161093575525@ghanshyammann.com>

Hello Everyone,

Technical Committee's next weekly meeting is scheduled for Mar 17th at 1500 UTC.

If you would like to add topics for discussion, please add them to the below wiki page by
Wednesday, Mar 16th, at 2100 UTC.

https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

-gmann



From stephenfin at redhat.com  Tue Mar 15 10:56:03 2022
From: stephenfin at redhat.com (Stephen Finucane)
Date: Tue, 15 Mar 2022 10:56:03 +0000
Subject: [release] Independent release jobs are still using old release
 job templates
In-Reply-To: <ea43bbe6-4ae9-0e77-2f7b-a47c97ade6eb@est.tech>
References: <bf15986abdd062c6d97fe09d0656ffe9e584274b.camel@redhat.com>
 <ea43bbe6-4ae9-0e77-2f7b-a47c97ade6eb@est.tech>
Message-ID: <d5c43febc70797b4b42bb4ca62eb8ee0bd64dc96.camel@redhat.com>

On Fri, 2022-03-11 at 17:13 +0100, El?d Ill?s wrote:
> Thanks for bringing this up Stephen! I am not aware of such discussions, 
> though i might missed it only.
> 
> So this is about projects with 'independent release model' and their CI 
> jobs. I think it's a valid question and we should solve this somehow.
> 
> I could also imagine a new task in our release process / schedule, when the
> release team generates the new patches via some new scripts (which is 
> somewhat identical to your second option). This has the risk though that these 
> kind of patches just linger around without anyone reviewing / fixing / merging them
> (similarly like the .gitreview and TOX_CONSTRAINTS_FILE patches, which 
> should be merged as soon as possible, but in lots of projects they just remain 
> there open forever, causing errors time to time). Considering this, maybe the 2nd
> option is better but what you wrote as CON regarding special (ie. semver)
> stable branches could be really problematic (I don't know actually, so 
> we need to ask for opinions from those projects that have such stable branches 
> in their projects with independent release model).

I've thought about this more, and I don't think the issue with the special
stable branches is actually a big issue. Firstly, I've no evidence that such
things even exist so it's likely a purely theoretical issue at this point.
However, assuming these branches _do_ exist, they would have to be created
manually. There's no reason that the '.zuul.yaml' file couldn't be modified
after this was done to use the job template from the current release (i.e.
'openstack-python3-zed-jobs'), ensuring things would age gracefully. If we have
"how to request manual stable branch creation" docs somewhere, then we could
simply note this there.

I think the unversioned job is definitely the way to go now. I just need another
approver for [1] to move forward with it.

Stephen

[1] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833286

> 
> Thanks,
> 
> El?d
> 
> On 2022. 03. 11. 13:26, Stephen Finucane wrote:
> > tl;dr: How do we get projects using the independent release process to use the
> > openstack-python3 zuul job template corresponding to the latest release? I've
> > noticed a couple of patches like [1] popping up for oslo-affiliated projects.
> > These projects are currently using the python3 zuul job templates corresponding
> > to an older release (e.g. Wallaby) and the author is correctly updating them to
> > use the most recent release. These initially caught me off-guard since I'm used
> > to seeing a bot propose these changes but I've realized that all affected
> > projects are using the "independent" release process and therefore don't receive
> > a new stable branch nor related bot-proposed commits. This leaves us in a bit of
> > a pickle though. There are a lot of projects using this release process, and
> > there's effectively zero chance that someone is going to remember to bump the
> > jobs every single release.
> > 
> > While some could argue that this is "working as designed", it seems important to
> > me that we would be testing these projects against the supported runtimes for
> > the release currently under development. As such, how should we try to address
> > this? One option I see is to add a new generic 'openstack-python3-jobs' template
> > which would always duplicate the jobs used for the current release. I've
> > proposed that here [2]. There are some pros and cons to this approach:
> > 
> >   * PRO: Minimal effort from everyone.
> >   * CON: The HEAD of master for each project could be broken and we'd never know
> >     until some change was proposed to master (note: this is effectively the
> >     status quo right now, so it's not a big break)
> >   * CON: If those independent projects had an alternative to stable branches
> >     (i.e. semver branches), those would eventually break as the runtimes kept
> >     changing.
> > 
> > The other option is to extend the openstack bot to propose release bump patches
> > against these independent projects. This has the inverse pro/con balance:
> > 
> >   * PRO: We get a regular "check-up" on the health of the project whenever these
> >     patches are proposed.
> >   * PRO: Long-lived stable branches should stay working
> >   * CON: Lots of busy work for reviewers.
> > 
> > What are everyone's thoughts? I'm in favour of the first approach (generic
> > 'openstack-python3-jobs' template) but the bot enhancement would also wfm. If we
> > go with the first approach, we'd probably want to script something to "fix" all
> > the existing independent projects rather than attempt to find and fix them
> > manually.
> > 
> > Cheers,
> > Stephen
> > 
> > PS: Apologies if this has been discussed previously. I clearly missed that
> > discussion.
> > 
> > [1] https://review.opendev.org/c/openstack/os-api-ref/+/831560
> > [2] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833286
> > 
> > 



From laurentfdumont at gmail.com  Sun Mar 13 21:09:34 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Sun, 13 Mar 2022 17:09:34 -0400
Subject: [VICTORIA] Not working SNAT over VXLAN?
In-Reply-To: <CABNe=UtQs-MVQUZ5bX2CgGe2W6RACjc-CJ94wDJ5RR1XvOVc1Q@mail.gmail.com>
References: <CABNe=Utwt0dVuzzyCbVw63WoSr4s9w0kfUNkPLsDJp7fNt97mA@mail.gmail.com>
 <CAOAKi8wA=bk2v2iHZgQT6Yp2baEx40a8AytBbe2cJtF6gwL-6Q@mail.gmail.com>
 <CABNe=UvCDXmhx0iD9CHtKPpiuDe=cLjw-66a9oUNStMyGwxn0g@mail.gmail.com>
 <CAOAKi8zHqtkuNg=Wyhai0JajiJXweB00e38avnJULM2_YtS8xA@mail.gmail.com>
 <CABNe=UvROiFnipaLCSJ+fzW7xo-JriuDWsdGJQnU5YMw3C0c6w@mail.gmail.com>
 <CAOAKi8wnduw+FZupKb8z8sZ6LeC10Wp+e-80fjkLeZCN0TC_NA@mail.gmail.com>
 <CABNe=UtQs-MVQUZ5bX2CgGe2W6RACjc-CJ94wDJ5RR1XvOVc1Q@mail.gmail.com>
Message-ID: <CAOAKi8wK4D=EPNJq8a70VyOCtRECZ6zcOPtnZktoio0VJc-aEA@mail.gmail.com>

Nice! I reread and meant to say that SNAT transforms the packets to take
the source of eth1, not eth0.

But the logic is the same.

It's worth mentioning that routers in Openstack essentially do that. But
they are a bit less flexible than a VM.

On Fri, Mar 11, 2022, 6:06 PM Ga?l THEROND <gael.therond at bitswalk.com>
wrote:

> I actually dig deeper and that?s exactly that, it?s filtered out by
> iptable that get a special match rule when you don?t disable the security
> ports or assign any allowed pairs :-)
>
> TBN: Your explication and schema is perfect! I?ll use it to explain this
> to my teammates that may face it at some point.
>
> Le ven. 11 mars 2022 ? 23:37, Laurent Dumont <laurentfdumont at gmail.com> a
> ?crit :
>
>> It's a bit hard to see without a diagram but here is my theory.
>>
>>    - Packets from client-vm towards external endpoint exit from eth0.
>>    - Packets arrive to eth1 on router-vm and are allowed because
>>       - security-groups OK
>>       - mac-address + ip_address policy is only applicable to outgoing
>>       traffic (that's what I think for now...)
>>    - You have a SNAT in place for eth0.
>>    - Packets leave router-vm from eth0 with the source address becoming
>>    the IP of eth0. This is allowed because
>>       - security-groups OK
>>       - mac-address + ip_address policies are applied, but will match
>>       the packet since you are SNAT the traffic (and not just routing).
>>    - Packets arrive to ze-internet, traffic returns towards the
>>    router-vm.
>>    - Packets arrive to eth0, still valid.
>>    - Packets are processed by iptables which mangles the flow to correct
>>    the source IP to the source of the ze-internet.
>>    - Packets try to leave through eth1 but are now invalid because
>>       - security-groups OK
>>       - mac-address + ip_address policies are applied *but are now
>>       invalid. Source is ze-internet, which Openstack knows is not associated
>>       with eth1.*
>>       - If you tcpdump on eth1 of router-vm, you should see the traffic
>>    going out since it's before any filtering from ovs on the compute. Either
>>    ovs-flows are iptables are used for the actual filtering.
>>
>>
>> At least, that's what I think. I'll run some tests in the lab!
>> [image: image.png]
>>
>> On Wed, Mar 9, 2022 at 4:51 AM Ga?l THEROND <gael.therond at bitswalk.com>
>> wrote:
>>
>>> I?ve made few test this morning, disabling port security on the MGMT
>>> port of VM-A (bastion) indeed did the trick and the traffic started to flow
>>> correctly.
>>>
>>> I?ve then tested to enable it back and set the allowed_pairs with
>>> subnet, it works too, so the issue is definitely what you were pointing out
>>> so big shout out to you as this options is so deeply burried on the
>>> config/ui that I didn?t thought of it more than that.
>>>
>>> Yeah regarding k8s that what I was suspecting, thanks for the
>>> confirmation.
>>>
>>> However, there is one thing that I can?t get my head around with my
>>> simple router installation.
>>>
>>> If VM-X send a ping for let say google.com on its gateway (VM-A), the
>>> packet goes with VM-X mac/ip header, then VM-A thanks to the ip_forward
>>> know that this packet is belonging to another nic which is having the
>>> appropriate default gareway. At this point, we didn?t touched anything on
>>> the packet (to my knowledge) so once we reach the SNAT our packet header
>>> source IP is changed with the external router connected nic IP, then it
>>> flow through dns resolver that answer this IP, once the nic get this
>>> response, it just forward it back to the MGMT nic of the bastion which in
>>> turn answer to the VM-X mgmt nic without doing any spoofing etc.
>>>
>>> I?m feeling that I miss something on the way in here, what did I missed
>>> on this flow? At which step VM-A is breaking the law? At forward step?
>>>
>>> Le mer. 9 mars 2022 ? 03:20, Laurent Dumont <laurentfdumont at gmail.com>
>>> a ?crit :
>>>
>>>> Any overlay inside the vxlan overlay should work. Since it encapsulates
>>>> the actual pod/service traffic, Openstack has no clue and happily forwards
>>>> the traffic since it matches the spec (mac + IP) of the port.
>>>>
>>>> Using only security groups will not let you spoof traffic/act as a
>>>> router.
>>>>
>>>>    - If you want to keep using security groups, you will need
>>>>    allowed-pairs.
>>>>       - You can use a subnet as a wildcard / or use the IP address
>>>>       specifically.
>>>>    - If you dont mind very permissive rules, then disabling
>>>>    port-security will require you to remove security groups + allowed-ip-pairs.
>>>>
>>>>
>>>> On Tue, Mar 8, 2022 at 4:59 PM Ga?l THEROND <gael.therond at bitswalk.com>
>>>> wrote:
>>>>
>>>>> Interesting I?ve thought about especially because of the anti-spoofing
>>>>> features but I had the feeling that Security-groups if assigned to the port
>>>>> would have allowed it.
>>>>>
>>>>> Additionally, what?s really weird is that one of our k8s clusters
>>>>> using flannel and/or calico (depends on the user needs) is actually putting
>>>>> those exact rules (SNAT+FORWARD rules) automatically for pods services
>>>>> ingress access but I?m wondering if it works because the traffic is on a
>>>>> tunnel that the host can?t see.
>>>>>
>>>>> I?ll have a look at your idea by disabling the port security and check
>>>>> if it work like that. If it works then I?ll re-enable it and work with the
>>>>> allowed-pairs.
>>>>>
>>>>> Many thanks!
>>>>>
>>>>> Le mar. 8 mars 2022 ? 22:13, Laurent Dumont <laurentfdumont at gmail.com>
>>>>> a ?crit :
>>>>>
>>>>>> You might want to look at port-security on the bastion host VM. If
>>>>>> it's enabled, it means that Openstack will drop any outgoing packets that
>>>>>> are not sourced using the ip address + mac AND/OR the allowed_pairs defined
>>>>>> on the port.
>>>>>>
>>>>>> On Tue, Mar 8, 2022 at 3:07 PM Ga?l THEROND <
>>>>>> gael.therond at bitswalk.com> wrote:
>>>>>>
>>>>>>> Hi everyone!
>>>>>>>
>>>>>>> I?m facing a weird situation on a tenant of one of our Openstack
>>>>>>> cluster based on Victoria.
>>>>>>>
>>>>>>> On this tenant, the network topology is as follow:
>>>>>>>
>>>>>>> One DMZ network (192.168.0.0/24) linked to our public network
>>>>>>> through a neutron router where there is a VM acting as a bastion/router for
>>>>>>> the MGMT network.
>>>>>>>
>>>>>>> One MGMT network (172.16.31.0/24) where all VMs are linked to.
>>>>>>>
>>>>>>> On the DMZ network, there is a linux Debian 11, let?s call it VM-A
>>>>>>> with a Floating IP from the public pool, this VM is both attached to the
>>>>>>> DMZ network (ens3 / 192.168.0.12) AND the MGMT network (ens4 /
>>>>>>> 172.16.31.23).
>>>>>>>
>>>>>>> All other VMs, let?s call them VM-X are exclusively attached to the
>>>>>>> MGMT network (ens4).
>>>>>>>
>>>>>>> I?ve setup VM-A with ip_forward kernel module and the following
>>>>>>> iptables rule:
>>>>>>>
>>>>>>> # iptables -t nat -A POSTROUTING -o ens3 -J SNAT ?to-source
>>>>>>> 192.168.0.12
>>>>>>>
>>>>>>> My VM-X are on their own setup with a default gateway via VM-A:
>>>>>>>
>>>>>>> # ip route add default via 172.31.16.23
>>>>>>>
>>>>>>> The setup seems to be working as if I don?t put the iptables rule
>>>>>>> and the kernel forwarding I can?t see any packets on my DMZ interface
>>>>>>> (ens3) on VM-A from VM-X.
>>>>>>>
>>>>>>> Ok so now that you get the whole schema, let dive into the issue.
>>>>>>>
>>>>>>> So when all rules, modules and gateway are set, I can fully see my
>>>>>>> VM-X traffic (ICMP ping to a dns server) going from VM-X (ens4) to VM-A
>>>>>>> (ens4) then forwarded to VM-A (ens3) and finally going to our public IP
>>>>>>> targeted service.
>>>>>>>
>>>>>>> What?s not working however is the response not reaching back to VM-X.
>>>>>>>
>>>>>>> I?ve tcpdump the whole traffic from VM-X to VM-A on each point of
>>>>>>> the platfrom:
>>>>>>>
>>>>>>> from inside the VM-X nic, on the tap device, on the qbr bridge, on
>>>>>>> the qvb veth, on the qvo second side of the veth through the ovs bridges
>>>>>>> and vice-versa.
>>>>>>>
>>>>>>> However the response packets aren?t reaching back further than on
>>>>>>> the VM-A qvo veth.
>>>>>>> Once it exit the VM-A the traffic never reaches the VM-X.
>>>>>>>
>>>>>>> What?s really suspicious in here is that a direct ping from VM-X
>>>>>>> (172.16.31.54) to VM-A (172.16.31.23) is coming back correctly, so it looks
>>>>>>> like if ovs detected that the response on a SNAT case isn?t legit or
>>>>>>> something similar.
>>>>>>>
>>>>>>> Is anyone able to get such setup working?
>>>>>>>
>>>>>>> Here are few additional information:
>>>>>>> Host runs on CentOS 8.5 latest update.
>>>>>>> Our platform is a Openstack Victoria deployed using kolla-ansible.
>>>>>>> We are using a OVS based deployment.
>>>>>>> Our tunnels are VXLAN.
>>>>>>> All VMs have a fully open secgroup applied and all ports have it (I
>>>>>>> checked it twice and even on host iptables).
>>>>>>>
>>>>>>> If you ever need additional information feel free to let me know !
>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220313/9495b37e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 21446 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220313/9495b37e/attachment-0001.png>

From gael.therond at bitswalk.com  Sun Mar 13 21:17:58 2022
From: gael.therond at bitswalk.com (=?UTF-8?Q?Ga=C3=ABl_THEROND?=)
Date: Sun, 13 Mar 2022 22:17:58 +0100
Subject: [VICTORIA] Not working SNAT over VXLAN?
In-Reply-To: <CAOAKi8wK4D=EPNJq8a70VyOCtRECZ6zcOPtnZktoio0VJc-aEA@mail.gmail.com>
References: <CABNe=Utwt0dVuzzyCbVw63WoSr4s9w0kfUNkPLsDJp7fNt97mA@mail.gmail.com>
 <CAOAKi8wA=bk2v2iHZgQT6Yp2baEx40a8AytBbe2cJtF6gwL-6Q@mail.gmail.com>
 <CABNe=UvCDXmhx0iD9CHtKPpiuDe=cLjw-66a9oUNStMyGwxn0g@mail.gmail.com>
 <CAOAKi8zHqtkuNg=Wyhai0JajiJXweB00e38avnJULM2_YtS8xA@mail.gmail.com>
 <CABNe=UvROiFnipaLCSJ+fzW7xo-JriuDWsdGJQnU5YMw3C0c6w@mail.gmail.com>
 <CAOAKi8wnduw+FZupKb8z8sZ6LeC10Wp+e-80fjkLeZCN0TC_NA@mail.gmail.com>
 <CABNe=UtQs-MVQUZ5bX2CgGe2W6RACjc-CJ94wDJ5RR1XvOVc1Q@mail.gmail.com>
 <CAOAKi8wK4D=EPNJq8a70VyOCtRECZ6zcOPtnZktoio0VJc-aEA@mail.gmail.com>
Message-ID: <CABNe=UuDdKYcpdtTWyoWFbaH0svyBYR97Q0yTWb3MuK5+_xNoA@mail.gmail.com>

Yeah, especially that you can?t use them for internal vxlan to vxlan
routing straight from horizon or without having higher knowledge to neutron
and using CLI, that honestly my users don?t have :-) I?m working on a
ansible skeleton that our business units devs could use ? easily ? for the
less infrastructure oriented.

I really think that vxlan to vxlan routing should be allowed right from
within horizon for the final users (non ops/admins).

Anyway! Thanks a lot!

Le dim. 13 mars 2022 ? 22:09, Laurent Dumont <laurentfdumont at gmail.com> a
?crit :

> Nice! I reread and meant to say that SNAT transforms the packets to take
> the source of eth1, not eth0.
>
> But the logic is the same.
>
> It's worth mentioning that routers in Openstack essentially do that. But
> they are a bit less flexible than a VM.
>
> On Fri, Mar 11, 2022, 6:06 PM Ga?l THEROND <gael.therond at bitswalk.com>
> wrote:
>
>> I actually dig deeper and that?s exactly that, it?s filtered out by
>> iptable that get a special match rule when you don?t disable the security
>> ports or assign any allowed pairs :-)
>>
>> TBN: Your explication and schema is perfect! I?ll use it to explain this
>> to my teammates that may face it at some point.
>>
>> Le ven. 11 mars 2022 ? 23:37, Laurent Dumont <laurentfdumont at gmail.com>
>> a ?crit :
>>
>>> It's a bit hard to see without a diagram but here is my theory.
>>>
>>>    - Packets from client-vm towards external endpoint exit from eth0.
>>>    - Packets arrive to eth1 on router-vm and are allowed because
>>>       - security-groups OK
>>>       - mac-address + ip_address policy is only applicable to outgoing
>>>       traffic (that's what I think for now...)
>>>    - You have a SNAT in place for eth0.
>>>    - Packets leave router-vm from eth0 with the source address becoming
>>>    the IP of eth0. This is allowed because
>>>       - security-groups OK
>>>       - mac-address + ip_address policies are applied, but will match
>>>       the packet since you are SNAT the traffic (and not just routing).
>>>    - Packets arrive to ze-internet, traffic returns towards the
>>>    router-vm.
>>>    - Packets arrive to eth0, still valid.
>>>    - Packets are processed by iptables which mangles the flow to
>>>    correct the source IP to the source of the ze-internet.
>>>    - Packets try to leave through eth1 but are now invalid because
>>>       - security-groups OK
>>>       - mac-address + ip_address policies are applied *but are now
>>>       invalid. Source is ze-internet, which Openstack knows is not associated
>>>       with eth1.*
>>>       - If you tcpdump on eth1 of router-vm, you should see the traffic
>>>    going out since it's before any filtering from ovs on the compute. Either
>>>    ovs-flows are iptables are used for the actual filtering.
>>>
>>>
>>> At least, that's what I think. I'll run some tests in the lab!
>>> [image: image.png]
>>>
>>> On Wed, Mar 9, 2022 at 4:51 AM Ga?l THEROND <gael.therond at bitswalk.com>
>>> wrote:
>>>
>>>> I?ve made few test this morning, disabling port security on the MGMT
>>>> port of VM-A (bastion) indeed did the trick and the traffic started to flow
>>>> correctly.
>>>>
>>>> I?ve then tested to enable it back and set the allowed_pairs with
>>>> subnet, it works too, so the issue is definitely what you were pointing out
>>>> so big shout out to you as this options is so deeply burried on the
>>>> config/ui that I didn?t thought of it more than that.
>>>>
>>>> Yeah regarding k8s that what I was suspecting, thanks for the
>>>> confirmation.
>>>>
>>>> However, there is one thing that I can?t get my head around with my
>>>> simple router installation.
>>>>
>>>> If VM-X send a ping for let say google.com on its gateway (VM-A), the
>>>> packet goes with VM-X mac/ip header, then VM-A thanks to the ip_forward
>>>> know that this packet is belonging to another nic which is having the
>>>> appropriate default gareway. At this point, we didn?t touched anything on
>>>> the packet (to my knowledge) so once we reach the SNAT our packet header
>>>> source IP is changed with the external router connected nic IP, then it
>>>> flow through dns resolver that answer this IP, once the nic get this
>>>> response, it just forward it back to the MGMT nic of the bastion which in
>>>> turn answer to the VM-X mgmt nic without doing any spoofing etc.
>>>>
>>>> I?m feeling that I miss something on the way in here, what did I missed
>>>> on this flow? At which step VM-A is breaking the law? At forward step?
>>>>
>>>> Le mer. 9 mars 2022 ? 03:20, Laurent Dumont <laurentfdumont at gmail.com>
>>>> a ?crit :
>>>>
>>>>> Any overlay inside the vxlan overlay should work. Since it
>>>>> encapsulates the actual pod/service traffic, Openstack has no clue and
>>>>> happily forwards the traffic since it matches the spec (mac + IP) of the
>>>>> port.
>>>>>
>>>>> Using only security groups will not let you spoof traffic/act as a
>>>>> router.
>>>>>
>>>>>    - If you want to keep using security groups, you will need
>>>>>    allowed-pairs.
>>>>>       - You can use a subnet as a wildcard / or use the IP address
>>>>>       specifically.
>>>>>    - If you dont mind very permissive rules, then disabling
>>>>>    port-security will require you to remove security groups + allowed-ip-pairs.
>>>>>
>>>>>
>>>>> On Tue, Mar 8, 2022 at 4:59 PM Ga?l THEROND <gael.therond at bitswalk.com>
>>>>> wrote:
>>>>>
>>>>>> Interesting I?ve thought about especially because of the
>>>>>> anti-spoofing features but I had the feeling that Security-groups if
>>>>>> assigned to the port would have allowed it.
>>>>>>
>>>>>> Additionally, what?s really weird is that one of our k8s clusters
>>>>>> using flannel and/or calico (depends on the user needs) is actually putting
>>>>>> those exact rules (SNAT+FORWARD rules) automatically for pods services
>>>>>> ingress access but I?m wondering if it works because the traffic is on a
>>>>>> tunnel that the host can?t see.
>>>>>>
>>>>>> I?ll have a look at your idea by disabling the port security and
>>>>>> check if it work like that. If it works then I?ll re-enable it and work
>>>>>> with the allowed-pairs.
>>>>>>
>>>>>> Many thanks!
>>>>>>
>>>>>> Le mar. 8 mars 2022 ? 22:13, Laurent Dumont <laurentfdumont at gmail.com>
>>>>>> a ?crit :
>>>>>>
>>>>>>> You might want to look at port-security on the bastion host VM. If
>>>>>>> it's enabled, it means that Openstack will drop any outgoing packets that
>>>>>>> are not sourced using the ip address + mac AND/OR the allowed_pairs defined
>>>>>>> on the port.
>>>>>>>
>>>>>>> On Tue, Mar 8, 2022 at 3:07 PM Ga?l THEROND <
>>>>>>> gael.therond at bitswalk.com> wrote:
>>>>>>>
>>>>>>>> Hi everyone!
>>>>>>>>
>>>>>>>> I?m facing a weird situation on a tenant of one of our Openstack
>>>>>>>> cluster based on Victoria.
>>>>>>>>
>>>>>>>> On this tenant, the network topology is as follow:
>>>>>>>>
>>>>>>>> One DMZ network (192.168.0.0/24) linked to our public network
>>>>>>>> through a neutron router where there is a VM acting as a bastion/router for
>>>>>>>> the MGMT network.
>>>>>>>>
>>>>>>>> One MGMT network (172.16.31.0/24) where all VMs are linked to.
>>>>>>>>
>>>>>>>> On the DMZ network, there is a linux Debian 11, let?s call it VM-A
>>>>>>>> with a Floating IP from the public pool, this VM is both attached to the
>>>>>>>> DMZ network (ens3 / 192.168.0.12) AND the MGMT network (ens4 /
>>>>>>>> 172.16.31.23).
>>>>>>>>
>>>>>>>> All other VMs, let?s call them VM-X are exclusively attached to the
>>>>>>>> MGMT network (ens4).
>>>>>>>>
>>>>>>>> I?ve setup VM-A with ip_forward kernel module and the following
>>>>>>>> iptables rule:
>>>>>>>>
>>>>>>>> # iptables -t nat -A POSTROUTING -o ens3 -J SNAT ?to-source
>>>>>>>> 192.168.0.12
>>>>>>>>
>>>>>>>> My VM-X are on their own setup with a default gateway via VM-A:
>>>>>>>>
>>>>>>>> # ip route add default via 172.31.16.23
>>>>>>>>
>>>>>>>> The setup seems to be working as if I don?t put the iptables rule
>>>>>>>> and the kernel forwarding I can?t see any packets on my DMZ interface
>>>>>>>> (ens3) on VM-A from VM-X.
>>>>>>>>
>>>>>>>> Ok so now that you get the whole schema, let dive into the issue.
>>>>>>>>
>>>>>>>> So when all rules, modules and gateway are set, I can fully see my
>>>>>>>> VM-X traffic (ICMP ping to a dns server) going from VM-X (ens4) to VM-A
>>>>>>>> (ens4) then forwarded to VM-A (ens3) and finally going to our public IP
>>>>>>>> targeted service.
>>>>>>>>
>>>>>>>> What?s not working however is the response not reaching back to
>>>>>>>> VM-X.
>>>>>>>>
>>>>>>>> I?ve tcpdump the whole traffic from VM-X to VM-A on each point of
>>>>>>>> the platfrom:
>>>>>>>>
>>>>>>>> from inside the VM-X nic, on the tap device, on the qbr bridge, on
>>>>>>>> the qvb veth, on the qvo second side of the veth through the ovs bridges
>>>>>>>> and vice-versa.
>>>>>>>>
>>>>>>>> However the response packets aren?t reaching back further than on
>>>>>>>> the VM-A qvo veth.
>>>>>>>> Once it exit the VM-A the traffic never reaches the VM-X.
>>>>>>>>
>>>>>>>> What?s really suspicious in here is that a direct ping from VM-X
>>>>>>>> (172.16.31.54) to VM-A (172.16.31.23) is coming back correctly, so it looks
>>>>>>>> like if ovs detected that the response on a SNAT case isn?t legit or
>>>>>>>> something similar.
>>>>>>>>
>>>>>>>> Is anyone able to get such setup working?
>>>>>>>>
>>>>>>>> Here are few additional information:
>>>>>>>> Host runs on CentOS 8.5 latest update.
>>>>>>>> Our platform is a Openstack Victoria deployed using kolla-ansible.
>>>>>>>> We are using a OVS based deployment.
>>>>>>>> Our tunnels are VXLAN.
>>>>>>>> All VMs have a fully open secgroup applied and all ports have it (I
>>>>>>>> checked it twice and even on host iptables).
>>>>>>>>
>>>>>>>> If you ever need additional information feel free to let me know !
>>>>>>>>
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220313/dc4499d1/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 21446 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220313/dc4499d1/attachment-0001.png>

From ahmedabdelhamid1221 at gmail.com  Mon Mar 14 16:02:28 2022
From: ahmedabdelhamid1221 at gmail.com (Ahmed Abdelhamid)
Date: Mon, 14 Mar 2022 12:02:28 -0400
Subject: Metadata service {devices list}
Message-ID: <CAMRGJtetgCKOCZ2WDZUJ8dWWJDufODOXZ=ia3s_KegiVp1A64g@mail.gmail.com>

Hi All,

I am running into a strange issue with the metadata service. Per
metadata-service
manual <https://docs.openstack.org/nova/latest/user/metadata.html>, the
devices attached to a VM should be visible in

$ curl http://169.254.169.254/openstack/2018-08-27/meta_data.json

However, whenever i execute it from a VM , the devices array is empty and
looks like this, any idea why ?

Thanks

{   "random_seed": "yu5ZnkqF2CqnDZVAfZgarG...",   "availability_zone":
"nova",   "keys": [       {         "data": "ssh-rsa AAAAB3NzaC1y...==
Generated by Nova\n",         "type": "ssh",         "name": "mykey"
    }   ],   "hostname": "test.novalocal",   "launch_index": 0,
"meta": {      "priority": "low",      "role": "webserver"   },
"devices": [ ],   "project_id": "f7ac731cc11f40efbc03a9f9e1d1d21f",
"public_keys": {       "mykey": "ssh-rsa AAAAB3NzaC1y...== Generated
by Nova\n"   },   "name": "test"}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220314/41d8291e/attachment.htm>

From laurentfdumont at gmail.com  Mon Mar 14 22:17:08 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Mon, 14 Mar 2022 18:17:08 -0400
Subject: [VICTORIA] Not working SNAT over VXLAN?
In-Reply-To: <CABNe=UuDdKYcpdtTWyoWFbaH0svyBYR97Q0yTWb3MuK5+_xNoA@mail.gmail.com>
References: <CABNe=Utwt0dVuzzyCbVw63WoSr4s9w0kfUNkPLsDJp7fNt97mA@mail.gmail.com>
 <CAOAKi8wA=bk2v2iHZgQT6Yp2baEx40a8AytBbe2cJtF6gwL-6Q@mail.gmail.com>
 <CABNe=UvCDXmhx0iD9CHtKPpiuDe=cLjw-66a9oUNStMyGwxn0g@mail.gmail.com>
 <CAOAKi8zHqtkuNg=Wyhai0JajiJXweB00e38avnJULM2_YtS8xA@mail.gmail.com>
 <CABNe=UvROiFnipaLCSJ+fzW7xo-JriuDWsdGJQnU5YMw3C0c6w@mail.gmail.com>
 <CAOAKi8wnduw+FZupKb8z8sZ6LeC10Wp+e-80fjkLeZCN0TC_NA@mail.gmail.com>
 <CABNe=UtQs-MVQUZ5bX2CgGe2W6RACjc-CJ94wDJ5RR1XvOVc1Q@mail.gmail.com>
 <CAOAKi8wK4D=EPNJq8a70VyOCtRECZ6zcOPtnZktoio0VJc-aEA@mail.gmail.com>
 <CABNe=UuDdKYcpdtTWyoWFbaH0svyBYR97Q0yTWb3MuK5+_xNoA@mail.gmail.com>
Message-ID: <CAOAKi8xyVZ4SyX3-XL+U3SFXS9os6rEG28d=H_bZVna0oN_8aA@mail.gmail.com>

In theory, if vxlan networks are created with the --shared flag, or rbac-ed
post creation, you could have one qrouter with multiple vxlan ports. You
just have to make sure they are not overlapping but I think it would route
between each out of the box.

On Sun, Mar 13, 2022 at 5:18 PM Ga?l THEROND <gael.therond at bitswalk.com>
wrote:

> Yeah, especially that you can?t use them for internal vxlan to vxlan
> routing straight from horizon or without having higher knowledge to neutron
> and using CLI, that honestly my users don?t have :-) I?m working on a
> ansible skeleton that our business units devs could use ? easily ? for the
> less infrastructure oriented.
>
> I really think that vxlan to vxlan routing should be allowed right from
> within horizon for the final users (non ops/admins).
>
> Anyway! Thanks a lot!
>
> Le dim. 13 mars 2022 ? 22:09, Laurent Dumont <laurentfdumont at gmail.com> a
> ?crit :
>
>> Nice! I reread and meant to say that SNAT transforms the packets to take
>> the source of eth1, not eth0.
>>
>> But the logic is the same.
>>
>> It's worth mentioning that routers in Openstack essentially do that. But
>> they are a bit less flexible than a VM.
>>
>> On Fri, Mar 11, 2022, 6:06 PM Ga?l THEROND <gael.therond at bitswalk.com>
>> wrote:
>>
>>> I actually dig deeper and that?s exactly that, it?s filtered out by
>>> iptable that get a special match rule when you don?t disable the security
>>> ports or assign any allowed pairs :-)
>>>
>>> TBN: Your explication and schema is perfect! I?ll use it to explain this
>>> to my teammates that may face it at some point.
>>>
>>> Le ven. 11 mars 2022 ? 23:37, Laurent Dumont <laurentfdumont at gmail.com>
>>> a ?crit :
>>>
>>>> It's a bit hard to see without a diagram but here is my theory.
>>>>
>>>>    - Packets from client-vm towards external endpoint exit from eth0.
>>>>    - Packets arrive to eth1 on router-vm and are allowed because
>>>>       - security-groups OK
>>>>       - mac-address + ip_address policy is only applicable to outgoing
>>>>       traffic (that's what I think for now...)
>>>>    - You have a SNAT in place for eth0.
>>>>    - Packets leave router-vm from eth0 with the source address
>>>>    becoming the IP of eth0. This is allowed because
>>>>       - security-groups OK
>>>>       - mac-address + ip_address policies are applied, but will match
>>>>       the packet since you are SNAT the traffic (and not just routing).
>>>>    - Packets arrive to ze-internet, traffic returns towards the
>>>>    router-vm.
>>>>    - Packets arrive to eth0, still valid.
>>>>    - Packets are processed by iptables which mangles the flow to
>>>>    correct the source IP to the source of the ze-internet.
>>>>    - Packets try to leave through eth1 but are now invalid because
>>>>       - security-groups OK
>>>>       - mac-address + ip_address policies are applied *but are now
>>>>       invalid. Source is ze-internet, which Openstack knows is not associated
>>>>       with eth1.*
>>>>       - If you tcpdump on eth1 of router-vm, you should see the
>>>>    traffic going out since it's before any filtering from ovs on the compute.
>>>>    Either ovs-flows are iptables are used for the actual filtering.
>>>>
>>>>
>>>> At least, that's what I think. I'll run some tests in the lab!
>>>> [image: image.png]
>>>>
>>>> On Wed, Mar 9, 2022 at 4:51 AM Ga?l THEROND <gael.therond at bitswalk.com>
>>>> wrote:
>>>>
>>>>> I?ve made few test this morning, disabling port security on the MGMT
>>>>> port of VM-A (bastion) indeed did the trick and the traffic started to flow
>>>>> correctly.
>>>>>
>>>>> I?ve then tested to enable it back and set the allowed_pairs with
>>>>> subnet, it works too, so the issue is definitely what you were pointing out
>>>>> so big shout out to you as this options is so deeply burried on the
>>>>> config/ui that I didn?t thought of it more than that.
>>>>>
>>>>> Yeah regarding k8s that what I was suspecting, thanks for the
>>>>> confirmation.
>>>>>
>>>>> However, there is one thing that I can?t get my head around with my
>>>>> simple router installation.
>>>>>
>>>>> If VM-X send a ping for let say google.com on its gateway (VM-A), the
>>>>> packet goes with VM-X mac/ip header, then VM-A thanks to the ip_forward
>>>>> know that this packet is belonging to another nic which is having the
>>>>> appropriate default gareway. At this point, we didn?t touched anything on
>>>>> the packet (to my knowledge) so once we reach the SNAT our packet header
>>>>> source IP is changed with the external router connected nic IP, then it
>>>>> flow through dns resolver that answer this IP, once the nic get this
>>>>> response, it just forward it back to the MGMT nic of the bastion which in
>>>>> turn answer to the VM-X mgmt nic without doing any spoofing etc.
>>>>>
>>>>> I?m feeling that I miss something on the way in here, what did I
>>>>> missed on this flow? At which step VM-A is breaking the law? At forward
>>>>> step?
>>>>>
>>>>> Le mer. 9 mars 2022 ? 03:20, Laurent Dumont <laurentfdumont at gmail.com>
>>>>> a ?crit :
>>>>>
>>>>>> Any overlay inside the vxlan overlay should work. Since it
>>>>>> encapsulates the actual pod/service traffic, Openstack has no clue and
>>>>>> happily forwards the traffic since it matches the spec (mac + IP) of the
>>>>>> port.
>>>>>>
>>>>>> Using only security groups will not let you spoof traffic/act as a
>>>>>> router.
>>>>>>
>>>>>>    - If you want to keep using security groups, you will need
>>>>>>    allowed-pairs.
>>>>>>       - You can use a subnet as a wildcard / or use the IP address
>>>>>>       specifically.
>>>>>>    - If you dont mind very permissive rules, then disabling
>>>>>>    port-security will require you to remove security groups + allowed-ip-pairs.
>>>>>>
>>>>>>
>>>>>> On Tue, Mar 8, 2022 at 4:59 PM Ga?l THEROND <
>>>>>> gael.therond at bitswalk.com> wrote:
>>>>>>
>>>>>>> Interesting I?ve thought about especially because of the
>>>>>>> anti-spoofing features but I had the feeling that Security-groups if
>>>>>>> assigned to the port would have allowed it.
>>>>>>>
>>>>>>> Additionally, what?s really weird is that one of our k8s clusters
>>>>>>> using flannel and/or calico (depends on the user needs) is actually putting
>>>>>>> those exact rules (SNAT+FORWARD rules) automatically for pods services
>>>>>>> ingress access but I?m wondering if it works because the traffic is on a
>>>>>>> tunnel that the host can?t see.
>>>>>>>
>>>>>>> I?ll have a look at your idea by disabling the port security and
>>>>>>> check if it work like that. If it works then I?ll re-enable it and work
>>>>>>> with the allowed-pairs.
>>>>>>>
>>>>>>> Many thanks!
>>>>>>>
>>>>>>> Le mar. 8 mars 2022 ? 22:13, Laurent Dumont <
>>>>>>> laurentfdumont at gmail.com> a ?crit :
>>>>>>>
>>>>>>>> You might want to look at port-security on the bastion host VM. If
>>>>>>>> it's enabled, it means that Openstack will drop any outgoing packets that
>>>>>>>> are not sourced using the ip address + mac AND/OR the allowed_pairs defined
>>>>>>>> on the port.
>>>>>>>>
>>>>>>>> On Tue, Mar 8, 2022 at 3:07 PM Ga?l THEROND <
>>>>>>>> gael.therond at bitswalk.com> wrote:
>>>>>>>>
>>>>>>>>> Hi everyone!
>>>>>>>>>
>>>>>>>>> I?m facing a weird situation on a tenant of one of our Openstack
>>>>>>>>> cluster based on Victoria.
>>>>>>>>>
>>>>>>>>> On this tenant, the network topology is as follow:
>>>>>>>>>
>>>>>>>>> One DMZ network (192.168.0.0/24) linked to our public network
>>>>>>>>> through a neutron router where there is a VM acting as a bastion/router for
>>>>>>>>> the MGMT network.
>>>>>>>>>
>>>>>>>>> One MGMT network (172.16.31.0/24) where all VMs are linked to.
>>>>>>>>>
>>>>>>>>> On the DMZ network, there is a linux Debian 11, let?s call it VM-A
>>>>>>>>> with a Floating IP from the public pool, this VM is both attached to the
>>>>>>>>> DMZ network (ens3 / 192.168.0.12) AND the MGMT network (ens4 /
>>>>>>>>> 172.16.31.23).
>>>>>>>>>
>>>>>>>>> All other VMs, let?s call them VM-X are exclusively attached to
>>>>>>>>> the MGMT network (ens4).
>>>>>>>>>
>>>>>>>>> I?ve setup VM-A with ip_forward kernel module and the following
>>>>>>>>> iptables rule:
>>>>>>>>>
>>>>>>>>> # iptables -t nat -A POSTROUTING -o ens3 -J SNAT ?to-source
>>>>>>>>> 192.168.0.12
>>>>>>>>>
>>>>>>>>> My VM-X are on their own setup with a default gateway via VM-A:
>>>>>>>>>
>>>>>>>>> # ip route add default via 172.31.16.23
>>>>>>>>>
>>>>>>>>> The setup seems to be working as if I don?t put the iptables rule
>>>>>>>>> and the kernel forwarding I can?t see any packets on my DMZ interface
>>>>>>>>> (ens3) on VM-A from VM-X.
>>>>>>>>>
>>>>>>>>> Ok so now that you get the whole schema, let dive into the issue.
>>>>>>>>>
>>>>>>>>> So when all rules, modules and gateway are set, I can fully see my
>>>>>>>>> VM-X traffic (ICMP ping to a dns server) going from VM-X (ens4) to VM-A
>>>>>>>>> (ens4) then forwarded to VM-A (ens3) and finally going to our public IP
>>>>>>>>> targeted service.
>>>>>>>>>
>>>>>>>>> What?s not working however is the response not reaching back to
>>>>>>>>> VM-X.
>>>>>>>>>
>>>>>>>>> I?ve tcpdump the whole traffic from VM-X to VM-A on each point of
>>>>>>>>> the platfrom:
>>>>>>>>>
>>>>>>>>> from inside the VM-X nic, on the tap device, on the qbr bridge, on
>>>>>>>>> the qvb veth, on the qvo second side of the veth through the ovs bridges
>>>>>>>>> and vice-versa.
>>>>>>>>>
>>>>>>>>> However the response packets aren?t reaching back further than on
>>>>>>>>> the VM-A qvo veth.
>>>>>>>>> Once it exit the VM-A the traffic never reaches the VM-X.
>>>>>>>>>
>>>>>>>>> What?s really suspicious in here is that a direct ping from VM-X
>>>>>>>>> (172.16.31.54) to VM-A (172.16.31.23) is coming back correctly, so it looks
>>>>>>>>> like if ovs detected that the response on a SNAT case isn?t legit or
>>>>>>>>> something similar.
>>>>>>>>>
>>>>>>>>> Is anyone able to get such setup working?
>>>>>>>>>
>>>>>>>>> Here are few additional information:
>>>>>>>>> Host runs on CentOS 8.5 latest update.
>>>>>>>>> Our platform is a Openstack Victoria deployed using kolla-ansible.
>>>>>>>>> We are using a OVS based deployment.
>>>>>>>>> Our tunnels are VXLAN.
>>>>>>>>> All VMs have a fully open secgroup applied and all ports have it
>>>>>>>>> (I checked it twice and even on host iptables).
>>>>>>>>>
>>>>>>>>> If you ever need additional information feel free to let me know !
>>>>>>>>>
>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220314/b0bacf7b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 21446 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220314/b0bacf7b/attachment-0001.png>

From gael.therond at bitswalk.com  Tue Mar 15 07:50:43 2022
From: gael.therond at bitswalk.com (=?UTF-8?Q?Ga=C3=ABl_THEROND?=)
Date: Tue, 15 Mar 2022 08:50:43 +0100
Subject: [VICTORIA] Not working SNAT over VXLAN?
In-Reply-To: <CAOAKi8xyVZ4SyX3-XL+U3SFXS9os6rEG28d=H_bZVna0oN_8aA@mail.gmail.com>
References: <CABNe=Utwt0dVuzzyCbVw63WoSr4s9w0kfUNkPLsDJp7fNt97mA@mail.gmail.com>
 <CAOAKi8wA=bk2v2iHZgQT6Yp2baEx40a8AytBbe2cJtF6gwL-6Q@mail.gmail.com>
 <CABNe=UvCDXmhx0iD9CHtKPpiuDe=cLjw-66a9oUNStMyGwxn0g@mail.gmail.com>
 <CAOAKi8zHqtkuNg=Wyhai0JajiJXweB00e38avnJULM2_YtS8xA@mail.gmail.com>
 <CABNe=UvROiFnipaLCSJ+fzW7xo-JriuDWsdGJQnU5YMw3C0c6w@mail.gmail.com>
 <CAOAKi8wnduw+FZupKb8z8sZ6LeC10Wp+e-80fjkLeZCN0TC_NA@mail.gmail.com>
 <CABNe=UtQs-MVQUZ5bX2CgGe2W6RACjc-CJ94wDJ5RR1XvOVc1Q@mail.gmail.com>
 <CAOAKi8wK4D=EPNJq8a70VyOCtRECZ6zcOPtnZktoio0VJc-aEA@mail.gmail.com>
 <CABNe=UuDdKYcpdtTWyoWFbaH0svyBYR97Q0yTWb3MuK5+_xNoA@mail.gmail.com>
 <CAOAKi8xyVZ4SyX3-XL+U3SFXS9os6rEG28d=H_bZVna0oN_8aA@mail.gmail.com>
Message-ID: <CABNe=UtXU1nV5MfyD8UaC4P9mAHXpawN-FCECZR9Q8LQpcnXJQ@mail.gmail.com>

Yes, if they?re shared and RBAC-ed you can.

I was more about pure private vxlan and a router/function to made them
inter-routable like what I?ve done with the linux base router, but that
would be either suboptimal or complexe depending on the solution chosen as
it would either require:

* a router for vxlans that would be located on your network node but then
it circumvent the purpose of a meshed vxlan topology.

Or

* Complexe as it would involve ovs flow rules and iptables rules on each
compute nodes that host the VMs and that automatically and seamlessly route
your traffic.

Anyway, a linux double homed instance is still the most efficient way (that
I?m aware of) to do that so far.

Le lun. 14 mars 2022 ? 23:17, Laurent Dumont <laurentfdumont at gmail.com> a
?crit :

> In theory, if vxlan networks are created with the --shared flag, or
> rbac-ed post creation, you could have one qrouter with multiple vxlan
> ports. You just have to make sure they are not overlapping but I think it
> would route between each out of the box.
>
> On Sun, Mar 13, 2022 at 5:18 PM Ga?l THEROND <gael.therond at bitswalk.com>
> wrote:
>
>> Yeah, especially that you can?t use them for internal vxlan to vxlan
>> routing straight from horizon or without having higher knowledge to neutron
>> and using CLI, that honestly my users don?t have :-) I?m working on a
>> ansible skeleton that our business units devs could use ? easily ? for the
>> less infrastructure oriented.
>>
>> I really think that vxlan to vxlan routing should be allowed right from
>> within horizon for the final users (non ops/admins).
>>
>> Anyway! Thanks a lot!
>>
>> Le dim. 13 mars 2022 ? 22:09, Laurent Dumont <laurentfdumont at gmail.com>
>> a ?crit :
>>
>>> Nice! I reread and meant to say that SNAT transforms the packets to take
>>> the source of eth1, not eth0.
>>>
>>> But the logic is the same.
>>>
>>> It's worth mentioning that routers in Openstack essentially do that. But
>>> they are a bit less flexible than a VM.
>>>
>>> On Fri, Mar 11, 2022, 6:06 PM Ga?l THEROND <gael.therond at bitswalk.com>
>>> wrote:
>>>
>>>> I actually dig deeper and that?s exactly that, it?s filtered out by
>>>> iptable that get a special match rule when you don?t disable the security
>>>> ports or assign any allowed pairs :-)
>>>>
>>>> TBN: Your explication and schema is perfect! I?ll use it to explain
>>>> this to my teammates that may face it at some point.
>>>>
>>>> Le ven. 11 mars 2022 ? 23:37, Laurent Dumont <laurentfdumont at gmail.com>
>>>> a ?crit :
>>>>
>>>>> It's a bit hard to see without a diagram but here is my theory.
>>>>>
>>>>>    - Packets from client-vm towards external endpoint exit from eth0.
>>>>>    - Packets arrive to eth1 on router-vm and are allowed because
>>>>>       - security-groups OK
>>>>>       - mac-address + ip_address policy is only applicable to
>>>>>       outgoing traffic (that's what I think for now...)
>>>>>    - You have a SNAT in place for eth0.
>>>>>    - Packets leave router-vm from eth0 with the source address
>>>>>    becoming the IP of eth0. This is allowed because
>>>>>       - security-groups OK
>>>>>       - mac-address + ip_address policies are applied, but will match
>>>>>       the packet since you are SNAT the traffic (and not just routing).
>>>>>    - Packets arrive to ze-internet, traffic returns towards the
>>>>>    router-vm.
>>>>>    - Packets arrive to eth0, still valid.
>>>>>    - Packets are processed by iptables which mangles the flow to
>>>>>    correct the source IP to the source of the ze-internet.
>>>>>    - Packets try to leave through eth1 but are now invalid because
>>>>>       - security-groups OK
>>>>>       - mac-address + ip_address policies are applied *but are now
>>>>>       invalid. Source is ze-internet, which Openstack knows is not associated
>>>>>       with eth1.*
>>>>>       - If you tcpdump on eth1 of router-vm, you should see the
>>>>>    traffic going out since it's before any filtering from ovs on the compute.
>>>>>    Either ovs-flows are iptables are used for the actual filtering.
>>>>>
>>>>>
>>>>> At least, that's what I think. I'll run some tests in the lab!
>>>>> [image: image.png]
>>>>>
>>>>> On Wed, Mar 9, 2022 at 4:51 AM Ga?l THEROND <gael.therond at bitswalk.com>
>>>>> wrote:
>>>>>
>>>>>> I?ve made few test this morning, disabling port security on the MGMT
>>>>>> port of VM-A (bastion) indeed did the trick and the traffic started to flow
>>>>>> correctly.
>>>>>>
>>>>>> I?ve then tested to enable it back and set the allowed_pairs with
>>>>>> subnet, it works too, so the issue is definitely what you were pointing out
>>>>>> so big shout out to you as this options is so deeply burried on the
>>>>>> config/ui that I didn?t thought of it more than that.
>>>>>>
>>>>>> Yeah regarding k8s that what I was suspecting, thanks for the
>>>>>> confirmation.
>>>>>>
>>>>>> However, there is one thing that I can?t get my head around with my
>>>>>> simple router installation.
>>>>>>
>>>>>> If VM-X send a ping for let say google.com on its gateway (VM-A),
>>>>>> the packet goes with VM-X mac/ip header, then VM-A thanks to the ip_forward
>>>>>> know that this packet is belonging to another nic which is having the
>>>>>> appropriate default gareway. At this point, we didn?t touched anything on
>>>>>> the packet (to my knowledge) so once we reach the SNAT our packet header
>>>>>> source IP is changed with the external router connected nic IP, then it
>>>>>> flow through dns resolver that answer this IP, once the nic get this
>>>>>> response, it just forward it back to the MGMT nic of the bastion which in
>>>>>> turn answer to the VM-X mgmt nic without doing any spoofing etc.
>>>>>>
>>>>>> I?m feeling that I miss something on the way in here, what did I
>>>>>> missed on this flow? At which step VM-A is breaking the law? At forward
>>>>>> step?
>>>>>>
>>>>>> Le mer. 9 mars 2022 ? 03:20, Laurent Dumont <laurentfdumont at gmail.com>
>>>>>> a ?crit :
>>>>>>
>>>>>>> Any overlay inside the vxlan overlay should work. Since it
>>>>>>> encapsulates the actual pod/service traffic, Openstack has no clue and
>>>>>>> happily forwards the traffic since it matches the spec (mac + IP) of the
>>>>>>> port.
>>>>>>>
>>>>>>> Using only security groups will not let you spoof traffic/act as a
>>>>>>> router.
>>>>>>>
>>>>>>>    - If you want to keep using security groups, you will need
>>>>>>>    allowed-pairs.
>>>>>>>       - You can use a subnet as a wildcard / or use the IP address
>>>>>>>       specifically.
>>>>>>>    - If you dont mind very permissive rules, then disabling
>>>>>>>    port-security will require you to remove security groups + allowed-ip-pairs.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Mar 8, 2022 at 4:59 PM Ga?l THEROND <
>>>>>>> gael.therond at bitswalk.com> wrote:
>>>>>>>
>>>>>>>> Interesting I?ve thought about especially because of the
>>>>>>>> anti-spoofing features but I had the feeling that Security-groups if
>>>>>>>> assigned to the port would have allowed it.
>>>>>>>>
>>>>>>>> Additionally, what?s really weird is that one of our k8s clusters
>>>>>>>> using flannel and/or calico (depends on the user needs) is actually putting
>>>>>>>> those exact rules (SNAT+FORWARD rules) automatically for pods services
>>>>>>>> ingress access but I?m wondering if it works because the traffic is on a
>>>>>>>> tunnel that the host can?t see.
>>>>>>>>
>>>>>>>> I?ll have a look at your idea by disabling the port security and
>>>>>>>> check if it work like that. If it works then I?ll re-enable it and work
>>>>>>>> with the allowed-pairs.
>>>>>>>>
>>>>>>>> Many thanks!
>>>>>>>>
>>>>>>>> Le mar. 8 mars 2022 ? 22:13, Laurent Dumont <
>>>>>>>> laurentfdumont at gmail.com> a ?crit :
>>>>>>>>
>>>>>>>>> You might want to look at port-security on the bastion host VM. If
>>>>>>>>> it's enabled, it means that Openstack will drop any outgoing packets that
>>>>>>>>> are not sourced using the ip address + mac AND/OR the allowed_pairs defined
>>>>>>>>> on the port.
>>>>>>>>>
>>>>>>>>> On Tue, Mar 8, 2022 at 3:07 PM Ga?l THEROND <
>>>>>>>>> gael.therond at bitswalk.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi everyone!
>>>>>>>>>>
>>>>>>>>>> I?m facing a weird situation on a tenant of one of our Openstack
>>>>>>>>>> cluster based on Victoria.
>>>>>>>>>>
>>>>>>>>>> On this tenant, the network topology is as follow:
>>>>>>>>>>
>>>>>>>>>> One DMZ network (192.168.0.0/24) linked to our public network
>>>>>>>>>> through a neutron router where there is a VM acting as a bastion/router for
>>>>>>>>>> the MGMT network.
>>>>>>>>>>
>>>>>>>>>> One MGMT network (172.16.31.0/24) where all VMs are linked to.
>>>>>>>>>>
>>>>>>>>>> On the DMZ network, there is a linux Debian 11, let?s call it
>>>>>>>>>> VM-A with a Floating IP from the public pool, this VM is both attached to
>>>>>>>>>> the DMZ network (ens3 / 192.168.0.12) AND the MGMT network (ens4 /
>>>>>>>>>> 172.16.31.23).
>>>>>>>>>>
>>>>>>>>>> All other VMs, let?s call them VM-X are exclusively attached to
>>>>>>>>>> the MGMT network (ens4).
>>>>>>>>>>
>>>>>>>>>> I?ve setup VM-A with ip_forward kernel module and the following
>>>>>>>>>> iptables rule:
>>>>>>>>>>
>>>>>>>>>> # iptables -t nat -A POSTROUTING -o ens3 -J SNAT ?to-source
>>>>>>>>>> 192.168.0.12
>>>>>>>>>>
>>>>>>>>>> My VM-X are on their own setup with a default gateway via VM-A:
>>>>>>>>>>
>>>>>>>>>> # ip route add default via 172.31.16.23
>>>>>>>>>>
>>>>>>>>>> The setup seems to be working as if I don?t put the iptables rule
>>>>>>>>>> and the kernel forwarding I can?t see any packets on my DMZ interface
>>>>>>>>>> (ens3) on VM-A from VM-X.
>>>>>>>>>>
>>>>>>>>>> Ok so now that you get the whole schema, let dive into the issue.
>>>>>>>>>>
>>>>>>>>>> So when all rules, modules and gateway are set, I can fully see
>>>>>>>>>> my VM-X traffic (ICMP ping to a dns server) going from VM-X (ens4) to VM-A
>>>>>>>>>> (ens4) then forwarded to VM-A (ens3) and finally going to our public IP
>>>>>>>>>> targeted service.
>>>>>>>>>>
>>>>>>>>>> What?s not working however is the response not reaching back to
>>>>>>>>>> VM-X.
>>>>>>>>>>
>>>>>>>>>> I?ve tcpdump the whole traffic from VM-X to VM-A on each point of
>>>>>>>>>> the platfrom:
>>>>>>>>>>
>>>>>>>>>> from inside the VM-X nic, on the tap device, on the qbr bridge,
>>>>>>>>>> on the qvb veth, on the qvo second side of the veth through the ovs bridges
>>>>>>>>>> and vice-versa.
>>>>>>>>>>
>>>>>>>>>> However the response packets aren?t reaching back further than on
>>>>>>>>>> the VM-A qvo veth.
>>>>>>>>>> Once it exit the VM-A the traffic never reaches the VM-X.
>>>>>>>>>>
>>>>>>>>>> What?s really suspicious in here is that a direct ping from VM-X
>>>>>>>>>> (172.16.31.54) to VM-A (172.16.31.23) is coming back correctly, so it looks
>>>>>>>>>> like if ovs detected that the response on a SNAT case isn?t legit or
>>>>>>>>>> something similar.
>>>>>>>>>>
>>>>>>>>>> Is anyone able to get such setup working?
>>>>>>>>>>
>>>>>>>>>> Here are few additional information:
>>>>>>>>>> Host runs on CentOS 8.5 latest update.
>>>>>>>>>> Our platform is a Openstack Victoria deployed using kolla-ansible.
>>>>>>>>>> We are using a OVS based deployment.
>>>>>>>>>> Our tunnels are VXLAN.
>>>>>>>>>> All VMs have a fully open secgroup applied and all ports have it
>>>>>>>>>> (I checked it twice and even on host iptables).
>>>>>>>>>>
>>>>>>>>>> If you ever need additional information feel free to let me know !
>>>>>>>>>>
>>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220315/78e50ac6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 21446 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220315/78e50ac6/attachment-0001.png>

From amotoki at gmail.com  Tue Mar 15 13:24:22 2022
From: amotoki at gmail.com (Akihiro Motoki)
Date: Tue, 15 Mar 2022 22:24:22 +0900
Subject: [neutron] bug deputy report (Mar 7 - 13)
Message-ID: <CALhU9tmvPt8LHxW-d9WD9kSUKa7bQ0pftz=yGx--ru2xaZDsCA@mail.gmail.com>

Hi,

Here is a bug deputy report last week. It was a quiet week too.

= Needs attention

- https://bugs.launchpad.net/neutron/+bug/1964339
  [OVN Octavia Provider] OVN provider tests using too old version of OVN
  it looks like local.conf in ovn-octavia-provider-functional-release
is not configured properly,
  so the bug reported here looks valid. Hopefully ovn-octavia-provider
folks can look into it.

= Gate Failures

- https://bugs.launchpad.net/neutron/+bug/1963899
  Rebuild server - notification about port UP isn't sent to nova properly
  Confirmed, Unassigned
- https://bugs.launchpad.net/neutron/+bug/1964313
  Functional tests fails due to missing namespace
  Confirmed, Unassigned

= Assigned

- https://bugs.launchpad.net/neutron/+bug/1964817
  [ovn-octavia-provider] Deleted members remain in ERROR status

= RFE

- https://bugs.launchpad.net/neutron/+bug/1964765
  DHCP agent scheduler filtering ignored when agent service restarted
- https://bugs.launchpad.net/neutron/+bug/1964342
  [QoS][OvS] implement QoS bandwidth limitation by leveraging ovs meter

Thanks,
Akihiro Motoki (amotoki)


From ralonsoh at redhat.com  Tue Mar 15 13:44:46 2022
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Tue, 15 Mar 2022 14:44:46 +0100
Subject: Metadata service {devices list}
In-Reply-To: <CAMRGJtetgCKOCZ2WDZUJ8dWWJDufODOXZ=ia3s_KegiVp1A64g@mail.gmail.com>
References: <CAMRGJtetgCKOCZ2WDZUJ8dWWJDufODOXZ=ia3s_KegiVp1A64g@mail.gmail.com>
Message-ID: <CAECr9X5AOUOBYRQoibP=Ryp1LXz5n-6j45Ax_9E+eSOKaB2KEg@mail.gmail.com>

Hello Ahmed:

What network backend are you using?

Regards.

On Tue, Mar 15, 2022 at 2:22 PM Ahmed Abdelhamid <
ahmedabdelhamid1221 at gmail.com> wrote:

> Hi All,
>
> I am running into a strange issue with the metadata service. Per metadata-service
> manual <https://docs.openstack.org/nova/latest/user/metadata.html>, the
> devices attached to a VM should be visible in
>
> $ curl http://169.254.169.254/openstack/2018-08-27/meta_data.json
>
> However, whenever i execute it from a VM , the devices array is empty and
> looks like this, any idea why ?
>
> Thanks
>
> {   "random_seed": "yu5ZnkqF2CqnDZVAfZgarG...",   "availability_zone": "nova",   "keys": [       {         "data": "ssh-rsa AAAAB3NzaC1y...== Generated by Nova\n",         "type": "ssh",         "name": "mykey"       }   ],   "hostname": "test.novalocal",   "launch_index": 0,   "meta": {      "priority": "low",      "role": "webserver"   },   "devices": [ ],   "project_id": "f7ac731cc11f40efbc03a9f9e1d1d21f",   "public_keys": {       "mykey": "ssh-rsa AAAAB3NzaC1y...== Generated by Nova\n"   },   "name": "test"}
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220315/550fb527/attachment.htm>

From gmann at ghanshyammann.com  Tue Mar 15 15:23:45 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Tue, 15 Mar 2022 10:23:45 -0500
Subject: [heat][rbac] Management of "system resources" with SRBAC enforced
In-Reply-To: <CAL_crJShD7Th6Q0UQtmCwJfSgdKtDkcY_wBdYMc4CA+j6a0R8g@mail.gmail.com>
References: <CAL_crJSy6_-+0oLZC1PP=RoE-2fNMn0jytsv9UxJOZ2BxYbeeQ@mail.gmail.com>
 <CA+WCyyovVWVhudrs0RGzoKedH7DdRCjgR1dEF5icK9Epr7XOEQ@mail.gmail.com>
 <CAL_crJSPv3pmJ31DVJKSurVOLGZM5MOtfapKN1s+DxA-Yhr7AQ@mail.gmail.com>
 <17f6fd5cf65.b558d8a025830.2422670910290295781@ghanshyammann.com>
 <CAL_crJR7rLqGoOe8oq=jiVvLQoeGq0Pe=3CPnUNaz6sV29wKUw@mail.gmail.com>
 <17f71638687.128ce54ec34578.5876409253282361143@ghanshyammann.com>
 <CAL_crJShD7Th6Q0UQtmCwJfSgdKtDkcY_wBdYMc4CA+j6a0R8g@mail.gmail.com>
Message-ID: <17f8e2d9264.10dd328d5267246.555045975862118639@ghanshyammann.com>

 ---- On Wed, 09 Mar 2022 19:28:03 -0600 Takashi Kajinami <tkajinam at redhat.com> wrote ----
 > 
 > 
 > On Thu, Mar 10, 2022 at 10:13 AM Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
 >  ---- On Wed, 09 Mar 2022 17:14:02 -0600 Takashi Kajinami <tkajinam at redhat.com> wrote ----
 >  > 
 >  > 
 >  > On Thu, Mar 10, 2022 at 2:59 AM Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
 >  >  ---- On Wed, 09 Mar 2022 06:43:03 -0600 Takashi Kajinami <tkajinam at redhat.com> wrote ----
 >  >  > Hi Rico.
 >  >  > Thank you for your insights.Please find my replies inline.
 >  >  > 
 >  >  > On Wed, Mar 9, 2022 at 6:22 PM Rico Lin <ricolin at ricolky.com> wrote:
 >  >  > 
 >  >  > 
 >  >  > On Wed, Mar 9, 2022 at 1:57 PM Takashi Kajinami <tkajinam at redhat.com> wrote:
 >  >  > >
 >  >  > > Hello,
 >  >  > >
 >  >  > >
 >  >  > > I've been working on updating policy rules in heat according to the latest
 >  >  > > guideline for SRBAC implementation.
 >  >  > 
 >  >  > Thanks so much for working on it, definitely +1 on enhancing security.
 >  >  > >
 >  >  > >  [1] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#direction-change
 >  >  > >
 >  >  > > However this change reveals one potential issue with system resources.
 >  >  > >
 >  >  > > In heat there are some resource types like OS::Nova::Flavor or OS::Keystone::User
 >  >  > > which is allowed for only system users. (I'll call these resources as "system resources" here)
 >  >  > We create those resources based on checking `role:admin`, so project admin is accepted.This means a user under that project with role:admin, can operate those resources.I'm not sure what system user means here, so correct me if I'm wrong.
 >  >  > The core problem is that backend services like nova enforces different policies from just role:admin whenSRBAC is enforced. I reported that a while ago as https://storyboard.openstack.org/#!/story/2009787 .
 >  >  > 
 >  >  > The main problem here is that heat currently supports resources which require different scopes of credentials.For example, once all deprecated policy rules are removed, nova allows project users to create instances(OS::Nova::Server)[1],while nova allows only system admins to create flavors(OS::Nova::Flavor)[2]. Currently Heat leverages the user credentialused to create a stack when Heat requests backend services to create its resources, and it's "impossible" to create a stackwith these two resources by a single credential (as each token can be scoped by project or system.
 >  >  > [1] https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/servers.py#L210[2] https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/flavor_manage.py#L28-L36
 >  >  > If we keep allowing system users to create stacks, then it would allow users to create system resourceslike flavors. But this never solves the problem with the "mixed" pattern which I described above.Hope this will explain these three options more clearly.
 >  >  >  
 >  >  > >
 >  >  > > Because heat uses user credentials to create resources in backend services, if we require
 >  >  > > project scope for stack/resource management then we are no longer able to create these system
 >  >  > > resources as part of stack. (*1)>
 >  >  > > There are some options I can think of at this moment.
 >  >  > >
 >  >  > > 1. Deprecate and remove all resources which require system scope
 >  >  > > Pros
 >  >  > > - This is most easy solution to be implemented
 >  >  > > Cons
 >  >  > > - This one has the biggest user impact
 >  >  > 
 >  >  > Don't :)
 >  > 
 >  > Yeah, not sure how removing will work.
 >  > 
 >  >  > > 2. Use service credential for resource creation
 >  >  > > Pros:
 >  >  > > - This might have smallest user impact
 >  >  > > Cons:
 >  >  > > - This requires a relatively big change in heat's architecture, which I've not yet evaluated.
 >  >  > > - We need to determine the project scope role to be allowed to do system operation.
 >  >  > >  
 >  >  > I think this is something we can discuss more.
 >  >  > > 3. Implement additional project-role in each service to allow creation via stack creation.
 >  >  > > Pros:
 >  >  > > - This would avoid user impact.
 >  >  > > Cons:
 >  >  > > - requires work in multiple components.
 >  >  > > - We need to determine the project scope role to be allowed to do system operation
 >  >  > 
 >  >  > 
 >  >  > Indeed current stack operation require `(role:admin and system_scope:all) OR (role:member and project_id:%(project_id)s)`.And if we remove the system part and keep `(role:member and project_id:%(project_id)s)`, will mean only a user in that project with a member role can operate stack, and if the user got also admin role, that user can manage User/Flavor resources through stack too.The main problem here is that nova will no longer allow project admins to create flavors,and it will require system admin when SRBAC is enforced(which means all deprecated rulesare disabled)
 >  >  >  
 >  >  > Also, note thatFor the case of Nova::Flavor, both policies from Nova and Heat resource will be enforced here, so it only accepts the intersection part of rules.
 >  >  > So if we go with removing the system admin, that means it's time to also remove some deprecated global scope operation.
 >  >  > IMO, to accept Project Admin or member make more reasonable (like you proposed in option 3)
 >  > 
 >  > This is a similar case that we discussed in the service role ML thread[1] or in the spec[2].
 >  > 
 >  > For such cases only, where services need to interact with another service we will have the 'service' as
 >  > a special role. In this case, the heat having the project scoped token will use the 'service' role token for
 >  > Nova Flavor APIs calls.  Now whether that 'service' role token needs to be system scoped or not is
 >  > open question Mark brought up in that discussion. IMO, we should use the scoped token even in case
 >  > of 'service' role and do not skip scope checks for 'service' role in oslo policy as it can be a valid role used
 >  > by any users at production. So with the new SRBAC, heat needs to use the system scoped 'service' role token.
 >  > 
 >  > But as 'service' role is not yet implemented by keystone[2], we can use the legacy admin token which is currently
 >  > used in heat or other service-to-service interaction. 
 >  > 
 >  > Thanks gmann for inputs.
 >  > HoweverI think we still need a different role here.
 >  > The role I've mentioned here is not the role assigned to the Heat service user but the project-roleassigned to users to allow them create stacks with system resources like nova flavor or keystone user.This role is assigned to actual cloud users so service would not be appropriate.
 >  > 
 >  > I thought of using the admin role initially but this means that we provide a way to "bypass" policy checkand expose system operations to project users.
 >  > 
 >  > As a side note, current heat does not use its own credential but user credentials used for stack API calls. 
 >  > We can introduce this mechanism and let heat manage system resources by its service user but that isthe completely new feature we need to implement.
 > 
 > Thanks for the detailed information. For service to service interaction, I think heat needs to start using the configured
 > service user token instead of using actual user token.
 > 
 > For example nova use for neutron and similarly for other service interaction
 > - https://zuul.opendev.org/t/openstack/build/654ccb626d0e41a69308db1ed3328824/log/controller/logs/etc/nova/nova_conf.txt#40-51
 > 
 > I'll look into that option but It might take some time because I've not yet evaluated the impact of that change.My current idea is to use service credentials for system resources only so that we can keep using the user credentialfor project resources. 
 > 
 > As heat allows only project users to manage stacks, we need to determine the project role to allow creatingstacks with such system resources. Does anyone have any suggestions about this ?
 > Do we agree we can allow project-admin to create stacks with flavors or keystone users as the previous policy rulesallow or should we implement a new role to restrict management of system resources ?

Currently, existing way of creating flavor with project user should work as Nova still support the legacy policy so yes
project admin can do that. And on the new role, I think that is what the 'service' role will be.

I think the question we are discussing here and on spec is what scope the project should use for 'service' role requests for
their service-to-service interaction? IMO, it can be the same scope that calling APIs has. For heat example, heat can create
a 'service' role with the 'system' scope and call Nova to create flavor.  Another option is we skip the scope check for 'service'
role as a special case but this can create issue when any production deployment has a role with the name of 'service'.
Any other thoughts on this?

-gmann


 > 
 >  -gmann
 > 
 >  >  [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026777.html
 >  > [2] https://review.opendev.org/c/openstack/keystone-specs/+/818616
 >  > 
 >  > -gmann
 >  > 
 >  >  > >
 >  >  > > Thank you,
 >  >  > > Takashi
 >  >  > >
 >  >  > 
 >  > 
 >  > 
 > 
 > 


From tkajinam at redhat.com  Tue Mar 15 15:45:05 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Wed, 16 Mar 2022 00:45:05 +0900
Subject: [heat][rbac] Management of "system resources" with SRBAC enforced
In-Reply-To: <17f8e2d9264.10dd328d5267246.555045975862118639@ghanshyammann.com>
References: <CAL_crJSy6_-+0oLZC1PP=RoE-2fNMn0jytsv9UxJOZ2BxYbeeQ@mail.gmail.com>
 <CA+WCyyovVWVhudrs0RGzoKedH7DdRCjgR1dEF5icK9Epr7XOEQ@mail.gmail.com>
 <CAL_crJSPv3pmJ31DVJKSurVOLGZM5MOtfapKN1s+DxA-Yhr7AQ@mail.gmail.com>
 <17f6fd5cf65.b558d8a025830.2422670910290295781@ghanshyammann.com>
 <CAL_crJR7rLqGoOe8oq=jiVvLQoeGq0Pe=3CPnUNaz6sV29wKUw@mail.gmail.com>
 <17f71638687.128ce54ec34578.5876409253282361143@ghanshyammann.com>
 <CAL_crJShD7Th6Q0UQtmCwJfSgdKtDkcY_wBdYMc4CA+j6a0R8g@mail.gmail.com>
 <17f8e2d9264.10dd328d5267246.555045975862118639@ghanshyammann.com>
Message-ID: <CAL_crJQzbosuh19cm6yC23Aiwhs3M5dyX_wFv=rEdLxTSF=ZTg@mail.gmail.com>

On Wed, Mar 16, 2022 at 12:23 AM Ghanshyam Mann <gmann at ghanshyammann.com>
wrote:

>  ---- On Wed, 09 Mar 2022 19:28:03 -0600 Takashi Kajinami <
> tkajinam at redhat.com> wrote ----
>  >
>  >
>  > On Thu, Mar 10, 2022 at 10:13 AM Ghanshyam Mann <
> gmann at ghanshyammann.com> wrote:
>  >  ---- On Wed, 09 Mar 2022 17:14:02 -0600 Takashi Kajinami <
> tkajinam at redhat.com> wrote ----
>  >  >
>  >  >
>  >  > On Thu, Mar 10, 2022 at 2:59 AM Ghanshyam Mann <
> gmann at ghanshyammann.com> wrote:
>  >  >  ---- On Wed, 09 Mar 2022 06:43:03 -0600 Takashi Kajinami <
> tkajinam at redhat.com> wrote ----
>  >  >  > Hi Rico.
>  >  >  > Thank you for your insights.Please find my replies inline.
>  >  >  >
>  >  >  > On Wed, Mar 9, 2022 at 6:22 PM Rico Lin <ricolin at ricolky.com>
> wrote:
>  >  >  >
>  >  >  >
>  >  >  > On Wed, Mar 9, 2022 at 1:57 PM Takashi Kajinami <
> tkajinam at redhat.com> wrote:
>  >  >  > >
>  >  >  > > Hello,
>  >  >  > >
>  >  >  > >
>  >  >  > > I've been working on updating policy rules in heat according to
> the latest
>  >  >  > > guideline for SRBAC implementation.
>  >  >  >
>  >  >  > Thanks so much for working on it, definitely +1 on enhancing
> security.
>  >  >  > >
>  >  >  > >  [1]
> https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#direction-change
>  >  >  > >
>  >  >  > > However this change reveals one potential issue with system
> resources.
>  >  >  > >
>  >  >  > > In heat there are some resource types like OS::Nova::Flavor or
> OS::Keystone::User
>  >  >  > > which is allowed for only system users. (I'll call these
> resources as "system resources" here)
>  >  >  > We create those resources based on checking `role:admin`, so
> project admin is accepted.This means a user under that project with
> role:admin, can operate those resources.I'm not sure what system user means
> here, so correct me if I'm wrong.
>  >  >  > The core problem is that backend services like nova enforces
> different policies from just role:admin whenSRBAC is enforced. I reported
> that a while ago as https://storyboard.openstack.org/#!/story/2009787 .
>  >  >  >
>  >  >  > The main problem here is that heat currently supports resources
> which require different scopes of credentials.For example, once all
> deprecated policy rules are removed, nova allows project users to create
> instances(OS::Nova::Server)[1],while nova allows only system admins to
> create flavors(OS::Nova::Flavor)[2]. Currently Heat leverages the user
> credentialused to create a stack when Heat requests backend services to
> create its resources, and it's "impossible" to create a stackwith these two
> resources by a single credential (as each token can be scoped by project or
> system.
>  >  >  > [1]
> https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/servers.py#L210[2]
> https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/flavor_manage.py#L28-L36
>  >  >  > If we keep allowing system users to create stacks, then it would
> allow users to create system resourceslike flavors. But this never solves
> the problem with the "mixed" pattern which I described above.Hope this will
> explain these three options more clearly.
>  >  >  >
>  >  >  > >
>  >  >  > > Because heat uses user credentials to create resources in
> backend services, if we require
>  >  >  > > project scope for stack/resource management then we are no
> longer able to create these system
>  >  >  > > resources as part of stack. (*1)>
>  >  >  > > There are some options I can think of at this moment.
>  >  >  > >
>  >  >  > > 1. Deprecate and remove all resources which require system scope
>  >  >  > > Pros
>  >  >  > > - This is most easy solution to be implemented
>  >  >  > > Cons
>  >  >  > > - This one has the biggest user impact
>  >  >  >
>  >  >  > Don't :)
>  >  >
>  >  > Yeah, not sure how removing will work.
>  >  >
>  >  >  > > 2. Use service credential for resource creation
>  >  >  > > Pros:
>  >  >  > > - This might have smallest user impact
>  >  >  > > Cons:
>  >  >  > > - This requires a relatively big change in heat's architecture,
> which I've not yet evaluated.
>  >  >  > > - We need to determine the project scope role to be allowed to
> do system operation.
>  >  >  > >
>  >  >  > I think this is something we can discuss more.
>  >  >  > > 3. Implement additional project-role in each service to allow
> creation via stack creation.
>  >  >  > > Pros:
>  >  >  > > - This would avoid user impact.
>  >  >  > > Cons:
>  >  >  > > - requires work in multiple components.
>  >  >  > > - We need to determine the project scope role to be allowed to
> do system operation
>  >  >  >
>  >  >  >
>  >  >  > Indeed current stack operation require `(role:admin and
> system_scope:all) OR (role:member and project_id:%(project_id)s)`.And if we
> remove the system part and keep `(role:member and
> project_id:%(project_id)s)`, will mean only a user in that project with a
> member role can operate stack, and if the user got also admin role, that
> user can manage User/Flavor resources through stack too.The main problem
> here is that nova will no longer allow project admins to create flavors,and
> it will require system admin when SRBAC is enforced(which means all
> deprecated rulesare disabled)
>  >  >  >
>  >  >  > Also, note thatFor the case of Nova::Flavor, both policies from
> Nova and Heat resource will be enforced here, so it only accepts the
> intersection part of rules.
>  >  >  > So if we go with removing the system admin, that means it's time
> to also remove some deprecated global scope operation.
>  >  >  > IMO, to accept Project Admin or member make more reasonable (like
> you proposed in option 3)
>  >  >
>  >  > This is a similar case that we discussed in the service role ML
> thread[1] or in the spec[2].
>  >  >
>  >  > For such cases only, where services need to interact with another
> service we will have the 'service' as
>  >  > a special role. In this case, the heat having the project scoped
> token will use the 'service' role token for
>  >  > Nova Flavor APIs calls.  Now whether that 'service' role token needs
> to be system scoped or not is
>  >  > open question Mark brought up in that discussion. IMO, we should use
> the scoped token even in case
>  >  > of 'service' role and do not skip scope checks for 'service' role in
> oslo policy as it can be a valid role used
>  >  > by any users at production. So with the new SRBAC, heat needs to use
> the system scoped 'service' role token.
>  >  >
>  >  > But as 'service' role is not yet implemented by keystone[2], we can
> use the legacy admin token which is currently
>  >  > used in heat or other service-to-service interaction.
>  >  >
>  >  > Thanks gmann for inputs.
>  >  > HoweverI think we still need a different role here.
>  >  > The role I've mentioned here is not the role assigned to the Heat
> service user but the project-roleassigned to users to allow them create
> stacks with system resources like nova flavor or keystone user.This role is
> assigned to actual cloud users so service would not be appropriate.
>  >  >
>  >  > I thought of using the admin role initially but this means that we
> provide a way to "bypass" policy checkand expose system operations to
> project users.
>  >  >
>  >  > As a side note, current heat does not use its own credential but
> user credentials used for stack API calls.
>  >  > We can introduce this mechanism and let heat manage system resources
> by its service user but that isthe completely new feature we need to
> implement.
>  >
>  > Thanks for the detailed information. For service to service
> interaction, I think heat needs to start using the configured
>  > service user token instead of using actual user token.
>  >
>  > For example nova use for neutron and similarly for other service
> interaction
>  > -
> https://zuul.opendev.org/t/openstack/build/654ccb626d0e41a69308db1ed3328824/log/controller/logs/etc/nova/nova_conf.txt#40-51
>  >
>  > I'll look into that option but It might take some time because I've not
> yet evaluated the impact of that change.My current idea is to use service
> credentials for system resources only so that we can keep using the user
> credentialfor project resources.
>  >
>  > As heat allows only project users to manage stacks, we need to
> determine the project role to allow creatingstacks with such system
> resources. Does anyone have any suggestions about this ?
>  > Do we agree we can allow project-admin to create stacks with flavors or
> keystone users as the previous policy rulesallow or should we implement a
> new role to restrict management of system resources ?
>
> Currently, existing way of creating flavor with project user should work
> as Nova still support the legacy policy so yes
> project admin can do that. And on the new role, I think that is what the
> 'service' role will be.
>
> I think the question we are discussing here and on spec is what scope the
> project should use for 'service' role requests for
> their service-to-service interaction? IMO, it can be the same scope that
> calling APIs has. For heat example, heat can create
> a 'service' role with the 'system' scope and call Nova to create flavor.
> Another option is we skip the scope check for 'service'
> role as a special case but this can create issue when any production
> deployment has a role with the name of 'service'.
> Any other thoughts on this?
>

No. The current question is related to the scope used by the user creating
a stack.

"Stack" in heat is the resource belonging to individual projects, so it
should be created by project users.

If we introduce the mechanism to make the heat service user create system
resources like flavors on behalf
of that project user, Heat would allow project users(eg. project admin) to
create a flavor, while Nova doesn't allow it
and requires system admin.
We should consider what would be the appropriate project role required here.


> -gmann
>
>
>  >
>  >  -gmann
>  >
>  >  >  [1]
> http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026777.html
>  >  > [2] https://review.opendev.org/c/openstack/keystone-specs/+/818616
>  >  >
>  >  > -gmann
>  >  >
>  >  >  > >
>  >  >  > > Thank you,
>  >  >  > > Takashi
>  >  >  > >
>  >  >  >
>  >  >
>  >  >
>  >
>  >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220316/19e1b881/attachment-0001.htm>

From stephenfin at redhat.com  Tue Mar 15 16:29:45 2022
From: stephenfin at redhat.com (Stephen Finucane)
Date: Tue, 15 Mar 2022 16:29:45 +0000
Subject: [release] Independent release jobs are still using old release
 job templates
In-Reply-To: <bf15986abdd062c6d97fe09d0656ffe9e584274b.camel@redhat.com>
References: <bf15986abdd062c6d97fe09d0656ffe9e584274b.camel@redhat.com>
Message-ID: <82588b844335ff73fe8168b7f47210d881511b9d.camel@redhat.com>

On Fri, 2022-03-11 at 12:26 +0000, Stephen Finucane wrote:
> tl;dr: How do we get projects using the independent release process to use the
> openstack-python3 zuul job template corresponding to the latest release?

FYI, we've opted to go with the first option below (introducing an unversioned
job template that projects using the independent release process can use). This
was achieved via [1] which should merge shortly. I've pushed a number of patches
to fix this for various oslo- and sdk-affiliated projects [2]. I trust other
teams (puppet? charms?) can handle this for their own projects :)

Cheers,
Stephen

[1] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833286
[2] https://review.opendev.org/q/topic:add-python3-unversioned-jobs


> I've noticed a couple of patches like [1] popping up for oslo-affiliated projects.
> These projects are currently using the python3 zuul job templates corresponding
> to an older release (e.g. Wallaby) and the author is correctly updating them to
> use the most recent release. These initially caught me off-guard since I'm used
> to seeing a bot propose these changes but I've realized that all affected
> projects are using the "independent" release process and therefore don't receive
> a new stable branch nor related bot-proposed commits. This leaves us in a bit of
> a pickle though. There are a lot of projects using this release process, and
> there's effectively zero chance that someone is going to remember to bump the
> jobs every single release.
> 
> While some could argue that this is "working as designed", it seems important to
> me that we would be testing these projects against the supported runtimes for
> the release currently under development. As such, how should we try to address
> this? One option I see is to add a new generic 'openstack-python3-jobs' template
> which would always duplicate the jobs used for the current release. I've
> proposed that here [2]. There are some pros and cons to this approach:
> 
>  * PRO: Minimal effort from everyone.
>  * CON: The HEAD of master for each project could be broken and we'd never know
>    until some change was proposed to master (note: this is effectively the
>    status quo right now, so it's not a big break)
>  * CON: If those independent projects had an alternative to stable branches
>    (i.e. semver branches), those would eventually break as the runtimes kept
>    changing.
> 
> The other option is to extend the openstack bot to propose release bump patches
> against these independent projects. This has the inverse pro/con balance:
> 
>  * PRO: We get a regular "check-up" on the health of the project whenever these
>    patches are proposed.
>  * PRO: Long-lived stable branches should stay working
>  * CON: Lots of busy work for reviewers.
> 
> What are everyone's thoughts? I'm in favour of the first approach (generic
> 'openstack-python3-jobs' template) but the bot enhancement would also wfm. If we
> go with the first approach, we'd probably want to script something to "fix" all
> the existing independent projects rather than attempt to find and fix them
> manually.
> 
> Cheers,
> Stephen
> 
> PS: Apologies if this has been discussed previously. I clearly missed that
> discussion.
> 
> [1] https://review.opendev.org/c/openstack/os-api-ref/+/831560
> [2] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833286



From gmann at ghanshyammann.com  Tue Mar 15 17:50:06 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Tue, 15 Mar 2022 12:50:06 -0500
Subject: [release] Independent release jobs are still using old release
 job templates
In-Reply-To: <82588b844335ff73fe8168b7f47210d881511b9d.camel@redhat.com>
References: <bf15986abdd062c6d97fe09d0656ffe9e584274b.camel@redhat.com>
 <82588b844335ff73fe8168b7f47210d881511b9d.camel@redhat.com>
Message-ID: <17f8eb38de7.b3a071b8278017.1197493698223951007@ghanshyammann.com>

 ---- On Tue, 15 Mar 2022 11:29:45 -0500 Stephen Finucane <stephenfin at redhat.com> wrote ----
 > On Fri, 2022-03-11 at 12:26 +0000, Stephen Finucane wrote:
 > > tl;dr: How do we get projects using the independent release process to use the
 > > openstack-python3 zuul job template corresponding to the latest release?
 > 
 > FYI, we've opted to go with the first option below (introducing an unversioned
 > job template that projects using the independent release process can use). This
 > was achieved via [1] which should merge shortly. I've pushed a number of patches
 > to fix this for various oslo- and sdk-affiliated projects [2]. I trust other
 > teams (puppet? charms?) can handle this for their own projects :)

Sorry for seeing this thread late.

I think testing with latest is no different than updating them manually to the latest
release template either by bot or manually. As we use the constraint and add a
compatible version of these independent repos for each OpenStack release, I don't
think we have any case where new future version is not tested with a supported
runtime where that version will be used/documented as the compatible version for
XYZ OpenStack release. So +1 on option1.

Now thinking on this case also, these release-specific templates are causing more issues.
For example:
1. This case of independent releases repo
2. If bot missed proposing patches for some reason (like format. other release model or so) or patches
are not merged then we missed testing such repo with defined testing runtime.
3. branchless repo like PBR, Tempest has to test py version explicitly as they cannot use these
release-wise templates.

With all these issues should we just get rid of these release-specific templates and have this generic
template 'openstack-python3-jobs' with the latest testing runtime for master code testing and when
we cut the stable branch then we pin a version of this template with help of the branch variant in the
template definition (no list of jobs in that template as we cannot use branch variant for template). It
means we are cutting a new stable for OpenStack so let's pin the testing template also for that branch
(pin the same template as openstack-zuul-jobs are branchless) and branch variant can help us here.
And for the new master, move the current template to the latest testing runtime. This helps to avoid all
these bot patches and missing the latest testing running in the above-mentioned cases.
One drawback for this is we have to remember and make sure we pin this same template when cut stable.
But that effort is no different than defining the new template per release each time.

We made these release-specific templates to be very explicit in testing but it leads to testing old testing runtime
due to mentioned issues. Making them controllable in a central place helps to avoid that and also avoid these bot
patches and reviews in each repo. 

WIP Example: https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833892

Should we re-consider that option? 

-gmann

 > 
 > Cheers,
 > Stephen
 > 
 > [1] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833286
 > [2] https://review.opendev.org/q/topic:add-python3-unversioned-jobs
 > 
 > 
 > > I've noticed a couple of patches like [1] popping up for oslo-affiliated projects.
 > > These projects are currently using the python3 zuul job templates corresponding
 > > to an older release (e.g. Wallaby) and the author is correctly updating them to
 > > use the most recent release. These initially caught me off-guard since I'm used
 > > to seeing a bot propose these changes but I've realized that all affected
 > > projects are using the "independent" release process and therefore don't receive
 > > a new stable branch nor related bot-proposed commits. This leaves us in a bit of
 > > a pickle though. There are a lot of projects using this release process, and
 > > there's effectively zero chance that someone is going to remember to bump the
 > > jobs every single release.
 > > 
 > > While some could argue that this is "working as designed", it seems important to
 > > me that we would be testing these projects against the supported runtimes for
 > > the release currently under development. As such, how should we try to address
 > > this? One option I see is to add a new generic 'openstack-python3-jobs' template
 > > which would always duplicate the jobs used for the current release. I've
 > > proposed that here [2]. There are some pros and cons to this approach:
 > > 
 > >  * PRO: Minimal effort from everyone.
 > >  * CON: The HEAD of master for each project could be broken and we'd never know
 > >    until some change was proposed to master (note: this is effectively the
 > >    status quo right now, so it's not a big break)
 > >  * CON: If those independent projects had an alternative to stable branches
 > >    (i.e. semver branches), those would eventually break as the runtimes kept
 > >    changing.
 > > 
 > > The other option is to extend the openstack bot to propose release bump patches
 > > against these independent projects. This has the inverse pro/con balance:
 > > 
 > >  * PRO: We get a regular "check-up" on the health of the project whenever these
 > >    patches are proposed.
 > >  * PRO: Long-lived stable branches should stay working
 > >  * CON: Lots of busy work for reviewers.
 > > 
 > > What are everyone's thoughts? I'm in favour of the first approach (generic
 > > 'openstack-python3-jobs' template) but the bot enhancement would also wfm. If we
 > > go with the first approach, we'd probably want to script something to "fix" all
 > > the existing independent projects rather than attempt to find and fix them
 > > manually.
 > > 
 > > Cheers,
 > > Stephen
 > > 
 > > PS: Apologies if this has been discussed previously. I clearly missed that
 > > discussion.
 > > 
 > > [1] https://review.opendev.org/c/openstack/os-api-ref/+/831560
 > > [2] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/833286
 > 
 > 
 > 


From cboylan at sapwetik.org  Tue Mar 15 18:15:11 2022
From: cboylan at sapwetik.org (Clark Boylan)
Date: Tue, 15 Mar 2022 11:15:11 -0700
Subject: [infra] gerrit is:mergeable predicate
In-Reply-To: <888611ec-be6c-4c5c-89a0-ddbfc7b7066a@www.fastmail.com>
References: <c5b126c1-6f50-bcbb-09ee-a85406d7d7ad@gmail.com>
 <43f436b5-699c-4800-8121-af358cf7c1db@www.fastmail.com>
 <888611ec-be6c-4c5c-89a0-ddbfc7b7066a@www.fastmail.com>
Message-ID: <d29794e7-9412-4f7e-b554-140892b3e26c@www.fastmail.com>

On Tue, Feb 1, 2022, at 1:23 PM, Clark Boylan wrote:
> On Fri, Jan 28, 2022, at 4:08 PM, Clark Boylan wrote:
>> On Fri, Jan 28, 2022, at 3:51 PM, Brian Rosmaita wrote:
>>> Hello Infra team,
>>>
>>> In Gerrit 3.4, the is:mergeable predicate is disabled by default [0]. It 
>>> was kind of handy to be able to screen out patches that are in merge 
>>> conflict when looking for reviews.  Is there an alternative way of doing 
>>> this, or would you be averse to restoring the previous behavior?  (I 
>>> promise not to complain about gerrit performance.)
>>
>> This was brought up on IRC as well. My biggest concern with re-enabling 
>> it is that the cost is actually largely incurred when we reindex if I 
>> understand how Gerrit works. This means it is fine most of the time 
>> except for when we want to rename projects or upgrade and we need to do 
>> reindexing.
>>
>> Two smaller concerns are that Gerrit often makes changes like this then 
>> stops allowing you to modify the default, and the further you get away 
>> from default Gerrit the more bugs and upgrade fun you run into. I'm 
>> pretty sure the signed tag issue we ran into is because literally 
>> everyone else allows you to push regular tags and signed tags and 
>> doesn't force signed tags.
>>
>> All that said we'll be discussing it during our next meeting and will 
>> hopefully have a plan from there: 
>> https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting. Feel free to 
>> join us at 19:00 UTC in #opendev-meeting Tuesday February 1, 2022.
>
> To follow up on this we made the decision to go ahead and toggle the 
> configuration option to add this back in then work to mitigate some of 
> the concerns. In particular we'll communicate our desire to keep this 
> feature in Gerrit to Gerrit upstream. Hopefully, you'll see this 
> information again in Gerrit in the near future.

I forgot to followup on this thread to mention we re-enabled this functionality. You should see that changes pushed in the last week and a half get merge conflict checking performed against them. The query predicate should also work for you.

>
>>
>> Side note: Zuul also checks mergeability, but only when you trigger 
>> events that cause Zuul to take action.
>>
>>>
>>> cheers,
>>> brian
>>>
>>>
>>> [0] 
>>> https://www.gerritcodereview.com/3.4.html#ismergeable-predicate-is-disabled-per-default


From tonyliu0592 at hotmail.com  Tue Mar 15 18:19:35 2022
From: tonyliu0592 at hotmail.com (Tony Liu)
Date: Tue, 15 Mar 2022 18:19:35 +0000
Subject: [Glance] Xena and CEPH RBD backend (show_image_direct_url status )
In-Reply-To: <20220228140433.Horde.HqHowF97yyXPEK-I97zzVWP@webmail.nde.ag>
References: <PAYP264MB42561803BD94515768D5F356C43D9@PAYP264MB4256.FRAP264.PROD.OUTLOOK.COM>
 <20220228140433.Horde.HqHowF97yyXPEK-I97zzVWP@webmail.nde.ag>
Message-ID: <DM8PR14MB525665DE5C672FF5E2ADFB57BD109@DM8PR14MB5256.namprd14.prod.outlook.com>

Add [Glance] to attract attention from Glance experts.
It would be good someone could point out what change between Victoria and Wallaby
caused such break, and what's the plan to bring it back to work.

Thanks!
Tony
________________________________________
From: Eugen Block <eblock at nde.ag>
Sent: February 28, 2022 06:04 AM
To: openstack-discuss at lists.openstack.org
Subject: Re: Xena and CEPH RBD backend (show_image_direct_url status )

Hi,

it's disappointing that this is still an issue.
We're currently using OpenStack Ussuri with Ceph Nautilus (we plan the
Upgrade to Octopus soon) which works fine without enabling
show_image_direct_url. The same goes for Victoria and Octopus (one of
our customers uses this combination).


> How is the noted GRAVE Security RISK  of enabling
> Show_image_direct_url mitigated  ?  (i.e I think , for CEPH RBD, it
> needs to  be True to get cloning to work efficiently)

I'm also wondering in which case the location contains credentials, I
haven't seen that yet. Depending on how your cloud is used (is it a
public or private cloud) maybe enabling the option is not that big of
a risk?

Regards,
Eugen


Zitat von "west, andrew" <andrew.west-contractor at cgg.com>:

> Hello experts
>
> Currently using openstack Xena and Ceph backend (Pacific 16.2.7)
>
> It seems there is a bug (since Wallaby?) where the efficient use of
> a CEPH Pacific RBD backend (i.e with copy-on-write-cloning) is not
> working .
> Show_image_direct_url needs to be False to create volumes (or
> ephemeral volumes for nova)
>
> This can of course be tremendously slow (Nova  , ephemeral root
> disk) without copy-on-write cloning feature of Ceph.
>
> As Ceph RBD is THE most favourite  backend for block storage in
> openstack I am wondering how others are coping (or workarounds found
> ?)
> Which combinations of Openstack and Ceph  are known to work well
> with copy-on-write-cloning?
>
> How is the noted GRAVE Security RISK  of enabling
> Show_image_direct_url mitigated  ?  (i.e I think , for CEPH RBD, it
> needs to  be True to get cloning to work efficiently)
>
>
> See another report of this issue here:
> Re: Ceph Pacifif and Openstack Wallaby - ERROR
> cinder.scheduler.flows.create_volume - CEPH Filesystem Users
> (spinics.net)<https://www.spinics.net/lists/ceph-users/msg66016.html>
>
> Thanks for any help or pointers,
>
> Andrew West
> Openstack consulting
> CGG France
>
>
> ________________________________
> "This e-mail and any accompanying attachments are confidential. The
> information is intended solely for the use of the individual to whom
> it is addressed. Any review, disclosure, copying, distribution, or
> use of the email by others is strictly prohibited. If you are not
> the intended recipient, you must not review, disclose, copy,
> distribute or use this e-mail; please delete it from your system and
> notify the sender immediately."






From fungi at yuggoth.org  Tue Mar 15 20:04:21 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 15 Mar 2022 20:04:21 +0000
Subject: [release] Independent release jobs are still using old release
 job templates
In-Reply-To: <17f8eb38de7.b3a071b8278017.1197493698223951007@ghanshyammann.com>
References: <bf15986abdd062c6d97fe09d0656ffe9e584274b.camel@redhat.com>
 <82588b844335ff73fe8168b7f47210d881511b9d.camel@redhat.com>
 <17f8eb38de7.b3a071b8278017.1197493698223951007@ghanshyammann.com>
Message-ID: <20220315200421.pba5onvcbk7fg4gw@yuggoth.org>

On 2022-03-15 12:50:06 -0500 (-0500), Ghanshyam Mann wrote:
[...]
> With all these issues should we just get rid of these
> release-specific templates and have this generic template
> 'openstack-python3-jobs' with the latest testing runtime for
> master code testing and when we cut the stable branch then we pin
> a version of this template with help of the branch variant in the
> template definition (no list of jobs in that template as we cannot
> use branch variant for template).
[...]

The flip side of that coin is that every project has to switch to the
new jobs in master at the exact same moment, whether they're ready
or not, so they'll need to be prepared to set aside time to sort out
job failures before proceeding with their usual development.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220315/9be5103f/attachment.sig>

From zakhar at gmail.com  Tue Mar 15 20:08:30 2022
From: zakhar at gmail.com (Zakhar Kirpichenko)
Date: Tue, 15 Mar 2022 22:08:30 +0200
Subject: [Glance] Xena and CEPH RBD backend (show_image_direct_url status )
In-Reply-To: <DM8PR14MB525665DE5C672FF5E2ADFB57BD109@DM8PR14MB5256.namprd14.prod.outlook.com>
References: <PAYP264MB42561803BD94515768D5F356C43D9@PAYP264MB4256.FRAP264.PROD.OUTLOOK.COM>
 <20220228140433.Horde.HqHowF97yyXPEK-I97zzVWP@webmail.nde.ag>
 <DM8PR14MB525665DE5C672FF5E2ADFB57BD109@DM8PR14MB5256.namprd14.prod.outlook.com>
Message-ID: <CAEw-OTV2jgq1mQw0=c5Vd9CiU=pCJ2YjWAPJQqP=M6oFcj15+A@mail.gmail.com>

What's really disappointing is that there were several discussions about
this both in Ceph and Openstack communities over a period of more than a
year, but the issue persists and isn't getting any attention from either
"camp".

/Z

On Tue, Mar 15, 2022 at 8:22 PM Tony Liu <tonyliu0592 at hotmail.com> wrote:

> Add [Glance] to attract attention from Glance experts.
> It would be good someone could point out what change between Victoria and
> Wallaby
> caused such break, and what's the plan to bring it back to work.
>
> Thanks!
> Tony
> ________________________________________
> From: Eugen Block <eblock at nde.ag>
> Sent: February 28, 2022 06:04 AM
> To: openstack-discuss at lists.openstack.org
> Subject: Re: Xena and CEPH RBD backend (show_image_direct_url status )
>
> Hi,
>
> it's disappointing that this is still an issue.
> We're currently using OpenStack Ussuri with Ceph Nautilus (we plan the
> Upgrade to Octopus soon) which works fine without enabling
> show_image_direct_url. The same goes for Victoria and Octopus (one of
> our customers uses this combination).
>
>
> > How is the noted GRAVE Security RISK  of enabling
> > Show_image_direct_url mitigated  ?  (i.e I think , for CEPH RBD, it
> > needs to  be True to get cloning to work efficiently)
>
> I'm also wondering in which case the location contains credentials, I
> haven't seen that yet. Depending on how your cloud is used (is it a
> public or private cloud) maybe enabling the option is not that big of
> a risk?
>
> Regards,
> Eugen
>
>
> Zitat von "west, andrew" <andrew.west-contractor at cgg.com>:
>
> > Hello experts
> >
> > Currently using openstack Xena and Ceph backend (Pacific 16.2.7)
> >
> > It seems there is a bug (since Wallaby?) where the efficient use of
> > a CEPH Pacific RBD backend (i.e with copy-on-write-cloning) is not
> > working .
> > Show_image_direct_url needs to be False to create volumes (or
> > ephemeral volumes for nova)
> >
> > This can of course be tremendously slow (Nova  , ephemeral root
> > disk) without copy-on-write cloning feature of Ceph.
> >
> > As Ceph RBD is THE most favourite  backend for block storage in
> > openstack I am wondering how others are coping (or workarounds found
> > ?)
> > Which combinations of Openstack and Ceph  are known to work well
> > with copy-on-write-cloning?
> >
> > How is the noted GRAVE Security RISK  of enabling
> > Show_image_direct_url mitigated  ?  (i.e I think , for CEPH RBD, it
> > needs to  be True to get cloning to work efficiently)
> >
> >
> > See another report of this issue here:
> > Re: Ceph Pacifif and Openstack Wallaby - ERROR
> > cinder.scheduler.flows.create_volume - CEPH Filesystem Users
> > (spinics.net)<https://www.spinics.net/lists/ceph-users/msg66016.html>
> >
> > Thanks for any help or pointers,
> >
> > Andrew West
> > Openstack consulting
> > CGG France
> >
> >
> > ________________________________
> > "This e-mail and any accompanying attachments are confidential. The
> > information is intended solely for the use of the individual to whom
> > it is addressed. Any review, disclosure, copying, distribution, or
> > use of the email by others is strictly prohibited. If you are not
> > the intended recipient, you must not review, disclose, copy,
> > distribute or use this e-mail; please delete it from your system and
> > notify the sender immediately."
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220315/d748ea7d/attachment.htm>

From gmann at ghanshyammann.com  Tue Mar 15 20:12:18 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Tue, 15 Mar 2022 15:12:18 -0500
Subject: [release] Independent release jobs are still using old release
 job templates
In-Reply-To: <20220315200421.pba5onvcbk7fg4gw@yuggoth.org>
References: <bf15986abdd062c6d97fe09d0656ffe9e584274b.camel@redhat.com>
 <82588b844335ff73fe8168b7f47210d881511b9d.camel@redhat.com>
 <17f8eb38de7.b3a071b8278017.1197493698223951007@ghanshyammann.com>
 <20220315200421.pba5onvcbk7fg4gw@yuggoth.org>
Message-ID: <17f8f35c047.117bc18f0283118.4272133184134692149@ghanshyammann.com>

 ---- On Tue, 15 Mar 2022 15:04:21 -0500 Jeremy Stanley <fungi at yuggoth.org> wrote ----
 > On 2022-03-15 12:50:06 -0500 (-0500), Ghanshyam Mann wrote:
 > [...]
 > > With all these issues should we just get rid of these
 > > release-specific templates and have this generic template
 > > 'openstack-python3-jobs' with the latest testing runtime for
 > > master code testing and when we cut the stable branch then we pin
 > > a version of this template with help of the branch variant in the
 > > template definition (no list of jobs in that template as we cannot
 > > use branch variant for template).
 > [...]
 > 
 > The flip side of that coin is that every project has to switch to the
 > new jobs in master at the exact same moment, whether they're ready
 > or not, so they'll need to be prepared to set aside time to sort out
 > job failures before proceeding with their usual development.

That is a good thing right, fix the things for new python version testing before you
introduce more failure. And in the current template change by bot is also at the
start of the cycle and it usually gets merged before any other code on that master branch
merge which means no change in timing as such.

-gmann

 > -- 
 > Jeremy Stanley
 > 


From kennelson11 at gmail.com  Tue Mar 15 20:29:50 2022
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Tue, 15 Mar 2022 15:29:50 -0500
Subject: [PTG] April 2022 Teams List
Message-ID: <CAJ6yrQhPC3LLg5XoZH4OdwUERb5WMG+YCutm6Dwdai5HDbUV+A@mail.gmail.com>

Hello Everyone!

The April 2022 Project Teams List is official!

Ansible OpenStack modules
Barbican
Blazar
Cinder
CloudKitty
Cyborg
Designate
Diversity & Inclusion WG
First Contact SIG
Glance
Horizon
Interop
Ironic
Keystone
Kolla
Kuryr
Large Scale SIG
Manila
Neutron
Nova/Placement
Octavia
OpenInfra Edge Computing Group
OpenStack Charms
OpenStack Technical Committee
OpenStack-Ansible
OpenStack-Helm
QA
Release Management
SDK
Security SIG
StarlingX
Swift
Tacker
TripleO

If your team was planning to meet and isn?t in this list, please contact
ptg at openinfra.dev IMMEDIATELY.

Otherwise, please don't forget to register[1] because that's how you'll
receive event details, passwords, and other relevant information about the
PTG.

Please let us know if you have any questions!

Thanks!

-Kendall (diablo_rojo)

[1] PTG Registration: https://openinfra-ptg.eventbrite.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220315/1bc1fb5c/attachment.htm>

From akanevsk at redhat.com  Tue Mar 15 21:23:54 2022
From: akanevsk at redhat.com (Arkady Kanevsky)
Date: Tue, 15 Mar 2022 16:23:54 -0500
Subject: [PTG] April 2022 Teams List
In-Reply-To: <CAJ6yrQhPC3LLg5XoZH4OdwUERb5WMG+YCutm6Dwdai5HDbUV+A@mail.gmail.com>
References: <CAJ6yrQhPC3LLg5XoZH4OdwUERb5WMG+YCutm6Dwdai5HDbUV+A@mail.gmail.com>
Message-ID: <CAEbdGYM2FTwSU3X1fsLV5i4ZjSYrcxNf_QsDk=wFLhg9+4NjEw@mail.gmail.com>

Kendall,
do we have a central repository of etherpad for planning each PTG project?
Thanks,
Arkady

On Tue, Mar 15, 2022 at 3:31 PM Kendall Nelson <kennelson11 at gmail.com>
wrote:

> Hello Everyone!
>
> The April 2022 Project Teams List is official!
>
> Ansible OpenStack modules
> Barbican
> Blazar
> Cinder
> CloudKitty
> Cyborg
> Designate
> Diversity & Inclusion WG
> First Contact SIG
> Glance
> Horizon
> Interop
> Ironic
> Keystone
> Kolla
> Kuryr
> Large Scale SIG
> Manila
> Neutron
> Nova/Placement
> Octavia
> OpenInfra Edge Computing Group
> OpenStack Charms
> OpenStack Technical Committee
> OpenStack-Ansible
> OpenStack-Helm
> QA
> Release Management
> SDK
> Security SIG
> StarlingX
> Swift
> Tacker
> TripleO
>
> If your team was planning to meet and isn?t in this list, please contact
> ptg at openinfra.dev IMMEDIATELY.
>
> Otherwise, please don't forget to register[1] because that's how you'll
> receive event details, passwords, and other relevant information about the
> PTG.
>
> Please let us know if you have any questions!
>
> Thanks!
>
> -Kendall (diablo_rojo)
>
> [1] PTG Registration: https://openinfra-ptg.eventbrite.com
>


-- 
Arkady Kanevsky, Ph.D.
Phone: 972 707-6456
Corporate Phone: 919 729-5744 ext. 8176456
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220315/75a97eef/attachment-0001.htm>

From fungi at yuggoth.org  Tue Mar 15 21:46:49 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 15 Mar 2022 21:46:49 +0000
Subject: [tc][release][security-sig Removing TC tags framework
In-Reply-To: <CAKZ_x7_f00CvB28qQCz9yFy2H1PiA3C0fvQAVh9v6-3nAruzuQ@mail.gmail.com>
References: <CAKZ_x795heRnzJuFRXGLBC7jE5kuwHoDjvDD5zBa+k9xYSUeCw@mail.gmail.com>
 <cc65fbdd-c1f5-6539-0382-607de45439eb@est.tech>
 <CAKZ_x7_f00CvB28qQCz9yFy2H1PiA3C0fvQAVh9v6-3nAruzuQ@mail.gmail.com>
Message-ID: <20220315214649.5gh2vhchtsc3bqxu@yuggoth.org>

Note that this is complete for the vulnerability:managed tag now,
and the www.openstack.org site also no longer links to the
governance tag pages from individual project descriptions.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220315/85143227/attachment.sig>

From gagehugo at gmail.com  Tue Mar 15 22:32:27 2022
From: gagehugo at gmail.com (Gage Hugo)
Date: Tue, 15 Mar 2022 17:32:27 -0500
Subject: [openstack][keystone] Stepping down from core
In-Reply-To: <c1ecf522-951a-b5a0-5a11-af6423b33846@redhat.com>
References: <CAE4Awf_WpipFpn4F5ZdwmAQdfmXNxr_wO-1ZpnLXSM09CzgzNA@mail.gmail.com>
 <c1ecf522-951a-b5a0-5a11-af6423b33846@redhat.com>
Message-ID: <CAE4Awf8j-zibdaW9yfXHoqitS1KXq6zK1vyhX4PjfsXURC3+hg@mail.gmail.com>

Hey Doug,

I plan on continuing to work with the Security SIG for the time being.

On Fri, Mar 11, 2022 at 3:48 PM Douglas Mendizabal <dmendiza at redhat.com>
wrote:

> On 3/8/22 10:23, Gage Hugo wrote:
> > After some consideration and my focus shifting to other priorities, I
> > cannot reliably devote enough time to keystone so I'll be stepping down
> > from keystone core. I greatly appreciate the experiences I had to learn
> > and grow thanks to everyone's help.
> >
> > Thanks to you all and I'm grateful for the opportunities I've had with
> > the project and openstack as a whole. Hopefully we will get to
> > collaborate again more in the future.
> >
> > Gage Hugo
>
> Thank you for all the work you've done in the Keystone team.  You will
> definitely be missed.
>
> I was wondering if you'll still be around in the Security SIG, or if
> you're stepping down from that as well?
>
> Regards,
> - Doug
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220315/2df3f1bf/attachment.htm>

From tonyliu0592 at hotmail.com  Tue Mar 15 23:04:20 2022
From: tonyliu0592 at hotmail.com (Tony Liu)
Date: Tue, 15 Mar 2022 23:04:20 +0000
Subject: [Glance] Xena and CEPH RBD backend (show_image_direct_url status )
In-Reply-To: <PAYP264MB42561803BD94515768D5F356C43D9@PAYP264MB4256.FRAP264.PROD.OUTLOOK.COM>
References: <PAYP264MB42561803BD94515768D5F356C43D9@PAYP264MB4256.FRAP264.PROD.OUTLOOK.COM>
Message-ID: <DM8PR14MB5256BA11E1082FEDD112A6F6BD109@DM8PR14MB5256.namprd14.prod.outlook.com>

Hi Andrew,

When you say it's not working, any error messages to user, any error or failure logging from Glance or Cinder?
More details might help to look into it.

Thanks!
Tony
________________________________________
From: west, andrew <andrew.west-contractor at CGG.COM>
Sent: February 24, 2022 06:29 AM
To: openstack-discuss at lists.openstack.org
Subject: Xena and CEPH RBD backend  (show_image_direct_url status )

Hello experts

Currently using openstack Xena and Ceph backend (Pacific 16.2.7)

It seems there is a bug (since Wallaby?) where the efficient use of a CEPH Pacific RBD backend (i.e with copy-on-write-cloning) is not working .
Show_image_direct_url needs to be False to create volumes (or ephemeral volumes for nova)

This can of course be tremendously slow (Nova  , ephemeral root disk) without copy-on-write cloning feature of Ceph.

As Ceph RBD is THE most favourite  backend for block storage in openstack I am wondering how others are coping (or workarounds found ?)
Which combinations of Openstack and Ceph  are known to work well with copy-on-write-cloning?

How is the noted GRAVE Security RISK  of enabling Show_image_direct_url mitigated  ?  (i.e I think , for CEPH RBD, it needs to  be True to get cloning to work efficiently)


See another report of this issue here:
Re: Ceph Pacifif and Openstack Wallaby - ERROR cinder.scheduler.flows.create_volume ? CEPH Filesystem Users (spinics.net)<https://www.spinics.net/lists/ceph-users/msg66016.html>

Thanks for any help or pointers,

Andrew West
Openstack consulting
CGG France


________________________________
?This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of the email by others is strictly prohibited. If you are not the intended recipient, you must not review, disclose, copy, distribute or use this e-mail; please delete it from your system and notify the sender immediately.?


From kennelson11 at gmail.com  Wed Mar 16 02:03:26 2022
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Tue, 15 Mar 2022 21:03:26 -0500
Subject: [PTG] April 2022 Teams List
In-Reply-To: <CAEbdGYM2FTwSU3X1fsLV5i4ZjSYrcxNf_QsDk=wFLhg9+4NjEw@mail.gmail.com>
References: <CAJ6yrQhPC3LLg5XoZH4OdwUERb5WMG+YCutm6Dwdai5HDbUV+A@mail.gmail.com>
 <CAEbdGYM2FTwSU3X1fsLV5i4ZjSYrcxNf_QsDk=wFLhg9+4NjEw@mail.gmail.com>
Message-ID: <CAJ6yrQhEDux978ixxUzQfKnE+g_JASWKiwPp4vrC9-oTL_WGjQ@mail.gmail.com>

Yes! I am going to get them all generated tomorrow and you can use what's
generated or override it with the ptgbot on irc.

-Kendall

On Tue, Mar 15, 2022, 4:24 PM Arkady Kanevsky <akanevsk at redhat.com> wrote:

> Kendall,
> do we have a central repository of etherpad for planning each PTG project?
> Thanks,
> Arkady
>
> On Tue, Mar 15, 2022 at 3:31 PM Kendall Nelson <kennelson11 at gmail.com>
> wrote:
>
>> Hello Everyone!
>>
>> The April 2022 Project Teams List is official!
>>
>> Ansible OpenStack modules
>> Barbican
>> Blazar
>> Cinder
>> CloudKitty
>> Cyborg
>> Designate
>> Diversity & Inclusion WG
>> First Contact SIG
>> Glance
>> Horizon
>> Interop
>> Ironic
>> Keystone
>> Kolla
>> Kuryr
>> Large Scale SIG
>> Manila
>> Neutron
>> Nova/Placement
>> Octavia
>> OpenInfra Edge Computing Group
>> OpenStack Charms
>> OpenStack Technical Committee
>> OpenStack-Ansible
>> OpenStack-Helm
>> QA
>> Release Management
>> SDK
>> Security SIG
>> StarlingX
>> Swift
>> Tacker
>> TripleO
>>
>> If your team was planning to meet and isn?t in this list, please contact
>> ptg at openinfra.dev IMMEDIATELY.
>>
>> Otherwise, please don't forget to register[1] because that's how you'll
>> receive event details, passwords, and other relevant information about the
>> PTG.
>>
>> Please let us know if you have any questions!
>>
>> Thanks!
>>
>> -Kendall (diablo_rojo)
>>
>> [1] PTG Registration: https://openinfra-ptg.eventbrite.com
>>
>
>
> --
> Arkady Kanevsky, Ph.D.
> Phone: 972 707-6456
> Corporate Phone: 919 729-5744 ext. 8176456
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220315/7d64e8cb/attachment.htm>

From hiwkby at yahoo.com  Wed Mar 16 10:34:25 2022
From: hiwkby at yahoo.com (Hirotaka Wakabayashi)
Date: Wed, 16 Mar 2022 10:34:25 +0000 (UTC)
Subject: [dev] [trove] Bug fixed from master to stable branch and release?
References: <852605785.2015914.1647426865509.ref@mail.yahoo.com>
Message-ID: <852605785.2015914.1647426865509@mail.yahoo.com>

Hello, I am a Trove contributor. I proposed a cherry-pick and lxkong kindly
merged it yesterday! Could someone release the new version as 13.0.1?
Because I believe this bug is significant for users for some reasons.

1. I hit this bug :P
2. One relevant Issue from IRC https://meetings.opendev.org/irclogs/%23openstack-trove/%23openstack-trove.2022-03-11.log.html
3. One relevant issue from https://storyboard.openstack.org/#!/story/2006996
This patch is cherry-picked from master branch and I think this patch has
no risk of regression.

Thanks in advance,
Hirotaka


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220316/c1988e66/attachment-0001.htm>

From mnasiadka at gmail.com  Wed Mar 16 12:36:02 2022
From: mnasiadka at gmail.com (=?utf-8?Q?Micha=C5=82_Nasiadka?=)
Date: Wed, 16 Mar 2022 13:36:02 +0100
Subject: [kolla] Proposing frickler for Kolla and Kolla-Ansible core
Message-ID: <23DC7FD6-25DE-45D3-A000-E2049B8F1D91@gmail.com>

Hello,

Jens has been working on Kolla and Kolla-Ansible for some time already, and in that time he has delivered thoughtful reviews and useful patches.
He has been helping for many bugs fixes nowadays and having him as Core will help us to speed up the things.

I?d like to propose him for Kolla and Kolla-Ansible core reviewer.

You can vote/feedback on this email. If no objection by end of next week, I will add him to the list.

[1]: https://www.stackalytics.io/?module=kolla-group

From radoslaw.piliszek at gmail.com  Wed Mar 16 12:50:45 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Wed, 16 Mar 2022 13:50:45 +0100
Subject: [kolla] Proposing frickler for Kolla and Kolla-Ansible core
In-Reply-To: <23DC7FD6-25DE-45D3-A000-E2049B8F1D91@gmail.com>
References: <23DC7FD6-25DE-45D3-A000-E2049B8F1D91@gmail.com>
Message-ID: <CAKZ_x7-=_vGkmmJTe3XSTqNJBm6uawPwjwFf+=cArJ_WfHLC8A@mail.gmail.com>

+2

On Wed, 16 Mar 2022 at 13:38, Micha? Nasiadka <mnasiadka at gmail.com> wrote:
>
> Hello,
>
> Jens has been working on Kolla and Kolla-Ansible for some time already, and in that time he has delivered thoughtful reviews and useful patches.
> He has been helping for many bugs fixes nowadays and having him as Core will help us to speed up the things.
>
> I?d like to propose him for Kolla and Kolla-Ansible core reviewer.
>
> You can vote/feedback on this email. If no objection by end of next week, I will add him to the list.
>
> [1]: https://www.stackalytics.io/?module=kolla-group


From elod.illes at est.tech  Wed Mar 16 13:11:27 2022
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Wed, 16 Mar 2022 14:11:27 +0100
Subject: [blazar][release][requirements] blazar-nova and nova requirements
In-Reply-To: <CA+ny2sxjdBV8_fL4ZGGiwGHUHjDuFsXdFTaL28Ze6JREh1LtRg@mail.gmail.com>
References: <CA+ny2sxjdBV8_fL4ZGGiwGHUHjDuFsXdFTaL28Ze6JREh1LtRg@mail.gmail.com>
Message-ID: <7aa04776-ecd7-3adc-d1f8-7737feca6045@est.tech>

Hi,

Sorry for the late answer.

First of all we are in library freeze period already and blazar-nova is 
currently marked as library. Though a Requirements Freeze Exception 
might be granted (would need to check with Matthew), I think it's not 
necessary. This is mostly a problem when distros do their packaging, but 
I guess due to nova's lower constraints change they already need to use 
the higher minimums.

Some more comments:
- though requirements shouldn't be changed on stable branches in 
general, i think this can be backported *after* the final yoga release 
(to unblock the gate)
- I think release model change is OK and can be proposed for Zed cycle

Cheers,

El?d


On 2022. 03. 04. 17:36, Pierre Riteau wrote:
> Hello release team,
>
> blazar-nova is a package including a nova scheduler filter, which must 
> be installed together with nova to?be used.
>
> The blazar-nova deliverable for Yoga was tagged with?2.4.0 at the time 
> of the final release for non-client libraries. A few days ago, 
> stable/yoga patches were automatically proposed. This is when I 
> discovered that the lower-constraints job was broken because nova 
> bumped some requirements / lower-constraints after we released [1] 
> [2]. Because blazar-nova and nova are installed together, we keep our 
> requirements in sync for testing purposes.
>
> Now, I believe it is just the lower-constraints testing that is 
> broken, since nova requirements are still compatible with what 
> blazar-nova requires: nova just requires more recent versions of some 
> packages. I can run "pip install blazar-nova 
> git+https://opendev.org/openstack/nova.git at master#egg=nova" fine.
>
> I fixed the issue on the blazar-nova master branch [3] and proposed a 
> backport to stable/yoga [4], but realised this was probably breaking 
> release policy.
> Should we leave stable/yoga as released and just drop the 
> lower-constraints job?
>
> As an aside, would it be possible to requalify blazar-nova as a 
> cycle-with-rc deliverable for the next release? It is typed as a 
> library but nothing depends on it: if anything, it depends on nova itself.
>
> Thanks,
> Pierre Riteau (priteau)
>
> [1] https://review.opendev.org/c/openstack/nova/+/712139
> [2] https://review.opendev.org/c/openstack/nova/+/821606
> [3] https://review.opendev.org/c/openstack/blazar-nova/+/831741
> [4] https://review.opendev.org/c/openstack/blazar-nova/+/831832

From ih at imranh.co.uk  Wed Mar 16 13:14:26 2022
From: ih at imranh.co.uk (Imran Hussain)
Date: Wed, 16 Mar 2022 13:14:26 +0000
Subject: [kolla] Using variable in ceph confs
Message-ID: <53494e2f94c2884fa370764fc55fdad6@imranh.co.uk>

Hi All,

I'm storing my kolla conf in git and I want to avoid committing secrets.

As per the subject I'm using an external ceph.

I've created a patchset for this to be possible 
https://review.opendev.org/c/openstack/kolla-ansible/+/824566

Jens replied to it pretty fast but beyond saying 'I don't understand why 
you would want to do this' (paraphrased) gave no feedback.

I recently got some feedback from Michal after asking on IRC about it 
which was very helpful.

But this doesn't seem to be going anywhere, any advice on next steps?

Even if the feedback is 'no we don't want this' anything would be nice.

Thanks,
Imran



From thierry at openstack.org  Wed Mar 16 13:25:30 2022
From: thierry at openstack.org (Thierry Carrez)
Date: Wed, 16 Mar 2022 14:25:30 +0100
Subject: [blazar][release][requirements] blazar-nova and nova requirements
In-Reply-To: <7aa04776-ecd7-3adc-d1f8-7737feca6045@est.tech>
References: <CA+ny2sxjdBV8_fL4ZGGiwGHUHjDuFsXdFTaL28Ze6JREh1LtRg@mail.gmail.com>
 <7aa04776-ecd7-3adc-d1f8-7737feca6045@est.tech>
Message-ID: <5684cb62-02c0-c14b-0de9-2ed74d072a14@openstack.org>

Given that in practice it is not really a library, it's not listed in 
global-requirements, and we will likely switch its type next cycle, I 
would consider just allowing a new release to fix this.

It should not create any issue with requirements since nothing lists it 
as a dependency. It would not even need a RFE.

El?d Ill?s wrote:
> Hi,
> 
> Sorry for the late answer.
> 
> First of all we are in library freeze period already and blazar-nova is 
> currently marked as library. Though a Requirements Freeze Exception 
> might be granted (would need to check with Matthew), I think it's not 
> necessary. This is mostly a problem when distros do their packaging, but 
> I guess due to nova's lower constraints change they already need to use 
> the higher minimums.
> 
> Some more comments:
> - though requirements shouldn't be changed on stable branches in 
> general, i think this can be backported *after* the final yoga release 
> (to unblock the gate)
> - I think release model change is OK and can be proposed for Zed cycle
> 
> Cheers,
> 
> El?d
> 
> 
> On 2022. 03. 04. 17:36, Pierre Riteau wrote:
>> Hello release team,
>>
>> blazar-nova is a package including a nova scheduler filter, which must 
>> be installed together with nova to?be used.
>>
>> The blazar-nova deliverable for Yoga was tagged with?2.4.0 at the time 
>> of the final release for non-client libraries. A few days ago, 
>> stable/yoga patches were automatically proposed. This is when I 
>> discovered that the lower-constraints job was broken because nova 
>> bumped some requirements / lower-constraints after we released [1] 
>> [2]. Because blazar-nova and nova are installed together, we keep our 
>> requirements in sync for testing purposes.
>>
>> Now, I believe it is just the lower-constraints testing that is 
>> broken, since nova requirements are still compatible with what 
>> blazar-nova requires: nova just requires more recent versions of some 
>> packages. I can run "pip install blazar-nova 
>> git+https://opendev.org/openstack/nova.git at master#egg=nova" fine.
>>
>> I fixed the issue on the blazar-nova master branch [3] and proposed a 
>> backport to stable/yoga [4], but realised this was probably breaking 
>> release policy.
>> Should we leave stable/yoga as released and just drop the 
>> lower-constraints job?
>>
>> As an aside, would it be possible to requalify blazar-nova as a 
>> cycle-with-rc deliverable for the next release? It is typed as a 
>> library but nothing depends on it: if anything, it depends on nova 
>> itself.
>>
>> Thanks,
>> Pierre Riteau (priteau)
>>
>> [1] https://review.opendev.org/c/openstack/nova/+/712139
>> [2] https://review.opendev.org/c/openstack/nova/+/821606
>> [3] https://review.opendev.org/c/openstack/blazar-nova/+/831741
>> [4] https://review.opendev.org/c/openstack/blazar-nova/+/831832


-- 
Thierry Carrez (ttx)


From ekuvaja at redhat.com  Wed Mar 16 13:33:05 2022
From: ekuvaja at redhat.com (Erno Kuvaja)
Date: Wed, 16 Mar 2022 13:33:05 +0000
Subject: Xena and CEPH RBD backend (show_image_direct_url status )
In-Reply-To: <PAYP264MB42561803BD94515768D5F356C43D9@PAYP264MB4256.FRAP264.PROD.OUTLOOK.COM>
References: <PAYP264MB42561803BD94515768D5F356C43D9@PAYP264MB4256.FRAP264.PROD.OUTLOOK.COM>
Message-ID: <CAKwVDDNPd3dT7Qf4iQ5__tTXVppb+krQ5keK2rxRhh36otXHvg@mail.gmail.com>

On Thu, Feb 24, 2022 at 2:37 PM west, andrew <andrew.west-contractor at cgg.com>
wrote:

> Hello experts
>
>
>
> Currently using openstack Xena and Ceph backend (Pacific 16.2.7)
>
>
>
> It seems there is a bug (since Wallaby?) where the efficient use of a CEPH
> Pacific RBD backend (i.e with copy-on-write-cloning) is not working .
>
> Show_image_direct_url needs to be False to create volumes (or ephemeral
> volumes for nova)
>
>
>
> This can of course be tremendously slow (Nova  , ephemeral root disk)
> without copy-on-write cloning feature of Ceph.
>
>
>
> As Ceph RBD is THE most favourite  backend for block storage in openstack
> I am wondering how others are coping (or workarounds found ?)
>
> Which combinations of Openstack and Ceph  are known to work well with
> copy-on-write-cloning?
>
>
>
> How is the noted *GRAVE Security RISK  of enabling *Show_image_direct_url
> mitigated  ?  (i.e I think , for CEPH RBD, it needs to  be True to get
> cloning to work efficiently)
>
>
>
>
>
> See another report of this issue here:
>
> Re: Ceph Pacifif and Openstack Wallaby - ERROR
> cinder.scheduler.flows.create_volume ? CEPH Filesystem Users (spinics.net)
> <https://www.spinics.net/lists/ceph-users/msg66016.html>
>
>
>
> Thanks for any help or pointers,
>
>
>
> Andrew West
>
> Openstack consulting
>
> CGG France
>
>
>
>
> ------------------------------
> ?This e-mail and any accompanying attachments are confidential. The
> information is intended solely for the use of the individual to whom it is
> addressed. Any review, disclosure, copying, distribution, or use of the
> email by others is strictly prohibited. If you are not the intended
> recipient, you must not review, disclose, copy, distribute or use this
> e-mail; please delete it from your system and notify the sender
> immediately.?
>

Hi Andrew,

Sorry for the delayed reply. I got distracted and forgot after the first
time I noticed this.

So far I see you only mentioning 'show_image_direct_url' setting but AFAIK
also the 'show_multiple_locations' is required for these features to work,
is that set true and the issue still persists?

- jokke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220316/3900b0ac/attachment-0001.htm>

From tecno at charne.net  Wed Mar 16 13:42:43 2022
From: tecno at charne.net (Tecnologia Charne.Net)
Date: Wed, 16 Mar 2022 10:42:43 -0300
Subject: Xena and CEPH RBD backend (show_image_direct_url status )
In-Reply-To: <CAKwVDDNPd3dT7Qf4iQ5__tTXVppb+krQ5keK2rxRhh36otXHvg@mail.gmail.com>
References: <PAYP264MB42561803BD94515768D5F356C43D9@PAYP264MB4256.FRAP264.PROD.OUTLOOK.COM>
 <CAKwVDDNPd3dT7Qf4iQ5__tTXVppb+krQ5keK2rxRhh36otXHvg@mail.gmail.com>
Message-ID: <bb54a2db-080d-75c5-ba96-6b1884b914af@charne.net>

Hello, Andrew & Joke:

I have the same problem.

If I enable

show_image_direct_url = True
show_multiple_locations = True

on /etc/glance/glance-api.conf

When I create an instance from image, I get:

[Error: Build of instance 5855874c-860c-4ab8-8b3f-08970e220806 aborted: 
Volume 0367557b-4efc-40ab-8fda-932ce0a9f542 did not finish being created 
even after we waited 3 seconds or 2 attempts. And its status is error.].


Thanks!


El 16/3/22 a las 10:33, Erno Kuvaja escribi?:
> On Thu, Feb 24, 2022 at 2:37 PM west, andrew 
> <andrew.west-contractor at cgg.com> wrote:
>
>     Hello experts
>
>     Currently using openstack Xena and Ceph backend (Pacific 16.2.7)
>
>     It seems there is a bug (since Wallaby?) where the efficient use
>     of a CEPH Pacific RBD backend (i.e with copy-on-write-cloning) is
>     not working .
>
>     Show_image_direct_url needs to be False to create volumes (or
>     ephemeral volumes for nova)
>
>     This can of course be tremendously slow (Nova? , ephemeral root
>     disk) without copy-on-write cloning feature of Ceph.
>
>     As Ceph RBD is THE most favourite ?backend for block storage in
>     openstack I am wondering how others are coping (or workarounds
>     found ?)
>
>     Which combinations of Openstack and Ceph ?are known to work well
>     with copy-on-write-cloning?
>
>     How is the noted /GRAVE Security RISK ?of enabling
>     /Show_image_direct_url mitigated? ?? (i.e I think , for CEPH RBD,
>     it needs to? be True to get cloning to work efficiently)
>
>     See another report of this issue here:
>
>     Re: Ceph Pacifif and Openstack Wallaby - ERROR
>     cinder.scheduler.flows.create_volume ? CEPH Filesystem Users
>     (spinics.net) <https://www.spinics.net/lists/ceph-users/msg66016.html>
>
>     Thanks for any help or pointers,
>
>     Andrew West
>
>     Openstack consulting
>
>     CGG France
>
>     ------------------------------------------------------------------------
>     ?This e-mail and any accompanying attachments are confidential.
>     The information is intended solely for the use of the individual
>     to whom it is addressed. Any review, disclosure, copying,
>     distribution, or use of the email by others is strictly
>     prohibited. If you are not the intended recipient, you must not
>     review, disclose, copy, distribute or use this e-mail; please
>     delete it from your system and notify the sender immediately.?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220316/092fec77/attachment.htm>

From elod.illes at est.tech  Wed Mar 16 14:04:09 2022
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Wed, 16 Mar 2022 15:04:09 +0100
Subject: [blazar][release][requirements] blazar-nova and nova requirements
In-Reply-To: <5684cb62-02c0-c14b-0de9-2ed74d072a14@openstack.org>
References: <CA+ny2sxjdBV8_fL4ZGGiwGHUHjDuFsXdFTaL28Ze6JREh1LtRg@mail.gmail.com>
 <7aa04776-ecd7-3adc-d1f8-7737feca6045@est.tech>
 <5684cb62-02c0-c14b-0de9-2ed74d072a14@openstack.org>
Message-ID: <1ba1c3e1-cee1-0a99-8edf-6405ed9c6f30@est.tech>

Thanks Thierry, you are right. Let's release then!

El?d

On 2022. 03. 16. 14:25, Thierry Carrez wrote:
> Given that in practice it is not really a library, it's not listed in 
> global-requirements, and we will likely switch its type next cycle, I 
> would consider just allowing a new release to fix this.
>
> It should not create any issue with requirements since nothing lists 
> it as a dependency. It would not even need a RFE.
>
> El?d Ill?s wrote:
>> Hi,
>>
>> Sorry for the late answer.
>>
>> First of all we are in library freeze period already and blazar-nova 
>> is currently marked as library. Though a Requirements Freeze 
>> Exception might be granted (would need to check with Matthew), I 
>> think it's not necessary. This is mostly a problem when distros do 
>> their packaging, but I guess due to nova's lower constraints change 
>> they already need to use the higher minimums.
>>
>> Some more comments:
>> - though requirements shouldn't be changed on stable branches in 
>> general, i think this can be backported *after* the final yoga 
>> release (to unblock the gate)
>> - I think release model change is OK and can be proposed for Zed cycle
>>
>> Cheers,
>>
>> El?d
>>
>>
>> On 2022. 03. 04. 17:36, Pierre Riteau wrote:
>>> Hello release team,
>>>
>>> blazar-nova is a package including a nova scheduler filter, which 
>>> must be installed together with nova to?be used.
>>>
>>> The blazar-nova deliverable for Yoga was tagged with?2.4.0 at the 
>>> time of the final release for non-client libraries. A few days ago, 
>>> stable/yoga patches were automatically proposed. This is when I 
>>> discovered that the lower-constraints job was broken because nova 
>>> bumped some requirements / lower-constraints after we released [1] 
>>> [2]. Because blazar-nova and nova are installed together, we keep 
>>> our requirements in sync for testing purposes.
>>>
>>> Now, I believe it is just the lower-constraints testing that is 
>>> broken, since nova requirements are still compatible with what 
>>> blazar-nova requires: nova just requires more recent versions of 
>>> some packages. I can run "pip install blazar-nova 
>>> git+https://opendev.org/openstack/nova.git at master#egg=nova" fine.
>>>
>>> I fixed the issue on the blazar-nova master branch [3] and proposed 
>>> a backport to stable/yoga [4], but realised this was probably 
>>> breaking release policy.
>>> Should we leave stable/yoga as released and just drop the 
>>> lower-constraints job?
>>>
>>> As an aside, would it be possible to requalify blazar-nova as a 
>>> cycle-with-rc deliverable for the next release? It is typed as a 
>>> library but nothing depends on it: if anything, it depends on nova 
>>> itself.
>>>
>>> Thanks,
>>> Pierre Riteau (priteau)
>>>
>>> [1] https://review.opendev.org/c/openstack/nova/+/712139
>>> [2] https://review.opendev.org/c/openstack/nova/+/821606
>>> [3] https://review.opendev.org/c/openstack/blazar-nova/+/831741
>>> [4] https://review.opendev.org/c/openstack/blazar-nova/+/831832
>
>

From ahmedabdelhamid1221 at gmail.com  Tue Mar 15 23:18:21 2022
From: ahmedabdelhamid1221 at gmail.com (Ahmed Abdelhamid)
Date: Tue, 15 Mar 2022 19:18:21 -0400
Subject: Metadata service {devices list}
In-Reply-To: <CAECr9X5AOUOBYRQoibP=Ryp1LXz5n-6j45Ax_9E+eSOKaB2KEg@mail.gmail.com>
References: <CAMRGJtetgCKOCZ2WDZUJ8dWWJDufODOXZ=ia3s_KegiVp1A64g@mail.gmail.com>
 <CAECr9X5AOUOBYRQoibP=Ryp1LXz5n-6j45Ax_9E+eSOKaB2KEg@mail.gmail.com>
Message-ID: <CAMRGJte3kCRSyZwoTut1pqppr3p7czzjmEWk0j3EgZvo=m37Kw@mail.gmail.com>

Hi Rodolfo,

I am using neutron-linuxbridge-agent, and vlan networks for tenants

Thanks

On Tue, Mar 15, 2022 at 9:45 AM Rodolfo Alonso Hernandez <
ralonsoh at redhat.com> wrote:

> Hello Ahmed:
>
> What network backend are you using?
>
> Regards.
>
> On Tue, Mar 15, 2022 at 2:22 PM Ahmed Abdelhamid <
> ahmedabdelhamid1221 at gmail.com> wrote:
>
>> Hi All,
>>
>> I am running into a strange issue with the metadata service. Per metadata-service
>> manual <https://docs.openstack.org/nova/latest/user/metadata.html>, the
>> devices attached to a VM should be visible in
>>
>> $ curl http://169.254.169.254/openstack/2018-08-27/meta_data.json
>>
>> However, whenever i execute it from a VM , the devices array is empty and
>> looks like this, any idea why ?
>>
>> Thanks
>>
>> {   "random_seed": "yu5ZnkqF2CqnDZVAfZgarG...",   "availability_zone": "nova",   "keys": [       {         "data": "ssh-rsa AAAAB3NzaC1y...== Generated by Nova\n",         "type": "ssh",         "name": "mykey"       }   ],   "hostname": "test.novalocal",   "launch_index": 0,   "meta": {      "priority": "low",      "role": "webserver"   },   "devices": [ ],   "project_id": "f7ac731cc11f40efbc03a9f9e1d1d21f",   "public_keys": {       "mykey": "ssh-rsa AAAAB3NzaC1y...== Generated by Nova\n"   },   "name": "test"}
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220315/5d2a0a3e/attachment-0001.htm>

From rosmaita.fossdev at gmail.com  Wed Mar 16 15:40:22 2022
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Wed, 16 Mar 2022 11:40:22 -0400
Subject: [cinder] festival of XS reviews 18 March 2022
Message-ID: <ce6ba1a8-1965-3fd6-ce86-a20facc224e4@gmail.com>

Hello Argonauts,

Just in case there's anyone out there who has not used the handy ICS 
file [0] to have this event on their personal calendars:

The most recent edition of the Cinder Festival of XS Reviews will be 
held on this coming Friday (18 March).

who: Everyone!
what: The Cinder Festival of XS Reviews
when: Friday 18 March 2022 from 1400-1600 UTC
where: https://meetpad.opendev.org/cinder-festival-of-reviews
etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews


See you there!
brian


[0] http://eavesdrop.openstack.org/calendars/cinder-festival-of-reviews.ics


From zigo at debian.org  Wed Mar 16 16:08:07 2022
From: zigo at debian.org (Thomas Goirand)
Date: Wed, 16 Mar 2022 17:08:07 +0100
Subject: [announce][debian] OpenStack Yoga preview Debian packages are ready
Message-ID: <c0dff748-80e2-62da-0350-2f5f2a42819c@debian.org>

Hi,

Today, my first Yoga VM pings. I haven't done the Tempest/refstack work 
yet, but it's ongoing. In the mean time, anyone can already try and use 
the packages as a preview for the Yoga release. They are available 
through extrepo as usual, or from the osbpo.debian.net repo directly:

apt-get install extrepo
extrepo enable openstack_yoga
apt-get update

I'll make a proper announcement once we pass all Refstack tests.

Note this is a record-breaking availability, as the RCs were published 
only at the end of last week. So thanks everyone for this very smooth 
release.

Also to be noted: a few packages are missing, due to unit test failures: 
magnum, murano, trove, sahara and zaqar. Many of these unit tests fall 
in the debtcollector that wines about "tenant" not "projects". I'll 
investigate these later on, but they seem of no real consequence, so I 
may just skip them.

See you in Berlin!

Cheers,

Thomas Goirand (zigo)


From marcin.juszkiewicz at linaro.org  Wed Mar 16 16:19:12 2022
From: marcin.juszkiewicz at linaro.org (Marcin Juszkiewicz)
Date: Wed, 16 Mar 2022 17:19:12 +0100
Subject: [kolla] Proposing frickler for Kolla and Kolla-Ansible core
In-Reply-To: <23DC7FD6-25DE-45D3-A000-E2049B8F1D91@gmail.com>
References: <23DC7FD6-25DE-45D3-A000-E2049B8F1D91@gmail.com>
Message-ID: <a438b6a7-2fe6-a455-2d1c-0d6b47cfa549@linaro.org>

W dniu 16.03.2022 o?13:36, Micha? Nasiadka pisze:
> Hello,
> 
> Jens has been working on Kolla and Kolla-Ansible for some time already

> I?d like to propose him for Kolla and Kolla-Ansible core reviewer.

+2


From gmann at ghanshyammann.com  Wed Mar 16 16:30:35 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 16 Mar 2022 11:30:35 -0500
Subject: [heat][rbac] Management of "system resources" with SRBAC enforced
In-Reply-To: <CAL_crJQzbosuh19cm6yC23Aiwhs3M5dyX_wFv=rEdLxTSF=ZTg@mail.gmail.com>
References: <CAL_crJSy6_-+0oLZC1PP=RoE-2fNMn0jytsv9UxJOZ2BxYbeeQ@mail.gmail.com>
 <CA+WCyyovVWVhudrs0RGzoKedH7DdRCjgR1dEF5icK9Epr7XOEQ@mail.gmail.com>
 <CAL_crJSPv3pmJ31DVJKSurVOLGZM5MOtfapKN1s+DxA-Yhr7AQ@mail.gmail.com>
 <17f6fd5cf65.b558d8a025830.2422670910290295781@ghanshyammann.com>
 <CAL_crJR7rLqGoOe8oq=jiVvLQoeGq0Pe=3CPnUNaz6sV29wKUw@mail.gmail.com>
 <17f71638687.128ce54ec34578.5876409253282361143@ghanshyammann.com>
 <CAL_crJShD7Th6Q0UQtmCwJfSgdKtDkcY_wBdYMc4CA+j6a0R8g@mail.gmail.com>
 <17f8e2d9264.10dd328d5267246.555045975862118639@ghanshyammann.com>
 <CAL_crJQzbosuh19cm6yC23Aiwhs3M5dyX_wFv=rEdLxTSF=ZTg@mail.gmail.com>
Message-ID: <17f93911e89.d7b72e0d346322.6491753934261633069@ghanshyammann.com>

 ---- On Tue, 15 Mar 2022 10:45:05 -0500 Takashi Kajinami <tkajinam at redhat.com> wrote ----
 > 
 > 
 > On Wed, Mar 16, 2022 at 12:23 AM Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
 >  ---- On Wed, 09 Mar 2022 19:28:03 -0600 Takashi Kajinami <tkajinam at redhat.com> wrote ----
 >  > 
 >  > 
 >  > On Thu, Mar 10, 2022 at 10:13 AM Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
 >  >  ---- On Wed, 09 Mar 2022 17:14:02 -0600 Takashi Kajinami <tkajinam at redhat.com> wrote ----
 >  >  > 
 >  >  > 
 >  >  > On Thu, Mar 10, 2022 at 2:59 AM Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
 >  >  >  ---- On Wed, 09 Mar 2022 06:43:03 -0600 Takashi Kajinami <tkajinam at redhat.com> wrote ----
 >  >  >  > Hi Rico.
 >  >  >  > Thank you for your insights.Please find my replies inline.
 >  >  >  > 
 >  >  >  > On Wed, Mar 9, 2022 at 6:22 PM Rico Lin <ricolin at ricolky.com> wrote:
 >  >  >  > 
 >  >  >  > 
 >  >  >  > On Wed, Mar 9, 2022 at 1:57 PM Takashi Kajinami <tkajinam at redhat.com> wrote:
 >  >  >  > >
 >  >  >  > > Hello,
 >  >  >  > >
 >  >  >  > >
 >  >  >  > > I've been working on updating policy rules in heat according to the latest
 >  >  >  > > guideline for SRBAC implementation.
 >  >  >  > 
 >  >  >  > Thanks so much for working on it, definitely +1 on enhancing security.
 >  >  >  > >
 >  >  >  > >  [1] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#direction-change
 >  >  >  > >
 >  >  >  > > However this change reveals one potential issue with system resources.
 >  >  >  > >
 >  >  >  > > In heat there are some resource types like OS::Nova::Flavor or OS::Keystone::User
 >  >  >  > > which is allowed for only system users. (I'll call these resources as "system resources" here)
 >  >  >  > We create those resources based on checking `role:admin`, so project admin is accepted.This means a user under that project with role:admin, can operate those resources.I'm not sure what system user means here, so correct me if I'm wrong.
 >  >  >  > The core problem is that backend services like nova enforces different policies from just role:admin whenSRBAC is enforced. I reported that a while ago as https://storyboard.openstack.org/#!/story/2009787 .
 >  >  >  > 
 >  >  >  > The main problem here is that heat currently supports resources which require different scopes of credentials.For example, once all deprecated policy rules are removed, nova allows project users to create instances(OS::Nova::Server)[1],while nova allows only system admins to create flavors(OS::Nova::Flavor)[2]. Currently Heat leverages the user credentialused to create a stack when Heat requests backend services to create its resources, and it's "impossible" to create a stackwith these two resources by a single credential (as each token can be scoped by project or system.
 >  >  >  > [1] https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/servers.py#L210[2] https://github.com/openstack/nova/blob/d1b036fdb124d1ef48f5cf024d4677bfe5b481d7/nova/policies/flavor_manage.py#L28-L36
 >  >  >  > If we keep allowing system users to create stacks, then it would allow users to create system resourceslike flavors. But this never solves the problem with the "mixed" pattern which I described above.Hope this will explain these three options more clearly.
 >  >  >  >  
 >  >  >  > >
 >  >  >  > > Because heat uses user credentials to create resources in backend services, if we require
 >  >  >  > > project scope for stack/resource management then we are no longer able to create these system
 >  >  >  > > resources as part of stack. (*1)>
 >  >  >  > > There are some options I can think of at this moment.
 >  >  >  > >
 >  >  >  > > 1. Deprecate and remove all resources which require system scope
 >  >  >  > > Pros
 >  >  >  > > - This is most easy solution to be implemented
 >  >  >  > > Cons
 >  >  >  > > - This one has the biggest user impact
 >  >  >  > 
 >  >  >  > Don't :)
 >  >  > 
 >  >  > Yeah, not sure how removing will work.
 >  >  > 
 >  >  >  > > 2. Use service credential for resource creation
 >  >  >  > > Pros:
 >  >  >  > > - This might have smallest user impact
 >  >  >  > > Cons:
 >  >  >  > > - This requires a relatively big change in heat's architecture, which I've not yet evaluated.
 >  >  >  > > - We need to determine the project scope role to be allowed to do system operation.
 >  >  >  > >  
 >  >  >  > I think this is something we can discuss more.
 >  >  >  > > 3. Implement additional project-role in each service to allow creation via stack creation.
 >  >  >  > > Pros:
 >  >  >  > > - This would avoid user impact.
 >  >  >  > > Cons:
 >  >  >  > > - requires work in multiple components.
 >  >  >  > > - We need to determine the project scope role to be allowed to do system operation
 >  >  >  > 
 >  >  >  > 
 >  >  >  > Indeed current stack operation require `(role:admin and system_scope:all) OR (role:member and project_id:%(project_id)s)`.And if we remove the system part and keep `(role:member and project_id:%(project_id)s)`, will mean only a user in that project with a member role can operate stack, and if the user got also admin role, that user can manage User/Flavor resources through stack too.The main problem here is that nova will no longer allow project admins to create flavors,and it will require system admin when SRBAC is enforced(which means all deprecated rulesare disabled)
 >  >  >  >  
 >  >  >  > Also, note thatFor the case of Nova::Flavor, both policies from Nova and Heat resource will be enforced here, so it only accepts the intersection part of rules.
 >  >  >  > So if we go with removing the system admin, that means it's time to also remove some deprecated global scope operation.
 >  >  >  > IMO, to accept Project Admin or member make more reasonable (like you proposed in option 3)
 >  >  > 
 >  >  > This is a similar case that we discussed in the service role ML thread[1] or in the spec[2].
 >  >  > 
 >  >  > For such cases only, where services need to interact with another service we will have the 'service' as
 >  >  > a special role. In this case, the heat having the project scoped token will use the 'service' role token for
 >  >  > Nova Flavor APIs calls.  Now whether that 'service' role token needs to be system scoped or not is
 >  >  > open question Mark brought up in that discussion. IMO, we should use the scoped token even in case
 >  >  > of 'service' role and do not skip scope checks for 'service' role in oslo policy as it can be a valid role used
 >  >  > by any users at production. So with the new SRBAC, heat needs to use the system scoped 'service' role token.
 >  >  > 
 >  >  > But as 'service' role is not yet implemented by keystone[2], we can use the legacy admin token which is currently
 >  >  > used in heat or other service-to-service interaction. 
 >  >  > 
 >  >  > Thanks gmann for inputs.
 >  >  > HoweverI think we still need a different role here.
 >  >  > The role I've mentioned here is not the role assigned to the Heat service user but the project-roleassigned to users to allow them create stacks with system resources like nova flavor or keystone user.This role is assigned to actual cloud users so service would not be appropriate.
 >  >  > 
 >  >  > I thought of using the admin role initially but this means that we provide a way to "bypass" policy checkand expose system operations to project users.
 >  >  > 
 >  >  > As a side note, current heat does not use its own credential but user credentials used for stack API calls. 
 >  >  > We can introduce this mechanism and let heat manage system resources by its service user but that isthe completely new feature we need to implement.
 >  > 
 >  > Thanks for the detailed information. For service to service interaction, I think heat needs to start using the configured
 >  > service user token instead of using actual user token.
 >  > 
 >  > For example nova use for neutron and similarly for other service interaction
 >  > - https://zuul.opendev.org/t/openstack/build/654ccb626d0e41a69308db1ed3328824/log/controller/logs/etc/nova/nova_conf.txt#40-51
 >  > 
 >  > I'll look into that option but It might take some time because I've not yet evaluated the impact of that change.My current idea is to use service credentials for system resources only so that we can keep using the user credentialfor project resources. 
 >  > 
 >  > As heat allows only project users to manage stacks, we need to determine the project role to allow creatingstacks with such system resources. Does anyone have any suggestions about this ?
 >  > Do we agree we can allow project-admin to create stacks with flavors or keystone users as the previous policy rulesallow or should we implement a new role to restrict management of system resources ?
 > 
 > Currently, existing way of creating flavor with project user should work as Nova still support the legacy policy so yes
 > project admin can do that. And on the new role, I think that is what the 'service' role will be.
 > 
 > I think the question we are discussing here and on spec is what scope the project should use for 'service' role requests for
 > their service-to-service interaction? IMO, it can be the same scope that calling APIs has. For heat example, heat can create
 > a 'service' role with the 'system' scope and call Nova to create flavor.  Another option is we skip the scope check for 'service'
 > role as a special case but this can create issue when any production deployment has a role with the name of 'service'.
 > Any other thoughts on this?
 >  No. The current question is related to the scope used by the user creating a stack. 
 > 
 > "Stack" in heat is the resource belonging to individual projects, so it should be created by project users.
 > If we introduce the mechanism to make the heat service user create system resources like flavors on behalfof that project user, Heat would allow project users(eg. project admin) to create a flavor, while Nova doesn't allow itand requires system admin.We should consider what would be the appropriate project role required here.

Yeah, I understand the issue. I am not a Heat expert but from APIs point of view these kinds of APIs need more
granularity especially when an APIs for creating one resource create another resource in other service and user
might not be aware of that. If it cannot be made granular form Heat perspective then we may want to think of
a special role like you suggested.

I am not sure how many such examples (creating different resources in other services and with different scope operations)
we have like this for other service-to-service interactions (at least not in nova).

I am adding it for the keystone PTG etherpad and let's discuss this case along with the general 'service' role case.

-gmann

 >  -gmann
 > 
 > 
 >  > 
 >  >  -gmann
 >  > 
 >  >  >  [1] http://lists.openstack.org/pipermail/openstack-discuss/2022-January/026777.html
 >  >  > [2] https://review.opendev.org/c/openstack/keystone-specs/+/818616
 >  >  > 
 >  >  > -gmann
 >  >  > 
 >  >  >  > >
 >  >  >  > > Thank you,
 >  >  >  > > Takashi
 >  >  >  > >
 >  >  >  > 
 >  >  > 
 >  >  > 
 >  > 
 >  > 
 > 
 > 


From marios at redhat.com  Wed Mar 16 16:41:49 2022
From: marios at redhat.com (Marios Andreou)
Date: Wed, 16 Mar 2022 18:41:49 +0200
Subject: [TripleO] Move tripleo repos stable/ussuri to End Of Life OK?
Message-ID: <CAM51kHXZnhsUgCYkQekLs10jFH874xCWtOpEFgsv5PboNTgVuA@mail.gmail.com>

Hello TripleO o/

The tripleo-ci team proposes that we move the stable/ussuri branch for all
tripleo repos [1] to End of Life [2].

The branch was moved to extended maintenance with [3] so we can already no
longer make any new releases for ussuri/tripleo repos.

Are there any objections or concerns about this? If so please speak up here
or directly on the patch. I think that any patches posted to ussuri
nowadays are mainly about cherrypicking back to train, rather than merging
something to ussuri specifically.

I have posted the proposal to move to EOL at [4] and have WF-1 to wait for
this discussion.

If there are no objections then once we move to EOL the tripleo-ci team
will remove all Ussuri related CI, check/gate/promotions.

regards, marios

[1] https://releases.openstack.org/teams/tripleo.html#ussuri
[2]
https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
[3] https://review.opendev.org/c/openstack/releases/+/817623
[4] https://review.opendev.org/c/openstack/releases/+/834049
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220316/16b80664/attachment-0001.htm>

From thierry at openstack.org  Wed Mar 16 16:58:05 2022
From: thierry at openstack.org (Thierry Carrez)
Date: Wed, 16 Mar 2022 17:58:05 +0100
Subject: [largescale-sig] Next meeting: Mar 16th, 15utc
In-Reply-To: <4b409c02-f496-abd7-912f-42c4d41214d3@openstack.org>
References: <4b409c02-f496-abd7-912f-42c4d41214d3@openstack.org>
Message-ID: <d5606f2b-294c-4bc6-eb67-bd486fa22309@openstack.org>

Earlier today we had our SIG meeting.

We discussed our next "Large Scale OpenStack" episode on OpenInfra.Live, 
which should feature Yahoo (ex-Oath, ex-Verizon Media), a million-core 
club member! We also discussed the topic of our PTG meeting, which 
should be centered on future steps on documenting the Large Scale Journey.

You can read the meeting logs at:
https://meetings.opendev.org/meetings/large_scale_sig/2022/large_scale_sig.2022-03-16-15.01.html

Our next IRC meeting will be March 30, at 1500utc on 
#openstack-operators on OFTC. We will discuss the last details of our 
OILive episode and finalize the contents of our PTG session.

Regards,

-- 
Thierry Carrez


From mark at stackhpc.com  Wed Mar 16 16:59:59 2022
From: mark at stackhpc.com (Mark Goddard)
Date: Wed, 16 Mar 2022 16:59:59 +0000
Subject: [kolla] Proposing frickler for Kolla and Kolla-Ansible core
In-Reply-To: <a438b6a7-2fe6-a455-2d1c-0d6b47cfa549@linaro.org>
References: <23DC7FD6-25DE-45D3-A000-E2049B8F1D91@gmail.com>
 <a438b6a7-2fe6-a455-2d1c-0d6b47cfa549@linaro.org>
Message-ID: <CAFHSqWqXQN0x+cwObHGMuTpYVB3Xu-mQwARaZcqjY2G1UfOfmg@mail.gmail.com>

+2

On Wed, 16 Mar 2022 at 16:23, Marcin Juszkiewicz
<marcin.juszkiewicz at linaro.org> wrote:
>
> W dniu 16.03.2022 o 13:36, Micha? Nasiadka pisze:
> > Hello,
> >
> > Jens has been working on Kolla and Kolla-Ansible for some time already
>
> > I?d like to propose him for Kolla and Kolla-Ansible core reviewer.
>
> +2
>


From christian.rohmann at inovex.de  Wed Mar 16 22:23:09 2022
From: christian.rohmann at inovex.de (Christian Rohmann)
Date: Wed, 16 Mar 2022 23:23:09 +0100
Subject: [neutron] Bug Deputy Report January 03 - 10
In-Reply-To: <CALg0jK=PMaspbFTBK2XkGjd28gZTdqMTOjaR791_X04ekBRQrQ@mail.gmail.com>
References: <CAB1EZBq7CC8uxqZMkj_QjSZZg0dGvSPhFNOGM8-Kqs95ej06dw@mail.gmail.com>
 <02b79e74-7d84-a6ba-537f-7db1a7ee6532@inovex.de>
 <CALg0jK=PMaspbFTBK2XkGjd28gZTdqMTOjaR791_X04ekBRQrQ@mail.gmail.com>
Message-ID: <68250a50-fc2e-4e8e-883d-5a214edc1f1a@inovex.de>

Hey Lajos, Slawek.

firstly I am truly very sorry about not responding to your kind message 
in any way until just now.
I myself simply expected to be able to reproduce the issue quicker and 
postponed any response way too long.
In any case: We were now able to reproduce the issue on DevStack with 
xena or master, see me comment at the end of this message.


On 13/01/2022 09:34, Lajos Katona wrote:
> Thanks for highlighting your issue with Linuxbridge driver and VPNaaS.
> I would like to ask you to consider the following, which will not give 
> you an answer or solution to your problem but perhaps helps to 
> understand and accept if any specific issue has not received the 
> needed attention from the community.
> Basically it is the core team (and some enthusiasts?around it) who do 
> bug triaging in Neutron, they are experienced and willing to provide 
> answers, solutions.
> The possible combinations of drivers, extensions, backends, deployment 
> tools is huge, and there are combinations which are not well covered 
> in the current community, like linuxbridge is not that used (OVS and 
> perhaps OVN are the top tested and deployed, at least from latest user 
> surveys). So it can happen that in the current core team nobody has 
> the special knowledge and tools (test environment, hardware...) to 
> debug a specific issue.

I understand and thank you for your patience in explaining this (likely 
not for the first time).
I am already tracking the progress happening in regards to OVN, but 
unfortunately support for VPNaaS is still not available there, but there 
is a pending change at 
https://review.opendev.org/c/openstack/neutron-vpnaas/+/765353.


On 13/01/2022 09:18, Slawek Kaplonski wrote:
>> I don't just want to shout louder and certainly everybody wants their
>> issue to be looked at and fixed first.
>> But I just noticed that my bug report received no reply or confirmation
>> in the last three months (apart from the tag "vpnaas" being added),
>> while other issues were triaged quickly and were consequently added to
>> this deputy report ...
> The problem with neutron-vpnaas is that there is almost no one who is
> maintining that project currently and probably because of that nobody works on
> the bug which You reported.
> If You are using that project and are interested in maintaining it, patches
> are always welcome:)

Not to push back on anything your said, it's just a bit frustrating 
sometimes that there seems to be no explicit deprecation and then EoL 
path for certain backends / drivers. To me this would be totally 
understandable as a way to free development time and bug hunting efforts.
And at the same time this means providing some strong guidance to the 
userbase what to avoid or actively moving away from.

The most prominent example to me, as our deployment was affected by this 
as well, is using PostgreSQL as DBMS. While there is this message, 
https://governance.openstack.org/tc/resolutions/20170613-postgresql-status.html, 
explaining that there will be less focus on PostgreSQL, it would 
actually be much better to simply deprecate support for this DBMS and 
then clearly state this for the next releases.
With a state of "supported, but not widely used", users will just have a 
hard time getting their reported bugs validated and fixed. Even 
reviewers for sent in patches are hard to find, see e.g. 
https://review.opendev.org/c/openstack/designate/+/668493. But even if 
an issue was found and fixed, as 
https://review.opendev.org/c/openstack/glance/+/820247, a similar issue 
is just around the corner, as this configuration is just not actively 
tested and validated.

Looking at Neutron there are lots of tables and comparisons. But I am 
not convinced the feature tables and complex interdependencies at

 ?* 
https://docs.openstack.org/neutron/latest/feature_classification/general_feature_support_matrix.html
 ?* https://docs.openstack.org/neutron/latest/admin/config-ml2.html#id5
 ?* https://docs.openstack.org/neutron/latest/ovn/gaps.html

help a new Neutron user to make the right choices.
I already somewhat read between the lines that OVS support could be 
dropped in favor of OVN at some point - like RedHat recommends and 
explains here: 
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/networking_with_open_virtual_network/migrating-ml2ovs-to-ovn

What I am trying to say is that it would be ok to drop support for 
something at some point to free time and effort to focus on more common 
configurations and making them work as best they can.
But this also includes making active recommendations and getting the 
missing features tackled (as in VPNaaS for OVN) so people can actually 
be asked to migrate away from a EoL config.


On 13/01/2022 09:34, Lajos Katona wrote:

>
> Neutron maintains a list of "lieutenants", to make easier to contact 
> the right person:
> https://docs.openstack.org/neutron/latest/contributor/policies/neutron-teams.html#neutron-lieutenants
> For VPNaaS the people are not active anymore in the community.
> In such difficult to debug situation it is really helpful for the 
> community if you can test the issue on current master code (it is 
> possible that the issue happens only on older branches) and with tools 
> that are available for most of us, like simple devstack.

My colleague Niklas Schwarz did setup two devstack nodes and documented 
their config as well as required steps setting up VPNs to then trigger 
the reported duplicate iptables issue, see 
https://bugs.launchpad.net/neutron/+bug/1943449/comments/4.
Please kindly take a look and let me know if there is any more details 
we need to provide. But since we have this issue reproducible in 
devstack I hope you'll be able to narrow it down.




Regards and thanks again for your patience,


Christian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220316/14e2a49d/attachment.htm>

From laurentfdumont at gmail.com  Wed Mar 16 22:39:36 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Wed, 16 Mar 2022 18:39:36 -0400
Subject: Metadata service {devices list}
In-Reply-To: <CAMRGJtetgCKOCZ2WDZUJ8dWWJDufODOXZ=ia3s_KegiVp1A64g@mail.gmail.com>
References: <CAMRGJtetgCKOCZ2WDZUJ8dWWJDufODOXZ=ia3s_KegiVp1A64g@mail.gmail.com>
Message-ID: <CAOAKi8zYcJVbGuaC2cUvYdNUjgrJFPzm7ojyPDW+Zd3dgdmXcQ@mail.gmail.com>

Are you getting anything from the neutron endpoint?

http://169.254.169.254/openstack/2018-08-27/network_data.json

Can you provide an "openstack server show $server_id" of the VM? I wonder
if it's a case of boot from a volume VM missing that data. It would not
explain why the port is not there though.

On Tue, Mar 15, 2022 at 9:15 AM Ahmed Abdelhamid <
ahmedabdelhamid1221 at gmail.com> wrote:

> Hi All,
>
> I am running into a strange issue with the metadata service. Per metadata-service
> manual <https://docs.openstack.org/nova/latest/user/metadata.html>, the
> devices attached to a VM should be visible in
>
> $ curl http://169.254.169.254/openstack/2018-08-27/meta_data.json
>
> However, whenever i execute it from a VM , the devices array is empty and
> looks like this, any idea why ?
>
> Thanks
>
> {   "random_seed": "yu5ZnkqF2CqnDZVAfZgarG...",   "availability_zone": "nova",   "keys": [       {         "data": "ssh-rsa AAAAB3NzaC1y...== Generated by Nova\n",         "type": "ssh",         "name": "mykey"       }   ],   "hostname": "test.novalocal",   "launch_index": 0,   "meta": {      "priority": "low",      "role": "webserver"   },   "devices": [ ],   "project_id": "f7ac731cc11f40efbc03a9f9e1d1d21f",   "public_keys": {       "mykey": "ssh-rsa AAAAB3NzaC1y...== Generated by Nova\n"   },   "name": "test"}
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220316/8acca3b5/attachment-0001.htm>

From gmann at ghanshyammann.com  Thu Mar 17 00:03:03 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 16 Mar 2022 19:03:03 -0500
Subject: [all][tc] Technical Committee next weekly meeting on Mar 17th
 at 1500 UTC
In-Reply-To: <17f8b7a5e4e.dced0167214057.6183832161093575525@ghanshyammann.com>
References: <17f8b7a5e4e.dced0167214057.6183832161093575525@ghanshyammann.com>
Message-ID: <17f952f5e81.101247b5c359762.2657311097526849422@ghanshyammann.com>

Hello Everyone,

Below is the agenda for Tomorrow's TC IRC meeting schedule at 1500 UTC.

https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

== Agenda for tomorrow's TC meeting ==

* Roll call

* Follow up on past action items

* Gate health check
** Fixing Zuul config error in OpenStack
*** https://etherpad.opendev.org/p/zuul-config-error-openstack

* Z cycle Leaderless projects
** https://etherpad.opendev.org/p/zed-leaderless

* PTG Preparation
** http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027381.html
** https://etherpad.opendev.org/p/tc-zed-ptg
** TC + Community Leaders Interaction
*** http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027382.html

* Open Reviews
** https://review.opendev.org/q/projects:openstack/governance+is:open

-gmann

 ---- On Mon, 14 Mar 2022 21:48:46 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > Hello Everyone,
 > 
 > Technical Committee's next weekly meeting is scheduled for Mar 17th at 1500 UTC.
 > 
 > If you would like to add topics for discussion, please add them to the below wiki page by
 > Wednesday, Mar 16th, at 2100 UTC.
 > 
 > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting
 > 
 > -gmann
 > 
 > 
 > 


From jpodivin at redhat.com  Thu Mar 17 07:20:41 2022
From: jpodivin at redhat.com (Jiri Podivin)
Date: Thu, 17 Mar 2022 08:20:41 +0100
Subject: [TripleO] Move tripleo repos stable/ussuri to End Of Life OK?
In-Reply-To: <CAM51kHXZnhsUgCYkQekLs10jFH874xCWtOpEFgsv5PboNTgVuA@mail.gmail.com>
References: <CAM51kHXZnhsUgCYkQekLs10jFH874xCWtOpEFgsv5PboNTgVuA@mail.gmail.com>
Message-ID: <CAD0_RgHMOTYPKtM4qHbGdrQYrEh7j5ptiqZupa2LDRbTkAPgiQ@mail.gmail.com>

Hi,
As far as Tripleo-Validations repo[5] is concerned I don't believe we
should see any issues.
For the most part we are treating the stable/ussuri branch as a necessary,
but not very meaningful, step when backporting changes to stable/train.

[5]https://review.opendev.org/admin/repos/openstack/tripleo-validations

On Wed, Mar 16, 2022 at 5:45 PM Marios Andreou <marios at redhat.com> wrote:

> Hello TripleO o/
>
> The tripleo-ci team proposes that we move the stable/ussuri branch for all
> tripleo repos [1] to End of Life [2].
>
> The branch was moved to extended maintenance with [3] so we can already no
> longer make any new releases for ussuri/tripleo repos.
>
> Are there any objections or concerns about this? If so please speak up
> here or directly on the patch. I think that any patches posted to ussuri
> nowadays are mainly about cherrypicking back to train, rather than merging
> something to ussuri specifically.
>
> I have posted the proposal to move to EOL at [4] and have WF-1 to wait for
> this discussion.
>
> If there are no objections then once we move to EOL the tripleo-ci team
> will remove all Ussuri related CI, check/gate/promotions.
>
> regards, marios
>
> [1] https://releases.openstack.org/teams/tripleo.html#ussuri
> [2]
> https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
> [3] https://review.opendev.org/c/openstack/releases/+/817623
> [4] https://review.opendev.org/c/openstack/releases/+/834049
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220317/7ec2128c/attachment.htm>

From amonster369 at gmail.com  Thu Mar 17 08:20:40 2022
From: amonster369 at gmail.com (A Monster)
Date: Thu, 17 Mar 2022 09:20:40 +0100
Subject: are Gpu's needed to get fast openstack instances with GUI
Message-ID: <CAEc0zitmpWwzYrP3yvmLAE8Pj3bp_OpkrudZe6RFoVMiwRs-Zw@mail.gmail.com>

I've deployed an openstack cloud using kolla-ansible, but the vm instances
which has gui are very slow, do I need GPUs in order to get fast instances ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220317/61524da9/attachment.htm>

From pierre at stackhpc.com  Thu Mar 17 09:47:21 2022
From: pierre at stackhpc.com (Pierre Riteau)
Date: Thu, 17 Mar 2022 10:47:21 +0100
Subject: [blazar][release][requirements] blazar-nova and nova requirements
In-Reply-To: <1ba1c3e1-cee1-0a99-8edf-6405ed9c6f30@est.tech>
References: <CA+ny2sxjdBV8_fL4ZGGiwGHUHjDuFsXdFTaL28Ze6JREh1LtRg@mail.gmail.com>
 <7aa04776-ecd7-3adc-d1f8-7737feca6045@est.tech>
 <5684cb62-02c0-c14b-0de9-2ed74d072a14@openstack.org>
 <1ba1c3e1-cee1-0a99-8edf-6405ed9c6f30@est.tech>
Message-ID: <CA+ny2sx-Yf=VBLp5TUx2MgKx=7cq+Gh4saZv+GG-aOV5EJ=iVA@mail.gmail.com>

Thank you both for your help. blazar-nova 2.5.0 has been released, this
issue is now resolved.

On Wed, 16 Mar 2022 at 15:10, El?d Ill?s <elod.illes at est.tech> wrote:

> Thanks Thierry, you are right. Let's release then!
>
> El?d
>
> On 2022. 03. 16. 14:25, Thierry Carrez wrote:
> > Given that in practice it is not really a library, it's not listed in
> > global-requirements, and we will likely switch its type next cycle, I
> > would consider just allowing a new release to fix this.
> >
> > It should not create any issue with requirements since nothing lists
> > it as a dependency. It would not even need a RFE.
> >
> > El?d Ill?s wrote:
> >> Hi,
> >>
> >> Sorry for the late answer.
> >>
> >> First of all we are in library freeze period already and blazar-nova
> >> is currently marked as library. Though a Requirements Freeze
> >> Exception might be granted (would need to check with Matthew), I
> >> think it's not necessary. This is mostly a problem when distros do
> >> their packaging, but I guess due to nova's lower constraints change
> >> they already need to use the higher minimums.
> >>
> >> Some more comments:
> >> - though requirements shouldn't be changed on stable branches in
> >> general, i think this can be backported *after* the final yoga
> >> release (to unblock the gate)
> >> - I think release model change is OK and can be proposed for Zed cycle
> >>
> >> Cheers,
> >>
> >> El?d
> >>
> >>
> >> On 2022. 03. 04. 17:36, Pierre Riteau wrote:
> >>> Hello release team,
> >>>
> >>> blazar-nova is a package including a nova scheduler filter, which
> >>> must be installed together with nova to be used.
> >>>
> >>> The blazar-nova deliverable for Yoga was tagged with 2.4.0 at the
> >>> time of the final release for non-client libraries. A few days ago,
> >>> stable/yoga patches were automatically proposed. This is when I
> >>> discovered that the lower-constraints job was broken because nova
> >>> bumped some requirements / lower-constraints after we released [1]
> >>> [2]. Because blazar-nova and nova are installed together, we keep
> >>> our requirements in sync for testing purposes.
> >>>
> >>> Now, I believe it is just the lower-constraints testing that is
> >>> broken, since nova requirements are still compatible with what
> >>> blazar-nova requires: nova just requires more recent versions of
> >>> some packages. I can run "pip install blazar-nova
> >>> git+https://opendev.org/openstack/nova.git at master#egg=nova" fine.
> >>>
> >>> I fixed the issue on the blazar-nova master branch [3] and proposed
> >>> a backport to stable/yoga [4], but realised this was probably
> >>> breaking release policy.
> >>> Should we leave stable/yoga as released and just drop the
> >>> lower-constraints job?
> >>>
> >>> As an aside, would it be possible to requalify blazar-nova as a
> >>> cycle-with-rc deliverable for the next release? It is typed as a
> >>> library but nothing depends on it: if anything, it depends on nova
> >>> itself.
> >>>
> >>> Thanks,
> >>> Pierre Riteau (priteau)
> >>>
> >>> [1] https://review.opendev.org/c/openstack/nova/+/712139
> >>> [2] https://review.opendev.org/c/openstack/nova/+/821606
> >>> [3] https://review.opendev.org/c/openstack/blazar-nova/+/831741
> >>> [4] https://review.opendev.org/c/openstack/blazar-nova/+/831832
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220317/b04f7a4e/attachment.htm>

From katonalala at gmail.com  Thu Mar 17 21:00:27 2022
From: katonalala at gmail.com (Lajos Katona)
Date: Thu, 17 Mar 2022 22:00:27 +0100
Subject: [neutron] Drivers meeting agenda - 18.03.2022.
Message-ID: <CALg0jKmSXqv6058EL+XpdFm2S9FW3OYY8OBHu3j6LME_zcr54w@mail.gmail.com>

Hi Neutron Drivers,

The agenda for tomorrow's drivers meeting is at [1].

* Recheck gratuitous ARPs are not sent during master transition: (
https://bugs.launchpad.net/neutron/+bug/1952907)
** For this one there are a few wip patches:
** https://review.opendev.org/c/openstack/neutron/+/821434
** https://review.opendev.org/c/openstack/neutron/+/821433
** https://review.opendev.org/c/openstack/neutron/+/712474

* [QoS][OvS] implement QoS bandwidth limitation by leveraging ovs meter
(#link https://bugs.launchpad.net/neutron/+bug/1964342 )

* DHCP agent scheduler filtering ignored when agent service restarted
(#link https://bugs.launchpad.net/neutron/+bug/1964765 )

[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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220317/64e85b3f/attachment.htm>

From wakorins at gmail.com  Thu Mar 17 21:19:22 2022
From: wakorins at gmail.com (Wada Akor)
Date: Thu, 17 Mar 2022 22:19:22 +0100
Subject: L3 agent issues
Message-ID: <CAG8+hJOF2T=33gRpSYot7TY7piq=3BPsd0c0Yw3=j45BbwDuMw@mail.gmail.com>

Good to all the openstack community,
Base on the above subject i was deploying openstack for a proof of concept
(POC) at the university of Jos ,Plateau State Nigeria .

after deploying the neutron on the controller and compute node
then I ran  the command # *openstack network agent list*
command output # is only 3 agent on the list as follow  linuxbridge agent
,metadata agent ,DHCP agent no l3 agent on the list

2) No log file for l3 agent at */var/log/neutron/**neuton*- linuxbridge
agent ,metadata agent ,DHCP agent on log no l3 agent .

My deployment hardware is HP gen 7 for the POC

please i need the community support

thanks

Wada k Jeremiah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220317/c22b5d1f/attachment.htm>

From laurentfdumont at gmail.com  Thu Mar 17 22:20:20 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Thu, 17 Mar 2022 18:20:20 -0400
Subject: are Gpu's needed to get fast openstack instances with GUI
In-Reply-To: <CAEc0zitmpWwzYrP3yvmLAE8Pj3bp_OpkrudZe6RFoVMiwRs-Zw@mail.gmail.com>
References: <CAEc0zitmpWwzYrP3yvmLAE8Pj3bp_OpkrudZe6RFoVMiwRs-Zw@mail.gmail.com>
Message-ID: <CAOAKi8wF+8h=U4KMq6G_jEJWpUujbn9Au2N1V8AmCA=6ELa0cw@mail.gmail.com>

Are these Windows instances? You can try to tweak the video memory on the
flavor.

But as a rule, non-GPU virtual instances will always be less efficient. But
if you are using RDP + Openstack Windows VM without a GPU, it can probably
get pretty good.

It's never going to be Citrix/any other virtual desktop good though.

On Thu, Mar 17, 2022 at 4:23 AM A Monster <amonster369 at gmail.com> wrote:

> I've deployed an openstack cloud using kolla-ansible, but the vm instances
> which has gui are very slow, do I need GPUs in order to get fast instances ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220317/2bf24a0e/attachment.htm>

From laurentfdumont at gmail.com  Thu Mar 17 22:21:09 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Thu, 17 Mar 2022 18:21:09 -0400
Subject: L3 agent issues
In-Reply-To: <CAG8+hJOF2T=33gRpSYot7TY7piq=3BPsd0c0Yw3=j45BbwDuMw@mail.gmail.com>
References: <CAG8+hJOF2T=33gRpSYot7TY7piq=3BPsd0c0Yw3=j45BbwDuMw@mail.gmail.com>
Message-ID: <CAOAKi8zHYZX6Z5H4JcCVR6KU60xjhpVeookQN=SQaZKEgzRbeQ@mail.gmail.com>

How was the Openstack deployed? Kolla, ansible-openstack?

On Thu, Mar 17, 2022 at 5:22 PM Wada Akor <wakorins at gmail.com> wrote:

> Good to all the openstack community,
> Base on the above subject i was deploying openstack for a proof of concept
> (POC) at the university of Jos ,Plateau State Nigeria .
>
> after deploying the neutron on the controller and compute node
> then I ran  the command # *openstack network agent list*
> command output # is only 3 agent on the list as follow  linuxbridge agent
> ,metadata agent ,DHCP agent no l3 agent on the list
>
> 2) No log file for l3 agent at */var/log/neutron/**neuton*- linuxbridge
> agent ,metadata agent ,DHCP agent on log no l3 agent .
>
> My deployment hardware is HP gen 7 for the POC
>
> please i need the community support
>
> thanks
>
> Wada k Jeremiah
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220317/45c0154a/attachment.htm>

From skaplons at redhat.com  Fri Mar 18 06:57:08 2022
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Fri, 18 Mar 2022 07:57:08 +0100
Subject: L3 agent issues
In-Reply-To: <CAG8+hJOF2T=33gRpSYot7TY7piq=3BPsd0c0Yw3=j45BbwDuMw@mail.gmail.com>
References: <CAG8+hJOF2T=33gRpSYot7TY7piq=3BPsd0c0Yw3=j45BbwDuMw@mail.gmail.com>
Message-ID: <10048724.nUPlyArG6x@p1>

Hi,

On czwartek, 17 marca 2022 22:19:22 CET Wada Akor wrote:
> Good to all the openstack community,
> Base on the above subject i was deploying openstack for a proof of concept
> (POC) at the university of Jos ,Plateau State Nigeria .
> 
> after deploying the neutron on the controller and compute node
> then I ran  the command # *openstack network agent list*
> command output # is only 3 agent on the list as follow  linuxbridge agent
> ,metadata agent ,DHCP agent no l3 agent on the list
> 
> 2) No log file for l3 agent at */var/log/neutron/**neuton*- linuxbridge
> agent ,metadata agent ,DHCP agent on log no l3 agent .
> 
> My deployment hardware is HP gen 7 for the POC
> 
> please i need the community support
> 
> thanks
> 
> Wada k Jeremiah
> 

L3 agent isn't something what is deployed automatically. You can deploy it on any node - sometimes You may want dedicated networking node with L3 agent for example.
Please check our documentation [1] for more details.

[1] https://docs.openstack.org/neutron/latest/install/index.html[1]

-- 
Slawek Kaplonski
Principal Software Engineer
Red Hat

--------
[1] https://docs.openstack.org/neutron/latest/install/index.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220318/a8ddac9e/attachment-0001.htm>
-------------- 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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220318/a8ddac9e/attachment-0001.sig>

From skaplons at redhat.com  Fri Mar 18 08:25:34 2022
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Fri, 18 Mar 2022 09:25:34 +0100
Subject: L3 agent issues
In-Reply-To: <CAG8+hJO1O9vv+=jqdKhpF2NGnSrc2NZvoo4sqibT=byiGrUCkw@mail.gmail.com>
References: <CAG8+hJOF2T=33gRpSYot7TY7piq=3BPsd0c0Yw3=j45BbwDuMw@mail.gmail.com>
 <10048724.nUPlyArG6x@p1>
 <CAG8+hJO1O9vv+=jqdKhpF2NGnSrc2NZvoo4sqibT=byiGrUCkw@mail.gmail.com>
Message-ID: <7357786.EvYhyI6sBW@p1>

Hi,

On pi?tek, 18 marca 2022 09:22:03 CET Wada Akor wrote:
> Thanks Slawek
> I just had feeling it is a bug or something has to with my hardware HP
> proliant gen 7 might affect the performance of the L3 Agent.

Bug where? In Neutron? I don't think so as Neutron is not deployment tool.
I don't know exactly what tool are You using to deploy OpenStack but if there is any bug, You should look there.

> 
> 
> On Fri, Mar 18, 2022 at 7:57 AM Slawek Kaplonski <skaplons at redhat.com>
> wrote:
> 
> > Hi,
> >
> > On czwartek, 17 marca 2022 22:19:22 CET Wada Akor wrote:
> >
> > > Good to all the openstack community,
> >
> > > Base on the above subject i was deploying openstack for a proof of
> > concept
> >
> > > (POC) at the university of Jos ,Plateau State Nigeria .
> >
> > >
> >
> > > after deploying the neutron on the controller and compute node
> >
> > > then I ran  the command # *openstack network agent list*
> >
> > > command output # is only 3 agent on the list as follow  linuxbridge agent
> >
> > > ,metadata agent ,DHCP agent no l3 agent on the list
> >
> > >
> >
> > > 2) No log file for l3 agent at */var/log/neutron/**neuton*- linuxbridge
> >
> > > agent ,metadata agent ,DHCP agent on log no l3 agent .
> >
> > >
> >
> > > My deployment hardware is HP gen 7 for the POC
> >
> > >
> >
> > > please i need the community support
> >
> > >
> >
> > > thanks
> >
> > >
> >
> > > Wada k Jeremiah
> >
> > >
> >
> > L3 agent isn't something what is deployed automatically. You can deploy it
> > on any node - sometimes You may want dedicated networking node with L3
> > agent for example.
> >
> > Please check our documentation [1] for more details.
> >
> > [1] https://docs.openstack.org/neutron/latest/install/index.html
> >
> > --
> >
> > Slawek Kaplonski
> >
> > Principal Software Engineer
> >
> > Red Hat
> >
> 



-- 
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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220318/f5b17075/attachment.sig>

From ozzzo at yahoo.com  Fri Mar 18 12:54:25 2022
From: ozzzo at yahoo.com (Albert Braden)
Date: Fri, 18 Mar 2022 12:54:25 +0000 (UTC)
Subject: [kolla] [rabbitmq] RMQ trouble after config update
References: <405973893.569766.1647608065129.ref@mail.yahoo.com>
Message-ID: <405973893.569766.1647608065129@mail.yahoo.com>

We?re running kolla-ansible Train. I followed the recommendations in [1] and ended up with the following config:

definitions.json (in the rabbitmq container):

{
  "vhosts": [
    {"name": "/"}  ],
  "users": [
    {"name": "openstack", "password": "<password>", "tags": "administrator"}  ],
  "permissions": [
    {"user": "openstack", "vhost": "/", "configure": ".*", "write": ".*", "read": ".*"}  ],
  "policies":[
    {"vhost": "/", "name": "notifications-expire", "pattern": "^(notifications_designate|versioned_notifications).*", "apply-to": "queues", "definition": {"message-ttl":600000,"expires":1200000}, "priority":0},
    {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0}  ]
}

etc/kolla/config/global.conf:

[oslo_messaging_rabbit]
amqp_durable_queues = True

This fixed some issues, but we seem to have a new issue so I must be missing a setting. When we stop the RMQ container on ctrl1, designate stops working (DNS records are not created nor deleted) and I see this in designate-sink.log:

2022-03-17 19:21:29.261 28 ERROR oslo.messaging._drivers.impl_rabbit [req-2c0cd9f4-5331-4697-9c3e-eece475a52af - - - - -] Failed to consume message from queue: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible: amqp.exceptions.NotFound: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible

When I look at the notifications_designate.info queue in the web interface, it appears to have moved to ctrl2:

Features             
durable:               true
Policy    notifications-expire
Operator policy                
Effective policy definition            
expires: 1200000
message-ttl:       600000
Node     rabbit at qde3-ctrl2

When I look at designate.conf in the designate_sink containers I don?t see anything pointing only to ctrl1:

transport_url = rabbit://openstack:<pwd>@<ctrl1>:5672,openstack:<pwd>@<ctrl2>:5672,openstack:<pwd>@<ctrl3>:5672//

But it appears that Designate still tries to use the queue on ctrl1. After I bring up ctrl1, the notifications_designate.info queue remains on ctrl2, but Designate starts working.

What am I missing?

[1] https://wiki.openstack.org/wiki/Large_Scale_Configuration_Rabbit


From felix.huettner at mail.schwarz  Fri Mar 18 13:53:50 2022
From: felix.huettner at mail.schwarz (=?iso-8859-1?Q?Felix_H=FCttner?=)
Date: Fri, 18 Mar 2022 13:53:50 +0000
Subject: [kolla] [rabbitmq] RMQ trouble after config update
In-Reply-To: <405973893.569766.1647608065129@mail.yahoo.com>
References: <405973893.569766.1647608065129.ref@mail.yahoo.com>
 <405973893.569766.1647608065129@mail.yahoo.com>
Message-ID: <DU0PR10MB5244FF8FAC7F41D9AB9B25BDEA139@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>

Hi Albert,

for the queue "notifications_designate.info" both the "notifications-expire" and the "ha-all" policy would match with their pattern. However only one policy can be applied to a queue at any given point in time. I assume "notifications-expire" is applied (but you can check that easily in the UI or with "rabbitmqctl list_queues name policy").

In this case the "notifications_designate.info" is created as durable (because of amqp_durable_queues) and non-ha (as the policy does not define ha).
When a node with a durable and non-ha queue goes down then this queue no longer useable until either the node comes back or the queue is deleted.

In your case I would assume that you also want this queue to be HA, so you probably need to set the options of the "ha-all" policy also in the "notifications-expire" policy.

Regarding the last point of the queue being on ctrl2 and you connecting to ctrl1 this is normal rabbitmq behaviour in that it will forward messages to other nodes if needed.

Best Regards

Felix H?ttner
Schwarz IT KG * Stiftsbergstra?e 1 * D-74172 Neckarsulm

-----Original Message-----
From: Albert Braden <ozzzo at yahoo.com>
Sent: Friday, March 18, 2022 1:54 PM
To: Openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: [kolla] [rabbitmq] RMQ trouble after config update

We're running kolla-ansible Train. I followed the recommendations in [1] and ended up with the following config:

definitions.json (in the rabbitmq container):

{
  "vhosts": [
    {"name": "/"}  ],
  "users": [
    {"name": "openstack", "password": "<password>", "tags": "administrator"}  ],
  "permissions": [
    {"user": "openstack", "vhost": "/", "configure": ".*", "write": ".*", "read": ".*"}  ],
  "policies":[
    {"vhost": "/", "name": "notifications-expire", "pattern": "^(notifications_designate|versioned_notifications).*", "apply-to": "queues", "definition": {"message-ttl":600000,"expires":1200000}, "priority":0},
    {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0}  ] }

etc/kolla/config/global.conf:

[oslo_messaging_rabbit]
amqp_durable_queues = True

This fixed some issues, but we seem to have a new issue so I must be missing a setting. When we stop the RMQ container on ctrl1, designate stops working (DNS records are not created nor deleted) and I see this in designate-sink.log:

2022-03-17 19:21:29.261 28 ERROR oslo.messaging._drivers.impl_rabbit [req-2c0cd9f4-5331-4697-9c3e-eece475a52af - - - - -] Failed to consume message from queue: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible: amqp.exceptions.NotFound: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible

When I look at the notifications_designate.info queue in the web interface, it appears to have moved to ctrl2:

Features
durable:               true
Policy    notifications-expire
Operator policy
Effective policy definition
expires: 1200000
message-ttl:       600000
Node     rabbit at qde3-ctrl2

When I look at designate.conf in the designate_sink containers I don't see anything pointing only to ctrl1:

transport_url = rabbit://openstack:<pwd>@<ctrl1>:5672,openstack:<pwd>@<ctrl2>:5672,openstack:<pwd>@<ctrl3>:5672//

But it appears that Designate still tries to use the queue on ctrl1. After I bring up ctrl1, the notifications_designate.info queue remains on ctrl2, but Designate starts working.

What am I missing?

[1] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FLarge_Scale_Configuration_Rabbit&amp;data=04%7C01%7C%7C103b79868a61424923bb08da08df82f7%7Cd04f47175a6e4b98b3f96918e0385f4c%7C0%7C0%7C637832053312648154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=1RIlfljNyKg71IrZc0NIuqDoHPkTGtSBthadz%2Bneofk%3D&amp;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<https://www.datenschutz.schwarz>.


From tkajinam at redhat.com  Fri Mar 18 14:13:46 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Fri, 18 Mar 2022 23:13:46 +0900
Subject: [puppet] Proposing Alan Bishop (abishop) for puppet-manila core
In-Reply-To: <CAKSuTPZ=FaN5Oyze9rKozrgBjeEnxa41cjxHw-nnOgKE2tcDrg@mail.gmail.com>
References: <CAL_crJQtgtBGG3KGjbqR7CuQH987B_9NqvJ9q63kTY5+t4LTzg@mail.gmail.com>
 <FF31E9C6-F917-4E4E-B164-A1CFDC98966F@binero.com>
 <CAKSuTPZ=FaN5Oyze9rKozrgBjeEnxa41cjxHw-nnOgKE2tcDrg@mail.gmail.com>
Message-ID: <CAL_crJTSCjRm919yVrWiiOj6Mo7pxVVwWr6oDoQ6fC7pMPB86g@mail.gmail.com>

Hello,

Thank you all who shared feedback.

Because we haven't heard any objections for a week, I'll move forward to
add Alan
to puppet-manila core.

Thank you, Alan, again for your continuous great work !

Thank you,
Takashi

On Fri, Mar 11, 2022 at 3:11 PM Goutham Pacha Ravi <gouthampravi at gmail.com>
wrote:

> +.02 since I?m not core :)
>
> Alan?s been super helpful to the Manila team regarding puppet and tripleo
> integration; and he does great reviews. Thanks for the proposal Takashi!
>
> On Thu, Mar 10, 2022 at 9:02 PM Tobias Urdin <tobias.urdin at binero.com>
> wrote:
>
>> +1 - Alan is doing great work!
>>
>>
>> On 9 Mar 2022, at 16:11, Takashi Kajinami <tkajinam at redhat.com> wrote:
>>
>> Hi Team,
>>
>>
>> Alan is currently a partial core reviewer in Puppet OpenStack and covers
>> puppet-cinder and puppet-glance.
>>
>> He has made great reviews in these two modules since he joined the team,
>> but
>> in addition,  he has been reviewing patches for puppet-manila and
>> providing
>> good feedback for the past two cycle.
>>  https://www.stackalytics.io/?user_id=alan-bishop
>>
>> Based on that fact, I'd like to propose extending his coverage and adding
>> Alan
>> to the puppet-manila core reviewers.
>>
>> If you have any feedback please share it in this thread. I'll add him to
>> the group
>> if we don't hear any objections for 1 week.
>>
>> I'd like to take this moment to thank Alan for his great work and help in
>> this project !
>>
>> Thank you,
>> Takashi KAJINAMI
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220318/754ebb7a/attachment-0001.htm>

From ozzzo at yahoo.com  Fri Mar 18 14:16:01 2022
From: ozzzo at yahoo.com (Albert Braden)
Date: Fri, 18 Mar 2022 14:16:01 +0000 (UTC)
Subject: [kolla] [rabbitmq] RMQ trouble after config update
In-Reply-To: <DU0PR10MB5244FF8FAC7F41D9AB9B25BDEA139@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>
References: <405973893.569766.1647608065129.ref@mail.yahoo.com>
 <405973893.569766.1647608065129@mail.yahoo.com>
 <DU0PR10MB5244FF8FAC7F41D9AB9B25BDEA139@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <1172470581.603275.1647612961192@mail.yahoo.com>

 That's what I was missing; I'll experiment with this today. Thank you!
     On Friday, March 18, 2022, 10:04:08 AM EDT, Felix H?ttner <felix.huettner at mail.schwarz> wrote:  
 
 Hi Albert,

for the queue "notifications_designate.info" both the "notifications-expire" and the "ha-all" policy would match with their pattern. However only one policy can be applied to a queue at any given point in time. I assume "notifications-expire" is applied (but you can check that easily in the UI or with "rabbitmqctl list_queues name policy").

In this case the "notifications_designate.info" is created as durable (because of amqp_durable_queues) and non-ha (as the policy does not define ha).
When a node with a durable and non-ha queue goes down then this queue no longer useable until either the node comes back or the queue is deleted.

In your case I would assume that you also want this queue to be HA, so you probably need to set the options of the "ha-all" policy also in the "notifications-expire" policy.

Regarding the last point of the queue being on ctrl2 and you connecting to ctrl1 this is normal rabbitmq behaviour in that it will forward messages to other nodes if needed.

Best Regards

Felix H?ttner
Schwarz IT KG * Stiftsbergstra?e 1 * D-74172 Neckarsulm

-----Original Message-----
From: Albert Braden <ozzzo at yahoo.com>
Sent: Friday, March 18, 2022 1:54 PM
To: Openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: [kolla] [rabbitmq] RMQ trouble after config update

We're running kolla-ansible Train. I followed the recommendations in [1] and ended up with the following config:

definitions.json (in the rabbitmq container):

{
? "vhosts": [
? ? {"name": "/"}? ],
? "users": [
? ? {"name": "openstack", "password": "<password>", "tags": "administrator"}? ],
? "permissions": [
? ? {"user": "openstack", "vhost": "/", "configure": ".*", "write": ".*", "read": ".*"}? ],
? "policies":[
? ? {"vhost": "/", "name": "notifications-expire", "pattern": "^(notifications_designate|versioned_notifications).*", "apply-to": "queues", "definition": {"message-ttl":600000,"expires":1200000}, "priority":0},
? ? {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0}? ] }

etc/kolla/config/global.conf:

[oslo_messaging_rabbit]
amqp_durable_queues = True

This fixed some issues, but we seem to have a new issue so I must be missing a setting. When we stop the RMQ container on ctrl1, designate stops working (DNS records are not created nor deleted) and I see this in designate-sink.log:

2022-03-17 19:21:29.261 28 ERROR oslo.messaging._drivers.impl_rabbit [req-2c0cd9f4-5331-4697-9c3e-eece475a52af - - - - -] Failed to consume message from queue: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible: amqp.exceptions.NotFound: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible

When I look at the notifications_designate.info queue in the web interface, it appears to have moved to ctrl2:

Features
durable:? ? ? ? ? ? ? true
Policy? ? notifications-expire
Operator policy
Effective policy definition
expires: 1200000
message-ttl:? ? ? 600000
Node? ? rabbit at qde3-ctrl2

When I look at designate.conf in the designate_sink containers I don't see anything pointing only to ctrl1:

transport_url = rabbit://openstack:<pwd>@<ctrl1>:5672,openstack:<pwd>@<ctrl2>:5672,openstack:<pwd>@<ctrl3>:5672//

But it appears that Designate still tries to use the queue on ctrl1. After I bring up ctrl1, the notifications_designate.info queue remains on ctrl2, but Designate starts working.

What am I missing?

[1] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FLarge_Scale_Configuration_Rabbit&data=04%7C01%7C%7C103b79868a61424923bb08da08df82f7%7Cd04f47175a6e4b98b3f96918e0385f4c%7C0%7C0%7C637832053312648154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1RIlfljNyKg71IrZc0NIuqDoHPkTGtSBthadz%2Bneofk%3D&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<https://www.datenschutz.schwarz>.

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220318/1cfa667d/attachment.htm>

From radoslaw.piliszek at gmail.com  Fri Mar 18 14:27:55 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Fri, 18 Mar 2022 15:27:55 +0100
Subject: [kolla] [rabbitmq] RMQ trouble after config update
In-Reply-To: <1172470581.603275.1647612961192@mail.yahoo.com>
References: <405973893.569766.1647608065129.ref@mail.yahoo.com>
 <405973893.569766.1647608065129@mail.yahoo.com>
 <DU0PR10MB5244FF8FAC7F41D9AB9B25BDEA139@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>
 <1172470581.603275.1647612961192@mail.yahoo.com>
Message-ID: <CAKZ_x7_6cNVLvhLG7sMhY2XZM4B64L1Y0K+hdRnXtXR61FxbbQ@mail.gmail.com>

Hello fellow OpenStackers,

you might be interested in what we (the Kolla team) have done to RMQ
policies: https://review.opendev.org/c/openstack/kolla-ansible/+/824994

-yoctozepto

On Fri, 18 Mar 2022 at 15:16, Albert Braden <ozzzo at yahoo.com> wrote:
>
> That's what I was missing; I'll experiment with this today. Thank you!
> On Friday, March 18, 2022, 10:04:08 AM EDT, Felix H?ttner <felix.huettner at mail.schwarz> wrote:
>
>
> Hi Albert,
>
> for the queue "notifications_designate.info" both the "notifications-expire" and the "ha-all" policy would match with their pattern. However only one policy can be applied to a queue at any given point in time. I assume "notifications-expire" is applied (but you can check that easily in the UI or with "rabbitmqctl list_queues name policy").
>
> In this case the "notifications_designate.info" is created as durable (because of amqp_durable_queues) and non-ha (as the policy does not define ha).
> When a node with a durable and non-ha queue goes down then this queue no longer useable until either the node comes back or the queue is deleted.
>
> In your case I would assume that you also want this queue to be HA, so you probably need to set the options of the "ha-all" policy also in the "notifications-expire" policy.
>
> Regarding the last point of the queue being on ctrl2 and you connecting to ctrl1 this is normal rabbitmq behaviour in that it will forward messages to other nodes if needed.
>
> Best Regards
>
> Felix H?ttner
> Schwarz IT KG * Stiftsbergstra?e 1 * D-74172 Neckarsulm
>
> -----Original Message-----
> From: Albert Braden <ozzzo at yahoo.com>
> Sent: Friday, March 18, 2022 1:54 PM
> To: Openstack-discuss <openstack-discuss at lists.openstack.org>
> Subject: [kolla] [rabbitmq] RMQ trouble after config update
>
> We're running kolla-ansible Train. I followed the recommendations in [1] and ended up with the following config:
>
> definitions.json (in the rabbitmq container):
>
> {
>   "vhosts": [
>     {"name": "/"}  ],
>   "users": [
>     {"name": "openstack", "password": "<password>", "tags": "administrator"}  ],
>   "permissions": [
>     {"user": "openstack", "vhost": "/", "configure": ".*", "write": ".*", "read": ".*"}  ],
>   "policies":[
>     {"vhost": "/", "name": "notifications-expire", "pattern": "^(notifications_designate|versioned_notifications).*", "apply-to": "queues", "definition": {"message-ttl":600000,"expires":1200000}, "priority":0},
>     {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0}  ] }
>
> etc/kolla/config/global.conf:
>
> [oslo_messaging_rabbit]
> amqp_durable_queues = True
>
> This fixed some issues, but we seem to have a new issue so I must be missing a setting. When we stop the RMQ container on ctrl1, designate stops working (DNS records are not created nor deleted) and I see this in designate-sink.log:
>
> 2022-03-17 19:21:29.261 28 ERROR oslo.messaging._drivers.impl_rabbit [req-2c0cd9f4-5331-4697-9c3e-eece475a52af - - - - -] Failed to consume message from queue: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible: amqp.exceptions.NotFound: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible
>
> When I look at the notifications_designate.info queue in the web interface, it appears to have moved to ctrl2:
>
> Features
> durable:              true
> Policy    notifications-expire
> Operator policy
> Effective policy definition
> expires: 1200000
> message-ttl:      600000
> Node    rabbit at qde3-ctrl2
>
> When I look at designate.conf in the designate_sink containers I don't see anything pointing only to ctrl1:
>
> transport_url = rabbit://openstack:<pwd>@<ctrl1>:5672,openstack:<pwd>@<ctrl2>:5672,openstack:<pwd>@<ctrl3>:5672//
>
> But it appears that Designate still tries to use the queue on ctrl1. After I bring up ctrl1, the notifications_designate.info queue remains on ctrl2, but Designate starts working.
>
> What am I missing?
>
> [1]
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FLarge_Scale_Configuration_Rabbit&data=04%7C01%7C%7C103b79868a61424923bb08da08df82f7%7Cd04f47175a6e4b98b3f96918e0385f4c%7C0%7C0%7C637832053312648154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1RIlfljNyKg71IrZc0NIuqDoHPkTGtSBthadz%2Bneofk%3D&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<https://www.datenschutz.schwarz
> >.
>


From marios at redhat.com  Fri Mar 18 15:35:10 2022
From: marios at redhat.com (Marios Andreou)
Date: Fri, 18 Mar 2022 17:35:10 +0200
Subject: [TripleO] Move tripleo repos stable/ussuri to End Of Life OK?
In-Reply-To: <CAD0_RgHMOTYPKtM4qHbGdrQYrEh7j5ptiqZupa2LDRbTkAPgiQ@mail.gmail.com>
References: <CAM51kHXZnhsUgCYkQekLs10jFH874xCWtOpEFgsv5PboNTgVuA@mail.gmail.com>
 <CAD0_RgHMOTYPKtM4qHbGdrQYrEh7j5ptiqZupa2LDRbTkAPgiQ@mail.gmail.com>
Message-ID: <CAM51kHVmqCH-RF-oUL4bFYwKMUh9ttEtuBewG8iqZQOxnVQRDQ@mail.gmail.com>

On Thu, Mar 17, 2022 at 9:20 AM Jiri Podivin <jpodivin at redhat.com> wrote:

> Hi,
> As far as Tripleo-Validations repo[5] is concerned I don't believe we
> should see any issues.
> For the most part we are treating the stable/ussuri branch as a necessary,
> but not very meaningful, step when backporting changes to stable/train.
>
> [5]https://review.opendev.org/admin/repos/openstack/tripleo-validations
>
>
thanks for confirming Jirka

so assuming we go ahead with this we will at some point need to close all
open reviews against stable ussuri - there aren't too many as we would
expect (just things being backported - validations has 3 currently). For
convenience, links for all the repos:


https://review.opendev.org/q/project:openstack%252Fos-apply-config+status:open+branch:stable/ussuri
https://review.opendev.org/q/project:openstack%252Fos-collect-config+status:open+branch:stable/ussuri
https://review.opendev.org/q/project:openstack%252Fos-net-config+status:open+branch:stable/ussuri
https://review.opendev.org/q/project:openstack%252Fos-refresh-config+status:open+branch:stable/ussuri
https://review.opendev.org/q/project:openstack%252Fpaunch+status:open+branch:stable/ussuri
https://review.opendev.org/q/project:openstack%252Fpuppet-tripleo+status:open+branch:stable/ussuri
https://review.opendev.org/q/project:openstack%252Fpython-tripleoclient+status:open+branch:stable/ussuri
https://review.opendev.org/q/project:openstack%252Ftripleo-ansible+status:open+branch:stable/ussuri
https://review.opendev.org/q/project:openstack%252Ftripleo-common+status:open+branch:stable/ussuri
https://review.opendev.org/q/project:openstack%252Ftripleo-heat-templates+status:open+branch:stable/ussuri
https://review.opendev.org/q/project:openstack%252Ftripleo-image-elements+status:open+branch:stable/ussuri
https://review.opendev.org/q/project:openstack%252Ftripleo-ipsec+status:open+branch:stable/ussuri
https://review.opendev.org/q/project:openstack%252Ftripleo-puppet-elements+status:open+branch:stable/ussuri
https://review.opendev.org/q/project:openstack%252Ftripleo-validations+status:open+branch:stable/ussuri


I'll bring this up again in #tripleo next week and see if there are any
objections, otherwise we can call it and start getting folks to close out
those open reviews and stop posting new ones,

thanks, marios




> On Wed, Mar 16, 2022 at 5:45 PM Marios Andreou <marios at redhat.com> wrote:
>
>> Hello TripleO o/
>>
>> The tripleo-ci team proposes that we move the stable/ussuri branch for
>> all tripleo repos [1] to End of Life [2].
>>
>> The branch was moved to extended maintenance with [3] so we can already
>> no longer make any new releases for ussuri/tripleo repos.
>>
>> Are there any objections or concerns about this? If so please speak up
>> here or directly on the patch. I think that any patches posted to ussuri
>> nowadays are mainly about cherrypicking back to train, rather than merging
>> something to ussuri specifically.
>>
>> I have posted the proposal to move to EOL at [4] and have WF-1 to wait
>> for this discussion.
>>
>> If there are no objections then once we move to EOL the tripleo-ci team
>> will remove all Ussuri related CI, check/gate/promotions.
>>
>> regards, marios
>>
>> [1] https://releases.openstack.org/teams/tripleo.html#ussuri
>> [2]
>> https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
>> [3] https://review.opendev.org/c/openstack/releases/+/817623
>> [4] https://review.opendev.org/c/openstack/releases/+/834049
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220318/488a77a0/attachment-0001.htm>

From jpodivin at redhat.com  Fri Mar 18 15:40:18 2022
From: jpodivin at redhat.com (Jiri Podivin)
Date: Fri, 18 Mar 2022 16:40:18 +0100
Subject: [TripleO] Move tripleo repos stable/ussuri to End Of Life OK?
In-Reply-To: <CAM51kHVmqCH-RF-oUL4bFYwKMUh9ttEtuBewG8iqZQOxnVQRDQ@mail.gmail.com>
References: <CAM51kHXZnhsUgCYkQekLs10jFH874xCWtOpEFgsv5PboNTgVuA@mail.gmail.com>
 <CAD0_RgHMOTYPKtM4qHbGdrQYrEh7j5ptiqZupa2LDRbTkAPgiQ@mail.gmail.com>
 <CAM51kHVmqCH-RF-oUL4bFYwKMUh9ttEtuBewG8iqZQOxnVQRDQ@mail.gmail.com>
Message-ID: <CAD0_RgHnDvod-caDs-zmnTcnWK=0Vp2FSRycfYuU6s9bFBJOfg@mail.gmail.com>

I suppose the corresponding rdo distgit branches will follow suit?
Once again most of the open reviews[6] are backports.

[6]https://review.rdoproject.org/r/q/branch:ussuri-rdo+status:open

On Fri, Mar 18, 2022 at 4:35 PM Marios Andreou <marios at redhat.com> wrote:

>
>
> On Thu, Mar 17, 2022 at 9:20 AM Jiri Podivin <jpodivin at redhat.com> wrote:
>
>> Hi,
>> As far as Tripleo-Validations repo[5] is concerned I don't believe we
>> should see any issues.
>> For the most part we are treating the stable/ussuri branch as a
>> necessary, but not very meaningful, step when backporting changes to
>> stable/train.
>>
>> [5]https://review.opendev.org/admin/repos/openstack/tripleo-validations
>>
>>
> thanks for confirming Jirka
>
> so assuming we go ahead with this we will at some point need to close all
> open reviews against stable ussuri - there aren't too many as we would
> expect (just things being backported - validations has 3 currently). For
> convenience, links for all the repos:
>
>
>
> https://review.opendev.org/q/project:openstack%252Fos-apply-config+status:open+branch:stable/ussuri
>
> https://review.opendev.org/q/project:openstack%252Fos-collect-config+status:open+branch:stable/ussuri
>
> https://review.opendev.org/q/project:openstack%252Fos-net-config+status:open+branch:stable/ussuri
>
> https://review.opendev.org/q/project:openstack%252Fos-refresh-config+status:open+branch:stable/ussuri
>
> https://review.opendev.org/q/project:openstack%252Fpaunch+status:open+branch:stable/ussuri
>
> https://review.opendev.org/q/project:openstack%252Fpuppet-tripleo+status:open+branch:stable/ussuri
>
> https://review.opendev.org/q/project:openstack%252Fpython-tripleoclient+status:open+branch:stable/ussuri
>
> https://review.opendev.org/q/project:openstack%252Ftripleo-ansible+status:open+branch:stable/ussuri
>
> https://review.opendev.org/q/project:openstack%252Ftripleo-common+status:open+branch:stable/ussuri
>
> https://review.opendev.org/q/project:openstack%252Ftripleo-heat-templates+status:open+branch:stable/ussuri
>
> https://review.opendev.org/q/project:openstack%252Ftripleo-image-elements+status:open+branch:stable/ussuri
>
> https://review.opendev.org/q/project:openstack%252Ftripleo-ipsec+status:open+branch:stable/ussuri
>
> https://review.opendev.org/q/project:openstack%252Ftripleo-puppet-elements+status:open+branch:stable/ussuri
>
> https://review.opendev.org/q/project:openstack%252Ftripleo-validations+status:open+branch:stable/ussuri
>
>
> I'll bring this up again in #tripleo next week and see if there are any
> objections, otherwise we can call it and start getting folks to close out
> those open reviews and stop posting new ones,
>
> thanks, marios
>
>
>
>
>> On Wed, Mar 16, 2022 at 5:45 PM Marios Andreou <marios at redhat.com> wrote:
>>
>>> Hello TripleO o/
>>>
>>> The tripleo-ci team proposes that we move the stable/ussuri branch for
>>> all tripleo repos [1] to End of Life [2].
>>>
>>> The branch was moved to extended maintenance with [3] so we can already
>>> no longer make any new releases for ussuri/tripleo repos.
>>>
>>> Are there any objections or concerns about this? If so please speak up
>>> here or directly on the patch. I think that any patches posted to ussuri
>>> nowadays are mainly about cherrypicking back to train, rather than merging
>>> something to ussuri specifically.
>>>
>>> I have posted the proposal to move to EOL at [4] and have WF-1 to wait
>>> for this discussion.
>>>
>>> If there are no objections then once we move to EOL the tripleo-ci team
>>> will remove all Ussuri related CI, check/gate/promotions.
>>>
>>> regards, marios
>>>
>>> [1] https://releases.openstack.org/teams/tripleo.html#ussuri
>>> [2]
>>> https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
>>> [3] https://review.opendev.org/c/openstack/releases/+/817623
>>> [4] https://review.opendev.org/c/openstack/releases/+/834049
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220318/9f820bc7/attachment.htm>

From elod.illes at est.tech  Fri Mar 18 17:05:40 2022
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Fri, 18 Mar 2022 18:05:40 +0100
Subject: [release] Release countdown for week R-1, Mar 21-25
Message-ID: <22225b12-2743-10b0-2e39-972563a34cfa@est.tech>

Development Focus
-----------------

We are on the final mile of the Yoga development cycle!

Remember that the Yoga final release will include the latest release
candidate (for cycle-with-rc deliverables) or the latest intermediary
release (for cycle-with-intermediary deliverables) available.

March 24th is the deadline for final Yoga 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 March 30th.
Teams should be prioritizing fixing release-critical bugs, before that
deadline.

Otherwise it's time to start planning the Zed development cycle,
including discussing PTG sessions content, in preparation of
Virtual PTG @ April 4-8.

Actions
-------

Watch for any translation patches coming through on the stable/yoga
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/yoga branch before triggering a new release.

Please drop by #openstack-release with any questions or concerns about
the upcoming release !

Upcoming Deadlines & Dates
--------------------------

Final Yoga release: March 30th, 2022
Next PTG: April 4 - 8, 2022 (virtual)
OpenInfra Summit: June 7-9, 2022 (Berlin)


El?d Ill?s
irc: elodilles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220318/34dbbeb7/attachment.htm>

From gmann at ghanshyammann.com  Fri Mar 18 18:23:39 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Fri, 18 Mar 2022 13:23:39 -0500
Subject: [all][tc] What's happening in Technical Committee: summary Mar
 18th, 21: Reading: 10 min
Message-ID: <17f9e4559ce.123f63a6e482426.5060652229400903671@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 Mar 17th. Most of the meeting discussions are summarized below (Completed
or in-progress activities section). Meeting full logs are available
@https://meetings.opendev.org/meetings/tc/2022/tc.2022-03-17-15.00.log.html

* Next week's meeting is on Mar 24th Thursday 15:00 UTC, feel free to add the topic on
the agenda[1] by Mar 23rd.


2. What we completed this week:
=========================
* Cleared the TC liaisons for projects[2]. We will discuss in PTG if we want to continue this framework in Zed cycle or
not.


3. Activities In progress:
==================
TC Tracker for Yoga cycle
------------------------------
* This etherpad includes the Yoga cycle targets/working items for TC[3].
4 out of 9 items are completed and many are in progress.

Open Reviews
-----------------
* Five open reviews for ongoing activities[4].

Zed cycle Leaderless projects
----------------------------------
One more PTL assignment (Trove) is merged and Zaqar is in progress[5]. With that
only one project left to assign a leader (Adjutant) and we will wait until the end of March for
Braden to get permission to maintain it[6].

PTG Preparation
--------------------
TC slots are selected for PTG[7], please continue adding the topics in etherpad[8].
* Monday 14 - 16 UTC (TC + PTL for 2 hrs )
* Thursday 13-17 UTC (TC discussion for 4 hrs)
* Friday 13-17 UTC (TC discussion for 4 hrs )

Dropping tags framework
------------------------------
VMT tag is also removed[9] and deprecation tag removal is proposed[10].

Fixing Zuul config error
----------------------------
Requesting projects with zuul config error to look into those and fix them which should
not take much time[11].

Project updates
-------------------
* None for this week.


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[12].
2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [13]
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/+/834243
[3] https://etherpad.opendev.org/p/tc-yoga-tracker
[4] https://review.opendev.org/q/projects:openstack/governance+status:open
[5] https://review.opendev.org/c/openstack/governance/+/831123
[6] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027626.html
[7] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027584.html
[8] https://etherpad.opendev.org/p/tc-zed-ptg
[9] https://review.opendev.org/c/openstack/governance/+/830478
[10] https://review.opendev.org/c/openstack/governance/+/834327
[11] https://etherpad.opendev.org/p/zuul-config-error-openstack
[12] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[13] http://eavesdrop.openstack.org/#Technical_Committee_Meeting

-gmann



From amy at demarco.com  Fri Mar 18 19:41:21 2022
From: amy at demarco.com (Amy Marrich)
Date: Fri, 18 Mar 2022 14:41:21 -0500
Subject: OPS Meetup Team resuming planning meetings - Berlin
Message-ID: <CAFs83QrA2d7XKto8HP7V84COtHLd6CEQL_KBY5oGPKkDrAGCXA@mail.gmail.com>

Hi everyone,

The OPS Meetup team will resume meeting to plan for the next OPS Meetup to
be held June 10 at T-Labs in Berlin. Please join us Tuesday mornings at
14:00 UTC  in the #openstack-operators room on OFTC to help us plan this
event.

We are currently looking for ideas for content as well as designing a logo
for the event. [0]

We can't wait to see everyone again in person!

Amy (spotz)

0 - https://etherpad.opendev.org/p/ops-meetup-berlin-2022-planning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220318/38a04efc/attachment.htm>

From ozzzo at yahoo.com  Fri Mar 18 20:13:06 2022
From: ozzzo at yahoo.com (Albert Braden)
Date: Fri, 18 Mar 2022 20:13:06 +0000 (UTC)
Subject: [kolla] [rabbitmq] RMQ trouble after config update
In-Reply-To: <DU0PR10MB5244FF8FAC7F41D9AB9B25BDEA139@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>
References: <405973893.569766.1647608065129.ref@mail.yahoo.com>
 <405973893.569766.1647608065129@mail.yahoo.com>
 <DU0PR10MB5244FF8FAC7F41D9AB9B25BDEA139@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <612895794.735804.1647634386875@mail.yahoo.com>

 I did not intend to make the notifications_designate queues HA nor durable. It
appears that those two queues are treated differently from the others that I
didn't specify as HA. For example, if I look at one of the _fanout queues, it
is not durable:

Features
x-expires: 1800000
Policy
Operator policy
Effective policy definition
Node rabbit at de6-ctrl2

I tried adding the notifications_designate queues to the exclusion list:

 {"vhost": "/", "name": "ha-all", "pattern":
"^(?!(amq\.)|(.*_fanout_)|(reply_)(notifications_designate)|(versioned_notifications)).*",
"apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown":
"always", "ha-sync

But this doesn't seem to make a difference. The notifications_designate queues
still have " Features: durable: true"

How can I make the notifications_designate queues non-durable?     On Friday, March 18, 2022, 10:04:08 AM EDT, Felix H?ttner <felix.huettner at mail.schwarz> wrote:  
 
 Hi Albert,

for the queue "notifications_designate.info" both the "notifications-expire" and the "ha-all" policy would match with their pattern. However only one policy can be applied to a queue at any given point in time. I assume "notifications-expire" is applied (but you can check that easily in the UI or with "rabbitmqctl list_queues name policy").

In this case the "notifications_designate.info" is created as durable (because of amqp_durable_queues) and non-ha (as the policy does not define ha).
When a node with a durable and non-ha queue goes down then this queue no longer useable until either the node comes back or the queue is deleted.

In your case I would assume that you also want this queue to be HA, so you probably need to set the options of the "ha-all" policy also in the "notifications-expire" policy.

Regarding the last point of the queue being on ctrl2 and you connecting to ctrl1 this is normal rabbitmq behaviour in that it will forward messages to other nodes if needed.

Best Regards

Felix H?ttner
Schwarz IT KG * Stiftsbergstra?e 1 * D-74172 Neckarsulm

-----Original Message-----
From: Albert Braden <ozzzo at yahoo.com>
Sent: Friday, March 18, 2022 1:54 PM
To: Openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: [kolla] [rabbitmq] RMQ trouble after config update

We're running kolla-ansible Train. I followed the recommendations in [1] and ended up with the following config:

definitions.json (in the rabbitmq container):

{
? "vhosts": [
? ? {"name": "/"}? ],
? "users": [
? ? {"name": "openstack", "password": "<password>", "tags": "administrator"}? ],
? "permissions": [
? ? {"user": "openstack", "vhost": "/", "configure": ".*", "write": ".*", "read": ".*"}? ],
? "policies":[
? ? {"vhost": "/", "name": "notifications-expire", "pattern": "^(notifications_designate|versioned_notifications).*", "apply-to": "queues", "definition": {"message-ttl":600000,"expires":1200000}, "priority":0},
? ? {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0}? ] }

etc/kolla/config/global.conf:

[oslo_messaging_rabbit]
amqp_durable_queues = True

This fixed some issues, but we seem to have a new issue so I must be missing a setting. When we stop the RMQ container on ctrl1, designate stops working (DNS records are not created nor deleted) and I see this in designate-sink.log:

2022-03-17 19:21:29.261 28 ERROR oslo.messaging._drivers.impl_rabbit [req-2c0cd9f4-5331-4697-9c3e-eece475a52af - - - - -] Failed to consume message from queue: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible: amqp.exceptions.NotFound: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible

When I look at the notifications_designate.info queue in the web interface, it appears to have moved to ctrl2:

Features
durable:? ? ? ? ? ? ? true
Policy? ? notifications-expire
Operator policy
Effective policy definition
expires: 1200000
message-ttl:? ? ? 600000
Node? ? rabbit at qde3-ctrl2

When I look at designate.conf in the designate_sink containers I don't see anything pointing only to ctrl1:

transport_url = rabbit://openstack:<pwd>@<ctrl1>:5672,openstack:<pwd>@<ctrl2>:5672,openstack:<pwd>@<ctrl3>:5672//

But it appears that Designate still tries to use the queue on ctrl1. After I bring up ctrl1, the notifications_designate.info queue remains on ctrl2, but Designate starts working.

What am I missing?

[1] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FLarge_Scale_Configuration_Rabbit&data=04%7C01%7C%7C103b79868a61424923bb08da08df82f7%7Cd04f47175a6e4b98b3f96918e0385f4c%7C0%7C0%7C637832053312648154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1RIlfljNyKg71IrZc0NIuqDoHPkTGtSBthadz%2Bneofk%3D&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<https://www.datenschutz.schwarz>.

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220318/a6251690/attachment.htm>

From ozzzo at yahoo.com  Fri Mar 18 20:50:14 2022
From: ozzzo at yahoo.com (Albert Braden)
Date: Fri, 18 Mar 2022 20:50:14 +0000 (UTC)
Subject: [kolla] [rabbitmq] RMQ trouble after config update
In-Reply-To: <612895794.735804.1647634386875@mail.yahoo.com>
References: <405973893.569766.1647608065129.ref@mail.yahoo.com>
 <405973893.569766.1647608065129@mail.yahoo.com>
 <DU0PR10MB5244FF8FAC7F41D9AB9B25BDEA139@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>
 <612895794.735804.1647634386875@mail.yahoo.com>
Message-ID: <1452271910.755075.1647636614609@mail.yahoo.com>

 I fixed the typo and redeployed. The filter now reads:

{"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)|(notifications_designate)|(versioned_notifications)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0} ]

 I also tried deleting the RMQ containers and volumes and then redeploying, and deleting the queues and their exchanges, but they are re-created durable.
     On Friday, March 18, 2022, 04:22:17 PM EDT, Albert Braden <ozzzo at yahoo.com> wrote:  
 
  I did not intend to make the notifications_designate queues HA nor durable. It
appears that those two queues are treated differently from the others that I
didn't specify as HA. For example, if I look at one of the _fanout queues, it
is not durable:

Features
x-expires: 1800000
Policy
Operator policy
Effective policy definition
Node rabbit at de6-ctrl2

I tried adding the notifications_designate queues to the exclusion list:

 {"vhost": "/", "name": "ha-all", "pattern":
"^(?!(amq\.)|(.*_fanout_)|(reply_)(notifications_designate)|(versioned_notifications)).*",
"apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown":
"always", "ha-sync

But this doesn't seem to make a difference. The notifications_designate queues
still have " Features: durable: true"

How can I make the notifications_designate queues non-durable?     On Friday, March 18, 2022, 10:04:08 AM EDT, Felix H?ttner <felix.huettner at mail.schwarz> wrote:  
 
 Hi Albert,

for the queue "notifications_designate.info" both the "notifications-expire" and the "ha-all" policy would match with their pattern. However only one policy can be applied to a queue at any given point in time. I assume "notifications-expire" is applied (but you can check that easily in the UI or with "rabbitmqctl list_queues name policy").

In this case the "notifications_designate.info" is created as durable (because of amqp_durable_queues) and non-ha (as the policy does not define ha).
When a node with a durable and non-ha queue goes down then this queue no longer useable until either the node comes back or the queue is deleted.

In your case I would assume that you also want this queue to be HA, so you probably need to set the options of the "ha-all" policy also in the "notifications-expire" policy.

Regarding the last point of the queue being on ctrl2 and you connecting to ctrl1 this is normal rabbitmq behaviour in that it will forward messages to other nodes if needed.

Best Regards

Felix H?ttner
Schwarz IT KG * Stiftsbergstra?e 1 * D-74172 Neckarsulm

-----Original Message-----
From: Albert Braden <ozzzo at yahoo.com>
Sent: Friday, March 18, 2022 1:54 PM
To: Openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: [kolla] [rabbitmq] RMQ trouble after config update

We're running kolla-ansible Train. I followed the recommendations in [1] and ended up with the following config:

definitions.json (in the rabbitmq container):

{
? "vhosts": [
? ? {"name": "/"}? ],
? "users": [
? ? {"name": "openstack", "password": "<password>", "tags": "administrator"}? ],
? "permissions": [
? ? {"user": "openstack", "vhost": "/", "configure": ".*", "write": ".*", "read": ".*"}? ],
? "policies":[
? ? {"vhost": "/", "name": "notifications-expire", "pattern": "^(notifications_designate|versioned_notifications).*", "apply-to": "queues", "definition": {"message-ttl":600000,"expires":1200000}, "priority":0},
? ? {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0}? ] }

etc/kolla/config/global.conf:

[oslo_messaging_rabbit]
amqp_durable_queues = True

This fixed some issues, but we seem to have a new issue so I must be missing a setting. When we stop the RMQ container on ctrl1, designate stops working (DNS records are not created nor deleted) and I see this in designate-sink.log:

2022-03-17 19:21:29.261 28 ERROR oslo.messaging._drivers.impl_rabbit [req-2c0cd9f4-5331-4697-9c3e-eece475a52af - - - - -] Failed to consume message from queue: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible: amqp.exceptions.NotFound: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible

When I look at the notifications_designate.info queue in the web interface, it appears to have moved to ctrl2:

Features
durable:? ? ? ? ? ? ? true
Policy? ? notifications-expire
Operator policy
Effective policy definition
expires: 1200000
message-ttl:? ? ? 600000
Node? ? rabbit at qde3-ctrl2

When I look at designate.conf in the designate_sink containers I don't see anything pointing only to ctrl1:

transport_url = rabbit://openstack:<pwd>@<ctrl1>:5672,openstack:<pwd>@<ctrl2>:5672,openstack:<pwd>@<ctrl3>:5672//

But it appears that Designate still tries to use the queue on ctrl1. After I bring up ctrl1, the notifications_designate.info queue remains on ctrl2, but Designate starts working.

What am I missing?

[1] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FLarge_Scale_Configuration_Rabbit&data=04%7C01%7C%7C103b79868a61424923bb08da08df82f7%7Cd04f47175a6e4b98b3f96918e0385f4c%7C0%7C0%7C637832053312648154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1RIlfljNyKg71IrZc0NIuqDoHPkTGtSBthadz%2Bneofk%3D&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<https://www.datenschutz.schwarz>.

    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220318/3edaeb79/attachment-0001.htm>

From ahmedabdelhamid1221 at gmail.com  Fri Mar 18 13:30:16 2022
From: ahmedabdelhamid1221 at gmail.com (Ahmed Abdelhamid)
Date: Fri, 18 Mar 2022 09:30:16 -0400
Subject: Metadata service {devices list}
In-Reply-To: <CAOAKi8zYcJVbGuaC2cUvYdNUjgrJFPzm7ojyPDW+Zd3dgdmXcQ@mail.gmail.com>
References: <CAMRGJtetgCKOCZ2WDZUJ8dWWJDufODOXZ=ia3s_KegiVp1A64g@mail.gmail.com>
 <CAOAKi8zYcJVbGuaC2cUvYdNUjgrJFPzm7ojyPDW+Zd3dgdmXcQ@mail.gmail.com>
Message-ID: <CAMRGJtddyw6iPofy5qnb_w-FpLrzD83jbzQow=5e7M0_iYubmQ@mail.gmail.com>

Thanks, Laurent. I tried it for both CEPH-backed VMs and ones with local
disk, still, the devices array is empty

Network data curl shows alright

{"links": [{"id": "tapa.....", "vif_id": "ae....", "type": "bridge", "mtu":
1500, "ethernet_mac_address": "fa:......."}], "networks": [{"id":
"network0", "type": "ipv4_dhcp", "link": "tap.....

On Wed, Mar 16, 2022 at 6:39 PM Laurent Dumont <laurentfdumont at gmail.com>
wrote:

> Are you getting anything from the neutron endpoint?
>
> http://169.254.169.254/openstack/2018-08-27/network_data.json
>
> Can you provide an "openstack server show $server_id" of the VM? I wonder
> if it's a case of boot from a volume VM missing that data. It would not
> explain why the port is not there though.
>
> On Tue, Mar 15, 2022 at 9:15 AM Ahmed Abdelhamid <
> ahmedabdelhamid1221 at gmail.com> wrote:
>
>> Hi All,
>>
>> I am running into a strange issue with the metadata service. Per metadata-service
>> manual <https://docs.openstack.org/nova/latest/user/metadata.html>, the
>> devices attached to a VM should be visible in
>>
>> $ curl http://169.254.169.254/openstack/2018-08-27/meta_data.json
>>
>> However, whenever i execute it from a VM , the devices array is empty and
>> looks like this, any idea why ?
>>
>> Thanks
>>
>> {   "random_seed": "yu5ZnkqF2CqnDZVAfZgarG...",   "availability_zone": "nova",   "keys": [       {         "data": "ssh-rsa AAAAB3NzaC1y...== Generated by Nova\n",         "type": "ssh",         "name": "mykey"       }   ],   "hostname": "test.novalocal",   "launch_index": 0,   "meta": {      "priority": "low",      "role": "webserver"   },   "devices": [ ],   "project_id": "f7ac731cc11f40efbc03a9f9e1d1d21f",   "public_keys": {       "mykey": "ssh-rsa AAAAB3NzaC1y...== Generated by Nova\n"   },   "name": "test"}
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220318/917ecca9/attachment.htm>

From laurentfdumont at gmail.com  Sat Mar 19 02:06:43 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Fri, 18 Mar 2022 22:06:43 -0400
Subject: Metadata service {devices list}
In-Reply-To: <CAMRGJtddyw6iPofy5qnb_w-FpLrzD83jbzQow=5e7M0_iYubmQ@mail.gmail.com>
References: <CAMRGJtetgCKOCZ2WDZUJ8dWWJDufODOXZ=ia3s_KegiVp1A64g@mail.gmail.com>
 <CAOAKi8zYcJVbGuaC2cUvYdNUjgrJFPzm7ojyPDW+Zd3dgdmXcQ@mail.gmail.com>
 <CAMRGJtddyw6iPofy5qnb_w-FpLrzD83jbzQow=5e7M0_iYubmQ@mail.gmail.com>
Message-ID: <CAOAKi8zV65qujprXNVtTLibyd=L6wecmEdSgsfFWMySbrBdM5Q@mail.gmail.com>

That is weird.

   - What version of Openstack are you running?
   - How was it deployed?


On Fri, Mar 18, 2022 at 9:30 AM Ahmed Abdelhamid <
ahmedabdelhamid1221 at gmail.com> wrote:

> Thanks, Laurent. I tried it for both CEPH-backed VMs and ones with local
> disk, still, the devices array is empty
>
> Network data curl shows alright
>
> {"links": [{"id": "tapa.....", "vif_id": "ae....", "type": "bridge",
> "mtu": 1500, "ethernet_mac_address": "fa:......."}], "networks": [{"id":
> "network0", "type": "ipv4_dhcp", "link": "tap.....
>
> On Wed, Mar 16, 2022 at 6:39 PM Laurent Dumont <laurentfdumont at gmail.com>
> wrote:
>
>> Are you getting anything from the neutron endpoint?
>>
>> http://169.254.169.254/openstack/2018-08-27/network_data.json
>>
>> Can you provide an "openstack server show $server_id" of the VM? I wonder
>> if it's a case of boot from a volume VM missing that data. It would not
>> explain why the port is not there though.
>>
>> On Tue, Mar 15, 2022 at 9:15 AM Ahmed Abdelhamid <
>> ahmedabdelhamid1221 at gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> I am running into a strange issue with the metadata service. Per metadata-service
>>> manual <https://docs.openstack.org/nova/latest/user/metadata.html>, the
>>> devices attached to a VM should be visible in
>>>
>>> $ curl http://169.254.169.254/openstack/2018-08-27/meta_data.json
>>>
>>> However, whenever i execute it from a VM , the devices array is empty
>>> and looks like this, any idea why ?
>>>
>>> Thanks
>>>
>>> {   "random_seed": "yu5ZnkqF2CqnDZVAfZgarG...",   "availability_zone": "nova",   "keys": [       {         "data": "ssh-rsa AAAAB3NzaC1y...== Generated by Nova\n",         "type": "ssh",         "name": "mykey"       }   ],   "hostname": "test.novalocal",   "launch_index": 0,   "meta": {      "priority": "low",      "role": "webserver"   },   "devices": [ ],   "project_id": "f7ac731cc11f40efbc03a9f9e1d1d21f",   "public_keys": {       "mykey": "ssh-rsa AAAAB3NzaC1y...== Generated by Nova\n"   },   "name": "test"}
>>>
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220318/4ff1b68b/attachment-0001.htm>

From wakorins at gmail.com  Sun Mar 20 06:12:00 2022
From: wakorins at gmail.com (Wada Akor)
Date: Sun, 20 Mar 2022 07:12:00 +0100
Subject: Support For Openstack Charms juju and MaaS Deployment
Message-ID: <CAG8+hJMfZbEesaOi51T9qH6WLy9Nr8we4FMaTsKT1imfMQjKjg@mail.gmail.com>

Good day to every one of you ,
Please what is the advantage of using the above subject deployment process
compare to the manual installation process i have been using .

I will be really happy for any one with openstack charms deployment
knowledge support me

thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220320/34d1fef9/attachment.htm>

From berndbausch at gmail.com  Sun Mar 20 07:38:37 2022
From: berndbausch at gmail.com (Bernd Bausch)
Date: Sun, 20 Mar 2022 16:38:37 +0900
Subject: Support For Openstack Charms juju and MaaS Deployment
In-Reply-To: <CAG8+hJMfZbEesaOi51T9qH6WLy9Nr8we4FMaTsKT1imfMQjKjg@mail.gmail.com>
References: <CAG8+hJMfZbEesaOi51T9qH6WLy9Nr8we4FMaTsKT1imfMQjKjg@mail.gmail.com>
Message-ID: <f66a03e9-0a51-6cb5-fd59-03ef38f2460d@gmail.com>

I have never tried the Ubuntu methods, but I can tell you this.

First, without knowing your situation, the correct answer is always "it 
depends".

Having said that, in almost all cases, any automated deployment is 
better than manual deployment. An automated process is easier and more 
robust. It's also more robust during operation, since it is likely to 
have tools for managing and updating your cloud. Downside: You probably 
lose flexibility.

Bernd.

On 2022/03/20 3:12 PM, Wada Akor wrote:
> Good day to every one of you ,
> Please what is the advantage of using the above subject?deployment 
> process compare to the manual installation process i have been using .
>
> I will be really happy for any one with openstack charms deployment 
> knowledge support me
>
> thanks


From laurentfdumont at gmail.com  Sun Mar 20 12:52:57 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Sun, 20 Mar 2022 08:52:57 -0400
Subject: Support For Openstack Charms juju and MaaS Deployment
In-Reply-To: <f66a03e9-0a51-6cb5-fd59-03ef38f2460d@gmail.com>
References: <CAG8+hJMfZbEesaOi51T9qH6WLy9Nr8we4FMaTsKT1imfMQjKjg@mail.gmail.com>
 <f66a03e9-0a51-6cb5-fd59-03ef38f2460d@gmail.com>
Message-ID: <CAOAKi8zfpRzJwimDKYwCL1FFgi+v+1J89Tge4aPKKySVQeD2gg@mail.gmail.com>

All of the pre-built deployment tooling also allows a certain level of
sensible defaults. These tools are effectively built from the common pool
of knowledge of dozens of operators/enterprises.

Trying to build your own is a bit like re-inventing the wheel.

On Sun, Mar 20, 2022 at 3:41 AM Bernd Bausch <berndbausch at gmail.com> wrote:

> I have never tried the Ubuntu methods, but I can tell you this.
>
> First, without knowing your situation, the correct answer is always "it
> depends".
>
> Having said that, in almost all cases, any automated deployment is
> better than manual deployment. An automated process is easier and more
> robust. It's also more robust during operation, since it is likely to
> have tools for managing and updating your cloud. Downside: You probably
> lose flexibility.
>
> Bernd.
>
> On 2022/03/20 3:12 PM, Wada Akor wrote:
> > Good day to every one of you ,
> > Please what is the advantage of using the above subject deployment
> > process compare to the manual installation process i have been using .
> >
> > I will be really happy for any one with openstack charms deployment
> > knowledge support me
> >
> > thanks
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220320/af06ea6e/attachment.htm>

From miguel at mlavalle.com  Sun Mar 20 16:51:18 2022
From: miguel at mlavalle.com (Miguel Lavalle)
Date: Sun, 20 Mar 2022 11:51:18 -0500
Subject: [neutron] bug deputy report March 14th to 20th
Message-ID: <CAEzGLDj_M2U58RPXqzACXnzBh+B-XQYMdX9kCnXHs6ahYwJ6-g@mail.gmail.com>

Hi,

Here's this week's bugs deputy report:

High
====


Medium
======

https://bugs.launchpad.net/neutron/+bug/1965183 ovn migration executes
scripts from /tmp directory. Assigned to Jakub Libosvar. Proposed fix:
https://review.opendev.org/c/openstack/neutron/+/834071

https://bugs.launchpad.net/neutron/+bug/1965294 [Secure RBAC] Create
network error due to role without permissions isn't clear. Assigned to
Slawek Kaplonski. Proposed fix
https://review.opendev.org/c/openstack/neutron/+/834171

https://bugs.launchpad.net/neutron/+bug/1965297 l3ha don't set backup qg
ports down. Assigned to Edward Hope-Morley. Proposed fix
https://review.opendev.org/c/openstack/neutron/+/834162. This is a follow
up to drivers meeting:
https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-03-04-14.03.log.html#l-14

https://bugs.launchpad.net/neutron/+bug/1965530 ovn-octavia-provider health
monitoring fails because doesn't set the correct source IP address for OVN
health check. Assigned to Miguel Lavalle. Proposed fix
https://review.opendev.org/c/openstack/ovn-octavia-provider/+/834345

https://bugs.launchpad.net/neutron/+bug/1965599 python-ovs package 2.17
introduce table.condition attribute which is overwriten by neutron ovsdb
code. Needs owner

Low
===

RFEs
====

Incomplete
========

https://bugs.launchpad.net/neutron/+bug/1965140 Eventlet fails when
starting network agents
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220320/a5041b4f/attachment.htm>

From marcin.juszkiewicz at linaro.org  Mon Mar 21 09:57:00 2022
From: marcin.juszkiewicz at linaro.org (Marcin Juszkiewicz)
Date: Mon, 21 Mar 2022 10:57:00 +0100
Subject: Support For Openstack Charms juju and MaaS Deployment
In-Reply-To: <CAG8+hJMfZbEesaOi51T9qH6WLy9Nr8we4FMaTsKT1imfMQjKjg@mail.gmail.com>
References: <CAG8+hJMfZbEesaOi51T9qH6WLy9Nr8we4FMaTsKT1imfMQjKjg@mail.gmail.com>
Message-ID: <d3612f56-04fb-c24b-c065-35af17330abc@linaro.org>

W dniu 20.03.2022 o?07:12, Wada Akor pisze:
> Good day to every one of you ,
> Please what is the advantage of using the above subject?deployment 
> process compare to the manual installation process i have been using .
> 
> I will be really happy for any one with openstack charms deployment 
> knowledge support me

If you ignore ubuntu technologies (someone uses juju outside?) then you 
have OpenStack Kayobe/Kolla-ansible using Ansible to deploy on baremetal.



From felix.huettner at mail.schwarz  Mon Mar 21 10:11:17 2022
From: felix.huettner at mail.schwarz (=?iso-8859-1?Q?Felix_H=FCttner?=)
Date: Mon, 21 Mar 2022 10:11:17 +0000
Subject: [kolla] [rabbitmq] RMQ trouble after config update
In-Reply-To: <1452271910.755075.1647636614609@mail.yahoo.com>
References: <405973893.569766.1647608065129.ref@mail.yahoo.com>
 <405973893.569766.1647608065129@mail.yahoo.com>
 <DU0PR10MB5244FF8FAC7F41D9AB9B25BDEA139@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>
 <612895794.735804.1647634386875@mail.yahoo.com>
 <1452271910.755075.1647636614609@mail.yahoo.com>
Message-ID: <DU0PR10MB5244FF5ABF5F7DE7289EAF66EA169@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>

Hi Albert,

TL;DR: you set durable on your openstack service, not on rabbitmq. It is the same for all queues, so either you make them all HA or none of them (at least afaik).

the "durable" setting is not defined by the policy but by the client that declares the queue. Openstack normally uses the following setting for that:

[oslo_messaging_rabbit]
amqp_durable_queues = true

AFAIK this is a global setting and not different for notifications vs. other queues.
An exception of this is fanout/reply queues which are always non-durable.

The whole durable/HA thing can be summarized as follows

Durable: If true then the message will survive the crash/restart of a rabbitmq nodes. If false the message is lost on crash/restart. Set by the client declaring the queue
HA-mode: If enabled the queue is replicated across multiple nodes. If disabled only a single node hosts the queue and all messages. Set by the policy on rabbitmq

And the following are the result of restarts of a single node in each of the combinations:

Durable
Non-durable
HA
Queue is failing over to another node. All messages are preserved
DO NOT DO THIS. The queue should fail over to another node, but the other node does not have any message. This does not make sense and causes all kind of strange rabbitmq issues.
Non-HA
Queue is unavailable (no reads or writes) until the single node comes back. All messages are preserved.
Queue is deleted and all messages are lost. It can be redeclared on another node while the first one is down.


Best Regards

Felix H?ttner
Schwarz IT KG * Stiftsbergstra?e 1 * D-74172 Neckarsulm
From: Albert Braden <ozzzo at yahoo.com>
Sent: Friday, March 18, 2022 9:50 PM
To: Openstack-discuss <openstack-discuss at lists.openstack.org>; Felix H?ttner <felix.huettner at mail.schwarz>
Subject: Re: [kolla] [rabbitmq] RMQ trouble after config update

I fixed the typo and redeployed. The filter now reads:

{"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)|(notifications_designate)|(versioned_notifications)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0} ]

I also tried deleting the RMQ containers and volumes and then redeploying, and deleting the queues and their exchanges, but they are re-created durable.
On Friday, March 18, 2022, 04:22:17 PM EDT, Albert Braden <ozzzo at yahoo.com<mailto:ozzzo at yahoo.com>> wrote:


I did not intend to make the notifications_designate queues HA nor durable. It
appears that those two queues are treated differently from the others that I
didn't specify as HA. For example, if I look at one of the _fanout queues, it
is not durable:

Features
x-expires: 1800000
Policy
Operator policy
Effective policy definition
Node rabbit at de6-ctrl2

I tried adding the notifications_designate queues to the exclusion list:

{"vhost": "/", "name": "ha-all", "pattern":
"^(?!(amq\.)|(.*_fanout_)|(reply_)(notifications_designate)|(versioned_notifications)).*",
"apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown":
"always", "ha-sync

But this doesn't seem to make a difference. The notifications_designate queues
still have " Features: durable: true"

How can I make the notifications_designate queues non-durable?
On Friday, March 18, 2022, 10:04:08 AM EDT, Felix H?ttner <felix.huettner at mail.schwarz<mailto:felix.huettner at mail.schwarz>> wrote:


Hi Albert,

for the queue "notifications_designate.info" both the "notifications-expire" and the "ha-all" policy would match with their pattern. However only one policy can be applied to a queue at any given point in time. I assume "notifications-expire" is applied (but you can check that easily in the UI or with "rabbitmqctl list_queues name policy").

In this case the "notifications_designate.info" is created as durable (because of amqp_durable_queues) and non-ha (as the policy does not define ha).
When a node with a durable and non-ha queue goes down then this queue no longer useable until either the node comes back or the queue is deleted.

In your case I would assume that you also want this queue to be HA, so you probably need to set the options of the "ha-all" policy also in the "notifications-expire" policy.

Regarding the last point of the queue being on ctrl2 and you connecting to ctrl1 this is normal rabbitmq behaviour in that it will forward messages to other nodes if needed.

Best Regards

Felix H?ttner
Schwarz IT KG * Stiftsbergstra?e 1 * D-74172 Neckarsulm

-----Original Message-----
From: Albert Braden <ozzzo at yahoo.com<mailto:ozzzo at yahoo.com>>
Sent: Friday, March 18, 2022 1:54 PM
To: Openstack-discuss <openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>>
Subject: [kolla] [rabbitmq] RMQ trouble after config update

We're running kolla-ansible Train. I followed the recommendations in [1] and ended up with the following config:

definitions.json (in the rabbitmq container):

{
  "vhosts": [
    {"name": "/"}  ],
  "users": [
    {"name": "openstack", "password": "<password>", "tags": "administrator"}  ],
  "permissions": [
    {"user": "openstack", "vhost": "/", "configure": ".*", "write": ".*", "read": ".*"}  ],
  "policies":[
    {"vhost": "/", "name": "notifications-expire", "pattern": "^(notifications_designate|versioned_notifications).*", "apply-to": "queues", "definition": {"message-ttl":600000,"expires":1200000}, "priority":0},
    {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0}  ] }

etc/kolla/config/global.conf:

[oslo_messaging_rabbit]
amqp_durable_queues = True

This fixed some issues, but we seem to have a new issue so I must be missing a setting. When we stop the RMQ container on ctrl1, designate stops working (DNS records are not created nor deleted) and I see this in designate-sink.log:

2022-03-17 19:21:29.261 28 ERROR oslo.messaging._drivers.impl_rabbit [req-2c0cd9f4-5331-4697-9c3e-eece475a52af - - - - -] Failed to consume message from queue: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1<mailto:rabbit at de6-ctrl1>' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible: amqp.exceptions.NotFound: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1<mailto:rabbit at de6-ctrl1>' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible

When I look at the notifications_designate.info queue in the web interface, it appears to have moved to ctrl2:

Features
durable:              true
Policy    notifications-expire
Operator policy
Effective policy definition
expires: 1200000
message-ttl:      600000
Node    rabbit at qde3-ctrl2<mailto:rabbit at qde3-ctrl2>

When I look at designate.conf in the designate_sink containers I don't see anything pointing only to ctrl1:

transport_url = rabbit://openstack:<pwd>@<ctrl1>:5672,openstack:<pwd>@<ctrl2>:5672,openstack:<pwd>@<ctrl3>:5672//

But it appears that Designate still tries to use the queue on ctrl1. After I bring up ctrl1, the notifications_designate.info queue remains on ctrl2, but Designate starts working.

What am I missing?

[1]
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FLarge_Scale_Configuration_Rabbit&data=04%7C01%7C%7C103b79868a61424923bb08da08df82f7%7Cd04f47175a6e4b98b3f96918e0385f4c%7C0%7C0%7C637832053312648154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1RIlfljNyKg71IrZc0NIuqDoHPkTGtSBthadz%2Bneofk%3D&reserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FLarge_Scale_Configuration_Rabbit&data=04%7C01%7C%7Ca44639612f0048ec107208da0920eabd%7Cd04f47175a6e4b98b3f96918e0385f4c%7C0%7C0%7C637832334244057512%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MvODUG8xnlxoXHZIwYes3acbS5sZorSKTTmTHXtm5mQ%3D&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<https://www.datenschutz.schwarz<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.datenschutz.schwarz%2F&data=04%7C01%7C%7Ca44639612f0048ec107208da0920eabd%7Cd04f47175a6e4b98b3f96918e0385f4c%7C0%7C0%7C637832334244213646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=j7bKXsxGWxgMPUMPAQAs7q6RvoFjZP6qy4Vp5kBriAE%3D&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<https://www.datenschutz.schwarz>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220321/e3e53514/attachment-0001.htm>

From katonalala at gmail.com  Mon Mar 21 10:12:11 2022
From: katonalala at gmail.com (Lajos Katona)
Date: Mon, 21 Mar 2022 11:12:11 +0100
Subject: [neutron] Bug Deputy Report January 03 - 10
In-Reply-To: <68250a50-fc2e-4e8e-883d-5a214edc1f1a@inovex.de>
References: <CAB1EZBq7CC8uxqZMkj_QjSZZg0dGvSPhFNOGM8-Kqs95ej06dw@mail.gmail.com>
 <02b79e74-7d84-a6ba-537f-7db1a7ee6532@inovex.de>
 <CALg0jK=PMaspbFTBK2XkGjd28gZTdqMTOjaR791_X04ekBRQrQ@mail.gmail.com>
 <68250a50-fc2e-4e8e-883d-5a214edc1f1a@inovex.de>
Message-ID: <CALg0jKmk7QTL3cb8Sumjhh=W6vy1D9nYFsshu=yLKiuBvjSxpg@mail.gmail.com>

Hi Christian,
Thanks for your efforts for reproduction.
I will bring this topic to the team meeting tomorrow (
https://meetings.opendev.org/#Neutron_Team_Meeting ):
https://wiki.openstack.org/wiki/Network/Meetings#On_Demand_Agenda

Regarding your frustration, I totally understand it. It is, I think can be
a topic for the coming PTG.

Regards
Lajos Katona (lajoskatona)

Christian Rohmann <christian.rohmann at inovex.de> ezt ?rta (id?pont: 2022.
m?rc. 16., Sze, 23:23):

> Hey Lajos, Slawek.
>
> firstly I am truly very sorry about not responding to your kind message in
> any way until just now.
> I myself simply expected to be able to reproduce the issue quicker and
> postponed any response way too long.
> In any case: We were now able to reproduce the issue on DevStack with xena
> or master, see me comment at the end of this message.
>
>
> On 13/01/2022 09:34, Lajos Katona wrote:
>
> Thanks for highlighting your issue with Linuxbridge driver and VPNaaS.
> I would like to ask you to consider the following, which will not give you
> an answer or solution to your problem but perhaps helps to understand and
> accept if any specific issue has not received the needed attention from the
> community.
> Basically it is the core team (and some enthusiasts around it) who do bug
> triaging in Neutron, they are experienced and willing to provide answers,
> solutions.
> The possible combinations of drivers, extensions, backends, deployment
> tools is huge, and there are combinations which are not well covered in the
> current community, like linuxbridge is not that used (OVS and perhaps OVN
> are the top tested and deployed, at least from latest user surveys). So it
> can happen that in the current core team nobody has the special knowledge
> and tools (test environment, hardware...) to debug a specific issue.
>
> I understand and thank you for your patience in explaining this (likely
> not for the first time).
> I am already tracking the progress happening in regards to OVN, but
> unfortunately support for VPNaaS is still not available there, but there is
> a pending change at
> https://review.opendev.org/c/openstack/neutron-vpnaas/+/765353.
>
>
> On 13/01/2022 09:18, Slawek Kaplonski wrote:
>
> I don't just want to shout louder and certainly everybody wants their
> issue to be looked at and fixed first.
> But I just noticed that my bug report received no reply or confirmation
> in the last three months (apart from the tag "vpnaas" being added),
> while other issues were triaged quickly and were consequently added to
> this deputy report ...
>
> The problem with neutron-vpnaas is that there is almost no one who is
> maintining that project currently and probably because of that nobody works on
> the bug which You reported.
> If You are using that project and are interested in maintaining it, patches
> are always welcome :)
>
> Not to push back on anything your said, it's just a bit frustrating
> sometimes that there seems to be no explicit deprecation and then EoL path
> for certain backends / drivers. To me this would be totally understandable
> as a way to free development time and bug hunting efforts.
> And at the same time this means providing some strong guidance to the
> userbase what to avoid or actively moving away from.
>
> The most prominent example to me, as our deployment was affected by this
> as well, is using PostgreSQL as DBMS. While there is this message,
> https://governance.openstack.org/tc/resolutions/20170613-postgresql-status.html,
> explaining that there will be less focus on PostgreSQL, it would actually
> be much better to simply deprecate support for this DBMS and then clearly
> state this for the next releases.
> With a state of "supported, but not widely used", users will just have a
> hard time getting their reported bugs validated and fixed. Even reviewers
> for sent in patches are hard to find, see e.g.
> https://review.opendev.org/c/openstack/designate/+/668493. But even if an
> issue was found and fixed, as
> https://review.opendev.org/c/openstack/glance/+/820247, a similar issue
> is just around the corner, as this configuration is just not actively
> tested and validated.
>
> Looking at Neutron there are lots of tables and comparisons. But I am not
> convinced the feature tables and complex interdependencies at
>
>  *
> https://docs.openstack.org/neutron/latest/feature_classification/general_feature_support_matrix.html
>  * https://docs.openstack.org/neutron/latest/admin/config-ml2.html#id5
>  * https://docs.openstack.org/neutron/latest/ovn/gaps.html
>
> help a new Neutron user to make the right choices.
> I already somewhat read between the lines that OVS support could be
> dropped in favor of OVN at some point - like RedHat recommends and explains
> here:
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.1/html/networking_with_open_virtual_network/migrating-ml2ovs-to-ovn
>
> What I am trying to say is that it would be ok to drop support for
> something at some point to free time and effort to focus on more common
> configurations and making them work as best they can.
> But this also includes making active recommendations and getting the
> missing features tackled (as in VPNaaS for OVN) so people can actually be
> asked to migrate away from a EoL config.
>
>
> On 13/01/2022 09:34, Lajos Katona wrote:
>
>
> Neutron maintains a list of "lieutenants", to make easier to contact the
> right person:
>
> https://docs.openstack.org/neutron/latest/contributor/policies/neutron-teams.html#neutron-lieutenants
> For VPNaaS the people are not active anymore in the community.
> In such difficult to debug situation it is really helpful for the
> community if you can test the issue on current master code (it is possible
> that the issue happens only on older branches) and with tools that are
> available for most of us, like simple devstack.
>
> My colleague Niklas Schwarz did setup two devstack nodes and documented
> their config as well as required steps setting up VPNs to then trigger the
> reported duplicate iptables issue, see
> https://bugs.launchpad.net/neutron/+bug/1943449/comments/4.
> Please kindly take a look and let me know if there is any more details we
> need to provide. But since we have this issue reproducible in devstack I
> hope you'll be able to narrow it down.
>
>
>
>
> Regards and thanks again for your patience,
>
>
> Christian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220321/64fe752f/attachment.htm>

From james.page at canonical.com  Mon Mar 21 10:13:10 2022
From: james.page at canonical.com (James Page)
Date: Mon, 21 Mar 2022 10:13:10 +0000
Subject: Support For Openstack Charms juju and MaaS Deployment
In-Reply-To: <CAG8+hJMfZbEesaOi51T9qH6WLy9Nr8we4FMaTsKT1imfMQjKjg@mail.gmail.com>
References: <CAG8+hJMfZbEesaOi51T9qH6WLy9Nr8we4FMaTsKT1imfMQjKjg@mail.gmail.com>
Message-ID: <CAG1bqQpzn7XGuHie5PCZuWDK5QoYhJ-8S3E_G0HBQ61WoKxyng@mail.gmail.com>

Hi Wada

On Sun, Mar 20, 2022 at 6:17 AM Wada Akor <wakorins at gmail.com> wrote:

> Good day to every one of you ,
> Please what is the advantage of using the above subject deployment process
> compare to the manual installation process i have been using .
>
> I will be really happy for any one with openstack charms deployment
> knowledge support me
>

Most deployment automation tooling aims to reduce the cost in terms of
time to deploy and manage whatever workload they are associated with and
the OpenStack Charms are aligned to this philosophy.

The main project deployment guide can be found here:


https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/

and the charm guide has quite a bit of documentation around how to use the
chams for various operational activities once you're up and running:

  https://docs.openstack.org/charm-guide/latest/

You can find the community of both users and developers of the charms on
IRC:

  #openstack-charms on OFTC

or on the charmhub mattermost channel (although that tends to be quieter):

  https://chat.charmhub.io/charmhub/channels/openstack-charms

Hope that helps get you started.

Cheers

James

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220321/524ae991/attachment.htm>

From stephane.chalansonnet at acoss.fr  Mon Mar 21 10:22:48 2022
From: stephane.chalansonnet at acoss.fr (=?iso-8859-1?Q?CHALANSONNET_St=E9phane_=28Acoss=29?=)
Date: Mon, 21 Mar 2022 10:22:48 +0000
Subject: Linux bonding configuration compute OpenStack / provider networks
Message-ID: <MRZP264MB1749BB60D3FE69063D01EB3897169@MRZP264MB1749.FRAP264.PROD.OUTLOOK.COM>

Hello,

We used in our OpenStack Production the following configuration on computes :
Centos7
Blade Gen10 on HPE C7000 Flex-10

Bonding for the public Interfaces
BONDING_OPTS="mode=6 miimon=100"

OpenVswitch under this Bonding

We did not find any particularsproblems, i am just curious which configuration are you using please ?

Thank you for your answer

Greeting


[cid:image001.jpg at 01D83D15.8EB53F00]
St?phane Chalansonnet

Secteur Op?rations Techniques
Responsable Gamme H?bergement Datacenter
DSI - Sous-Direction Architecture Technique

stephane.chalansonnet at acoss.fr<mailto:stephane.chalansonnet at acoss.fr>
04 37 60 19 90 * 06 80 89 92 23
590 cours du 3eme mill?naire, 69800 Saint-Priest
www.urssaf.fr<https://www.urssaf.fr/>
[cid:image006.png at 01D83D15.FC848360]<https://www.youtube.com/channel/UCSjS8hOXCs5FlAnTi74rPrA>[cid:image007.png at 01D83D15.FC848360]<https://www.linkedin.com/company/acoss/>[cid:image006.png at 01D83D15.FC848360]<https://twitter.com/urssaf>[cid:image005.jpg at 01D83D15.8EB53F00]


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220321/152e460f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2683 bytes
Desc: image001.jpg
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220321/152e460f/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 2176 bytes
Desc: image005.jpg
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220321/152e460f/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 179 bytes
Desc: image006.png
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220321/152e460f/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 178 bytes
Desc: image007.png
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220321/152e460f/attachment-0003.png>

From ozzzo at yahoo.com  Mon Mar 21 13:56:05 2022
From: ozzzo at yahoo.com (Albert Braden)
Date: Mon, 21 Mar 2022 13:56:05 +0000 (UTC)
Subject: [kolla] [rabbitmq] RMQ trouble after config update
In-Reply-To: <DU0PR10MB5244FF5ABF5F7DE7289EAF66EA169@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>
References: <405973893.569766.1647608065129.ref@mail.yahoo.com>
 <405973893.569766.1647608065129@mail.yahoo.com>
 <DU0PR10MB5244FF8FAC7F41D9AB9B25BDEA139@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>
 <612895794.735804.1647634386875@mail.yahoo.com>
 <1452271910.755075.1647636614609@mail.yahoo.com>
 <DU0PR10MB5244FF5ABF5F7DE7289EAF66EA169@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <222141973.1340186.1647870965176@mail.yahoo.com>

 Thank you Felix; that?s very helpful. I think I understand how it works now. The problem is, I want the notifications_designate messages to expire, because if they don?t, unconsumed messages linger forever. Is it possible to combine these two policies so that all durable queues are HA, but notifications_designate still expires? Can I have two definitions applied to different patterns in a single policy?

 {"vhost": "/", "name": "notifications-expire", "pattern": "^(notifications_designate|versioned_notifications).*", "apply-to": "queues", "definition": {"message-ttl":600000,"expires":1200000}, "priority":0},
 {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0} ] }
     On Monday, March 21, 2022, 06:11:23 AM EDT, Felix H?ttner <felix.huettner at mail.schwarz> wrote:  
 
 <!--#yiv5740977587 _filtered {} _filtered {} _filtered {}#yiv5740977587 #yiv5740977587 p.yiv5740977587MsoNormal, #yiv5740977587 li.yiv5740977587MsoNormal, #yiv5740977587 div.yiv5740977587MsoNormal {margin:0cm;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv5740977587 a:link, #yiv5740977587 span.yiv5740977587MsoHyperlink {color:blue;text-decoration:underline;}#yiv5740977587 span.yiv5740977587E-MailFormatvorlage20 {font-family:"Calibri", sans-serif;color:windowtext;}#yiv5740977587 .yiv5740977587MsoChpDefault {font-family:"Calibri", sans-serif;} _filtered {}#yiv5740977587 div.yiv5740977587WordSection1 {}-->
Hi Albert,
 
 ?
 
TL;DR: you set durable on your openstack service, not on rabbitmq. It is the same for all queues, so either you make them all HA or none of them (at least afaik).
 
 ?
 
the ?durable? setting is not defined by the policy but by the client that declares the queue. Openstack normally uses the following setting for that:
 
 ?
 
[oslo_messaging_rabbit]
 
amqp_durable_queues = true
 
 ?
 
AFAIK this is a global setting and not different for notifications vs. other queues.
 
An exception of this is fanout/reply queues which are always non-durable.
 
 ?
 
The whole durable/HA thing can be summarized as follows
 
 ?
 
Durable: If true then the message will survive the crash/restart of a rabbitmq nodes. If false the message is lost on crash/restart. Set by the client declaring the queue
 
HA-mode: If enabled the queue is replicated across multiple nodes. If disabled only a single node hosts the queue and all messages. Set by the policy on rabbitmq
 
 ?
 
And the following are the result of restarts of a single node in each of the combinations:
 
| 
 ?
  | 
Durable
  | 
Non-durable
  |
| 
HA
  | 
Queue is failing over to another node. All messages are preserved
  | 
DO NOT DO THIS. The queue should fail over to another node, but the other node does not have any message. This does not make sense and causes all kind of strange rabbitmq issues.
  |
| 
Non-HA
  | 
Queue is unavailable (no reads or writes) until the single node comes back. All messages are preserved.
  | 
Queue is deleted and all messages are lost. It can be redeclared on another node while the first one is down.
  |


 ?
 
 ?
 
Best Regards

Felix H?ttner
Schwarz IT KG * Stiftsbergstra?e 1 * D-74172 Neckarsulm
 
From: Albert Braden <ozzzo at yahoo.com> 
Sent: Friday, March 18, 2022 9:50 PM
To: Openstack-discuss <openstack-discuss at lists.openstack.org>; Felix H?ttner <felix.huettner at mail.schwarz>
Subject: Re: [kolla] [rabbitmq] RMQ trouble after config update
 
 ?
 
I fixed the typo and redeployed. The filter now reads:

{"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)|(notifications_designate)|(versioned_notifications)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0} ]

I also tried deleting the RMQ containers and volumes and then redeploying, and deleting the queues and their exchanges, but they are re-created durable.
 
On Friday, March 18, 2022, 04:22:17 PM EDT, Albert Braden <ozzzo at yahoo.com> wrote:
 
 ?
 
 ?
 
I did not intend to make the notifications_designate queues HA nor durable. It
appears that those two queues are treated differently from the others that I
didn't specify as HA. For example, if I look at one of the _fanout queues, it
is not durable:

Features
x-expires: 1800000
Policy
Operator policy
Effective policy definition
Node rabbit at de6-ctrl2

I tried adding the notifications_designate queues to the exclusion list:

{"vhost": "/", "name": "ha-all", "pattern":
"^(?!(amq\.)|(.*_fanout_)|(reply_)(notifications_designate)|(versioned_notifications)).*",
"apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown":
"always", "ha-sync

But this doesn't seem to make a difference. The notifications_designate queues
still have " Features: durable: true"

How can I make the notifications_designate queues non-durable? 
 
On Friday, March 18, 2022, 10:04:08 AM EDT, Felix H?ttner <felix.huettner at mail.schwarz> wrote:
 
 ?
 
 ?
 
Hi Albert,

for the queue "notifications_designate.info" both the "notifications-expire" and the "ha-all" policy would match with their pattern. However only one policy can be applied to a queue at any given point in time. I assume "notifications-expire" is applied (but you can check that easily in the UI or with "rabbitmqctl list_queues name policy").

In this case the "notifications_designate.info" is created as durable (because of amqp_durable_queues) and non-ha (as the policy does not define ha).
When a node with a durable and non-ha queue goes down then this queue no longer useable until either the node comes back or the queue is deleted.

In your case I would assume that you also want this queue to be HA, so you probably need to set the options of the "ha-all" policy also in the "notifications-expire" policy.

Regarding the last point of the queue being on ctrl2 and you connecting to ctrl1 this is normal rabbitmq behaviour in that it will forward messages to other nodes if needed.

Best Regards

Felix H?ttner
Schwarz IT KG * Stiftsbergstra?e 1 * D-74172 Neckarsulm
 

-----Original Message-----
From: Albert Braden <ozzzo at yahoo.com>
Sent: Friday, March 18, 2022 1:54 PM
To: Openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: [kolla] [rabbitmq] RMQ trouble after config update

We're running kolla-ansible Train. I followed the recommendations in [1] and ended up with the following config:

definitions.json (in the rabbitmq container):

{
? "vhosts": [
? ? {"name": "/"}? ],
? "users": [
? ? {"name": "openstack", "password": "<password>", "tags": "administrator"}? ],
? "permissions": [
? ? {"user": "openstack", "vhost": "/", "configure": ".*", "write": ".*", "read": ".*"}? ],
? "policies":[
? ? {"vhost": "/", "name": "notifications-expire", "pattern": "^(notifications_designate|versioned_notifications).*", "apply-to": "queues", "definition": {"message-ttl":600000,"expires":1200000}, "priority":0},
? ? {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0}? ] }

etc/kolla/config/global.conf:

[oslo_messaging_rabbit]
amqp_durable_queues = True

This fixed some issues, but we seem to have a new issue so I must be missing a setting. When we stop the RMQ container on ctrl1, designate stops working (DNS records are not created nor deleted) and I see this in designate-sink.log:

2022-03-17 19:21:29.261 28 ERROR oslo.messaging._drivers.impl_rabbit [req-2c0cd9f4-5331-4697-9c3e-eece475a52af - - - - -] Failed to consume message from queue: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible: amqp.exceptions.NotFound: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible

When I look at the notifications_designate.info queue in the web interface, it appears to have moved to ctrl2:

Features
durable:? ? ? ? ? ? ? true
Policy? ? notifications-expire
Operator policy
Effective policy definition
expires: 1200000
message-ttl:? ? ? 600000
Node? ? rabbit at qde3-ctrl2

When I look at designate.conf in the designate_sink containers I don't see anything pointing only to ctrl1:

transport_url = rabbit://openstack:<pwd>@<ctrl1>:5672,openstack:<pwd>@<ctrl2>:5672,openstack:<pwd>@<ctrl3>:5672//

But it appears that Designate still tries to use the queue on ctrl1. After I bring up ctrl1, the notifications_designate.info queue remains on ctrl2, but Designate starts working.

What am I missing?

[1] 
 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FLarge_Scale_Configuration_Rabbit&data=04%7C01%7C%7C103b79868a61424923bb08da08df82f7%7Cd04f47175a6e4b98b3f96918e0385f4c%7C0%7C0%7C637832053312648154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1RIlfljNyKg71IrZc0NIuqDoHPkTGtSBthadz%2Bneofk%3D&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<https://www.datenschutz.schwarz
 
>.
 
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 Siehier.
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220321/02dfb0b1/attachment-0001.htm>

From ahmedabdelhamid1221 at gmail.com  Sun Mar 20 15:10:55 2022
From: ahmedabdelhamid1221 at gmail.com (Ahmed Abdelhamid)
Date: Sun, 20 Mar 2022 11:10:55 -0400
Subject: Metadata service {devices list}
In-Reply-To: <CAOAKi8zV65qujprXNVtTLibyd=L6wecmEdSgsfFWMySbrBdM5Q@mail.gmail.com>
References: <CAMRGJtetgCKOCZ2WDZUJ8dWWJDufODOXZ=ia3s_KegiVp1A64g@mail.gmail.com>
 <CAOAKi8zYcJVbGuaC2cUvYdNUjgrJFPzm7ojyPDW+Zd3dgdmXcQ@mail.gmail.com>
 <CAMRGJtddyw6iPofy5qnb_w-FpLrzD83jbzQow=5e7M0_iYubmQ@mail.gmail.com>
 <CAOAKi8zV65qujprXNVtTLibyd=L6wecmEdSgsfFWMySbrBdM5Q@mail.gmail.com>
Message-ID: <CAMRGJtd=yKD3uGz+b70BfrJLTbUAgE77PL+MmUqvPw_1=fjmgw@mail.gmail.com>

Thanks. It's OpenStack ussuri, deployed via kolla-ansible

On Fri, Mar 18, 2022 at 10:06 PM Laurent Dumont <laurentfdumont at gmail.com>
wrote:

> That is weird.
>
>    - What version of Openstack are you running?
>    - How was it deployed?
>
>
> On Fri, Mar 18, 2022 at 9:30 AM Ahmed Abdelhamid <
> ahmedabdelhamid1221 at gmail.com> wrote:
>
>> Thanks, Laurent. I tried it for both CEPH-backed VMs and ones with local
>> disk, still, the devices array is empty
>>
>> Network data curl shows alright
>>
>> {"links": [{"id": "tapa.....", "vif_id": "ae....", "type": "bridge",
>> "mtu": 1500, "ethernet_mac_address": "fa:......."}], "networks": [{"id":
>> "network0", "type": "ipv4_dhcp", "link": "tap.....
>>
>> On Wed, Mar 16, 2022 at 6:39 PM Laurent Dumont <laurentfdumont at gmail.com>
>> wrote:
>>
>>> Are you getting anything from the neutron endpoint?
>>>
>>> http://169.254.169.254/openstack/2018-08-27/network_data.json
>>>
>>> Can you provide an "openstack server show $server_id" of the VM? I
>>> wonder if it's a case of boot from a volume VM missing that data. It would
>>> not explain why the port is not there though.
>>>
>>> On Tue, Mar 15, 2022 at 9:15 AM Ahmed Abdelhamid <
>>> ahmedabdelhamid1221 at gmail.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I am running into a strange issue with the metadata service. Per metadata-service
>>>> manual <https://docs.openstack.org/nova/latest/user/metadata.html>,
>>>> the devices attached to a VM should be visible in
>>>>
>>>> $ curl http://169.254.169.254/openstack/2018-08-27/meta_data.json
>>>>
>>>> However, whenever i execute it from a VM , the devices array is empty
>>>> and looks like this, any idea why ?
>>>>
>>>> Thanks
>>>>
>>>> {   "random_seed": "yu5ZnkqF2CqnDZVAfZgarG...",   "availability_zone": "nova",   "keys": [       {         "data": "ssh-rsa AAAAB3NzaC1y...== Generated by Nova\n",         "type": "ssh",         "name": "mykey"       }   ],   "hostname": "test.novalocal",   "launch_index": 0,   "meta": {      "priority": "low",      "role": "webserver"   },   "devices": [ ],   "project_id": "f7ac731cc11f40efbc03a9f9e1d1d21f",   "public_keys": {       "mykey": "ssh-rsa AAAAB3NzaC1y...== Generated by Nova\n"   },   "name": "test"}
>>>>
>>>>
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220320/e966cfb9/attachment-0001.htm>

From felix.huettner at mail.schwarz  Mon Mar 21 14:20:46 2022
From: felix.huettner at mail.schwarz (=?iso-8859-1?Q?Felix_H=FCttner?=)
Date: Mon, 21 Mar 2022 14:20:46 +0000
Subject: [kolla] [rabbitmq] RMQ trouble after config update
In-Reply-To: <222141973.1340186.1647870965176@mail.yahoo.com>
References: <405973893.569766.1647608065129.ref@mail.yahoo.com>
 <405973893.569766.1647608065129@mail.yahoo.com>
 <DU0PR10MB5244FF8FAC7F41D9AB9B25BDEA139@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>
 <612895794.735804.1647634386875@mail.yahoo.com>
 <1452271910.755075.1647636614609@mail.yahoo.com>
 <DU0PR10MB5244FF5ABF5F7DE7289EAF66EA169@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>
 <222141973.1340186.1647870965176@mail.yahoo.com>
Message-ID: <DU0PR10MB5244D0F445E12A93AD10C75AEA169@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>

Hi Albert,

i think the following should work (but not tested)

{"vhost": "/", "name": "notifications-expire", "pattern": "^(notifications_designate|versioned_notifications).*", "apply-to": "queues", "definition": {"message-ttl":600000,"expires":1200000, "ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":1},
{"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0}

Note the "priority": 1 on the first one. It should ensure it is prioritized over the second one.
This way the notifications get all the ha setting as well as the expire stuff.


Best Regards

Felix H?ttner
Schwarz IT KG * Stiftsbergstra?e 1 * D-74172 Neckarsulm
From: Albert Braden <ozzzo at yahoo.com>
Sent: Monday, March 21, 2022 2:56 PM
To: Openstack-discuss <openstack-discuss at lists.openstack.org>; Felix H?ttner <felix.huettner at mail.schwarz>
Subject: Re: [kolla] [rabbitmq] RMQ trouble after config update

Thank you Felix; that's very helpful. I think I understand how it works now. The problem is, I want the notifications_designate messages to expire, because if they don't, unconsumed messages linger forever. Is it possible to combine these two policies so that all durable queues are HA, but notifications_designate still expires? Can I have two definitions applied to different patterns in a single policy?

{"vhost": "/", "name": "notifications-expire", "pattern": "^(notifications_designate|versioned_notifications).*", "apply-to": "queues", "definition": {"message-ttl":600000,"expires":1200000}, "priority":0},
{"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0} ] }
On Monday, March 21, 2022, 06:11:23 AM EDT, Felix H?ttner <felix.huettner at mail.schwarz<mailto:felix.huettner at mail.schwarz>> wrote:



Hi Albert,



TL;DR: you set durable on your openstack service, not on rabbitmq. It is the same for all queues, so either you make them all HA or none of them (at least afaik).



the "durable" setting is not defined by the policy but by the client that declares the queue. Openstack normally uses the following setting for that:



[oslo_messaging_rabbit]

amqp_durable_queues = true



AFAIK this is a global setting and not different for notifications vs. other queues.

An exception of this is fanout/reply queues which are always non-durable.



The whole durable/HA thing can be summarized as follows



Durable: If true then the message will survive the crash/restart of a rabbitmq nodes. If false the message is lost on crash/restart. Set by the client declaring the queue

HA-mode: If enabled the queue is replicated across multiple nodes. If disabled only a single node hosts the queue and all messages. Set by the policy on rabbitmq



And the following are the result of restarts of a single node in each of the combinations:



Durable

Non-durable

HA

Queue is failing over to another node. All messages are preserved

DO NOT DO THIS. The queue should fail over to another node, but the other node does not have any message. This does not make sense and causes all kind of strange rabbitmq issues.

Non-HA

Queue is unavailable (no reads or writes) until the single node comes back. All messages are preserved.

Queue is deleted and all messages are lost. It can be redeclared on another node while the first one is down.





Best Regards

Felix H?ttner
Schwarz IT KG * Stiftsbergstra?e 1 * D-74172 Neckarsulm

From: Albert Braden <ozzzo at yahoo.com<mailto:ozzzo at yahoo.com>>
Sent: Friday, March 18, 2022 9:50 PM
To: Openstack-discuss <openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>>; Felix H?ttner <felix.huettner at mail.schwarz<mailto:felix.huettner at mail.schwarz>>
Subject: Re: [kolla] [rabbitmq] RMQ trouble after config update



I fixed the typo and redeployed. The filter now reads:

{"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)|(notifications_designate)|(versioned_notifications)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0} ]

I also tried deleting the RMQ containers and volumes and then redeploying, and deleting the queues and their exchanges, but they are re-created durable.

On Friday, March 18, 2022, 04:22:17 PM EDT, Albert Braden <ozzzo at yahoo.com<mailto:ozzzo at yahoo.com>> wrote:





I did not intend to make the notifications_designate queues HA nor durable. It
appears that those two queues are treated differently from the others that I
didn't specify as HA. For example, if I look at one of the _fanout queues, it
is not durable:

Features
x-expires: 1800000
Policy
Operator policy
Effective policy definition
Node rabbit at de6-ctrl2

I tried adding the notifications_designate queues to the exclusion list:

{"vhost": "/", "name": "ha-all", "pattern":
"^(?!(amq\.)|(.*_fanout_)|(reply_)(notifications_designate)|(versioned_notifications)).*",
"apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown":
"always", "ha-sync

But this doesn't seem to make a difference. The notifications_designate queues
still have " Features: durable: true"

How can I make the notifications_designate queues non-durable?

On Friday, March 18, 2022, 10:04:08 AM EDT, Felix H?ttner <felix.huettner at mail.schwarz<mailto:felix.huettner at mail.schwarz>> wrote:





Hi Albert,

for the queue "notifications_designate.info" both the "notifications-expire" and the "ha-all" policy would match with their pattern. However only one policy can be applied to a queue at any given point in time. I assume "notifications-expire" is applied (but you can check that easily in the UI or with "rabbitmqctl list_queues name policy").

In this case the "notifications_designate.info" is created as durable (because of amqp_durable_queues) and non-ha (as the policy does not define ha).
When a node with a durable and non-ha queue goes down then this queue no longer useable until either the node comes back or the queue is deleted.

In your case I would assume that you also want this queue to be HA, so you probably need to set the options of the "ha-all" policy also in the "notifications-expire" policy.

Regarding the last point of the queue being on ctrl2 and you connecting to ctrl1 this is normal rabbitmq behaviour in that it will forward messages to other nodes if needed.

Best Regards

Felix H?ttner
Schwarz IT KG * Stiftsbergstra?e 1 * D-74172 Neckarsulm

-----Original Message-----
From: Albert Braden <ozzzo at yahoo.com<mailto:ozzzo at yahoo.com>>
Sent: Friday, March 18, 2022 1:54 PM
To: Openstack-discuss <openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>>
Subject: [kolla] [rabbitmq] RMQ trouble after config update

We're running kolla-ansible Train. I followed the recommendations in [1] and ended up with the following config:

definitions.json (in the rabbitmq container):

{
  "vhosts": [
    {"name": "/"}  ],
  "users": [
    {"name": "openstack", "password": "<password>", "tags": "administrator"}  ],
  "permissions": [
    {"user": "openstack", "vhost": "/", "configure": ".*", "write": ".*", "read": ".*"}  ],
  "policies":[
    {"vhost": "/", "name": "notifications-expire", "pattern": "^(notifications_designate|versioned_notifications).*", "apply-to": "queues", "definition": {"message-ttl":600000,"expires":1200000}, "priority":0},
    {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0}  ] }

etc/kolla/config/global.conf:

[oslo_messaging_rabbit]
amqp_durable_queues = True

This fixed some issues, but we seem to have a new issue so I must be missing a setting. When we stop the RMQ container on ctrl1, designate stops working (DNS records are not created nor deleted) and I see this in designate-sink.log:

2022-03-17 19:21:29.261 28 ERROR oslo.messaging._drivers.impl_rabbit [req-2c0cd9f4-5331-4697-9c3e-eece475a52af - - - - -] Failed to consume message from queue: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1<mailto:rabbit at de6-ctrl1>' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible: amqp.exceptions.NotFound: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1<mailto:rabbit at de6-ctrl1>' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible

When I look at the notifications_designate.info queue in the web interface, it appears to have moved to ctrl2:

Features
durable:              true
Policy    notifications-expire
Operator policy
Effective policy definition
expires: 1200000
message-ttl:      600000
Node    rabbit at qde3-ctrl2<mailto:rabbit at qde3-ctrl2>

When I look at designate.conf in the designate_sink containers I don't see anything pointing only to ctrl1:

transport_url = rabbit://openstack:<pwd>@<ctrl1>:5672,openstack:<pwd>@<ctrl2>:5672,openstack:<pwd>@<ctrl3>:5672//

But it appears that Designate still tries to use the queue on ctrl1. After I bring up ctrl1, the notifications_designate.info queue remains on ctrl2, but Designate starts working.

What am I missing?

[1]

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FLarge_Scale_Configuration_Rabbit&data=04%7C01%7C%7C103b79868a61424923bb08da08df82f7%7Cd04f47175a6e4b98b3f96918e0385f4c%7C0%7C0%7C637832053312648154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1RIlfljNyKg71IrZc0NIuqDoHPkTGtSBthadz%2Bneofk%3D&reserved=0<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FLarge_Scale_Configuration_Rabbit&data=04%7C01%7C%7C32d09b881bb2459c89d008da0b428c8c%7Cd04f47175a6e4b98b3f96918e0385f4c%7C0%7C0%7C637834677702617860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QTI4mDjems3GOf6pEOkPAlTqNA68SYvlUVmNQ%2BnVu%2Bg%3D&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<https://www.datenschutz.schwarz<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.datenschutz.schwarz%2F&data=04%7C01%7C%7C32d09b881bb2459c89d008da0b428c8c%7Cd04f47175a6e4b98b3f96918e0385f4c%7C0%7C0%7C637834677702617860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jlA5EviINuxe%2BjZU15IplSM3eWyaKco0OotB1PLdx3E%3D&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 Siehier<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.datenschutz.schwarz%2F&data=04%7C01%7C%7C32d09b881bb2459c89d008da0b428c8c%7Cd04f47175a6e4b98b3f96918e0385f4c%7C0%7C0%7C637834677702617860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jlA5EviINuxe%2BjZU15IplSM3eWyaKco0OotB1PLdx3E%3D&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<https://www.datenschutz.schwarz>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220321/99406a78/attachment-0001.htm>

From alan.davis at apogee-research.com  Mon Mar 21 19:31:43 2022
From: alan.davis at apogee-research.com (Alan Davis)
Date: Mon, 21 Mar 2022 15:31:43 -0400
Subject: [nova][scheduler] DiskFilter return 0 when launching pre-allocated
 disk volume
Message-ID: <CADjfRFtBQXec2tA+jdKEaCb6TJVxnr22wiF4A55jakFPb05BEw@mail.gmail.com>

All,

 I'm having a problem with launching a volume that already exists. I'm not
finding any indication why DiskFilter is saying there's not enough disk
space available.
This is not a new system, it's been in use for over a year and has more
than 20 VM's running on it already. Creating a volume (either from image or
from install iso) is my normal way of creating instances, so this isn't
anything I haven't done many times.

Any ideas on why or what debugging steps I can take would be appreciated.

Here's the error from nova-scheduler.log

2022-03-21 15:20:22.021 16602 INFO nova.filters
[req-f8909a62-723d-4128-9e68-2fe445fa861d a676762eea994d08a7ce018c3ccbb0b8
1ab386267c2b4c969d551ea763c906dc - default default] Filtering removed all
hosts for the request with instance ID
'59dfe21d-c527-4fd7-ad50-39c144af93fc'. Filter results: ['RetryFilter:
(start: 1, end: 1)', 'AvailabilityZoneFilter: (start: 1, end: 1)',
'RamFilter: (start: 1, end: 1)', 'DiskFilter: (start: 1, end: 0)']

vgs (yes, i know... LVM) shows plenty of space, as well

 VG             #PV #LV #SN Attr   VSize  VFree
  centos_stack2    1   3   0 wz--n- 74.00g     0
  cinder-volumes   1  51   1 wz--n- <9.10t <3.64t

openstack says:
+--------------------------------+---------------------------------------+
| Field                          | Value                                 |
+--------------------------------+---------------------------------------+
| attachments                    | []                                    |
| availability_zone              | nova                                  |
| bootable                       | true                                  |
| consistencygroup_id            | None                                  |
| created_at                     | 2022-03-21T15:44:44.000000            |
| description                    | root disk for rh8.3 vm                |
| encrypted                      | False                                 |
| id                             | 3a2aab97-d49d-431c-824d-5fbdcac40fa3  |
| migration_status               | None                                  |
| multiattach                    | False                                 |
| name                           | rhel83-str-root                       |
| os-vol-host-attr:host          | stack2.xxxx at lvm#lvm    |
| os-vol-mig-status-attr:migstat | None                                  |
| os-vol-mig-status-attr:name_id | None                                  |
| os-vol-tenant-attr:tenant_id   | 1ab386267c2b4c969d551ea763c906dc      |
| properties                     |                                       |
| replication_status             | None                                  |
| size                           | 80                                    |
| snapshot_id                    | None                                  |
| source_volid                   | None                                  |
| status                         | reserved                              |
| type                           | iscsi                                 |
| updated_at                     | 2022-03-21T19:20:20.000000            |
| user_id                        | a676762eea994d08a7ce018c3ccbb0b8      |
+--------------------------------+---------------------------------------+

-- 
Alan Davis
Principal System Administrator
Apogee Research LLC
Office : 571.384.8941 x26
Cell : 410.701.0518
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220321/b9e773b9/attachment.htm>

From gmann at ghanshyammann.com  Mon Mar 21 20:40:12 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 21 Mar 2022 15:40:12 -0500
Subject: [all][tc] Technical Committee next weekly meeting on Mar 24th at
 1500 UTC
Message-ID: <17fae3571a9.1138fb707593239.4265001476272661884@ghanshyammann.com>

Hello Everyone,

Technical Committee's next weekly meeting is scheduled for Mar 24th at 1500 UTC.

If you would like to add topics for discussion, please add them to the below wiki page by
Wednesday, Mar 23rd, at 2100 UTC.

https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

-gmann


From kennelson11 at gmail.com  Mon Mar 21 21:51:33 2022
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Mon, 21 Mar 2022 16:51:33 -0500
Subject: Forum Submissions Open for Berlin Summit 2022!
Message-ID: <CAJ6yrQgc+1a0+t4fWfBy+4dZ_Re7rK8zgQM+yVFENTwQXp60Qw@mail.gmail.com>

Hello Everyone!

We are now accepting Forum [1] submissions for the 2022 Open Infrastructure
Summit Forum [2].  Please submit your ideas through the Summit CFP tool [3]
through April 8th.  Don't forget to put your brainstorming etherpad up on
the Berlin Forum page [4].

This is not a classic conference track with speakers and presentations.
OpenInfra community members (participants in development teams, operators,
working groups, SIGs, and other interested individuals) discuss the topics
they want to cover and get alignment on and we welcome your participation.
The Forum is your opportunity to help shape the development of future
project releases. More information about the Forum [1].

The timeline for submissions is as follows:

March 21st | Formal topic submission tool opens: https://cfp.openstack.org.
April 8th | Deadline for proposing Forum topics. Scheduling committee
meeting to make draft agenda.
April 15th | Draft Forum schedule published. Crowd sourced session conflict
detection. Forum promotion begins.
April 22nd | Forum schedule final
June 20th | Forum begins!

If you have questions or concerns, please reach out to
speakersupport at openinfra.dev.

Cheers,
- Kendall Nelson (diablo_rojo)

[1] https://wiki.openstack.org/wiki/Forum
[2] https://openinfra.dev/summit
[3] https://cfp.openstack.org
[4] https://wiki.openstack.org/wiki/Forum/Berlin2022
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220321/d9655ec9/attachment.htm>

From kennelson11 at gmail.com  Mon Mar 21 22:02:59 2022
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Mon, 21 Mar 2022 17:02:59 -0500
Subject: Forum Submissions Open for Berlin Summit 2022!
In-Reply-To: <CAJ6yrQgc+1a0+t4fWfBy+4dZ_Re7rK8zgQM+yVFENTwQXp60Qw@mail.gmail.com>
References: <CAJ6yrQgc+1a0+t4fWfBy+4dZ_Re7rK8zgQM+yVFENTwQXp60Qw@mail.gmail.com>
Message-ID: <CAJ6yrQi1TO_fJKZ=-NO0-exrWqRyJ2vHJ2Ci5ecvH3W6w9PTAQ@mail.gmail.com>

Correction :) Because... Mondays

The Forum starts June 7th!

Sorry for any confusion!

-Kendall

On Mon, Mar 21, 2022 at 4:51 PM Kendall Nelson <kennelson11 at gmail.com>
wrote:

> Hello Everyone!
>
> We are now accepting Forum [1] submissions for the 2022 Open
> Infrastructure Summit Forum [2].  Please submit your ideas through the
> Summit CFP tool [3] through April 8th.  Don't forget to put your
> brainstorming etherpad up on the Berlin Forum page [4].
>
> This is not a classic conference track with speakers and presentations.
> OpenInfra community members (participants in development teams, operators,
> working groups, SIGs, and other interested individuals) discuss the topics
> they want to cover and get alignment on and we welcome your participation.
> The Forum is your opportunity to help shape the development of future
> project releases. More information about the Forum [1].
>
> The timeline for submissions is as follows:
>
> March 21st | Formal topic submission tool opens: https://cfp.openstack.org
> .
> April 8th | Deadline for proposing Forum topics. Scheduling committee
> meeting to make draft agenda.
> April 15th | Draft Forum schedule published. Crowd sourced session
> conflict detection. Forum promotion begins.
> April 22nd | Forum schedule final
> June 20th | Forum begins!
>
> If you have questions or concerns, please reach out to
> speakersupport at openinfra.dev.
>
> Cheers,
> - Kendall Nelson (diablo_rojo)
>
> [1] https://wiki.openstack.org/wiki/Forum
> [2] https://openinfra.dev/summit
> [3] https://cfp.openstack.org
> [4] https://wiki.openstack.org/wiki/Forum/Berlin2022
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220321/3a585a84/attachment-0001.htm>

From stephenfin at redhat.com  Tue Mar 22 11:40:46 2022
From: stephenfin at redhat.com (Stephen Finucane)
Date: Tue, 22 Mar 2022 11:40:46 +0000
Subject: [qa] Retire os-testr
Message-ID: <d667b34c9d02230bef8eac319d47d1b4176aba92.camel@redhat.com>

Hey,

I think it's time we retired os-testr. It is already effectively unmaintained
and we made a concerted effort some cycles ago to migrate all projects to
stestr. I think it's time we finally closed that out. For any projects still
using os-testr, stestr effectively provides a drop-in replacement.

I'll propose patches to do this shortly. Please let me know if anyone has any
concerns about this course of action.

Cheers,
Stephen



From stephenfin at redhat.com  Tue Mar 22 11:45:00 2022
From: stephenfin at redhat.com (Stephen Finucane)
Date: Tue, 22 Mar 2022 11:45:00 +0000
Subject: [qa] Retire os-testr
In-Reply-To: <d667b34c9d02230bef8eac319d47d1b4176aba92.camel@redhat.com>
References: <d667b34c9d02230bef8eac319d47d1b4176aba92.camel@redhat.com>
Message-ID: <62048141c613e734e6fa4192177d10cb823689c7.camel@redhat.com>

On Tue, 2022-03-22 at 11:40 +0000, Stephen Finucane wrote:
> Hey,
> 
> I think it's time we retired os-testr. It is already effectively unmaintained
> and we made a concerted effort some cycles ago to migrate all projects to
> stestr. I think it's time we finally closed that out. For any projects still
> using os-testr, stestr effectively provides a drop-in replacement.
> 
> I'll propose patches to do this shortly. Please let me know if anyone has any
> concerns about this course of action.

Patches are here:

 * https://review.opendev.org/c/openstack/project-config/+/834658
 * https://review.opendev.org/c/openstack/os-testr/+/834659
 * https://review.opendev.org/c/openstack/project-config/+/834660

Stephen

> 
> Cheers,
> Stephen



From mtreinish at kortar.org  Tue Mar 22 11:57:51 2022
From: mtreinish at kortar.org (Matthew Treinish)
Date: Tue, 22 Mar 2022 07:57:51 -0400
Subject: [qa] Retire os-testr
In-Reply-To: <d667b34c9d02230bef8eac319d47d1b4176aba92.camel@redhat.com>
References: <d667b34c9d02230bef8eac319d47d1b4176aba92.camel@redhat.com>
Message-ID: <Yjm5v1P4BWEl7xGT@neo-zeong.kortar.org>

On Tue, Mar 22, 2022 at 11:40:46AM +0000, Stephen Finucane wrote:
> Hey,
> 
> I think it's time we retired os-testr. It is already effectively unmaintained
> and we made a concerted effort some cycles ago to migrate all projects to
> stestr. I think it's time we finally closed that out. For any projects still
> using os-testr, stestr effectively provides a drop-in replacement.
> 
> I'll propose patches to do this shortly. Please let me know if anyone has any
> concerns about this course of action.

Well the reason we didn't retire it after everything migrated to stestr was that
the repo contained other utilities for working with subunit streams. Primarily,
the subunit2html and generate-subunit utilities. I'm not sure if they're still being
used anywhere, but at least historically subunit2html was used to generate the
interactive web view of the test results and was run at the end of every job. The
generate-subunit tool was used by at least devstack to have build failures show up
in the test results stream (this was primarily in support of reporting it to
subunit2sql which I know has recently shut down so it might not be needed anymore).

I personally don't really have any strong feelings on whether to retire the repo or
not, but at least the last time we discussed it we kept the repo around for those
other utilities.

- Matt Treinish
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220322/ded68d5e/attachment.sig>

From smooney at redhat.com  Tue Mar 22 12:11:27 2022
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 22 Mar 2022 12:11:27 +0000
Subject: [nova][scheduler] DiskFilter return 0 when launching
 pre-allocated disk volume
In-Reply-To: <CADjfRFtBQXec2tA+jdKEaCb6TJVxnr22wiF4A55jakFPb05BEw@mail.gmail.com>
References: <CADjfRFtBQXec2tA+jdKEaCb6TJVxnr22wiF4A55jakFPb05BEw@mail.gmail.com>
Message-ID: <8001b14b32b2e764772e30ad5f109b4bd79a3d14.camel@redhat.com>

On Mon, 2022-03-21 at 15:31 -0400, Alan Davis wrote:
> All,
> 
>  I'm having a problem with launching a volume that already exists. I'm not
> finding any indication why DiskFilter is saying there's not enough disk
> space available.
what release of nova are you using.
the disk filter has been deprecated for a number of years and removed in recent releases in favor
of counting disk in placement.

> This is not a new system, it's been in use for over a year and has more
> than 20 VM's running on it already. Creating a volume (either from image or
> from install iso) is my normal way of creating instances, so this isn't
> anything I haven't done many times.

instnaces that are booted form a volume shoudl have a flavor that requests 0 root gb
if you use a flavor that request root gb the disk filter will still 
> 
> Any ideas on why or what debugging steps I can take would be appreciated.
> 
> Here's the error from nova-scheduler.log
> 
> 2022-03-21 15:20:22.021 16602 INFO nova.filters
> [req-f8909a62-723d-4128-9e68-2fe445fa861d a676762eea994d08a7ce018c3ccbb0b8
> 1ab386267c2b4c969d551ea763c906dc - default default] Filtering removed all
> hosts for the request with instance ID
> '59dfe21d-c527-4fd7-ad50-39c144af93fc'. Filter results: ['RetryFilter:
> (start: 1, end: 1)', 'AvailabilityZoneFilter: (start: 1, end: 1)',
> 'RamFilter: (start: 1, end: 1)', 'DiskFilter: (start: 1, end: 0)']
the retry filter ram filter and disk filter are not required in any release that has placment
so if you are using ~pike or later you do not need them enabled. placment will have already valdiated ram and disk
capasity and the retry filter is repleace with a set of alternate hosts that are selected when the vm is initally schduled.
> 
> vgs (yes, i know... LVM) shows plenty of space, as well
> 
>  VG             #PV #LV #SN Attr   VSize  VFree
>   centos_stack2    1   3   0 wz--n- 74.00g     0
>   cinder-volumes   1  51   1 wz--n- <9.10t <3.64t
> 
> openstack says:
> +--------------------------------+---------------------------------------+
> > Field                          | Value                                 |
> +--------------------------------+---------------------------------------+
> > attachments                    | []                                    |
> > availability_zone              | nova                                  |
> > bootable                       | true                                  |
> > consistencygroup_id            | None                                  |
> > created_at                     | 2022-03-21T15:44:44.000000            |
> > description                    | root disk for rh8.3 vm                |
> > encrypted                      | False                                 |
> > id                             | 3a2aab97-d49d-431c-824d-5fbdcac40fa3  |
> > migration_status               | None                                  |
> > multiattach                    | False                                 |
> > name                           | rhel83-str-root                       |
> > os-vol-host-attr:host          | stack2.xxxx at lvm#lvm    |
> > os-vol-mig-status-attr:migstat | None                                  |
> > os-vol-mig-status-attr:name_id | None                                  |
> > os-vol-tenant-attr:tenant_id   | 1ab386267c2b4c969d551ea763c906dc      |
> > properties                     |                                       |
> > replication_status             | None                                  |
> > size                           | 80                                    |
> > snapshot_id                    | None                                  |
> > source_volid                   | None                                  |
> > status                         | reserved                              |
> > type                           | iscsi                                 |
> > updated_at                     | 2022-03-21T19:20:20.000000            |
> > user_id                        | a676762eea994d08a7ce018c3ccbb0b8      |
> +--------------------------------+---------------------------------------+
> 



From smooney at redhat.com  Tue Mar 22 12:18:03 2022
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 22 Mar 2022 12:18:03 +0000
Subject: [qa] Retire os-testr
In-Reply-To: <Yjm5v1P4BWEl7xGT@neo-zeong.kortar.org>
References: <d667b34c9d02230bef8eac319d47d1b4176aba92.camel@redhat.com>
 <Yjm5v1P4BWEl7xGT@neo-zeong.kortar.org>
Message-ID: <aaf810c03070c2f4f140eadb56584363c8e22d95.camel@redhat.com>

On Tue, 2022-03-22 at 07:57 -0400, Matthew Treinish wrote:
> On Tue, Mar 22, 2022 at 11:40:46AM +0000, Stephen Finucane wrote:
> > Hey,
> > 
> > I think it's time we retired os-testr. It is already effectively unmaintained
> > and we made a concerted effort some cycles ago to migrate all projects to
> > stestr. I think it's time we finally closed that out. For any projects still
> > using os-testr, stestr effectively provides a drop-in replacement.
> > 
> > I'll propose patches to do this shortly. Please let me know if anyone has any
> > concerns about this course of action.
> 
> Well the reason we didn't retire it after everything migrated to stestr was that
> the repo contained other utilities for working with subunit streams. Primarily,
> the subunit2html and generate-subunit utilities. I'm not sure if they're still being
> used anywhere, but at least historically subunit2html was used to generate the
> interactive web view of the test results and was run at the end of every job. The
> generate-subunit tool was used by at least devstack to have build failures show up
> in the test results stream (this was primarily in support of reporting it to
> subunit2sql which I know has recently shut down so it might not be needed anymore).
> 
> I personally don't really have any strong feelings on whether to retire the repo or
> not, but at least the last time we discussed it we kept the repo around for those
> other utilities.
i feel like migrating those utilities to there own repo perhaps zuul-jobs would make more sense
if they are in fact still used by zuul to generate the html report.
> 
> - Matt Treinish



From ltoscano at redhat.com  Tue Mar 22 13:09:49 2022
From: ltoscano at redhat.com (Luigi Toscano)
Date: Tue, 22 Mar 2022 14:09:49 +0100
Subject: [qa] Retire os-testr
In-Reply-To: <aaf810c03070c2f4f140eadb56584363c8e22d95.camel@redhat.com>
References: <d667b34c9d02230bef8eac319d47d1b4176aba92.camel@redhat.com>
 <Yjm5v1P4BWEl7xGT@neo-zeong.kortar.org>
 <aaf810c03070c2f4f140eadb56584363c8e22d95.camel@redhat.com>
Message-ID: <3416399.dWV9SEqChM@whitebase.usersys.redhat.com>

On Tuesday, 22 March 2022 13:18:03 CET Sean Mooney wrote:
> On Tue, 2022-03-22 at 07:57 -0400, Matthew Treinish wrote:
> > On Tue, Mar 22, 2022 at 11:40:46AM +0000, Stephen Finucane wrote:
> > > Hey,
> > > 
> > > I think it's time we retired os-testr. It is already effectively
> > > unmaintained and we made a concerted effort some cycles ago to migrate
> > > all projects to stestr. I think it's time we finally closed that out.
> > > For any projects still using os-testr, stestr effectively provides a
> > > drop-in replacement.
> > > 
> > > I'll propose patches to do this shortly. Please let me know if anyone
> > > has any concerns about this course of action.
> > 
> > Well the reason we didn't retire it after everything migrated to stestr
> > was that the repo contained other utilities for working with subunit
> > streams. Primarily, the subunit2html and generate-subunit utilities. I'm
> > not sure if they're still being used anywhere, but at least historically
> > subunit2html was used to generate the interactive web view of the test
> > results and was run at the end of every job. The generate-subunit tool
> > was used by at least devstack to have build failures show up in the test
> > results stream (this was primarily in support of reporting it to
> > subunit2sql which I know has recently shut down so it might not be needed
> > anymore).
> > 
> > I personally don't really have any strong feelings on whether to retire
> > the repo or not, but at least the last time we discussed it we kept the
> > repo around for those other utilities.
> 
> i feel like migrating those utilities to there own repo perhaps zuul-jobs
> would make more sense if they are in fact still used by zuul to generate
> the html report.

Agreed, it would be nice to have at least subunit2html around somewhere.


-- 
Luigi




From gmann at ghanshyammann.com  Tue Mar 22 14:12:47 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Tue, 22 Mar 2022 09:12:47 -0500
Subject: [qa] Retire os-testr
In-Reply-To: <3416399.dWV9SEqChM@whitebase.usersys.redhat.com>
References: <d667b34c9d02230bef8eac319d47d1b4176aba92.camel@redhat.com>
 <Yjm5v1P4BWEl7xGT@neo-zeong.kortar.org>
 <aaf810c03070c2f4f140eadb56584363c8e22d95.camel@redhat.com>
 <3416399.dWV9SEqChM@whitebase.usersys.redhat.com>
Message-ID: <17fb1f91ead.cabc3330647451.1195633804487171276@ghanshyammann.com>

 ---- On Tue, 22 Mar 2022 08:09:49 -0500 Luigi Toscano <ltoscano at redhat.com> wrote ----
 > On Tuesday, 22 March 2022 13:18:03 CET Sean Mooney wrote:
 > > On Tue, 2022-03-22 at 07:57 -0400, Matthew Treinish wrote:
 > > > On Tue, Mar 22, 2022 at 11:40:46AM +0000, Stephen Finucane wrote:
 > > > > Hey,
 > > > > 
 > > > > I think it's time we retired os-testr. It is already effectively
 > > > > unmaintained and we made a concerted effort some cycles ago to migrate
 > > > > all projects to stestr. I think it's time we finally closed that out.
 > > > > For any projects still using os-testr, stestr effectively provides a
 > > > > drop-in replacement.
 > > > > 
 > > > > I'll propose patches to do this shortly. Please let me know if anyone
 > > > > has any concerns about this course of action.
 > > > 
 > > > Well the reason we didn't retire it after everything migrated to stestr
 > > > was that the repo contained other utilities for working with subunit
 > > > streams. Primarily, the subunit2html and generate-subunit utilities. I'm
 > > > not sure if they're still being used anywhere, but at least historically
 > > > subunit2html was used to generate the interactive web view of the test
 > > > results and was run at the end of every job. The generate-subunit tool
 > > > was used by at least devstack to have build failures show up in the test
 > > > results stream (this was primarily in support of reporting it to
 > > > subunit2sql which I know has recently shut down so it might not be needed
 > > > anymore).
 > > > 
 > > > I personally don't really have any strong feelings on whether to retire
 > > > the repo or not, but at least the last time we discussed it we kept the
 > > > repo around for those other utilities.
 > > 
 > > i feel like migrating those utilities to there own repo perhaps zuul-jobs
 > > would make more sense if they are in fact still used by zuul to generate
 > > the html report.
 > 
 > Agreed, it would be nice to have at least subunit2html around somewhere.

We can move but we need to check overall benefits of moving them as users has
to use the new location. 

I am not sure why it is considered as not maintained. is it failing in code or gate? In QA, we keep trying
to have them running always. This is not just os-testr but other small stable projects under QA.

I do not have strong opinion on retiring it until we really need to do and it is very costly
to maintain which is not as per the current situation.

-gmann

 > 
 > 
 > -- 
 > Luigi
 > 
 > 
 > 
 > 


From mihalis68 at gmail.com  Tue Mar 22 14:42:47 2022
From: mihalis68 at gmail.com (Chris Morgan)
Date: Tue, 22 Mar 2022 10:42:47 -0400
Subject: [ops] ops meetups team meeting 2022-3-22
Message-ID: <CA+NmNoM9Y61yx9A_p7h36cz0mvbATs0sjzFc7qnVVkYAu3UzRw@mail.gmail.com>

The OpenStack Ops Meetups team met on IRC in preparation for a 1-day ops
meetup in berlin alongside the summit. Meeting minutes below, next meeting
in two weeks time at 13:00 UTC

<opendevmeet> Opendev IRC Services Meeting ended Tue Mar 22 14:40:47 2022
UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
10:40 AM Minutes:
https://meetings.opendev.org/meetings/ops_meetup_team/2022/ops_meetup_team.2022-03-22-14.04.html
10:40 AM Minutes (text):
https://meetings.opendev.org/meetings/ops_meetup_team/2022/ops_meetup_team.2022-03-22-14.04.txt
10:40 AM Log:
https://meetings.opendev.org/meetings/ops_meetup_team/2022/ops_meetup_team.2022-03-22-14.04.log.html

-- 
Chris Morgan <mihalis68 at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220322/6b16071c/attachment-0001.htm>

From marios at redhat.com  Tue Mar 22 15:06:56 2022
From: marios at redhat.com (Marios Andreou)
Date: Tue, 22 Mar 2022 17:06:56 +0200
Subject: [TripleO] Move tripleo repos stable/ussuri to End Of Life OK?
In-Reply-To: <CAD0_RgHnDvod-caDs-zmnTcnWK=0Vp2FSRycfYuU6s9bFBJOfg@mail.gmail.com>
References: <CAM51kHXZnhsUgCYkQekLs10jFH874xCWtOpEFgsv5PboNTgVuA@mail.gmail.com>
 <CAD0_RgHMOTYPKtM4qHbGdrQYrEh7j5ptiqZupa2LDRbTkAPgiQ@mail.gmail.com>
 <CAM51kHVmqCH-RF-oUL4bFYwKMUh9ttEtuBewG8iqZQOxnVQRDQ@mail.gmail.com>
 <CAD0_RgHnDvod-caDs-zmnTcnWK=0Vp2FSRycfYuU6s9bFBJOfg@mail.gmail.com>
Message-ID: <CAM51kHXWz9MzC=Uzy1PYYAwDR=UndPGW9jkr22isaHpODnP8ng@mail.gmail.com>

On Fri, Mar 18, 2022 at 5:40 PM Jiri Podivin <jpodivin at redhat.com> wrote:

> I suppose the corresponding rdo distgit branches will follow suit?
> Once again most of the open reviews[6] are backports.
>
> [6]https://review.rdoproject.org/r/q/branch:ussuri-rdo+status:open
>
>
well those won't be removed as part of
https://review.opendev.org/c/openstack/releases/+/834049 - that will only
remove the source code branches.
However indeed the rdo team will likely want to remove the corresponding
distgit for each of the tripleo repos being eol for ussuri after we move
forward.

At this point I think we'll probably hold on this until ptg which is just
under 2 weeks away but I haven't heard any pushback against this proposal
so far,

marios



> On Fri, Mar 18, 2022 at 4:35 PM Marios Andreou <marios at redhat.com> wrote:
>
>>
>>
>> On Thu, Mar 17, 2022 at 9:20 AM Jiri Podivin <jpodivin at redhat.com> wrote:
>>
>>> Hi,
>>> As far as Tripleo-Validations repo[5] is concerned I don't believe we
>>> should see any issues.
>>> For the most part we are treating the stable/ussuri branch as a
>>> necessary, but not very meaningful, step when backporting changes to
>>> stable/train.
>>>
>>> [5]https://review.opendev.org/admin/repos/openstack/tripleo-validations
>>>
>>>
>> thanks for confirming Jirka
>>
>> so assuming we go ahead with this we will at some point need to close all
>> open reviews against stable ussuri - there aren't too many as we would
>> expect (just things being backported - validations has 3 currently). For
>> convenience, links for all the repos:
>>
>>
>>
>> https://review.opendev.org/q/project:openstack%252Fos-apply-config+status:open+branch:stable/ussuri
>>
>> https://review.opendev.org/q/project:openstack%252Fos-collect-config+status:open+branch:stable/ussuri
>>
>> https://review.opendev.org/q/project:openstack%252Fos-net-config+status:open+branch:stable/ussuri
>>
>> https://review.opendev.org/q/project:openstack%252Fos-refresh-config+status:open+branch:stable/ussuri
>>
>> https://review.opendev.org/q/project:openstack%252Fpaunch+status:open+branch:stable/ussuri
>>
>> https://review.opendev.org/q/project:openstack%252Fpuppet-tripleo+status:open+branch:stable/ussuri
>>
>> https://review.opendev.org/q/project:openstack%252Fpython-tripleoclient+status:open+branch:stable/ussuri
>>
>> https://review.opendev.org/q/project:openstack%252Ftripleo-ansible+status:open+branch:stable/ussuri
>>
>> https://review.opendev.org/q/project:openstack%252Ftripleo-common+status:open+branch:stable/ussuri
>>
>> https://review.opendev.org/q/project:openstack%252Ftripleo-heat-templates+status:open+branch:stable/ussuri
>>
>> https://review.opendev.org/q/project:openstack%252Ftripleo-image-elements+status:open+branch:stable/ussuri
>>
>> https://review.opendev.org/q/project:openstack%252Ftripleo-ipsec+status:open+branch:stable/ussuri
>>
>> https://review.opendev.org/q/project:openstack%252Ftripleo-puppet-elements+status:open+branch:stable/ussuri
>>
>> https://review.opendev.org/q/project:openstack%252Ftripleo-validations+status:open+branch:stable/ussuri
>>
>>
>> I'll bring this up again in #tripleo next week and see if there are any
>> objections, otherwise we can call it and start getting folks to close out
>> those open reviews and stop posting new ones,
>>
>> thanks, marios
>>
>>
>>
>>
>>> On Wed, Mar 16, 2022 at 5:45 PM Marios Andreou <marios at redhat.com>
>>> wrote:
>>>
>>>> Hello TripleO o/
>>>>
>>>> The tripleo-ci team proposes that we move the stable/ussuri branch for
>>>> all tripleo repos [1] to End of Life [2].
>>>>
>>>> The branch was moved to extended maintenance with [3] so we can already
>>>> no longer make any new releases for ussuri/tripleo repos.
>>>>
>>>> Are there any objections or concerns about this? If so please speak up
>>>> here or directly on the patch. I think that any patches posted to ussuri
>>>> nowadays are mainly about cherrypicking back to train, rather than merging
>>>> something to ussuri specifically.
>>>>
>>>> I have posted the proposal to move to EOL at [4] and have WF-1 to wait
>>>> for this discussion.
>>>>
>>>> If there are no objections then once we move to EOL the tripleo-ci team
>>>> will remove all Ussuri related CI, check/gate/promotions.
>>>>
>>>> regards, marios
>>>>
>>>> [1] https://releases.openstack.org/teams/tripleo.html#ussuri
>>>> [2]
>>>> https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
>>>> [3] https://review.opendev.org/c/openstack/releases/+/817623
>>>> [4] https://review.opendev.org/c/openstack/releases/+/834049
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220322/57d6f3fa/attachment.htm>

From a.yeremko at connectria.com  Tue Mar 22 18:11:45 2022
From: a.yeremko at connectria.com (Alexander Yeremko)
Date: Tue, 22 Mar 2022 18:11:45 +0000
Subject: question on plain text config parameters encryption feature
Message-ID: <DS7PR03MB54939B446AD009F77E7B725A9C179@DS7PR03MB5493.namprd03.prod.outlook.com>

Dear OpenStack community,

we are developing plain text config secrets encryption feature according to the next specification:

https://specs.openstack.org/openstack/openstack-ansible-specs/specs/xena/protecting-plaintext-configs.html

We started from Glance OS service and submitted two patchsets already:

https://review.opendev.org/c/openstack/openstack-ansible-os_glance/+/814865

Now we have two questions that we need to clarify to proceed our work on that feature and finish our development:

1. Is it correct that we need to develop more patchsets to rework some logic of encryption mechanism according
to comment to 'files/encypt_secrets.py' script that arised at the second patchset (PatchSet 2) dated Nov/30/2021 ?
Comment is by Dmitry Rabotyagov: "We _really_ should make it as an ansible plugin and re-work logic"

2. We wish to have such feature in previous releases also, not just in upcoming Yoga or Zed.
Stein, Train and Victoria - it would be excellent to have plain text secrets encryption with these releases also.
So question is how is it possible to use our feature in those releases also? Can we push some backports to those releases openstack-ansible repo?

Best regards and wishes,
Alex Yeremko
This E-Mail (including any attachments) may contain privileged or confidential information. It is intended only for the addressee(s) indicated above. The sender does not waive any of its rights, privileges or other protections respecting this information. Any distribution, copying or other use of this E-Mail or the information it contains, by other than an intended recipient, is not sanctioned and is prohibited. If you received this E-Mail in error, please delete it and advise the sender (by return E-Mail or otherwise) immediately. Any calls held by you with Connectria may be recorded by an automated note taking system to ensure prompt follow up and for information collection purposes, and your attendance on any calls with Connectria confirms your consent to this. Any E-mail received by or sent from Connectria is subject to review by Connectria supervisory personnel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220322/c32ec0a3/attachment-0001.htm>

From hanguangyu2 at gmail.com  Wed Mar 23 06:49:57 2022
From: hanguangyu2 at gmail.com (=?UTF-8?B?6Z+p5YWJ5a6H?=)
Date: Wed, 23 Mar 2022 14:49:57 +0800
Subject: [devstack][ubuntu20.04 focal] Failed to fetch after apt-get install
Message-ID: <CAOirdiWrpibEutpEPOO9pV8WomrW=RWEHb_wu-f9-RtuN6zEog@mail.gmail.com>

Hi all,

I used devstack to deploy OpenStack with ironic in Ubuntu20.4. But I always got
```
Err:1 http://nova.clouds.archive.ubuntu.com/ubuntu focal/universe
amd64 exfat-fuse amd64 1.3.0-1
  Connection failed [IP: 91.189.88.245 80]
Err:2 http://nova.clouds.archive.ubuntu.com/ubuntu focal/universe
amd64 libf2fs5 amd64 1.11.0-1.1ubuntu1
  Connection failed [IP: 91.189.91.121 80]
Err:3 http://nova.clouds.archive.ubuntu.com/ubuntu focal/universe
amd64 libf2fs-format4 amd64 1.11.0-1.1ubuntu1
  Connection failed [IP: 91.189.88.245 80]
Err:4 http://nova.clouds.archive.ubuntu.com/ubuntu focal/universe
amd64 f2fs-tools amd64 1.11.0-1.1ubuntu1
  Connection failed [IP: 91.189.91.121 80]
Err:5 http://nova.clouds.archive.ubuntu.com/ubuntu focal-updates/main
amd64 fonts-noto-mono all 20200323-1build1~ubuntu20.04.1
  Connection failed [IP: 91.189.88.245 80]
Err:6 http://nova.clouds.archive.ubuntu.com/ubuntu focal/main amd64
fonts-urw-base35 all 20170801.1-3
  Connection failed [IP: 91.189.91.121 80]
Err:7 http://nova.clouds.archive.ubuntu.com/ubuntu focal/main amd64
libxi6 amd64 2:1.7.10-0ubuntu1
  Connection failed [IP: 91.189.88.245 80]
Err:8 http://nova.clouds.archive.ubuntu.com/ubuntu focal/main amd64
libxinerama1 amd64 2:1.1.4-2
  Connection failed [IP: 91.189.91.121 80]
E: Failed to fetch
http://nova.clouds.archive.ubuntu.com/ubuntu/pool/universe/f/fuse-exfat/exfat-fuse_1.3.0-1_amd64.deb
 Connection failed [IP: 91.189.88.245 80]
E: Failed to fetch
http://nova.clouds.archive.ubuntu.com/ubuntu/pool/universe/f/f2fs-tools/libf2fs5_1.11.0-1.1ubuntu1_amd64.deb
 Connection failed [IP: 91.189.91.121 80]
E: Failed to fetch
http://nova.clouds.archive.ubuntu.com/ubuntu/pool/universe/f/f2fs-tools/libf2fs-format4_1.11.0-1.1ubuntu1_amd64.deb
 Connection failed [IP: 91.189.88.245 80]
E: Failed to fetch
http://nova.clouds.archive.ubuntu.com/ubuntu/pool/universe/f/f2fs-tools/f2fs-tools_1.11.0-1.1ubuntu1_amd64.deb
 Connection failed [IP: 91.189.91.121 80]
E: Failed to fetch
http://nova.clouds.archive.ubuntu.com/ubuntu/pool/main/f/fonts-noto/fonts-noto-mono_20200323-1build1~ubuntu20.04.1_all.deb
 Connection failed [IP: 91.189.88.245 80]
E: Failed to fetch
http://nova.clouds.archive.ubuntu.com/ubuntu/pool/main/f/fonts-urw-base35/fonts-urw-base35_20170801.1-3_all.deb
 Connection failed [IP: 91.189.91.121 80]
E: Failed to fetch
http://nova.clouds.archive.ubuntu.com/ubuntu/pool/main/libx/libxi/libxi6_1.7.10-0ubuntu1_amd64.deb
 Connection failed [IP: 91.189.88.245 80]
E: Failed to fetch
http://nova.clouds.archive.ubuntu.com/ubuntu/pool/main/libx/libxinerama/libxinerama1_1.1.4-2_amd64.deb
 Connection failed [IP: 91.189.91.121 80]
E: Unable to fetch some archives, maybe run apt-get update or try with
--fix-missing?
```

This is my local.conf:
https://paste.opendev.org/show/bsJYZ7fcLSlAxZkr5fsV/
This is my /etc/apt/sources.list:
https://paste.opendev.org/show/bRAlj2UoeqNv6U7dVdwG/
I have added /etc/resolv.conf:
```
nameserver 127.0.0.53
options edns0 trust-ad
search openstacklocal
nameserver 114.114.114.114
nameserver 8.8.8.8
nameserver 223.5.5.5
nameserver 223.6.6.6
```
$ sudo apt-get update
Hit:1 http://nova.clouds.archive.ubuntu.com/ubuntu focal InRelease
Hit:2 http://security.ubuntu.com/ubuntu focal-security InRelease
Hit:3 http://nova.clouds.archive.ubuntu.com/ubuntu focal-updates InRelease
Hit:4 http://nova.clouds.archive.ubuntu.com/ubuntu focal-backports InRelease
Reading package lists... Done
$ sudo apt-get update --fix-missing
Hit:1 http://nova.clouds.archive.ubuntu.com/ubuntu focal InRelease
Hit:2 http://security.ubuntu.com/ubuntu focal-security InRelease
Hit:3 http://nova.clouds.archive.ubuntu.com/ubuntu focal-updates InRelease
Hit:4 http://nova.clouds.archive.ubuntu.com/ubuntu focal-backports InRelease
Reading package lists... Done

But still got error.
I know this is  a apt install error, But I always can't resolve it. Do
you konw how can I resolve this?

I will very appreciate any help and advice.

HanGuangyu


From hanguangyu2 at gmail.com  Wed Mar 23 07:35:50 2022
From: hanguangyu2 at gmail.com (=?UTF-8?B?6Z+p5YWJ5a6H?=)
Date: Wed, 23 Mar 2022 15:35:50 +0800
Subject: [nova]Can I modify the xml of openstac instance by 'virsh edit'
Message-ID: <CAOirdiWCfHcwNjYfXjBVa0uk59ucsiLEzciXW8U0oRYY1T7A2A@mail.gmail.com>

Hello,

I have a All-in-One OpenStack Victoria. And I want to bind vCPU of
openstack instance(guest) to pCPU of host.
# virsh edit instance-00000107
origin:
```
...
  <vcpu placement='static'>8</vcpu>
  <cputune>
    <shares>8192</shares>
  </cputune>
...
```

after modify:
```
  <vcpu placement='static' cpuset='104-111'>8</vcpu>
  <cputune>
    <shares>8192</shares>
   <vcpupin vcpu='0' cpuset='104'/>
   <vcpupin vcpu='1' cpuset='105'/>
   <vcpupin vcpu='2' cpuset='106'/>
   <vcpupin vcpu='3' cpuset='107'/>
   <vcpupin vcpu='4' cpuset='108'/>
   <vcpupin vcpu='5' cpuset='109'/>
   <vcpupin vcpu='6' cpuset='110'/>
   <vcpupin vcpu='7' cpuset='111'/>
   <emulatorpin cpuset='104-111'/>
  </cputune>
```
But If I stop and start instance by openstack command, xml
automatically recover.
And If I user `virsh shutdown instance-00000107 && virsh start
instance-00000107`, instance can't be start(I don't konw if the
openstack instance must be started using openstack command).

So:
1. Can I modify the xml of openstac instance by 'virsh edit'?
2. If I can't modify the xml, how can I bind vcpu of guest and pcpu of host

I would appreciate any kind of guidance or help.

HanGuangyu


From arne.wiebalck at cern.ch  Wed Mar 23 07:53:31 2022
From: arne.wiebalck at cern.ch (Arne Wiebalck)
Date: Wed, 23 Mar 2022 08:53:31 +0100
Subject: [nova]Can I modify the xml of openstac instance by 'virsh edit'
In-Reply-To: <CAOirdiWCfHcwNjYfXjBVa0uk59ucsiLEzciXW8U0oRYY1T7A2A@mail.gmail.com>
References: <CAOirdiWCfHcwNjYfXjBVa0uk59ucsiLEzciXW8U0oRYY1T7A2A@mail.gmail.com>
Message-ID: <e0da2cf7-2fb9-a74e-0704-d2a78985c733@cern.ch>

HanGuangyu,

For testing, e.g. to see if your workloads are sensitive to pinning,
you should be able to use 'virsh vcpupin ...' to pin vCPUs to pCPUs.

To configure pinning in your deployment, the CPU topology docs for
Victoria should help:

https://docs.openstack.org/nova/victoria/admin/cpu-topologies.html

 From our experience (and our workloads), pinning to a NUMA node gives
the same performance as pinning to individual pCPUs and is therefore
good enough.

Hope this helps, cheers,
  Arne


On 23.03.22 08:35, ??? wrote:
> Hello,
> 
> I have a All-in-One OpenStack Victoria. And I want to bind vCPU of
> openstack instance(guest) to pCPU of host.
> # virsh edit instance-00000107
> origin:
> ```
> ...
>    <vcpu placement='static'>8</vcpu>
>    <cputune>
>      <shares>8192</shares>
>    </cputune>
> ...
> ```
> 
> after modify:
> ```
>    <vcpu placement='static' cpuset='104-111'>8</vcpu>
>    <cputune>
>      <shares>8192</shares>
>     <vcpupin vcpu='0' cpuset='104'/>
>     <vcpupin vcpu='1' cpuset='105'/>
>     <vcpupin vcpu='2' cpuset='106'/>
>     <vcpupin vcpu='3' cpuset='107'/>
>     <vcpupin vcpu='4' cpuset='108'/>
>     <vcpupin vcpu='5' cpuset='109'/>
>     <vcpupin vcpu='6' cpuset='110'/>
>     <vcpupin vcpu='7' cpuset='111'/>
>     <emulatorpin cpuset='104-111'/>
>    </cputune>
> ```
> But If I stop and start instance by openstack command, xml
> automatically recover.
> And If I user `virsh shutdown instance-00000107 && virsh start
> instance-00000107`, instance can't be start(I don't konw if the
> openstack instance must be started using openstack command).
> 
> So:
> 1. Can I modify the xml of openstac instance by 'virsh edit'?
> 2. If I can't modify the xml, how can I bind vcpu of guest and pcpu of host
> 
> I would appreciate any kind of guidance or help.
> 
> HanGuangyu
> 


From elfosardo at gmail.com  Wed Mar 23 08:50:47 2022
From: elfosardo at gmail.com (Riccardo Pittau)
Date: Wed, 23 Mar 2022 09:50:47 +0100
Subject: [ironic] Moving weekly meeting time
In-Reply-To: <CAORRS==7RoGwr+kLU6C2CmQLLxcxDJgYhWm2rj0PMzNcgXqrDQ@mail.gmail.com>
References: <CAORRS==7RoGwr+kLU6C2CmQLLxcxDJgYhWm2rj0PMzNcgXqrDQ@mail.gmail.com>
Message-ID: <CAORRS=knaGHDdig5n2OEAKn455D0+UU1ptGtCBRRJko4ekNH9Q@mail.gmail.com>

Hello ironicers!

Since no objections were raised in the past 10 days, the weekly ironic
meeting will be moved at 15:00 UTC starting Monday March 28th.

Thanks!

Ciao
Riccardo

On Tue, Mar 8, 2022 at 5:01 PM Riccardo Pittau <elfosardo at gmail.com> wrote:

> Hello ironicers!
>
> We're close to time change, again (Sunday March 13th for US, and Sunday
> March 27th for EU).
>
> For this reason, if there are no objections, we'd like to move the weekly
> ironic Monday meeting one hour earlier starting Monday March 28th.
>
> Thanks!
>
> Ciao
> Riccardo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220323/0e45d3f0/attachment.htm>

From senrique at redhat.com  Wed Mar 23 11:57:54 2022
From: senrique at redhat.com (Sofia Enriquez)
Date: Wed, 23 Mar 2022 08:57:54 -0300
Subject: [cinder] Bug deputy report for week of 03-23-2022
Message-ID: <CANtmtpGN=qjQXnTA00xroszXh3uFD8qP-E5t50fAti-=i82yUQ@mail.gmail.com>

This is a bug report from 03-09-2022 to 03-23-2022.
Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting
-----------------------------------------------------------------------------------------
Medium

   - https://bugs.launchpad.net/cinder/+bug/1964396 "Volume left in
   detaching status." Unassigned.
   - https://bugs.launchpad.net/cinder/+bug/1965847 "Attempt to import
   duplicate backup record deletes existing record." Confirmed.


   - NVMe-oF:


   - https://bugs.launchpad.net/os-brick/+bug/1965954 "NVMe-oF: Extend
      replicated for in-use doesn't grow the raid." Unassigned.
      - https://bugs.launchpad.net/os-brick/+bug/1964590 "NVMe-oF: Extend
      in-use volume not working." Unassigned.
      - https://bugs.launchpad.net/os-brick/+bug/1964395 "NVMe-oF: Does not
      properly wait for a block device." Unassigned.
      - https://bugs.launchpad.net/os-brick/+bug/1964389 "NVMe-oF: Shows
      misleading traceback." Unassigned.
      - https://bugs.launchpad.net/os-brick/+bug/1964388 "NVMe-oF: Connects
      wrong volume to instance." Unassigned.
      - https://bugs.launchpad.net/os-brick/+bug/1964385 "NVMe-oF: Devices
      disappearing from the host." Unassigned.
      - https://bugs.launchpad.net/os-brick/+bug/1964388 "NVMe-oF: Connects
      wrong volume to instance." Unassigned.
      - https://bugs.launchpad.net/os-brick/+bug/1964383 "NVMe-oF: Only
      connects to the first volume." Unassigned.
      - https://bugs.launchpad.net/os-brick/+bug/1964380 "NVMe-oF: Does not
      work if driver shares the subsystem." Unassigned.
      - https://bugs.launchpad.net/os-brick/+bug/1964379 "Encryption broken
      for the nvmeof connector." Unassigned.

Low

   - https://bugs.launchpad.net/cinder/+bug/1965799 "Cinder gets out of
   memory at json.dumps when doing a backup of a large volume." Fix proposed
   to master.
   - https://bugs.launchpad.net/cinder/+bug/1964394 "LVM nvmet: Exporting
   volume creates kernel messages." Unassigned.
   - https://bugs.launchpad.net/cinder/+bug/1964391 "LVM nvmet: Disconnects
   all volumes on map/unmap." Unassigned.

Incomplete

   - https://bugs.launchpad.net/cinder/+bug/1965952 "Netapp copyoffload
   provider location None." Unassigned.

Cheers


-- 

Sof?a Enriquez

she/her

Software Engineer

Red Hat PnT <https://www.redhat.com>

IRC: @enriquetaso
@RedHat <https://twitter.com/redhat>   Red Hat
<https://www.linkedin.com/company/red-hat>  Red Hat
<https://www.facebook.com/RedHatInc>
<https://www.redhat.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220323/cdd250ce/attachment-0001.htm>

From senrique at redhat.com  Wed Mar 23 12:00:22 2022
From: senrique at redhat.com (Sofia Enriquez)
Date: Wed, 23 Mar 2022 09:00:22 -0300
Subject: [cinder] Bug deputy report for week of 03-23-2022
In-Reply-To: <CANtmtpGN=qjQXnTA00xroszXh3uFD8qP-E5t50fAti-=i82yUQ@mail.gmail.com>
References: <CANtmtpGN=qjQXnTA00xroszXh3uFD8qP-E5t50fAti-=i82yUQ@mail.gmail.com>
Message-ID: <CANtmtpFsBfBFgFNa=WVSjROX5GZnesniNLzQc8eBGX8k8OusMA@mail.gmail.com>

Low

   - https://bugs.launchpad.net/cinder/+bug/1965952 "Netapp copyoffload
   provider location None." Fix proposed to master.


On Wed, Mar 23, 2022 at 8:57 AM Sofia Enriquez <senrique at redhat.com> wrote:

> This is a bug report from 03-09-2022 to 03-23-2022.
> Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting
>
> -----------------------------------------------------------------------------------------
> Medium
>
>    - https://bugs.launchpad.net/cinder/+bug/1964396 "Volume left in
>    detaching status." Unassigned.
>    - https://bugs.launchpad.net/cinder/+bug/1965847 "Attempt to import
>    duplicate backup record deletes existing record." Confirmed.
>
>
>    - NVMe-oF:
>
>
>    - https://bugs.launchpad.net/os-brick/+bug/1965954 "NVMe-oF: Extend
>       replicated for in-use doesn't grow the raid." Unassigned.
>       - https://bugs.launchpad.net/os-brick/+bug/1964590 "NVMe-oF: Extend
>       in-use volume not working." Unassigned.
>       - https://bugs.launchpad.net/os-brick/+bug/1964395 "NVMe-oF: Does
>       not properly wait for a block device." Unassigned.
>       - https://bugs.launchpad.net/os-brick/+bug/1964389 "NVMe-oF: Shows
>       misleading traceback." Unassigned.
>       - https://bugs.launchpad.net/os-brick/+bug/1964388 "NVMe-oF:
>       Connects wrong volume to instance." Unassigned.
>       - https://bugs.launchpad.net/os-brick/+bug/1964385 "NVMe-oF:
>       Devices disappearing from the host." Unassigned.
>       - https://bugs.launchpad.net/os-brick/+bug/1964388 "NVMe-oF:
>       Connects wrong volume to instance." Unassigned.
>       - https://bugs.launchpad.net/os-brick/+bug/1964383 "NVMe-oF: Only
>       connects to the first volume." Unassigned.
>       - https://bugs.launchpad.net/os-brick/+bug/1964380 "NVMe-oF: Does
>       not work if driver shares the subsystem." Unassigned.
>       - https://bugs.launchpad.net/os-brick/+bug/1964379 "Encryption
>       broken for the nvmeof connector." Unassigned.
>
> Low
>
>    - https://bugs.launchpad.net/cinder/+bug/1965799 "Cinder gets out of
>    memory at json.dumps when doing a backup of a large volume." Fix proposed
>    to master.
>    - https://bugs.launchpad.net/cinder/+bug/1964394 "LVM nvmet: Exporting
>    volume creates kernel messages." Unassigned.
>    - https://bugs.launchpad.net/cinder/+bug/1964391 "LVM nvmet:
>    Disconnects all volumes on map/unmap." Unassigned.
>
> Incomplete
>
>    - https://bugs.launchpad.net/cinder/+bug/1965952 "Netapp copyoffload
>    provider location None." Unassigned.
>
> Cheers
>
>
> --
>
> Sof?a Enriquez
>
> she/her
>
> Software Engineer
>
> Red Hat PnT <https://www.redhat.com>
>
> IRC: @enriquetaso
> @RedHat <https://twitter.com/redhat>   Red Hat
> <https://www.linkedin.com/company/red-hat>  Red Hat
> <https://www.facebook.com/RedHatInc>
> <https://www.redhat.com>
>
>

-- 

Sof?a Enriquez

she/her

Software Engineer

Red Hat PnT <https://www.redhat.com>

IRC: @enriquetaso
@RedHat <https://twitter.com/redhat>   Red Hat
<https://www.linkedin.com/company/red-hat>  Red Hat
<https://www.facebook.com/RedHatInc>
<https://www.redhat.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220323/21a20cde/attachment.htm>

From anyrude10 at gmail.com  Wed Mar 23 09:15:56 2022
From: anyrude10 at gmail.com (Anirudh Gupta)
Date: Wed, 23 Mar 2022 14:45:56 +0530
Subject: [TripleO] Offline Installation Support
In-Reply-To: <CAJm6b-54VnWRY19PPZxy6XfFQQMuSgYh1Czuso9z6ayMwXdACQ@mail.gmail.com>
References: <CAKxkTi0zKnjKLF5sBQ0TdCbymhCQnvuj-=jCJh6PS4asgmzD+w@mail.gmail.com>
 <5ff25e47-1a0d-6b42-2f49-336ba68ffba9@redhat.com>
 <CAJm6b-54VnWRY19PPZxy6XfFQQMuSgYh1Czuso9z6ayMwXdACQ@mail.gmail.com>
Message-ID: <CAKxkTi06DycBER29GRHMs0OKe523-6GJZnKf=1XXSdU3ogD38w@mail.gmail.com>

Hi Harald,

Thanks for sharing the steps and apologies for the late reply.

I tried setting up Local Repo Server and Registry Server on one machine.
Using that I successfully deployed Openstack Ussuri Undercloud and
Overcloud in an offline mode.

Now, in order to test Upgrade from USSURI to VICTORIA, I updated the repo
file and podman registry at my local server for Victoria.
On Undercloud , repo file content is as follows:

[tripleo]
baseurl = http://30.30.30.8/software/repos/tripleo_victoria
enabled = 1
gpgcheck = 0
module_hotfixes=1
name = tripleo

where 30.30.30.8 is the IP of my reposerver.

With this I have successfully updated the required packages using the
command:
*sudo yum update python*-tripleoclient openstack-tripleo-common
openstack-tripleo-heat-templates*

Also the container image prepare file, now has the following content
parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
      name_prefix: openstack-
      name_suffix: ''
      namespace: myserver.com:5000/tripleovictoria
      neutron_driver: ovn
      rhel_containers: false
      tag: current-tripleo
    tag_from_label: rdo_version


But once I run the command "*openstack undercloud upgrade*", I get the
following error
2022-03-23 09:53:24,527 p=380392 u=root n=ansible | 2022-03-23
09:53:24.527073 | 5254007b-2040-558f-a68f-0000000000ac |      FATAL |
Ensure DNF modules have the right stream | undercloud | item={'module':
'container-tools', 'stream': '3.0'} | error={
    "ansible_loop_var": "item",
    "changed": false,
    "invocation": {
        "module_args": {
            "allow_downgrade": false,
            "autoremove": false,
            "bugfix": false,
            "conf_file": null,
            "disable_excludes": null,
            "disable_gpg_check": false,
            "disable_plugin": [],
            "disablerepo": [],
            "download_dir": null,
            "download_only": false,
            "enable_plugin": [],
            "enablerepo": [],
            "exclude": [],
            "install_repoquery": true,
            "install_weak_deps": true,
            "installroot": "/",
            "list": null,
            "lock_timeout": 30,
            "name": [
                "@container-tools:3.0/common"
            ],
            "releasever": null,
            "security": false,
            "skip_broken": false,
            "state": "present",
            "update_cache": false,
            "update_only": false,
            "validate_certs": true
        }
    },
    "item": {
        "module": "container-tools",
        "stream": "3.0"
    },
    "msg": "*No group container-tools:3.0/common available*.",
    "results": []
}

Can you please help in resolving this issue.

Regards
Anirudh Gupta


On Wed, Mar 23, 2022 at 2:06 PM Lokendra Rathour <lokendrarathour at gmail.com>
wrote:

>
>
> ---------- Forwarded message ---------
> From: Harald Jensas <hjensas at redhat.com>
> Date: Wed, Feb 23, 2022 at 9:57 PM
> Subject: Re: [TripleO] Offline Installation Support
> To: <openstack-discuss at lists.openstack.org>
>
>
> On 2/16/22 13:58, Anirudh Gupta wrote:
> > Hi Team,
> >
> > We have successfully done POC on deploying my TripleO Train HA Setup
> > with Baremetal Provisioning on Overcloud Node as well.
> >
> > We would like to thank Tripleo community members for helping us and
> > resolving all our concerns at all times.
> >
> > Moving forward, we need to deploy the setup on the Lab environment for
> > which I need some support as well.
> >
> > We don't have internet in Lab machines, all that we have is access to a
> > central server (staging) which has internet access and we can download
> > all the requirements over there.
> >
> > Queries:
> >
> >   * Is there any feasible method to install Undercloud and Overcloud
> >     Machines in complete offline mode?
> >   * If yes, then
> >
> >      1. What are the steps to download all related stuff on the staging
> >         server?
>
> I don't know the exact steps, and I am not aware of upstream
> documentation page explaining this.
>
> You will probalby want to use the 'rsync' tool to sync RDO RPM
> repositories and create a local repo on you staging machine. Sync
> packages, use `createrepo` tool to generate yum/dnf repo metadata. Then
> set up a webserver to make the repository available over HTTP. Search
> the internets for "Create local RPM repository / mirror", there are many
> generic guides that will help you.
>
>
> For containers you need to set up a local container registry. Then I
> would suggest useing the `skopeo`[1] tool to sync containers from the
> public registry to your local registry.
>
> >      2. What modifications would be required in undercloud/overcloud and
> >         other configuration files to support this?
> >
>
> You need to set up the undercloud to use the RPM repositries on the
> staging server. Put config in /etc/yum.repos.d/*.repo files. Once the
> overcloud is deployed you would want to add the repo config there as well.
>
> You need to use a custom containers-prepare file when deploying the
> undercloud and overcloud, you must set the namespaces to point to your
> local registry. Something like this:
>
> parameter_defaults:
>    ContainerImagePrepare:
>    - push_destination: false
>      set:
>        name_prefix: openstack-
>        name_suffix: ''
>        namespace: staging.example.com:5000/tripleotrain
>        neutron_driver: null
>        tag: current-tripleo
>        ...
>
> I would suggest generating the container prepare env file with the
> `openstack tripleo container image prepare` command[2] and then edit the
> generated file.
>
>
> [1] https://github.com/containers/skopeo
> [2]
>
> https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/container_image_prepare.html
>
>
>
>
> --
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220323/174ab0ca/attachment-0001.htm>

From smooney at redhat.com  Wed Mar 23 12:30:19 2022
From: smooney at redhat.com (Sean Mooney)
Date: Wed, 23 Mar 2022 12:30:19 +0000
Subject: [nova]Can I modify the xml of openstac instance by 'virsh edit'
In-Reply-To: <e0da2cf7-2fb9-a74e-0704-d2a78985c733@cern.ch>
References: <CAOirdiWCfHcwNjYfXjBVa0uk59ucsiLEzciXW8U0oRYY1T7A2A@mail.gmail.com>
 <e0da2cf7-2fb9-a74e-0704-d2a78985c733@cern.ch>
Message-ID: <3ce1a40a11bfa1738e68ac1ba42df58efb507f07.camel@redhat.com>

On Wed, 2022-03-23 at 08:53 +0100, Arne Wiebalck wrote:
> HanGuangyu,
> 
> For testing, e.g. to see if your workloads are sensitive to pinning,
> you should be able to use 'virsh vcpupin ...' to pin vCPUs to pCPUs.
> 
> To configure pinning in your deployment, the CPU topology docs for
> Victoria should help:
> 
> https://docs.openstack.org/nova/victoria/admin/cpu-topologies.html

openstakc support virtual cpu toplogies and cpu pinning but they are two different things
that doc does cover both. 
https://docs.openstack.org/nova/victoria/admin/cpu-topologies.html#customizing-instance-cpu-pinning-policies
is the releve section for pinning which is normally enable via the  hw:cpu_policy=dedicated flavaor extra spec but
can also be enabeld using  hw_cpu_policy=dedicated image property.
> 
>  From our experience (and our workloads), pinning to a NUMA node gives
> the same performance as pinning to individual pCPUs and is therefore
> good enough.
> 
for the most part yes but you need to ensure you set hw:mem_page_size to enable numa aware memory tracking
setting hw:numa_nodes is not sufficent for correct memory accounting.
> Hope this helps, cheers,
>   Arne
> 
> 
> On 23.03.22 08:35, ??? wrote:
> > Hello,
> > 
> > I have a All-in-One OpenStack Victoria. And I want to bind vCPU of
> > openstack instance(guest) to pCPU of host.
> > # virsh edit instance-00000107
> > origin:
> > ```
> > ...
> >    <vcpu placement='static'>8</vcpu>
> >    <cputune>
> >      <shares>8192</shares>
> >    </cputune>
> > ...
> > ```
> > 
> > after modify:
> > ```
> >    <vcpu placement='static' cpuset='104-111'>8</vcpu>
> >    <cputune>
> >      <shares>8192</shares>
> >     <vcpupin vcpu='0' cpuset='104'/>
> >     <vcpupin vcpu='1' cpuset='105'/>
> >     <vcpupin vcpu='2' cpuset='106'/>
> >     <vcpupin vcpu='3' cpuset='107'/>
> >     <vcpupin vcpu='4' cpuset='108'/>
> >     <vcpupin vcpu='5' cpuset='109'/>
> >     <vcpupin vcpu='6' cpuset='110'/>
> >     <vcpupin vcpu='7' cpuset='111'/>
> >     <emulatorpin cpuset='104-111'/>
> >    </cputune>
> > ```
> > But If I stop and start instance by openstack command, xml
> > automatically recover.
> > And If I user `virsh shutdown instance-00000107 && virsh start
> > instance-00000107`, instance can't be start(I don't konw if the
> > openstack instance must be started using openstack command).
> > 
> > So:
> > 1. Can I modify the xml of openstac instance by 'virsh edit'?
no that is not supported. the xmls are regenerated by nova after many operations so
change you make directly will not persist and it will potentially break nova so its unsupported.
> > 2. If I can't modify the xml, how can I bind vcpu of guest and pcpu of host
as noted above we support requesting cpu pinning using flavor extra specs and image propperties.
depending on the release you are usign there are some other feature such as the ablity to have some pinned and some unbinidn cores
in the same vm.

on thing to keep in mind is we do not support mixing vms with a numa toplogy and vms without a numa toplogy.
so that means that you have to enabel numa aware memofy trackign for all vms on a host if you are using cpu pinning.

that generally means grouping host for numa workloads and non numa workloads using host aggreates and configuring fileters to isolate them


> > 
> > I would appreciate any kind of guidance or help.
> > 
> > HanGuangyu
> > 
> 



From amoralej at redhat.com  Wed Mar 23 14:19:32 2022
From: amoralej at redhat.com (Alfredo Moralejo Alonso)
Date: Wed, 23 Mar 2022 15:19:32 +0100
Subject: [tripleo][RDO] Tags for Yoga GA version in tripleo projects
Message-ID: <CACrbaxinP2E=5C95pndGJD1aUWWH2+YJmVucnnwCExZsYd6O6g@mail.gmail.com>

Hi,

As we are doing builds for RDO Yoga release, I'd like to know what we
should include in yoga release. In Xena, tags were created with the commits
for the most recent promotion at around GA and shipped rpm packages for
them. Additionally, we pinned RDO Trunk Xena to those versions. Will we get
similar tags for Yoga?

Best regards,

Alfredo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220323/0cf2191a/attachment.htm>

From geguileo at redhat.com  Wed Mar 23 15:24:35 2022
From: geguileo at redhat.com (Gorka Eguileor)
Date: Wed, 23 Mar 2022 16:24:35 +0100
Subject: [cinder] Bug deputy report for week of 03-23-2022
In-Reply-To: <CANtmtpGN=qjQXnTA00xroszXh3uFD8qP-E5t50fAti-=i82yUQ@mail.gmail.com>
References: <CANtmtpGN=qjQXnTA00xroszXh3uFD8qP-E5t50fAti-=i82yUQ@mail.gmail.com>
Message-ID: <20220323152435.64jbzdsyymfwno4p@localhost>

On 23/03, Sofia Enriquez wrote:
> This is a bug report from 03-09-2022 to 03-23-2022.
> Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting
> -----------------------------------------------------------------------------------------
> Medium
>
>    - https://bugs.launchpad.net/cinder/+bug/1964396 "Volume left in
>    detaching status." Unassigned.
>    - https://bugs.launchpad.net/cinder/+bug/1965847 "Attempt to import
>    duplicate backup record deletes existing record." Confirmed.
>
>
>    - NVMe-oF:
>
>
>    - https://bugs.launchpad.net/os-brick/+bug/1965954 "NVMe-oF: Extend
>       replicated for in-use doesn't grow the raid." Unassigned.
>       - https://bugs.launchpad.net/os-brick/+bug/1964590 "NVMe-oF: Extend
>       in-use volume not working." Unassigned.
>       - https://bugs.launchpad.net/os-brick/+bug/1964395 "NVMe-oF: Does not
>       properly wait for a block device." Unassigned.
>       - https://bugs.launchpad.net/os-brick/+bug/1964389 "NVMe-oF: Shows
>       misleading traceback." Unassigned.
>       - https://bugs.launchpad.net/os-brick/+bug/1964388 "NVMe-oF: Connects
>       wrong volume to instance." Unassigned.
>       - https://bugs.launchpad.net/os-brick/+bug/1964385 "NVMe-oF: Devices
>       disappearing from the host." Unassigned.
>       - https://bugs.launchpad.net/os-brick/+bug/1964388 "NVMe-oF: Connects
>       wrong volume to instance." Unassigned.
>       - https://bugs.launchpad.net/os-brick/+bug/1964383 "NVMe-oF: Only
>       connects to the first volume." Unassigned.
>       - https://bugs.launchpad.net/os-brick/+bug/1964380 "NVMe-oF: Does not
>       work if driver shares the subsystem." Unassigned.
>       - https://bugs.launchpad.net/os-brick/+bug/1964379 "Encryption broken
>       for the nvmeof connector." Unassigned.

Hi,

I think there's a mistake, because all the os-brick NVMe-oF bugs are
assigned to me, and I already have an almost complete set of patches to
fix them.  ;-)


>
> Low
>
>    - https://bugs.launchpad.net/cinder/+bug/1965799 "Cinder gets out of
>    memory at json.dumps when doing a backup of a large volume." Fix proposed
>    to master.
>    - https://bugs.launchpad.net/cinder/+bug/1964394 "LVM nvmet: Exporting
>    volume creates kernel messages." Unassigned.
>    - https://bugs.launchpad.net/cinder/+bug/1964391 "LVM nvmet: Disconnects
>    all volumes on map/unmap." Unassigned.

Something similar happens with these 2 LVM nvmet bugs, though I still
have to write the unit tests for these ones.

Cheers,
Gorka.


>
> Incomplete
>
>    - https://bugs.launchpad.net/cinder/+bug/1965952 "Netapp copyoffload
>    provider location None." Unassigned.
>
> Cheers
>
>
> --
>
> Sof?a Enriquez
>
> she/her
>
> Software Engineer
>
> Red Hat PnT <https://www.redhat.com>
>
> IRC: @enriquetaso
> @RedHat <https://twitter.com/redhat>   Red Hat
> <https://www.linkedin.com/company/red-hat>  Red Hat
> <https://www.facebook.com/RedHatInc>
> <https://www.redhat.com>



From mnasiadka at gmail.com  Wed Mar 23 15:37:50 2022
From: mnasiadka at gmail.com (=?utf-8?Q?Micha=C5=82_Nasiadka?=)
Date: Wed, 23 Mar 2022 16:37:50 +0100
Subject: [kolla] Proposing frickler for Kolla and Kolla-Ansible core
In-Reply-To: <CAFHSqWqXQN0x+cwObHGMuTpYVB3Xu-mQwARaZcqjY2G1UfOfmg@mail.gmail.com>
References: <23DC7FD6-25DE-45D3-A000-E2049B8F1D91@gmail.com>
 <a438b6a7-2fe6-a455-2d1c-0d6b47cfa549@linaro.org>
 <CAFHSqWqXQN0x+cwObHGMuTpYVB3Xu-mQwARaZcqjY2G1UfOfmg@mail.gmail.com>
Message-ID: <AB830A02-28CE-488A-90E6-D83299800724@gmail.com>

Hello,

Thanks for positive feedback - let?s welcome Jens as a core reviewer.

Best regards,
Michal

> On 16 Mar 2022, at 17:59, Mark Goddard <mark at stackhpc.com> wrote:
> 
> +2
> 
> On Wed, 16 Mar 2022 at 16:23, Marcin Juszkiewicz
> <marcin.juszkiewicz at linaro.org> wrote:
>> 
>> W dniu 16.03.2022 o 13:36, Micha? Nasiadka pisze:
>>> Hello,
>>> 
>>> Jens has been working on Kolla and Kolla-Ansible for some time already
>> 
>>> I?d like to propose him for Kolla and Kolla-Ansible core reviewer.
>> 
>> +2
>> 
> 



From radoslaw.piliszek at gmail.com  Wed Mar 23 15:51:49 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Wed, 23 Mar 2022 16:51:49 +0100
Subject: [kolla] Proposing frickler for Kolla and Kolla-Ansible core
In-Reply-To: <AB830A02-28CE-488A-90E6-D83299800724@gmail.com>
References: <23DC7FD6-25DE-45D3-A000-E2049B8F1D91@gmail.com>
 <a438b6a7-2fe6-a455-2d1c-0d6b47cfa549@linaro.org>
 <CAFHSqWqXQN0x+cwObHGMuTpYVB3Xu-mQwARaZcqjY2G1UfOfmg@mail.gmail.com>
 <AB830A02-28CE-488A-90E6-D83299800724@gmail.com>
Message-ID: <CAKZ_x7-yn51ObtNT_x1wTC8J6HVGg4m-sHd2gaxk4hyaxJMbsA@mail.gmail.com>

Welcome, welcome! :-)

-yoctozepto

On Wed, 23 Mar 2022 at 16:38, Micha? Nasiadka <mnasiadka at gmail.com> wrote:
>
> Hello,
>
> Thanks for positive feedback - let?s welcome Jens as a core reviewer.
>
> Best regards,
> Michal
>
> > On 16 Mar 2022, at 17:59, Mark Goddard <mark at stackhpc.com> wrote:
> >
> > +2
> >
> > On Wed, 16 Mar 2022 at 16:23, Marcin Juszkiewicz
> > <marcin.juszkiewicz at linaro.org> wrote:
> >>
> >> W dniu 16.03.2022 o 13:36, Micha? Nasiadka pisze:
> >>> Hello,
> >>>
> >>> Jens has been working on Kolla and Kolla-Ansible for some time already
> >>
> >>> I?d like to propose him for Kolla and Kolla-Ansible core reviewer.
> >>
> >> +2
> >>
> >
>
>


From tjoen at dds.nl  Wed Mar 23 18:03:35 2022
From: tjoen at dds.nl (tjoen)
Date: Wed, 23 Mar 2022 19:03:35 +0100
Subject: [devstack][ubuntu20.04 focal] Failed to fetch after apt-get
 install
In-Reply-To: <CAOirdiWrpibEutpEPOO9pV8WomrW=RWEHb_wu-f9-RtuN6zEog@mail.gmail.com>
References: <CAOirdiWrpibEutpEPOO9pV8WomrW=RWEHb_wu-f9-RtuN6zEog@mail.gmail.com>
Message-ID: <00d2876d-83d1-a910-b1bc-c0b622e477b1@dds.nl>

On 3/23/22 07:49, ??? wrote:
..
>    Connection failed [IP: 91.189.88.245 80]

I can ping it

...
> But still got error.
> I know this is  a apt install error, But I always can't resolve it. Do
> you konw how can I resolve this?

Problem Canonical not openstack


From senrique at redhat.com  Wed Mar 23 23:17:33 2022
From: senrique at redhat.com (Sofia Enriquez)
Date: Wed, 23 Mar 2022 20:17:33 -0300
Subject: [cinder] Bug deputy report for week of 03-23-2022
In-Reply-To: <20220323152435.64jbzdsyymfwno4p@localhost>
References: <CANtmtpGN=qjQXnTA00xroszXh3uFD8qP-E5t50fAti-=i82yUQ@mail.gmail.com>
 <20220323152435.64jbzdsyymfwno4p@localhost>
Message-ID: <CANtmtpH+WhrB2QjYor_m553JRWXYtd5jxhNKCrkOES3gYm85VA@mail.gmail.com>

Right! My fault, sorry :P

On Wed, Mar 23, 2022 at 12:25 PM Gorka Eguileor <geguileo at redhat.com> wrote:

> On 23/03, Sofia Enriquez wrote:
> > This is a bug report from 03-09-2022 to 03-23-2022.
> > Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting
> >
> -----------------------------------------------------------------------------------------
> > Medium
> >
> >    - https://bugs.launchpad.net/cinder/+bug/1964396 "Volume left in
> >    detaching status." Unassigned.
> >    - https://bugs.launchpad.net/cinder/+bug/1965847 "Attempt to import
> >    duplicate backup record deletes existing record." Confirmed.
> >
> >
> >    - NVMe-oF:
> >
> >
> >    - https://bugs.launchpad.net/os-brick/+bug/1965954 "NVMe-oF: Extend
> >       replicated for in-use doesn't grow the raid." Unassigned.
> >       - https://bugs.launchpad.net/os-brick/+bug/1964590 "NVMe-oF:
> Extend
> >       in-use volume not working." Unassigned.
> >       - https://bugs.launchpad.net/os-brick/+bug/1964395 "NVMe-oF: Does
> not
> >       properly wait for a block device." Unassigned.
> >       - https://bugs.launchpad.net/os-brick/+bug/1964389 "NVMe-oF: Shows
> >       misleading traceback." Unassigned.
> >       - https://bugs.launchpad.net/os-brick/+bug/1964388 "NVMe-oF:
> Connects
> >       wrong volume to instance." Unassigned.
> >       - https://bugs.launchpad.net/os-brick/+bug/1964385 "NVMe-oF:
> Devices
> >       disappearing from the host." Unassigned.
> >       - https://bugs.launchpad.net/os-brick/+bug/1964388 "NVMe-oF:
> Connects
> >       wrong volume to instance." Unassigned.
> >       - https://bugs.launchpad.net/os-brick/+bug/1964383 "NVMe-oF: Only
> >       connects to the first volume." Unassigned.
> >       - https://bugs.launchpad.net/os-brick/+bug/1964380 "NVMe-oF: Does
> not
> >       work if driver shares the subsystem." Unassigned.
> >       - https://bugs.launchpad.net/os-brick/+bug/1964379 "Encryption
> broken
> >       for the nvmeof connector." Unassigned.
>
> Hi,
>
> I think there's a mistake, because all the os-brick NVMe-oF bugs are
> assigned to me, and I already have an almost complete set of patches to
> fix them.  ;-)
>
>
> >
> > Low
> >
> >    - https://bugs.launchpad.net/cinder/+bug/1965799 "Cinder gets out of
> >    memory at json.dumps when doing a backup of a large volume." Fix
> proposed
> >    to master.
> >    - https://bugs.launchpad.net/cinder/+bug/1964394 "LVM nvmet:
> Exporting
> >    volume creates kernel messages." Unassigned.
> >    - https://bugs.launchpad.net/cinder/+bug/1964391 "LVM nvmet:
> Disconnects
> >    all volumes on map/unmap." Unassigned.
>
> Something similar happens with these 2 LVM nvmet bugs, though I still
> have to write the unit tests for these ones.
>
> Cheers,
> Gorka.
>
>
> >
> > Incomplete
> >
> >    - https://bugs.launchpad.net/cinder/+bug/1965952 "Netapp copyoffload
> >    provider location None." Unassigned.
> >
> > Cheers
> >
> >
> > --
> >
> > Sof?a Enriquez
> >
> > she/her
> >
> > Software Engineer
> >
> > Red Hat PnT <https://www.redhat.com>
> >
> > IRC: @enriquetaso
> > @RedHat <https://twitter.com/redhat>   Red Hat
> > <https://www.linkedin.com/company/red-hat>  Red Hat
> > <https://www.facebook.com/RedHatInc>
> > <https://www.redhat.com>
>
>

-- 

Sof?a Enriquez

she/her

Software Engineer

Red Hat PnT <https://www.redhat.com>

IRC: @enriquetaso
@RedHat <https://twitter.com/redhat>   Red Hat
<https://www.linkedin.com/company/red-hat>  Red Hat
<https://www.facebook.com/RedHatInc>
<https://www.redhat.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220323/3a13aae4/attachment.htm>

From gmann at ghanshyammann.com  Thu Mar 24 03:34:50 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 23 Mar 2022 22:34:50 -0500
Subject: [all][tc] Technical Committee next weekly meeting on Mar 24th
 at 1500 UTC
In-Reply-To: <17fae3571a9.1138fb707593239.4265001476272661884@ghanshyammann.com>
References: <17fae3571a9.1138fb707593239.4265001476272661884@ghanshyammann.com>
Message-ID: <17fb9fdc47b.101adc2a6750642.6388793699491996452@ghanshyammann.com>

Hello Everyone,

Below is the agenda for Tomorrow's TC IRC meeting schedule at 1500 UTC.

https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

== Agenda for tomorrow's TC meeting ==

* Roll call

* Follow up on past action items

* Gate health check
** Fixing Zuul config error in OpenStack
*** https://etherpad.opendev.org/p/zuul-config-error-openstack

* PTG Preparation
** http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027381.html
** https://etherpad.opendev.org/p/tc-zed-ptg
** TC + Community Leaders Interaction
*** http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027382.html

* Open Reviews
** https://review.opendev.org/q/projects:openstack/governance+is:open

-gmann


 ---- On Mon, 21 Mar 2022 15:40:12 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > Hello Everyone,
 > 
 > Technical Committee's next weekly meeting is scheduled for Mar 24th at 1500 UTC.
 > 
 > If you would like to add topics for discussion, please add them to the below wiki page by
 > Wednesday, Mar 23rd, at 2100 UTC.
 > 
 > https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting
 > 
 > -gmann
 > 
 > 


From marios at redhat.com  Thu Mar 24 06:23:12 2022
From: marios at redhat.com (Marios Andreou)
Date: Thu, 24 Mar 2022 08:23:12 +0200
Subject: [tripleo][RDO] Tags for Yoga GA version in tripleo projects
In-Reply-To: <CACrbaxinP2E=5C95pndGJD1aUWWH2+YJmVucnnwCExZsYd6O6g@mail.gmail.com>
References: <CACrbaxinP2E=5C95pndGJD1aUWWH2+YJmVucnnwCExZsYd6O6g@mail.gmail.com>
Message-ID: <CAM51kHXm0VHtzkjXS6pVr=KMeKi6gqUHyum+Wn1Am81rH+g_PQ@mail.gmail.com>

On Wed, Mar 23, 2022 at 4:24 PM Alfredo Moralejo Alonso <amoralej at redhat.com>
wrote:

> Hi,
>
> As we are doing builds for RDO Yoga release, I'd like to know what we
> should include in yoga release. In Xena, tags were created with the commits
> for the most recent promotion at around GA and shipped rpm packages for
> them. Additionally, we pinned RDO Trunk Xena to those versions. Will we get
> similar tags for Yoga?
>
>
Hi Alfredo - I think it's a fair request and I guess by replying here I am
also volunteering to do that ;)

I can prepare a release just after PTG (that is usually about the time we
would cut the new branch and make the release) is that OK for you? I am
guessing you'll be blocking the release for this? Or possibly can you
release without tripleo then release those afterwards if you don't want to
block?

Assuming slagle or anyone else doesn't have any objections to that of
course

regards, marios




> Best regards,
>
> Alfredo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220324/de3cb1df/attachment.htm>

From dsneddon at redhat.com  Thu Mar 24 06:47:43 2022
From: dsneddon at redhat.com (Dan Sneddon)
Date: Wed, 23 Mar 2022 23:47:43 -0700
Subject: [TripleO] Core team cleanup
In-Reply-To: <CAHV77z8=qME7dnaZz0Pa7rO_ag+D9ERjZmEDyBjA4cWSkY1k8w@mail.gmail.com>
References: <CAHV77z8=qME7dnaZz0Pa7rO_ag+D9ERjZmEDyBjA4cWSkY1k8w@mail.gmail.com>
Message-ID: <222496ea-c194-6c2b-3383-a6ffd05321d9@redhat.com>

I had moved on from doing TripleO reviews and was focusing on other
things, so I didn't mind losing my TripleO core status when this email
went out. However I am once again focusing on os-net-config, and I just
realized I have lost my +2/-2 and workflow +1 status on os-net-config.

In order for me to contribute to os-net-config and help to implement the
NetworkManager/nmstate implementation, I may need TripleO core status
again. I would be happy to do regular reviews again in TripleO in order
to maintain that status. Can somebody nominate me for TripleO core status?

Thanks,
-Dan

On 11/3/21 09:52, James Slagle wrote:
> Hello, I took a look at our core team, "tripleo-core" in gerrit. We have
> a few individuals who I feel have moved on from TripleO in their focus.
> I looked at the reviews from stackalytics.io <http://stackalytics.io>
> for the last 180 days[1].
> 
> These individuals have less than 6 reviews, which is about 1 review a month:
> Bob Fournier
> Dan Sneddon
> Dmitry Tantsur
> Ji?? Str?nsk?
> Juan Antonio Osorio Robles
> Marius Cornea
> 
> These individuals have publicly expressed that they are moving on from
> TripleO:
> Michele Baldessari
> wes hayutin
> 
> I'd like to propose we remove these folks from our core team, while
> thanking them for their contributions. I'll also note that I'd still
> value +1/-1 from these folks with a lot of significance, and encourage
> them to review their areas of expertise!
> 
> If anyone on the list plans to start reviewing in TripleO again, then I
> also think we can postpone the removal for the time being and
> re-evaluate later. Please let me know if that's the case.
> 
> Please reply and let me know any agreements or concerns with this change.
> 
> Thank you!
> 
> [1]
> https://www.stackalytics.io/report/contribution?module=tripleo-group&project_type=openstack&days=180
> <https://www.stackalytics.io/report/contribution?module=tripleo-group&project_type=openstack&days=180>
> 
> -- 
> -- James Slagle
> --

-- 
Dan Sneddon         |  Senior Principal Software Engineer
dsneddon at redhat.com |  redhat.com/cloud
dsneddon:irc        |  @dxs:twitter



From marios at redhat.com  Thu Mar 24 08:46:11 2022
From: marios at redhat.com (Marios Andreou)
Date: Thu, 24 Mar 2022 10:46:11 +0200
Subject: [TripleO] Core team cleanup
In-Reply-To: <222496ea-c194-6c2b-3383-a6ffd05321d9@redhat.com>
References: <CAHV77z8=qME7dnaZz0Pa7rO_ag+D9ERjZmEDyBjA4cWSkY1k8w@mail.gmail.com>
 <222496ea-c194-6c2b-3383-a6ffd05321d9@redhat.com>
Message-ID: <CAM51kHWEHHW5KXta_Q9KrkKqBcNBQ6T6GpR4RbD+Gv9ensdtHQ@mail.gmail.com>

On Thu, Mar 24, 2022 at 8:52 AM Dan Sneddon <dsneddon at redhat.com> wrote:

> I had moved on from doing TripleO reviews and was focusing on other
> things, so I didn't mind losing my TripleO core status when this email
> went out. However I am once again focusing on os-net-config, and I just
> realized I have lost my +2/-2 and workflow +1 status on os-net-config.
>
> In order for me to contribute to os-net-config and help to implement the
> NetworkManager/nmstate implementation, I may need TripleO core status
> again. I would be happy to do regular reviews again in TripleO in order
> to maintain that status. Can somebody nominate me for TripleO core status?
>
>
I think you just did ;)

+1 for dsneddon to regain core.

He hasn't been dormant for that long (last review there in November [1] )
and over the last 6 months [2] shows up in the list of reviewers.

My 2c:  Dan imho the review count is a little low - would be great if you
could try to do 1 review/day across tripleo (pick any repo ;)) now that
you're working on os-net-config again. We all need code reviews to keep
things moving and you'll be needing reviews from other tripleo cores again
soon enough for the work you'll be doing,

regards, marios


[1] https://review.opendev.org/c/openstack/os-net-config/+/813838
[2]
https://www.stackalytics.io/report/contribution?module=opendev.org/openstack/os-net-config&project_type=openstack&days=180


> Thanks,
> -Dan
>
> On 11/3/21 09:52, James Slagle wrote:
> > Hello, I took a look at our core team, "tripleo-core" in gerrit. We have
> > a few individuals who I feel have moved on from TripleO in their focus.
> > I looked at the reviews from stackalytics.io <http://stackalytics.io>
> > for the last 180 days[1].
> >
> > These individuals have less than 6 reviews, which is about 1 review a
> month:
> > Bob Fournier
> > Dan Sneddon
> > Dmitry Tantsur
> > Ji?? Str?nsk?
> > Juan Antonio Osorio Robles
> > Marius Cornea
> >
> > These individuals have publicly expressed that they are moving on from
> > TripleO:
> > Michele Baldessari
> > wes hayutin
> >
> > I'd like to propose we remove these folks from our core team, while
> > thanking them for their contributions. I'll also note that I'd still
> > value +1/-1 from these folks with a lot of significance, and encourage
> > them to review their areas of expertise!
> >
> > If anyone on the list plans to start reviewing in TripleO again, then I
> > also think we can postpone the removal for the time being and
> > re-evaluate later. Please let me know if that's the case.
> >
> > Please reply and let me know any agreements or concerns with this change.
> >
> > Thank you!
> >
> > [1]
> >
> https://www.stackalytics.io/report/contribution?module=tripleo-group&project_type=openstack&days=180
> > <
> https://www.stackalytics.io/report/contribution?module=tripleo-group&project_type=openstack&days=180
> >
> >
> > --
> > -- James Slagle
> > --
>
> --
> Dan Sneddon         |  Senior Principal Software Engineer
> dsneddon at redhat.com |  redhat.com/cloud
> dsneddon:irc        |  @dxs:twitter
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220324/0d053d6d/attachment.htm>

From mnasiadka at gmail.com  Thu Mar 24 09:49:18 2022
From: mnasiadka at gmail.com (=?utf-8?Q?Micha=C5=82_Nasiadka?=)
Date: Thu, 24 Mar 2022 10:49:18 +0100
Subject: [kolla] Moving weekly meeting time
Message-ID: <797C69C8-DF37-4003-B46A-8C38129C8BE5@gmail.com>

Hello Koalas!

As agreed on the weekly meeting yesterday - we?re moving the weekly Kolla Wednesday meeting one hour earlier starting next week (March 30th).
The reason for this change is daylight savings time change (Sunday March 13th for US, and Sunday March 27th for EU).

https://review.opendev.org/c/opendev/irc-meetings/+/835020

Michal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220324/bf8c81a1/attachment.htm>

From eblock at nde.ag  Thu Mar 24 09:58:10 2022
From: eblock at nde.ag (Eugen Block)
Date: Thu, 24 Mar 2022 09:58:10 +0000
Subject: rabbitmq config changes not applied in newer format
Message-ID: <20220324095810.Horde.M7FDQIhittE5kJ6pIdqj24Y@webmail.nde.ag>

Hi *,

this might not be the right place to ask but I'm curious how others  
configure their rabbitmq.

RabbitMQ version: 3.8.3
OpenStack version: Ussuri/Victoria (two different clusters)

We have a highly available cloud controlled by pacemaker. The  
deployment is based on our own Salt states. We noticed that our config  
is not applied (e. g. after power outage), we need to import those  
manually with 'rabbitmqctl import /path/to/definitions.json'.  
Comparing it to an older cloud version (Rocky, Rabbit version 3.6.16)  
I noticed that the config format is different between those versions,  
the older version uses a json format (?):

---snip---
# old format

cat /etc/rabbitmq/rabbitmq.config
[
  {mnesia,
   [
    {dump_log_write_threshold, 300},
    {dump_log_time_threshold, 180000}
   ]
  },
  {rabbit,
   [
    {collect_statistics_interval, 5000},
    {tcp_listen_options, [
                          {backlog, 128},{nodelay, true},{keepalive, false}
                         ]
    },
    {tcp_listeners, [
                     {"x.x.x.x", 5672}
                    ]},
    {cluster_partition_handling, pause_minority},
    {queue_master_locator, <<"min-masters">>},
    {disk_free_limit, 50000000}
  ]},
  {rabbitmq_management,
   [
    {listener, [{ip, "x.x.x.x"}, {port, 15673}]},
    {load_definitions, "/etc/rabbitmq/definitions.json"}
   ]
  }
].


# new format
[...]
listeners.tcp.default = 5672
listeners.tcp.other_port = 5673
listeners.tcp.other_ip   = x.x.x.x:5672
[...]
---snip---

If I switch to the old format and restart rabbitmq on that node, the  
changes are applied successfully. Is this a known issue? Should I just  
stick to the old format? Any comments are appreciated!

Regards,
Eugen



From stephenfin at redhat.com  Thu Mar 24 12:20:05 2022
From: stephenfin at redhat.com (Stephen Finucane)
Date: Thu, 24 Mar 2022 12:20:05 +0000
Subject: [qa] Retire os-testr
In-Reply-To: <3416399.dWV9SEqChM@whitebase.usersys.redhat.com>
References: <d667b34c9d02230bef8eac319d47d1b4176aba92.camel@redhat.com>
 <Yjm5v1P4BWEl7xGT@neo-zeong.kortar.org>
 <aaf810c03070c2f4f140eadb56584363c8e22d95.camel@redhat.com>
 <3416399.dWV9SEqChM@whitebase.usersys.redhat.com>
Message-ID: <842b88d6faf53dda5ab04a6c5f84247b730b0a5b.camel@redhat.com>

On Tue, 2022-03-22 at 14:09 +0100, Luigi Toscano wrote:
> On Tuesday, 22 March 2022 13:18:03 CET Sean Mooney wrote:
> > On Tue, 2022-03-22 at 07:57 -0400, Matthew Treinish wrote:
> > > On Tue, Mar 22, 2022 at 11:40:46AM +0000, Stephen Finucane wrote:
> > > > Hey,
> > > > 
> > > > I think it's time we retired os-testr. It is already effectively
> > > > unmaintained and we made a concerted effort some cycles ago to migrate
> > > > all projects to stestr. I think it's time we finally closed that out.
> > > > For any projects still using os-testr, stestr effectively provides a
> > > > drop-in replacement.
> > > > 
> > > > I'll propose patches to do this shortly. Please let me know if anyone
> > > > has any concerns about this course of action.
> > > 
> > > Well the reason we didn't retire it after everything migrated to stestr
> > > was that the repo contained other utilities for working with subunit
> > > streams. Primarily, the subunit2html and generate-subunit utilities. I'm
> > > not sure if they're still being used anywhere, but at least historically
> > > subunit2html was used to generate the interactive web view of the test
> > > results and was run at the end of every job. The generate-subunit tool
> > > was used by at least devstack to have build failures show up in the test
> > > results stream (this was primarily in support of reporting it to
> > > subunit2sql which I know has recently shut down so it might not be needed
> > > anymore).
> > > 
> > > I personally don't really have any strong feelings on whether to retire
> > > the repo or not, but at least the last time we discussed it we kept the
> > > repo around for those other utilities.
> > 
> > i feel like migrating those utilities to there own repo perhaps zuul-jobs
> > would make more sense if they are in fact still used by zuul to generate
> > the html report.
> 
> Agreed, it would be nice to have at least subunit2html around somewhere.

Thanks for the information here. I'll look into where these could live before
abandoning things. If they're widespead, I'll probably leave well enough alone
:)

Stephen

> 
> 



From ozzzo at yahoo.com  Wed Mar 23 19:24:08 2022
From: ozzzo at yahoo.com (Albert Braden)
Date: Wed, 23 Mar 2022 19:24:08 +0000 (UTC)
Subject: [kolla] [rabbitmq] RMQ trouble after config update
In-Reply-To: <DU0PR10MB5244D0F445E12A93AD10C75AEA169@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>
References: <405973893.569766.1647608065129.ref@mail.yahoo.com>
 <405973893.569766.1647608065129@mail.yahoo.com>
 <DU0PR10MB5244FF8FAC7F41D9AB9B25BDEA139@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>
 <612895794.735804.1647634386875@mail.yahoo.com>
 <1452271910.755075.1647636614609@mail.yahoo.com>
 <DU0PR10MB5244FF5ABF5F7DE7289EAF66EA169@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>
 <222141973.1340186.1647870965176@mail.yahoo.com>
 <DU0PR10MB5244D0F445E12A93AD10C75AEA169@DU0PR10MB5244.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <1605510184.2349044.1648063448543@mail.yahoo.com>

 That fixed it; thank you! My co-workers will think I'm an RMQ guru.
     On Monday, March 21, 2022, 10:52:16 AM EDT, Felix H?ttner <felix.huettner at mail.schwarz> wrote:  
 
 <!--#yiv7291928012 _filtered {} _filtered {} _filtered {}#yiv7291928012 #yiv7291928012 p.yiv7291928012MsoNormal, #yiv7291928012 li.yiv7291928012MsoNormal, #yiv7291928012 div.yiv7291928012MsoNormal {margin:0cm;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv7291928012 a:link, #yiv7291928012 span.yiv7291928012MsoHyperlink {color:blue;text-decoration:underline;}#yiv7291928012 p.yiv7291928012msonormal, #yiv7291928012 li.yiv7291928012msonormal, #yiv7291928012 div.yiv7291928012msonormal {margin-right:0cm;margin-left:0cm;font-size:11.0pt;font-family:"Calibri", sans-serif;}#yiv7291928012 .yiv7291928012MsoChpDefault {font-family:"Calibri", sans-serif;} _filtered {}#yiv7291928012 div.yiv7291928012WordSection1 {}-->
Hi Albert,
 
 ?
 
i think the following should work (but not tested)
 
 ?
 
{"vhost": "/", "name": "notifications-expire", "pattern": "^(notifications_designate|versioned_notifications).*", "apply-to": "queues", "definition": {"message-ttl":600000,"expires":1200000, "ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":1},
{"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0}
 
 ?
 
Note the ?priority?: 1 on the first one. It should ensure it is prioritized over the second one.
 
This way the notifications get all the ha setting as well as the expire stuff.
 
 ?
 
Best Regards

Felix H?ttner
Schwarz IT KG * Stiftsbergstra?e 1 * D-74172 Neckarsulm
 
From: Albert Braden <ozzzo at yahoo.com>
Sent: Monday, March 21, 2022 2:56 PM
To: Openstack-discuss <openstack-discuss at lists.openstack.org>; Felix H?ttner <felix.huettner at mail.schwarz>
Subject: Re: [kolla] [rabbitmq] RMQ trouble after config update
 
 ?
 
Thank you Felix; that?s very helpful. I think I understand how it works now. The problem is, I want the notifications_designate messages to expire, because if they don?t, unconsumed messages linger forever. Is it possible to combine these two policies so that all durable queues are HA, but notifications_designate still expires? Can I have two definitions applied to different patterns in a single policy?

{"vhost": "/", "name": "notifications-expire", "pattern": "^(notifications_designate|versioned_notifications).*", "apply-to": "queues", "definition": {"message-ttl":600000,"expires":1200000}, "priority":0},
{"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0} ] }
 
On Monday, March 21, 2022, 06:11:23 AM EDT, Felix H?ttner <felix.huettner at mail.schwarz> wrote:
 
 ?
 
 ?
 
Hi Albert,
 
?
 
TL;DR: you set durable on your openstack service, not on rabbitmq. It is the same for all queues, so either you make them all HA or none of them (at least afaik).
 
?
 
the ?durable? setting is not defined by the policy but by the client that declares the queue. Openstack normally uses the following setting for that:
 
?
 
[oslo_messaging_rabbit]
 
amqp_durable_queues = true
 
?
 
AFAIK this is a global setting and not different for notifications vs. other queues.
 
An exception of this is fanout/reply queues which are always non-durable.
 
?
 
The whole durable/HA thing can be summarized as follows
 
?
 
Durable: If true then the message will survive the crash/restart of a rabbitmq nodes. If false the message is lost on crash/restart. Set by the client declaring the queue
 
HA-mode: If enabled the queue is replicated across multiple nodes. If disabled only a single node hosts the queue and all messages. Set by the policy on rabbitmq
 
?
 
And the following are the result of restarts of a single node in each of the combinations:
 
| 
?
  | 
Durable
  | 
Non-durable
  |
| 
HA
  | 
Queue is failing over to another node. All messages are preserved
  | 
DO NOT DO THIS. The queue should fail over to another node, but the other node does not have any message. This does not make sense and causes all kind of strange rabbitmq issues.
  |
| 
Non-HA
  | 
Queue is unavailable (no reads or writes) until the single node comes back. All messages are preserved.
  | 
Queue is deleted and all messages are lost. It can be redeclared on another node while the first one is down.
  |


?
 
?
 
Best Regards

Felix H?ttner
Schwarz IT KG * Stiftsbergstra?e 1 * D-74172 Neckarsulm
 
From: Albert Braden <ozzzo at yahoo.com>
Sent: Friday, March 18, 2022 9:50 PM
To: Openstack-discuss <openstack-discuss at lists.openstack.org>; Felix H?ttner <felix.huettner at mail.schwarz>
Subject: Re: [kolla] [rabbitmq] RMQ trouble after config update
 
?
 
I fixed the typo and redeployed. The filter now reads:

{"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)|(notifications_designate)|(versioned_notifications)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0} ]

I also tried deleting the RMQ containers and volumes and then redeploying, and deleting the queues and their exchanges, but they are re-created durable.
 
On Friday, March 18, 2022, 04:22:17 PM EDT, Albert Braden <ozzzo at yahoo.com> wrote:
 
?
 
?
 
I did not intend to make the notifications_designate queues HA nor durable. It
appears that those two queues are treated differently from the others that I
didn't specify as HA. For example, if I look at one of the _fanout queues, it
is not durable:

Features
x-expires: 1800000
Policy
Operator policy
Effective policy definition
Node rabbit at de6-ctrl2

I tried adding the notifications_designate queues to the exclusion list:

{"vhost": "/", "name": "ha-all", "pattern":
"^(?!(amq\.)|(.*_fanout_)|(reply_)(notifications_designate)|(versioned_notifications)).*",
"apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown":
"always", "ha-sync

But this doesn't seem to make a difference. The notifications_designate queues
still have " Features: durable: true"

How can I make the notifications_designate queues non-durable? 
 
On Friday, March 18, 2022, 10:04:08 AM EDT, Felix H?ttner <felix.huettner at mail.schwarz> wrote:
 
?
 
?
 
Hi Albert,

for the queue "notifications_designate.info" both the "notifications-expire" and the "ha-all" policy would match with their pattern. However only one policy can be applied to a queue at any given point in time. I assume "notifications-expire" is applied (but you can check that easily in the UI or with "rabbitmqctl list_queues name policy").

In this case the "notifications_designate.info" is created as durable (because of amqp_durable_queues) and non-ha (as the policy does not define ha).
When a node with a durable and non-ha queue goes down then this queue no longer useable until either the node comes back or the queue is deleted.

In your case I would assume that you also want this queue to be HA, so you probably need to set the options of the "ha-all" policy also in the "notifications-expire" policy.

Regarding the last point of the queue being on ctrl2 and you connecting to ctrl1 this is normal rabbitmq behaviour in that it will forward messages to other nodes if needed.

Best Regards

Felix H?ttner
Schwarz IT KG * Stiftsbergstra?e 1 * D-74172 Neckarsulm
 

-----Original Message-----
From: Albert Braden <ozzzo at yahoo.com>
Sent: Friday, March 18, 2022 1:54 PM
To: Openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: [kolla] [rabbitmq] RMQ trouble after config update

We're running kolla-ansible Train. I followed the recommendations in [1] and ended up with the following config:

definitions.json (in the rabbitmq container):

{
? "vhosts": [
? ? {"name": "/"}? ],
? "users": [
? ? {"name": "openstack", "password": "<password>", "tags": "administrator"}? ],
? "permissions": [
? ? {"user": "openstack", "vhost": "/", "configure": ".*", "write": ".*", "read": ".*"}? ],
? "policies":[
? ? {"vhost": "/", "name": "notifications-expire", "pattern": "^(notifications_designate|versioned_notifications).*", "apply-to": "queues", "definition": {"message-ttl":600000,"expires":1200000}, "priority":0},
? ? {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all","ha-promote-on-shutdown": "always", "ha-sync-mode":"automatic"}, "priority":0}? ] }

etc/kolla/config/global.conf:

[oslo_messaging_rabbit]
amqp_durable_queues = True

This fixed some issues, but we seem to have a new issue so I must be missing a setting. When we stop the RMQ container on ctrl1, designate stops working (DNS records are not created nor deleted) and I see this in designate-sink.log:

2022-03-17 19:21:29.261 28 ERROR oslo.messaging._drivers.impl_rabbit [req-2c0cd9f4-5331-4697-9c3e-eece475a52af - - - - -] Failed to consume message from queue: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible: amqp.exceptions.NotFound: Queue.declare: (404) NOT_FOUND - home node 'rabbit at de6-ctrl1' of durable queue 'notifications_designate.info' in vhost '/' is down or inaccessible

When I look at the notifications_designate.info queue in the web interface, it appears to have moved to ctrl2:

Features
durable:? ? ? ? ? ? ? true
Policy? ? notifications-expire
Operator policy
Effective policy definition
expires: 1200000
message-ttl:? ? ? 600000
Node? ? rabbit at qde3-ctrl2

When I look at designate.conf in the designate_sink containers I don't see anything pointing only to ctrl1:

transport_url = rabbit://openstack:<pwd>@<ctrl1>:5672,openstack:<pwd>@<ctrl2>:5672,openstack:<pwd>@<ctrl3>:5672//

But it appears that Designate still tries to use the queue on ctrl1. After I bring up ctrl1, the notifications_designate.info queue remains on ctrl2, but Designate starts working.

What am I missing?

[1] 
 
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FLarge_Scale_Configuration_Rabbit&data=04%7C01%7C%7C103b79868a61424923bb08da08df82f7%7Cd04f47175a6e4b98b3f96918e0385f4c%7C0%7C0%7C637832053312648154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1RIlfljNyKg71IrZc0NIuqDoHPkTGtSBthadz%2Bneofk%3D&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<https://www.datenschutz.schwarz
 
>.
 
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 Siehier.
 
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 Siehier.
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220323/34ffec37/attachment-0001.htm>

From anyrude10 at gmail.com  Thu Mar 24 11:52:28 2022
From: anyrude10 at gmail.com (Anirudh Gupta)
Date: Thu, 24 Mar 2022 17:22:28 +0530
Subject: [TripleO] Offline Installation Support
In-Reply-To: <CAKxkTi06DycBER29GRHMs0OKe523-6GJZnKf=1XXSdU3ogD38w@mail.gmail.com>
References: <CAKxkTi0zKnjKLF5sBQ0TdCbymhCQnvuj-=jCJh6PS4asgmzD+w@mail.gmail.com>
 <5ff25e47-1a0d-6b42-2f49-336ba68ffba9@redhat.com>
 <CAJm6b-54VnWRY19PPZxy6XfFQQMuSgYh1Czuso9z6ayMwXdACQ@mail.gmail.com>
 <CAKxkTi06DycBER29GRHMs0OKe523-6GJZnKf=1XXSdU3ogD38w@mail.gmail.com>
Message-ID: <CAKxkTi3vsT+QQaU-1Qrj_UUKniA-kjAMX3ZkdpfkUKCndO7ujQ@mail.gmail.com>

Hi Harald/TripleO Team,

Is there any solution/work around for the problem being faced?

*Ensure DNF modules have the right stream* | undercloud | item={'module':
'container-tools', 'stream': '3.0'} | error={
    "ansible_loop_var": "item",
    "changed": false,
    "invocation": {
        "module_args": {
            "allow_downgrade": false,
            "autoremove": false,
            "bugfix": false,
            "conf_file": null,
            "disable_excludes": null,
            "disable_gpg_check": false,
            "disable_plugin": [],
            "disablerepo": [],
            "download_dir": null,
            "download_only": false,
            "enable_plugin": [],
            "enablerepo": [],
            "exclude": [],
            "install_repoquery": true,
            "install_weak_deps": true,
            "installroot": "/",
            "list": null,
            "lock_timeout": 30,
            "name": [
                "@container-tools:3.0/common"
            ],
            "releasever": null,
            "security": false,
            "skip_broken": false,
            "state": "present",
            "update_cache": false,
            "update_only": false,
            "validate_certs": true
        }
    },
    "item": {
        "module": "container-tools",
        "stream": "3.0"
    },
    "msg": "*No group container-tools:3.0/common available*.",
    "results": []
}


On Wed, Mar 23, 2022 at 2:45 PM Anirudh Gupta <anyrude10 at gmail.com> wrote:

> Hi Harald,
>
> Thanks for sharing the steps and apologies for the late reply.
>
> I tried setting up Local Repo Server and Registry Server on one machine.
> Using that I successfully deployed Openstack Ussuri Undercloud and
> Overcloud in an offline mode.
>
> Now, in order to test Upgrade from USSURI to VICTORIA, I updated the repo
> file and podman registry at my local server for Victoria.
> On Undercloud , repo file content is as follows:
>
> [tripleo]
> baseurl = http://30.30.30.8/software/repos/tripleo_victoria
> enabled = 1
> gpgcheck = 0
> module_hotfixes=1
> name = tripleo
>
> where 30.30.30.8 is the IP of my reposerver.
>
> With this I have successfully updated the required packages using the
> command:
> *sudo yum update python*-tripleoclient openstack-tripleo-common
> openstack-tripleo-heat-templates*
>
> Also the container image prepare file, now has the following content
> parameter_defaults:
>   ContainerImagePrepare:
>   - push_destination: true
>     set:
>       name_prefix: openstack-
>       name_suffix: ''
>       namespace: myserver.com:5000/tripleovictoria
>       neutron_driver: ovn
>       rhel_containers: false
>       tag: current-tripleo
>     tag_from_label: rdo_version
>
>
> But once I run the command "*openstack undercloud upgrade*", I get the
> following error
> 2022-03-23 09:53:24,527 p=380392 u=root n=ansible | 2022-03-23
> 09:53:24.527073 | 5254007b-2040-558f-a68f-0000000000ac |      FATAL |
> Ensure DNF modules have the right stream | undercloud | item={'module':
> 'container-tools', 'stream': '3.0'} | error={
>     "ansible_loop_var": "item",
>     "changed": false,
>     "invocation": {
>         "module_args": {
>             "allow_downgrade": false,
>             "autoremove": false,
>             "bugfix": false,
>             "conf_file": null,
>             "disable_excludes": null,
>             "disable_gpg_check": false,
>             "disable_plugin": [],
>             "disablerepo": [],
>             "download_dir": null,
>             "download_only": false,
>             "enable_plugin": [],
>             "enablerepo": [],
>             "exclude": [],
>             "install_repoquery": true,
>             "install_weak_deps": true,
>             "installroot": "/",
>             "list": null,
>             "lock_timeout": 30,
>             "name": [
>                 "@container-tools:3.0/common"
>             ],
>             "releasever": null,
>             "security": false,
>             "skip_broken": false,
>             "state": "present",
>             "update_cache": false,
>             "update_only": false,
>             "validate_certs": true
>         }
>     },
>     "item": {
>         "module": "container-tools",
>         "stream": "3.0"
>     },
>     "msg": "*No group container-tools:3.0/common available*.",
>     "results": []
> }
>
> Can you please help in resolving this issue.
>
> Regards
> Anirudh Gupta
>
>
> On Wed, Mar 23, 2022 at 2:06 PM Lokendra Rathour <
> lokendrarathour at gmail.com> wrote:
>
>>
>>
>> ---------- Forwarded message ---------
>> From: Harald Jensas <hjensas at redhat.com>
>> Date: Wed, Feb 23, 2022 at 9:57 PM
>> Subject: Re: [TripleO] Offline Installation Support
>> To: <openstack-discuss at lists.openstack.org>
>>
>>
>> On 2/16/22 13:58, Anirudh Gupta wrote:
>> > Hi Team,
>> >
>> > We have successfully done POC on deploying my TripleO Train HA Setup
>> > with Baremetal Provisioning on Overcloud Node as well.
>> >
>> > We would like to thank Tripleo community members for helping us and
>> > resolving all our concerns at all times.
>> >
>> > Moving forward, we need to deploy the setup on the Lab environment for
>> > which I need some support as well.
>> >
>> > We don't have internet in Lab machines, all that we have is access to a
>> > central server (staging) which has internet access and we can download
>> > all the requirements over there.
>> >
>> > Queries:
>> >
>> >   * Is there any feasible method to install Undercloud and Overcloud
>> >     Machines in complete offline mode?
>> >   * If yes, then
>> >
>> >      1. What are the steps to download all related stuff on the staging
>> >         server?
>>
>> I don't know the exact steps, and I am not aware of upstream
>> documentation page explaining this.
>>
>> You will probalby want to use the 'rsync' tool to sync RDO RPM
>> repositories and create a local repo on you staging machine. Sync
>> packages, use `createrepo` tool to generate yum/dnf repo metadata. Then
>> set up a webserver to make the repository available over HTTP. Search
>> the internets for "Create local RPM repository / mirror", there are many
>> generic guides that will help you.
>>
>>
>> For containers you need to set up a local container registry. Then I
>> would suggest useing the `skopeo`[1] tool to sync containers from the
>> public registry to your local registry.
>>
>> >      2. What modifications would be required in undercloud/overcloud and
>> >         other configuration files to support this?
>> >
>>
>> You need to set up the undercloud to use the RPM repositries on the
>> staging server. Put config in /etc/yum.repos.d/*.repo files. Once the
>> overcloud is deployed you would want to add the repo config there as well.
>>
>> You need to use a custom containers-prepare file when deploying the
>> undercloud and overcloud, you must set the namespaces to point to your
>> local registry. Something like this:
>>
>> parameter_defaults:
>>    ContainerImagePrepare:
>>    - push_destination: false
>>      set:
>>        name_prefix: openstack-
>>        name_suffix: ''
>>        namespace: staging.example.com:5000/tripleotrain
>>        neutron_driver: null
>>        tag: current-tripleo
>>        ...
>>
>> I would suggest generating the container prepare env file with the
>> `openstack tripleo container image prepare` command[2] and then edit the
>> generated file.
>>
>>
>> [1] https://github.com/containers/skopeo
>> [2]
>>
>> https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/container_image_prepare.html
>>
>>
>>
>>
>> --
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220324/daf8d4ff/attachment-0001.htm>

From Karthik.Viswanath at datacore.com  Thu Mar 24 12:33:28 2022
From: Karthik.Viswanath at datacore.com (Karthik Viswanath)
Date: Thu, 24 Mar 2022 12:33:28 +0000
Subject: [cinder][drivers][stable-policy] propose adding DataCore driver to
 train
In-Reply-To: <DM6PR11MB335600798C570DF0AF1896A49F199@DM6PR11MB3356.namprd11.prod.outlook.com>
References: <DM6PR11MB335600798C570DF0AF1896A49F199@DM6PR11MB3356.namprd11.prod.outlook.com>
Message-ID: <DM6PR11MB33564648FCD96A01A30B3E649F199@DM6PR11MB3356.namprd11.prod.outlook.com>

Hi OpenStack community,

I am the product manager for SANsymphony, a software defined SAN storage offering, at DataCore<http://www.datacore.com/>.

A little bit of history on the current request.

DataCore had a Cinder driver in Queen?s branch few years back. Due to organizational restructuring and change in priorities we had to scale back on our efforts towards OpenStack solutions. Because of this we were unable to be active in the community and as a result we got ousted out of Rocky branch due to lack of CI. Details here<https://review.opendev.org/c/openstack/cinder/+/638029>.

Currently we have multiple open opportunities with our European customers requiring us to certify RHOSP Cinder driver for both iSCSI and FC protocols. All our current customers are on RHOSP 16.x and would continue to be on that release for another 12-14 months. As a storage solutions provider, we will have to support our customers on 16.x release.

As per OpenStack?s Cinder driver policy, this change is considered as *new* driver request and we are unable to backport the changes directly.

Given that this has direct revenue impact for DataCore and is time sensitive, we request the community to approve our request to add Cinder driver patch to 16.x maintenance releases ( mainly for Trains branch).

Thanks!

Karthik Viswanath
Sr Product Manager, DataCore
Cell: 9886032686

[https://www.datacoreassets.com/email-signatures/logo-email-signature.png]<https://www.datacore.com/?utm_source=signature&utm_medium=email&utm_content=logo>
DataCore Software ? The Authority on Software-Defined Storage
1901 Cypress Creek Road Ste. 200 Ft. Lauderdale, FL 33309

[cid1612899890*image002.png at 01D83EF4.5833C600]


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220324/81c75cbb/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 2351 bytes
Desc: image001.png
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220324/81c75cbb/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 34942 bytes
Desc: image002.png
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220324/81c75cbb/attachment-0003.png>

From eblock at nde.ag  Thu Mar 24 14:33:03 2022
From: eblock at nde.ag (Eugen Block)
Date: Thu, 24 Mar 2022 14:33:03 +0000
Subject: rabbitmq config changes not applied in newer format
In-Reply-To: <20220324095810.Horde.M7FDQIhittE5kJ6pIdqj24Y@webmail.nde.ag>
Message-ID: <20220324143303.Horde.npmqqZg6mUlqUY46i2AdSpC@webmail.nde.ag>

Update: it doesn't seem to be a problem with the config file format  
but with the clustering. On a VM (single-control node) I tried the  
"newer" config file format and it worked. But that node is not part of  
a cluster, in our production cloud we have the "classic_config"  
enabled as backend and a list of all cluster nodes in the config file:

cluster_formation.peer_discovery_backend = classic_config
cluster_formation.classic_config.nodes.1 = rabbit at controller01.fqdn
cluster_formation.classic_config.nodes.2 = rabbit at controller02.fqdn
cluster_formation.classic_config.nodes.3 = rabbit at controller01
cluster_formation.classic_config.nodes.4 = rabbit at controller02

When I remove that cluster part from the newer config file the node  
doesn't join the cluster, this is what the config looks like:

listeners.tcp.all_ips   = 0.0.0.0:5672
management.load_definitions = /etc/rabbitmq/definitions.json
management.ssl.port = 15671
management.ssl.ip   = 0.0.0.0
management.ssl.cacertfile = /path/to/cafile
management.ssl.certfile   = /path/to/certfile
management.ssl.keyfile    = /path/to/keyfile

This is the error message:

2022-03-24 15:25:49.183 [info] <0.1227.0> WAL: recovering  
["/var/lib/rabbitmq/mnesia/rabbit at controller01/quorum/rabbit at controller01/00000002.wal"]
2022-03-24 15:25:49.359 [warning] <0.1227.0> wal: encountered error  
during recovery: badarg

Then I switch back to the old format where no clustering is mentioned  
at all and it works. Could anyone give me a hint what I'm doing wrong?


Zitat von Eugen Block <eblock at nde.ag>:

> Hi *,
>
> this might not be the right place to ask but I'm curious how others  
> configure their rabbitmq.
>
> RabbitMQ version: 3.8.3
> OpenStack version: Ussuri/Victoria (two different clusters)
>
> We have a highly available cloud controlled by pacemaker. The  
> deployment is based on our own Salt states. We noticed that our  
> config is not applied (e. g. after power outage), we need to import  
> those manually with 'rabbitmqctl import /path/to/definitions.json'.  
> Comparing it to an older cloud version (Rocky, Rabbit version  
> 3.6.16) I noticed that the config format is different between those  
> versions, the older version uses a json format (?):
>
> ---snip---
> # old format
>
> cat /etc/rabbitmq/rabbitmq.config
> [
>  {mnesia,
>   [
>    {dump_log_write_threshold, 300},
>    {dump_log_time_threshold, 180000}
>   ]
>  },
>  {rabbit,
>   [
>    {collect_statistics_interval, 5000},
>    {tcp_listen_options, [
>                          {backlog, 128},{nodelay, true},{keepalive, false}
>                         ]
>    },
>    {tcp_listeners, [
>                     {"x.x.x.x", 5672}
>                    ]},
>    {cluster_partition_handling, pause_minority},
>    {queue_master_locator, <<"min-masters">>},
>    {disk_free_limit, 50000000}
>  ]},
>  {rabbitmq_management,
>   [
>    {listener, [{ip, "x.x.x.x"}, {port, 15673}]},
>    {load_definitions, "/etc/rabbitmq/definitions.json"}
>   ]
>  }
> ].
>
>
> # new format
> [...]
> listeners.tcp.default = 5672
> listeners.tcp.other_port = 5673
> listeners.tcp.other_ip   = x.x.x.x:5672
> [...]
> ---snip---
>
> If I switch to the old format and restart rabbitmq on that node, the  
> changes are applied successfully. Is this a known issue? Should I  
> just stick to the old format? Any comments are appreciated!
>
> Regards,
> Eugen





From fungi at yuggoth.org  Thu Mar 24 14:53:46 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Thu, 24 Mar 2022 14:53:46 +0000
Subject: [cinder][drivers][stable-policy] propose adding DataCore driver
 to train
In-Reply-To: <DM6PR11MB33564648FCD96A01A30B3E649F199@DM6PR11MB3356.namprd11.prod.outlook.com>
References: <DM6PR11MB335600798C570DF0AF1896A49F199@DM6PR11MB3356.namprd11.prod.outlook.com>
 <DM6PR11MB33564648FCD96A01A30B3E649F199@DM6PR11MB3356.namprd11.prod.outlook.com>
Message-ID: <20220324145346.vfikmy3z7junmrfg@yuggoth.org>

[I'm leaving you in Cc since you don't seem to be subscribed to the
mailing list.]

On 2022-03-24 12:33:28 +0000 (+0000), Karthik Viswanath wrote:
[...]
> Given that this has direct revenue impact for DataCore and is time
> sensitive, we request the community to approve our request to add
> Cinder driver patch to 16.x maintenance releases ( mainly for
> Trains branch).

I can't speak for the Cinder maintainers and their backport
policies, but from a release perspective there will be no further
16.x releases of Cinder. The stable/ussuri branch (where 16.x
releases were made) passed out of maintenance phase after 16.4.2 was
tagged in November of last year. The stable/train branch is where
Cinder's 15.x releases were made and has been out of official
maintenance since 15.6.0 last May. The stable/victoria branch
(Cinder 17.x releases) is the oldest still officially maintained and
is slated to be dropped from maintenance next month.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220324/7c5883f4/attachment.sig>

From tobias.urdin at binero.com  Thu Mar 24 15:28:30 2022
From: tobias.urdin at binero.com (Tobias Urdin)
Date: Thu, 24 Mar 2022 15:28:30 +0000
Subject: [puppet] Proposing core team clean up
In-Reply-To: <CAL_crJS5OeWhbJ3RcgKTZ9ENHfpNZRy1ZQdzDXRKx=unRJiV-A@mail.gmail.com>
References: <CAL_crJS5OeWhbJ3RcgKTZ9ENHfpNZRy1ZQdzDXRKx=unRJiV-A@mail.gmail.com>
Message-ID: <65AF5398-4C61-4A5E-8CED-0E1C6F47F46D@binero.com>

+1

Good with some cleanup, thanks Takashi, and thanks to all the people below
who has worked on the project before!

> On 14 Mar 2022, at 02:28, Takashi Kajinami <tkajinam at redhat.com> wrote:
> 
> Hello,
> 
> 
> I went through the current core reviewers and found out that the current list includes
> some people no longer working in the OpenStack community.
> 
> I'd like to propose removing the following persons from the core reviewer team
> as we haven't seen these people making any activity in the community recently.
> 
> * Pradeep Kilambi
>  - puppet-aodh, puppet-ceilometer, puppet-gnocchi, puppet-panko
> 
> * Richard Megginson
>  - puppet-keystone
> 
> * Denis Egorenko
>  - puppet-murano
> 
> * Serg Melikyan
>  - puppet-murano
> 
> * Sergey Kolekonov
>  - puppet-neutron
>  
> * David Moreau Simard
>  - puppet-openstack-integration
>  
> * Yu xingchao
>  - all modules
> 
> Also, I confirmed that Wes Hayutin is no longer working for OpenStack and he agreed
> to retire from the core reviewer position. Thus I'll remove him as well.
> 
> I'll be open for any feedback for one week to hear any thoughts/feedback about this removal.
> 
> I'd like to take this moment to thank all people for their past work.
> We always welcome them back if they resume their work in this project.
> 
> Thank you,
> Takashi KAJINAMI



From peter.matulis at canonical.com  Thu Mar 24 16:06:35 2022
From: peter.matulis at canonical.com (Peter Matulis)
Date: Thu, 24 Mar 2022 12:06:35 -0400
Subject: [docs] toctree directive + hidden
Message-ID: <CABBmjLpgRKiPNMEdzkx_WWujKXKyXtOfqWgKwQ1o6980d_e8oA@mail.gmail.com>

Greetings to any doc peeps,

I've been struggling with my project's documentation table of contents for
a while. What I want to do is NOT publish a TOC on the page where it is
defined (via the 'toctree' directive) but I DO want the sidebar/navigation
(left menu) to be populaed. According to the upstream documentation [0] the
way forward is via the toctree 'hidden' option. However, by doing so I also
lose the sidebar aspect - I filed a bug against the openstackdocstheme
theme [2]. Help?

p.s. I found an old workaround on Stack Overflow [1].

Thanks,
Peter

[0]:
https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html
[1]: https://stackoverflow.com/a/20841272/12801299
[2]: https://bugs.launchpad.net/openstack-doc-tools/+bug/1965063
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220324/bc7c3f76/attachment.htm>

From tkajinam at redhat.com  Thu Mar 24 16:18:03 2022
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Fri, 25 Mar 2022 01:18:03 +0900
Subject: [puppet] Proposing core team clean up
In-Reply-To: <65AF5398-4C61-4A5E-8CED-0E1C6F47F46D@binero.com>
References: <CAL_crJS5OeWhbJ3RcgKTZ9ENHfpNZRy1ZQdzDXRKx=unRJiV-A@mail.gmail.com>
 <65AF5398-4C61-4A5E-8CED-0E1C6F47F46D@binero.com>
Message-ID: <CAL_crJRiShGmd4SQGECdpxtM-XKVuNL2+x096ETRYBYUd+drSw@mail.gmail.com>

Thanks Tobias for your feedback here.
I also had a chat with Alex and he agreed with the cleanup.

As we have heard no objections but only positive feedback for a week,
I've made the change.

I'd like to thank these people again for their past work in this project !


On Fri, Mar 25, 2022 at 12:34 AM Tobias Urdin <tobias.urdin at binero.com>
wrote:

> +1
>
> Good with some cleanup, thanks Takashi, and thanks to all the people below
> who has worked on the project before!
>
> > On 14 Mar 2022, at 02:28, Takashi Kajinami <tkajinam at redhat.com> wrote:
> >
> > Hello,
> >
> >
> > I went through the current core reviewers and found out that the current
> list includes
> > some people no longer working in the OpenStack community.
> >
> > I'd like to propose removing the following persons from the core
> reviewer team
> > as we haven't seen these people making any activity in the community
> recently.
> >
> > * Pradeep Kilambi
> >  - puppet-aodh, puppet-ceilometer, puppet-gnocchi, puppet-panko
> >
> > * Richard Megginson
> >  - puppet-keystone
> >
> > * Denis Egorenko
> >  - puppet-murano
> >
> > * Serg Melikyan
> >  - puppet-murano
> >
> > * Sergey Kolekonov
> >  - puppet-neutron
> >
> > * David Moreau Simard
> >  - puppet-openstack-integration
> >
> > * Yu xingchao
> >  - all modules
> >
> > Also, I confirmed that Wes Hayutin is no longer working for OpenStack
> and he agreed
> > to retire from the core reviewer position. Thus I'll remove him as well.
> >
> > I'll be open for any feedback for one week to hear any thoughts/feedback
> about this removal.
> >
> > I'd like to take this moment to thank all people for their past work.
> > We always welcome them back if they resume their work in this project.
> >
> > Thank you,
> > Takashi KAJINAMI
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220325/3976f38a/attachment-0001.htm>

From lokendrarathour at gmail.com  Thu Mar 24 16:36:58 2022
From: lokendrarathour at gmail.com (Lokendra Rathour)
Date: Thu, 24 Mar 2022 22:06:58 +0530
Subject: [TripleO] Offline Installation Support
In-Reply-To: <CAKxkTi06DycBER29GRHMs0OKe523-6GJZnKf=1XXSdU3ogD38w@mail.gmail.com>
References: <CAKxkTi0zKnjKLF5sBQ0TdCbymhCQnvuj-=jCJh6PS4asgmzD+w@mail.gmail.com>
 <5ff25e47-1a0d-6b42-2f49-336ba68ffba9@redhat.com>
 <CAJm6b-54VnWRY19PPZxy6XfFQQMuSgYh1Czuso9z6ayMwXdACQ@mail.gmail.com>
 <CAKxkTi06DycBER29GRHMs0OKe523-6GJZnKf=1XXSdU3ogD38w@mail.gmail.com>
Message-ID: <CAJm6b-5iVWO8dTQOWtUYVGOG3gdss_YfdHZ4S-Mh=MUO=_Ft3w@mail.gmail.com>

Hi OpenStack Team,
Facing similar problem.
Any proposed solution?


Thanks & Regards,
Lokendra


On Wed, 23 Mar 2022, 14:45 Anirudh Gupta, <anyrude10 at gmail.com> wrote:

> Hi Harald,
>
> Thanks for sharing the steps and apologies for the late reply.
>
> I tried setting up Local Repo Server and Registry Server on one machine.
> Using that I successfully deployed Openstack Ussuri Undercloud and
> Overcloud in an offline mode.
>
> Now, in order to test Upgrade from USSURI to VICTORIA, I updated the repo
> file and podman registry at my local server for Victoria.
> On Undercloud , repo file content is as follows:
>
> [tripleo]
> baseurl = http://30.30.30.8/software/repos/tripleo_victoria
> enabled = 1
> gpgcheck = 0
> module_hotfixes=1
> name = tripleo
>
> where 30.30.30.8 is the IP of my reposerver.
>
> With this I have successfully updated the required packages using the
> command:
> *sudo yum update python*-tripleoclient openstack-tripleo-common
> openstack-tripleo-heat-templates*
>
> Also the container image prepare file, now has the following content
> parameter_defaults:
>   ContainerImagePrepare:
>   - push_destination: true
>     set:
>       name_prefix: openstack-
>       name_suffix: ''
>       namespace: myserver.com:5000/tripleovictoria
>       neutron_driver: ovn
>       rhel_containers: false
>       tag: current-tripleo
>     tag_from_label: rdo_version
>
>
> But once I run the command "*openstack undercloud upgrade*", I get the
> following error
> 2022-03-23 09:53:24,527 p=380392 u=root n=ansible | 2022-03-23
> 09:53:24.527073 | 5254007b-2040-558f-a68f-0000000000ac |      FATAL |
> Ensure DNF modules have the right stream | undercloud | item={'module':
> 'container-tools', 'stream': '3.0'} | error={
>     "ansible_loop_var": "item",
>     "changed": false,
>     "invocation": {
>         "module_args": {
>             "allow_downgrade": false,
>             "autoremove": false,
>             "bugfix": false,
>             "conf_file": null,
>             "disable_excludes": null,
>             "disable_gpg_check": false,
>             "disable_plugin": [],
>             "disablerepo": [],
>             "download_dir": null,
>             "download_only": false,
>             "enable_plugin": [],
>             "enablerepo": [],
>             "exclude": [],
>             "install_repoquery": true,
>             "install_weak_deps": true,
>             "installroot": "/",
>             "list": null,
>             "lock_timeout": 30,
>             "name": [
>                 "@container-tools:3.0/common"
>             ],
>             "releasever": null,
>             "security": false,
>             "skip_broken": false,
>             "state": "present",
>             "update_cache": false,
>             "update_only": false,
>             "validate_certs": true
>         }
>     },
>     "item": {
>         "module": "container-tools",
>         "stream": "3.0"
>     },
>     "msg": "*No group container-tools:3.0/common available*.",
>     "results": []
> }
>
> Can you please help in resolving this issue.
>
> Regards
> Anirudh Gupta
>
>
> On Wed, Mar 23, 2022 at 2:06 PM Lokendra Rathour <
> lokendrarathour at gmail.com> wrote:
>
>>
>>
>> ---------- Forwarded message ---------
>> From: Harald Jensas <hjensas at redhat.com>
>> Date: Wed, Feb 23, 2022 at 9:57 PM
>> Subject: Re: [TripleO] Offline Installation Support
>> To: <openstack-discuss at lists.openstack.org>
>>
>>
>> On 2/16/22 13:58, Anirudh Gupta wrote:
>> > Hi Team,
>> >
>> > We have successfully done POC on deploying my TripleO Train HA Setup
>> > with Baremetal Provisioning on Overcloud Node as well.
>> >
>> > We would like to thank Tripleo community members for helping us and
>> > resolving all our concerns at all times.
>> >
>> > Moving forward, we need to deploy the setup on the Lab environment for
>> > which I need some support as well.
>> >
>> > We don't have internet in Lab machines, all that we have is access to a
>> > central server (staging) which has internet access and we can download
>> > all the requirements over there.
>> >
>> > Queries:
>> >
>> >   * Is there any feasible method to install Undercloud and Overcloud
>> >     Machines in complete offline mode?
>> >   * If yes, then
>> >
>> >      1. What are the steps to download all related stuff on the staging
>> >         server?
>>
>> I don't know the exact steps, and I am not aware of upstream
>> documentation page explaining this.
>>
>> You will probalby want to use the 'rsync' tool to sync RDO RPM
>> repositories and create a local repo on you staging machine. Sync
>> packages, use `createrepo` tool to generate yum/dnf repo metadata. Then
>> set up a webserver to make the repository available over HTTP. Search
>> the internets for "Create local RPM repository / mirror", there are many
>> generic guides that will help you.
>>
>>
>> For containers you need to set up a local container registry. Then I
>> would suggest useing the `skopeo`[1] tool to sync containers from the
>> public registry to your local registry.
>>
>> >      2. What modifications would be required in undercloud/overcloud and
>> >         other configuration files to support this?
>> >
>>
>> You need to set up the undercloud to use the RPM repositries on the
>> staging server. Put config in /etc/yum.repos.d/*.repo files. Once the
>> overcloud is deployed you would want to add the repo config there as well.
>>
>> You need to use a custom containers-prepare file when deploying the
>> undercloud and overcloud, you must set the namespaces to point to your
>> local registry. Something like this:
>>
>> parameter_defaults:
>>    ContainerImagePrepare:
>>    - push_destination: false
>>      set:
>>        name_prefix: openstack-
>>        name_suffix: ''
>>        namespace: staging.example.com:5000/tripleotrain
>>        neutron_driver: null
>>        tag: current-tripleo
>>        ...
>>
>> I would suggest generating the container prepare env file with the
>> `openstack tripleo container image prepare` command[2] and then edit the
>> generated file.
>>
>>
>> [1] https://github.com/containers/skopeo
>> [2]
>>
>> https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/container_image_prepare.html
>>
>>
>>
>>
>> --
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220324/276d7440/attachment.htm>

From rosmaita.fossdev at gmail.com  Thu Mar 24 17:26:28 2022
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Thu, 24 Mar 2022 13:26:28 -0400
Subject: [cinder][drivers][stable-policy] propose adding DataCore driver
 to train
In-Reply-To: <20220324145346.vfikmy3z7junmrfg@yuggoth.org>
References: <DM6PR11MB335600798C570DF0AF1896A49F199@DM6PR11MB3356.namprd11.prod.outlook.com>
 <DM6PR11MB33564648FCD96A01A30B3E649F199@DM6PR11MB3356.namprd11.prod.outlook.com>
 <20220324145346.vfikmy3z7junmrfg@yuggoth.org>
Message-ID: <e14e1300-aea4-6fd2-2055-bd521a67c056@gmail.com>

On 3/24/22 10:53 AM, Jeremy Stanley wrote:
> [I'm leaving you in Cc since you don't seem to be subscribed to the
> mailing list.]
> 
> On 2022-03-24 12:33:28 +0000 (+0000), Karthik Viswanath wrote:
> [...]
>> Given that this has direct revenue impact for DataCore and is time
>> sensitive, we request the community to approve our request to add
>> Cinder driver patch to 16.x maintenance releases ( mainly for
>> Trains branch).
> 
> I can't speak for the Cinder maintainers and their backport
> policies, but from a release perspective there will be no further
> 16.x releases of Cinder. The stable/ussuri branch (where 16.x
> releases were made) passed out of maintenance phase after 16.4.2 was
> tagged in November of last year. The stable/train branch is where
> Cinder's 15.x releases were made and has been out of official
> maintenance since 15.6.0 last May. The stable/victoria branch
> (Cinder 17.x releases) is the oldest still officially maintained and
> is slated to be dropped from maintenance next month.
> 

Everything Jeremy says is correct.  I would like to add a few points:

(1) With train in extended maintenance mode, appropriate backports are 
accepted, but no releases are made.  Thus, even if the patch were 
accepted, you would have to make other arrangements to get the code to 
your customers, as there will never be a train-series OpenStack release 
containing your patch.

(2) Backports are described in this cinder document, which also 
references the OpenStack Stable Branch Policy:
   https://docs.openstack.org/cinder/latest/contributor/backporting.html
The key issue here is that patches proposed directly to a stable branch 
are only accepted when the issue is not present in more recent branches 
(for example, Block Storage API v2 was removed in xena, so a bug 
affecting only the v2 API could be proposed directly to stable/wallaby). 
  This is not the case here (see next point).

(3) The Cinder project has traditionally considered a new backend driver 
to be a new feature, and hence not backportable.  This includes the 
restoration of drivers that have been kicked out of tree due to a lack 
of compliance with the CI policy.  The policy and why we have it is 
explained here:
   https://docs.openstack.org/cinder/latest/drivers-all-about.html
So, even if you were to propose your driver for the current release, it 
would not be backportable to earlier stable branches.  (Some people have 
maintained that since drivers are isolated to particular backends, maybe 
this restriction could be relaxed.  I'm willing to hear opinions about 
that idea (misguided though it may be), but even so, that's not the case 
here; you're proposing to add a new feature directly to a stable branch.)

(4) If you would like your driver included in the next OpenStack release 
(Zed), you need to propose it to master (which is currently the Zed 
development branch) before Milestone-2, as documented here:
   https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver
A necessary condition for your driver being included in the Zed release 
is that your third-party CI must be compliant with the CI policy 
referenced above in point #3.  (For some reason, people consistently 
underestimate the effort required to get a third-party CI running 
reliably, so I encourage you to begin working on that immediately.)

(5) It seems that your goal here is ultimately that your driver be 
included in the Red Hat OpenStack Platform 16 distribution, which is 
based on OpenStack Train.  Downstream distributions of OpenStack have 
their own policies about what code they will accept and distribute.  I 
know a little about RHOSP, and one of their requirements is that the 
code must exist in an appropriate upstream branch.  Given that you are 
proposing a new driver, the appropriate branch is master (since our 
upstream policies won't allow you to put your code anywhere else). 
Thus, even if your ultimate goal is a presence in RHOSP 16, the correct 
branch to which to contribute your driver is the current master branch.


Thus, speaking on behalf of the Cinder community in my final week as 
Cinder PTL, your request to contribute the DataCore driver directly to 
stable/train is denied.  I do encourage you to persist in your efforts 
to contribute it for the Zed release, as it would be nice to have 
DataCore back in the Cinder family.

cheers,
brian



From katonalala at gmail.com  Thu Mar 24 18:23:09 2022
From: katonalala at gmail.com (Lajos Katona)
Date: Thu, 24 Mar 2022 19:23:09 +0100
Subject: [neutron] Drivers meeting agenda - 24.03.2022.
Message-ID: <CALg0jKkdFg0BrSG-u4wmCxuCbGYtgakoV1-VL2ptrW_Nc3FCZg@mail.gmail.com>

Hi Neutron Drivers,

The agenda for tomorrow's drivers meeting is at [1].

* Recheck gratuitous ARPs are not sent during master transition: (
https://bugs.launchpad.net/neutron/+bug/1952907)
** For this one there are a few wip patches:
** https://review.opendev.org/c/openstack/neutron/+/821434
** https://review.opendev.org/c/openstack/neutron/+/821433
** https://review.opendev.org/c/openstack/neutron/+/712474

On Demand agenda
* (ralonsoh): https://bugs.launchpad.net/neutron/+bug/1964575. In
particular patch https://review.opendev.org/c/openstack/neutron/+/833247.
I'm raising this topic to make the community aware of this migration to
SQLAlchemy 2.0 and the implications related. (if needed, I'll request 20
mins during the PTG).
* (lajoskatona): PTG etherpad:
https://etherpad.opendev.org/p/neutron-zed-ptg

[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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220324/b3680bc1/attachment-0001.htm>

From smooney at redhat.com  Thu Mar 24 19:02:42 2022
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 24 Mar 2022 19:02:42 +0000
Subject: [cinder][drivers][stable-policy] propose adding DataCore driver
 to train
In-Reply-To: <e14e1300-aea4-6fd2-2055-bd521a67c056@gmail.com>
References: <DM6PR11MB335600798C570DF0AF1896A49F199@DM6PR11MB3356.namprd11.prod.outlook.com>
 <DM6PR11MB33564648FCD96A01A30B3E649F199@DM6PR11MB3356.namprd11.prod.outlook.com>
 <20220324145346.vfikmy3z7junmrfg@yuggoth.org>
 <e14e1300-aea4-6fd2-2055-bd521a67c056@gmail.com>
Message-ID: <688109cd69ea82f9411f3a306e88c736c8b0702f.camel@redhat.com>

On Thu, 2022-03-24 at 13:26 -0400, Brian Rosmaita wrote:
> On 3/24/22 10:53 AM, Jeremy Stanley wrote:
> > [I'm leaving you in Cc since you don't seem to be subscribed to the
> > mailing list.]
> > 
> > On 2022-03-24 12:33:28 +0000 (+0000), Karthik Viswanath wrote:
> > [...]
> > > Given that this has direct revenue impact for DataCore and is time
> > > sensitive, we request the community to approve our request to add
> > > Cinder driver patch to 16.x maintenance releases ( mainly for
> > > Trains branch).
> > 
> > I can't speak for the Cinder maintainers and their backport
> > policies, but from a release perspective there will be no further
> > 16.x releases of Cinder. The stable/ussuri branch (where 16.x
> > releases were made) passed out of maintenance phase after 16.4.2 was
> > tagged in November of last year. The stable/train branch is where
> > Cinder's 15.x releases were made and has been out of official
> > maintenance since 15.6.0 last May. The stable/victoria branch
> > (Cinder 17.x releases) is the oldest still officially maintained and
> > is slated to be dropped from maintenance next month.
> > 
> 
> Everything Jeremy says is correct.  I would like to add a few points:
> 
> (1) With train in extended maintenance mode, appropriate backports are 
> accepted, but no releases are made.  Thus, even if the patch were 
> accepted, you would have to make other arrangements to get the code to 
> your customers, as there will never be a train-series OpenStack release 
> containing your patch.
> 
> (2) Backports are described in this cinder document, which also 
> references the OpenStack Stable Branch Policy:
>    https://docs.openstack.org/cinder/latest/contributor/backporting.html
> The key issue here is that patches proposed directly to a stable branch 
> are only accepted when the issue is not present in more recent branches 
> (for example, Block Storage API v2 was removed in xena, so a bug 
> affecting only the v2 API could be proposed directly to stable/wallaby). 
>   This is not the case here (see next point).
> 
> (3) The Cinder project has traditionally considered a new backend driver 
> to be a new feature, and hence not backportable.  This includes the 
> restoration of drivers that have been kicked out of tree due to a lack 
> of compliance with the CI policy.  The policy and why we have it is 
> explained here:
>    https://docs.openstack.org/cinder/latest/drivers-all-about.html
> So, even if you were to propose your driver for the current release, it 
> would not be backportable to earlier stable branches.  (Some people have 
> maintained that since drivers are isolated to particular backends, maybe 
> this restriction could be relaxed.  I'm willing to hear opinions about 
> that idea (misguided though it may be), but even so, that's not the case 
> here; you're proposing to add a new feature directly to a stable branch.)
> 
> (4) If you would like your driver included in the next OpenStack release 
> (Zed), you need to propose it to master (which is currently the Zed 
> development branch) before Milestone-2, as documented here:
>    https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver
> A necessary condition for your driver being included in the Zed release 
> is that your third-party CI must be compliant with the CI policy 
> referenced above in point #3.  (For some reason, people consistently 
> underestimate the effort required to get a third-party CI running 
> reliably, so I encourage you to begin working on that immediately.)
> 
> (5) It seems that your goal here is ultimately that your driver be 
> included in the Red Hat OpenStack Platform 16 distribution, which is 
> based on OpenStack Train.  Downstream distributions of OpenStack have 
> their own policies about what code they will accept and distribute.  I 
> know a little about RHOSP, and one of their requirements is that the 
> code must exist in an appropriate upstream branch.  Given that you are 
> proposing a new driver, the appropriate branch is master (since our 
> upstream policies won't allow you to put your code anywhere else). 
> Thus, even if your ultimate goal is a presence in RHOSP 16, the correct 
> branch to which to contribute your driver is the current master branch.
on the downstream side for osp 16 you would also have to comply with the thrid party vender integration certification requirements
https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/8.42/html/red_hat_openstack_certification_policy_guide/assembly-rhosp-certification-targets_rhosp-pol-introduction-policy-guide#con_products-implementing-openstack-apis_rhosp-pol-certification-targets
to pass certification you will need to support installing your driver via tripleo/direct in adddiont to the other requirement in the document above.
also form a platform lifecycle point of view New certification are only allowed in the full support pahse and for the first 90 days fo maintance
phase?in our old policy  https://access.redhat.com/support/policy/updates/openstack/platform however there are explcit Third-party certification
period listed for 16.1 and 16.2. 

the certification deadline for 16.2 is currently May 31, 2022
while its not imposiable to complet certificaiton for 16.2 at this point downstream we still have ci and Recertification requiremtns
https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/8.42/html/red_hat_openstack_certification_policy_guide/assembly-certification-lifecycle_rhosp-pol-certification-targets#con_continual-testing_rhosp-pol-certifiation-lifecycle
the cinder specific requirement for certificaiton are listed here
https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/8.42/html/red_hat_openstack_certification_policy_guide/con_cinder-subtests_rhosp-pol-openstack-director

as other have noted the best way forward is likely to work on getting datacore added back to master/zed with the required third party ci and in
paralle reach out to the redhat cerificaion team the workflow for certification is described here
https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/8.42/html/red_hat_openstack_certification_workflow_guide/assembly-introduction-to-openstack-certification_rhosp-policy-guide

i am neither involved in the storage side of osp rhosp or certification so im just providign the links to the downstream document to be helpful.

> 
> 
> Thus, speaking on behalf of the Cinder community in my final week as 
> Cinder PTL, your request to contribute the DataCore driver directly to 
> stable/train is denied.  I do encourage you to persist in your efforts 
> to contribute it for the Zed release, as it would be nice to have 
> DataCore back in the Cinder family.
> 
> cheers,
> brian
> 
> 



From gmann at ghanshyammann.com  Thu Mar 24 21:57:49 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 24 Mar 2022 16:57:49 -0500
Subject: [qa] Retire os-testr
In-Reply-To: <842b88d6faf53dda5ab04a6c5f84247b730b0a5b.camel@redhat.com>
References: <d667b34c9d02230bef8eac319d47d1b4176aba92.camel@redhat.com>
 <Yjm5v1P4BWEl7xGT@neo-zeong.kortar.org>
 <aaf810c03070c2f4f140eadb56584363c8e22d95.camel@redhat.com>
 <3416399.dWV9SEqChM@whitebase.usersys.redhat.com>
 <842b88d6faf53dda5ab04a6c5f84247b730b0a5b.camel@redhat.com>
Message-ID: <17fbdef94e7.101d9358f817116.7690732712894392495@ghanshyammann.com>

 ---- On Thu, 24 Mar 2022 07:20:05 -0500 Stephen Finucane <stephenfin at redhat.com> wrote ----
 > On Tue, 2022-03-22 at 14:09 +0100, Luigi Toscano wrote:
 > > On Tuesday, 22 March 2022 13:18:03 CET Sean Mooney wrote:
 > > > On Tue, 2022-03-22 at 07:57 -0400, Matthew Treinish wrote:
 > > > > On Tue, Mar 22, 2022 at 11:40:46AM +0000, Stephen Finucane wrote:
 > > > > > Hey,
 > > > > > 
 > > > > > I think it's time we retired os-testr. It is already effectively
 > > > > > unmaintained and we made a concerted effort some cycles ago to migrate
 > > > > > all projects to stestr. I think it's time we finally closed that out.
 > > > > > For any projects still using os-testr, stestr effectively provides a
 > > > > > drop-in replacement.
 > > > > > 
 > > > > > I'll propose patches to do this shortly. Please let me know if anyone
 > > > > > has any concerns about this course of action.
 > > > > 
 > > > > Well the reason we didn't retire it after everything migrated to stestr
 > > > > was that the repo contained other utilities for working with subunit
 > > > > streams. Primarily, the subunit2html and generate-subunit utilities. I'm
 > > > > not sure if they're still being used anywhere, but at least historically
 > > > > subunit2html was used to generate the interactive web view of the test
 > > > > results and was run at the end of every job. The generate-subunit tool
 > > > > was used by at least devstack to have build failures show up in the test
 > > > > results stream (this was primarily in support of reporting it to
 > > > > subunit2sql which I know has recently shut down so it might not be needed
 > > > > anymore).
 > > > > 
 > > > > I personally don't really have any strong feelings on whether to retire
 > > > > the repo or not, but at least the last time we discussed it we kept the
 > > > > repo around for those other utilities.
 > > > 
 > > > i feel like migrating those utilities to there own repo perhaps zuul-jobs
 > > > would make more sense if they are in fact still used by zuul to generate
 > > > the html report.
 > > 
 > > Agreed, it would be nice to have at least subunit2html around somewhere.
 > 
 > Thanks for the information here. I'll look into where these could live before
 > abandoning things. If they're widespead, I'll probably leave well enough alone
 > :)

We discussed it in QA meeting and agreed to remove only deprecated ostestr
command and continue maintaining other parts.

- https://meetings.opendev.org/irclogs/%23openstack-qa/%23openstack-qa.2022-03-22.log.html#t2022-03-22T15:45:36
- https://review.opendev.org/c/openstack/os-testr/+/835124/2

-gmann
 > 
 > Stephen
 > 
 > > 
 > > 
 > 
 > 
 > 


From gmann at ghanshyammann.com  Thu Mar 24 22:43:18 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 24 Mar 2022 17:43:18 -0500
Subject: [all][tc] Canceling TC next two weekly meetings
Message-ID: <17fbe193b16.afc7fc8b817868.2151498156029219740@ghanshyammann.com>

Hello Everyone,

Because of OpenInfra episode of "Yoga release" on March 31st and PTG on April 7th,
we agreed to cancel the TC weekly meeting for the next two weeks (31st March and 7th April).

We will continue our weekly meeting from April 14th onwards.

-gmann


From laurentfdumont at gmail.com  Thu Mar 24 23:13:10 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Thu, 24 Mar 2022 19:13:10 -0400
Subject: [TripleO] Offline Installation Support
In-Reply-To: <CAJm6b-5iVWO8dTQOWtUYVGOG3gdss_YfdHZ4S-Mh=MUO=_Ft3w@mail.gmail.com>
References: <CAKxkTi0zKnjKLF5sBQ0TdCbymhCQnvuj-=jCJh6PS4asgmzD+w@mail.gmail.com>
 <5ff25e47-1a0d-6b42-2f49-336ba68ffba9@redhat.com>
 <CAJm6b-54VnWRY19PPZxy6XfFQQMuSgYh1Czuso9z6ayMwXdACQ@mail.gmail.com>
 <CAKxkTi06DycBER29GRHMs0OKe523-6GJZnKf=1XXSdU3ogD38w@mail.gmail.com>
 <CAJm6b-5iVWO8dTQOWtUYVGOG3gdss_YfdHZ4S-Mh=MUO=_Ft3w@mail.gmail.com>
Message-ID: <CAOAKi8wYJqU=GprWvx3SpQXzeBoBTACJwP9kW58tmWD3m-fRFQ@mail.gmail.com>

I have never used  DNF, but it seems to check for DNF to have the right
modules.

On Thu, Mar 24, 2022 at 12:40 PM Lokendra Rathour <lokendrarathour at gmail.com>
wrote:

> Hi OpenStack Team,
> Facing similar problem.
> Any proposed solution?
>
>
> Thanks & Regards,
> Lokendra
>
>
> On Wed, 23 Mar 2022, 14:45 Anirudh Gupta, <anyrude10 at gmail.com> wrote:
>
>> Hi Harald,
>>
>> Thanks for sharing the steps and apologies for the late reply.
>>
>> I tried setting up Local Repo Server and Registry Server on one machine.
>> Using that I successfully deployed Openstack Ussuri Undercloud and
>> Overcloud in an offline mode.
>>
>> Now, in order to test Upgrade from USSURI to VICTORIA, I updated the repo
>> file and podman registry at my local server for Victoria.
>> On Undercloud , repo file content is as follows:
>>
>> [tripleo]
>> baseurl = http://30.30.30.8/software/repos/tripleo_victoria
>> enabled = 1
>> gpgcheck = 0
>> module_hotfixes=1
>> name = tripleo
>>
>> where 30.30.30.8 is the IP of my reposerver.
>>
>> With this I have successfully updated the required packages using the
>> command:
>> *sudo yum update python*-tripleoclient openstack-tripleo-common
>> openstack-tripleo-heat-templates*
>>
>> Also the container image prepare file, now has the following content
>> parameter_defaults:
>>   ContainerImagePrepare:
>>   - push_destination: true
>>     set:
>>       name_prefix: openstack-
>>       name_suffix: ''
>>       namespace: myserver.com:5000/tripleovictoria
>>       neutron_driver: ovn
>>       rhel_containers: false
>>       tag: current-tripleo
>>     tag_from_label: rdo_version
>>
>>
>> But once I run the command "*openstack undercloud upgrade*", I get the
>> following error
>> 2022-03-23 09:53:24,527 p=380392 u=root n=ansible | 2022-03-23
>> 09:53:24.527073 | 5254007b-2040-558f-a68f-0000000000ac |      FATAL |
>> Ensure DNF modules have the right stream | undercloud | item={'module':
>> 'container-tools', 'stream': '3.0'} | error={
>>     "ansible_loop_var": "item",
>>     "changed": false,
>>     "invocation": {
>>         "module_args": {
>>             "allow_downgrade": false,
>>             "autoremove": false,
>>             "bugfix": false,
>>             "conf_file": null,
>>             "disable_excludes": null,
>>             "disable_gpg_check": false,
>>             "disable_plugin": [],
>>             "disablerepo": [],
>>             "download_dir": null,
>>             "download_only": false,
>>             "enable_plugin": [],
>>             "enablerepo": [],
>>             "exclude": [],
>>             "install_repoquery": true,
>>             "install_weak_deps": true,
>>             "installroot": "/",
>>             "list": null,
>>             "lock_timeout": 30,
>>             "name": [
>>                 "@container-tools:3.0/common"
>>             ],
>>             "releasever": null,
>>             "security": false,
>>             "skip_broken": false,
>>             "state": "present",
>>             "update_cache": false,
>>             "update_only": false,
>>             "validate_certs": true
>>         }
>>     },
>>     "item": {
>>         "module": "container-tools",
>>         "stream": "3.0"
>>     },
>>     "msg": "*No group container-tools:3.0/common available*.",
>>     "results": []
>> }
>>
>> Can you please help in resolving this issue.
>>
>> Regards
>> Anirudh Gupta
>>
>>
>> On Wed, Mar 23, 2022 at 2:06 PM Lokendra Rathour <
>> lokendrarathour at gmail.com> wrote:
>>
>>>
>>>
>>> ---------- Forwarded message ---------
>>> From: Harald Jensas <hjensas at redhat.com>
>>> Date: Wed, Feb 23, 2022 at 9:57 PM
>>> Subject: Re: [TripleO] Offline Installation Support
>>> To: <openstack-discuss at lists.openstack.org>
>>>
>>>
>>> On 2/16/22 13:58, Anirudh Gupta wrote:
>>> > Hi Team,
>>> >
>>> > We have successfully done POC on deploying my TripleO Train HA Setup
>>> > with Baremetal Provisioning on Overcloud Node as well.
>>> >
>>> > We would like to thank Tripleo community members for helping us and
>>> > resolving all our concerns at all times.
>>> >
>>> > Moving forward, we need to deploy the setup on the Lab environment for
>>> > which I need some support as well.
>>> >
>>> > We don't have internet in Lab machines, all that we have is access to
>>> a
>>> > central server (staging) which has internet access and we can download
>>> > all the requirements over there.
>>> >
>>> > Queries:
>>> >
>>> >   * Is there any feasible method to install Undercloud and Overcloud
>>> >     Machines in complete offline mode?
>>> >   * If yes, then
>>> >
>>> >      1. What are the steps to download all related stuff on the staging
>>> >         server?
>>>
>>> I don't know the exact steps, and I am not aware of upstream
>>> documentation page explaining this.
>>>
>>> You will probalby want to use the 'rsync' tool to sync RDO RPM
>>> repositories and create a local repo on you staging machine. Sync
>>> packages, use `createrepo` tool to generate yum/dnf repo metadata. Then
>>> set up a webserver to make the repository available over HTTP. Search
>>> the internets for "Create local RPM repository / mirror", there are many
>>> generic guides that will help you.
>>>
>>>
>>> For containers you need to set up a local container registry. Then I
>>> would suggest useing the `skopeo`[1] tool to sync containers from the
>>> public registry to your local registry.
>>>
>>> >      2. What modifications would be required in undercloud/overcloud
>>> and
>>> >         other configuration files to support this?
>>> >
>>>
>>> You need to set up the undercloud to use the RPM repositries on the
>>> staging server. Put config in /etc/yum.repos.d/*.repo files. Once the
>>> overcloud is deployed you would want to add the repo config there as
>>> well.
>>>
>>> You need to use a custom containers-prepare file when deploying the
>>> undercloud and overcloud, you must set the namespaces to point to your
>>> local registry. Something like this:
>>>
>>> parameter_defaults:
>>>    ContainerImagePrepare:
>>>    - push_destination: false
>>>      set:
>>>        name_prefix: openstack-
>>>        name_suffix: ''
>>>        namespace: staging.example.com:5000/tripleotrain
>>>        neutron_driver: null
>>>        tag: current-tripleo
>>>        ...
>>>
>>> I would suggest generating the container prepare env file with the
>>> `openstack tripleo container image prepare` command[2] and then edit the
>>> generated file.
>>>
>>>
>>> [1] https://github.com/containers/skopeo
>>> [2]
>>>
>>> https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/container_image_prepare.html
>>>
>>>
>>>
>>>
>>> --
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220324/b67289b9/attachment-0001.htm>

From rosmaita.fossdev at gmail.com  Thu Mar 24 23:17:13 2022
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Thu, 24 Mar 2022 19:17:13 -0400
Subject: [cinder] Yoga retrospective surveys! Win fabulous prizes!
Message-ID: <1a446d73-5314-d067-1feb-1186d0810744@gmail.com>

Hello Argonauts,

As discussed at yesterday's Cinder meeting, we'll have a Yoga cycle 
retrospective during the next weekly cinder meeting on Wednesday 30 
March.  I'm actually going to broaden it a bit, so feel free to express 
your gripes (or kudos) for the Wallaby-Xena-Yoga cycles.  Because IRC 
and video don't allow for much anonymity, you can fill out one (or both) 
of these anonymous surveys that we can use as the basis for discussion:

Cinder Wallaby-Xena-Yoga Retrospective
- https://rosmaita.wufoo.com/forms/m1gc1dfo1s42947/

Cinder W-X-Y Retrospective Survey for Drivers
- https://rosmaita.wufoo.com/forms/zab0fdr1dg4nwo/

These are really short.  The best manager I ever had always just asked 3 
questions when he wanted an evaluation of someone, and that's what I'm 
doing too.  That means you only have to give 3 answers!

I will be interested to learn stuff I can use if I'm not reincarnated as 
a cockroach, and Rajat will be able to get some feedback about how the 
team feels about how things are going.  So please take the surveys.


cheers,
brian


From rdhasman at redhat.com  Fri Mar 25 04:42:01 2022
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Fri, 25 Mar 2022 10:12:01 +0530
Subject: [cinder][drivers][stable-policy] propose adding DataCore driver
 to train
In-Reply-To: <688109cd69ea82f9411f3a306e88c736c8b0702f.camel@redhat.com>
References: <DM6PR11MB335600798C570DF0AF1896A49F199@DM6PR11MB3356.namprd11.prod.outlook.com>
 <DM6PR11MB33564648FCD96A01A30B3E649F199@DM6PR11MB3356.namprd11.prod.outlook.com>
 <20220324145346.vfikmy3z7junmrfg@yuggoth.org>
 <e14e1300-aea4-6fd2-2055-bd521a67c056@gmail.com>
 <688109cd69ea82f9411f3a306e88c736c8b0702f.camel@redhat.com>
Message-ID: <CAARK8KTo01ff_jgQKKxufwfkGs29xMiTou4h7M4JgeQWDykjog@mail.gmail.com>

Big +1 to what Brian said. In the current situation, the most sensible
thing to do is to try to get the driver merged into Zed release (current
master).
The release schedule for Zed is here[1] and you need to get the driver code
merged before milestone 2 i.e. Jul 11 - Jul 15. Also the driver
requires a third party CI working to ensure the driver is working correctly
so that also needs to be done at the same time.

I would recommend the DataCore driver developer team to join the Cinder
PTG[2] as we are going to have sessions for driver maintainers
that would be very helpful to understand the process and how to contribute
a new driver to Cinder.

[1] https://releases.openstack.org/zed/schedule.html
[2] https://etherpad.opendev.org/p/zed-ptg-cinder-planning

Thanks and regards
Rajat Dhasmana

On Fri, Mar 25, 2022 at 12:37 AM Sean Mooney <smooney at redhat.com> wrote:

> On Thu, 2022-03-24 at 13:26 -0400, Brian Rosmaita wrote:
> > On 3/24/22 10:53 AM, Jeremy Stanley wrote:
> > > [I'm leaving you in Cc since you don't seem to be subscribed to the
> > > mailing list.]
> > >
> > > On 2022-03-24 12:33:28 +0000 (+0000), Karthik Viswanath wrote:
> > > [...]
> > > > Given that this has direct revenue impact for DataCore and is time
> > > > sensitive, we request the community to approve our request to add
> > > > Cinder driver patch to 16.x maintenance releases ( mainly for
> > > > Trains branch).
> > >
> > > I can't speak for the Cinder maintainers and their backport
> > > policies, but from a release perspective there will be no further
> > > 16.x releases of Cinder. The stable/ussuri branch (where 16.x
> > > releases were made) passed out of maintenance phase after 16.4.2 was
> > > tagged in November of last year. The stable/train branch is where
> > > Cinder's 15.x releases were made and has been out of official
> > > maintenance since 15.6.0 last May. The stable/victoria branch
> > > (Cinder 17.x releases) is the oldest still officially maintained and
> > > is slated to be dropped from maintenance next month.
> > >
> >
> > Everything Jeremy says is correct.  I would like to add a few points:
> >
> > (1) With train in extended maintenance mode, appropriate backports are
> > accepted, but no releases are made.  Thus, even if the patch were
> > accepted, you would have to make other arrangements to get the code to
> > your customers, as there will never be a train-series OpenStack release
> > containing your patch.
> >
> > (2) Backports are described in this cinder document, which also
> > references the OpenStack Stable Branch Policy:
> >    https://docs.openstack.org/cinder/latest/contributor/backporting.html
> > The key issue here is that patches proposed directly to a stable branch
> > are only accepted when the issue is not present in more recent branches
> > (for example, Block Storage API v2 was removed in xena, so a bug
> > affecting only the v2 API could be proposed directly to stable/wallaby).
> >   This is not the case here (see next point).
> >
> > (3) The Cinder project has traditionally considered a new backend driver
> > to be a new feature, and hence not backportable.  This includes the
> > restoration of drivers that have been kicked out of tree due to a lack
> > of compliance with the CI policy.  The policy and why we have it is
> > explained here:
> >    https://docs.openstack.org/cinder/latest/drivers-all-about.html
> > So, even if you were to propose your driver for the current release, it
> > would not be backportable to earlier stable branches.  (Some people have
> > maintained that since drivers are isolated to particular backends, maybe
> > this restriction could be relaxed.  I'm willing to hear opinions about
> > that idea (misguided though it may be), but even so, that's not the case
> > here; you're proposing to add a new feature directly to a stable branch.)
> >
> > (4) If you would like your driver included in the next OpenStack release
> > (Zed), you need to propose it to master (which is currently the Zed
> > development branch) before Milestone-2, as documented here:
> >    https://wiki.openstack.org/wiki/Cinder/how-to-contribute-a-driver
> > A necessary condition for your driver being included in the Zed release
> > is that your third-party CI must be compliant with the CI policy
> > referenced above in point #3.  (For some reason, people consistently
> > underestimate the effort required to get a third-party CI running
> > reliably, so I encourage you to begin working on that immediately.)
> >
> > (5) It seems that your goal here is ultimately that your driver be
> > included in the Red Hat OpenStack Platform 16 distribution, which is
> > based on OpenStack Train.  Downstream distributions of OpenStack have
> > their own policies about what code they will accept and distribute.  I
> > know a little about RHOSP, and one of their requirements is that the
> > code must exist in an appropriate upstream branch.  Given that you are
> > proposing a new driver, the appropriate branch is master (since our
> > upstream policies won't allow you to put your code anywhere else).
> > Thus, even if your ultimate goal is a presence in RHOSP 16, the correct
> > branch to which to contribute your driver is the current master branch.
> on the downstream side for osp 16 you would also have to comply with the
> thrid party vender integration certification requirements
>
> https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/8.42/html/red_hat_openstack_certification_policy_guide/assembly-rhosp-certification-targets_rhosp-pol-introduction-policy-guide#con_products-implementing-openstack-apis_rhosp-pol-certification-targets
> to pass certification you will need to support installing your driver via
> tripleo/direct in adddiont to the other requirement in the document above.
> also form a platform lifecycle point of view New certification are only
> allowed in the full support pahse and for the first 90 days fo maintance
> phase in our old policy
> https://access.redhat.com/support/policy/updates/openstack/platform
> however there are explcit Third-party certification
> period listed for 16.1 and 16.2.
>
> the certification deadline for 16.2 is currently May 31, 2022
> while its not imposiable to complet certificaiton for 16.2 at this point
> downstream we still have ci and Recertification requiremtns
>
> https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/8.42/html/red_hat_openstack_certification_policy_guide/assembly-certification-lifecycle_rhosp-pol-certification-targets#con_continual-testing_rhosp-pol-certifiation-lifecycle
> the cinder specific requirement for certificaiton are listed here
>
> https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/8.42/html/red_hat_openstack_certification_policy_guide/con_cinder-subtests_rhosp-pol-openstack-director
>
> as other have noted the best way forward is likely to work on getting
> datacore added back to master/zed with the required third party ci and in
> paralle reach out to the redhat cerificaion team the workflow for
> certification is described here
>
> https://access.redhat.com/documentation/en-us/red_hat_openstack_certification/8.42/html/red_hat_openstack_certification_workflow_guide/assembly-introduction-to-openstack-certification_rhosp-policy-guide
>
> i am neither involved in the storage side of osp rhosp or certification so
> im just providign the links to the downstream document to be helpful.
>
> >
> >
> > Thus, speaking on behalf of the Cinder community in my final week as
> > Cinder PTL, your request to contribute the DataCore driver directly to
> > stable/train is denied.  I do encourage you to persist in your efforts
> > to contribute it for the Zed release, as it would be nice to have
> > DataCore back in the Cinder family.
> >
> > cheers,
> > brian
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220325/dac500e5/attachment.htm>

From chkumar at redhat.com  Fri Mar 25 10:19:58 2022
From: chkumar at redhat.com (Chandan Kumar)
Date: Fri, 25 Mar 2022 15:49:58 +0530
Subject: [tripleo] CI jobs broken due to #1966382
Message-ID: <CANhJ86Cx--apCvzJBHdX37sOwci21zXP3dx9njVBSMNXqz5wew@mail.gmail.com>

Hello,

The tripleo-ci jobs are broken due to the following bug.
https://bugs.launchpad.net/tripleo/+bug/1966382 -
Multiple tripleo jobs are failing because of "error: Multiple
top-level packages discovered in a flat-layout"

The  latest release of setuptools 61.0 caused it and more info is
added here: https://github.com/pypa/setuptools/issues/3197

The team is working on fixing it
https://review.opendev.org/q/topic:lp%252F1966382.

Till then please hold the rechecks and avoid workflowing patches.

Thanks,

Chandan Kumar



From amoralej at redhat.com  Fri Mar 25 11:03:11 2022
From: amoralej at redhat.com (Alfredo Moralejo Alonso)
Date: Fri, 25 Mar 2022 12:03:11 +0100
Subject: [tripleo][RDO] Tags for Yoga GA version in tripleo projects
In-Reply-To: <CAM51kHXm0VHtzkjXS6pVr=KMeKi6gqUHyum+Wn1Am81rH+g_PQ@mail.gmail.com>
References: <CACrbaxinP2E=5C95pndGJD1aUWWH2+YJmVucnnwCExZsYd6O6g@mail.gmail.com>
 <CAM51kHXm0VHtzkjXS6pVr=KMeKi6gqUHyum+Wn1Am81rH+g_PQ@mail.gmail.com>
Message-ID: <CACrbaxjaOiT60du=USA79z6ad7KjNEG8WQkufAMr8pq7kU8GgA@mail.gmail.com>

On Thu, Mar 24, 2022 at 7:23 AM Marios Andreou <marios at redhat.com> wrote:

> On Wed, Mar 23, 2022 at 4:24 PM Alfredo Moralejo Alonso <
> amoralej at redhat.com> wrote:
>
>> Hi,
>>
>> As we are doing builds for RDO Yoga release, I'd like to know what we
>> should include in yoga release. In Xena, tags were created with the commits
>> for the most recent promotion at around GA and shipped rpm packages for
>> them. Additionally, we pinned RDO Trunk Xena to those versions. Will we get
>> similar tags for Yoga?
>>
>>
> Hi Alfredo - I think it's a fair request and I guess by replying here I am
> also volunteering to do that ;)
>
> I can prepare a release just after PTG (that is usually about the time we
> would cut the new branch and make the release) is that OK for you? I am
> guessing you'll be blocking the release for this? Or possibly can you
> release without tripleo then release those afterwards if you don't want to
> block?
>
>
Thanks Marios. I think after PTG is fine for us, we can wait for it. I'd
prefer to do the RDO Yoga announcement when we have tripleo packages even
if we push builds for other packages to the repositories before.

Alfredo



> Assuming slagle or anyone else doesn't have any objections to that of
> course
>
> regards, marios
>
>
>
>
>> Best regards,
>>
>> Alfredo
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220325/0f6bed3a/attachment.htm>

From mthode at mthode.org  Fri Mar 25 12:42:32 2022
From: mthode at mthode.org (Matthew Thode)
Date: Fri, 25 Mar 2022 07:42:32 -0500
Subject: [requirements][all] We are now branched for stable/yoga
Message-ID: <20220325124232.kmewnpdysixs3kba@mthode.org>

As the title states, openstack/requirements just branched.  This means
that master can start moving forward with upper-constraints and
global-requirements changes.

1. If you have not branched yet you may start seeing dependency changes
for the 'Z' release in your development branch (Yoga if you've not
branched it yet).
2. If you have changes going into requirements' devepment branch but
want to back port to yoga, remember that you'll have to create a
backport patch for yoga (and other previous branches).

-- 
Matthew Thode
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220325/dedeee5a/attachment.sig>

From ralonsoh at redhat.com  Fri Mar 25 15:08:20 2022
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Fri, 25 Mar 2022 16:08:20 +0100
Subject: [neutron] Feedback on slides (driver's meeting topic)
Message-ID: <CAECr9X4a-BC4r9vt0UuOsNrRGy5cW91=H6CaezOz7F2u5EKSkg@mail.gmail.com>

Hello Neutrinos (and Lajos on this topic):

I would also add:
- OVN BW scheduling aware (in progress during the last two cycles but
almost ready).
- OVN QoS GW IP (actually the patch was merged, so for sure we'll have this
feature that closes the gap between OVN and OVS).

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220325/264f2985/attachment.htm>

From elod.illes at est.tech  Fri Mar 25 15:16:43 2022
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Fri, 25 Mar 2022 16:16:43 +0100
Subject: [release] Release countdown for week R-0, Mar 28-30
Message-ID: <5eda052b-8e52-92a3-12d7-d4b0d4c0debc@est.tech>

Development Focus
-----------------

We will be releasing the coordinated OpenStack Yoga release Wednesday next
week, on March 30th. Thanks to everyone involved in the Yoga 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.opendev.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 30th, so that their approval is included in the metadata
that goes onto the signed tag.

Upcoming Deadlines & Dates
--------------------------

Final Yoga release: March 30th, 2022
PTG: April 4 - 8, 2022 (virtual)
OpenInfra Summit: June 7-9, 2022 (Berlin)

El?dIll?s
irc: elodilles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220325/f30f7398/attachment.htm>

From gmann at ghanshyammann.com  Fri Mar 25 15:49:37 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Fri, 25 Mar 2022 10:49:37 -0500
Subject: [all][tc][goals] : Consistent and Secure Default RBAC: Yoga
 Timeline updates
Message-ID: <17fc1c4d747.1159273f228.8841856384188733923@ghanshyammann.com>

Hello Everyone,

As you know, "Consistent and Secure Default RBAC" is one of the currently selected
community-wide goals and we have divided it into multiple milestones (cycle)[1].

Our first milestone was Yoga release[2] and in this email, I am going to summarize the
progress of Yoga timeline targets. With Lance's role change in his company and we
finalized the direction in between of Yoga cycle, there is less progress than what we
targeted.

Gerrit Topic: https://review.opendev.org/q/topic:%2522secure-rbac%2522+(status:open+OR+status:merged)
Tracking: https://etherpad.opendev.org/p/rbac-goal-tracking

Completed:
=========
* Keystone is already implemented the RBAC as per the new direction.
* Nova completed the RBAC as per the new direction[3].

In-progress:
=========
* Neutron has started the policy update as per the new direction[4].

Yoga Targets and their progress:
========================
1. Keystone implements a new default role called manager:
Spec merged[5], implementation yet to start.

2. Keystone implements a new default role called service:
Spec under discussion[6]

3. Keystone enforces scope by default:
Not yet done. We can do it at the start of the Zed cycle.

4. Services start implementing Phase 1:
Done. The target was to do at least in one of the services and Nova completed it.

5. OpenStack-wide Personas Documentation:
Not yet done.


[1] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#completion-date-criteria
[2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#yoga-timeline-7th-mar-2022
[3] https://blueprints.launchpad.net/nova/+spec/policy-defaults-refresh-2
[4] https://review.opendev.org/c/openstack/neutron/+/821208
[5] https://review.opendev.org/c/openstack/keystone-specs/+/818603
[6] https://review.opendev.org/c/openstack/keystone-specs/+/818616


-gmann



From katonalala at gmail.com  Fri Mar 25 16:09:49 2022
From: katonalala at gmail.com (Lajos Katona)
Date: Fri, 25 Mar 2022 17:09:49 +0100
Subject: [neutron] Feedback on slides (driver's meeting topic)
In-Reply-To: <CAECr9X4a-BC4r9vt0UuOsNrRGy5cW91=H6CaezOz7F2u5EKSkg@mail.gmail.com>
References: <CAECr9X4a-BC4r9vt0UuOsNrRGy5cW91=H6CaezOz7F2u5EKSkg@mail.gmail.com>
Message-ID: <CALg0jKkQmLQxmRi3ZodjuGhJ-hiaKisq7pOk6wZPAdZyQOA7Jg@mail.gmail.com>

Hi Rodolfo,
Thanks, added them.

Rodolfo Alonso Hernandez <ralonsoh at redhat.com> ezt ?rta (id?pont: 2022.
m?rc. 25., P, 16:17):

> Hello Neutrinos (and Lajos on this topic):
>
> I would also add:
> - OVN BW scheduling aware (in progress during the last two cycles but
> almost ready).
> - OVN QoS GW IP (actually the patch was merged, so for sure we'll have
> this feature that closes the gap between OVN and OVS).
>
> Regards.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220325/99004051/attachment-0001.htm>

From rlandy at redhat.com  Fri Mar 25 16:31:31 2022
From: rlandy at redhat.com (Ronelle Landy)
Date: Fri, 25 Mar 2022 12:31:31 -0400
Subject: [tripleo] CI jobs broken due to #1966382
In-Reply-To: <CANhJ86Cx--apCvzJBHdX37sOwci21zXP3dx9njVBSMNXqz5wew@mail.gmail.com>
References: <CANhJ86Cx--apCvzJBHdX37sOwci21zXP3dx9njVBSMNXqz5wew@mail.gmail.com>
Message-ID: <CANnyimMN0TJSRR8_i2hG074aXKTvmwSGatvUwRoMpJj9gTpJbw@mail.gmail.com>

The gate blocker has been cleared.

Thanks for fungi for force merging the required patches.

Also thanks to Sandeep, Chandan, Jakob and Jiri for working on fixes:

https://review.opendev.org/c/openstack/tripleo-quickstart/+/835192/
https://review.opendev.org/c/openstack/tripleo-quickstart-extras/+/835203/
https://review.opendev.org/c/openstack/tripleo-ci/+/835193

On Fri, Mar 25, 2022 at 6:20 AM Chandan Kumar <chkumar at redhat.com> wrote:

> Hello,
>
> The tripleo-ci jobs are broken due to the following bug.
> https://bugs.launchpad.net/tripleo/+bug/1966382 -
> Multiple tripleo jobs are failing because of "error: Multiple
> top-level packages discovered in a flat-layout"
>
> The  latest release of setuptools 61.0 caused it and more info is
> added here: https://github.com/pypa/setuptools/issues/3197
>
> The team is working on fixing it
> https://review.opendev.org/q/topic:lp%252F1966382.
>
> Till then please hold the rechecks and avoid workflowing patches.
>
> Thanks,
>
> Chandan Kumar
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220325/1ca1ca4a/attachment.htm>

From ozzzo at yahoo.com  Fri Mar 25 18:58:16 2022
From: ozzzo at yahoo.com (Albert Braden)
Date: Fri, 25 Mar 2022 18:58:16 +0000 (UTC)
Subject: [kolla] [rabbitmq] Another RMQ config question
References: <1582632913.373382.1648234696593.ref@mail.yahoo.com>
Message-ID: <1582632913.373382.1648234696593@mail.yahoo.com>

We?re running kolla-ansible Train and implementing durable queues. I was able to make it work by adding these lines to etc/kolla/config/global.conf:

[oslo_messaging_rabbit]
amqp_durable_queues = True

But we want to do it one cluster at a time, so I tried commenting that out and adding line: amqp_durable_queues: "True"
to group_vars/<region>/vars.yml but that seems to have no effect. Where can I put this value to enable durable queues per-cluster?


From radoslaw.piliszek at gmail.com  Fri Mar 25 20:56:55 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Fri, 25 Mar 2022 21:56:55 +0100
Subject: [kolla] [rabbitmq] Another RMQ config question
In-Reply-To: <1582632913.373382.1648234696593@mail.yahoo.com>
References: <1582632913.373382.1648234696593.ref@mail.yahoo.com>
 <1582632913.373382.1648234696593@mail.yahoo.com>
Message-ID: <CAKZ_x78oP3h1ewebfT=4Gwgg9mRDaRNbhKrqds92KQNT23Df1A@mail.gmail.com>

On Fri, 25 Mar 2022 at 19:59, Albert Braden <ozzzo at yahoo.com> wrote:
>
> We?re running kolla-ansible Train and implementing durable queues. I was able to make it work by adding these lines to etc/kolla/config/global.conf:
>
> [oslo_messaging_rabbit]
> amqp_durable_queues = True
>
> But we want to do it one cluster at a time, so I tried commenting that out and adding line: amqp_durable_queues: "True"
> to group_vars/<region>/vars.yml but that seems to have no effect. Where can I put this value to enable durable queues per-cluster?

1) Region does not automatically become a group - you need to have an
aptly named group - I believe you know that but I'm just stating this
for completeness. :-)
2) The approach you are taking is correct but you need some level of
indirection. Keep the line you added to global.conf where it is,
replace "True" with something like "{{ my_amqp_durable_queues }}"
(without quotes of course) and then set the my_amqp_durable_queues
variable like you wanted to.

-yoctozepto


From cdilorenzo at gmail.com  Fri Mar 25 21:50:35 2022
From: cdilorenzo at gmail.com (Chris DiLorenzo)
Date: Fri, 25 Mar 2022 17:50:35 -0400
Subject: [magnum] kube_cluster_deploy timing out
Message-ID: <CAJ8AfbGaqnxRCvX=fcAOqyn8QjnMUGLkGZpTqONg00LhT+HLRQ@mail.gmail.com>

Hello,

I'm trying to deploy a kubernetes cluster using CoreOS 33.   I have
also tried with CoreOS 35/. 1 master, 1 worker.  Ths VMs are deploying
without issue.  However, the stack is timing out on kube_cluster_deploy.
It appears the kubernetes API isn't running:

[root at tes-001-pkjawhk66slm-master-0 log]# podman ps
CONTAINER ID  IMAGE
   COMMAND               CREATED         STATUS             PORTS   NAMES
a08cbea59a57
docker.io/openstackmagnum/heat-container-agent:wallaby-stable-1
 /usr/bin/start-he...  21 minutes ago  Up 21 minutes ago
 heat-container-agent

[root at tes-001-pkjawhk66slm-master-0 log]# ss -ln | grep 8080 -> nothing

[root at tes-001-pkjawhk66slm-master-0 heat-config-script]# tail -f
8d8fa128-bca4-485e-946f-90732ebb4cf0-tes-001-pkjawhk66slm-kube_cluster_config-bwkfqwjxzk36.log
+ sleep 5
++ kubectl get --raw=/healthz
The connection to the server localhost:8080 was refused - did you specify
the right host or port?
+ '[' ok = '' ']'
+ sleep 5
++ kubectl get --raw=/healthz
The connection to the server localhost:8080 was refused - did you specify
the right host or port?
+ '[' ok = '' ']'
+ sleep 5
++ kubectl get --raw=/healthz

Not sure where else to look.

Thanks
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220325/3673d48d/attachment.htm>

From gmann at ghanshyammann.com  Sat Mar 26 00:58:16 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Fri, 25 Mar 2022 19:58:16 -0500
Subject: [all][tc] What's happening in Technical Committee: summary Mar
 25th, 21: Reading: 10 min
Message-ID: <17fc3bb25bb.d78be51412554.9182130462818071437@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 Mar 24th. Most of the meeting discussions are summarized below (Completed
or in-progress activities section). Meeting full logs are available
@https://meetings.opendev.org/meetings/tc/2022/tc.2022-03-24-15.00.log.html

* Due to OpenInfra episode and PTG, we have cancelled the next two meetings[1] and will be meeting on April 14th
Thursday 15:00 UTC, feel free to add the topic on the agenda[2] by April 13th.


2. What we completed this week:
=========================
* None for this week.


3. Activities In progress:
==================
TC Tracker for Yoga cycle
------------------------------
* This etherpad includes the Yoga cycle targets/working items for TC[3].
4 out of 9 items are completed and many are in progress.

Open Reviews
-----------------
* Five open reviews for ongoing activities[4].

Consistent and Secure Default RBAC
--------------------------------------------
I sent the updates for Yoga timeline target on ML[5] and created the etherpad
to track this goal for all the milestone[6].  The quick summary is, along with keystone,
Nova has completed the work and neutron is in progress.

Community-wide goals readiness checklist
--------------------------------------------------
As we received the feedback in Yoga PTG TC+PTL interaction session, I have
proposed the checklist which can help us to check if the goal is ready to start or
not[7], please review and let us know if more items need to be added.

Zed cycle Leaderless projects
----------------------------------
No updates on this. I am still waiting for Zaqar PTL +1 on the PTL appointment patch[8]
and we will discuss Adjutant in PTG, hoping Braden will be ready with their company
side permission[9].

PTG Preparation
--------------------
Nothing much to share on this but please continue adding the topics in etherpad[10].

Dropping tags framework
------------------------------
Along with deprecation tag removal[11], we are removing the complete framework now[12].

Fixing Zuul config error
----------------------------
Requesting projects with zuul config error to look into those and fix them which should
not take much time[13].

Project updates
-------------------
* None for this week.


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[14].
2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [15]
3. Ping us using 'tc-members' nickname on #openstack-tc IRC channel.


[1] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027828.html
[2] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting
[3] https://etherpad.opendev.org/p/tc-yoga-tracker
[4] https://review.opendev.org/q/projects:openstack/governance+status:open
[5] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027837.html
[6] https://etherpad.opendev.org/p/rbac-goal-tracking
[7] https://review.opendev.org/c/openstack/governance/+/835102
[8] https://review.opendev.org/c/openstack/governance/+/831123
[9] http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027626.html
[10] https://etherpad.opendev.org/p/tc-zed-ptg
[11] https://review.opendev.org/c/openstack/governance/+/834327
[12] https://review.opendev.org/c/openstack/governance/+/834798/3
[13] https://etherpad.opendev.org/p/zuul-config-error-openstack
[14] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
[15] http://eavesdrop.openstack.org/#Technical_Committee_Meeting

-gmann


From tonyliu0592 at hotmail.com  Sat Mar 26 05:02:53 2022
From: tonyliu0592 at hotmail.com (Tony Liu)
Date: Sat, 26 Mar 2022 05:02:53 +0000
Subject: [kolla-ansible] OVS br-ex configuration for OVN SNAT gateway along
 with HAProxy
Message-ID: <CO6PR14MB52507C4B98FF62461D4A6A57BD1B9@CO6PR14MB5250.namprd14.prod.outlook.com>

Hi,

My goal is to have OVN SNAT gateway (with OVS bridge) and HAProxy co-exist.
Here is the networking configuration (partial) before deployment.
eth1, no address, neutron_external_interface
eth1.40, external address, kolla_external_vip_interface

After deployment, I'd like to see this.
br-ex
  eth1
  eth1.40 tag 40
eth1.40 with external address

But actually, only eth1 is put on br-ex by Kolla Ansible.

Need eth1.40 on br-ex, because the external network is also one of the provider
networks. Need eth1 on br-ex, to support other provider networks (different VLANs).
It works fine when deploy with TripleO with os-net-config.

Is it supported by Kolla Ansible? It seems Kolla Ansible only puts one interface
(neutron_external_interface) on br-ex?

I know a few workarounds in case that's not supported, just want to confirm.

Thanks!
Tony


From skaplons at redhat.com  Sat Mar 26 07:03:29 2022
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Sat, 26 Mar 2022 08:03:29 +0100
Subject: [neutron] Feedback on slides (driver's meeting topic)
In-Reply-To: <CALg0jKkQmLQxmRi3ZodjuGhJ-hiaKisq7pOk6wZPAdZyQOA7Jg@mail.gmail.com>
References: <CAECr9X4a-BC4r9vt0UuOsNrRGy5cW91=H6CaezOz7F2u5EKSkg@mail.gmail.com>
 <CALg0jKkQmLQxmRi3ZodjuGhJ-hiaKisq7pOk6wZPAdZyQOA7Jg@mail.gmail.com>
Message-ID: <21569501.EfDdHjke4D@p1>

Hi,

On pi?tek, 25 marca 2022 17:09:49 CET Lajos Katona wrote:
> Hi Rodolfo,
> Thanks, added them.
> 
> Rodolfo Alonso Hernandez <ralonsoh at redhat.com> ezt ?rta (id?pont: 2022.
> m?rc. 25., P, 16:17):
> 
> > Hello Neutrinos (and Lajos on this topic):
> >
> > I would also add:
> > - OVN BW scheduling aware (in progress during the last two cycles but
> > almost ready).
> > - OVN QoS GW IP (actually the patch was merged, so for sure we'll have
> > this feature that closes the gap between OVN and OVS).
> >
> > Regards.
> >
> >
> 

It looks good for me. I would only highligh that FwaaS team wants to add support for OVN there and that this was (IIRC) main reason why it was revived recently.

-- 
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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220326/4b839fab/attachment.sig>

From Danny.Webb at thehutgroup.com  Sat Mar 26 19:05:03 2022
From: Danny.Webb at thehutgroup.com (Danny Webb)
Date: Sat, 26 Mar 2022 19:05:03 +0000
Subject: [kolla-ansible] OVS br-ex configuration for OVN SNAT gateway
 along with HAProxy
In-Reply-To: <CO6PR14MB52507C4B98FF62461D4A6A57BD1B9@CO6PR14MB5250.namprd14.prod.outlook.com>
References: <CO6PR14MB52507C4B98FF62461D4A6A57BD1B9@CO6PR14MB5250.namprd14.prod.outlook.com>
Message-ID: <LO2P265MB5773FA98E54E30F0CE83CC6F9A1B9@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>

<https://github.com/openstack/kolla-ansible/blob/79a5bf2bbe6d8b3509ace56c887baba4c79e61d5/doc/source/reference/networking/neutron.rst#example-multiple-interfaces>
Hi Tony,

Multiple interfaces can be configured as follows:

https://github.com/openstack/kolla-ansible/blob/master/doc/source/reference/networking/neutron.rst#example-multiple-interfaces

Danny
________________________________
From: Tony Liu <tonyliu0592 at hotmail.com>
Sent: 26 March 2022 05:02
To: openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: [kolla-ansible] OVS br-ex configuration for OVN SNAT gateway along with HAProxy

CAUTION: This email originates from outside THG

Hi,

My goal is to have OVN SNAT gateway (with OVS bridge) and HAProxy co-exist.
Here is the networking configuration (partial) before deployment.
eth1, no address, neutron_external_interface
eth1.40, external address, kolla_external_vip_interface

After deployment, I'd like to see this.
br-ex
  eth1
  eth1.40 tag 40
eth1.40 with external address

But actually, only eth1 is put on br-ex by Kolla Ansible.

Need eth1.40 on br-ex, because the external network is also one of the provider
networks. Need eth1 on br-ex, to support other provider networks (different VLANs).
It works fine when deploy with TripleO with os-net-config.

Is it supported by Kolla Ansible? It seems Kolla Ansible only puts one interface
(neutron_external_interface) on br-ex?

I know a few workarounds in case that's not supported, just want to confirm.

Thanks!
Tony



Danny Webb
Principal OpenStack Engineer
The Hut Group<http://www.thehutgroup.com/>

Tel:
Email: Danny.Webb at thehutgroup.com<mailto:Danny.Webb at thehutgroup.com>

For the purposes of this email, the "company" means The Hut Group Limited, a company registered in England and Wales (company number 6539496) whose registered office is at Fifth Floor, Voyager House, Chicago Avenue, Manchester Airport, M90 3DQ and/or any of its respective subsidiaries.

Confidentiality Notice
This e-mail is confidential and intended for the use of the named recipient only. If you are not the intended recipient please notify us by telephone immediately on +44(0)1606 811888 or return it to us by e-mail. Please then delete it from your system and note that any use, dissemination, forwarding, printing or copying is strictly prohibited. Any views or opinions are solely those of the author and do not necessarily represent those of the company.

Encryptions and Viruses
Please note that this e-mail and any attachments have not been encrypted. They may therefore be liable to be compromised. Please also note that it is your responsibility to scan this e-mail and any attachments for viruses. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or confidentiality in relation to transmissions sent by e-mail.

Monitoring
Activity and use of the company's systems is monitored to secure its effective use and operation and for other lawful business purposes. Communications using these systems will also be monitored and may be recorded to secure effective use and operation and for other lawful business purposes.

hgvyjuv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220326/8c79834e/attachment.htm>

From tonyliu0592 at hotmail.com  Sat Mar 26 22:43:53 2022
From: tonyliu0592 at hotmail.com (Tony Liu)
Date: Sat, 26 Mar 2022 22:43:53 +0000
Subject: [kolla-ansible] OVS br-ex configuration for OVN SNAT gateway
 along with HAProxy
In-Reply-To: <LO2P265MB5773FA98E54E30F0CE83CC6F9A1B9@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
References: <CO6PR14MB52507C4B98FF62461D4A6A57BD1B9@CO6PR14MB5250.namprd14.prod.outlook.com>
 <LO2P265MB5773FA98E54E30F0CE83CC6F9A1B9@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <DM8PR14MB5256C5E0951BF0B8E64857A9BD1B9@DM8PR14MB5256.namprd14.prod.outlook.com>

Thank you Danny for pointing it out! I somehow missed it when going through doc.
Read it again, test and looked into playbook. It seems that's not what I need.

[1] doesn't add multiple interfaces onto one bridge. It actually adds one interface
onto one bridge, but there could be multiple pairs.
This is also confirmed by playbook [2].

Also, the limitation of [3] is an issue for me. 

Hopefully this can be supported in the future.

Thanks!
Tony
[1] https://docs.openstack.org/kolla-ansible/latest/reference/networking/neutron.html#example-multiple-interfaces
[2] https://opendev.org/openstack/kolla-ansible/src/commit/5dbcbda4751f3ac401693c919e6ad2c94f553d7a/ansible/roles/openvswitch/tasks/post-config.yml#L19
[3] https://docs.openstack.org/kolla-ansible/latest/reference/networking/neutron.html#example-shared-interface

________________________________________
From: Danny Webb <Danny.Webb at thehutgroup.com>
Sent: March 26, 2022 12:05 PM
To: Tony Liu; openstack-discuss
Subject: Re: [kolla-ansible] OVS br-ex configuration for OVN SNAT gateway along with HAProxy

<https://github.com/openstack/kolla-ansible/blob/79a5bf2bbe6d8b3509ace56c887baba4c79e61d5/doc/source/reference/networking/neutron.rst#example-multiple-interfaces>
Hi Tony,

Multiple interfaces can be configured as follows:

https://github.com/openstack/kolla-ansible/blob/master/doc/source/reference/networking/neutron.rst#example-multiple-interfaces

Danny
________________________________
From: Tony Liu <tonyliu0592 at hotmail.com>
Sent: 26 March 2022 05:02
To: openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: [kolla-ansible] OVS br-ex configuration for OVN SNAT gateway along with HAProxy

CAUTION: This email originates from outside THG

Hi,

My goal is to have OVN SNAT gateway (with OVS bridge) and HAProxy co-exist.
Here is the networking configuration (partial) before deployment.
eth1, no address, neutron_external_interface
eth1.40, external address, kolla_external_vip_interface

After deployment, I'd like to see this.
br-ex
  eth1
  eth1.40 tag 40
eth1.40 with external address

But actually, only eth1 is put on br-ex by Kolla Ansible.

Need eth1.40 on br-ex, because the external network is also one of the provider
networks. Need eth1 on br-ex, to support other provider networks (different VLANs).
It works fine when deploy with TripleO with os-net-config.

Is it supported by Kolla Ansible? It seems Kolla Ansible only puts one interface
(neutron_external_interface) on br-ex?

I know a few workarounds in case that's not supported, just want to confirm.

Thanks!
Tony



Danny Webb
Principal OpenStack Engineer
The Hut Group<http://www.thehutgroup.com/>

Tel:
Email: Danny.Webb at thehutgroup.com<mailto:Danny.Webb at thehutgroup.com>

For the purposes of this email, the "company" means The Hut Group Limited, a company registered in England and Wales (company number 6539496) whose registered office is at Fifth Floor, Voyager House, Chicago Avenue, Manchester Airport, M90 3DQ and/or any of its respective subsidiaries.

Confidentiality Notice
This e-mail is confidential and intended for the use of the named recipient only. If you are not the intended recipient please notify us by telephone immediately on +44(0)1606 811888 or return it to us by e-mail. Please then delete it from your system and note that any use, dissemination, forwarding, printing or copying is strictly prohibited. Any views or opinions are solely those of the author and do not necessarily represent those of the company.

Encryptions and Viruses
Please note that this e-mail and any attachments have not been encrypted. They may therefore be liable to be compromised. Please also note that it is your responsibility to scan this e-mail and any attachments for viruses. We do not, to the extent permitted by law, accept any liability (whether in contract, negligence or otherwise) for any virus infection and/or external compromise of security and/or confidentiality in relation to transmissions sent by e-mail.

Monitoring
Activity and use of the company's systems is monitored to secure its effective use and operation and for other lawful business purposes. Communications using these systems will also be monitored and may be recorded to secure effective use and operation and for other lawful business purposes.

hgvyjuv


From tonyliu0592 at hotmail.com  Sun Mar 27 01:02:54 2022
From: tonyliu0592 at hotmail.com (Tony Liu)
Date: Sun, 27 Mar 2022 01:02:54 +0000
Subject: [glance] import RBD image
Message-ID: <DM8PR14MB52568F0CF6DBAE3C06A0736DBD1C9@DM8PR14MB5256.namprd14.prod.outlook.com>

Hi,

There used to be a way to import RBD image with API v1, but not any more with v2.
Is there any other way to do that?
In case given QCOW2 image, It would be much faster and easier to convert it directly
to RBD image with RAW format, than convert it to RAW format on local file system and
upload the RAW image to Glance.


Thanks!
Tony


From arne.wiebalck at cern.ch  Sun Mar 27 15:43:16 2022
From: arne.wiebalck at cern.ch (Arne Wiebalck)
Date: Sun, 27 Mar 2022 17:43:16 +0200
Subject: [Ironic][Bare Metal SIG] Community Feedback Survey (1 minute)
Message-ID: <870961726.31831.1648395796384@cernmail.cern.ch>

Dear all,

As input for the PTG and to align priorities for the next cycle, the Ironic team is looking for
feedback from the community (users, operators, admins, deployers ... everyone interested
in bare metal really!).

So, if you have 1 minute, we would greatly appreciate your input by filling:

https://de.surveymonkey.com/r/XCR2TN5

If you have any additional input for the Ironic team, do not hesitate to reach out (via mail, on IRC,
or come along to the PTG!).

Thanks!
 Arne 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220327/845aa6c8/attachment.htm>

From katonalala at gmail.com  Mon Mar 28 09:20:26 2022
From: katonalala at gmail.com (Lajos Katona)
Date: Mon, 28 Mar 2022 11:20:26 +0200
Subject: [neutron] Week 13 meetings (starting from 28 March)
Message-ID: <CALg0jKkewpY7Lj39=MBdZjSyDbpUvR-cLXzwds1D=qpLsRr0Eg@mail.gmail.com>

Hi Neutrinos,
Let's cancel this week's Team and Drivers meeting as we have PTG next week
anyway.
See you next week during the PTG

Cheers
Lajos Katona (lajoskatona)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220328/bf993dc0/attachment.htm>

From thierry at openstack.org  Mon Mar 28 09:33:06 2022
From: thierry at openstack.org (Thierry Carrez)
Date: Mon, 28 Mar 2022 11:33:06 +0200
Subject: [largescale-sig] Next meeting: Mar 30th, 15utc
Message-ID: <fea369e2-f99b-e2dd-524e-2bbd75a4f831@openstack.org>

Hi everyone,

The Large Scale SIG will be meeting this Wednesday in 
#openstack-operators on OFTC IRC, at 15UTC.

With recent DST changes, you should doublecheck how that time translates 
locally at:
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20220330T15

Feel free to add topics to the agenda:
https://etherpad.openstack.org/p/large-scale-sig-meeting

Regards,

-- 
Thierry Carrez


From skaplons at redhat.com  Mon Mar 28 09:37:30 2022
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Mon, 28 Mar 2022 11:37:30 +0200
Subject: [neutron] CI meetings next 2 weeks
Message-ID: <12084951.O9o76ZdvQC@p1>

Hi,

I can't chair CI meeting this week (29.03) because of some personal appointment in the same time.
Next week (5.04) there is PTG so lets cancel CI meeting this and next week.
See You on the CI meeting after the PTG week, on Tuesday 12.04

-- 
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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220328/094e3cd5/attachment.sig>

From ekuvaja at redhat.com  Mon Mar 28 11:13:54 2022
From: ekuvaja at redhat.com (Erno Kuvaja)
Date: Mon, 28 Mar 2022 12:13:54 +0100
Subject: [glance] import RBD image
In-Reply-To: <DM8PR14MB52568F0CF6DBAE3C06A0736DBD1C9@DM8PR14MB5256.namprd14.prod.outlook.com>
References: <DM8PR14MB52568F0CF6DBAE3C06A0736DBD1C9@DM8PR14MB5256.namprd14.prod.outlook.com>
Message-ID: <CAKwVDDOsqMzw0kWN2+FY32NBKcQMLpbwiJMtCJ4W7Qva5F2=Bw@mail.gmail.com>

On Sun, Mar 27, 2022 at 2:10 AM Tony Liu <tonyliu0592 at hotmail.com> wrote:

> Hi,
>
> There used to be a way to import RBD image with API v1, but not any more
> with v2.
> Is there any other way to do that?
> In case given QCOW2 image, It would be much faster and easier to convert
> it directly
> to RBD image with RAW format, than convert it to RAW format on local file
> system and
> upload the RAW image to Glance.
>
>
> Thanks!
> Tony
>
>
> Hi Tony,

There is an image-conversion plugin for Interoperable Image Import for
that. Please see
https://docs.openstack.org/glance/latest/admin/interoperable-image-import.html
for the documentation.

jokke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220328/7d4ac288/attachment.htm>

From mbultel at redhat.com  Mon Mar 28 12:29:55 2022
From: mbultel at redhat.com (Mathieu Bultel)
Date: Mon, 28 Mar 2022 14:29:55 +0200
Subject: [TripleO] Propositing Jiri Podivin as TripleO (Validation Framework)
 core
Message-ID: <CAKwUe8kynak8TOcxC6c88K23cYY=0Wsu8DfHS5s2oVNCtB13Kg@mail.gmail.com>

Hi folks,

I would like to propose Jiri Podivin as TripleO Validation Framework core.
Jirka has been part of the TripleO organization for some significant time
now and his contribution has grown a lot during the last few months.
He is submitting highly valuable reviews and has now a strong knowledge
around the TripleO Validations Framework areas, the Python framework but
also in the CI (TripleO and upstream generic) and more general projects.

I think getting him as a core reviewer for the Validations
repositories will be very good for us.

Feel free to send your feedback, if there is no objection until next week,
I propose to add him to the list with limited core votes to the VF repo [1].

Thank you,

KR,
Mathieu (matbu)

[1] openstack/validations-libs openstack/validations-common
openstack/tripleo-validations and eventually the Validation related code in
openstack/python-tripleoclient.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220328/42fce2e2/attachment.htm>

From johfulto at redhat.com  Mon Mar 28 12:36:27 2022
From: johfulto at redhat.com (John Fulton)
Date: Mon, 28 Mar 2022 08:36:27 -0400
Subject: [TripleO] Propositing Jiri Podivin as TripleO (Validation
 Framework) core
In-Reply-To: <CAKwUe8kynak8TOcxC6c88K23cYY=0Wsu8DfHS5s2oVNCtB13Kg@mail.gmail.com>
References: <CAKwUe8kynak8TOcxC6c88K23cYY=0Wsu8DfHS5s2oVNCtB13Kg@mail.gmail.com>
Message-ID: <CAE66OMDAHv851YHr4Lo2Pm1xqwTYYs7LpP8XaMVcG6VH+oXBQw@mail.gmail.com>

On Mon, Mar 28, 2022 at 8:32 AM Mathieu Bultel <mbultel at redhat.com> wrote:
>
> Hi folks,
>
> I would like to propose Jiri Podivin as TripleO Validation Framework core.
> Jirka has been part of the TripleO organization for some significant time now and his contribution has grown a lot during the last few months.
> He is submitting highly valuable reviews and has now a strong knowledge around the TripleO Validations Framework areas, the Python framework but also in the CI (TripleO and upstream generic) and more general projects.
>
> I think getting him as a core reviewer for the Validations repositories will be very good for us.
>
> Feel free to send your feedback, if there is no objection until next week, I propose to add him to the list with limited core votes to the VF repo [1].
>
> Thank you,
>
> KR,
> Mathieu (matbu)

+1

>
> [1] openstack/validations-libs openstack/validations-common openstack/tripleo-validations and eventually the Validation related code in openstack/python-tripleoclient.



From cjeanner at redhat.com  Mon Mar 28 13:03:20 2022
From: cjeanner at redhat.com (=?UTF-8?Q?C=c3=a9dric_Jeanneret?=)
Date: Mon, 28 Mar 2022 15:03:20 +0200
Subject: [TripleO] Propositing Jiri Podivin as TripleO (Validation
 Framework) core
In-Reply-To: <CAKwUe8kynak8TOcxC6c88K23cYY=0Wsu8DfHS5s2oVNCtB13Kg@mail.gmail.com>
References: <CAKwUe8kynak8TOcxC6c88K23cYY=0Wsu8DfHS5s2oVNCtB13Kg@mail.gmail.com>
Message-ID: <98fe2e34-2db4-f139-24f2-a2b677dca688@redhat.com>

+1

On 3/28/22 14:29, Mathieu Bultel wrote:
> Hi folks,
> 
> I would like to propose Jiri Podivin as TripleO Validation Framework core.
> Jirka has been part of the TripleO organization for some significant 
> time now and his contribution has grown a lot during the last few months.
> He is submitting highly valuable reviews and has now a strong knowledge 
> around the TripleO Validations Framework areas, the Python framework but 
> also in the CI (TripleO and upstream generic) and more general projects.
> 
> I think getting him as a core reviewer for the Validations 
> repositories?will be very good for us.
> 
> Feel free to send your feedback, if there is no objection until next 
> week, I propose to add him to the list with limited core votes to the VF 
> repo [1].
> 
> Thank you,
> 
> KR,
> Mathieu (matbu)
> 
> [1] openstack/validations-libs openstack/validations-common 
> openstack/tripleo-validations and eventually the Validation related code 
> in openstack/python-tripleoclient.

-- 
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: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220328/d89c0205/attachment.sig>

From akekane at redhat.com  Mon Mar 28 13:56:17 2022
From: akekane at redhat.com (Abhishek Kekane)
Date: Mon, 28 Mar 2022 19:26:17 +0530
Subject: [glance] Zed PTG schedule
Message-ID: <CALOt+STtZkeVPN1bbVYQybWAeQA=MesQX8=9pgtPRuQi_ZxEsg@mail.gmail.com>

Hello All,
Greetings!!!

Zed PTG is going to start next week and if you haven't already registered,
please do so as soon as possible [1].

I have created an etherpad [2] and also added day wise topics along with
timings we are going to discuss. Kindly let me know if you have any
concerns with allotted time slots. We also have one slot open on Wednesday
and Friday is kept reserved for any unplanned discussions. So please feel
free to add your topics if you still haven't added yet.

As a reminder, these are the time slots for our discussion.

Tuesday 5 April 2022
1400 UTC to 1700 UTC

Wednesday 6 April 2022
1400 UTC to 1700 UTC

Thursday 7 April 2022
1400 UTC to 1700 UTC

Friday 8 April 2022
1400 UTC to 1700 UTC

NOTE:
At the moment we don't have any sessions scheduled on Friday, if there are
any last moment request(s)/topic(s) we will discuss them on Friday else we
will conclude our PTG on Thursday 7th April.

We will be using bluejeans for our discussion, kindly try to use it once
before the actual discussion. The meeting URL is mentioned in etherpad [2]
and will be the same throughout the PTG.

[1] https://openinfra-ptg.eventbrite.com/
[2] https://etherpad.opendev.org/p/zed-glance-ptg

Thank you,

Abhishek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220328/4bc2015b/attachment.htm>

From anuragsinghrajawat22 at gmail.com  Sun Mar 27 06:23:54 2022
From: anuragsinghrajawat22 at gmail.com (Anurag Singh Rajawat)
Date: Sun, 27 Mar 2022 11:53:54 +0530
Subject: [glance] Outreachy 2022 Contribution
Message-ID: <CANr7emHYCPnOhC6mMp+KsqBD6eenMbq6Hk8HZP=bL7HQ_K_aAQ@mail.gmail.com>

Dear Openstack Team,

My name is Anurag Rajawat and I am selected as an outreachy initial
applicant.

I am highly interested in the project: "*Add mypy support in OpenStack
glance".*
I would appreciate it if you could guide me on how to begin contributing to
your organization and starting on a current issue. And I am eager to become
a part of your community.

Thank you so much for taking the time to view this email.

Sincerely,
Anurag
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220327/c0f62f53/attachment-0001.htm>

From bartosz.rabiega at ovhcloud.com  Mon Mar 28 09:20:28 2022
From: bartosz.rabiega at ovhcloud.com (bartosz.rabiega at ovhcloud.com)
Date: Mon, 28 Mar 2022 11:20:28 +0200
Subject: Cinder - easy to hit RecursionError with complex config formulas
Message-ID: <2d45281c-7283-88c6-07bf-850c4d009f6e@ovhcloud.com>

Hello,

I wanted to share something I've recently discovered - there is a 
strange issue with cinder evaluating complex configuration formulas.

For example when using complex goodness_function it's quite easy to hit:
     ERROR cinder.scheduler.weights.goodness maximum recursion depth 
exceeded: RecursionError: maximum recursion depth exceeded

I did some tests to find the root cause. It seems that pyparsing module 
does deep recursive parsing quite a lot (default recursion limit is 1000).

Not sure how to solve it but it would be nice to at least have a warning 
in the docs.
Results and methodology below.

Tests were done using following code snippet
-------------------------------------------
from cinder.scheduler.evaluator.evaluator import evaluate
import sys

formulas = [
     "1",
     "1 + 1",
     "max(1, 2, 3)",
     "max(1 + (10 / 20), 2, 3)",
     "(1 + max(1 + (10 / 20), 2, 3)) / 100",
     "((1 + max(1 + (10 / 20), 2, 3)) / 100) + stats.total_capacity_gb",
     "(((1 + max(1 + (10 / 20), 2, 3)) / 100) + stats.total_capacity_gb) 
/ 100",
]

stats = {
     'allocated_capacity_gb': 50000,
     'total_capacity_gb': 60000,
     'free_capacity_gb': 10000,
}

for f in formulas:
     for i in range(10, 2000, 10):
         sys.setrecursionlimit(i)
         try:
             res = evaluate(f, stats=stats)
             print(f"{i}: {f}")
             break
         except RecursionError:
             pass


Test results
--------------------------------
Cinder 14.3.1, pyparsing<3.0
210: 1
210: 1 + 1
450: max(1, 2, 3)
600: max(1 + (10 / 20), 2, 3)
790: (1 + max(1 + (10 / 20), 2, 3)) / 100
980: ((1 + max(1 + (10 / 20), 2, 3)) / 100) + stats.total_capacity_gb
1160: (((1 + max(1 + (10 / 20), 2, 3)) / 100) + stats.total_capacity_gb) 
/ 100

Cinder 16.4.2, pyparsing<3.0
220: 1
220: 1 + 1
450: max(1, 2, 3)
610: max(1 + (10 / 20), 2, 3)
790: (1 + max(1 + (10 / 20), 2, 3)) / 100
980: ((1 + max(1 + (10 / 20), 2, 3)) / 100) + stats.total_capacity_gb
1170: (((1 + max(1 + (10 / 20), 2, 3)) / 100) + stats.total_capacity_gb) 
/ 100

Cinder 19.1.0, pyparsing<3.0
220: 1
220: 1 + 1
450: max(1, 2, 3)
610: max(1 + (10 / 20), 2, 3)
790: (1 + max(1 + (10 / 20), 2, 3)) / 100
980: ((1 + max(1 + (10 / 20), 2, 3)) / 100) + stats.total_capacity_gb
1170: (((1 + max(1 + (10 / 20), 2, 3)) / 100) + stats.total_capacity_gb) 
/ 100


BR


From pedro.alvarez at softiron.com  Mon Mar 28 14:47:19 2022
From: pedro.alvarez at softiron.com (Pedro Alvarez)
Date: Mon, 28 Mar 2022 15:47:19 +0100
Subject: [sdk] Fixing role assignment for groups on a domain different than
 default
Message-ID: <087bd9b4-f65f-e1e9-b1fe-ed827bfae29f@softiron.com>

Hi all,

Some time ago I discovered that I wasn't able to add groups as members 
of a project (when not in the default domain) using 
"openstack.cloud.role_assignment".

I spent some time debugging and figured what was the issue, and that a 
solution was already in place for "users", and not "groups".

I also noticed that the master branch had all this part of the codebase 
rewritten, and probably the bug doesn't exist in there, but I believe 
that version of the sdk won't work with Xena. Additionally just noticed 
that the stable/yoga branch also has the issue.

So, I'm sending a patch to fix this issue, hoping the next tag/release 
of openstacksdk could have the fix.


You can find them here:
 
https://review.opendev.org/q/topic:pedro%252Ffix-group-assignment-on-domain

My guess is that the only relevant one would be the one for 
'stable/yoga' and I can drop the other. Also I'm assuming that Zuul is 
taking its time to run CI, and I'll need to update some unit tests 
before it can be merged.

Just wanted to know your thoughts before I finish with the tests.

Thanks,
Pedro.


PS: An example of the current issue:

The full traceback is:
   File 
"/tmp/ansible_openstack.cloud.role_assignment_payload_hcrpn6hu/ansible_openstack.cloud.role_assignment_payload.zip/ansible_collections/openstack/cloud/plugins/module_utils/openstack.py", 
line 407, in __call__
     results = self.run()
   File 
"/tmp/ansible_openstack.cloud.role_assignment_payload_hcrpn6hu/ansible_openstack.cloud.role_assignment_payload.zip/ansible_collections/openstack/cloud/plugins/modules/role_assignment.py", 
line 178, in run
   File 
"/home/ollivander/.local/lib/python3.9/site-packages/openstack/cloud/_identity.py", 
line 1379, in grant_role
     raise exc.OpenStackCloudException(
failed: [localhost] (item={'name': 'sa', 'groups': ['openstack-sa', 
'openstack-pe', 'openstack-technology']}) => {
     "ansible_facts": {
         "discovered_interpreter_python": "/usr/bin/python3"
     },
     "ansible_loop_var": "item",
     "changed": false,
     "extra_data": {
         "data": null,
         "details": "None",
         "response": "None"
     },
     "invocation": {
         "module_args": {
             "api_timeout": null,
             "auth": null,
             "auth_type": null,
             "availability_zone": null,
             "ca_cert": null,
             "client_cert": null,
             "client_key": null,
             "domain": "LDAP",
             "group": "openstack-pe",
             "interface": "public",
             "project": "sa",
             "region_name": null,
             "role": "member",
             "state": "present",
             "timeout": 180,
             "user": null,
             "validate_certs": null,
             "wait": true
         }
     },
     "item": {
         "groups": [
             "openstack-sa",
             "openstack-pe",
             "openstack-technology"
         ],
         "name": "sa"
     },
     "msg": "Must specify either a user or a group"
}


From rosmaita.fossdev at gmail.com  Mon Mar 28 14:57:46 2022
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Mon, 28 Mar 2022 10:57:46 -0400
Subject: [cinder] reminder: this week's meeting in video+IRC
Message-ID: <9267dc05-c28f-c9e1-b737-c81c5eb9c972@gmail.com>

Quick reminder that this week's Cinder team meeting on Wednesday 30 
March, being the final meeting of the month, will be held in both 
videoconference and IRC at the regularly scheduled time of 1400 UTC.

Given that this is the final meeting of the Yoga development cycle, 
we're going to do a retrospective during the meeting.  It would be 
helpful to get things rolling if you filled out one (or both) of the 
following 3 question forms:

Cinder Wallaby-Xena-Yoga Retrospective
- https://rosmaita.wufoo.com/forms/m1gc1dfo1s42947/

Cinder W-X-Y Retrospective Survey for Drivers
- https://rosmaita.wufoo.com/forms/zab0fdr1dg4nwo/

As a reminder, these are the video meeting rules we've agreed to:

* Everyone will keep IRC open during the meeting.

* We'll take notes in IRC to leave a record similar to what
   we have for our regular IRC meetings.

* Some people are more comfortable communicating in written
   English. So at any point, any attendee may request that the
   discussion of the current topic be conducted entirely in IRC.

* The meeting will be recorded.

connection info: https://bluejeans.com/3228528973
meeting agenda: https://etherpad.opendev.org/p/cinder-yoga-meetings


cheers,
brian


From bence.romsics at gmail.com  Mon Mar 28 15:23:17 2022
From: bence.romsics at gmail.com (Bence Romsics)
Date: Mon, 28 Mar 2022 17:23:17 +0200
Subject: [neutron] deputy report late
Message-ID: <CAHeS+38r6jJTXZ3pvgVOaM4THSabOxv0knwuMusUkJ+77wxhAw@mail.gmail.com>

Hi Team,

I miscalculated a bit about how much time I have early this week and did
not have time to compile the deputy report. Sorry for that. Later this week
I'll catch up with the bugs still belonging to my week and make sure to
send out the report so it can be discussed on next week's meeting.

Cheers,
Bence
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220328/86fc9726/attachment.htm>

From tonyliu0592 at hotmail.com  Mon Mar 28 17:16:17 2022
From: tonyliu0592 at hotmail.com (Tony Liu)
Date: Mon, 28 Mar 2022 17:16:17 +0000
Subject: [glance] import RBD image
In-Reply-To: <CAKwVDDOsqMzw0kWN2+FY32NBKcQMLpbwiJMtCJ4W7Qva5F2=Bw@mail.gmail.com>
References: <DM8PR14MB52568F0CF6DBAE3C06A0736DBD1C9@DM8PR14MB5256.namprd14.prod.outlook.com>
 <CAKwVDDOsqMzw0kWN2+FY32NBKcQMLpbwiJMtCJ4W7Qva5F2=Bw@mail.gmail.com>
Message-ID: <DM8PR14MB52562054AAB94FD1A0E3CA7EBD1D9@DM8PR14MB5256.namprd14.prod.outlook.com>

Thank you Erno for pointing it out!
I wonder if I can get a bit more clarifications.

```
[image_import_opts]
image_import_plugins = ['image_decompression', 'image_conversion']

[image_conversion]
output_format = raw
```
For example, with the above configuration and web-download method,
to download image.qcow2.gz2 (2GB) and create a raw image (40GB).
The uncompressed image.qcow2 is 10GB.
My understanding is that, image.qcow2.gz2 is downloaded and takes 2GB space.
Then it's decompressed to image.qcow2, and 12GB space is used now.
Then it's converted to raw image to Ceph directly. So the max space required for
this process is 12GB. Is that correct?

Regarding to recommended local staging directory, doc says "you must configure
each worker with the URL by which the other workers can reach it directly".
Is that because the image processing (download, convert, upload) may be split to
different workers? I would expect the whole process/task is tied to one worker,
because the process is triggered by single request from client. It would be good
to get some clarifications on how this works and why workers need to connect
to each other during image processing.

For worker_self_reference_url, would "http://<worker IP>:<glance-api port>" work?


Thanks!
Tony
________________________________________
From: Erno Kuvaja <ekuvaja at redhat.com>
Sent: March 28, 2022 04:13 AM
To: Tony Liu
Cc: openstack-discuss
Subject: Re: [glance] import RBD image

On Sun, Mar 27, 2022 at 2:10 AM Tony Liu <tonyliu0592 at hotmail.com<mailto:tonyliu0592 at hotmail.com>> wrote:
Hi,

There used to be a way to import RBD image with API v1, but not any more with v2.
Is there any other way to do that?
In case given QCOW2 image, It would be much faster and easier to convert it directly
to RBD image with RAW format, than convert it to RAW format on local file system and
upload the RAW image to Glance.


Thanks!
Tony


Hi Tony,

There is an image-conversion plugin for Interoperable Image Import for that. Please see https://docs.openstack.org/glance/latest/admin/interoperable-image-import.html for the documentation.

jokke


From fungi at yuggoth.org  Mon Mar 28 18:28:45 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 28 Mar 2022 18:28:45 +0000
Subject: [magnum][murano][release][sahara][tc][trove][zaqar] Emergency bypass
 reviewer/PTL/liaison approval for Yoga release fixes
Message-ID: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>

A number of teams seem not to have noticed that their tests (and
possibly the services themselves) were broken by the removal[*] of
the "tenant" argument from RequestContext objects in oslo.context
4.0.0 released on February 3, 2022.

As we're at a little over a day left before we need to finalize the
Yoga release, I'm seeking permission from the TC on behalf of the
OpenStack Release Managers to bypass normal core reviewer, PTL and
release liaison approval processes in order to approve any remaining
changes for official OpenStack projects necessary for this
transition, and to produce new release candidates with those fixes
included as necessary.

[*] https://review.opendev.org/815938
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220328/772c0329/attachment.sig>

From gmann at ghanshyammann.com  Mon Mar 28 18:43:05 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 28 Mar 2022 13:43:05 -0500
Subject: [magnum][murano][release][sahara][tc][trove][zaqar] Emergency
 bypass reviewer/PTL/liaison approval for Yoga release fixes
In-Reply-To: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
References: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
Message-ID: <17fd1d6bbbf.c30ef1e5114563.3221141952654135338@ghanshyammann.com>

 ---- On Mon, 28 Mar 2022 13:28:45 -0500 Jeremy Stanley <fungi at yuggoth.org> wrote ----
 > A number of teams seem not to have noticed that their tests (and
 > possibly the services themselves) were broken by the removal[*] of
 > the "tenant" argument from RequestContext objects in oslo.context
 > 4.0.0 released on February 3, 2022.
 > 
 > As we're at a little over a day left before we need to finalize the
 > Yoga release, I'm seeking permission from the TC on behalf of the
 > OpenStack Release Managers to bypass normal core reviewer, PTL and
 > release liaison approval processes in order to approve any remaining
 > changes for official OpenStack projects necessary for this
 > transition, and to produce new release candidates with those fixes
 > included as necessary.

Thanks, Fungi and the release team for bringing it and taking care of those projects
release. 

We called the TC emergency meeting to discuss it and agreed on the above proposal to
allow fungi to approve the fixes and proceed on their release.

- https://meetings.opendev.org/meetings/tc/2022/tc.2022-03-28-18.07.log.html

This is something those project's PTLs/Release liaisons (who were recently appointed based on
their request) should give serious thought to this situation and take care of it at least during the
release time that their code/tests are in working state. 

-gmann


 > 
 > [*] https://review.opendev.org/815938
 > -- 
 > Jeremy Stanley
 > 


From ltoscano at redhat.com  Mon Mar 28 19:23:22 2022
From: ltoscano at redhat.com (Luigi Toscano)
Date: Mon, 28 Mar 2022 21:23:22 +0200
Subject: [magnum][murano][release][sahara][tc][trove][zaqar] Emergency
 bypass reviewer/PTL/liaison approval for Yoga release fixes
In-Reply-To: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
References: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
Message-ID: <2452114.9o76ZdvQCi@whitebase.usersys.redhat.com>

On Monday, 28 March 2022 20:28:45 CEST Jeremy Stanley wrote:
> A number of teams seem not to have noticed that their tests (and
> possibly the services themselves) were broken by the removal[*] of
> the "tenant" argument from RequestContext objects in oslo.context
> 4.0.0 released on February 3, 2022.
> 
> As we're at a little over a day left before we need to finalize the
> Yoga release, I'm seeking permission from the TC on behalf of the
> OpenStack Release Managers to bypass normal core reviewer, PTL and
> release liaison approval processes in order to approve any remaining
> changes for official OpenStack projects necessary for this
> transition, and to produce new release candidates with those fixes
> included as necessary.
> 
> [*] https://review.opendev.org/815938

I think the relevant patches were merged last week in sahara, both master and 
yoga.
https://review.opendev.org/q/topic:story%252F2009921

-- 
Luigi




From strigazi at gmail.com  Mon Mar 28 19:32:54 2022
From: strigazi at gmail.com (Spyros Trigazis)
Date: Mon, 28 Mar 2022 21:32:54 +0200
Subject: [magnum][murano][release][sahara][tc][trove][zaqar] Emergency
 bypass reviewer/PTL/liaison approval for Yoga release fixes
In-Reply-To: <2452114.9o76ZdvQCi@whitebase.usersys.redhat.com>
References: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
 <2452114.9o76ZdvQCi@whitebase.usersys.redhat.com>
Message-ID: <CAB9QTQbf_H6G7mnRadfkSzU0nCkcMD-2xJ8Cv-fkXjFKWFZGPw@mail.gmail.com>

Same for magnum, 10 days ago.
https://review.opendev.org/q/I10daa22b614aab456b837c03278eb04da0355ff7

Merged in stable/yoga and tagged 14.0.0.0rc2.

Am I missing something?

Spyros

On Mon, Mar 28, 2022 at 9:27 PM Luigi Toscano <ltoscano at redhat.com> wrote:

> On Monday, 28 March 2022 20:28:45 CEST Jeremy Stanley wrote:
> > A number of teams seem not to have noticed that their tests (and
> > possibly the services themselves) were broken by the removal[*] of
> > the "tenant" argument from RequestContext objects in oslo.context
> > 4.0.0 released on February 3, 2022.
> >
> > As we're at a little over a day left before we need to finalize the
> > Yoga release, I'm seeking permission from the TC on behalf of the
> > OpenStack Release Managers to bypass normal core reviewer, PTL and
> > release liaison approval processes in order to approve any remaining
> > changes for official OpenStack projects necessary for this
> > transition, and to produce new release candidates with those fixes
> > included as necessary.
> >
> > [*] https://review.opendev.org/815938
>
> I think the relevant patches were merged last week in sahara, both master
> and
> yoga.
> https://review.opendev.org/q/topic:story%252F2009921
>
> --
> Luigi
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220328/ec25686a/attachment.htm>

From fungi at yuggoth.org  Mon Mar 28 19:38:30 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 28 Mar 2022 19:38:30 +0000
Subject: [magnum][murano][release][sahara][tc][trove][zaqar] Emergency
 bypass reviewer/PTL/liaison approval for Yoga release fixes
In-Reply-To: <2452114.9o76ZdvQCi@whitebase.usersys.redhat.com>
References: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
 <2452114.9o76ZdvQCi@whitebase.usersys.redhat.com>
Message-ID: <20220328193829.bv33ahhwdfh6dojh@yuggoth.org>

On 2022-03-28 21:23:22 +0200 (+0200), Luigi Toscano wrote:
[...]
> I think the relevant patches were merged last week in sahara, both master and 
> yoga.
> https://review.opendev.org/q/topic:story%252F2009921

Yes, in Sahara's case, it looks like the release request for a new
RC was waiting for PTL or release liaison approval:
https://review.opendev.org/835037

It seems to have received no feedback by the final RC deadline and
was therefore abandoned initially, but has been restored since it
was pointed out by downstream distro package maintainers that the
test for Sahara were still failing on the existing release
candidate.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220328/55b6e0aa/attachment.sig>

From fungi at yuggoth.org  Mon Mar 28 19:42:28 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 28 Mar 2022 19:42:28 +0000
Subject: [magnum][murano][release][sahara][tc][trove][zaqar] Emergency
 bypass reviewer/PTL/liaison approval for Yoga release fixes
In-Reply-To: <CAB9QTQbf_H6G7mnRadfkSzU0nCkcMD-2xJ8Cv-fkXjFKWFZGPw@mail.gmail.com>
References: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
 <2452114.9o76ZdvQCi@whitebase.usersys.redhat.com>
 <CAB9QTQbf_H6G7mnRadfkSzU0nCkcMD-2xJ8Cv-fkXjFKWFZGPw@mail.gmail.com>
Message-ID: <20220328194228.bo7c2pcsropsgzzl@yuggoth.org>

On 2022-03-28 21:32:54 +0200 (+0200), Spyros Trigazis wrote:
> Same for magnum, 10 days ago.
> https://review.opendev.org/q/I10daa22b614aab456b837c03278eb04da0355ff7
> 
> Merged in stable/yoga and tagged 14.0.0.0rc2.
> 
> Am I missing something?
[...]

Nope, it was crossed off the list shortly after I sent my initial
message, since it looks like the fix did end up in RC2 on Friday
(the error reports the Release Managers were working from were from
earlier in the week).
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220328/fe1ac6ad/attachment.sig>

From elod.illes at est.tech  Mon Mar 28 19:43:13 2022
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Mon, 28 Mar 2022 21:43:13 +0200
Subject: [magnum][murano][release][sahara][tc][trove][zaqar] Emergency
 bypass reviewer/PTL/liaison approval for Yoga release fixes
In-Reply-To: <2452114.9o76ZdvQCi@whitebase.usersys.redhat.com>
References: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
 <2452114.9o76ZdvQCi@whitebase.usersys.redhat.com>
Message-ID: <90bb4857-e247-c18c-65ec-5ec2c06e4188@est.tech>

Indeed, the patches are merged, unfortunately the generated release 
patch was abandoned as no replies came from release liaisons to continue 
with it. The release patch is now restored:

https://review.opendev.org/c/openstack/releases/+/835037

El?d

On 2022. 03. 28. 21:23, Luigi Toscano wrote:
> On Monday, 28 March 2022 20:28:45 CEST Jeremy Stanley wrote:
>> A number of teams seem not to have noticed that their tests (and
>> possibly the services themselves) were broken by the removal[*] of
>> the "tenant" argument from RequestContext objects in oslo.context
>> 4.0.0 released on February 3, 2022.
>>
>> As we're at a little over a day left before we need to finalize the
>> Yoga release, I'm seeking permission from the TC on behalf of the
>> OpenStack Release Managers to bypass normal core reviewer, PTL and
>> release liaison approval processes in order to approve any remaining
>> changes for official OpenStack projects necessary for this
>> transition, and to produce new release candidates with those fixes
>> included as necessary.
>>
>> [*] https://review.opendev.org/815938
> I think the relevant patches were merged last week in sahara, both master and
> yoga.
> https://review.opendev.org/q/topic:story%252F2009921
>

From elod.illes at est.tech  Mon Mar 28 19:45:41 2022
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Mon, 28 Mar 2022 21:45:41 +0200
Subject: [magnum][murano][release][sahara][tc][trove][zaqar] Emergency
 bypass reviewer/PTL/liaison approval for Yoga release fixes
In-Reply-To: <CAB9QTQbf_H6G7mnRadfkSzU0nCkcMD-2xJ8Cv-fkXjFKWFZGPw@mail.gmail.com>
References: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
 <2452114.9o76ZdvQCi@whitebase.usersys.redhat.com>
 <CAB9QTQbf_H6G7mnRadfkSzU0nCkcMD-2xJ8Cv-fkXjFKWFZGPw@mail.gmail.com>
Message-ID: <07b1a9a3-f4f1-9605-fd96-deddb8405ba8@est.tech>

Sorry, it seems there were some false alarms. Magnum seems to be OK 
regarding the mentioned change.

El?d

On 2022. 03. 28. 21:32, Spyros Trigazis wrote:
> Same for magnum, 10 days ago.
> https://review.opendev.org/q/I10daa22b614aab456b837c03278eb04da0355ff7
>
> Merged in stable/yoga and tagged 14.0.0.0rc2.
>
> Am I missing something?
>
> Spyros
>
> On Mon, Mar 28, 2022 at 9:27 PM Luigi Toscano <ltoscano at redhat.com> wrote:
>
>     On Monday, 28 March 2022 20:28:45 CEST Jeremy Stanley wrote:
>     > A number of teams seem not to have noticed that their tests (and
>     > possibly the services themselves) were broken by the removal[*] of
>     > the "tenant" argument from RequestContext objects in oslo.context
>     > 4.0.0 released on February 3, 2022.
>     >
>     > As we're at a little over a day left before we need to finalize the
>     > Yoga release, I'm seeking permission from the TC on behalf of the
>     > OpenStack Release Managers to bypass normal core reviewer, PTL and
>     > release liaison approval processes in order to approve any remaining
>     > changes for official OpenStack projects necessary for this
>     > transition, and to produce new release candidates with those fixes
>     > included as necessary.
>     >
>     > [*] https://review.opendev.org/815938
>
>     I think the relevant patches were merged last week in sahara, both
>     master and
>     yoga.
>     https://review.opendev.org/q/topic:story%252F2009921
>
>     -- 
>     Luigi
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220328/903f23d9/attachment.htm>

From fungi at yuggoth.org  Mon Mar 28 19:46:26 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Mon, 28 Mar 2022 19:46:26 +0000
Subject: [magnum][murano][release][sahara][tc][trove][zaqar] Emergency
 bypass reviewer/PTL/liaison approval for Yoga release fixes
In-Reply-To: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
References: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
Message-ID: <20220328194626.pomgewvd4t73n3fw@yuggoth.org>

On 2022-03-28 18:28:45 +0000 (+0000), Jeremy Stanley wrote:
> A number of teams seem not to have noticed that their tests (and
> possibly the services themselves) were broken by the removal[*] of
> the "tenant" argument from RequestContext objects in oslo.context
> 4.0.0 released on February 3, 2022.
[...]

Since this initial list was assembled, we've been able to cross
Magnum and Zaqar off the list as already fixed or affected by
unrelated issues.

Note that some projects were included because they did not
acknowledge release requests with the fixes, so while they may have
patches already merged in stable/yoga, the tags slated for inclusion
in the release did not cover those fixes. In such cases, the Release
Managers are seeking to approve pending release requests in order to
make sure those fixes end up in the coordinated release on
Wednesday.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220328/9f3e9016/attachment.sig>

From tonyliu0592 at hotmail.com  Tue Mar 29 01:33:22 2022
From: tonyliu0592 at hotmail.com (Tony Liu)
Date: Tue, 29 Mar 2022 01:33:22 +0000
Subject: [keystone] get project info with username and password only?
Message-ID: <DM8PR14MB5256E10838A338DD4842CE30BD1E9@DM8PR14MB5256.namprd14.prod.outlook.com>

Hi,

Is there any way to know which project(s) a non-admin user is assigned to by
username and password only? Or it can only be found out by admin user?
The intention is to get the project-scoped token by username and password.

Another thing interesting, when tried unscoped auth with Train and Xena, no project
info or catalog returned. This is expected. But when tried the same unscoped auth with
Ussuri, project info and catalog are returned. This is not expected. Any clues how this
could happen? Or how I can look into it?


Thanks!
Tony


From yasufum.o at gmail.com  Tue Mar 29 02:23:49 2022
From: yasufum.o at gmail.com (Yasufumi Ogawa)
Date: Tue, 29 Mar 2022 11:23:49 +0900
Subject: [tacker] Zed PTG schedule
Message-ID: <e01cfe88-e136-1efb-e7d2-ee147484db9a@gmail.com>

Hi everyone,

The next vPTG will be held on 4-8 April and I've reserved rooms 6-8 UTC 
from 5th to 8th Apr. If you have any suggestion, add your topic on the 
etherpad[1]. Please don't forget to register youself before joining[2].

[1] https://etherpad.opendev.org/p/tacker-zed-ptg
[2] https://openinfra-ptg.eventbrite.com/

Cheers,
Yasufumi


From fungi at yuggoth.org  Tue Mar 29 02:58:39 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 29 Mar 2022 02:58:39 +0000
Subject: [murano][oslo][release][tc] Emergency bypass
 reviewer/PTL/liaison approval for Yoga release fixes
In-Reply-To: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
References: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
Message-ID: <20220329025838.aqryk7olbubellqr@yuggoth.org>

On 2022-03-28 18:28:45 +0000 (+0000), Jeremy Stanley wrote:
> A number of teams seem not to have noticed that their tests (and
> possibly the services themselves) were broken by the removal[*] of
> the "tenant" argument from RequestContext objects in oslo.context
> 4.0.0 released on February 3, 2022.
> 
> As we're at a little over a day left before we need to finalize the
> Yoga release, I'm seeking permission from the TC on behalf of the
> OpenStack Release Managers to bypass normal core reviewer, PTL and
> release liaison approval processes in order to approve any remaining
> changes for official OpenStack projects necessary for this
> transition, and to produce new release candidates with those fixes
> included as necessary.
> 
> [*] https://review.opendev.org/815938

Apparently there were not yet fixes proposed for all projects. I
tried to put one together for Murano, but am a bit out of my depth.
My naive attempt to find places where tenant_id gets passed into the
context manager still misses something, or is having a ripple effect
in other parts of the code. It's getting rather late in my part of
the World, so if someone else (perhaps someone with more context,
pun intended) has ideas on how to get it working, please feel free
to push up new revisions of this change:

    https://review.opendev.org/835488

Any help is most appreciated. If we can get it working in master,
then merging that and backporting to stable/yoga will be the next
step for Murano.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/c93e9db1/attachment.sig>

From andy at andybotting.com  Tue Mar 29 05:13:12 2022
From: andy at andybotting.com (Andy Botting)
Date: Tue, 29 Mar 2022 16:13:12 +1100
Subject: [murano][oslo][release][tc] Emergency bypass reviewer/PTL/liaison
 approval for Yoga release fixes
In-Reply-To: <20220329025838.aqryk7olbubellqr@yuggoth.org>
References: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
 <20220329025838.aqryk7olbubellqr@yuggoth.org>
Message-ID: <CAHj+3C57gnjWEp4ovymMwJAmFyb+gRpvs0b1d=20ZWAezK2bpw@mail.gmail.com>

Hi Jeremy,

> Apparently there were not yet fixes proposed for all projects. I
> tried to put one together for Murano, but am a bit out of my depth.
> My naive attempt to find places where tenant_id gets passed into the
> context manager still misses something, or is having a ripple effect
> in other parts of the code. It's getting rather late in my part of
> the World, so if someone else (perhaps someone with more context,
> pun intended) has ideas on how to get it working, please feel free
> to push up new revisions of this change:
>
>     https://review.opendev.org/835488
>
> Any help is most appreciated. If we can get it working in master,
> then merging that and backporting to stable/yoga will be the next
> step for Murano.

I'm starting to have a look now. I'll let you know how I get on.

cheers,
Andy


From marios at redhat.com  Tue Mar 29 06:02:57 2022
From: marios at redhat.com (Marios Andreou)
Date: Tue, 29 Mar 2022 09:02:57 +0300
Subject: [TripleO] Propositing Jiri Podivin as TripleO (Validation
 Framework) core
In-Reply-To: <CAKwUe8kynak8TOcxC6c88K23cYY=0Wsu8DfHS5s2oVNCtB13Kg@mail.gmail.com>
References: <CAKwUe8kynak8TOcxC6c88K23cYY=0Wsu8DfHS5s2oVNCtB13Kg@mail.gmail.com>
Message-ID: <CAM51kHXydGCeXi6wj+EGT_-XKLy+HSSNbnK9vcMVj6rUuDSEow@mail.gmail.com>

+1



On Mon, Mar 28, 2022 at 3:36 PM Mathieu Bultel <mbultel at redhat.com> wrote:

> Hi folks,
>
> I would like to propose Jiri Podivin as TripleO Validation Framework core.
> Jirka has been part of the TripleO organization for some significant time
> now and his contribution has grown a lot during the last few months.
> He is submitting highly valuable reviews and has now a strong knowledge
> around the TripleO Validations Framework areas, the Python framework but
> also in the CI (TripleO and upstream generic) and more general projects.
>
> I think getting him as a core reviewer for the Validations
> repositories will be very good for us.
>
> Feel free to send your feedback, if there is no objection until next week,
> I propose to add him to the list with limited core votes to the VF repo [1].
>
> Thank you,
>
> KR,
> Mathieu (matbu)
>
> [1] openstack/validations-libs openstack/validations-common
> openstack/tripleo-validations and eventually the Validation related code in
> openstack/python-tripleoclient.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/c09eaac6/attachment.htm>

From fpantano at redhat.com  Tue Mar 29 07:08:46 2022
From: fpantano at redhat.com (Francesco Pantano)
Date: Tue, 29 Mar 2022 09:08:46 +0200
Subject: [TripleO] Propositing Jiri Podivin as TripleO (Validation
 Framework) core
In-Reply-To: <CAKwUe8kynak8TOcxC6c88K23cYY=0Wsu8DfHS5s2oVNCtB13Kg@mail.gmail.com>
References: <CAKwUe8kynak8TOcxC6c88K23cYY=0Wsu8DfHS5s2oVNCtB13Kg@mail.gmail.com>
Message-ID: <CAJy1LSHuQWjphFxDTtbjxQGYH7LGdTzBrV-4wyP7w4-CT8gc0g@mail.gmail.com>

+1

On Mon, Mar 28, 2022 at 2:38 PM Mathieu Bultel <mbultel at redhat.com> wrote:

> Hi folks,
>
> I would like to propose Jiri Podivin as TripleO Validation Framework core.
> Jirka has been part of the TripleO organization for some significant time
> now and his contribution has grown a lot during the last few months.
> He is submitting highly valuable reviews and has now a strong knowledge
> around the TripleO Validations Framework areas, the Python framework but
> also in the CI (TripleO and upstream generic) and more general projects.
>
> I think getting him as a core reviewer for the Validations
> repositories will be very good for us.
>
> Feel free to send your feedback, if there is no objection until next week,
> I propose to add him to the list with limited core votes to the VF repo [1].
>
> Thank you,
>
> KR,
> Mathieu (matbu)
>
> [1] openstack/validations-libs openstack/validations-common
> openstack/tripleo-validations and eventually the Validation related code in
> openstack/python-tripleoclient.
>


-- 
Francesco Pantano
GPG KEY: F41BD75C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/adb708f3/attachment.htm>

From zigo at debian.org  Tue Mar 29 08:22:18 2022
From: zigo at debian.org (Thomas Goirand)
Date: Tue, 29 Mar 2022 10:22:18 +0200
Subject: [magnum][murano][release][sahara][tc][trove][zaqar] Emergency
 bypass reviewer/PTL/liaison approval for Yoga release fixes
In-Reply-To: <CAB9QTQbf_H6G7mnRadfkSzU0nCkcMD-2xJ8Cv-fkXjFKWFZGPw@mail.gmail.com>
References: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
 <2452114.9o76ZdvQCi@whitebase.usersys.redhat.com>
 <CAB9QTQbf_H6G7mnRadfkSzU0nCkcMD-2xJ8Cv-fkXjFKWFZGPw@mail.gmail.com>
Message-ID: <bdf67c01-008d-67a8-f2a2-4923958c188e@debian.org>

On 3/28/22 21:32, Spyros Trigazis wrote:
> Same for magnum, 10 days ago.
> https://review.opendev.org/q/I10daa22b614aab456b837c03278eb04da0355ff7 
> <https://review.opendev.org/q/I10daa22b614aab456b837c03278eb04da0355ff7>
> 
> Merged in stable/yoga and tagged 14.0.0.0rc2.
> 
> Am I missing something?
> 
> Spyros
Hi,

I'm still getting these though:

https://buildd.debian.org/status/fetch.php?pkg=magnum&arch=all&ver=14.0.0%7Erc1-3&stamp=1648488744&raw=0

Any idea what's going on? It doesn't do that on my laptop... :/

Cheers,

Thomas Goirand (zigo)


From rdhasman at redhat.com  Tue Mar 29 08:40:03 2022
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Tue, 29 Mar 2022 14:10:03 +0530
Subject: Cinder - easy to hit RecursionError with complex config formulas
In-Reply-To: <2d45281c-7283-88c6-07bf-850c4d009f6e@ovhcloud.com>
References: <2d45281c-7283-88c6-07bf-850c4d009f6e@ovhcloud.com>
Message-ID: <CAARK8KRuZnVLcfmEz5pe2nPght9pqxFM19e_on-jU9HW7DxqDg@mail.gmail.com>

Hi Bartos,

I checked the current evaluator code and you're correct that it exceeds the
recursion depth for complex expressions.
Given your script, I was able to confirm that I'm hitting the same
recursion depths as well.

Packrat[1] is an optimization (pyparsing.ParserElement.enablePackrat())
that uses memoization to reduce recursion depths but
that is already enabled in the evaluator (if not for it, simpler
evaluations like "max(1, 2, 3)" wouldn't even return in 1000 recursion
depth and would fail). It has a cache size of 128 by default which I tried
tweaking to make it unbounded but that didn't help.

Second approach which I tried was to use pyparsing_common instead of
defining expressions in a custom way (as pyparsing already
has them optimized) which reduced the recursion depth by a measure of "10"
with just redefining two variables.
I've proposed a patch for the same here[2] which is a minor change and
thanks to your script, I was able to verify this improvement.

The main problem I see is with the infixNotation we use[3] as we're passing
a lot of expressions to it which is known to reduce performance.

Thanks for raising the concern and feel free to open a bug at launchpad[4]
and we can discuss this issue at our bug squad meeting.

[1]
https://github.com/openstack/cinder/blob/04da59177d97e5f57cb5000f2cfe21d86221139a/cinder/scheduler/evaluator/evaluator.py#L231
[2] https://review.opendev.org/c/openstack/cinder/+/835553
[3]
https://github.com/openstack/cinder/blob/04da59177d97e5f57cb5000f2cfe21d86221139a/cinder/scheduler/evaluator/evaluator.py#L260-L271
[4] https://launchpad.net/cinder

On Mon, Mar 28, 2022 at 8:15 PM bartosz.rabiega at ovhcloud.com <
bartosz.rabiega at ovhcloud.com> wrote:

> Hello,
>
> I wanted to share something I've recently discovered - there is a
> strange issue with cinder evaluating complex configuration formulas.
>
> For example when using complex goodness_function it's quite easy to hit:
>      ERROR cinder.scheduler.weights.goodness maximum recursion depth
> exceeded: RecursionError: maximum recursion depth exceeded
>
> I did some tests to find the root cause. It seems that pyparsing module
> does deep recursive parsing quite a lot (default recursion limit is 1000).
>
> Not sure how to solve it but it would be nice to at least have a warning
> in the docs.
> Results and methodology below.
>
> Tests were done using following code snippet
> -------------------------------------------
> from cinder.scheduler.evaluator.evaluator import evaluate
> import sys
>
> formulas = [
>      "1",
>      "1 + 1",
>      "max(1, 2, 3)",
>      "max(1 + (10 / 20), 2, 3)",
>      "(1 + max(1 + (10 / 20), 2, 3)) / 100",
>      "((1 + max(1 + (10 / 20), 2, 3)) / 100) + stats.total_capacity_gb",
>      "(((1 + max(1 + (10 / 20), 2, 3)) / 100) + stats.total_capacity_gb)
> / 100",
> ]
>
> stats = {
>      'allocated_capacity_gb': 50000,
>      'total_capacity_gb': 60000,
>      'free_capacity_gb': 10000,
> }
>
> for f in formulas:
>      for i in range(10, 2000, 10):
>          sys.setrecursionlimit(i)
>          try:
>              res = evaluate(f, stats=stats)
>              print(f"{i}: {f}")
>              break
>          except RecursionError:
>              pass
>
>
> Test results
> --------------------------------
> Cinder 14.3.1, pyparsing<3.0
> 210: 1
> 210: 1 + 1
> 450: max(1, 2, 3)
> 600: max(1 + (10 / 20), 2, 3)
> 790: (1 + max(1 + (10 / 20), 2, 3)) / 100
> 980: ((1 + max(1 + (10 / 20), 2, 3)) / 100) + stats.total_capacity_gb
> 1160: (((1 + max(1 + (10 / 20), 2, 3)) / 100) + stats.total_capacity_gb)
> / 100
>
> Cinder 16.4.2, pyparsing<3.0
> 220: 1
> 220: 1 + 1
> 450: max(1, 2, 3)
> 610: max(1 + (10 / 20), 2, 3)
> 790: (1 + max(1 + (10 / 20), 2, 3)) / 100
> 980: ((1 + max(1 + (10 / 20), 2, 3)) / 100) + stats.total_capacity_gb
> 1170: (((1 + max(1 + (10 / 20), 2, 3)) / 100) + stats.total_capacity_gb)
> / 100
>
> Cinder 19.1.0, pyparsing<3.0
> 220: 1
> 220: 1 + 1
> 450: max(1, 2, 3)
> 610: max(1 + (10 / 20), 2, 3)
> 790: (1 + max(1 + (10 / 20), 2, 3)) / 100
> 980: ((1 + max(1 + (10 / 20), 2, 3)) / 100) + stats.total_capacity_gb
> 1170: (((1 + max(1 + (10 / 20), 2, 3)) / 100) + stats.total_capacity_gb)
> / 100
>
>
> BR
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/d5164f62/attachment-0001.htm>

From fungi at yuggoth.org  Tue Mar 29 12:02:43 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 29 Mar 2022 12:02:43 +0000
Subject: [magnum][murano][release][sahara][tc][trove][zaqar] Emergency
 bypass reviewer/PTL/liaison approval for Yoga release fixes
In-Reply-To: <bdf67c01-008d-67a8-f2a2-4923958c188e@debian.org>
References: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
 <2452114.9o76ZdvQCi@whitebase.usersys.redhat.com>
 <CAB9QTQbf_H6G7mnRadfkSzU0nCkcMD-2xJ8Cv-fkXjFKWFZGPw@mail.gmail.com>
 <bdf67c01-008d-67a8-f2a2-4923958c188e@debian.org>
Message-ID: <20220329120243.fgy2id7bw2b7aira@yuggoth.org>

On 2022-03-29 10:22:18 +0200 (+0200), Thomas Goirand wrote:
[...]
> I'm still getting these though:
> 
> https://buildd.debian.org/status/fetch.php?pkg=magnum&arch=all&ver=14.0.0%7Erc1-3&stamp=1648488744&raw=0
> 
> Any idea what's going on? It doesn't do that on my laptop... :/

"BlockingIOError: [Errno 11] write could not complete without
blocking" is what you should expect if one side of a socket or other
file descriptor is opened in noblock mode and too much data is
written too quickly, so it's not surprising that it would crop up at
random and you'd see it on some systems but not others. I got as far
as looking through the TestApp class in the webtest library Pecan
uses, but am not clear where the socket setup is occurring. I
suppose it's also possible that the test runner or even sbuild
itself is setting stdout/stderr to blocking mode.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/5467d878/attachment.sig>

From fungi at yuggoth.org  Tue Mar 29 12:11:49 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 29 Mar 2022 12:11:49 +0000
Subject: [murano][oslo][release][tc] Emergency bypass
 reviewer/PTL/liaison approval for Yoga release fixes
In-Reply-To: <CAHj+3C57gnjWEp4ovymMwJAmFyb+gRpvs0b1d=20ZWAezK2bpw@mail.gmail.com>
References: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
 <20220329025838.aqryk7olbubellqr@yuggoth.org>
 <CAHj+3C57gnjWEp4ovymMwJAmFyb+gRpvs0b1d=20ZWAezK2bpw@mail.gmail.com>
Message-ID: <20220329121149.6wh6htts2efjpk5e@yuggoth.org>

On 2022-03-29 16:13:12 +1100 (+1100), Andy Botting wrote:
[...]
> I'm starting to have a look now. I'll let you know how I get on.

Thanks! Looks like it's passing all the voting jobs now except
lower-constraints, with an array of errors where tenant_id is coming
back as None in session objects and DB inserts, but also some
failures for API authorization problems which I guess could also
drive back to wrong tenant_id values as well.

I can't tell if the patch for the tenant->project_id migration is
the cause, or if this is a separate latent regression. I suppose one
response might be to drop the lower-constraints job or make it
non-voting, or simply backport this to stable/yoga even though it
hasn't merged to master.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/ccf3bfa8/attachment.sig>

From dpeacock at redhat.com  Tue Mar 29 12:19:51 2022
From: dpeacock at redhat.com (David Peacock)
Date: Tue, 29 Mar 2022 08:19:51 -0400
Subject: [TripleO] Propositing Jiri Podivin as TripleO (Validation
 Framework) core
In-Reply-To: <CAKwUe8kynak8TOcxC6c88K23cYY=0Wsu8DfHS5s2oVNCtB13Kg@mail.gmail.com>
References: <CAKwUe8kynak8TOcxC6c88K23cYY=0Wsu8DfHS5s2oVNCtB13Kg@mail.gmail.com>
Message-ID: <CAK6G-fJgg+-Re-s1=TithUnQ4CdJjDE+OXA=0vNFhDFh_yFkGA@mail.gmail.com>

+1 from me. Thank you Jiri for your great dedication!

On Mon, Mar 28, 2022 at 8:33 AM Mathieu Bultel <mbultel at redhat.com> wrote:

> Hi folks,
>
> I would like to propose Jiri Podivin as TripleO Validation Framework core.
> Jirka has been part of the TripleO organization for some significant time
> now and his contribution has grown a lot during the last few months.
> He is submitting highly valuable reviews and has now a strong knowledge
> around the TripleO Validations Framework areas, the Python framework but
> also in the CI (TripleO and upstream generic) and more general projects.
>
> I think getting him as a core reviewer for the Validations
> repositories will be very good for us.
>
> Feel free to send your feedback, if there is no objection until next week,
> I propose to add him to the list with limited core votes to the VF repo [1].
>
> Thank you,
>
> KR,
> Mathieu (matbu)
>
> [1] openstack/validations-libs openstack/validations-common
> openstack/tripleo-validations and eventually the Validation related code in
> openstack/python-tripleoclient.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/e5b31357/attachment.htm>

From y.romanova at connectria.com  Mon Mar 28 23:08:44 2022
From: y.romanova at connectria.com (Yuliia Romanova)
Date: Mon, 28 Mar 2022 23:08:44 +0000
Subject: question on plain text config parameters encryption feature
In-Reply-To: <DS7PR03MB54939B446AD009F77E7B725A9C179@DS7PR03MB5493.namprd03.prod.outlook.com>
References: <DS7PR03MB54939B446AD009F77E7B725A9C179@DS7PR03MB5493.namprd03.prod.outlook.com>
Message-ID: <CY4PR03MB31256C2F08FA3122777E5671E11D9@CY4PR03MB3125.namprd03.prod.outlook.com>

Happy Monday OpenStack community,
I hope everyone is doing well and staying safe.

Coming back to the questions that Alex raised previous week.
Did you have a chance to review our request?

Thank you,
Yuliia Romanova
________________________________
From: Alexander Yeremko <a.yeremko at connectria.com>
Sent: Tuesday, March 22, 2022 1:11 PM
To: openstack-discuss at lists.openstack.org <openstack-discuss at lists.openstack.org>
Cc: Tina Wisbiski <t.wisbiski at connectria.com>; Kelsi Parenteau <k.parenteau at connectria.com>; Yuliia Romanova <y.romanova at connectria.com>
Subject: question on plain text config parameters encryption feature

Dear OpenStack community,

we are developing plain text config secrets encryption feature according to the next specification:

https://specs.openstack.org/openstack/openstack-ansible-specs/specs/xena/protecting-plaintext-configs.html

We started from Glance OS service and submitted two patchsets already:

https://review.opendev.org/c/openstack/openstack-ansible-os_glance/+/814865

Now we have two questions that we need to clarify to proceed our work on that feature and finish our development:

1. Is it correct that we need to develop more patchsets to rework some logic of encryption mechanism according
to comment to 'files/encypt_secrets.py' script that arised at the second patchset (PatchSet 2) dated Nov/30/2021 ?
Comment is by Dmitry Rabotyagov: "We _really_ should make it as an ansible plugin and re-work logic"

2. We wish to have such feature in previous releases also, not just in upcoming Yoga or Zed.
Stein, Train and Victoria - it would be excellent to have plain text secrets encryption with these releases also.
So question is how is it possible to use our feature in those releases also? Can we push some backports to those releases openstack-ansible repo?

Best regards and wishes,
Alex Yeremko
This E-Mail (including any attachments) may contain privileged or confidential information. It is intended only for the addressee(s) indicated above. The sender does not waive any of its rights, privileges or other protections respecting this information. Any distribution, copying or other use of this E-Mail or the information it contains, by other than an intended recipient, is not sanctioned and is prohibited. If you received this E-Mail in error, please delete it and advise the sender (by return E-Mail or otherwise) immediately. Any calls held by you with Connectria may be recorded by an automated note taking system to ensure prompt follow up and for information collection purposes, and your attendance on any calls with Connectria confirms your consent to this. Any E-mail received by or sent from Connectria is subject to review by Connectria supervisory personnel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220328/5d399d96/attachment-0001.htm>

From jean-francois.taltavull at elca.ch  Tue Mar 29 13:29:35 2022
From: jean-francois.taltavull at elca.ch (=?iso-8859-1?Q?Taltavull_Jean-Fran=E7ois?=)
Date: Tue, 29 Mar 2022 13:29:35 +0000
Subject: [Ceph Rados Gateway] 403 when using S3 client
Message-ID: <8b05dea37bd2412ab15d54ed806b2658@elca.ch>

Hi All,

I get an http 403 error code when I try to get the bucket list with Ubuntu (Focal) S3 client (awscli).

S3 api has been activated in radosgw config file and EC2 credentials have been created and put in S3 client config file.

Otherwise, everything is working fine with OpenStack client.

My deployment:
- OSA 23.2.0
- OpenStack Wallaby
- Ceph and Rados GW Octopus

Has any of you already experienced this kind of behaviour ?

Many thanks,
Jean-Francois


From aaronzhu1121 at gmail.com  Tue Mar 29 13:51:44 2022
From: aaronzhu1121 at gmail.com (Rong Zhu)
Date: Tue, 29 Mar 2022 21:51:44 +0800
Subject: [murano][oslo][release][tc] Emergency bypass reviewer/PTL/liaison
 approval for Yoga release fixes
In-Reply-To: <20220329121149.6wh6htts2efjpk5e@yuggoth.org>
References: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
 <20220329025838.aqryk7olbubellqr@yuggoth.org>
 <CAHj+3C57gnjWEp4ovymMwJAmFyb+gRpvs0b1d=20ZWAezK2bpw@mail.gmail.com>
 <20220329121149.6wh6htts2efjpk5e@yuggoth.org>
Message-ID: <CAN2nDNsj2e_YJGmQqHBg-aA2VaqBHabtWXSgUO40rqDoF+JQ7A@mail.gmail.com>

Thanks, Jeremy and Andy, I dropped the l-c job and passed all the jobs, I
approved the patch and also backport to stable/yoga.

On Tue, Mar 29, 2022 at 8:17 PM Jeremy Stanley <fungi at yuggoth.org> wrote:

> On 2022-03-29 16:13:12 +1100 (+1100), Andy Botting wrote:
> [...]
> > I'm starting to have a look now. I'll let you know how I get on.
>
> Thanks! Looks like it's passing all the voting jobs now except
> lower-constraints, with an array of errors where tenant_id is coming
> back as None in session objects and DB inserts, but also some
> failures for API authorization problems which I guess could also
> drive back to wrong tenant_id values as well.
>
> I can't tell if the patch for the tenant->project_id migration is
> the cause, or if this is a separate latent regression. I suppose one
> response might be to drop the lower-constraints job or make it
> non-voting, or simply backport this to stable/yoga even though it
> hasn't merged to master.
> --
> Jeremy Stanley
>


-- 
Thanks,
Rong Zhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/7661a659/attachment.htm>

From fungi at yuggoth.org  Tue Mar 29 14:39:29 2022
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 29 Mar 2022 14:39:29 +0000
Subject: [murano][oslo][release][tc] Emergency bypass
 reviewer/PTL/liaison approval for Yoga release fixes
In-Reply-To: <CAN2nDNsj2e_YJGmQqHBg-aA2VaqBHabtWXSgUO40rqDoF+JQ7A@mail.gmail.com>
References: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
 <20220329025838.aqryk7olbubellqr@yuggoth.org>
 <CAHj+3C57gnjWEp4ovymMwJAmFyb+gRpvs0b1d=20ZWAezK2bpw@mail.gmail.com>
 <20220329121149.6wh6htts2efjpk5e@yuggoth.org>
 <CAN2nDNsj2e_YJGmQqHBg-aA2VaqBHabtWXSgUO40rqDoF+JQ7A@mail.gmail.com>
Message-ID: <20220329143929.nui6nzdjks3noqvn@yuggoth.org>

On 2022-03-29 21:51:44 +0800 (+0800), Rong Zhu wrote:
> Thanks, Jeremy and Andy, I dropped the l-c job and passed all the
> jobs, I approved the patch and also backport to stable/yoga.
[...]

Thanks for picking this up! Once the backport merges, the Release
Managers can tag a new RC for Murano and then we'll be in a good
place for the final Yoga releases tomorrow.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/1e4b9b0d/attachment.sig>

From rdhasman at redhat.com  Tue Mar 29 15:44:44 2022
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Tue, 29 Mar 2022 21:14:44 +0530
Subject: [cinder] Zed PTG schedule
Message-ID: <CAARK8KTWaai_3mgcCtBrZ7q8gUChgKRAEMGHHVt2F_V7YMY6sw@mail.gmail.com>

Hello Argonauts,

Zed PTG is going to start from next week i.e. 4th April, 2022 to 8th April,
2022. Kindly register if you haven't already[1]. The registration is free
and acts as a count of the people participating.

The Cinder team will be meeting from 5th April (Tuesday) till 8th April
(Friday) in the 1300-1700 UTC time slot.
I've arranged the topics as per participants availability and in the
following manner[2]. The connection details are on the etherpad along with
the day wise schedule of topics. I've also arranged them in a tabular
structure[3] (the time allotted to each topic here might vary).

Hope to see everyone next week!

[1] https://openinfra-ptg.eventbrite.com/
[2] https://etherpad.opendev.org/p/zed-ptg-cinder
[3] https://ethercalc.openstack.org/crz6qdm7fq0v

Thanks and regards
Rajat Dhasmana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/d27afb4b/attachment.htm>

From sbauza at redhat.com  Tue Mar 29 16:14:30 2022
From: sbauza at redhat.com (Sylvain Bauza)
Date: Tue, 29 Mar 2022 18:14:30 +0200
Subject: [nova][placement] We want you for the PTG !
Message-ID: <CALOCmu=P87g-=GkiFu1V8vOGujtGhwa8JGEgBoV4BYD2+jwT_Q@mail.gmail.com>

Hi folks,

As a reminder, PTG will start next week and we'll have Nova meetings on
Tues up to Friday everyday between 2pm UTC and 5pm UTC.

I'm asking here loudly folks to provide their topics they want to discuss
for the PTG *before Thursday this week* so I can start to plan the agenda
for next week.

All of the PTG logistics and topics are within
https://etherpad.opendev.org/p/nova-zed-ptg
Add the topics you want !
Don't be afraid to join the hopefully last virtual PTG and see our
community :-)

Last note, remember you need to register for free for the PTG
https://openinfra-ptg.eventbrite.com/
See you next week,

-Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/27ee8d37/attachment.htm>

From wakorins at gmail.com  Tue Mar 29 16:25:48 2022
From: wakorins at gmail.com (Wada Akor)
Date: Tue, 29 Mar 2022 17:25:48 +0100
Subject: Juju bootstrap issues on ubuntu 20.04 LTS
Message-ID: <CAG8+hJNeXh3n2JPC5EY=86oeKuyKHrh+bDbwpan6Kv1YBDcXXg@mail.gmail.com>

Good Day every one,

Please i need a respond from these who have deployed openstack charms

on ubuntu .

i ran the command below

# juju bootstrap --bootstrap-series=focal --constraints tags=juju
mymaas maas-controller

here is my out put below

# Creating Juju controller "maas-controller" on mymaas/default

Looking for packaged Juju agent version 2.9.27 for amd64
Located Juju agent version 2.9.27-ubuntu-amd64 at
https://streams.canonical.com/juju/tools/agent/2.9.27/juju-2.9.27-ubuntu-amd64.tgz
Launching controller instance(s) on mymaas/default...
 - a3r8rm (arch=amd64 mem=3.5G cores=2)
Installing Juju agent on bootstrap instance
Fetching Juju Dashboard 0.8.1
Waiting for address
Attempting to connect to 10.0.0.2:22
Connected to 10.0.0.2
Running machine configuration script...

I was unable to bootstrap the juju-controller on the maa-controller
I need support
thanks
Wada Akoh Kenneth Jos,Plateau State , Nigeria
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/e35b4481/attachment-0001.htm>

From mkopec at redhat.com  Tue Mar 29 16:35:01 2022
From: mkopec at redhat.com (Martin Kopec)
Date: Tue, 29 Mar 2022 18:35:01 +0200
Subject: [qa] Cancelling office hour on April 5th
Message-ID: <CAKZGdE3+kymY4uzwVoTR=299MZ7mTm8vF-pEjLw2aT=MSH+06A@mail.gmail.com>

Hi everyone,

we are cancelling the QA office hour on April 5th due to PTG.

We are looking forward to seeing you on PTG.

Just as a reminder, QA time slots:
- Monday (April 4th) 13-14 UTC (1 hour) @ Liberty room
- Tuesday (April 5th) 15-17 UTC (2 hours) @ Liberty room
- Thursday (April 7th)  13-14 UTC (1 hour) @ Liberty room

The topics we are going to cover are gathered in this etherpad [1].
If you have anything you would like to discuss with us, please, feel free
to write it to [1].

[1] https://etherpad.opendev.org/p/qa-zed-ptg

Thank you,

-- 
Martin Kopec
Senior Software Quality Engineer
Red Hat EMEA
IM: kopecmartin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/5f25ef1e/attachment.htm>

From noonedeadpunk at ya.ru  Tue Mar 29 16:48:45 2022
From: noonedeadpunk at ya.ru (Dmitriy Rabotyagov)
Date: Tue, 29 Mar 2022 19:48:45 +0300
Subject: [Ceph Rados Gateway] 403 when using S3 client
In-Reply-To: <8b05dea37bd2412ab15d54ed806b2658@elca.ch>
References: <8b05dea37bd2412ab15d54ed806b2658@elca.ch>
Message-ID: <612721648572028@mail.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/1b630f82/attachment.htm>

From iurygregory at gmail.com  Tue Mar 29 17:25:09 2022
From: iurygregory at gmail.com (Iury Gregory)
Date: Tue, 29 Mar 2022 14:25:09 -0300
Subject: [ironic] Ironic Zed PTG Schedule
Message-ID: <CAJqPaj_DS5z0bkcFMJAe=p-deVYYy0fg=k7FkTZcRuabJR0YiA@mail.gmail.com>

Hello Ironicers and Stackers!

I've split the topics we had in our etherpad [1]  in the booked slots.
You can find the proposed schedule in [2], please provide feedback till
Thursday so I can make changes and provide the official schedule by Friday
morning =).
If you haven't registered yourself for the PTG, please do [3].

[1] https://etherpad.opendev.org/p/ironic-zed-ptg
[2] https://paste.opendev.org/show/bosAputU90U8RNKUbvKd/
[3] https://openinfra-ptg.eventbrite.com/

-- 


*Att[]'sIury Gregory Melo Ferreira *
*MSc in Computer Science at UFCG*
*Part of the ironic-core and puppet-manager-core team in OpenStack*
*Software Engineer at Red Hat Czech*
*Social*: https://www.linkedin.com/in/iurygregory
*E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/0bbed419/attachment.htm>

From iurygregory at gmail.com  Tue Mar 29 17:26:43 2022
From: iurygregory at gmail.com (Iury Gregory)
Date: Tue, 29 Mar 2022 14:26:43 -0300
Subject: [ironic] No weekly meeting in April 4th
Message-ID: <CAJqPaj9fY+FC84YZH+Hx1XZeYEuGup0UTonRAN-_r2fbMB+T5A@mail.gmail.com>

Hello Ironicers,

Since next week is the PTG we won't have our weekly meeting, we will resume
our weekly meeting on April 11.

Thank you!

-- 


*Att[]'sIury Gregory Melo Ferreira *
*MSc in Computer Science at UFCG*
*Part of the ironic-core and puppet-manager-core team in OpenStack*
*Software Engineer at Red Hat Czech*
*Social*: https://www.linkedin.com/in/iurygregory
*E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/1e3bf930/attachment.htm>

From elod.illes at est.tech  Tue Mar 29 17:43:44 2022
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Tue, 29 Mar 2022 19:43:44 +0200
Subject: [murano][oslo][release][tc] Emergency bypass reviewer/PTL/liaison
 approval for Yoga release fixes
In-Reply-To: <20220329143929.nui6nzdjks3noqvn@yuggoth.org>
References: <20220328182812.6te6s6bivqrs6wiu@yuggoth.org>
 <20220329025838.aqryk7olbubellqr@yuggoth.org>
 <CAHj+3C57gnjWEp4ovymMwJAmFyb+gRpvs0b1d=20ZWAezK2bpw@mail.gmail.com>
 <20220329121149.6wh6htts2efjpk5e@yuggoth.org>
 <CAN2nDNsj2e_YJGmQqHBg-aA2VaqBHabtWXSgUO40rqDoF+JQ7A@mail.gmail.com>
 <20220329143929.nui6nzdjks3noqvn@yuggoth.org>
Message-ID: <00220545-71f7-488a-1716-003db3e874c6@est.tech>

Thanks everyone for all the efforts! The necessary releases are done [1] 
thanks to you!

Now we are looking forward to the Yoga final release in a couple of hours!

Thanks,

El?d


[1] https://etherpad.opendev.org/p/tenant-projectid-last-minute-fixes


On 2022. 03. 29. 16:39, Jeremy Stanley wrote:
> On 2022-03-29 21:51:44 +0800 (+0800), Rong Zhu wrote:
>> Thanks, Jeremy and Andy, I dropped the l-c job and passed all the
>> jobs, I approved the patch and also backport to stable/yoga.
> [...]
>
> Thanks for picking this up! Once the backport merges, the Release
> Managers can tag a new RC for Murano and then we'll be in a good
> place for the final Yoga releases tomorrow.

From zigo at debian.org  Tue Mar 29 19:21:18 2022
From: zigo at debian.org (Thomas Goirand)
Date: Tue, 29 Mar 2022 21:21:18 +0200
Subject: Getting invoice for the Berlin summit ticket
Message-ID: <842de580-8ca0-03e6-916f-e03d9b481a6f@debian.org>

Hi,

I asked summit at openinfra.dev but so far got no answer. How do I get an 
invoice for the summit ticket ? Eventbright doesn't provide it, and my 
company is asking for it so I can get a refund.

Cheers,

Thomas Goirand (zigo)


From jimmy at openinfra.dev  Tue Mar 29 19:25:58 2022
From: jimmy at openinfra.dev (Jimmy McArthur)
Date: Tue, 29 Mar 2022 14:25:58 -0500
Subject: Getting invoice for the Berlin summit ticket
In-Reply-To: <842de580-8ca0-03e6-916f-e03d9b481a6f@debian.org>
References: <842de580-8ca0-03e6-916f-e03d9b481a6f@debian.org>
Message-ID: <918B44A4-A528-4E7B-9843-15E825AF21F9@getmailspring.com>

Hi Thomas,

Apologies for the trouble. We had a bunch of zendesk tickets that got stuck in the suspended queue over the last 6 days and just got them all this morning. At this point, you should have received the response, but please let us know if it's not in your inbox.
Cheers,
Jimmy

On Mar 29 2022, at 2:21 pm, Thomas Goirand <zigo at debian.org> wrote:
> Hi,
>
> I asked summit at openinfra.dev but so far got no answer. How do I get an
> invoice for the summit ticket ? Eventbright doesn't provide it, and my
> company is asking for it so I can get a refund.
>
> Cheers,
> Thomas Goirand (zigo)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/fd1a9592/attachment.htm>

From amy at demarco.com  Tue Mar 29 19:32:45 2022
From: amy at demarco.com (Amy Marrich)
Date: Tue, 29 Mar 2022 14:32:45 -0500
Subject: Getting invoice for the Berlin summit ticket
In-Reply-To: <842de580-8ca0-03e6-916f-e03d9b481a6f@debian.org>
References: <842de580-8ca0-03e6-916f-e03d9b481a6f@debian.org>
Message-ID: <CAFs83QpGD0XQJAQ31oX61xk-nak8nbveFwRh18EiGjAKbL9r0w@mail.gmail.com>

Thomas,

I just looked at the email I received from Eventbrite and it did include a
section called Order Summary which had costs broken down like a receipt.

Hope that helps.

Amy

On Tue, Mar 29, 2022 at 2:25 PM Thomas Goirand <zigo at debian.org> wrote:

> Hi,
>
> I asked summit at openinfra.dev but so far got no answer. How do I get an
> invoice for the summit ticket ? Eventbright doesn't provide it, and my
> company is asking for it so I can get a refund.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/689fa5e3/attachment.htm>

From a.yeremko at connectria.com  Tue Mar 29 20:10:12 2022
From: a.yeremko at connectria.com (Alexander Yeremko)
Date: Tue, 29 Mar 2022 20:10:12 +0000
Subject: plain text config parameters encryption feature
Message-ID: <DS7PR03MB549385F366BA4E05A81DDA6A9C1E9@DS7PR03MB5493.namprd03.prod.outlook.com>

Dear OpenStack community,

we are developing plain text config secrets encryption feature according to the next specification:

https://specs.openstack.org/openstack/openstack-ansible-specs/specs/xena/protecting-plaintext-configs.html

We started from Glance OS service and submitted two patchsets already:

https://review.opendev.org/c/openstack/openstack-ansible-os_glance/+/814865

Now we have two questions that we need to clarify to proceed our work on that feature and finish our development:

1. Is it correct that we need to develop more patchsets to rework some logic of encryption mechanism according
to comment to 'files/encypt_secrets.py' script that arised at the second patchset (PatchSet 2) dated Nov/30/2021 ?
Comment is by Dmitry Rabotyagov: "We _really_ should make it as an ansible plugin and re-work logic"

2. We wish to have such feature in previous releases also, not just in upcoming Yoga or Zed.
Stein, Train and Victoria - it would be excellent to have plain text secrets encryption with these releases also.
So question is how is it possible to use our feature in those releases also? Can we push some backports to those releases openstack-ansible repo?

Could someone be so kind and give us answers?

Best regards and wishes,
Alex Yeremko
This E-Mail (including any attachments) may contain privileged or confidential information. It is intended only for the addressee(s) indicated above. The sender does not waive any of its rights, privileges or other protections respecting this information. Any distribution, copying or other use of this E-Mail or the information it contains, by other than an intended recipient, is not sanctioned and is prohibited. If you received this E-Mail in error, please delete it and advise the sender (by return E-Mail or otherwise) immediately. Any calls held by you with Connectria may be recorded by an automated note taking system to ensure prompt follow up and for information collection purposes, and your attendance on any calls with Connectria confirms your consent to this. Any E-mail received by or sent from Connectria is subject to review by Connectria supervisory personnel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220329/22e16b03/attachment.htm>

From ozzzo at yahoo.com  Tue Mar 29 21:04:22 2022
From: ozzzo at yahoo.com (Albert Braden)
Date: Tue, 29 Mar 2022 21:04:22 +0000 (UTC)
Subject: [neutron] [kolla] Static routes added to subnets after upgrading
 from Queens to Train
References: <997697892.1640950.1648587862872.ref@mail.yahoo.com>
Message-ID: <997697892.1640950.1648587862872@mail.yahoo.com>

After upgrading our kolla-ansible clusters from Queens to Train, we are seeing static routes when we create subnets. We didn?t see this in Queens. For example, in our de6 region we have a network called ?trust? with 3 subnets:

Subnet                 CIDR                                   Gateway
trust-az1:             10.52.160.0/22   10.52.160.1
trust-az2:             10.52.164.0/22   10.52.164.1
trust-az3:             10.52.168.0/22   10.52.168.1

Each of these subnets has 2 entries under ?host_routes:? that point to the other two subnets. For example, subnet trust-az1 has these two routes:

host_routes          | destination='10.52.164.0/22', gateway='10.52.160.1' |
|                      | destination='10.52.168.0/22', gateway='10.52.160.1' |

How can we prevent these host routes from being created in Train? Do we need to change something in our config?


From eblock at nde.ag  Wed Mar 30 07:26:48 2022
From: eblock at nde.ag (Eugen Block)
Date: Wed, 30 Mar 2022 07:26:48 +0000
Subject: rabbitmq config changes not applied in newer format
In-Reply-To: <20220324143303.Horde.npmqqZg6mUlqUY46i2AdSpC@webmail.nde.ag>
References: <20220324095810.Horde.M7FDQIhittE5kJ6pIdqj24Y@webmail.nde.ag>
 <20220324143303.Horde.npmqqZg6mUlqUY46i2AdSpC@webmail.nde.ag>
Message-ID: <20220330072648.Horde.GLg4_yQxpOzXuAGlgWjm4Ak@webmail.nde.ag>

Update #2: After playing around with my test setup (without pacemaker  
involved) I learned that the "new config file format" is just  
converted into the erlang format during rabbitmq startup. That's why  
our production setup works (we use the erlang format). But I noticed  
that in the HA setup there's no  
/var/lib/rabbitmq/schema/rabbitmq_management.schema file present.  
Apparently, that file is created by  starting rabbitmq via systemd, it  
is not created when pacemaker starts rabbitmq although the plugin is  
enabled, the zipped files are all there but don't seem to be generated  
in the working directory like in my test setup. Also, the file  
/var/lib/rabbitmq/config/generated/rabbitmq.config is not generated in  
the HA setup. So the workaround is clearly to use the erlang config  
file format, but I'd like to understand the difference. I'll continue  
the investigation to see if I find it myself, but I'd appreciate any  
hints.


Zitat von Eugen Block <eblock at nde.ag>:

> Update: it doesn't seem to be a problem with the config file format  
> but with the clustering. On a VM (single-control node) I tried the  
> "newer" config file format and it worked. But that node is not part  
> of a cluster, in our production cloud we have the "classic_config"  
> enabled as backend and a list of all cluster nodes in the config file:
>
> cluster_formation.peer_discovery_backend = classic_config
> cluster_formation.classic_config.nodes.1 = rabbit at controller01.fqdn
> cluster_formation.classic_config.nodes.2 = rabbit at controller02.fqdn
> cluster_formation.classic_config.nodes.3 = rabbit at controller01
> cluster_formation.classic_config.nodes.4 = rabbit at controller02
>
> When I remove that cluster part from the newer config file the node  
> doesn't join the cluster, this is what the config looks like:
>
> listeners.tcp.all_ips   = 0.0.0.0:5672
> management.load_definitions = /etc/rabbitmq/definitions.json
> management.ssl.port = 15671
> management.ssl.ip   = 0.0.0.0
> management.ssl.cacertfile = /path/to/cafile
> management.ssl.certfile   = /path/to/certfile
> management.ssl.keyfile    = /path/to/keyfile
>
> This is the error message:
>
> 2022-03-24 15:25:49.183 [info] <0.1227.0> WAL: recovering  
> ["/var/lib/rabbitmq/mnesia/rabbit at controller01/quorum/rabbit at controller01/00000002.wal"]
> 2022-03-24 15:25:49.359 [warning] <0.1227.0> wal: encountered error  
> during recovery: badarg
>
> Then I switch back to the old format where no clustering is  
> mentioned at all and it works. Could anyone give me a hint what I'm  
> doing wrong?
>
>
> Zitat von Eugen Block <eblock at nde.ag>:
>
>> Hi *,
>>
>> this might not be the right place to ask but I'm curious how others  
>> configure their rabbitmq.
>>
>> RabbitMQ version: 3.8.3
>> OpenStack version: Ussuri/Victoria (two different clusters)
>>
>> We have a highly available cloud controlled by pacemaker. The  
>> deployment is based on our own Salt states. We noticed that our  
>> config is not applied (e. g. after power outage), we need to import  
>> those manually with 'rabbitmqctl import /path/to/definitions.json'.  
>> Comparing it to an older cloud version (Rocky, Rabbit version  
>> 3.6.16) I noticed that the config format is different between those  
>> versions, the older version uses a json format (?):
>>
>> ---snip---
>> # old format
>>
>> cat /etc/rabbitmq/rabbitmq.config
>> [
>> {mnesia,
>>  [
>>   {dump_log_write_threshold, 300},
>>   {dump_log_time_threshold, 180000}
>>  ]
>> },
>> {rabbit,
>>  [
>>   {collect_statistics_interval, 5000},
>>   {tcp_listen_options, [
>>                         {backlog, 128},{nodelay, true},{keepalive, false}
>>                        ]
>>   },
>>   {tcp_listeners, [
>>                    {"x.x.x.x", 5672}
>>                   ]},
>>   {cluster_partition_handling, pause_minority},
>>   {queue_master_locator, <<"min-masters">>},
>>   {disk_free_limit, 50000000}
>> ]},
>> {rabbitmq_management,
>>  [
>>   {listener, [{ip, "x.x.x.x"}, {port, 15673}]},
>>   {load_definitions, "/etc/rabbitmq/definitions.json"}
>>  ]
>> }
>> ].
>>
>>
>> # new format
>> [...]
>> listeners.tcp.default = 5672
>> listeners.tcp.other_port = 5673
>> listeners.tcp.other_ip   = x.x.x.x:5672
>> [...]
>> ---snip---
>>
>> If I switch to the old format and restart rabbitmq on that node,  
>> the changes are applied successfully. Is this a known issue? Should  
>> I just stick to the old format? Any comments are appreciated!
>>
>> Regards,
>> Eugen





From amonster369 at gmail.com  Wed Mar 30 07:38:50 2022
From: amonster369 at gmail.com (A Monster)
Date: Wed, 30 Mar 2022 08:38:50 +0100
Subject: [kolla] RDP access to openstack instances
Message-ID: <CAEc0ziuazStTB8kv4wN80UvzWk+8FoKRZOD08zRJH90RoN7_hw@mail.gmail.com>

I can ssh into instances after attributing floating ips but whenever I try
to access using remote desktop I fail, although I've enabled RDP traffic in
security groups, is there a problem with my configuration or do I have to
do extra work to successfully do a remote access.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/d2479107/attachment.htm>

From derekokeeffe85 at yahoo.ie  Wed Mar 30 08:16:12 2022
From: derekokeeffe85 at yahoo.ie (Derek O keeffe)
Date: Wed, 30 Mar 2022 08:16:12 +0000 (UTC)
Subject: Volume attached to removed instance
References: <561681084.2529212.1648628172407.ref@mail.yahoo.com>
Message-ID: <561681084.2529212.1648628172407@mail.yahoo.com>

Hi all,
We are having an issue with a volume. The volume was created and attached to an instance that was then deleted. We now need to attach the volume to another instance to rescue the data on it but it still thinks it's attached to the deleted instance and we can't "manage attachments" or view the details of the volume.
We have tried forcing it from the cli to detach but with no luck. We were thinking of doing it through the DB but said we'd askhere first in case anyone has experienced the same and has a better way of approaching the issue. Thanks in advance.
Regards,Derek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/740e9311/attachment.htm>

From jean-francois.taltavull at elca.ch  Wed Mar 30 08:24:02 2022
From: jean-francois.taltavull at elca.ch (=?utf-8?B?VGFsdGF2dWxsIEplYW4tRnJhbsOnb2lz?=)
Date: Wed, 30 Mar 2022 08:24:02 +0000
Subject: [Ceph Rados Gateway] 403 when using S3 client
In-Reply-To: <612721648572028@mail.yandex.ru>
References: <8b05dea37bd2412ab15d54ed806b2658@elca.ch>
 <612721648572028@mail.yandex.ru>
Message-ID: <96f86768b73d456ba1937a9177c3831f@elca.ch>

Hi Dmitriy,

I just tried with s3cmd but I still get a 403.

Here is the rgw section of ceph.conf:

rgw_keystone_url = http://xxxxx.xxxx.xxx/identity
rgw_keystone_api_version = 3
rgw_keystone_admin_user = radosgw
rgw_keystone_admin_password = xxxxxxxxxxxxxxxxxxxxxxxxx
rgw_keystone_admin_project = service
rgw_keystone_admin_domain = default
rgw_keystone_accepted_roles = member, _member_, admin, swiftoperator
rgw_keystone_accepted_admin_roles = ResellerAdmin
rgw_keystone_implicit_tenants = true
rgw_swift_account_in_url = true
rgw_swift_versioning_enabled = true
rgw_enable_apis = swift,s3
rgw_s3_auth_use_keystone = true

From: Dmitriy Rabotyagov <noonedeadpunk at ya.ru>
Sent: mardi, 29 mars 2022 18:49
To: openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: Re: [Ceph Rados Gateway] 403 when using S3 client



EXTERNAL MESSAGE - This email comes from outside ELCA companies.

- ???

Hi Jean-Francois.

It's quite hard to understand what exactly could went wrong based on the information you've provided.
Highly likely it's related to the RGW configuration itself and it's integration with keystone to be specific.

Would be helpful if you could provide your ceph.conf regarding rgw configuration.

I'm also not 100% sure if awscli does work with RGW... At least I always used s3cmd or rclone to interact with RGW S3 API.

29.03.2022, 16:36, "Taltavull Jean-Fran?ois" <jean-francois.taltavull at elca.ch<mailto:jean-francois.taltavull at elca.ch>>:

Hi All,

I get an http 403 error code when I try to get the bucket list with Ubuntu (Focal) S3 client (awscli).

S3 api has been activated in radosgw config file and EC2 credentials have been created and put in S3 client config file.

Otherwise, everything is working fine with OpenStack client.

My deployment:
- OSA 23.2.0
- OpenStack Wallaby
- Ceph and Rados GW Octopus

Has any of you already experienced this kind of behaviour ?

Many thanks,
Jean-Francois


--
Kind Regards,
Dmitriy Rabotyagov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/85305c96/attachment-0001.htm>

From jonathan.rosser at rd.bbc.co.uk  Wed Mar 30 08:43:51 2022
From: jonathan.rosser at rd.bbc.co.uk (Jonathan Rosser)
Date: Wed, 30 Mar 2022 09:43:51 +0100
Subject: [Ceph Rados Gateway] 403 when using S3 client
In-Reply-To: <96f86768b73d456ba1937a9177c3831f@elca.ch>
References: <8b05dea37bd2412ab15d54ed806b2658@elca.ch>
 <612721648572028@mail.yandex.ru> <96f86768b73d456ba1937a9177c3831f@elca.ch>
Message-ID: <dd1ba269-470b-17e1-9c93-120908e90498@rd.bbc.co.uk>

Hi Jean-Francois.

I have the following difference to your config:

rgw keystone url = http://xx.xx.xx.xx:5000

The normal OSA loadbalancer setup would have the keystone service on 
port 5000.

Jonathan.

On 30/03/2022 09:24, Taltavull Jean-Fran?ois wrote:
>
> Hi Dmitriy,
>
> I just tried with s3cmd but I still get a 403.
>
> Here is the rgw section of ceph.conf:
>
> rgw_keystone_url = http://xxxxx.xxxx.xxx/identity
>
> rgw_keystone_api_version = 3
>
> rgw_keystone_admin_user = radosgw
>
> rgw_keystone_admin_password = xxxxxxxxxxxxxxxxxxxxxxxxx
>
> rgw_keystone_admin_project = service
>
> rgw_keystone_admin_domain = default
>
> rgw_keystone_accepted_roles = member, _member_, admin, swiftoperator
>
> rgw_keystone_accepted_admin_roles = ResellerAdmin
>
> rgw_keystone_implicit_tenants = true
>
> rgw_swift_account_in_url = true
>
> rgw_swift_versioning_enabled = true
>
> rgw_enable_apis = swift,s3
>
> rgw_s3_auth_use_keystone = true
>
> *From:*Dmitriy Rabotyagov <noonedeadpunk at ya.ru>
> *Sent:* mardi, 29 mars 2022 18:49
> *To:* openstack-discuss <openstack-discuss at lists.openstack.org>
> *Subject:* Re: [Ceph Rados Gateway] 403 when using S3 client
>
> 	
>
> */EXTERNAL MESSAGE /*-?This email comes from *outside ELCA companies*.
>
> - ???
>
> Hi Jean-Francois.
>
> It's quite hard to understand what exactly could went wrong based on 
> the information you've provided.
>
> Highly likely it's related to the RGW configuration itself and it's 
> integration with keystone to be specific.
>
> Would be helpful if you could provide your ceph.conf regarding rgw 
> configuration.
>
> I'm also not 100% sure if awscli does work with RGW... At least I 
> always used s3cmd or rclone to interact with RGW S3 API.
>
> 29.03.2022, 16:36, "Taltavull Jean-Fran?ois" 
> <jean-francois.taltavull at elca.ch>:
>
>     Hi All,
>
>     I get an http 403 error code when I try to get the bucket list
>     with Ubuntu (Focal) S3 client (awscli).
>
>     S3 api has been activated in radosgw config file and EC2
>     credentials have been created and put in S3 client config file.
>
>     Otherwise, everything is working fine with OpenStack client.
>
>     My deployment:
>     - OSA 23.2.0
>     - OpenStack Wallaby
>     - Ceph and Rados GW Octopus
>
>     Has any of you already experienced this kind of behaviour ?
>
>     Many thanks,
>     Jean-Francois
>
> -- 
> Kind Regards,
>
> Dmitriy Rabotyagov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/f1dd82d3/attachment.htm>

From jean-francois.taltavull at elca.ch  Wed Mar 30 09:01:30 2022
From: jean-francois.taltavull at elca.ch (=?utf-8?B?VGFsdGF2dWxsIEplYW4tRnJhbsOnb2lz?=)
Date: Wed, 30 Mar 2022 09:01:30 +0000
Subject: [Ceph Rados Gateway] 403 when using S3 client
In-Reply-To: <dd1ba269-470b-17e1-9c93-120908e90498@rd.bbc.co.uk>
References: <8b05dea37bd2412ab15d54ed806b2658@elca.ch>
 <612721648572028@mail.yandex.ru> <96f86768b73d456ba1937a9177c3831f@elca.ch>
 <dd1ba269-470b-17e1-9c93-120908e90498@rd.bbc.co.uk>
Message-ID: <64208f0fd7344c0bab323b66c503f73a@elca.ch>

Hi Jonathan,

The keystone URL is correct. HAProxy has been configured to handle this kind or URL.

And everything works fine with the openstack client.

From: Jonathan Rosser <jonathan.rosser at rd.bbc.co.uk>
Sent: mercredi, 30 mars 2022 10:44
To: openstack-discuss at lists.openstack.org
Subject: Re: [Ceph Rados Gateway] 403 when using S3 client



EXTERNAL MESSAGE - This email comes from outside ELCA companies.


Hi Jean-Francois.

I have the following difference to your config:

rgw keystone url = http://xx.xx.xx.xx:5000

The normal OSA loadbalancer setup would have the keystone service on port 5000.

Jonathan.
On 30/03/2022 09:24, Taltavull Jean-Fran?ois wrote:
Hi Dmitriy,

I just tried with s3cmd but I still get a 403.

Here is the rgw section of ceph.conf:

rgw_keystone_url = http://xxxxx.xxxx.xxx/identity
rgw_keystone_api_version = 3
rgw_keystone_admin_user = radosgw
rgw_keystone_admin_password = xxxxxxxxxxxxxxxxxxxxxxxxx
rgw_keystone_admin_project = service
rgw_keystone_admin_domain = default
rgw_keystone_accepted_roles = member, _member_, admin, swiftoperator
rgw_keystone_accepted_admin_roles = ResellerAdmin
rgw_keystone_implicit_tenants = true
rgw_swift_account_in_url = true
rgw_swift_versioning_enabled = true
rgw_enable_apis = swift,s3
rgw_s3_auth_use_keystone = true

From: Dmitriy Rabotyagov <noonedeadpunk at ya.ru><mailto:noonedeadpunk at ya.ru>
Sent: mardi, 29 mars 2022 18:49
To: openstack-discuss <openstack-discuss at lists.openstack.org><mailto:openstack-discuss at lists.openstack.org>
Subject: Re: [Ceph Rados Gateway] 403 when using S3 client



EXTERNAL MESSAGE - This email comes from outside ELCA companies.

- ???

Hi Jean-Francois.

It's quite hard to understand what exactly could went wrong based on the information you've provided.
Highly likely it's related to the RGW configuration itself and it's integration with keystone to be specific.

Would be helpful if you could provide your ceph.conf regarding rgw configuration.

I'm also not 100% sure if awscli does work with RGW... At least I always used s3cmd or rclone to interact with RGW S3 API.

29.03.2022, 16:36, "Taltavull Jean-Fran?ois" <jean-francois.taltavull at elca.ch<mailto:jean-francois.taltavull at elca.ch>>:

Hi All,

I get an http 403 error code when I try to get the bucket list with Ubuntu (Focal) S3 client (awscli).

S3 api has been activated in radosgw config file and EC2 credentials have been created and put in S3 client config file.

Otherwise, everything is working fine with OpenStack client.

My deployment:
- OSA 23.2.0
- OpenStack Wallaby
- Ceph and Rados GW Octopus

Has any of you already experienced this kind of behaviour ?

Many thanks,
Jean-Francois


--
Kind Regards,
Dmitriy Rabotyagov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/3e0726e5/attachment-0001.htm>

From zigo at debian.org  Wed Mar 30 09:44:32 2022
From: zigo at debian.org (Thomas Goirand)
Date: Wed, 30 Mar 2022 11:44:32 +0200
Subject: Getting invoice for the Berlin summit ticket
In-Reply-To: <CAFs83QpGD0XQJAQ31oX61xk-nak8nbveFwRh18EiGjAKbL9r0w@mail.gmail.com>
References: <842de580-8ca0-03e6-916f-e03d9b481a6f@debian.org>
 <CAFs83QpGD0XQJAQ31oX61xk-nak8nbveFwRh18EiGjAKbL9r0w@mail.gmail.com>
Message-ID: <dbed4143-e819-8ced-5e73-c5ea969d31e0@debian.org>

Hi,

This isn't helpful, it only contains the amount, this isn't a real 
invoice: it doesn't contain an invoice number, so this has no legal 
validity for accounting...

Cheers,

Thomas Goirand

On 3/29/22 21:32, Amy Marrich wrote:
> Thomas,
> 
> I just looked at the email I received from Eventbrite and it did include 
> a section called Order Summary which had costs broken down like a receipt.
> 
> Hope that helps.
> 
> Amy
> 
> On Tue, Mar 29, 2022 at 2:25 PM Thomas Goirand <zigo at debian.org 
> <mailto:zigo at debian.org>> wrote:
> 
>     Hi,
> 
>     I asked summit at openinfra.dev <mailto:summit at openinfra.dev> but so
>     far got no answer. How do I get an
>     invoice for the summit ticket ? Eventbright doesn't provide it, and my
>     company is asking for it so I can get a refund.
> 
>     Cheers,
> 
>     Thomas Goirand (zigo)
> 



From lists at optimcloud.com  Wed Mar 30 11:40:01 2022
From: lists at optimcloud.com (Embedded Devel)
Date: Wed, 30 Mar 2022 11:40:01 +0000
Subject: Getting invoice for the Berlin summit ticket
In-Reply-To: <dbed4143-e819-8ced-5e73-c5ea969d31e0@debian.org>
References: <dbed4143-e819-8ced-5e73-c5ea969d31e0@debian.org>
Message-ID: <1648640359372.2127358957.2861474992@optimcloud.com>



On Wednesday 30 March 2022 16:44:32 PM (+07:00), Thomas Goirand wrote:

 > Hi,
 >
 > This isn't helpful, it only contains the amount, this isn't a real 
invoice: it doesn't contain an invoice number, so this has no legal 
validity for accounting...
 >
 > Cheers,
 >
 > Thomas Goirand
I think he is looking for a commercial invoice, also what we know as a VAT 
invoice, in Europe anyway


 >
 > On 3/29/22 21:32, Amy Marrich wrote:
 > > Thomas,
 > > I just looked at the email I received from Eventbrite and it did 
include a section called Order Summary which had costs broken down like a 
receipt.
 > > Hope that helps.
 > > Amy
 > > On Tue, Mar 29, 2022 at 2:25 PM Thomas Goirand <zigo at debian.org 
<mailto:zigo at debian.org>> wrote:
 > > Hi,
 > > I asked summit at openinfra.dev <mailto:summit at openinfra.dev> but so
 > > far got no answer. How do I get an
 > > invoice for the summit ticket ? Eventbright doesn't provide it, and my
 > > company is asking for it so I can get a refund.
 > > Cheers,
 > > Thomas Goirand (zigo)
 > >
 >
 >
-- 
Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com


From katonalala at gmail.com  Wed Mar 30 12:12:04 2022
From: katonalala at gmail.com (Lajos Katona)
Date: Wed, 30 Mar 2022 14:12:04 +0200
Subject: [neutron] We want you for the PTG !
Message-ID: <CALg0jKnDukWny2PidOHPBfd9FsEM+Un-+Yz7O=0zp67doCRpiQ@mail.gmail.com>

Retweet..... (original
http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027889.html
)

Hi folks

As a reminder, PTG will start next week and we'll have Neutron meetings on
Monday up to Friday everyday between 1pm UTC and 4pm UTC.

I'm asking here loudly folks to provide their topics they want to discuss
for the PTG *before Thursday this week* so I can start to plan the agenda
for next week.

All of the PTG logistics and topics are on
https://etherpad.opendev.org/p/neutron-zed-ptg
Add the topics you want !
Don't be afraid to join the hopefully last virtual PTG and see our
community :-)

Last note, remember you need to register for free for the PTG
https://openinfra-ptg.eventbrite.com/
See you next week,

Lajos Katona (lajoskatona)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/25edcbad/attachment.htm>

From pdeore at redhat.com  Wed Mar 30 12:44:59 2022
From: pdeore at redhat.com (Pranali Deore)
Date: Wed, 30 Mar 2022 18:14:59 +0530
Subject: [glance] Outreachy 2022 Contribution
In-Reply-To: <CANr7emHYCPnOhC6mMp+KsqBD6eenMbq6Hk8HZP=bL7HQ_K_aAQ@mail.gmail.com>
References: <CANr7emHYCPnOhC6mMp+KsqBD6eenMbq6Hk8HZP=bL7HQ_K_aAQ@mail.gmail.com>
Message-ID: <CADkbuWjxe-pxvDKC+MmcntvG5JthWwK=JpVXxG2pGA8tveP1ug@mail.gmail.com>

Hello Anurag,

Nice to see that you're interested in the OpenStack project.

Cyril Roelandt, Mridula Joshi & myself would be mentoring for the "Add mypy
support in OpenStack glance" project

I think being able to run the unit tests on glance, glanceclient and
glance-store would be a good start !!
You can start the same by running https://docs.openstack.org/devstack/latest in
a VM.

Please feel free to reach out to us on #openstack-glance irc channel or
email, if you face any issues.

You can find us on the #openstack-glance channel with below irc nicknames,
Cyril Roelandt:  croelandt
Mridula Joshi: mrjoshi
Pranali Deore: pdeore


Cheers,
Pranali Deore


On Mon, Mar 28, 2022 at 8:16 PM Anurag Singh Rajawat <
anuragsinghrajawat22 at gmail.com> wrote:

> Dear Openstack Team,
>
> My name is Anurag Rajawat and I am selected as an outreachy initial
> applicant.
>
> I am highly interested in the project: "*Add mypy support in OpenStack
> glance".*
> I would appreciate it if you could guide me on how to begin contributing
> to your organization and starting on a current issue. And I am eager to
> become a part of your community.
>
> Thank you so much for taking the time to view this email.
>
> Sincerely,
> Anurag
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/269e75ca/attachment.htm>

From amy at demarco.com  Wed Mar 30 12:58:23 2022
From: amy at demarco.com (Amy Marrich)
Date: Wed, 30 Mar 2022 07:58:23 -0500
Subject: [Diversity] Meeting Cancelled and PTG
Message-ID: <CAFs83Qou4MPJ012WEOwaHHcwnYdkjmN0yH-Ek8=Aaqt-+ZCbdw@mail.gmail.com>

With the PTG next week we have decided to cancel this Friday's Diversity
and Inclusion WG meeting.

We invite everyone to join us at the PTG on Monday at 16:00 UTC in the
Mitaka room. Please add any topics you have to the PTG etherpad[0].

Hope to see everyone there!

Amy
0 - https://etherpad.opendev.org/p/april2022-ptg-diversity
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/69ec8038/attachment.htm>

From senrique at redhat.com  Wed Mar 30 13:20:50 2022
From: senrique at redhat.com (Sofia Enriquez)
Date: Wed, 30 Mar 2022 10:20:50 -0300
Subject: [cinder] Bug deputy report for week of 03-30-2022
Message-ID: <CANtmtpHHqoob+Poy4bcJiPiEENoRQhHD4ZKgukhMSOm6Rxd2+Q@mail.gmail.com>

This is a bug report from 03-23-2022 to 03-30-2022.
Agenda: https://etherpad.opendev.org/p/cinder-bug-squad-meeting
-----------------------------------------------------------------------------------------
Medium

   - https://bugs.launchpad.net/cinder/+bug/1966513 "LVM crashes if there
   is no iSCSI initiator configured." Assigned to Gorka.

Low

   - https://bugs.launchpad.net/cinder/+bug/1966397 "[Fujitsu] Redundant
   scsi records of fujitsu volumes." Unassigned.
   - https://bugs.launchpad.net/cinder/+bug/1966103 "NFS and NVMe-oF
   drivers report different storage_protocol values." Assigned to Gorka.

Incomplete

   - https://bugs.launchpad.net/cinder/+bug/1966639 "[powervc] Resize of
   volume in reverse replication if it is a part of a group." Unassigned.

Cheers,

-- 

Sof?a Enriquez

she/her

Software Engineer

Red Hat PnT <https://www.redhat.com>

IRC: @enriquetaso
@RedHat <https://twitter.com/redhat>   Red Hat
<https://www.linkedin.com/company/red-hat>  Red Hat
<https://www.facebook.com/RedHatInc>
<https://www.redhat.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/4c67d8f8/attachment.htm>

From allison at openinfra.dev  Wed Mar 30 13:27:51 2022
From: allison at openinfra.dev (Allison Price)
Date: Wed, 30 Mar 2022 08:27:51 -0500
Subject: Getting invoice for the Berlin summit ticket
In-Reply-To: <dbed4143-e819-8ced-5e73-c5ea969d31e0@debian.org>
References: <842de580-8ca0-03e6-916f-e03d9b481a6f@debian.org>
 <CAFs83QpGD0XQJAQ31oX61xk-nak8nbveFwRh18EiGjAKbL9r0w@mail.gmail.com>
 <dbed4143-e819-8ced-5e73-c5ea969d31e0@debian.org>
Message-ID: <8AC47171-4201-4B2C-9AC7-2107DEBCAA71@openinfra.dev>

Hi Thomas, 

To date, this has been sufficient for attendees who need to provide additional documentation to their employer. If you require specific information, please reply to me directly or within the email we have going with you from summit at openinfra.dev <mailto:summit at openinfra.dev>. These are each created manually, so we can provide any and all information your organization needs to process the invoice. 

Look forward to seeing you in Berlin! 

Cheers,
Allison 

> On Mar 30, 2022, at 4:44 AM, Thomas Goirand <zigo at debian.org> wrote:
> 
> Hi,
> 
> This isn't helpful, it only contains the amount, this isn't a real invoice: it doesn't contain an invoice number, so this has no legal validity for accounting...
> 
> Cheers,
> 
> Thomas Goirand
> 
> On 3/29/22 21:32, Amy Marrich wrote:
>> Thomas,
>> I just looked at the email I received from Eventbrite and it did include a section called Order Summary which had costs broken down like a receipt.
>> Hope that helps.
>> Amy
>> On Tue, Mar 29, 2022 at 2:25 PM Thomas Goirand <zigo at debian.org <mailto:zigo at debian.org>> wrote:
>>    Hi,
>>    I asked summit at openinfra.dev <mailto:summit at openinfra.dev> but so
>>    far got no answer. How do I get an
>>    invoice for the summit ticket ? Eventbright doesn't provide it, and my
>>    company is asking for it so I can get a refund.
>>    Cheers,
>>    Thomas Goirand (zigo)
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/fa9d4c30/attachment-0001.htm>

From james.slagle at gmail.com  Wed Mar 30 13:50:38 2022
From: james.slagle at gmail.com (James Slagle)
Date: Wed, 30 Mar 2022 09:50:38 -0400
Subject: [TripleO] Core team cleanup
In-Reply-To: <CAM51kHWEHHW5KXta_Q9KrkKqBcNBQ6T6GpR4RbD+Gv9ensdtHQ@mail.gmail.com>
References: <CAHV77z8=qME7dnaZz0Pa7rO_ag+D9ERjZmEDyBjA4cWSkY1k8w@mail.gmail.com>
 <222496ea-c194-6c2b-3383-a6ffd05321d9@redhat.com>
 <CAM51kHWEHHW5KXta_Q9KrkKqBcNBQ6T6GpR4RbD+Gv9ensdtHQ@mail.gmail.com>
Message-ID: <CAHV77z8k_AAU2y+f0srgr3uUfAjB+6MEEgZ=+miD134D8_WLUg@mail.gmail.com>

On Thu, Mar 24, 2022 at 4:46 AM Marios Andreou <marios at redhat.com> wrote:

>
>
> On Thu, Mar 24, 2022 at 8:52 AM Dan Sneddon <dsneddon at redhat.com> wrote:
>
>> I had moved on from doing TripleO reviews and was focusing on other
>> things, so I didn't mind losing my TripleO core status when this email
>> went out. However I am once again focusing on os-net-config, and I just
>> realized I have lost my +2/-2 and workflow +1 status on os-net-config.
>>
>> In order for me to contribute to os-net-config and help to implement the
>> NetworkManager/nmstate implementation, I may need TripleO core status
>> again. I would be happy to do regular reviews again in TripleO in order
>> to maintain that status. Can somebody nominate me for TripleO core status?
>>
>>
> I think you just did ;)
>
> +1 for dsneddon to regain core.
>
> He hasn't been dormant for that long (last review there in November [1] )
> and over the last 6 months [2] shows up in the list of reviewers.
>
> My 2c:  Dan imho the review count is a little low - would be great if you
> could try to do 1 review/day across tripleo (pick any repo ;)) now that
> you're working on os-net-config again. We all need code reviews to keep
> things moving and you'll be needing reviews from other tripleo cores again
> soon enough for the work you'll be doing,
>

Welcome back Dan! I've re-added you to the core team for the purposes of
reviewing os-net-config and related changes to our network stack.

-- 
-- James Slagle
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/01b0f558/attachment.htm>

From amy at demarco.com  Wed Mar 30 14:21:35 2022
From: amy at demarco.com (Amy Marrich)
Date: Wed, 30 Mar 2022 09:21:35 -0500
Subject: RDO Social during the PTG
Message-ID: <CAFs83Qp8=QSTJFZVgiXfLft6eAJZ5EzLPpUPScmc0nPwQxE7mA@mail.gmail.com>

Come join in the fun on Tuesday at 17:00 UTC during the PTG for some
Pictionary! There will be prizes so please register so I have contact
information!

https://eventyay.com/e/d8254248

See you all there!

Amy(spotz)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/c9d9f1b4/attachment.htm>

From elod.illes at est.tech  Wed Mar 30 14:56:37 2022
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Wed, 30 Mar 2022 16:56:37 +0200
Subject: OpenStack Yoga is officially released!
Message-ID: <ef2edffa-5579-25df-2c99-a0dc54544924@est.tech>

Hello OpenStack community,

The official OpenStack Yoga release announcement has been sent out:

http://lists.openstack.org/pipermail/openstack-announce/2022-March/002059.html

Thanks to all who were a part of the Yoga development cycle!

This marks the official opening of the openstack/releases repository for 
Zed,
and freezes are now lifted. Yoga is now a fully normal stable branch, 
and the
normal stable policy applies from now on.

Thanks,

El?d Ill?s and the Release Management team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/84a83e2a/attachment.htm>

From gmann at ghanshyammann.com  Wed Mar 30 15:16:37 2022
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 30 Mar 2022 10:16:37 -0500
Subject: OpenStack Yoga is officially released!
In-Reply-To: <ef2edffa-5579-25df-2c99-a0dc54544924@est.tech>
References: <ef2edffa-5579-25df-2c99-a0dc54544924@est.tech>
Message-ID: <17fdb666d67.b5863813259308.60588582867579219@ghanshyammann.com>

Thanks and congratulation to all the contributors.

Special thanks to our "The Release team" with 25th on-time release (~12.5 years) /o\
for their excellent work.

-gmann

 ---- On Wed, 30 Mar 2022 09:56:37 -0500 El?d Ill?s <elod.illes at est.tech> wrote ----
 >         Hello OpenStack        community,
 >       
 >       The official OpenStack Yoga release announcement has been sent      out:
 >       
 > http://lists.openstack.org/pipermail/openstack-announce/2022-March/002059.html
 >       
 >       Thanks to all who were a part of the Yoga development cycle!
 >       
 >       This marks the official opening of the openstack/releases      repository for Zed,
 >       and freezes are now lifted. Yoga is now a fully normal stable      branch, and the
 >       normal stable policy applies from now on.
 >       
 >       Thanks,
 >       
 >       El?d Ill?s and the Release Management team  


From cdilorenzo at gmail.com  Wed Mar 30 15:30:06 2022
From: cdilorenzo at gmail.com (Chris DiLorenzo)
Date: Wed, 30 Mar 2022 11:30:06 -0400
Subject: [magnum] kube_cluster_deploy timing out
Message-ID: <CAJ8AfbEivStNyqMkS3MKpvVqQQCDXHO9wuBMVw5525LUcC1vcA@mail.gmail.com>

Hello,

I'm trying to deploy a kubernetes cluster using CoreOS 33.   I have
also tried with CoreOS 35/. 1 master, 1 worker.  Ths VMs are deploying
without issue.  However, the stack is timing out on kube_cluster_deploy.
It appears the kubernetes API isn't running:

[root at tes-001-pkjawhk66slm-master-0 log]# podman ps
CONTAINER ID  IMAGE
   COMMAND               CREATED         STATUS             PORTS   NAMES
a08cbea59a57
docker.io/openstackmagnum/heat-container-agent:wallaby-stable-1
/usr/bin/start-he...
 21 minutes ago  Up 21 minutes ago          heat-container-agent

[root at tes-001-pkjawhk66slm-master-0 log]# ss -ln | grep 8080 -> nothing

[root at tes-001-pkjawhk66slm-master-0 heat-config-script]# tail -f
8d8fa128-bca4-485e-946f-90732ebb4cf0-tes-001-pkjawhk66slm-kube_cluster_config-bwkfqwjxzk36.log
+ sleep 5
++ kubectl get --raw=/healthz
The connection to the server localhost:8080 was refused - did you specify
the right host or port?
+ '[' ok = '' ']'
+ sleep 5
++ kubectl get --raw=/healthz
The connection to the server localhost:8080 was refused - did you specify
the right host or port?
+ '[' ok = '' ']'
+ sleep 5
++ kubectl get --raw=/healthz

Not sure where else to look.

Thanks
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/6f050647/attachment-0001.htm>

From amy at demarco.com  Wed Mar 30 15:38:28 2022
From: amy at demarco.com (Amy Marrich)
Date: Wed, 30 Mar 2022 10:38:28 -0500
Subject: OpenStack Yoga is officially released!
In-Reply-To: <ef2edffa-5579-25df-2c99-a0dc54544924@est.tech>
References: <ef2edffa-5579-25df-2c99-a0dc54544924@est.tech>
Message-ID: <CAFs83Qp3g-_H-Sxh5CdzOt8zN4UViR9_U=GFCJ80FF7=Zqu0KA@mail.gmail.com>

Great work everyone!

Amy

On Wed, Mar 30, 2022 at 10:00 AM El?d Ill?s <elod.illes at est.tech> wrote:

> Hello OpenStack community,
>
> The official OpenStack Yoga release announcement has been sent out:
>
>
> http://lists.openstack.org/pipermail/openstack-announce/2022-March/002059.html
>
> Thanks to all who were a part of the Yoga development cycle!
>
> This marks the official opening of the openstack/releases repository for
> Zed,
> and freezes are now lifted. Yoga is now a fully normal stable branch, and
> the
> normal stable policy applies from now on.
>
> Thanks,
>
> El?d Ill?s and the Release Management team
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/892f3fb1/attachment.htm>

From knikolla at bu.edu  Wed Mar 30 15:42:00 2022
From: knikolla at bu.edu (Nikolla, Kristi)
Date: Wed, 30 Mar 2022 15:42:00 +0000
Subject: OpenStack Yoga is officially released!
In-Reply-To: <ef2edffa-5579-25df-2c99-a0dc54544924@est.tech>
References: <ef2edffa-5579-25df-2c99-a0dc54544924@est.tech>
Message-ID: <2B7F30BF-203C-4F68-8751-F31002F05C25@bu.edu>

Great work and thank you everyone!

Kristi

Il giorno 30 mar 2022, alle ore 10:56, El?d Ill?s <elod.illes at est.tech<mailto:elod.illes at est.tech>> ha scritto:

Hello OpenStack community,

The official OpenStack Yoga release announcement has been sent out:

http://lists.openstack.org/pipermail/openstack-announce/2022-March/002059.html

Thanks to all who were a part of the Yoga development cycle!

This marks the official opening of the openstack/releases repository for Zed,
and freezes are now lifted. Yoga is now a fully normal stable branch, and the
normal stable policy applies from now on.

Thanks,

El?d Ill?s and the Release Management team

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/88dec217/attachment.htm>

From manchandavishal143 at gmail.com  Wed Mar 30 15:54:35 2022
From: manchandavishal143 at gmail.com (vishal manchanda)
Date: Wed, 30 Mar 2022 21:24:35 +0530
Subject: [horizon] Zed PTG Schedule
Message-ID: <CADrq38uxs8sBw62vPyfwVP-cFq17Uu0WUM85_-4=3hhcGv8aSg@mail.gmail.com>

Hello Team,

Please Find the Schedule for Horizon PTG in the eherpad [1].
Feel Free to add the topics you want to discuss in the PTG.

Also, as discussed in today's weekly meeting, there will be
no horizon weekly meeting next week.
Don't forget to register for PTG, if not done yet [2].
See you at the PTG!

Thanks & Regards,
Vishal Manchanda

[1] https://etherpad.opendev.org/p/horizon-zed-ptg
[2] https://openinfra-ptg.eventbrite.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/99a00bf3/attachment.htm>

From radoslaw.piliszek at gmail.com  Wed Mar 30 15:57:06 2022
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Wed, 30 Mar 2022 17:57:06 +0200
Subject: OpenStack Yoga is officially released!
In-Reply-To: <17fdb666d67.b5863813259308.60588582867579219@ghanshyammann.com>
References: <ef2edffa-5579-25df-2c99-a0dc54544924@est.tech>
 <17fdb666d67.b5863813259308.60588582867579219@ghanshyammann.com>
Message-ID: <CAKZ_x796+He9bj40bzqOqwVg1fNXqpKQFaWvDpqHYVJZtG7O8Q@mail.gmail.com>

I join the thanks and congratulations and would like to also send
another round of special thanks - this time to the OpenDev/Infra team
who bravely support the ongoing development and release processes and
ensure they go as smoothly as it is in their power to ensure. :-)

-yoctozepto

On Wed, 30 Mar 2022 at 17:17, Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
>
> Thanks and congratulation to all the contributors.
>
> Special thanks to our "The Release team" with 25th on-time release (~12.5 years) /o\
> for their excellent work.
>
> -gmann
>
>  ---- On Wed, 30 Mar 2022 09:56:37 -0500 El?d Ill?s <elod.illes at est.tech> wrote ----
>  >         Hello OpenStack        community,
>  >
>  >       The official OpenStack Yoga release announcement has been sent      out:
>  >
>  > http://lists.openstack.org/pipermail/openstack-announce/2022-March/002059.html
>  >
>  >       Thanks to all who were a part of the Yoga development cycle!
>  >
>  >       This marks the official opening of the openstack/releases      repository for Zed,
>  >       and freezes are now lifted. Yoga is now a fully normal stable      branch, and the
>  >       normal stable policy applies from now on.
>  >
>  >       Thanks,
>  >
>  >       El?d Ill?s and the Release Management team
>


From james.slagle at gmail.com  Wed Mar 30 16:20:49 2022
From: james.slagle at gmail.com (James Slagle)
Date: Wed, 30 Mar 2022 12:20:49 -0400
Subject: [TripleO] TripleO Zed PTG topics Etherpad
In-Reply-To: <CAHV77z849Er-V1agvgL=td1=3PLwZRaeqS77jPEOMYa+w7z4nw@mail.gmail.com>
References: <CAHV77z849Er-V1agvgL=td1=3PLwZRaeqS77jPEOMYa+w7z4nw@mail.gmail.com>
Message-ID: <CAHV77z_3D48C251HKw6u0UdGsx7kCuCiKQ=buCexSFZsFY_R4A@mail.gmail.com>

On Thu, Mar 10, 2022 at 7:49 AM James Slagle <james.slagle at gmail.com> wrote:

> TripleO,
> Please add your proposed topics for the PTG to this etherad:
> https://etherpad.opendev.org/p/tripleo-zed-ptg-topics
>
> I will reserve time allocation for TripleO based on the number of proposed
> topics. Thanks!
>

I've put forth a draft schedule in the etherpad:
https://etherpad.opendev.org/p/tripleo-zed-ptg-topics
Let me know if there are any concerns or conflicts. We still have some time
for additional topics on Wednesday in case there are any late breaking
topics. Talk to everyone next week!

-- 
-- James Slagle
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/e41df349/attachment-0001.htm>

From jungleboyj at gmail.com  Wed Mar 30 16:58:57 2022
From: jungleboyj at gmail.com (Jay Bryant)
Date: Wed, 30 Mar 2022 11:58:57 -0500
Subject: OpenStack Yoga is officially released!
In-Reply-To: <CAKZ_x796+He9bj40bzqOqwVg1fNXqpKQFaWvDpqHYVJZtG7O8Q@mail.gmail.com>
References: <ef2edffa-5579-25df-2c99-a0dc54544924@est.tech>
 <17fdb666d67.b5863813259308.60588582867579219@ghanshyammann.com>
 <CAKZ_x796+He9bj40bzqOqwVg1fNXqpKQFaWvDpqHYVJZtG7O8Q@mail.gmail.com>
Message-ID: <7d1678f8-6297-da0e-da86-cc6a7c7d292d@gmail.com>

I echo gmann and yoctozepto's thanks!? The fact that OpenStack has 
delivered a release on time, 25 times in a row is amazing!

Great work everyone!

-Jay

(jungleboyj)

On 3/30/2022 10:57 AM, Rados?aw Piliszek wrote:
> I join the thanks and congratulations and would like to also send
> another round of special thanks - this time to the OpenDev/Infra team
> who bravely support the ongoing development and release processes and
> ensure they go as smoothly as it is in their power to ensure. :-)
>
> -yoctozepto
>
> On Wed, 30 Mar 2022 at 17:17, Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
>> Thanks and congratulation to all the contributors.
>>
>> Special thanks to our "The Release team" with 25th on-time release (~12.5 years) /o\
>> for their excellent work.
>>
>> -gmann
>>
>>   ---- On Wed, 30 Mar 2022 09:56:37 -0500 El?d Ill?s <elod.illes at est.tech> wrote ----
>>   >         Hello OpenStack        community,
>>   >
>>   >       The official OpenStack Yoga release announcement has been sent      out:
>>   >
>>   > http://lists.openstack.org/pipermail/openstack-announce/2022-March/002059.html
>>   >
>>   >       Thanks to all who were a part of the Yoga development cycle!
>>   >
>>   >       This marks the official opening of the openstack/releases      repository for Zed,
>>   >       and freezes are now lifted. Yoga is now a fully normal stable      branch, and the
>>   >       normal stable policy applies from now on.
>>   >
>>   >       Thanks,
>>   >
>>   >       El?d Ill?s and the Release Management team
>>


From haleyb.dev at gmail.com  Wed Mar 30 17:46:18 2022
From: haleyb.dev at gmail.com (Brian Haley)
Date: Wed, 30 Mar 2022 13:46:18 -0400
Subject: [neutron] [kolla] Static routes added to subnets after upgrading
 from Queens to Train
In-Reply-To: <997697892.1640950.1648587862872@mail.yahoo.com>
References: <997697892.1640950.1648587862872.ref@mail.yahoo.com>
 <997697892.1640950.1648587862872@mail.yahoo.com>
Message-ID: <f195da6e-fb83-bcf1-64bc-1885377e07b3@gmail.com>

Hi Albert,

On 3/29/22 17:04, Albert Braden wrote:
> After upgrading our kolla-ansible clusters from Queens to Train, we are seeing static routes when we create subnets. We didn?t see this in Queens. For example, in our de6 region we have a network called ?trust? with 3 subnets:
> 
> Subnet                 CIDR                                   Gateway
> trust-az1:             10.52.160.0/22   10.52.160.1
> trust-az2:             10.52.164.0/22   10.52.164.1
> trust-az3:             10.52.168.0/22   10.52.168.1
> 
> Each of these subnets has 2 entries under ?host_routes:? that point to the other two subnets. For example, subnet trust-az1 has these two routes:
> 
> host_routes          | destination='10.52.164.0/22', gateway='10.52.160.1' |
> |                      | destination='10.52.168.0/22', gateway='10.52.160.1' |
> 
> How can we prevent these host routes from being created in Train? Do we need to change something in our config?

 From the neutron side of things, host_routes of a subnet is not 
automatically calculated and filled-in, they have to be manually added. 
So perhaps this is something kolla is doing? At least on my Yoga setup 
it is completely blank using 'openstack subnet create ...' even with 
multiple subnets on a network.

How exactly are the subnets getting created?

-Brian


From allison at openinfra.dev  Wed Mar 30 18:24:02 2022
From: allison at openinfra.dev (Allison Price)
Date: Wed, 30 Mar 2022 13:24:02 -0500
Subject: OpenInfra Live on OpenStack Yoga - March 31 at 1400 UTC
Message-ID: <E0008625-B41D-4B55-95FC-36F7378A93D8@openinfra.dev>

Hi everyone,

First of all, I would like to echo some of our community members here[1] and thank everyone who contributed to the OpenStack Yoga release. Delivering 25 on-time releases is no easy feat?very impressive! 

This week?s OpenInfra Live episode is brought to you by some of the contributors and community leaders for the OpenStack Yoga release! 

OpenStack continues to be one of the most active open source projects in the world. Come learn more about OpenStack Yoga, the 25th release of the open source cloud computing project that was released today!! Over 680 contributors from over 125 organizations delivered OpenStack Yoga and this episode of OpenInfra Live will highlight some of the key features, what use cases are impacted and what operators can expect.


Episode: OpenStack Yoga: New Features Straight from the Contributors

Date and time: March 31 at 1400 UTC (9am CT)

You can watch us live on:
YouTube: https://www.youtube.com/watch?v=hwPfjvshxOM <https://www.youtube.com/watch?v=hwPfjvshxOM> 
LinkedIn: https://www.linkedin.com/video/event/urn:li:ugcPost:6912440696532598784/ <https://www.linkedin.com/video/event/urn:li:ugcPost:6912440696532598784/> 
Facebook: https://www.facebook.com/104139126308032/posts/4958355564219673/ <https://www.facebook.com/104139126308032/posts/4958355564219673/> 
WeChat: recording will be posted on OpenStack WeChat after the live stream

Host: Ghanshyam Mann, chair of the OpenStack TC for the Yoga cycle 
Speakers: 
Brian Rosmaita (Cinder)
Mark Goddard (Kolla)
Maysa Macedo (Kuryr)
Lajos Katona (Neutron)
Iury Gregory (Ironic)
Goutham Pacha Ravi (Manila)
Gregory Thiemonge (Octavia)
Sylvain Bauza (Nova) 

Have an idea for a future episode? Share it now at ideas.openinfra.live <https://openinfrafoundation.formstack.com/forms/openinfralive>. 

Thanks, 
Allison

[1] http://lists.openstack.org/pipermail/openstack-announce/2022-March/002059.html <http://lists.openstack.org/pipermail/openstack-announce/2022-March/002059.html> 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/a10c8610/attachment-0001.htm>

From eblock at nde.ag  Wed Mar 30 18:57:48 2022
From: eblock at nde.ag (Eugen Block)
Date: Wed, 30 Mar 2022 18:57:48 +0000
Subject: [magnum] kube_cluster_deploy timing out
In-Reply-To: <CAJ8AfbEivStNyqMkS3MKpvVqQQCDXHO9wuBMVw5525LUcC1vcA@mail.gmail.com>
Message-ID: <20220330185748.Horde.fGQzHsVjHooVE7VQvREqa7J@webmail.nde.ag>

Hi,
I haven?t had the chance to play with magnum too much yet but could it  
be an issue with the image? I had an issue with Octavia when I first  
used an image which didn?t work as expected. Maybe check all relevant  
log files inside the VMs, maybe cloud-init didn?t work as expected.

Zitat von Chris DiLorenzo <cdilorenzo at gmail.com>:

> Hello,
>
> I'm trying to deploy a kubernetes cluster using CoreOS 33.   I have
> also tried with CoreOS 35/. 1 master, 1 worker.  Ths VMs are deploying
> without issue.  However, the stack is timing out on kube_cluster_deploy.
> It appears the kubernetes API isn't running:
>
> [root at tes-001-pkjawhk66slm-master-0 log]# podman ps
> CONTAINER ID  IMAGE
>    COMMAND               CREATED         STATUS             PORTS   NAMES
> a08cbea59a57
> docker.io/openstackmagnum/heat-container-agent:wallaby-stable-1
> /usr/bin/start-he...
>  21 minutes ago  Up 21 minutes ago          heat-container-agent
>
> [root at tes-001-pkjawhk66slm-master-0 log]# ss -ln | grep 8080 -> nothing
>
> [root at tes-001-pkjawhk66slm-master-0 heat-config-script]# tail -f
> 8d8fa128-bca4-485e-946f-90732ebb4cf0-tes-001-pkjawhk66slm-kube_cluster_config-bwkfqwjxzk36.log
> + sleep 5
> ++ kubectl get --raw=/healthz
> The connection to the server localhost:8080 was refused - did you specify
> the right host or port?
> + '[' ok = '' ']'
> + sleep 5
> ++ kubectl get --raw=/healthz
> The connection to the server localhost:8080 was refused - did you specify
> the right host or port?
> + '[' ok = '' ']'
> + sleep 5
> ++ kubectl get --raw=/healthz
>
> Not sure where else to look.
>
> Thanks
> Chris





From ozzzo at yahoo.com  Wed Mar 30 19:27:07 2022
From: ozzzo at yahoo.com (Albert Braden)
Date: Wed, 30 Mar 2022 19:27:07 +0000 (UTC)
Subject: [neutron] [kolla] Static routes added to subnets after
 upgrading from Queens to Train
In-Reply-To: <f195da6e-fb83-bcf1-64bc-1885377e07b3@gmail.com>
References: <997697892.1640950.1648587862872.ref@mail.yahoo.com>
 <997697892.1640950.1648587862872@mail.yahoo.com>
 <f195da6e-fb83-bcf1-64bc-1885377e07b3@gmail.com>
Message-ID: <242099798.347726.1648668427206@mail.yahoo.com>

 The command that we use to create subnets looks like this:

openstack subnet create --no-dhcp --network trust --network-segment trust-az1-seg --ip-version 4 --allocation-pool start=10.52.160.14,end=10.52.160.235 --subnet-range 10.52.160.0/24 --dns-nameserver 10.10.10.10 --gateway 10.52.160.1 trust-az1

 My co-workers tell me that we also specified "--gateway" when we created our Queens subnets, but this did not cause static routes to be created. Did the handling of "--gateway" change from Queens to Train?
     On Wednesday, March 30, 2022, 01:45:52 PM EDT, Brian Haley <haleyb.dev at gmail.com> wrote:  
 
 Hi Albert,

On 3/29/22 17:04, Albert Braden wrote:
> After upgrading our kolla-ansible clusters from Queens to Train, we are seeing static routes when we create subnets. We didn?t see this in Queens. For example, in our de6 region we have a network called ?trust? with 3 subnets:
> 
> Subnet? ? ? ? ? ? ? ? CIDR? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Gateway
> trust-az1:? ? ? ? ? ? 10.52.160.0/22? 10.52.160.1
> trust-az2:? ? ? ? ? ? 10.52.164.0/22? 10.52.164.1
> trust-az3:? ? ? ? ? ? 10.52.168.0/22? 10.52.168.1
> 
> Each of these subnets has 2 entries under ?host_routes:? that point to the other two subnets. For example, subnet trust-az1 has these two routes:
> 
> host_routes? ? ? ? ? | destination='10.52.164.0/22', gateway='10.52.160.1' |
> |? ? ? ? ? ? ? ? ? ? ? | destination='10.52.168.0/22', gateway='10.52.160.1' |
> 
> How can we prevent these host routes from being created in Train? Do we need to change something in our config?

 From the neutron side of things, host_routes of a subnet is not 
automatically calculated and filled-in, they have to be manually added. 
So perhaps this is something kolla is doing? At least on my Yoga setup 
it is completely blank using 'openstack subnet create ...' even with 
multiple subnets on a network.

How exactly are the subnets getting created?

-Brian
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/0a1f32ea/attachment.htm>

From johfulto at redhat.com  Wed Mar 30 19:39:24 2022
From: johfulto at redhat.com (John Fulton)
Date: Wed, 30 Mar 2022 15:39:24 -0400
Subject: [TripleO] TripleO Zed PTG topics Etherpad
In-Reply-To: <CAHV77z_3D48C251HKw6u0UdGsx7kCuCiKQ=buCexSFZsFY_R4A@mail.gmail.com>
References: <CAHV77z849Er-V1agvgL=td1=3PLwZRaeqS77jPEOMYa+w7z4nw@mail.gmail.com>
 <CAHV77z_3D48C251HKw6u0UdGsx7kCuCiKQ=buCexSFZsFY_R4A@mail.gmail.com>
Message-ID: <CAE66OMAf44re10qJd+i+SLs_ZC4C99VRiBoLUpjuupFs7zJO_g@mail.gmail.com>

On Wed, Mar 30, 2022 at 12:22 PM James Slagle <james.slagle at gmail.com> wrote:
> On Thu, Mar 10, 2022 at 7:49 AM James Slagle <james.slagle at gmail.com> wrote:
>>
>> TripleO,
>> Please add your proposed topics for the PTG to this etherad: https://etherpad.opendev.org/p/tripleo-zed-ptg-topics
>>
>> I will reserve time allocation for TripleO based on the number of proposed topics. Thanks!
>
>
> I've put forth a draft schedule in the etherpad:
> https://etherpad.opendev.org/p/tripleo-zed-ptg-topics
> Let me know if there are any concerns or conflicts. We still have some time for additional topics on Wednesday in case there are any late breaking topics. Talk to everyone next week!

Hi James,

Because the Ceph integration topics involve collaboration with Manila
and they have a conflict between 1600 and 1700 UTC [1], would it be
possible to move the Ceph topic to any other slot TripleO has
available earlier in the day?

Thanks,
  John

[1] https://etherpad.opendev.org/p/zorilla-ptg-manila-planning

>
> --
> -- James Slagle
> --



From ces.eduardo98 at gmail.com  Wed Mar 30 21:09:03 2022
From: ces.eduardo98 at gmail.com (Carlos Silva)
Date: Wed, 30 Mar 2022 18:09:03 -0300
Subject: [manila] Zed PTG schedule
Message-ID: <CAE51gQJrwDwcFwzAVmu6=6uxX_QB_fSsBfrV_3j9GrCy3KR2=Q@mail.gmail.com>

Hello fellow Zorillas and interested stackers,

The PTG is going to take place next week (April 4th to 8th). Our agenda
starts at 16 UTC with the Yoga cycle retrospective, as usual.

On the following days, we will proceed with the proposed topics.

The topics in the official Manila PTG etherpad [1] now have a proposed time
slot assigned to them. Please check the etherpad and if you would like to
have a topic moved around, please let me know.

If you haven't registered yet, there's still time! Please register here [2].

[1] https://etherpad.opendev.org/p/zorilla-ptg-manila
[2] https://openinfra-ptg.eventbrite.com/

See you soon!

Thanks!
carloss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/cae19a69/attachment.htm>

From james.slagle at gmail.com  Wed Mar 30 21:28:10 2022
From: james.slagle at gmail.com (James Slagle)
Date: Wed, 30 Mar 2022 17:28:10 -0400
Subject: [TripleO] TripleO Zed PTG topics Etherpad
In-Reply-To: <CAE66OMAf44re10qJd+i+SLs_ZC4C99VRiBoLUpjuupFs7zJO_g@mail.gmail.com>
References: <CAHV77z849Er-V1agvgL=td1=3PLwZRaeqS77jPEOMYa+w7z4nw@mail.gmail.com>
 <CAHV77z_3D48C251HKw6u0UdGsx7kCuCiKQ=buCexSFZsFY_R4A@mail.gmail.com>
 <CAE66OMAf44re10qJd+i+SLs_ZC4C99VRiBoLUpjuupFs7zJO_g@mail.gmail.com>
Message-ID: <CAHV77z8jNCrHUimSsBF_d=fvzCDbaY4MF=-DoHZuOK2rneA2og@mail.gmail.com>

On Wed, Mar 30, 2022 at 3:39 PM John Fulton <johfulto at redhat.com> wrote:

> On Wed, Mar 30, 2022 at 12:22 PM James Slagle <james.slagle at gmail.com>
> wrote:
> > On Thu, Mar 10, 2022 at 7:49 AM James Slagle <james.slagle at gmail.com>
> wrote:
> >>
> >> TripleO,
> >> Please add your proposed topics for the PTG to this etherad:
> https://etherpad.opendev.org/p/tripleo-zed-ptg-topics
> >>
> >> I will reserve time allocation for TripleO based on the number of
> proposed topics. Thanks!
> >
> >
> > I've put forth a draft schedule in the etherpad:
> > https://etherpad.opendev.org/p/tripleo-zed-ptg-topics
> > Let me know if there are any concerns or conflicts. We still have some
> time for additional topics on Wednesday in case there are any late breaking
> topics. Talk to everyone next week!
>
> Hi James,
>
> Because the Ceph integration topics involve collaboration with Manila
> and they have a conflict between 1600 and 1700 UTC [1], would it be
> possible to move the Ceph topic to any other slot TripleO has
> available earlier in the day?
>

Sure thing, I moved it to earlier on Monday.

-- 
-- James Slagle
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/b15e217c/attachment-0001.htm>

From jon at csail.mit.edu  Wed Mar 30 21:40:51 2022
From: jon at csail.mit.edu (Jonathan Proulx)
Date: Wed, 30 Mar 2022 17:40:51 -0400
Subject: Volume attached to removed instance
In-Reply-To: <561681084.2529212.1648628172407@mail.yahoo.com>
References: <561681084.2529212.1648628172407.ref@mail.yahoo.com>
 <561681084.2529212.1648628172407@mail.yahoo.com>
Message-ID: <20220330214051.r4h32saqulqqvmky@csail.mit.edu>

On Wed, Mar 30, 2022 at 08:16:12AM +0000, Derek O keeffe wrote:
:Hi all,
:We are having an issue with a volume. The volume was created and attached to an instance that was then deleted. We now need to attach the volume to another instance to rescue the data on it but it still thinks it's attached to the deleted instance and we can't "manage attachments" or view the details of the volume.

When you say

:We have tried forcing it from the cli to detach but with no luck. We were thinking of doing it through the DB but said we'd askhere first in case anyone has experienced the same and has a better way of approaching the issue. Thanks in advance.

is this what you tried?

cinder reset-state --attach-status detached <UUID>

I've had the stale attachement problem a number of times and that
one's always worked for me so here's hoping it's not what you tried...

-Jon


From abishop at redhat.com  Wed Mar 30 22:12:06 2022
From: abishop at redhat.com (Alan Bishop)
Date: Wed, 30 Mar 2022 15:12:06 -0700
Subject: Volume attached to removed instance
In-Reply-To: <20220330214051.r4h32saqulqqvmky@csail.mit.edu>
References: <561681084.2529212.1648628172407.ref@mail.yahoo.com>
 <561681084.2529212.1648628172407@mail.yahoo.com>
 <20220330214051.r4h32saqulqqvmky@csail.mit.edu>
Message-ID: <CADO3vb7xOX=Ahyis8qzuRVJdOo02RoWMe41H+5dQPXaZ0+6UeA@mail.gmail.com>

On Wed, Mar 30, 2022 at 2:42 PM Jonathan Proulx <jon at csail.mit.edu> wrote:

> On Wed, Mar 30, 2022 at 08:16:12AM +0000, Derek O keeffe wrote:
> :Hi all,
> :We are having an issue with a volume. The volume was created and attached
> to an instance that was then deleted. We now need to attach the volume to
> another instance to rescue the data on it but it still thinks it's attached
> to the deleted instance and we can't "manage attachments" or view the
> details of the volume.
>
> When you say
>
> :We have tried forcing it from the cli to detach but with no luck. We were
> thinking of doing it through the DB but said we'd askhere first in case
> anyone has experienced the same and has a better way of approaching the
> issue. Thanks in advance.
>
> is this what you tried?
>
> cinder reset-state --attach-status detached <UUID>
>

Assuming your cloud is based on Queens or later, these commands may also
help:

cinder --os-volume-api-version 3.44 attachment-list
cinder --os-volume-api-version 3.44 attachment-delete <attachment ID>

Alan


> I've had the stale attachement problem a number of times and that
> one's always worked for me so here's hoping it's not what you tried...
>
> -Jon
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220330/a00f6c7a/attachment.htm>

From ildiko.vancsa at gmail.com  Thu Mar 31 00:20:16 2022
From: ildiko.vancsa at gmail.com (Ildiko Vancsa)
Date: Wed, 30 Mar 2022 17:20:16 -0700
Subject: [edge] Edge sessions at the PTG
Message-ID: <18EC428D-0BBE-40BD-B2C6-4D3BBB8ED6CE@gmail.com>

Hi,

I?m reaching out to you to draw your attention to the edge related sessions at the PTG next week.

As part of the event the OpenInfra Edge Computing Group[1] is meeting on three consecutive days, where we will talk about the challenges and steps to deploy and operate end-to-end edge infrastructures in production. Please join us if you have relevant experience, expertise or challenges to discuss requirements and solutions.

The time slots of the edge sessions are the following:

* Monday (April 4) at 1300 UTC - 1500 UTC
* Tuesday (April 5) at 1500 UTC - 1700 UTC
* Wednesday (April 6) at 1400 UTC - 1700 UTC

For further details about the session and agenda please check out this article: https://superuser.openstack.org/articles/edge-in-production-at-the-upcoming-project-teams-gathering/

Please let me know if you have any questions.

Thanks and Best Regards,
Ildik? V?ncsa

[1] https://wiki.openstack.org/wiki/Edge_Computing_Group





From haleyb.dev at gmail.com  Thu Mar 31 00:55:11 2022
From: haleyb.dev at gmail.com (Brian Haley)
Date: Wed, 30 Mar 2022 20:55:11 -0400
Subject: [neutron] [kolla] Static routes added to subnets after upgrading
 from Queens to Train
In-Reply-To: <242099798.347726.1648668427206@mail.yahoo.com>
References: <997697892.1640950.1648587862872.ref@mail.yahoo.com>
 <997697892.1640950.1648587862872@mail.yahoo.com>
 <f195da6e-fb83-bcf1-64bc-1885377e07b3@gmail.com>
 <242099798.347726.1648668427206@mail.yahoo.com>
Message-ID: <2f5ea4b4-73a3-b6cc-2e7c-e6b7114117e4@gmail.com>

Hi,

On 3/30/22 15:27, Albert Braden wrote:
> The command that we use to create subnets looks like this:
> 
> openstack subnet create --no-dhcp --network trust --network-segment 
> trust-az1-seg --ip-version 4 --allocation-pool 
> start=10.52.160.14,end=10.52.160.235 --subnet-range 10.52.160.0/24 
> --dns-nameserver 10.10.10.10 --gateway 10.52.160.1 trust-az1

Since you're not specifying --host-route there should be none, can you 
paste the created object returned from this call since for me 
host_routes is blank (see below).

> My co-workers tell me that we also specified "--gateway" when we created 
> our Queens subnets, but this did not cause static routes to be created. 
> Did the handling of "--gateway" change from Queens to Train?

I don't believe so, and --gateway will default to the first IP in the 
subnet if not given so isn't required.

-Brian


$ openstack subnet create --subnet-pool 
f5e3f133-a932-4adc-9592-0b525aec278f --network private private-subnet-2
+----------------------+---------------------------+
| Field                | Value                     |
+----------------------+---------------------------+
| allocation_pools     | 10.0.0.66-10.0.0.126      |
| cidr                 | 10.0.0.64/26              |
| created_at           | 2022-03-30T17:38:40Z      |
| description          |                           |
| dns_nameservers      |                           |
| dns_publish_fixed_ip | None                      |
| enable_dhcp          | True                      |
| gateway_ip           | 10.0.0.65                 |
| host_routes          |                           |
| id                   | ce09a038-b918-4208-9a3d-c8c259ae7433 |
| ip_version           | 4                         |
| ipv6_address_mode    | None                      |
| ipv6_ra_mode         | None                      |
| name                 | private-subnet-2          |
| network_id           | baf6c62d-4cec-464e-a768-253074df8879 |
| project_id           | 657e6d647c0446438c1f06da70d79bed |
| revision_number      | 0                         | 
         | segment_id           | None                      | 

| service_types        |                           |
| subnetpool_id        | f5e3f133-a932-4adc-9592-0b525aec278f |
| tags                 |                           |
| updated_at           | 2022-03-30T17:38:40Z      |
+----------------------+---------------------------+

> On Wednesday, March 30, 2022, 01:45:52 PM EDT, Brian Haley 
> <haleyb.dev at gmail.com> wrote:
> 
> 
> Hi Albert,
> 
> On 3/29/22 17:04, Albert Braden wrote:
>  > After upgrading our kolla-ansible clusters from Queens to Train, we 
> are seeing static routes when we create subnets. We didn?t see this in 
> Queens. For example, in our de6 region we have a network called ?trust? 
> with 3 subnets:
>  >
>  > Subnet? ? ? ? ? ? ? ? CIDR? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Gateway
>  > trust-az1:? ? ? ? ? ? 10.52.160.0/22? 10.52.160.1
>  > trust-az2:? ? ? ? ? ? 10.52.164.0/22? 10.52.164.1
>  > trust-az3:? ? ? ? ? ? 10.52.168.0/22? 10.52.168.1
>  >
>  > Each of these subnets has 2 entries under ?host_routes:? that point 
> to the other two subnets. For example, subnet trust-az1 has these two 
> routes:
>  >
>  > host_routes? ? ? ? ? | destination='10.52.164.0/22', 
> gateway='10.52.160.1' |
>  > |? ? ? ? ? ? ? ? ? ? ? | destination='10.52.168.0/22', 
> gateway='10.52.160.1' |
>  >
>  > How can we prevent these host routes from being created in Train? Do 
> we need to change something in our config?
> 
> 
>  From the neutron side of things, host_routes of a subnet is not
> automatically calculated and filled-in, they have to be manually added.
> So perhaps this is something kolla is doing? At least on my Yoga setup
> it is completely blank using 'openstack subnet create ...' even with
> multiple subnets on a network.
> 
> How exactly are the subnets getting created?
> 
> -Brian
> 


From derekokeeffe85 at yahoo.ie  Thu Mar 31 08:07:55 2022
From: derekokeeffe85 at yahoo.ie (Derek O keeffe)
Date: Thu, 31 Mar 2022 08:07:55 +0000 (UTC)
Subject: Volume attached to removed instance
In-Reply-To: <CADO3vb7xOX=Ahyis8qzuRVJdOo02RoWMe41H+5dQPXaZ0+6UeA@mail.gmail.com>
References: <561681084.2529212.1648628172407.ref@mail.yahoo.com>
 <561681084.2529212.1648628172407@mail.yahoo.com>
 <20220330214051.r4h32saqulqqvmky@csail.mit.edu>
 <CADO3vb7xOX=Ahyis8qzuRVJdOo02RoWMe41H+5dQPXaZ0+6UeA@mail.gmail.com>
Message-ID: <357473757.218636.1648714075220@mail.yahoo.com>

 Hi Jonathan, Alan,
Thanks for the replies. Yep those are what we tried Alan and also tried yours Jonathan, it showed it actually still had an attachment so I removed that and set it from state "reserved" to "available".
We think we figured out after I sent the original mail that it's not an openstack issue, we have it backended on Quobyte and we can interact with all the other volumes there but not this particular one so we believe the issue is there.
Thanks for the help anyway.
Regards,Derek
    On Wednesday 30 March 2022, 23:52:30 IST, Alan Bishop <abishop at redhat.com> wrote:  
 
 

On Wed, Mar 30, 2022 at 2:42 PM Jonathan Proulx <jon at csail.mit.edu> wrote:

On Wed, Mar 30, 2022 at 08:16:12AM +0000, Derek O keeffe wrote:
:Hi all,
:We are having an issue with a volume. The volume was created and attached to an instance that was then deleted. We now need to attach the volume to another instance to rescue the data on it but it still thinks it's attached to the deleted instance and we can't "manage attachments" or view the details of the volume.

When you say

:We have tried forcing it from the cli to detach but with no luck. We were thinking of doing it through the DB but said we'd askhere first in case anyone has experienced the same and has a better way of approaching the issue. Thanks in advance.

is this what you tried?

cinder reset-state --attach-status detached <UUID>


Assuming your cloud is based on Queens or later, these commands may also help:
 cinder --os-volume-api-version 3.44 attachment-listcinder --os-volume-api-version 3.44 attachment-delete <attachment ID>
Alan



I've had the stale attachement problem a number of times and that
one's always worked for me so here's hoping it's not what you tried...

-Jon


  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220331/35e1afe4/attachment-0001.htm>

From hanguangyu2 at gmail.com  Thu Mar 31 09:19:34 2022
From: hanguangyu2 at gmail.com (=?UTF-8?B?6Z+p5YWJ5a6H?=)
Date: Thu, 31 Mar 2022 17:19:34 +0800
Subject: [Ironic]After deleting server on bare metal node, baremetal node
 clean failed because pxe dhcp no reply
Message-ID: <CAOirdiVWALdOVpaFrTgp4S9zmUJ0jAXM+4hfGkFEAMXd7912Kg@mail.gmail.com>

Hi all,

I have a OpenStack Victoria All-in-One environment, and I can deploy
os to bare metal by Ironic.
I use `openstack server create --flavor my-baremetal-flavor --nic
net-id=$PROVISION_UUID --image $whiole-disk-image BM-server-01` to get
a server successfully.

But if I delete server by "openstack server delete BM-server-01",
baremetal node will be clean. When baremetal node performs the clean
process, it enters the PXE phase, but its DHCP request cannot be
replied.

The log of ironic-conductor:
2022-03-31 11:40:42.572 63976 INFO ironic.conductor.task_manager
[req-9e92ea87-d48c-42ed-83fd-2f7f14a20984
8763be6de0434240803f305c895fced5 a1758405f9c24ae191543248ad65a447 -
default default] Node 4b243894-d651-4700-9a69-28ca3c60446f moved to
provision state "clean wait" from state "cleaning"; target provision
state is "available"
2022-03-31 12:11:06.694 63976 ERROR ironic.conductor.task_manager
[req-3ff5cebf-0895-4e85-bf75-4ac1d20b30f4 - - - - -] Node
4b243894-d651-4700-9a69-28ca3c60446f moved to provision state "clean
failed" from state "clean wait"; target provision state is "available"
2022-03-31 12:11:07.676 63976 INFO ironic.drivers.modules.network.flat
[-] Removing ports from cleaning network for node
4b243894-d651-4700-9a69-28ca3c60446f
2022-03-31 12:11:08.218 63976 INFO ironic.common.neutron [-]
Successfully removed node 4b243894-d651-4700-9a69-28ca3c60446f neutron
ports.
2022-03-31 12:11:08.222 63976 ERROR ironic.conductor.utils [-] Timeout
reached while cleaning the node. Please check if the ramdisk
responsible for the cleaning is running on the node. Failed on step
{}.

The log of tcpdump in openstack:
# tcpdump -n -S -i br-ex port 67 or port 68 or port 69
11:44:43.358657 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 18:9b:a5:81:46:b7, length 300
11:44:46.550963 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 18:9b:a5:81:46:b7, length 300
11:44:51.558266 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 18:9b:a5:81:46:b7, length 300
11:44:57.374583 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 18:9b:a5:81:46:b7, length 300
11:44:57.375096 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 18:9b:a5:81:46:b7, length 300
11:44:57.691646 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 18:9b:a5:81:46:b7, length 300
11:44:57.807714 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 18:9b:a5:81:46:b7, length 300
11:44:57.907428 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 18:9b:a5:81:46:b7, length 300
11:44:58.027351 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
BOOTP/DHCP, Request from 18:9b:a5:81:46:b7, length 300

The log of /var/log/neutron/dhcp-agent.log:
2022-03-31 11:40:18.373 47489 INFO neutron.agent.dhcp.agent [-]
Trigger reload_allocations for port admin_state_up=True,
allowed_address_pairs=[], binding:host_id=, binding:profile=,
binding:vif_details=, binding:vif_type=unbound,
binding:vnic_type=baremetal, created_at=2022-03-31T03:40:18Z,
description=, device_id=4b243894-d651-4700-9a69-28ca3c60446f,
device_owner=, extra_dhcp_opts=[],
fixed_ips=[<neutron.agent.linux.dhcp.DictModel object at
0x7f56d29aeeb8>], id=20e8d806-f976-4415-85f5-ed2df55978dc,
mac_address=fa:16:3e:f1:b3:aa, name=, network=admin_state_up=True,
availability_zone_hints=[], availability_zones=['nova'],
created_at=2022-03-28T08:39:24Z, description=,
id=faa2b805-7898-4fb2-ad51-49251da6e35e, ipv4_address_scope=None,
ipv6_address_scope=None, is_default=False, mtu=1500, name=provider1,
port_security_enabled=True,
project_id=a1758405f9c24ae191543248ad65a447,
provider:network_type=flat, provider:physical_network=provider,
provider:segmentation_id=None, revision_number=2,
router:external=True, shared=True, status=ACTIVE,
subnets=['2d5d4c2c-8c8c-44ef-92b4-a124ed52030f'], tags=[],
tenant_id=a1758405f9c24ae191543248ad65a447,
updated_at=2022-03-28T08:39:29Z, vlan_transparent=None,
network_id=faa2b805-7898-4fb2-ad51-49251da6e35e,
port_security_enabled=True,
project_id=a1758405f9c24ae191543248ad65a447, revision_number=1,
security_groups=['f574b5d0-8308-40f4-a8e5-81126b920e8f'], status=DOWN,
tags=[], tenant_id=a1758405f9c24ae191543248ad65a447,
updated_at=2022-03-31T03:40:18Z on network
_ns_name=qdhcp-faa2b805-7898-4fb2-ad51-49251da6e35e,
admin_state_up=True, availability_zone_hints=[],
availability_zones=['nova'], created_at=2022-03-28T08:39:24Z,
description=, id=faa2b805-7898-4fb2-ad51-49251da6e35e,
ipv4_address_scope=None, ipv6_address_scope=None, is_default=False,
mtu=1500, name=provider1, non_local_subnets=[],
port_security_enabled=True, ports=[<neutron.agent.linux.dhcp.DictModel
object at 0x7f56d3a16a98>],
project_id=a1758405f9c24ae191543248ad65a447,
provider:network_type=flat, provider:physical_network=provider,
provider:segmentation_id=None, revision_number=2,
router:external=True, shared=True, status=ACTIVE,
subnets=[<neutron.agent.linux.dhcp.DictModel object at
0x7f56d3a169d8>], tags=[], tenant_id=a1758405f9c24ae191543248ad65a447,
updated_at=2022-03-28T08:39:29Z, vlan_transparent=None
2022-03-31 11:40:18.516 47489 INFO neutron.agent.dhcp.agent
[req-9b1713fa-1082-4ccf-8c8b-e953beaf5e5d - - - - -] DHCP
configuration for ports {'20e8d806-f976-4415-85f5-ed2df55978dc'} is
completed
2022-03-31 11:40:19.517 47489 INFO neutron.agent.dhcp.agent [-]
Trigger reload_allocations for port admin_state_up=True,
allowed_address_pairs=[],
binding:host_id=4b243894-d651-4700-9a69-28ca3c60446f,
binding:profile=local_link_information=[<neutron.agent.linux.dhcp.DictModel
object at 0x7f56d29aeb28>], binding:vif_details=,
binding:vif_type=unbound, binding:vnic_type=baremetal,
created_at=2022-03-31T03:40:18Z, description=,
device_id=4b243894-d651-4700-9a69-28ca3c60446f,
device_owner=baremetal:none, extra_dhcp_opts=[],
fixed_ips=[<neutron.agent.linux.dhcp.DictModel object at
0x7f56d29aefa8>], id=20e8d806-f976-4415-85f5-ed2df55978dc,
mac_address=18:9b:a5:81:46:b7, name=,
network_id=faa2b805-7898-4fb2-ad51-49251da6e35e,
port_security_enabled=True,
project_id=a1758405f9c24ae191543248ad65a447, revision_number=2,
security_groups=['f574b5d0-8308-40f4-a8e5-81126b920e8f'], status=DOWN,
tags=[], tenant_id=a1758405f9c24ae191543248ad65a447,
updated_at=2022-03-31T03:40:19Z on network
_ns_name=qdhcp-faa2b805-7898-4fb2-ad51-49251da6e35e,
admin_state_up=True, availability_zone_hints=[],
availability_zones=['nova'], created_at=2022-03-28T08:39:24Z,
description=, id=faa2b805-7898-4fb2-ad51-49251da6e35e,
ipv4_address_scope=None, ipv6_address_scope=None, is_default=False,
mtu=1500, name=provider1, non_local_subnets=[],
port_security_enabled=True, ports=[<neutron.agent.linux.dhcp.DictModel
object at 0x7f56d3a16a98>, <neutron.agent.linux.dhcp.DictModel object
at 0x7f56d29aeaf8>], project_id=a1758405f9c24ae191543248ad65a447,
provider:network_type=flat, provider:physical_network=provider,
provider:segmentation_id=None, revision_number=2,
router:external=True, shared=True, status=ACTIVE,
subnets=[<neutron.agent.linux.dhcp.DictModel object at
0x7f56d3a169d8>], tags=[], tenant_id=a1758405f9c24ae191543248ad65a447,
updated_at=2022-03-28T08:39:29Z, vlan_transparent=None
2022-03-31 11:40:19.649 47489 INFO neutron.agent.dhcp.agent
[req-7b9253ec-0a60-4309-ac66-8e3ea167cbba - - - - -] DHCP
configuration for ports {'20e8d806-f976-4415-85f5-ed2df55978dc'} is
completed
2022-03-31 11:40:19.678 47489 INFO neutron.agent.dhcp.agent [-]
Trigger reload_allocations for port admin_state_up=True,
allowed_address_pairs=[],
binding:host_id=4b243894-d651-4700-9a69-28ca3c60446f,
binding:profile=local_link_information=[<neutron.agent.linux.dhcp.DictModel
object at 0x7f56d29c88e8>], binding:vif_details=,
binding:vif_type=binding_failed, binding:vnic_type=baremetal,
created_at=2022-03-31T03:40:18Z, description=,
device_id=4b243894-d651-4700-9a69-28ca3c60446f,
device_owner=baremetal:none, extra_dhcp_opts=[],
fixed_ips=[<neutron.agent.linux.dhcp.DictModel object at
0x7f56d29c8558>], id=20e8d806-f976-4415-85f5-ed2df55978dc,
mac_address=18:9b:a5:81:46:b7, name=,
network_id=faa2b805-7898-4fb2-ad51-49251da6e35e,
port_security_enabled=True,
project_id=a1758405f9c24ae191543248ad65a447, revision_number=3,
security_groups=['f574b5d0-8308-40f4-a8e5-81126b920e8f'], status=DOWN,
tags=[], tenant_id=a1758405f9c24ae191543248ad65a447,
updated_at=2022-03-31T03:40:19Z on network
_ns_name=qdhcp-faa2b805-7898-4fb2-ad51-49251da6e35e,
admin_state_up=True, availability_zone_hints=[],
availability_zones=['nova'], created_at=2022-03-28T08:39:24Z,
description=, id=faa2b805-7898-4fb2-ad51-49251da6e35e,
ipv4_address_scope=None, ipv6_address_scope=None, is_default=False,
mtu=1500, name=provider1, non_local_subnets=[],
port_security_enabled=True, ports=[<neutron.agent.linux.dhcp.DictModel
object at 0x7f56d3a16a98>, <neutron.agent.linux.dhcp.DictModel object
at 0x7f56d28b53d8>], project_id=a1758405f9c24ae191543248ad65a447,
provider:network_type=flat, provider:physical_network=provider,
provider:segmentation_id=None, revision_number=2,
router:external=True, shared=True, status=ACTIVE,
subnets=[<neutron.agent.linux.dhcp.DictModel object at
0x7f56d3a169d8>], tags=[], tenant_id=a1758405f9c24ae191543248ad65a447,
updated_at=2022-03-28T08:39:29Z, vlan_transparent=None
2022-03-31 11:40:19.776 47489 INFO neutron.agent.dhcp.agent
[req-99eb793a-230c-490a-b126-ee9b595ed1bf - - - - -] DHCP
configuration for ports {'20e8d806-f976-4415-85f5-ed2df55978dc'} is
completed
2022-03-31 11:40:21.082 47489 INFO neutron.agent.dhcp.agent [-]
Trigger reload_allocations for port admin_state_up=True,
allowed_address_pairs=[],
binding:host_id=4b243894-d651-4700-9a69-28ca3c60446f,
binding:profile=local_link_information=[<neutron.agent.linux.dhcp.DictModel
object at 0x7f56d288ea68>], binding:vif_details=,
binding:vif_type=binding_failed, binding:vnic_type=baremetal,
created_at=2022-03-31T03:40:18Z, description=,
device_id=4b243894-d651-4700-9a69-28ca3c60446f,
device_owner=baremetal:none,
extra_dhcp_opts=[<neutron.agent.linux.dhcp.DictModel object at
0x7f56d288e9a8>, <neutron.agent.linux.dhcp.DictModel object at
0x7f56d288ed38>, <neutron.agent.linux.dhcp.DictModel object at
0x7f56d288e4f8>, <neutron.agent.linux.dhcp.DictModel object at
0x7f56d288e528>, <neutron.agent.linux.dhcp.DictModel object at
0x7f56d288e948>], fixed_ips=[<neutron.agent.linux.dhcp.DictModel
object at 0x7f56d288e0a8>], id=20e8d806-f976-4415-85f5-ed2df55978dc,
mac_address=18:9b:a5:81:46:b7, name=,
network_id=faa2b805-7898-4fb2-ad51-49251da6e35e,
port_security_enabled=True,
project_id=a1758405f9c24ae191543248ad65a447, revision_number=4,
security_groups=['f574b5d0-8308-40f4-a8e5-81126b920e8f'], status=DOWN,
tags=[], tenant_id=a1758405f9c24ae191543248ad65a447,
updated_at=2022-03-31T03:40:21Z on network
_ns_name=qdhcp-faa2b805-7898-4fb2-ad51-49251da6e35e,
admin_state_up=True, availability_zone_hints=[],
availability_zones=['nova'], created_at=2022-03-28T08:39:24Z,
description=, id=faa2b805-7898-4fb2-ad51-49251da6e35e,
ipv4_address_scope=None, ipv6_address_scope=None, is_default=False,
mtu=1500, name=provider1, non_local_subnets=[],
port_security_enabled=True, ports=[<neutron.agent.linux.dhcp.DictModel
object at 0x7f56d3a16a98>, <neutron.agent.linux.dhcp.DictModel object
at 0x7f56d29c8eb8>], project_id=a1758405f9c24ae191543248ad65a447,
provider:network_type=flat, provider:physical_network=provider,
provider:segmentation_id=None, revision_number=2,
router:external=True, shared=True, status=ACTIVE,
subnets=[<neutron.agent.linux.dhcp.DictModel object at
0x7f56d3a169d8>], tags=[], tenant_id=a1758405f9c24ae191543248ad65a447,
updated_at=2022-03-28T08:39:29Z, vlan_transparent=None
2022-03-31 11:40:21.207 47489 INFO neutron.agent.dhcp.agent
[req-d7cb57c1-4cda-4ceb-99ca-18ca650db61b - - - - -] DHCP
configuration for ports {'20e8d806-f976-4415-85f5-ed2df55978dc'} is
completed


I would very appreciate any kind of guidance or help.

Thank you,
Han Guangyu


From mark at stackhpc.com  Thu Mar 31 09:31:09 2022
From: mark at stackhpc.com (Mark Goddard)
Date: Thu, 31 Mar 2022 10:31:09 +0100
Subject: [monasca][neutron][venus][release][kolla] Missing yoga tarballs
Message-ID: <CAFHSqWoFi_J6bdYPfuA1bPL5Aw9o9ZiR5_oN-BB+_PsXMuS1iA@mail.gmail.com>

Hi,

In kolla we are trying to switch to the yoga branch tarballs in our images
as part of our release process. The following projects lack these:

* monasca-api: stable/yoga exists, but no additional commits yet, so
no tarball. Could someone merge the release bot patches for stable/yoga?

* neutron-vpnaas-dashboard: stable/yoga exists, but no additional commits
yet, so no tarball. Could someone merge the release bot patches for
stable/yoga?

* venus: no stable/yoga branch yet. Looks like the review for the
deliverable files is still open:
https://review.opendev.org/c/openstack/releases/+/824394

Thanks,
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220331/5d344f3c/attachment.htm>

From zigo at debian.org  Thu Mar 31 10:14:11 2022
From: zigo at debian.org (Thomas Goirand)
Date: Thu, 31 Mar 2022 12:14:11 +0200
Subject: [yoga][horizon] Broken Horizon plugins UT: murano-dashboard,
 magnum-ui, heat-dashboard
Message-ID: <706d5bb9-9153-49f1-1010-e0ba0bfa397b@debian.org>

Hi,

Building Horizon plugins for yoga after upgrading to Horizon 22.1.0 lead 
me to broken unit tests. I haven't filed separate bugs yet, as I'd like 
to have the opinion of upstream about what's going on first.

I've pushed the build logs over here:

http://shade.infomaniak.ch/yoga-dashboard-plugins-build-logs/

So, what's going on? :)

Cheers,

Thomas Goirand (zigo)

P.S: These are the last remaining failed to build issues I have for 
Yoga, everything else has been uploaded already.


From mnasiadka at gmail.com  Thu Mar 31 11:51:26 2022
From: mnasiadka at gmail.com (=?utf-8?Q?Micha=C5=82_Nasiadka?=)
Date: Thu, 31 Mar 2022 13:51:26 +0200
Subject: [kolla] Zed PTG Schedule && cancel weekly meeting 6th April
Message-ID: <B407DDD5-721E-4569-BD58-5AD8A6F935D3@gmail.com>

Hello Koalas,

The PTG is going to take place next week (April 4th to 8th).
Kolla sessions are planned Mon/Tue 13-17UTC (Kolla/Kolla-Ansible) and Wed 13-15 UTC (Kayobe slot) in Havana room.

NOTE: The weekly team meeting on 6th April is cancelled - since we?ll all be discussing Kayobe on the PTG then.

If you haven't registered yet, there's still time! Please register here [2].

[1] https://etherpad.opendev.org/p/ <https://etherpad.opendev.org/p/>kolla-zed-ptg
[2] https://openinfra-ptg.eventbrite.com/ <https://openinfra-ptg.eventbrite.com/>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220331/a5efc937/attachment.htm>

From thierry at openstack.org  Thu Mar 31 11:58:49 2022
From: thierry at openstack.org (Thierry Carrez)
Date: Thu, 31 Mar 2022 13:58:49 +0200
Subject: [largescale-sig] Next meeting: Mar 30th, 15utc
In-Reply-To: <fea369e2-f99b-e2dd-524e-2bbd75a4f831@openstack.org>
References: <fea369e2-f99b-e2dd-524e-2bbd75a4f831@openstack.org>
Message-ID: <84df9b07-63fd-2ebb-414a-244d083d63f8@openstack.org>

Yesterday we had a short SIG meeting.

We discussed the Ops Deep Dive: Yahoo" upcoming OpenInfra.Live episode, 
as well as topics to discuss during our PTG meeting next week.

You can read the meeting logs at:
https://meetings.opendev.org/meetings/large_scale_sig/2022/large_scale_sig.2022-03-30-15.00.html

Next week we will meet in a video meeting during the PTG:
Wed April 6, 15UTC in the "Kilo" room.

To get more information you can register for the event for free at:
https://openinfra-ptg.eventbrite.com

Our next IRC meeting will be April 27, at 1500utc on 
#openstack-operators on OFTC.

Regards,

-- 
Thierry Carrez


From katonalala at gmail.com  Thu Mar 31 13:38:48 2022
From: katonalala at gmail.com (Lajos Katona)
Date: Thu, 31 Mar 2022 15:38:48 +0200
Subject: [monasca][neutron][venus][release][kolla] Missing yoga tarballs
In-Reply-To: <CAFHSqWoFi_J6bdYPfuA1bPL5Aw9o9ZiR5_oN-BB+_PsXMuS1iA@mail.gmail.com>
References: <CAFHSqWoFi_J6bdYPfuA1bPL5Aw9o9ZiR5_oN-BB+_PsXMuS1iA@mail.gmail.com>
Message-ID: <CALg0jKmcrO7sC97naQMQFZC8fEwbPvxvEZSWJjQXWFaexKD9iA@mail.gmail.com>

Hi,
Thanks for heads up.
I will check neutron-vpnaas-dashboard, but it seems we lost the maintainers
of vpnaas, so even neutron-vpnaas gate seems to be red currently.
We will anyway spend a slot for such low activity networking projects.

Lajos Katona (lajoskatona)

Mark Goddard <mark at stackhpc.com> ezt ?rta (id?pont: 2022. m?rc. 31., Cs,
11:38):

> Hi,
>
> In kolla we are trying to switch to the yoga branch tarballs in our images
> as part of our release process. The following projects lack these:
>
> * monasca-api: stable/yoga exists, but no additional commits yet, so
> no tarball. Could someone merge the release bot patches for stable/yoga?
>
> * neutron-vpnaas-dashboard: stable/yoga exists, but no additional commits
> yet, so no tarball. Could someone merge the release bot patches for
> stable/yoga?
>
> * venus: no stable/yoga branch yet. Looks like the review for the
> deliverable files is still open:
> https://review.opendev.org/c/openstack/releases/+/824394
>
> Thanks,
> Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220331/429703f3/attachment.htm>

From federica.fanzago at pd.infn.it  Thu Mar 31 10:31:33 2022
From: federica.fanzago at pd.infn.it (federica fanzago)
Date: Thu, 31 Mar 2022 12:31:33 +0200
Subject: Openstack Xena: error deleting image and snapshot via dashboard (as
 user and as admin)
Message-ID: <dedfa947-110a-5767-a3c5-5c5296d2e0d8@pd.infn.it>

Hi all,

we have installed Openstack Xena in our cloud infrastructure (OS 
Centos-Stream 8) and we find a problem with the delete of images and 
snapshots via dashboard. The delete command returns "Error: Unable to 
delete Image:xxx"

Via command line the delete works well.

Looking in glance logs? I don't find any error message.

Did you experienced this problem? Have you suggestions about it?

Thanks,

cheers

 ??? Federica


-- 
Federica Fanzago
INFN Sezione di Padova
Via Marzolo, 8
35131 Padova - Italy

Tel: +39 049.967.7367
--



From bence.romsics at gmail.com  Thu Mar 31 14:03:26 2022
From: bence.romsics at gmail.com (Bence Romsics)
Date: Thu, 31 Mar 2022 16:03:26 +0200
Subject: [neutron] bug deputy report of week 2022-03-21
Message-ID: <CAHeS+3_ya3jD6tnUM0oMHC7XjFPH-MLAmvf_HNJSg575H_bcJA@mail.gmail.com>

Hi Team,

Once again sorry for the late report.

Needs attention:
ovn-octavia-provider maintainers please have a look at the the two
ovn-octavia-provider bugs below.

Critical:
* https://bugs.launchpad.net/neutron/+bug/1966394
Functional tests hits oom-killer which is causing job failures
gate failure, fix proposed:
https://review.opendev.org/c/openstack/neutron/+/835179
* https://bugs.launchpad.net/neutron/+bug/1966035
neutron.tests.functional.agent.test_dhcp_agent.DHCPAgentOVSTestCase.test_good_address_allocation
is failing intermittently
One-off gate failure that we cannot reproduce, may need to be looked
at again if it recurs.

Medium:
* https://bugs.launchpad.net/neutron/+bug/1965819
list object has no attribute 'acked'
fix in ovdbapp merged and backported to wallaby:
https://review.opendev.org/q/Iad0d7472a7adce4a79111f94a2f33fc5b1a5c530
proposed fix in neutron waiting for ovsdbapp release:
https://review.opendev.org/c/openstack/neutron/+/834613

ovn-octavia-provider:
* https://bugs.launchpad.net/neutron/+bug/1965772
ovn-octavia-provider does not report status correctly to octavia
* https://bugs.launchpad.net/neutron/+bug/1966052
ovn-octavia-provider associates to wrong logical router when
LogicalRouterPortEvent is fired and network has multiple routers

Incomplete:
* https://bugs.launchpad.net/neutron/+bug/1966383
ovs-agent: value -1 is not a valid port number when _set_port_filters
* https://bugs.launchpad.net/neutron/+bug/1966121
[neutron-tempest-plugin] Test fails with AttributeError: type object
'DNSIntegrationTests' has no attribute 'query_client'
Probably not a bug in code, but a dependency error in the reporter's
environment.

Invalid:
* https://bugs.launchpad.net/neutron/+bug/1966403
Cres_Ubuntu 20.04,CI,Checkbox TPM test failed

Cheers,
Bence


From zigo at debian.org  Thu Mar 31 14:05:59 2022
From: zigo at debian.org (Thomas Goirand)
Date: Thu, 31 Mar 2022 16:05:59 +0200
Subject: [yoga][horizon] Broken Horizon plugins UT: murano-dashboard,
 magnum-ui, heat-dashboard
In-Reply-To: <706d5bb9-9153-49f1-1010-e0ba0bfa397b@debian.org>
References: <706d5bb9-9153-49f1-1010-e0ba0bfa397b@debian.org>
Message-ID: <18213530-40b1-c70b-49a1-dec74559a613@debian.org>

On 3/31/22 12:14, Thomas Goirand wrote:
> Hi,
> 
> Building Horizon plugins for yoga after upgrading to Horizon 22.1.0 lead 
> me to broken unit tests. I haven't filed separate bugs yet, as I'd like 
> to have the opinion of upstream about what's going on first.
> 
> I've pushed the build logs over here:
> 
> http://shade.infomaniak.ch/yoga-dashboard-plugins-build-logs/
> 
> So, what's going on? :)
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 
> P.S: These are the last remaining failed to build issues I have for 
> Yoga, everything else has been uploaded already.
> 

I found out that these are the fixes:
https://review.opendev.org/c/openstack/heat-dashboard/+/835890
https://review.opendev.org/c/openstack/magnum-ui/+/835963
https://review.opendev.org/c/openstack/murano-dashboard/+/835781

I still have this after applying the murano-dashboard patch though:

======================================================================
ERROR: test_get_data_except_glance_image_list_exception 
(muranodashboard.tests.unit.images.test_views.TestMarkedImagesView)
Test that glance_v1_client.images.list exception is handled.
----------------------------------------------------------------------
Traceback (most recent call last):
   File "/<<PKGBUILDDIR>>/muranodashboard/images/views.py", line 68, in 
get_data
     images_iter = glance_v2_client.images.list(
   File "/usr/lib/python3.10/unittest/mock.py", line 1104, in __call__
     return self._mock_call(*args, **kwargs)
   File "/usr/lib/python3.10/unittest/mock.py", line 1108, in _mock_call
     return self._execute_mock_call(*args, **kwargs)
   File "/usr/lib/python3.10/unittest/mock.py", line 1163, in 
_execute_mock_call
     raise effect
Exception

Thanks a lot Vishal Manchanda for your work!

Cheers,

Thomas Goirand (zigo)


From juliaashleykreger at gmail.com  Thu Mar 31 14:07:12 2022
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Thu, 31 Mar 2022 07:07:12 -0700
Subject: [Ironic]After deleting server on bare metal node, baremetal node
 clean failed because pxe dhcp no reply
In-Reply-To: <CAOirdiVWALdOVpaFrTgp4S9zmUJ0jAXM+4hfGkFEAMXd7912Kg@mail.gmail.com>
References: <CAOirdiVWALdOVpaFrTgp4S9zmUJ0jAXM+4hfGkFEAMXd7912Kg@mail.gmail.com>
Message-ID: <CAF7gwdiNUNxDEQ9dyJM-AU8dD1p=4LpgEDb_6p5P=NZOpfG0_Q@mail.gmail.com>

Can you see the dhcp packets in the network namespace dnsmasq is running in?

ip netns list
ip netns exec <namespace> ip addr
ip netns exec <namespace> tcpdump -i <interface from namespace> <add
your filters and remaining tcpdump parameters here>

On Thu, Mar 31, 2022 at 2:23 AM ??? <hanguangyu2 at gmail.com> wrote:
>
> Hi all,
>
> I have a OpenStack Victoria All-in-One environment, and I can deploy
> os to bare metal by Ironic.
> I use `openstack server create --flavor my-baremetal-flavor --nic
> net-id=$PROVISION_UUID --image $whiole-disk-image BM-server-01` to get
> a server successfully.
>
> But if I delete server by "openstack server delete BM-server-01",
> baremetal node will be clean. When baremetal node performs the clean
> process, it enters the PXE phase, but its DHCP request cannot be
> replied.
>
> The log of ironic-conductor:
> 2022-03-31 11:40:42.572 63976 INFO ironic.conductor.task_manager
> [req-9e92ea87-d48c-42ed-83fd-2f7f14a20984
> 8763be6de0434240803f305c895fced5 a1758405f9c24ae191543248ad65a447 -
> default default] Node 4b243894-d651-4700-9a69-28ca3c60446f moved to
> provision state "clean wait" from state "cleaning"; target provision
> state is "available"
> 2022-03-31 12:11:06.694 63976 ERROR ironic.conductor.task_manager
> [req-3ff5cebf-0895-4e85-bf75-4ac1d20b30f4 - - - - -] Node
> 4b243894-d651-4700-9a69-28ca3c60446f moved to provision state "clean
> failed" from state "clean wait"; target provision state is "available"
> 2022-03-31 12:11:07.676 63976 INFO ironic.drivers.modules.network.flat
> [-] Removing ports from cleaning network for node
> 4b243894-d651-4700-9a69-28ca3c60446f
> 2022-03-31 12:11:08.218 63976 INFO ironic.common.neutron [-]
> Successfully removed node 4b243894-d651-4700-9a69-28ca3c60446f neutron
> ports.
> 2022-03-31 12:11:08.222 63976 ERROR ironic.conductor.utils [-] Timeout
> reached while cleaning the node. Please check if the ramdisk
> responsible for the cleaning is running on the node. Failed on step
> {}.
>
> The log of tcpdump in openstack:
> # tcpdump -n -S -i br-ex port 67 or port 68 or port 69
> 11:44:43.358657 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
> BOOTP/DHCP, Request from 18:9b:a5:81:46:b7, length 300
> 11:44:46.550963 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
> BOOTP/DHCP, Request from 18:9b:a5:81:46:b7, length 300
> 11:44:51.558266 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
> BOOTP/DHCP, Request from 18:9b:a5:81:46:b7, length 300
> 11:44:57.374583 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
> BOOTP/DHCP, Request from 18:9b:a5:81:46:b7, length 300
> 11:44:57.375096 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
> BOOTP/DHCP, Request from 18:9b:a5:81:46:b7, length 300
> 11:44:57.691646 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
> BOOTP/DHCP, Request from 18:9b:a5:81:46:b7, length 300
> 11:44:57.807714 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
> BOOTP/DHCP, Request from 18:9b:a5:81:46:b7, length 300
> 11:44:57.907428 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
> BOOTP/DHCP, Request from 18:9b:a5:81:46:b7, length 300
> 11:44:58.027351 IP 0.0.0.0.bootpc > 255.255.255.255.bootps:
> BOOTP/DHCP, Request from 18:9b:a5:81:46:b7, length 300
>
> The log of /var/log/neutron/dhcp-agent.log:
> 2022-03-31 11:40:18.373 47489 INFO neutron.agent.dhcp.agent [-]
> Trigger reload_allocations for port admin_state_up=True,
> allowed_address_pairs=[], binding:host_id=, binding:profile=,
> binding:vif_details=, binding:vif_type=unbound,
> binding:vnic_type=baremetal, created_at=2022-03-31T03:40:18Z,
> description=, device_id=4b243894-d651-4700-9a69-28ca3c60446f,
> device_owner=, extra_dhcp_opts=[],
> fixed_ips=[<neutron.agent.linux.dhcp.DictModel object at
> 0x7f56d29aeeb8>], id=20e8d806-f976-4415-85f5-ed2df55978dc,
> mac_address=fa:16:3e:f1:b3:aa, name=, network=admin_state_up=True,
> availability_zone_hints=[], availability_zones=['nova'],
> created_at=2022-03-28T08:39:24Z, description=,
> id=faa2b805-7898-4fb2-ad51-49251da6e35e, ipv4_address_scope=None,
> ipv6_address_scope=None, is_default=False, mtu=1500, name=provider1,
> port_security_enabled=True,
> project_id=a1758405f9c24ae191543248ad65a447,
> provider:network_type=flat, provider:physical_network=provider,
> provider:segmentation_id=None, revision_number=2,
> router:external=True, shared=True, status=ACTIVE,
> subnets=['2d5d4c2c-8c8c-44ef-92b4-a124ed52030f'], tags=[],
> tenant_id=a1758405f9c24ae191543248ad65a447,
> updated_at=2022-03-28T08:39:29Z, vlan_transparent=None,
> network_id=faa2b805-7898-4fb2-ad51-49251da6e35e,
> port_security_enabled=True,
> project_id=a1758405f9c24ae191543248ad65a447, revision_number=1,
> security_groups=['f574b5d0-8308-40f4-a8e5-81126b920e8f'], status=DOWN,
> tags=[], tenant_id=a1758405f9c24ae191543248ad65a447,
> updated_at=2022-03-31T03:40:18Z on network
> _ns_name=qdhcp-faa2b805-7898-4fb2-ad51-49251da6e35e,
> admin_state_up=True, availability_zone_hints=[],
> availability_zones=['nova'], created_at=2022-03-28T08:39:24Z,
> description=, id=faa2b805-7898-4fb2-ad51-49251da6e35e,
> ipv4_address_scope=None, ipv6_address_scope=None, is_default=False,
> mtu=1500, name=provider1, non_local_subnets=[],
> port_security_enabled=True, ports=[<neutron.agent.linux.dhcp.DictModel
> object at 0x7f56d3a16a98>],
> project_id=a1758405f9c24ae191543248ad65a447,
> provider:network_type=flat, provider:physical_network=provider,
> provider:segmentation_id=None, revision_number=2,
> router:external=True, shared=True, status=ACTIVE,
> subnets=[<neutron.agent.linux.dhcp.DictModel object at
> 0x7f56d3a169d8>], tags=[], tenant_id=a1758405f9c24ae191543248ad65a447,
> updated_at=2022-03-28T08:39:29Z, vlan_transparent=None
> 2022-03-31 11:40:18.516 47489 INFO neutron.agent.dhcp.agent
> [req-9b1713fa-1082-4ccf-8c8b-e953beaf5e5d - - - - -] DHCP
> configuration for ports {'20e8d806-f976-4415-85f5-ed2df55978dc'} is
> completed
> 2022-03-31 11:40:19.517 47489 INFO neutron.agent.dhcp.agent [-]
> Trigger reload_allocations for port admin_state_up=True,
> allowed_address_pairs=[],
> binding:host_id=4b243894-d651-4700-9a69-28ca3c60446f,
> binding:profile=local_link_information=[<neutron.agent.linux.dhcp.DictModel
> object at 0x7f56d29aeb28>], binding:vif_details=,
> binding:vif_type=unbound, binding:vnic_type=baremetal,
> created_at=2022-03-31T03:40:18Z, description=,
> device_id=4b243894-d651-4700-9a69-28ca3c60446f,
> device_owner=baremetal:none, extra_dhcp_opts=[],
> fixed_ips=[<neutron.agent.linux.dhcp.DictModel object at
> 0x7f56d29aefa8>], id=20e8d806-f976-4415-85f5-ed2df55978dc,
> mac_address=18:9b:a5:81:46:b7, name=,
> network_id=faa2b805-7898-4fb2-ad51-49251da6e35e,
> port_security_enabled=True,
> project_id=a1758405f9c24ae191543248ad65a447, revision_number=2,
> security_groups=['f574b5d0-8308-40f4-a8e5-81126b920e8f'], status=DOWN,
> tags=[], tenant_id=a1758405f9c24ae191543248ad65a447,
> updated_at=2022-03-31T03:40:19Z on network
> _ns_name=qdhcp-faa2b805-7898-4fb2-ad51-49251da6e35e,
> admin_state_up=True, availability_zone_hints=[],
> availability_zones=['nova'], created_at=2022-03-28T08:39:24Z,
> description=, id=faa2b805-7898-4fb2-ad51-49251da6e35e,
> ipv4_address_scope=None, ipv6_address_scope=None, is_default=False,
> mtu=1500, name=provider1, non_local_subnets=[],
> port_security_enabled=True, ports=[<neutron.agent.linux.dhcp.DictModel
> object at 0x7f56d3a16a98>, <neutron.agent.linux.dhcp.DictModel object
> at 0x7f56d29aeaf8>], project_id=a1758405f9c24ae191543248ad65a447,
> provider:network_type=flat, provider:physical_network=provider,
> provider:segmentation_id=None, revision_number=2,
> router:external=True, shared=True, status=ACTIVE,
> subnets=[<neutron.agent.linux.dhcp.DictModel object at
> 0x7f56d3a169d8>], tags=[], tenant_id=a1758405f9c24ae191543248ad65a447,
> updated_at=2022-03-28T08:39:29Z, vlan_transparent=None
> 2022-03-31 11:40:19.649 47489 INFO neutron.agent.dhcp.agent
> [req-7b9253ec-0a60-4309-ac66-8e3ea167cbba - - - - -] DHCP
> configuration for ports {'20e8d806-f976-4415-85f5-ed2df55978dc'} is
> completed
> 2022-03-31 11:40:19.678 47489 INFO neutron.agent.dhcp.agent [-]
> Trigger reload_allocations for port admin_state_up=True,
> allowed_address_pairs=[],
> binding:host_id=4b243894-d651-4700-9a69-28ca3c60446f,
> binding:profile=local_link_information=[<neutron.agent.linux.dhcp.DictModel
> object at 0x7f56d29c88e8>], binding:vif_details=,
> binding:vif_type=binding_failed, binding:vnic_type=baremetal,
> created_at=2022-03-31T03:40:18Z, description=,
> device_id=4b243894-d651-4700-9a69-28ca3c60446f,
> device_owner=baremetal:none, extra_dhcp_opts=[],
> fixed_ips=[<neutron.agent.linux.dhcp.DictModel object at
> 0x7f56d29c8558>], id=20e8d806-f976-4415-85f5-ed2df55978dc,
> mac_address=18:9b:a5:81:46:b7, name=,
> network_id=faa2b805-7898-4fb2-ad51-49251da6e35e,
> port_security_enabled=True,
> project_id=a1758405f9c24ae191543248ad65a447, revision_number=3,
> security_groups=['f574b5d0-8308-40f4-a8e5-81126b920e8f'], status=DOWN,
> tags=[], tenant_id=a1758405f9c24ae191543248ad65a447,
> updated_at=2022-03-31T03:40:19Z on network
> _ns_name=qdhcp-faa2b805-7898-4fb2-ad51-49251da6e35e,
> admin_state_up=True, availability_zone_hints=[],
> availability_zones=['nova'], created_at=2022-03-28T08:39:24Z,
> description=, id=faa2b805-7898-4fb2-ad51-49251da6e35e,
> ipv4_address_scope=None, ipv6_address_scope=None, is_default=False,
> mtu=1500, name=provider1, non_local_subnets=[],
> port_security_enabled=True, ports=[<neutron.agent.linux.dhcp.DictModel
> object at 0x7f56d3a16a98>, <neutron.agent.linux.dhcp.DictModel object
> at 0x7f56d28b53d8>], project_id=a1758405f9c24ae191543248ad65a447,
> provider:network_type=flat, provider:physical_network=provider,
> provider:segmentation_id=None, revision_number=2,
> router:external=True, shared=True, status=ACTIVE,
> subnets=[<neutron.agent.linux.dhcp.DictModel object at
> 0x7f56d3a169d8>], tags=[], tenant_id=a1758405f9c24ae191543248ad65a447,
> updated_at=2022-03-28T08:39:29Z, vlan_transparent=None
> 2022-03-31 11:40:19.776 47489 INFO neutron.agent.dhcp.agent
> [req-99eb793a-230c-490a-b126-ee9b595ed1bf - - - - -] DHCP
> configuration for ports {'20e8d806-f976-4415-85f5-ed2df55978dc'} is
> completed
> 2022-03-31 11:40:21.082 47489 INFO neutron.agent.dhcp.agent [-]
> Trigger reload_allocations for port admin_state_up=True,
> allowed_address_pairs=[],
> binding:host_id=4b243894-d651-4700-9a69-28ca3c60446f,
> binding:profile=local_link_information=[<neutron.agent.linux.dhcp.DictModel
> object at 0x7f56d288ea68>], binding:vif_details=,
> binding:vif_type=binding_failed, binding:vnic_type=baremetal,
> created_at=2022-03-31T03:40:18Z, description=,
> device_id=4b243894-d651-4700-9a69-28ca3c60446f,
> device_owner=baremetal:none,
> extra_dhcp_opts=[<neutron.agent.linux.dhcp.DictModel object at
> 0x7f56d288e9a8>, <neutron.agent.linux.dhcp.DictModel object at
> 0x7f56d288ed38>, <neutron.agent.linux.dhcp.DictModel object at
> 0x7f56d288e4f8>, <neutron.agent.linux.dhcp.DictModel object at
> 0x7f56d288e528>, <neutron.agent.linux.dhcp.DictModel object at
> 0x7f56d288e948>], fixed_ips=[<neutron.agent.linux.dhcp.DictModel
> object at 0x7f56d288e0a8>], id=20e8d806-f976-4415-85f5-ed2df55978dc,
> mac_address=18:9b:a5:81:46:b7, name=,
> network_id=faa2b805-7898-4fb2-ad51-49251da6e35e,
> port_security_enabled=True,
> project_id=a1758405f9c24ae191543248ad65a447, revision_number=4,
> security_groups=['f574b5d0-8308-40f4-a8e5-81126b920e8f'], status=DOWN,
> tags=[], tenant_id=a1758405f9c24ae191543248ad65a447,
> updated_at=2022-03-31T03:40:21Z on network
> _ns_name=qdhcp-faa2b805-7898-4fb2-ad51-49251da6e35e,
> admin_state_up=True, availability_zone_hints=[],
> availability_zones=['nova'], created_at=2022-03-28T08:39:24Z,
> description=, id=faa2b805-7898-4fb2-ad51-49251da6e35e,
> ipv4_address_scope=None, ipv6_address_scope=None, is_default=False,
> mtu=1500, name=provider1, non_local_subnets=[],
> port_security_enabled=True, ports=[<neutron.agent.linux.dhcp.DictModel
> object at 0x7f56d3a16a98>, <neutron.agent.linux.dhcp.DictModel object
> at 0x7f56d29c8eb8>], project_id=a1758405f9c24ae191543248ad65a447,
> provider:network_type=flat, provider:physical_network=provider,
> provider:segmentation_id=None, revision_number=2,
> router:external=True, shared=True, status=ACTIVE,
> subnets=[<neutron.agent.linux.dhcp.DictModel object at
> 0x7f56d3a169d8>], tags=[], tenant_id=a1758405f9c24ae191543248ad65a447,
> updated_at=2022-03-28T08:39:29Z, vlan_transparent=None
> 2022-03-31 11:40:21.207 47489 INFO neutron.agent.dhcp.agent
> [req-d7cb57c1-4cda-4ceb-99ca-18ca650db61b - - - - -] DHCP
> configuration for ports {'20e8d806-f976-4415-85f5-ed2df55978dc'} is
> completed
>
>
> I would very appreciate any kind of guidance or help.
>
> Thank you,
> Han Guangyu
>


From aaronzhu1121 at gmail.com  Thu Mar 31 14:24:42 2022
From: aaronzhu1121 at gmail.com (aaronzhu1121)
Date: Thu, 31 Mar 2022 22:24:42 +0800
Subject: [yoga][horizon] Broken Horizon plugins UT:
 murano-dashboard, magnum-ui, heat-dashboard
In-Reply-To: <18213530-40b1-c70b-49a1-dec74559a613@debian.org>
References: <706d5bb9-9153-49f1-1010-e0ba0bfa397b@debian.org>
Message-ID: <FA6E57B7-A3D8-4CC0-9053-AE4FCD015CF2@gmail.com>

An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220331/e7c4e574/attachment.htm>

From ces.eduardo98 at gmail.com  Thu Mar 31 16:06:37 2022
From: ces.eduardo98 at gmail.com (Carlos Silva)
Date: Thu, 31 Mar 2022 13:06:37 -0300
Subject: [manila] Cancelling weekly meetings on the 7th and 14th
Message-ID: <CAE51gQJDqsVO=PE4GAt2mrgiFhbN6D6m1kcLJP3tG6xqTvpfQw@mail.gmail.com>

Hello, zorillas!

During today's meeting we agreed that we would cancel the next week's
weekly meeting, as well as the meeting in the week after that.

So we will be getting back to the regular manila meetings on April 21st.

Thank you!
carloss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220331/2607e382/attachment.htm>

From sbauza at redhat.com  Thu Mar 31 16:49:50 2022
From: sbauza at redhat.com (Sylvain Bauza)
Date: Thu, 31 Mar 2022 18:49:50 +0200
Subject: [nova][placement] Nova meeting on Apr 5th CANCELLED
Message-ID: <CALOCmunPZX2wNSpK8T0mhN=tB-UW01f7G0XV0Z-60RjVfcFHWQ@mail.gmail.com>

Forgot to send this email before, but obviously let's cancel next week's
Nova meeting as we'll see us virtually at the PTG.

-Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220331/cb7b3182/attachment.htm>

From rdhasman at redhat.com  Thu Mar 31 18:18:06 2022
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Thu, 31 Mar 2022 23:48:06 +0530
Subject: [cinder] Cancelling cinder meeting on 6th April
Message-ID: <CAARK8KSxJfh4HBJbbFXWK2F5L0DZNZHOeLDgHvArGxMq0nTohA@mail.gmail.com>

Hi,

We will be cancelling the cinder meeting on 6th April as it is the PTG week.

Thanks and regards
Rajat Dhasmana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220331/a0cdb082/attachment.htm>

From katonalala at gmail.com  Thu Mar 31 19:23:14 2022
From: katonalala at gmail.com (Lajos Katona)
Date: Thu, 31 Mar 2022 21:23:14 +0200
Subject: [neutron] PTG schedule
Message-ID: <CALg0jK=EnYu5V9QcQZ_pLYenAM9u6naea9vi7UUSV4H5g2OGQA@mail.gmail.com>

Hi Neutrinos,

Please check the PTG schedule:
https://etherpad.opendev.org/p/neutron-zed-ptg#L83

Please check it, and raise your hand if

   - a time slot is not suitable for you
   - or if you have any more topics to discuss next week.

We have one full free day (Friday) and for Thursday I just added a
theoretical Nova-Neutron cross project discussion, so we have space to
shuffle slots.

I added a slot for Edge, perhaps Designate folks can join us, that can also
move in the schedule.

See you next week during the PTG :-)

Lajos Katona (lajoskatona)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220331/af289a7c/attachment.htm>

From ozzzo at yahoo.com  Thu Mar 31 20:06:40 2022
From: ozzzo at yahoo.com (Albert Braden)
Date: Thu, 31 Mar 2022 20:06:40 +0000 (UTC)
Subject: [neutron] [kolla] Static routes added to subnets after
 upgrading from Queens to Train
In-Reply-To: <2f5ea4b4-73a3-b6cc-2e7c-e6b7114117e4@gmail.com>
References: <997697892.1640950.1648587862872.ref@mail.yahoo.com>
 <997697892.1640950.1648587862872@mail.yahoo.com>
 <f195da6e-fb83-bcf1-64bc-1885377e07b3@gmail.com>
 <242099798.347726.1648668427206@mail.yahoo.com>
 <2f5ea4b4-73a3-b6cc-2e7c-e6b7114117e4@gmail.com>
Message-ID: <1362758790.769385.1648757200650@mail.yahoo.com>

 Here's what I get when I create a 4th subnet:

$ openstack network segment create --physical-network physnet_bo-az3 --network-type vlan --segment 1115 --network trust trust-az4
+------------------+--------------------------------------+
| Field | Value |
+------------------+--------------------------------------+
| description | |
| id | 92355e6d-3406-4b29-a956-1b05c4c9a33e |
| name | private-provider-trust-az4 |
| network_id | ac30a487-bccc-c3de-93eb-c422ad9f3ce5 |
| network_type | vlan |
| physical_network | physnet_bo-az3 |
| segmentation_id | 1115 |
+------------------+--------------------------------------+
 
$ openstack subnet create --no-dhcp --network private-provider-trust --network-segment private-provider-trust-az4 --ip-version 4 --allocation-pool start=10.52.172.14,end=10.52.172.235 --subnet-range 10.52.172.0/22 --dns-nameserver 10.10.10.10 --gateway 10.52.172.1 private-provider-trust-az4-subnet
+----------------------+------------------------------------------------------+
| Field | Value |
+----------------------+------------------------------------------------------+
| allocation_pools | 10.52.172.10-10.52.172.245 |
| cidr | 10.52.172.0/22 |
| created_at | 2022-03-31T19:26:48Z |
| description | |
| dns_nameservers | 10.10.10.10 |
| dns_publish_fixed_ip | None |
| enable_dhcp | False |
| gateway_ip | 10.52.172.1 |
| host_routes | destination='10.52.160.0/22', gateway='10.52.172.1' |
| | destination='10.52.164.0/22', gateway='10.52.172.1' |
| | destination='10.52.168.0/22', gateway='10.52.172.1' |
| id | 04a15cdd-d22b-4e58-8bbd-8b956d8c10ba |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | private-provider-trust-az4-subnet |
| network_id | ac30a487-bccc-4ac5-93eb-c422ad9f3ce5 |
| prefix_length | None |
| project_id | 561e8d2236634ece81ffa22203e80dc7 |
| revision_number | 0 |
| segment_id | 92355e6d-a5de-4b29-a956-1b05c4c9a33e |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2022-03-31T19:26:48Z |
+----------------------+------------------------------------------------------+

If I create the 4th subnet without specifying a gateway, then the routes are not created. It looks like this may be what changed from Queens to Train:

$ openstack subnet create --no-dhcp --network private-provider-trust --network-segment private-provider-trust-az4 --ip-version 4 --allocation-pool start=10.52.172.10,end=10.52.172.245 --subnet-range 10.52.172.0/22 --dns-nameserver 10.10.10.10 private-provider-trust-az4-subnet
+----------------------+--------------------------------------+
| Field | Value |
+----------------------+--------------------------------------+
| allocation_pools | 10.52.172.10-10.52.172.245 |
| cidr | 10.52.172.0/22 |
| created_at | 2022-03-31T20:00:44Z |
| description | |
| dns_nameservers | 10.10.10.10 |
| dns_publish_fixed_ip | None |
| enable_dhcp | False |
| gateway_ip | 10.52.172.1 |
| host_routes | |
| id | 11757c89-2057-4c7c-9730-9b7d976e361e |
| ip_version | 4 |
| ipv6_address_mode | None |
| ipv6_ra_mode | None |
| name | private-provider-trust-az4-subnet |
| network_id | ac30a487-bccc-4ac5-93eb-c422ad9f3ce5 |
| prefix_length | None |
| project_id | 561e8d2236634ece81ffa22203e80dc7 |
| revision_number | 0 |
| segment_id | 92355e6d-a5de-4b29-a956-1b05c4c9a33e |
| service_types | |
| subnetpool_id | None |
| tags | |
| updated_at | 2022-03-31T20:00:44Z |
+----------------------+--------------------------------------+     On Wednesday, March 30, 2022, 09:01:23 PM EDT, Brian Haley <haleyb.dev at gmail.com> wrote:  
 
 Hi,

On 3/30/22 15:27, Albert Braden wrote:
> The command that we use to create subnets looks like this:
> 
> openstack subnet create --no-dhcp --network trust --network-segment 
> trust-az1-seg --ip-version 4 --allocation-pool 
> start=10.52.160.14,end=10.52.160.235 --subnet-range 10.52.160.0/24 
> --dns-nameserver 10.10.10.10 --gateway 10.52.160.1 trust-az1

Since you're not specifying --host-route there should be none, can you 
paste the created object returned from this call since for me 
host_routes is blank (see below).

> My co-workers tell me that we also specified "--gateway" when we created 
> our Queens subnets, but this did not cause static routes to be created. 
> Did the handling of "--gateway" change from Queens to Train?

I don't believe so, and --gateway will default to the first IP in the 
subnet if not given so isn't required.

-Brian


$ openstack subnet create --subnet-pool 
f5e3f133-a932-4adc-9592-0b525aec278f --network private private-subnet-2
+----------------------+---------------------------+
| Field? ? ? ? ? ? ? ? | Value? ? ? ? ? ? ? ? ? ? |
+----------------------+---------------------------+
| allocation_pools? ? | 10.0.0.66-10.0.0.126? ? ? |
| cidr? ? ? ? ? ? ? ? | 10.0.0.64/26? ? ? ? ? ? ? |
| created_at? ? ? ? ? | 2022-03-30T17:38:40Z? ? ? |
| description? ? ? ? ? |? ? ? ? ? ? ? ? ? ? ? ? ? |
| dns_nameservers? ? ? |? ? ? ? ? ? ? ? ? ? ? ? ? |
| dns_publish_fixed_ip | None? ? ? ? ? ? ? ? ? ? ? |
| enable_dhcp? ? ? ? ? | True? ? ? ? ? ? ? ? ? ? ? |
| gateway_ip? ? ? ? ? | 10.0.0.65? ? ? ? ? ? ? ? |
| host_routes? ? ? ? ? |? ? ? ? ? ? ? ? ? ? ? ? ? |
| id? ? ? ? ? ? ? ? ? | ce09a038-b918-4208-9a3d-c8c259ae7433 |
| ip_version? ? ? ? ? | 4? ? ? ? ? ? ? ? ? ? ? ? |
| ipv6_address_mode? ? | None? ? ? ? ? ? ? ? ? ? ? |
| ipv6_ra_mode? ? ? ? | None? ? ? ? ? ? ? ? ? ? ? |
| name? ? ? ? ? ? ? ? | private-subnet-2? ? ? ? ? |
| network_id? ? ? ? ? | baf6c62d-4cec-464e-a768-253074df8879 |
| project_id? ? ? ? ? | 657e6d647c0446438c1f06da70d79bed |
| revision_number? ? ? | 0? ? ? ? ? ? ? ? ? ? ? ? | 
? ? ? ? | segment_id? ? ? ? ? | None? ? ? ? ? ? ? ? ? ? ? | 

| service_types? ? ? ? |? ? ? ? ? ? ? ? ? ? ? ? ? |
| subnetpool_id? ? ? ? | f5e3f133-a932-4adc-9592-0b525aec278f |
| tags? ? ? ? ? ? ? ? |? ? ? ? ? ? ? ? ? ? ? ? ? |
| updated_at? ? ? ? ? | 2022-03-30T17:38:40Z? ? ? |
+----------------------+---------------------------+

> On Wednesday, March 30, 2022, 01:45:52 PM EDT, Brian Haley 
> <haleyb.dev at gmail.com> wrote:
> 
> 
> Hi Albert,
> 
> On 3/29/22 17:04, Albert Braden wrote:
>? > After upgrading our kolla-ansible clusters from Queens to Train, we 
> are seeing static routes when we create subnets. We didn?t see this in 
> Queens. For example, in our de6 region we have a network called ?trust? 
> with 3 subnets:
>? >
>? > Subnet? ? ? ? ? ? ? ? CIDR? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Gateway
>? > trust-az1:? ? ? ? ? ? 10.52.160.0/22? 10.52.160.1
>? > trust-az2:? ? ? ? ? ? 10.52.164.0/22? 10.52.164.1
>? > trust-az3:? ? ? ? ? ? 10.52.168.0/22? 10.52.168.1
>? >
>? > Each of these subnets has 2 entries under ?host_routes:? that point 
> to the other two subnets. For example, subnet trust-az1 has these two 
> routes:
>? >
>? > host_routes? ? ? ? ? | destination='10.52.164.0/22', 
> gateway='10.52.160.1' |
>? > |? ? ? ? ? ? ? ? ? ? ? | destination='10.52.168.0/22', 
> gateway='10.52.160.1' |
>? >
>? > How can we prevent these host routes from being created in Train? Do 
> we need to change something in our config?
> 
> 
>? From the neutron side of things, host_routes of a subnet is not
> automatically calculated and filled-in, they have to be manually added.
> So perhaps this is something kolla is doing? At least on my Yoga setup
> it is completely blank using 'openstack subnet create ...' even with
> multiple subnets on a network.
> 
> How exactly are the subnets getting created?
> 
> -Brian
> 

  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220331/a93a5cde/attachment-0001.htm>

From rlandy at redhat.com  Thu Mar 31 21:05:15 2022
From: rlandy at redhat.com (Ronelle Landy)
Date: Thu, 31 Mar 2022 17:05:15 -0400
Subject: [TripleO] gate blocker - impacting all quickstart-based jobs -
 openstack-ansible-os_tempest
Message-ID: <CANnyimMEjNQVetJ0DnrhuyiVpeM_1xH8U6eS1aN_sqNsdBTzXw@mail.gmail.com>

Hello All,

We have a check/gate blocker on all TripleO quickstart-based jobs, as
described in:

https://bugs.launchpad.net/tripleo/+bug/1967430

[1] commit to openstack-ansible-os_tempest removed setup.py and is causing
failings in all quickstart jobs.

A revert was proposed but will not be workable - we are waiting on another
fix.

Please hold rechecks until this is resolved.

[1]
https://review.opendev.org/c/openstack/openstack-ansible-os_tempest/+/835969

Thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220331/a65614ab/attachment.htm>

From laurentfdumont at gmail.com  Thu Mar 31 23:29:45 2022
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Thu, 31 Mar 2022 19:29:45 -0400
Subject: [kolla] RDP access to openstack instances
In-Reply-To: <CAEc0ziuazStTB8kv4wN80UvzWk+8FoKRZOD08zRJH90RoN7_hw@mail.gmail.com>
References: <CAEc0ziuazStTB8kv4wN80UvzWk+8FoKRZOD08zRJH90RoN7_hw@mail.gmail.com>
Message-ID: <CAOAKi8wgGLEQqX=BSB6AxjjAA-L_GPUXP9PuyY9KhG623wt1Qw@mail.gmail.com>

There is nothing specific about RDP vs SSH. It's all TCP in the end.

I would validate :

   - Check the security groups to make sure the ports are correct.
   - tcpdump at the compute, vm, network level to see the traffic.
   - try RDP locally in the subnet to see if it's enabled on the
   destination box.


On Wed, Mar 30, 2022 at 3:43 AM A Monster <amonster369 at gmail.com> wrote:

> I can ssh into instances after attributing floating ips but whenever I try
> to access using remote desktop I fail, although I've enabled RDP traffic in
> security groups, is there a problem with my configuration or do I have to
> do extra work to successfully do a remote access.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220331/6d6b3180/attachment.htm>