From swogatpradhan22 at gmail.com  Sat Apr  1 07:16:33 2023
From: swogatpradhan22 at gmail.com (Swogat Pradhan)
Date: Sat, 1 Apr 2023 12:46:33 +0530
Subject: Unable to create external vlan network | openstack wallaby
Message-ID: <CAH0LXPp_wPN=jXHyMbwvMfCpr_wGziE_EMEM+Rt+KT9VV3dsyA@mail.gmail.com>

Hi,
I have an openstack setup which already has vm's running on it and other
external and internal networks.
I configured DCN recently adding 2 additional sites and while testing the
services, I found I am unable to create external vlan networks for some
reason, whereas other networks like geneve are getting created.

Horizon is throwing 1 error and that is Internal server error, i am not
sure why this happened, or how to solve this issue.
Can someone please suggest?

With regards,
Swogat Pradhan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230401/6e86d60a/attachment.htm>

From swogatpradhan22 at gmail.com  Sat Apr  1 07:32:23 2023
From: swogatpradhan22 at gmail.com (Swogat Pradhan)
Date: Sat, 1 Apr 2023 13:02:23 +0530
Subject: Unable to create external vlan network | openstack wallaby
In-Reply-To: <CAH0LXPp_wPN=jXHyMbwvMfCpr_wGziE_EMEM+Rt+KT9VV3dsyA@mail.gmail.com>
References: <CAH0LXPp_wPN=jXHyMbwvMfCpr_wGziE_EMEM+Rt+KT9VV3dsyA@mail.gmail.com>
Message-ID: <CAH0LXPovw+dkNrYU-oxQRJ1W9AzVbTb89EOa0PhR354CBtONBg@mail.gmail.com>

Horizon error:
Request Failed: internal server error while processing your request.
Neutron server returns request_ids:
['req-174a625b-ef17-4898-ae70-ff66eef86587']

I am not getting any error messages in neutron server.log
I am not sure where to check and what to check as it was previously working.

On Sat, Apr 1, 2023 at 12:46?PM Swogat Pradhan <swogatpradhan22 at gmail.com>
wrote:

> Hi,
> I have an openstack setup which already has vm's running on it and other
> external and internal networks.
> I configured DCN recently adding 2 additional sites and while testing the
> services, I found I am unable to create external vlan networks for some
> reason, whereas other networks like geneve are getting created.
>
> Horizon is throwing 1 error and that is Internal server error, i am not
> sure why this happened, or how to solve this issue.
> Can someone please suggest?
>
> With regards,
> Swogat Pradhan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230401/972b26b9/attachment.htm>

From swogatpradhan22 at gmail.com  Sat Apr  1 10:26:46 2023
From: swogatpradhan22 at gmail.com (Swogat Pradhan)
Date: Sat, 1 Apr 2023 15:56:46 +0530
Subject: Unable to create external vlan network | openstack wallaby
In-Reply-To: <CAH0LXPovw+dkNrYU-oxQRJ1W9AzVbTb89EOa0PhR354CBtONBg@mail.gmail.com>
References: <CAH0LXPp_wPN=jXHyMbwvMfCpr_wGziE_EMEM+Rt+KT9VV3dsyA@mail.gmail.com>
 <CAH0LXPovw+dkNrYU-oxQRJ1W9AzVbTb89EOa0PhR354CBtONBg@mail.gmail.com>
Message-ID: <CAH0LXPowF41Hidz3O1KLRWnhBgqBRsPZZjFTgPrXQ7mCbbbM4A@mail.gmail.com>

update:
(overcloud) [stack at hkg2director ~]$ openstack network agent list
HttpException: 500: Server Error for url:
https://bolt.bdxworld.com:13696/v2.0/agents, Request Failed: internal
server error while processing your request.
(overcloud) [stack at hkg2director ~]$

I don't see any errors anywhere, except for haproxy logs where it shows
status code 500 in neutron_be backend.

On Sat, Apr 1, 2023 at 1:02?PM Swogat Pradhan <swogatpradhan22 at gmail.com>
wrote:

> Horizon error:
> Request Failed: internal server error while processing your request.
> Neutron server returns request_ids:
> ['req-174a625b-ef17-4898-ae70-ff66eef86587']
>
> I am not getting any error messages in neutron server.log
> I am not sure where to check and what to check as it was previously
> working.
>
> On Sat, Apr 1, 2023 at 12:46?PM Swogat Pradhan <swogatpradhan22 at gmail.com>
> wrote:
>
>> Hi,
>> I have an openstack setup which already has vm's running on it and other
>> external and internal networks.
>> I configured DCN recently adding 2 additional sites and while testing the
>> services, I found I am unable to create external vlan networks for some
>> reason, whereas other networks like geneve are getting created.
>>
>> Horizon is throwing 1 error and that is Internal server error, i am not
>> sure why this happened, or how to solve this issue.
>> Can someone please suggest?
>>
>> With regards,
>> Swogat Pradhan
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230401/95e98000/attachment.htm>

From swogatpradhan22 at gmail.com  Sat Apr  1 14:16:26 2023
From: swogatpradhan22 at gmail.com (Swogat Pradhan)
Date: Sat, 1 Apr 2023 19:46:26 +0530
Subject: Unable to create external vlan network | openstack wallaby
In-Reply-To: <CAH0LXPowF41Hidz3O1KLRWnhBgqBRsPZZjFTgPrXQ7mCbbbM4A@mail.gmail.com>
References: <CAH0LXPp_wPN=jXHyMbwvMfCpr_wGziE_EMEM+Rt+KT9VV3dsyA@mail.gmail.com>
 <CAH0LXPovw+dkNrYU-oxQRJ1W9AzVbTb89EOa0PhR354CBtONBg@mail.gmail.com>
 <CAH0LXPowF41Hidz3O1KLRWnhBgqBRsPZZjFTgPrXQ7mCbbbM4A@mail.gmail.com>
Message-ID: <CAH0LXPrOBpH3EDVuB6co=ZLE8cqNv74TYDKugK8Vy6j7yu6fqg@mail.gmail.com>

Resolved:

The issue and solution is defined clearly here:
https://www.jimmdenton.com/neutron-ovn-private-chassis/

On Sat, Apr 1, 2023 at 3:56?PM Swogat Pradhan <swogatpradhan22 at gmail.com>
wrote:

> update:
> (overcloud) [stack at hkg2director ~]$ openstack network agent list
> HttpException: 500: Server Error for url:
> https://bolt.bdxworld.com:13696/v2.0/agents, Request Failed: internal
> server error while processing your request.
> (overcloud) [stack at hkg2director ~]$
>
> I don't see any errors anywhere, except for haproxy logs where it shows
> status code 500 in neutron_be backend.
>
> On Sat, Apr 1, 2023 at 1:02?PM Swogat Pradhan <swogatpradhan22 at gmail.com>
> wrote:
>
>> Horizon error:
>> Request Failed: internal server error while processing your request.
>> Neutron server returns request_ids:
>> ['req-174a625b-ef17-4898-ae70-ff66eef86587']
>>
>> I am not getting any error messages in neutron server.log
>> I am not sure where to check and what to check as it was previously
>> working.
>>
>> On Sat, Apr 1, 2023 at 12:46?PM Swogat Pradhan <swogatpradhan22 at gmail.com>
>> wrote:
>>
>>> Hi,
>>> I have an openstack setup which already has vm's running on it and other
>>> external and internal networks.
>>> I configured DCN recently adding 2 additional sites and while testing
>>> the services, I found I am unable to create external vlan networks for some
>>> reason, whereas other networks like geneve are getting created.
>>>
>>> Horizon is throwing 1 error and that is Internal server error, i am not
>>> sure why this happened, or how to solve this issue.
>>> Can someone please suggest?
>>>
>>> With regards,
>>> Swogat Pradhan
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230401/e5c6d4a9/attachment.htm>

From satish.txt at gmail.com  Sat Apr  1 16:20:51 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Sat, 1 Apr 2023 12:20:51 -0400
Subject: [kolla] Image building question
In-Reply-To: <93a78d3cdbc7fb8ca66545a981ca145c6ce21d7a.camel@redhat.com>
References: <CAPgF-fqFP1YENfG-XsrL2oJQeqzVhUTdJzn2_VwKsZvkvpeApQ@mail.gmail.com>
 <d419fa044dab2f07ff408fc10b7e708185310a48.camel@redhat.com>
 <CAPgF-fqm-OvCzd+My85P8MFe6uobwJ6y_OpFU2K+i7R2u6qdDA@mail.gmail.com>
 <93a78d3cdbc7fb8ca66545a981ca145c6ce21d7a.camel@redhat.com>
Message-ID: <CAPgF-fpXdhgstwXkqtnrz=BQxKjkRgGRkP_uK-4S-993_OsQuQ@mail.gmail.com>

Thank you sean,

I did following an it works hope this is correct way to customize

{% extends parent_template %}

# Horizon
{% block horizon_ubuntu_source_setup %}
RUN apt update -y
RUN apt install -y net-tools vim
RUN touch /root/foo
{% endblock %}


$ kolla-build --registry docker-reg:4000 -b ubuntu -t source --tag zed-v2
--template-override template-overrides.j2 --debug horizon


On Fri, Mar 31, 2023 at 1:31?PM Sean Mooney <smooney at redhat.com> wrote:

> On Fri, 2023-03-31 at 10:25 -0400, Satish Patel wrote:
> > Thank you Sean,
> >
> > What a wonderful explanation of the process. Yes I can download images
> from
> > the public domain and push them to a local repository but in some cases I
> > would like to add my own tools like monitoring agents, utilities etc
> > for debugging so i decided to build my own images.
> >
> > I believe https://tarballs.opendev.org is the right place to source
> > software correctly?
> that is the offcial location where all opendev/openstack projects are
> released
> and its the location distros use to build there packages.
> >
> > If I want to add some tools or packages inside images then I should use
> > Dockerfile.j2 to add and compile images. correct?
>
> yes so one of the great things about kolla images is tiem was taken to
> write
> down the image api when the project was first started
> https://docs.openstack.org/kolla/yoga/admin/kolla_api.html
>
> over time the common usecaes were then docuemnted in the admin
> image-building guide
>
> https://docs.openstack.org/kolla/yoga/admin/image-building.html#dockerfile-customisation
>
>
> all of the templated imnages have convension/contract that they provide
> delement that operator can
> use to add customisations.
>
> for examplel the nova_base_footer block and be used to add addtional
> content to the nova-base image
>
> https://github.com/openstack/kolla/blob/master/docker/nova/nova-base/Dockerfile.j2#L82
>
> to customise the iamges you provide what is know as a template override
> file
>
> the contrib folder has a number of exmaples
>
>
> https://github.com/openstack/kolla/blob/master/contrib/template-override/ovs-dpdk.j2
>
> https://github.com/openstack/kolla/blob/master/contrib/neutron-plugins/template_override-networking-mlnx.j2
>
> https://github.com/openstack/kolla/blob/master/contrib/neutron-plugins/template_override-vmware-nsx.j2
>
>
> the way they work is you starte it with
>
> {% extends parent_template %}
>
> then you just create a block that mages the name of the one you want to
> repalce
> {% extends parent_template %}
>
> {% block nova_base_footer %}
>  RUN /bin/true
> {% endblock %}
>
>
> what ever content you put in the block will be injected directly into the
> rendered docer file
>
>
>
> https://docs.openstack.org/kolla/yoga/admin/image-building.html#plugin-functionality
>
> show how to use that for neutron
>
> in addtion to replacing block you can set the conten of specal variables
> like horizon_packages_append or horizon_packages_remove
>
>
> https://docs.openstack.org/kolla/yoga/admin/image-building.html#packages-customisation
>
> that allow you add an remove packages in a simple way
> there is also a set of macros that you can use
>
> you include them with
> {% import "macros.j2" as macros with context %}
>
> they are defiend here
> https://github.com/openstack/kolla/blob/master/docker/macros.j2
>
> if you know that the docs exist the capablitys are coverd pretty well in
> the kolla docs you just need to know where to look
> hopefully that helps.
>
> the ovs-dpdk template overide docs can be fouund here
> https://docs.openstack.org/kolla/yoga/admin/template-override/ovs-dpdk.html
>
> its a liltle differnt then the other since there i used the template
> override mechanium to allow compiling ovs with dpdk form souces
>
> kolla normlly does not support that but it serves as a demonstration for
> how operator can do that if they really need too.
> i.e. compile a replacment for a minary componet like mariadb. it salso
> show how to use git as the souce localtion instead
> of tars if that is your prefernce.
>
> >
> > ~S
> >
> > On Fri, Mar 31, 2023 at 7:01?AM Sean Mooney <smooney at redhat.com> wrote:
> >
> > > On Thu, 2023-03-30 at 16:49 -0400, Satish Patel wrote:
> > > > Folks,
> > > >
> > > > I am playing with kolla image building to understand how it works. I
> am
> > > > using the following command to build images and wanted to check with
> you
> > > > folks if that is the correct way to do it.
> > > >
> > > > $ kolla-build -b ubuntu -t source keystone nova neutron glance
> > > >
> > > > Does the above command compile code from source or just download
> images
> > > > from remote repositories and re-compile them?
> > > >
> > > openstack is mainly python so in general ther is no complie step.
> > > but to answer your question that builds the image using the source
> tarballs
> > > or the openstakc packages.
> > >
> > > the defaults soruce locations are rendered into a file which you can
> > > override
> > > from the data stored in
> > > https://github.com/openstack/kolla/blob/master/kolla/common/sources.py
> > > the other build config defaults are generated form this code
> > > https://github.com/openstack/kolla/blob/master/kolla/common/config.py
> > >
> > > when you invoke kolla-build its executing
> > > https://github.com/openstack/kolla/blob/master/kolla/cmd/build.py
> > > but the main build workflow is here
> > >
> https://github.com/openstack/kolla/blob/be15d6212f278027c257f9dd67e5b2719e9f730a/kolla/image/build.py#L95
> > >
> > > the tl;dr is the build worklow starts by creating  build director and
> > > locating the docker file templats.
> > > in otherwords the content of the
> > >
> https://github.com/openstack/kolla/tree/be15d6212f278027c257f9dd67e5b2719e9f730a/docker
> > > directory
> > >
> > > each project has a direcoty in the docker directory and then each
> > > contaienr that project has has a directory in the project directory
> > >
> > > so the aodh project has a aodh folder
> > >
> https://github.com/openstack/kolla/tree/be15d6212f278027c257f9dd67e5b2719e9f730a/docker/aodh
> > > the convention is to have a <project>-base contaienr which handels the
> > > depency installation and then one addtional contaienr for each binary
> deamon
> > > the project has i.e. aodh-api
> > >
> > > the name of the folder in teh project dir is used as the name of the
> > > contaienr
> > >
> > > if we look at the content of the docker files we will see that they are
> > > not actuly dockerfiles
> > >
> > >
> https://github.com/openstack/kolla/blob/be15d6212f278027c257f9dd67e5b2719e9f730a/docker/aodh/aodh-api/Dockerfile.j2
> > >
> > > they are jinja2 templates that produce docker files
> > >
> > > kolla as far as i am aware has drop support for binary images and
> > > alternitiv distos
> > >
> > > but looking at an older release we can se ehow this worked
> > >
> > >
> https://github.com/openstack/kolla/blob/stable/wallaby/docker/nova/nova-base/Dockerfile.j2#L13-L52
> > >
> > > each docker file template would use the jinja2 to generate a set of
> > > concreate docker files form the template
> > > and make dession based on the parmater passed in.
> > >
> > > so when you are invokeing
> > > kolla-build -b ubuntu -t source keystone nova neutron glance
> > >
> > > what actully happening is that the -t flag is being set as teh
> > > install_type parmater in the the jinja2 environemtn when
> > > the docker file is rendered.
> > >
> > > after all the docer files are rendered into normal docker files kolla
> just
> > > invokes the build.
> > >
> > > in the case of a source build that inovles pre fetching the source tar
> > > from https://tarballs.opendev.org
> > > and puting it in the build directory so that it can be included into
> the
> > > contianer.
> > >
> > > kolla also used to supprot git repo as a alternitve  source fromat
> > >
> > > i have glossed over a lot of the details of how this actully work but
> that
> > > is the essence of what that command is doing
> > > creating a build dir, downloading the source, rendering the dockerfile
> > > templates to docker files, invokeing docker build on those
> > > and then taging them with the contaienr nameand build tag
> > >
> > >
> > > https://docs.openstack.org/kolla/latest/admin/image-building.html
> > > covers this form a high level
> > >
> > > >   because in command output
> > > > I've not noticed anything related to the compiling process going on.
> > > >
> > > > Here is the output of all images produced by kolla-build command. Do
> I
> > > need
> > > > anything else or is this enough to deploy kolla?
> > > you can deploy coll with what you have yes although since the kolla
> files
> > > are automaticaly
> > > built by ci kolla-ansible can just use the ones form the docker hub or
> > > quay instead you do not need to build them yourself
> > >
> > > if you do build them your self then there is basically one other stpe
> that
> > > you shoudl take if this si a multi node deployment
> > > you should push the iamges to an interally host docker registry
> although
> > > based on the hostname in the prompt below
> > > it looks like you ahve alredy done that.
> > > >
> > > > root at docker-reg:~# docker images
> > > > REPOSITORY                            TAG       IMAGE ID
>  CREATED
> > > >         SIZE
> > > > kolla/mariadb-server                  15.1.0    2a497eee8269   26
> minutes
> > > > ago      595MB
> > > > kolla/cron                            15.1.0    342877f26a8a   30
> minutes
> > > > ago      250MB
> > > > kolla/memcached                       15.1.0    0d19a4902644   31
> minutes
> > > > ago      250MB
> > > > kolla/mariadb-clustercheck            15.1.0    d84427d3c639   31
> minutes
> > > > ago      314MB
> > > > kolla/mariadb-base                    15.1.0    34447e3e59b6   31
> minutes
> > > > ago      314MB
> > > > kolla/keepalived                      15.1.0    82133b09fbf0   31
> minutes
> > > > ago      260MB
> > > > kolla/prometheus-memcached-exporter   15.1.0    6c2d605f70ee   31
> minutes
> > > > ago      262MB
> > > > <none>                                <none>    e66b228c2a07   31
> minutes
> > > > ago      248MB
> > > > kolla/rabbitmq                        15.1.0    8de5c39379d3   32
> minutes
> > > > ago      309MB
> > > > kolla/fluentd                         15.1.0    adfd19027862   33
> minutes
> > > > ago      519MB
> > > > kolla/haproxy-ssh                     15.1.0    514357ac4d36   36
> minutes
> > > > ago      255MB
> > > > kolla/haproxy                         15.1.0    e5b9cfdf6dfc   37
> minutes
> > > > ago      257MB
> > > > kolla/prometheus-haproxy-exporter     15.1.0    a679f65fd735   37
> minutes
> > > > ago      263MB
> > > > kolla/prometheus-base                 15.1.0    afeff3ed5dce   37
> minutes
> > > > ago      248MB
> > > > kolla/glance-api                      15.1.0    a2241f68f23a   38
> minutes
> > > > ago      1.04GB
> > > > kolla/glance-base                     15.1.0    7286772a03a4   About
> an
> > > > hour ago   1.03GB
> > > > kolla/neutron-infoblox-ipam-agent     15.1.0    f90ffc1a3326   About
> an
> > > > hour ago   1.05GB
> > > > kolla/neutron-server                  15.1.0    69c844a2e3a9   About
> an
> > > > hour ago   1.05GB
> > > > kolla/neutron-l3-agent                15.1.0    4d87e6963c96   About
> an
> > > > hour ago   1.05GB
> > > > <none>                                <none>    486da9a6562e   About
> an
> > > > hour ago   1.05GB
> > > > kolla/neutron-linuxbridge-agent       15.1.0    e5b3ca7e099c   About
> an
> > > > hour ago   1.04GB
> > > > kolla/neutron-bgp-dragent             15.1.0    ac37377820c6   About
> an
> > > > hour ago   1.04GB
> > > > kolla/ironic-neutron-agent            15.1.0    90993adcd74b   About
> an
> > > > hour ago   1.04GB
> > > > kolla/neutron-metadata-agent          15.1.0    8522f147f88d   About
> an
> > > > hour ago   1.04GB
> > > > kolla/neutron-sriov-agent             15.1.0    8a92ce7d13c0   About
> an
> > > > hour ago   1.04GB
> > > > kolla/neutron-dhcp-agent              15.1.0    5c214b0171f5   About
> an
> > > > hour ago   1.04GB
> > > > kolla/neutron-metering-agent          15.1.0    7b3b91ecd77b   About
> an
> > > > hour ago   1.04GB
> > > > kolla/neutron-openvswitch-agent       15.1.0    1f8807308814   About
> an
> > > > hour ago   1.04GB
> > > > kolla/neutron-base                    15.1.0    f85b6a2e2725   About
> an
> > > > hour ago   1.04GB
> > > > kolla/nova-libvirt                    15.1.0    0f3ecefe4752   About
> an
> > > > hour ago   987MB
> > > > kolla/nova-compute                    15.1.0    241b7e7fafbe   About
> an
> > > > hour ago   1.47GB
> > > > kolla/nova-spicehtml5proxy            15.1.0    b740820a7ad1   About
> an
> > > > hour ago   1.15GB
> > > > kolla/nova-novncproxy                 15.1.0    1ba2f443d5c3   About
> an
> > > > hour ago   1.22GB
> > > > kolla/nova-compute-ironic             15.1.0    716612107532   About
> an
> > > > hour ago   1.12GB
> > > > kolla/nova-ssh                        15.1.0    ae2397f4e1c1   About
> an
> > > > hour ago   1.11GB
> > > > kolla/nova-api                        15.1.0    2aef02667ff8   About
> an
> > > > hour ago   1.11GB
> > > > kolla/nova-conductor                  15.1.0    6f1da3400901   About
> an
> > > > hour ago   1.11GB
> > > > kolla/nova-scheduler                  15.1.0    628326776b1d   About
> an
> > > > hour ago   1.11GB
> > > > kolla/nova-serialproxy                15.1.0    28eb7a4a13f8   About
> an
> > > > hour ago   1.11GB
> > > > kolla/nova-base                       15.1.0    e47420013283   About
> an
> > > > hour ago   1.11GB
> > > > kolla/keystone                        15.1.0    e5530d829d5f   2
> hours
> > > ago
> > > >         947MB
> > > > kolla/keystone-ssh                    15.1.0    eaa7e3f3985a   2
> hours
> > > ago
> > > >         953MB
> > > > kolla/keystone-fernet                 15.1.0    8a4fa24853a8   2
> hours
> > > ago
> > > >         951MB
> > > > kolla/keystone-base                   15.1.0    b6f9562364a9   2
> hours
> > > ago
> > > >         945MB
> > > > kolla/barbican-base                   15.1.0    b2fdef1afb44   2
> hours
> > > ago
> > > >         915MB
> > > > kolla/barbican-keystone-listener      15.1.0    58bd59de2c63   2
> hours
> > > ago
> > > >         915MB
> > > > kolla/openstack-base                  15.1.0    c805b4b3b1c1   2
> hours
> > > ago
> > > >         893MB
> > > > kolla/base                            15.1.0    f68e9ef3dd30   2
> hours
> > > ago
> > > >         248MB
> > > > registry                              2         8db46f9d7550   19
> hours
> > > ago
> > > >        24.2MB
> > > > ubuntu                                22.04     08d22c0ceb15   3
> weeks
> > > ago
> > > >         77.8MB
> > >
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230401/41277349/attachment-0001.htm>

From jamesleong123098 at gmail.com  Sat Apr  1 23:28:37 2023
From: jamesleong123098 at gmail.com (James Leong)
Date: Sat, 1 Apr 2023 18:28:37 -0500
Subject: [Horizon][policy][keystone][yoga] allow __member__ role to create user
Message-ID: <CA+_ZFmGLRHtrVy9QsUz146=0kmWi0M+qD5w=HzEJnd5WBjuV6w@mail.gmail.com>

Hi all,
I have deploy openstack in yoga version using kolla-ansible. I noticed that
only admin role can create a new user. Would it be possible to also allow
user with __member__ role to create user in the respective project.

Best,
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230401/ac32cd2c/attachment.htm>

From noonedeadpunk at gmail.com  Sun Apr  2 04:34:43 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Sun, 2 Apr 2023 06:34:43 +0200
Subject: [Horizon][policy][keystone][yoga] allow __member__ role to create
 user
In-Reply-To: <CA+_ZFmGLRHtrVy9QsUz146=0kmWi0M+qD5w=HzEJnd5WBjuV6w@mail.gmail.com>
References: <CA+_ZFmGLRHtrVy9QsUz146=0kmWi0M+qD5w=HzEJnd5WBjuV6w@mail.gmail.com>
Message-ID: <CAPd_6AtDEQ5U8F9xvuvn49=RZvuJEAP=vuWkrvhug48bz+Uc2w@mail.gmail.com>

I would suggest domain admin [1] to create another users rather then
granting any regular user to create another ones. As you would need not
only create the user, but also be able to assign appropriate role to it,
which should not be granted for members for sure.

I'm not actually sure about your usecase, but what regular _member_ can do,
is to create application credentials [2], that can be used for
authentication in keystone by clients (including usage of
openrc/clouds.yaml files), but that will basically shadow user that has
created these credentials. Though they can't be used to auth in Horizon if
I'm not mistaken.

[1]
https://docs.openstack.org/keystone/latest/admin/service-api-protection.html#domain-administrators
[2]
https://docs.openstack.org/keystone/latest/user/application_credentials.html

??, 2 ???. 2023 ?., 01:33 James Leong <jamesleong123098 at gmail.com>:

> Hi all,
> I have deploy openstack in yoga version using kolla-ansible. I noticed
> that only admin role can create a new user. Would it be possible to also
> allow user with __member__ role to create user in the respective project.
>
> Best,
> James
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230402/4cd6bebd/attachment.htm>

From nguyenhuukhoinw at gmail.com  Sun Apr  2 04:46:29 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Sun, 2 Apr 2023 11:46:29 +0700
Subject: [cinder]multi backend SAN and Ceph
Message-ID: <CABAODRet93Qw7eLtd0ZAkhRCq1E++nA91LW+o+1FidfUuottvQ@mail.gmail.com>

Hello.
I have a question that could we use both SAN and Ceph for multi backend? If
yes can we change volume type from SAN to Ceph and otherwise?
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230402/093e1606/attachment.htm>

From noonedeadpunk at gmail.com  Sun Apr  2 05:37:00 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Sun, 2 Apr 2023 07:37:00 +0200
Subject: [cinder]multi backend SAN and Ceph
In-Reply-To: <CABAODRet93Qw7eLtd0ZAkhRCq1E++nA91LW+o+1FidfUuottvQ@mail.gmail.com>
References: <CABAODRet93Qw7eLtd0ZAkhRCq1E++nA91LW+o+1FidfUuottvQ@mail.gmail.com>
Message-ID: <CAPd_6Avs0G3+JdULtY1P7oQ1XaPaROHg-Xk+m4XRPh8ZhBTQ8g@mail.gmail.com>

I don't see any reason why this won't be possible. Though, I would likely
used different sets of cinder-volume services for that, as while Ceph does
support active-active setup, I'm not sure your NAS driver does - it's worth
checking your specific driver with this matrix:
https://docs.openstack.org/cinder/latest/reference/support-matrix.html

Regarding changing volume types, I assume you mean basically volume
retypes. It actually depends on the format of images that are stored on the
backend, as cinder does not execute type conversion during retype. So if
your NAS storage stores in RAW as Ceph does, this should work, I assume.

??, 2 ???. 2023 ?., 06:48 Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>:

> Hello.
> I have a question that could we use both SAN and Ceph for multi backend?
> If yes can we change volume type from SAN to Ceph and otherwise?
> Thanks.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230402/21ed838b/attachment.htm>

From nguyenhuukhoinw at gmail.com  Sun Apr  2 05:56:16 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Sun, 2 Apr 2023 12:56:16 +0700
Subject: [cinder]multi backend SAN and Ceph
In-Reply-To: <CAPd_6Avs0G3+JdULtY1P7oQ1XaPaROHg-Xk+m4XRPh8ZhBTQ8g@mail.gmail.com>
References: <CABAODRet93Qw7eLtd0ZAkhRCq1E++nA91LW+o+1FidfUuottvQ@mail.gmail.com>
 <CAPd_6Avs0G3+JdULtY1P7oQ1XaPaROHg-Xk+m4XRPh8ZhBTQ8g@mail.gmail.com>
Message-ID: <CABAODReQ-GY07WO-H=+2WYvWK+4BLx7BzDe2j=fNRFjFRKxQZA@mail.gmail.com>

I ask becasuse I have no see docs which talked about.
I will lab and update you.
Many thanks for quick response. Have a nice weekend.



On Sun, Apr 2, 2023, 12:43 PM Dmitriy Rabotyagov <noonedeadpunk at gmail.com>
wrote:

> I don't see any reason why this won't be possible. Though, I would likely
> used different sets of cinder-volume services for that, as while Ceph does
> support active-active setup, I'm not sure your NAS driver does - it's worth
> checking your specific driver with this matrix:
> https://docs.openstack.org/cinder/latest/reference/support-matrix.html
>
> Regarding changing volume types, I assume you mean basically volume
> retypes. It actually depends on the format of images that are stored on the
> backend, as cinder does not execute type conversion during retype. So if
> your NAS storage stores in RAW as Ceph does, this should work, I assume.
>
> ??, 2 ???. 2023 ?., 06:48 Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>:
>
>> Hello.
>> I have a question that could we use both SAN and Ceph for multi backend?
>> If yes can we change volume type from SAN to Ceph and otherwise?
>> Thanks.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230402/39a4f429/attachment.htm>

From wodel.youchi at gmail.com  Sun Apr  2 12:42:18 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Sun, 2 Apr 2023 13:42:18 +0100
Subject: Does Openstack support the notion of cinder backend in maintenance
 mode?
Message-ID: <CAJV_UBB2R7GZrWWYcOqOuf2U3xFBN+RWAe4GxqhgqLUow5fJnA@mail.gmail.com>

Hi,

When you have multiple cinder backends, and you need to take down one of
them for maintenance purposes, what is the best way to proceed?
Does Openstack have the notion of : cinder backend in maintenance mode?

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230402/3cf0d6f0/attachment.htm>

From ignaziocassano at gmail.com  Sun Apr  2 12:47:50 2023
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Sun, 2 Apr 2023 14:47:50 +0200
Subject: Does Openstack support the notion of cinder backend in
 maintenance mode?
In-Reply-To: <CAJV_UBB2R7GZrWWYcOqOuf2U3xFBN+RWAe4GxqhgqLUow5fJnA@mail.gmail.com>
References: <CAJV_UBB2R7GZrWWYcOqOuf2U3xFBN+RWAe4GxqhgqLUow5fJnA@mail.gmail.com>
Message-ID: <CAB7j8cVDSW_RPUbmo_V3vxjS5mRo22AMJwdS8r_zdm=ey_hs_g@mail.gmail.com>

Hello, cinder-manage command can disable service on a backend If I remember
well.
Ignazio

Il Dom 2 Apr 2023, 14:46 wodel youchi <wodel.youchi at gmail.com> ha scritto:

> Hi,
>
> When you have multiple cinder backends, and you need to take down one of
> them for maintenance purposes, what is the best way to proceed?
> Does Openstack have the notion of : cinder backend in maintenance mode?
>
> Regards.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230402/cb8b155f/attachment.htm>

From wodel.youchi at gmail.com  Sun Apr  2 12:50:11 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Sun, 2 Apr 2023 13:50:11 +0100
Subject: Does cinder-backup support multi-backend?
Message-ID: <CAJV_UBAwDcy7Adob712AVYa0uK0txsoJbi3U83Fjy2G6UFhyiQ@mail.gmail.com>

Hi,

Could cinder-backup be configured with multiple-backends, ceph and nfs for
example?

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230402/bda8cfd5/attachment.htm>

From ignaziocassano at gmail.com  Sun Apr  2 12:53:59 2023
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Sun, 2 Apr 2023 14:53:59 +0200
Subject: Does Openstack support the notion of cinder backend in
 maintenance mode?
In-Reply-To: <CAJV_UBB2R7GZrWWYcOqOuf2U3xFBN+RWAe4GxqhgqLUow5fJnA@mail.gmail.com>
References: <CAJV_UBB2R7GZrWWYcOqOuf2U3xFBN+RWAe4GxqhgqLUow5fJnA@mail.gmail.com>
Message-ID: <CAB7j8cWpiz6WfhTeGof7ZdhskmwXwkwzYY=WSpPco0M78cko2A@mail.gmail.com>

Or using the openstack command :

https://platform9.com/kb/openstack/deleting-a-cinder-service-from-host

Il Dom 2 Apr 2023, 14:46 wodel youchi <wodel.youchi at gmail.com> ha scritto:

> Hi,
>
> When you have multiple cinder backends, and you need to take down one of
> them for maintenance purposes, what is the best way to proceed?
> Does Openstack have the notion of : cinder backend in maintenance mode?
>
> Regards.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230402/6d1db439/attachment.htm>

From ignaziocassano at gmail.com  Sun Apr  2 12:55:50 2023
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Sun, 2 Apr 2023 14:55:50 +0200
Subject: Does cinder-backup support multi-backend?
In-Reply-To: <CAJV_UBAwDcy7Adob712AVYa0uK0txsoJbi3U83Fjy2G6UFhyiQ@mail.gmail.com>
References: <CAJV_UBAwDcy7Adob712AVYa0uK0txsoJbi3U83Fjy2G6UFhyiQ@mail.gmail.com>
Message-ID: <CAB7j8cUDM=OptqH3muqT7aEvET-ub09qdBg8NM4HxmSqz4M0ig@mail.gmail.com>

I am sorry but I do not use cinder backup because we acquired trilio vault
backup solution.

Il Dom 2 Apr 2023, 14:53 wodel youchi <wodel.youchi at gmail.com> ha scritto:

> Hi,
>
> Could cinder-backup be configured with multiple-backends, ceph and nfs for
> example?
>
> Regards.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230402/a669f4ab/attachment.htm>

From nguyenhuukhoinw at gmail.com  Sun Apr  2 13:00:49 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Sun, 2 Apr 2023 20:00:49 +0700
Subject: Does cinder-backup support multi-backend?
In-Reply-To: <CAJV_UBAwDcy7Adob712AVYa0uK0txsoJbi3U83Fjy2G6UFhyiQ@mail.gmail.com>
References: <CAJV_UBAwDcy7Adob712AVYa0uK0txsoJbi3U83Fjy2G6UFhyiQ@mail.gmail.com>
Message-ID: <CABAODRfY9v6muyZw34yxk25npgFUc4LfTe594Ng8VUUXA334DQ@mail.gmail.com>

Yes, it can be done.

On Sun, Apr 2, 2023, 7:58 PM wodel youchi <wodel.youchi at gmail.com> wrote:

> Hi,
>
> Could cinder-backup be configured with multiple-backends, ceph and nfs for
> example?
>
> Regards.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230402/608ec6e2/attachment.htm>

From nguyenhuukhoinw at gmail.com  Sun Apr  2 13:03:20 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Sun, 2 Apr 2023 20:03:20 +0700
Subject: Does cinder-backup support multi-backend?
In-Reply-To: <CABAODRfY9v6muyZw34yxk25npgFUc4LfTe594Ng8VUUXA334DQ@mail.gmail.com>
References: <CAJV_UBAwDcy7Adob712AVYa0uK0txsoJbi3U83Fjy2G6UFhyiQ@mail.gmail.com>
 <CABAODRfY9v6muyZw34yxk25npgFUc4LfTe594Ng8VUUXA334DQ@mail.gmail.com>
Message-ID: <CABAODRd=ps4S8pPcHgSkpdyKzbwtkS6_YXzUZpx1dU71NXNDRg@mail.gmail.com>

I just ask today.
https://docs.openstack.org/cinder/latest/reference/support-matrix.html

https://www.google.com/amp/s/www.openstackfaq.com/cinder-multiple-backends/%3famp

On Sun, Apr 2, 2023, 8:00 PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Yes, it can be done.
>
> On Sun, Apr 2, 2023, 7:58 PM wodel youchi <wodel.youchi at gmail.com> wrote:
>
>> Hi,
>>
>> Could cinder-backup be configured with multiple-backends, ceph and nfs
>> for example?
>>
>> Regards.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230402/f68e9462/attachment-0001.htm>

From nguyenhuukhoinw at gmail.com  Sun Apr  2 13:05:04 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Sun, 2 Apr 2023 20:05:04 +0700
Subject: Does cinder-backup support multi-backend?
In-Reply-To: <CABAODRd=ps4S8pPcHgSkpdyKzbwtkS6_YXzUZpx1dU71NXNDRg@mail.gmail.com>
References: <CAJV_UBAwDcy7Adob712AVYa0uK0txsoJbi3U83Fjy2G6UFhyiQ@mail.gmail.com>
 <CABAODRfY9v6muyZw34yxk25npgFUc4LfTe594Ng8VUUXA334DQ@mail.gmail.com>
 <CABAODRd=ps4S8pPcHgSkpdyKzbwtkS6_YXzUZpx1dU71NXNDRg@mail.gmail.com>
Message-ID: <CABAODRedjYcb0NDeemMHCfSMSiken=iaDQqpkQQVq57dE+XiaA@mail.gmail.com>

Oh. Sr. U asked for cinder-backup. My mistake.

On Sun, Apr 2, 2023, 8:03 PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> I just ask today.
> https://docs.openstack.org/cinder/latest/reference/support-matrix.html
>
>
> https://www.google.com/amp/s/www.openstackfaq.com/cinder-multiple-backends/%3famp
>
> On Sun, Apr 2, 2023, 8:00 PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> wrote:
>
>> Yes, it can be done.
>>
>> On Sun, Apr 2, 2023, 7:58 PM wodel youchi <wodel.youchi at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Could cinder-backup be configured with multiple-backends, ceph and nfs
>>> for example?
>>>
>>> Regards.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230402/6a78091e/attachment.htm>

From nguyenhuukhoinw at gmail.com  Sun Apr  2 13:14:54 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Sun, 2 Apr 2023 20:14:54 +0700
Subject: Does cinder-backup support multi-backend?
In-Reply-To: <CABAODRedjYcb0NDeemMHCfSMSiken=iaDQqpkQQVq57dE+XiaA@mail.gmail.com>
References: <CAJV_UBAwDcy7Adob712AVYa0uK0txsoJbi3U83Fjy2G6UFhyiQ@mail.gmail.com>
 <CABAODRfY9v6muyZw34yxk25npgFUc4LfTe594Ng8VUUXA334DQ@mail.gmail.com>
 <CABAODRd=ps4S8pPcHgSkpdyKzbwtkS6_YXzUZpx1dU71NXNDRg@mail.gmail.com>
 <CABAODRedjYcb0NDeemMHCfSMSiken=iaDQqpkQQVq57dE+XiaA@mail.gmail.com>
Message-ID: <CABAODReU3fBhPi0co77y=2qXM+u1u8mVpH4XxRiXVoX12_hsnw@mail.gmail.com>

https://blueprints.launchpad.net/cinder/+spec/backup-backends-configuration

I just read and test later.

On Sun, Apr 2, 2023, 8:05 PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Oh. Sr. U asked for cinder-backup. My mistake.
>
> On Sun, Apr 2, 2023, 8:03 PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> wrote:
>
>> I just ask today.
>> https://docs.openstack.org/cinder/latest/reference/support-matrix.html
>>
>>
>> https://www.google.com/amp/s/www.openstackfaq.com/cinder-multiple-backends/%3famp
>>
>> On Sun, Apr 2, 2023, 8:00 PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
>> wrote:
>>
>>> Yes, it can be done.
>>>
>>> On Sun, Apr 2, 2023, 7:58 PM wodel youchi <wodel.youchi at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Could cinder-backup be configured with multiple-backends, ceph and nfs
>>>> for example?
>>>>
>>>> Regards.
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230402/32a6690e/attachment.htm>

From wodel.youchi at gmail.com  Sun Apr  2 13:17:27 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Sun, 2 Apr 2023 14:17:27 +0100
Subject: Does Openstack support the notion of cinder backend in
 maintenance mode?
In-Reply-To: <CAB7j8cWpiz6WfhTeGof7ZdhskmwXwkwzYY=WSpPco0M78cko2A@mail.gmail.com>
References: <CAJV_UBB2R7GZrWWYcOqOuf2U3xFBN+RWAe4GxqhgqLUow5fJnA@mail.gmail.com>
 <CAB7j8cWpiz6WfhTeGof7ZdhskmwXwkwzYY=WSpPco0M78cko2A@mail.gmail.com>
Message-ID: <CAJV_UBBZpOsPg92W41=qnyonqpr4Kis1C5qffv=MXUp47bYUYw@mail.gmail.com>

Thank you,

Maybe my question was not clear enough.
Let's say I have a  cinder-volume with nfs as backend and I need to take
down the nfs server for maintenance, can I put the cinder-volume-nfs into
some sort of maintenance mode, work on the nfs server bring it back, then
reactivate the cinder-volume-nfs?

Regards.

Le dim. 2 avr. 2023 ? 13:54, Ignazio Cassano <ignaziocassano at gmail.com> a
?crit :

> Or using the openstack command :
>
> https://platform9.com/kb/openstack/deleting-a-cinder-service-from-host
>
> Il Dom 2 Apr 2023, 14:46 wodel youchi <wodel.youchi at gmail.com> ha scritto:
>
>> Hi,
>>
>> When you have multiple cinder backends, and you need to take down one of
>> them for maintenance purposes, what is the best way to proceed?
>> Does Openstack have the notion of : cinder backend in maintenance mode?
>>
>> Regards.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230402/ca19880f/attachment.htm>

From ignaziocassano at gmail.com  Sun Apr  2 16:10:16 2023
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Sun, 2 Apr 2023 18:10:16 +0200
Subject: Does Openstack support the notion of cinder backend in
 maintenance mode?
In-Reply-To: <CAJV_UBBZpOsPg92W41=qnyonqpr4Kis1C5qffv=MXUp47bYUYw@mail.gmail.com>
References: <CAJV_UBB2R7GZrWWYcOqOuf2U3xFBN+RWAe4GxqhgqLUow5fJnA@mail.gmail.com>
 <CAB7j8cWpiz6WfhTeGof7ZdhskmwXwkwzYY=WSpPco0M78cko2A@mail.gmail.com>
 <CAJV_UBBZpOsPg92W41=qnyonqpr4Kis1C5qffv=MXUp47bYUYw@mail.gmail.com>
Message-ID: <CAB7j8cU9zYX=XhEF2aJNS6WSWJOSxAUNA=Zm2erMKLAwXO_Dcg@mail.gmail.com>

If you read the link I sent you, you can note that it disable a backend
before removing it. So you can exclude the removing section.
Another way can be excluding the backend from enabled backends in
cinder.conf and restarting cinser services.
Ignazio

Il Dom 2 Apr 2023, 15:17 wodel youchi <wodel.youchi at gmail.com> ha scritto:

> Thank you,
>
> Maybe my question was not clear enough.
> Let's say I have a  cinder-volume with nfs as backend and I need to take
> down the nfs server for maintenance, can I put the cinder-volume-nfs into
> some sort of maintenance mode, work on the nfs server bring it back, then
> reactivate the cinder-volume-nfs?
>
> Regards.
>
> Le dim. 2 avr. 2023 ? 13:54, Ignazio Cassano <ignaziocassano at gmail.com> a
> ?crit :
>
>> Or using the openstack command :
>>
>> https://platform9.com/kb/openstack/deleting-a-cinder-service-from-host
>>
>> Il Dom 2 Apr 2023, 14:46 wodel youchi <wodel.youchi at gmail.com> ha
>> scritto:
>>
>>> Hi,
>>>
>>> When you have multiple cinder backends, and you need to take down one of
>>> them for maintenance purposes, what is the best way to proceed?
>>> Does Openstack have the notion of : cinder backend in maintenance mode?
>>>
>>> Regards.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230402/15d14c52/attachment.htm>

From ignaziocassano at gmail.com  Sun Apr  2 16:16:38 2023
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Sun, 2 Apr 2023 18:16:38 +0200
Subject: Does Openstack support the notion of cinder backend in
 maintenance mode?
In-Reply-To: <CAB7j8cU9zYX=XhEF2aJNS6WSWJOSxAUNA=Zm2erMKLAwXO_Dcg@mail.gmail.com>
References: <CAJV_UBB2R7GZrWWYcOqOuf2U3xFBN+RWAe4GxqhgqLUow5fJnA@mail.gmail.com>
 <CAB7j8cWpiz6WfhTeGof7ZdhskmwXwkwzYY=WSpPco0M78cko2A@mail.gmail.com>
 <CAJV_UBBZpOsPg92W41=qnyonqpr4Kis1C5qffv=MXUp47bYUYw@mail.gmail.com>
 <CAB7j8cU9zYX=XhEF2aJNS6WSWJOSxAUNA=Zm2erMKLAwXO_Dcg@mail.gmail.com>
Message-ID: <CAB7j8cXE-=kLRzVF6TtE-OTGNan=JB=WzoUYqedPtFYd5E8q9g@mail.gmail.com>

In other words, when you disable a cinder backend you cannot allocate
volumes on it.
This is what you want.
Ignazio


Il Dom 2 Apr 2023, 18:10 Ignazio Cassano <ignaziocassano at gmail.com> ha
scritto:

> If you read the link I sent you, you can note that it disable a backend
> before removing it. So you can exclude the removing section.
> Another way can be excluding the backend from enabled backends in
> cinder.conf and restarting cinser services.
> Ignazio
>
> Il Dom 2 Apr 2023, 15:17 wodel youchi <wodel.youchi at gmail.com> ha scritto:
>
>> Thank you,
>>
>> Maybe my question was not clear enough.
>> Let's say I have a  cinder-volume with nfs as backend and I need to take
>> down the nfs server for maintenance, can I put the cinder-volume-nfs into
>> some sort of maintenance mode, work on the nfs server bring it back, then
>> reactivate the cinder-volume-nfs?
>>
>> Regards.
>>
>> Le dim. 2 avr. 2023 ? 13:54, Ignazio Cassano <ignaziocassano at gmail.com>
>> a ?crit :
>>
>>> Or using the openstack command :
>>>
>>> https://platform9.com/kb/openstack/deleting-a-cinder-service-from-host
>>>
>>> Il Dom 2 Apr 2023, 14:46 wodel youchi <wodel.youchi at gmail.com> ha
>>> scritto:
>>>
>>>> Hi,
>>>>
>>>> When you have multiple cinder backends, and you need to take down one
>>>> of them for maintenance purposes, what is the best way to proceed?
>>>> Does Openstack have the notion of : cinder backend in maintenance mode?
>>>>
>>>> Regards.
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230402/9a799005/attachment-0001.htm>

From jamesleong123098 at gmail.com  Sun Apr  2 21:18:14 2023
From: jamesleong123098 at gmail.com (James Leong)
Date: Sun, 2 Apr 2023 16:18:14 -0500
Subject: [Horizon][policy][keystone][yoga] allow __member__ role to create
 user
In-Reply-To: <CA+_ZFmGLRHtrVy9QsUz146=0kmWi0M+qD5w=HzEJnd5WBjuV6w@mail.gmail.com>
References: <CA+_ZFmGLRHtrVy9QsUz146=0kmWi0M+qD5w=HzEJnd5WBjuV6w@mail.gmail.com>
Message-ID: <CA+_ZFmFny5qfQ8bKs5TSaL0fDS+dX9jpZGSXrMBmuDuS=A6JJQ@mail.gmail.com>

Hi,

Thanks for the reply on creating domains for users. Our use-case is as
follows: We want to have a *project_admin* role for a project. The user
with *project_admin* role can only create/delete new users for the project
with *member *role.

Thanks
James

On Sat, Apr 1, 2023 at 6:28?PM James Leong <jamesleong123098 at gmail.com>
wrote:

> Hi all,
> I have deploy openstack in yoga version using kolla-ansible. I noticed
> that only admin role can create a new user. Would it be possible to also
> allow user with __member__ role to create user in the respective project.
>
> Best,
> James
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230402/d1a51c73/attachment.htm>

From jamesleong123098 at gmail.com  Mon Apr  3 00:30:13 2023
From: jamesleong123098 at gmail.com (James Leong)
Date: Sun, 2 Apr 2023 19:30:13 -0500
Subject: [Horizon][policy][keystone][yoga] allow __member__ role to create
 user
In-Reply-To: <CA+_ZFmFny5qfQ8bKs5TSaL0fDS+dX9jpZGSXrMBmuDuS=A6JJQ@mail.gmail.com>
References: <CA+_ZFmGLRHtrVy9QsUz146=0kmWi0M+qD5w=HzEJnd5WBjuV6w@mail.gmail.com>
 <CA+_ZFmFny5qfQ8bKs5TSaL0fDS+dX9jpZGSXrMBmuDuS=A6JJQ@mail.gmail.com>
Message-ID: <CA+_ZFmFsJmcqr8C-vNAbu6AKW103JQZzskv6MnOcBb3PqoxcWA@mail.gmail.com>

How do I enable domain tab on horizon dashboard. After enabling the option
"openstack_keystone_multidomain_support," I am still not being able to see
the domain tab on my dashboard. I am using kolla-ansible deployment tools
to deploy the openstack.

Best,
James

On Sun, 2 Apr 2023, 4:18 pm James Leong, <jamesleong123098 at gmail.com> wrote:

> Hi,
>
> Thanks for the reply on creating domains for users. Our use-case is as
> follows: We want to have a *project_admin* role for a project. The user
> with *project_admin* role can only create/delete new users for the
> project with *member *role.
>
> Thanks
> James
>
> On Sat, Apr 1, 2023 at 6:28?PM James Leong <jamesleong123098 at gmail.com>
> wrote:
>
>> Hi all,
>> I have deploy openstack in yoga version using kolla-ansible. I noticed
>> that only admin role can create a new user. Would it be possible to also
>> allow user with __member__ role to create user in the respective project.
>>
>> Best,
>> James
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230402/bd20b193/attachment.htm>

From nguyenhuukhoinw at gmail.com  Mon Apr  3 03:46:48 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Mon, 3 Apr 2023 10:46:48 +0700
Subject: [kolla] horizon image build failed
In-Reply-To: <CAPgF-frpTBVbPvsqPY3w2D4SvBmMHLtnWO4gORN1BsBwHeAvUQ@mail.gmail.com>
References: <CAPgF-fpUEaapOVDdWpX2z-3-u8V=tLruyfvpoOeSObm2suGh3g@mail.gmail.com>
 <D5A23ACF-1301-4182-964E-08122ACECE97@gmail.com>
 <CAPgF-fprrVfbN-oVwYTsONF5EHfoVV5b84hBaPOJ_0R5ia4qwg@mail.gmail.com>
 <B222A2CC-7342-4EAA-8CA6-6DE61D3A82AB@gmail.com>
 <CAPgF-fr3xDGQgQPkqFBT+B0dKqq2GHvuf9UDNtGPGcUOZVYusA@mail.gmail.com>
 <92A192DF-ABFC-4ED3-A65A-15A2E3869B2B@gmail.com>
 <CAPgF-frpTBVbPvsqPY3w2D4SvBmMHLtnWO4gORN1BsBwHeAvUQ@mail.gmail.com>
Message-ID: <CABAODRcgnh5zVrpGGe5d1=2czHinscV=Xg=Bd=Lz4ah8tsE6gA@mail.gmail.com>

Hello.
I have problems with kolla-buid on Zed
I get stuck at

INFO:kolla.common.utils.neutron-mlnx-agent:  Created wheel for pyzmq:
filename=pyzmq-21.0.2-cp310-cp310-linux_x86_64.whl size=6820181
sha256=28c64060b01a12bdffc3eda488992d6aa440795339a49b22097182db4ae4385a
INFO:kolla.common.utils.neutron-mlnx-agent:  Stored in directory:
/tmp/pip-ephem-wheel-cache-7qgll_a7/wheels/d5/87/ca/40e7748395c2c2e1cb9642ece92c78f3fd94b0ab33050c6300
INFO:kolla.common.utils.neutron-mlnx-agent:Successfully built pyzmq
INFO:kolla.common.utils.neutron-mlnx-agent:Installing collected packages:
pyzmq, defusedxml, networking-mlnx
INFO:kolla.common.utils.neutron-mlnx-agent:Successfully installed
defusedxml-0.7.1 networking-mlnx-21.0.0 pyzmq-21.0.2
INFO:kolla.common.utils.neutron-mlnx-agent:Removing intermediate container
d3c30f67df00
INFO:kolla.common.utils.neutron-mlnx-agent: ---> 6f2c93a4351e
INFO:kolla.common.utils.neutron-mlnx-agent:Step 5/5 : USER neutron
INFO:kolla.common.utils.neutron-mlnx-agent: ---> Running in 044a31130fff
INFO:kolla.common.utils.neutron-mlnx-agent:Removing intermediate container
044a31130fff
INFO:kolla.common.utils.neutron-mlnx-agent: ---> 94c718467cad
INFO:kolla.common.utils.neutron-mlnx-agent:Successfully built 94c718467cad
INFO:kolla.common.utils.neutron-mlnx-agent:Successfully tagged
fornix/neutron-mlnx-agent:15.1.1
INFO:kolla.common.utils.neutron-mlnx-agent:Built at 2023-04-03
10:35:00.380591 (took 0:01:21.725054)

It won't run for a long time although I followed

https://bugs.launchpad.net/kolla/+bug/2006727



Nguyen Huu Khoi


On Fri, Mar 31, 2023 at 9:52?PM Satish Patel <satish.txt at gmail.com> wrote:

> Awesome, thanks!
>
> This is easy, and +++1 to amend that in docs :)
>
> On Fri, Mar 31, 2023 at 10:34?AM Micha? Nasiadka <mnasiadka at gmail.com>
> wrote:
>
>> Hi Satish,
>>
>> git clone https://opendev.org/openstack/kolla -b stable/zed
>> cd kolla
>> pip3 install .
>>
>> I think we should amend the docs a bit to make it easier - thanks for
>> pointing out.
>>
>> Michal
>>
>> On 31 Mar 2023, at 16:27, Satish Patel <satish.txt at gmail.com> wrote:
>>
>> Hi Micha?,
>>
>> This is my sandbox environment so I did  "pip install kolla" and started
>> building images. How do I check out specific stable/zed or tag releases to
>> build images?
>>
>> ~S
>>
>> On Fri, Mar 31, 2023 at 9:59?AM Micha? Nasiadka <mnasiadka at gmail.com>
>> wrote:
>>
>>> Hi Satish,
>>>
>>> Vishal mentioned a bug that I raised in Horizon, but we have been
>>> pinning to earlier setuptools in Kolla builds just because of that (and
>>> that?s the workaround).
>>> Are you using kolla from PyPI or the latest stable/zed checkout from
>>> Git? We recommend the latter.
>>>
>>> Michal
>>>
>>> On 31 Mar 2023, at 15:53, Satish Patel <satish.txt at gmail.com> wrote:
>>>
>>> Thank Michal,
>>>
>>> I have posted commands in my original post which have
>>> distribution Ubuntu and release zed.  ( $ kolla-build --registry
>>> docker-reg:4000 -b ubuntu -t source --tag zed horizon )
>>>
>>> I can definitely open a new bug but it looks like vishal already on it.
>>> Are there any workarounds or interim solutions? I am new to the kolla-image
>>> building process so I'm not sure where I should change the setup tool
>>> version to move on.
>>>
>>> Very curious how the CI-CD pipeline passed this bug?
>>>
>>>
>>> On Fri, Mar 31, 2023 at 1:51?AM Micha? Nasiadka <mnasiadka at gmail.com>
>>> wrote:
>>>
>>>> Hi Satish,
>>>>
>>>> Have you raised a bug in Launchpad (bugs.launchpad.net/kolla) for this?
>>>>
>>>> You have also not mentioned what distribution and Kolla release are you
>>>> using, so please do that in the bug report.
>>>> Looking at the output probably it?s stable/yoga and Debian - being
>>>> fixed in https://review.opendev.org/c/openstack/kolla/+/873913
>>>>
>>>> Michal
>>>>
>>>> On 31 Mar 2023, at 05:05, Satish Patel <satish.txt at gmail.com> wrote:
>>>>
>>>> Folks,
>>>>
>>>> All other images build successfully but when i am trying to build
>>>> horizon which failed with following error:
>>>>
>>>> $ kolla-build --registry docker-reg:4000 -b ubuntu -t source --tag zed
>>>> horizon
>>>>
>>>>
>>>> INFO:kolla.common.utils.horizon:Collecting XStatic-Dagre>=0.6.4.0
>>>> INFO:kolla.common.utils.horizon:  Downloading
>>>> XStatic_Dagre-0.6.4.1-py2.py3-none-any.whl (140 kB)
>>>> INFO:kolla.common.utils.horizon:
>>>> ?????????????????????????????????????? 140.0/140.0 kB 14.4 MB/s eta 0:00:00
>>>> INFO:kolla.common.utils.horizon:Collecting XStatic-Dagre-D3>=0.4.17.0
>>>> INFO:kolla.common.utils.horizon:  Downloading
>>>> XStatic_Dagre_D3-0.4.17.0-py2.py3-none-any.whl (357 kB)
>>>> INFO:kolla.common.utils.horizon:
>>>> ?????????????????????????????????????? 357.4/357.4 kB 13.5 MB/s eta 0:00:00
>>>> INFO:kolla.common.utils.horizon:Requirement already satisfied:
>>>> XStatic-Font-Awesome>=4.7.0.0 in
>>>> /var/lib/kolla/venv/lib/python3.10/site-packages (from
>>>> vitrage-dashboard==3.6.1.dev2) (4.7.0.0)
>>>> INFO:kolla.common.utils.horizon:Collecting XStatic-Graphlib>=2.1.7.0
>>>> INFO:kolla.common.utils.horizon:  Downloading
>>>> XStatic_Graphlib-2.1.7.0-py2.py3-none-any.whl (51 kB)
>>>> INFO:kolla.common.utils.horizon:
>>>> ??????????????????????????????????????? 51.5/51.5 kB 114.3 MB/s eta 0:00:00
>>>> INFO:kolla.common.utils.horizon:Requirement already satisfied:
>>>> XStatic-jQuery>=1.8.2.1 in /var/lib/kolla/venv/lib/python3.10/site-packages
>>>> (from vitrage-dashboard==3.6.1.dev2) (1.12.4.1)
>>>> INFO:kolla.common.utils.horizon:Collecting XStatic-lodash>=4.16.4.1
>>>> INFO:kolla.common.utils.horizon:  Downloading
>>>> XStatic_lodash-4.16.4.2-py3-none-any.whl (167 kB)
>>>> INFO:kolla.common.utils.horizon:
>>>> ?????????????????????????????????????? 167.9/167.9 kB 12.4 MB/s eta 0:00:00
>>>> INFO:kolla.common.utils.horizon:Collecting XStatic-moment>=2.8.4.1
>>>> INFO:kolla.common.utils.horizon:  Downloading
>>>> XStatic_moment-2.8.4.3-py3-none-any.whl (58 kB)
>>>> INFO:kolla.common.utils.horizon:
>>>> ???????????????????????????????????????? 58.0/58.0 kB 66.7 MB/s eta 0:00:00
>>>> INFO:kolla.common.utils.horizon:Collecting
>>>> XStatic-Moment-Timezone>=0.5.22.0
>>>> INFO:kolla.common.utils.horizon:  Downloading
>>>> XStatic-Moment-Timezone-0.5.22.0.tar.gz (99 kB)
>>>> INFO:kolla.common.utils.horizon:
>>>> ???????????????????????????????????????? 99.7/99.7 kB 45.1 MB/s eta 0:00:00
>>>> INFO:kolla.common.utils.horizon:  Preparing metadata (setup.py): started
>>>> INFO:kolla.common.utils.horizon:  Preparing metadata (setup.py):
>>>> finished with status 'error'
>>>> INFO:kolla.common.utils.horizon:  error: subprocess-exited-with-error
>>>> INFO:kolla.common.utils.horizon:
>>>> INFO:kolla.common.utils.horizon:  ? python setup.py egg_info did not
>>>> run successfully.
>>>> INFO:kolla.common.utils.horizon:  ? exit code: 1
>>>> INFO:kolla.common.utils.horizon:  ??> [6 lines of output]
>>>> INFO:kolla.common.utils.horizon:      Traceback (most recent call last):
>>>> INFO:kolla.common.utils.horizon:        File "<string>", line 2, in
>>>> <module>
>>>> INFO:kolla.common.utils.horizon:        File "<pip-setuptools-caller>",
>>>> line 34, in <module>
>>>> INFO:kolla.common.utils.horizon:        File
>>>> "/tmp/pip-install-dqag1zef/xstatic-moment-timezone_60eeadc1dfb9492781fe3ca90e3b95c2/setup.py",
>>>> line 2, in <module>
>>>> INFO:kolla.common.utils.horizon:          from xstatic.pkg import
>>>> moment_timezone as xs
>>>> INFO:kolla.common.utils.horizon:      ImportError: cannot import name
>>>> 'moment_timezone' from 'xstatic.pkg' (unknown location)
>>>> INFO:kolla.common.utils.horizon:      [end of output]
>>>> INFO:kolla.common.utils.horizon:
>>>> INFO:kolla.common.utils.horizon:  note: This error originates from a
>>>> subprocess, and is likely not a problem with pip.
>>>> INFO:kolla.common.utils.horizon:
>>>> INFO:kolla.common.utils.horizon:error: metadata-generation-failed
>>>> INFO:kolla.common.utils.horizon:? Encountered error while generating
>>>> package metadata.
>>>> INFO:kolla.common.utils.horizon:??> See above for output.
>>>> INFO:kolla.common.utils.horizon:note: This is an issue with the package
>>>> mentioned above, not pip.
>>>> INFO:kolla.common.utils.horizon:hint: See above for details.
>>>> INFO:kolla.common.utils.horizon:
>>>> INFO:kolla.common.utils.horizon:Removing intermediate container
>>>> e6cd437ba529
>>>> ERROR:kolla.common.utils.horizon:Error'd with the following message
>>>> ERROR:kolla.common.utils.horizon:The command '/bin/sh -c ln -s
>>>> horizon-source/* horizon     && sed -i /^horizon=/d
>>>> /requirements/upper-constraints.txt     && SETUPTOOLS_USE_DISTUTILS=stdlib
>>>> python3 -m pip --no-cache-dir install --upgrade -c
>>>> /requirements/upper-constraints.txt /horizon     && mkdir -p
>>>> /etc/openstack-dashboard     && cp -r /horizon/openstack_dashboard/conf/*
>>>> /etc/openstack-dashboard/     && cp
>>>> /horizon/openstack_dashboard/local/local_settings.py.example
>>>> /etc/openstack-dashboard/local_settings     && cp /horizon/manage.py
>>>> /var/lib/kolla/venv/bin/manage.py     && if [ "$(ls /plugins)" ]; then
>>>>        SETUPTOOLS_USE_DISTUTILS=stdlib python3 -m pip --no-cache-dir
>>>> install --upgrade -c /requirements/upper-constraints.txt /plugins/*;
>>>>  fi     && for locale in
>>>>  /var/lib/kolla/venv/lib/python3.10/site-packages/*/locale; do
>>>>  (cd ${locale%/*} && /var/lib/kolla/venv/bin/django-admin compilemessages)
>>>>        done     && chmod 644 /usr/local/bin/kolla_extend_start' returned a
>>>> non-zero code: 1
>>>> INFO:kolla.common.utils:=========================
>>>> INFO:kolla.common.utils:Successfully built images
>>>> INFO:kolla.common.utils:=========================
>>>> INFO:kolla.common.utils:base
>>>> INFO:kolla.common.utils:openstack-base
>>>> INFO:kolla.common.utils:===========================
>>>> INFO:kolla.common.utils:Images that failed to build
>>>> INFO:kolla.common.utils:===========================
>>>>
>>>>
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/b3ab103c/attachment-0001.htm>

From christian.rohmann at inovex.de  Mon Apr  3 07:36:15 2023
From: christian.rohmann at inovex.de (Christian Rohmann)
Date: Mon, 3 Apr 2023 09:36:15 +0200
Subject: [designate] Proposal to deprecate the agent framework and agent
 based backends
In-Reply-To: <CAMH0MgJAyyUyUgMM20+GLew_Tc-jXAEo9hDCfgtEqcQD2OVmQw@mail.gmail.com>
References: <CAMH0MgJFtt_FJG3rWk7qyT=y_5ZUVrm1ZyTKOQ90T2R6hmBA5w@mail.gmail.com>
 <c8d3c12f-9807-11e1-582a-01c30e4a3f41@inovex.de>
 <CAMH0MgJAyyUyUgMM20+GLew_Tc-jXAEo9hDCfgtEqcQD2OVmQw@mail.gmail.com>
Message-ID: <a43f7293-29c5-0c15-679c-7f794e976ae3@inovex.de>

Hey Michael,


On 18/01/2023 23:50, Michael Johnson wrote:
> Personally I think the specification is very close to being complete,
> I think we just need to agree on these last few design items and we
> can push for reviews.
>
> As I was looking at these agent based drivers, it was very obvious
> that the catalog zones may eliminate the need for some of the agent
> based drivers. That is awesome and your proposal to add catalog zone
> support is perfectly timed.
>
> Michael
>
>
> On Wed, Jan 18, 2023 at 2:19 PM Christian Rohmann
> <christian.rohmann at inovex.de>  wrote:
>> Hey Michael, openstack-discuss,
>>
>> On 17/01/2023 01:52, Michael Johnson wrote:
>>> 6. The introduction of catalog zones[6] may eliminate the need for
>>> some of the agent based backend drivers.
>> I proposed the spec to have catalog zone support added to Designate, see
>> https://review.opendev.org/c/openstack/designate-specs/+/849109.


May I ask what the intended way forward with implementing the newly 
merged "catalog zones spec" is?
Is this targeting the Bobcat release?



Regards


Christian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/999f3fec/attachment.htm>

From marios at redhat.com  Mon Apr  3 07:56:44 2023
From: marios at redhat.com (Marios Andreou)
Date: Mon, 3 Apr 2023 10:56:44 +0300
Subject: [tripleo] Removal of TripleO Master Integration and Component
 Lines
In-Reply-To: <20230331181131.jbdeq3nrylsrag4s@yuggoth.org>
References: <CANnyimP_f94dEL79Uvai-fvYC1DYKoGFsbNw4HZ4pp3oPLj8gQ@mail.gmail.com>
 <20230331181131.jbdeq3nrylsrag4s@yuggoth.org>
Message-ID: <CAM51kHUGNCE0QsZ+0vFRs6JaD3ZxhMHrviErwaX2vxZ8CGo78w@mail.gmail.com>

On Fri, Mar 31, 2023 at 9:18?PM Jeremy Stanley <fungi at yuggoth.org> wrote:
>
> On 2023-03-31 11:59:27 -0400 (-0400), Ronelle Landy wrote:
> [...]
> > Check/gate testing for the master branch is in process of being removed as
> > well.
> >
> > [1] https://review.opendev.org/c/openstack/governance/+/878799
>
> I notice that the tripleo-ci repository only has a master branch.
> Will its contents going away cause problems with upstream testing
> for stable branches of other TripleO deliverables? Are there other
> single-branch TripleO deliverable repositories for which removal of
> content would impact stable branches?

Jeremy thank you!

your message made me go and check the proposed governance patch and I
commented there just now [1]

Indeed we want to keep the CI repos that are branchless and that will
remain active in support of the stable/wallaby and train branches.

regards, marios

[1] https://review.opendev.org/c/openstack/governance/+/877132/2#message-616ddf45fa1229ba2b51c4bac910b65a2a9b0a51



> --
> Jeremy Stanley



From noonedeadpunk at gmail.com  Mon Apr  3 08:19:26 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Mon, 3 Apr 2023 10:19:26 +0200
Subject: [ptl][monasca] Need PTL volunteer for OpenStack Monasca
Message-ID: <CAPd_6As016UXLAyRiHjp_F-aY21+sPiBEHUjcFd=8k_wicaypw@mail.gmail.com>

Hi everyone,

I am reaching out to find interested parties to maintain the OpenStack
Monasca project.
At the moment there is no PTL candidate for the next cycle (2023.2),
and it is on the leaderless project list [1]. In case there are no
interested parties to lead this project, TC might take the decision to
retire it.

If you're interested to help out with the project maintenance to keep
it alive, please kindly reach out to TC either by replying to this
email or joining us on IRC OFTC network in #openstack-tc channel.

[1] https://etherpad.opendev.org/p/2023.2-leaderless


From nemanja at nemanjamiletic.com  Mon Apr  3 08:44:26 2023
From: nemanja at nemanjamiletic.com (Nemanja Miletic)
Date: Mon, 03 Apr 2023 10:44:26 +0200
Subject: [nova][dev] image to local block device mapping not supported
Message-ID: <3b2e2326-3680-4845-a71c-9bbf7ea6adfb@app.fastmail.com>

Hello,

Nova does not support image to local block device mapping since issue in this bug is fixed:
https://bugs.launchpad.net/nova/+bug/1377958

In particular I am interested in scenario best described with this command:
openstack server create --flavor m1.small --network mgmt --image XXX \
--block-device uuid=YYY,source_type=image,\
destination_type=local,disk_bus=ide,device_type=cdrom,boot_index=1 testvm300

For above command nova gives error:
Block Device Mapping is Invalid: Mapping image to local is not supported.

Libvirt does not have issues with having two block devices which have file source.

My question is what am I missing here? Why Nova does not support image to local block device mapping?

Thank you for your help.
Nemanja


From noonedeadpunk at gmail.com  Mon Apr  3 10:25:36 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Mon, 3 Apr 2023 12:25:36 +0200
Subject: [openstack-ansible] Bobcat vPTG results
Message-ID: <CAPd_6As=-DxTFUK_4cPyAwVY+yt1M5Xzqmb8AxgJazQ+UOOnsQ@mail.gmail.com>

Hi everyone,

This year we didn't have many attendees, but I want to thank everyone
who managed to join the discussion regarding further project plans and
goals.

1. Things we'd love to work on to release 2023.1 (Antelope):

* Documentation improvements. That includes:
** Since Zed we're using OVN as a default network driver, while most
docs still refer to LXB in examples. We'd need to update architecture
and most networking docs with regards to this change, as they might be
misleading at the moment.
** Update Ironic documentation with regards to the latest changes to the role.
** Describe multi-arch deployments
* Finalize internal TLS - encryption between haproxy and uwsgi
backends that happens through the management network. We have couple
of topics here
** Split haproxy configuration so that backends were configured
per-service playbooks rather then while running haproxy one.
https://review.opendev.org/q/topic:separated-haproxy-service-config
** Actually patching services to support TLS for backends
https://review.opendev.org/q/topic:tls-backend
** Ensure we test in CI both TLS and non-TLS usecases for internal traffic.
* Bump MariaDB version to the next LTS release - 10.11
* Adding support for leap upgrades to our upgrade script and CI
* After switching to cloudsmith repo to be source for RabbitMQ and
Erlang we struggle a lot with packages being obsoleted and removed
randomly from the repo. With that we're going to execute following
plan:
** Switch rabbitmq back to packagecloud - it contains packages for
both deb and rpm
** Use minor releases of erlang rather than specific bugfix releases
that will still come from cloudsmith. Hopefully that will fail less.
** File an issue to rabbitmq-erlang-deb to publish releases in
github/packagecloud alike to rpms
** Track down state of ELS repo that could be used as alternative to
cloudsmith given it's working reliably.
* At the moment systemd services don't restart if only init overrides
are applied. POC patch was proposed and this topic should track
progress: https://review.opendev.org/q/topic:osa%252Fsystemd_restart_on_unit_change
We will also attempt to backport this to stable branches with just the
single vote as patches are quite trivial.

2. Bobcat goals

* Pretty endpoint names. It's great to have a supported way of having
pretty names in your endpoints, like compute.example.com. While this
is completely possible to achieve with current codebase, we have ways
to improve and ease the process of doing so.
** haproxy maps we've added should simplify the process a lot
** Add a boolean variable, that instead of concatenating vip_address +
port, do service_type + vip_address in roles with ability of global
override
** Fix certificates to include SAN or wildcard for all endpoint names
** document a way of doing that
* There is a long-going confusion about variables
external/internal_lb_vip_address as they could be either IP or an FQDN
and then needing other vars for the IP in haproxy/keepalived. We can
attempt to replace this variable with a more meaningful or intuitive
one.
** With that change we also have a chance of fixing inconsistent
service names (url vs. uri) across roles
* At the moment PKI keys/certificates can't be stored in a trusted
storage, as community.crypto.openssl_privatekey does require keys to
be files on filesystem. With that we can replace such module with
openssl_privatekey_pipe as then it can use different lookups.
** With that it would be also great to re-think/document a way of
storing user-secrets outside of using ansible-vault (that's trivial).
* With RabbitMQ 4.0 HA queues that are used now by default are going
to be removed. Quorum queues can be used instead to provide HA for
queues. Though they have quite different concepts. In order to migrate
to them, the exchange needs to be re-created with the enabled
persistence option. Easiest way to do that would be re-creating
vhosts, which will result in significant downtime for services like
nova or neutron, but that's the price that should be paid for the
migration/upgrade. Topic can be tracked here:
https://review.opendev.org/q/topic:osa%252Fquorum_queues
* ansible-core 2.14 requires >=py39, so Ubuntu 20.04 support will be
dropped early in the cycle.
* We also discussed resuming efforts of fucntional testing with
molecule. We came up with following requirements/pain ponts:
** avoid duplicated boilerplate in all repos
** a way to run tests locally, document that
** clean up current tox/test for projects to avoid confusion
* We agreed on having a common role for managing openstack resources,
like images, networks, flavors, etc. This is valuable not only for
operators, but also for our service roles, like octavia or tempest,
where we're creating specific resources in pretty different ways each
time. Work has started in the plugins repo with ambition to move that
to openstack collection in the future:
https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/878794
* We're not sure about current IPv6-only deployments at the moment,
when talking about public networks. While private networks is not smth
we want to focus on right now, we need to ensure that IPv6-only public
networks are supported and documented. Volunteers are highly
appreciated for this work.
* Releasing skyline role. While we have a POC role, Skyline doesn't
meet internal requirements of OSA maintainers. So while we'd love to
see role being released, it's unlikely to be a priority for majority
of current team. So we're calling for volunteers to make Skyline role
ready for releasing in Bobcat.
* We also agreed to work on Core reviewers promotion/demotion policies
and process, that should be published on Core reviewers page:
https://docs.openstack.org/openstack-ansible/latest/contributor/core-reviewers.html


From ralonsoh at redhat.com  Mon Apr  3 10:41:36 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Mon, 3 Apr 2023 12:41:36 +0200
Subject: [neutron][ptg] Neutron PTG summary
Message-ID: <CAECr9X7RXcNO7CoeCB88O4Mg043Jpa0LzxHGjEorTVKbaXFAWw@mail.gmail.com>

Hello Neutrinos:

This is a quick summary of the PTG sessions last week. This is the etherpad
used: https://etherpad.opendev.org/p/neutron-bobcat-ptg

*Retrospective.*

   - Good:
      - Speed on RFE spec reviewal.
      - Continue the deprecation of non-supported code: Linux Bridge,
      neutronclient
      - Good CI tracking of external library dependencies: pyroute2,
      sqlalchemy
      - Good progress on TC goals, in particular sRBAC (now supported in
      Zed).
      - Close of stale bugs
   - Bad:
      - The use of devstack for newcomers, in particular because of
      Neutron. It was proposed to implement vagrant files that will
work with ant
      IDE and will allow to deploy OpenStack easily.
      - Scenario CI jobs still running in Ubuntu Focal due to the nested
      virt provider issues: https://bugs.launchpad.net/neutron/+bug/1999249


   - To be improved:
      - Engagement with students to join the Neutron community


*Stadium projects.*
SQLAlchemy 2.0 is the main problem right now. The CI "-sqlalchmey-master"
jobs should help us to prepare these projects for the next framework
version and we need to start now.
Train branch is broken in most of the CIs. With
https://review.opendev.org/c/openstack/releases/+/878202, all projects will
be migrated to EOL.
networking-odl will be deprecated: it is still testing against ODL 11,
while the latest version is 16. Due to the lack of maintainers, we are no
longer delivering a new release.

*Release cadence.*
New meeting the first Tuesday of each month (Neutron team meeting) to
decide when to release a new project version.
Transition Train to EOL:
https://review.opendev.org/c/openstack/releases/+/878202

*python-neutronclient deprecation.*
Both the CLI and the python bindings code:
https://etherpad.opendev.org/p/python-neutronclient_deprecation
We decided not to spend too much time on this goal, as long as there are
other priorities. But we are going to mark this project as deprecated
(README and mail); that means we'll only push patches for bugs but no new
feature will be accepted. If any project is still using the CLI or the
bindings and needs a new feature, it will need to migrate to SDK (that will
help us on this common effort).

*Port hints feature.*
https://review.opendev.org/q/topic:port-hints
It was considered to use the "tags" resource attribute but this
functionality is very specific to the backend and the property is by
default admin-only. We'll keep the current implementation (under review
right now).

*Stateless security groups.*
This issue was found during the implementation of stateless SG in ML2/OVN.
Main problems:

   - Semantics and mechanics defined in the documentation and the API.
   - DHCP and DHCPv6: as long as other FWs (ML2/OVS native and iptables)
   support both by default with stateless SGs, it will be implicitly supported
   too in ML2/OVN. That will be documented. Rationale: DHCP is a networking
   service and we should be able to provide IP in any case.
   - Metadata: no support. Users will need to explicitly define the
   egress/ingress rules to allow the metadata traffic (as is now in ML2/OVS FW
   drivers).


*IPv6 prefix delegation.*
https://bugs.launchpad.net/neutron/+bug/1895972
It was decided not to implement this feature during this release.
At the same time it was decided to define L3 agent PD feature as
"experimental" because the client used, dibbler, ended the support:
https://bugs.launchpad.net/neutron/+bug/1916428

*Neutron agent status report.*
https://bugs.launchpad.net/neutron/+bug/2011422
It was accepted to have a better report from the agent side of the current
status, including if it was during the initial transient period, if the
agent was doing a full sync, if it was restarted, etc. This functionality
should also provide the ability of reporting customized status for
particular agents.

*DHCP agents with IPv6 metadata services.*
https://bugs.launchpad.net/neutron/+bug/1953165
Several options were considered. The approved one was (3): to schedule a
single IPv6 metadata agent per network, regardless of the HA number of DHCP
agents. That will prevent the IPv6 DAD error now present; the DHCP agent
will use that to stop spawning a new metadata agent (it will consider
another DHCP agent has a running metadata server). No DB/API changes will
be needed.

*sRBAC, phase 2.*
A new role called "service" will be created. It will identify the server to
service calls during the normal operation. For example: Nova to Neutron
port binding activation.
During this cycle we need to identify the server-2-server calls, performed
by other projects against the Neutron API and update these actions with the
new role.

*HWOL API for ports.*
Same topic as commented during the last PTG: the HWOL functionality implies
modifying the port binding, that is an admin-only property (and should
always be like that). Normal users cannot create and request a port with
this functionality if that port was not created before by an admin.
It was also suggested (but at least rejected by me: config driven API is
something now recommended) to have a configuration option to allow the
creation of HWOL ports by default.

*Delete on termination for Neutron ports.*
The goal of this new feature is to mark the port in order to know if it
needs to be deleted after the VM is deleted or not. This functionality is
valid for user created ports, not Nova created ports (the last ones are
always deleted when the VM is).
Nova folks are investigating if "tags" API is valid or not for this RFE. If
not, a new API will be proposed for Neutron ports.

*Allow to specify the hardware model in the Neutron port.*
The goal of this feature is to tint the port with a HW model. For
example "hw_vif_model=virtio"
or "hw_vif_model=e1000".
Same as before, investigate if "tags" is valid or not. We are also
considering improving "tags" to be a key-value model, instead of a list of
strings only.

*Add support for Napatech LinkVirt SmartNICs*
https://review.opendev.org/c/openstack/nova-specs/+/859290
The OVS service is running on the NIC HW. It uses DPDK port representors
(similar to devlink port representors but not present in kernel).
There is a POC in gerrit to be reviewed (patches in the etherpad). The VNIC
type was added some releases ago.
The main issue of this RFE: the lack of CI support. This is why the main
request for this company is to implement an external CI for zuul, adding
some basic tempest tests.

*Port binding activation duplication.*
https://bugs.launchpad.net/neutron/+bug/1986003
It was decided to implement the current solution (
https://review.opendev.org/c/openstack/neutron/+/853281/): if a duplicated
call is received by Neutron, it will raise a Conflict (409) exception,
handled by Nova.

*SR-IOV port tracking in Placement.*
Still under definition. Several alternatives to the current ML2/SRIOV
agent-resource reporting (for QoS) are presented, some of them exclusive to
the current model.
There is a etherpad to track the spec definition:
https://etherpad.opendev.org/p/track-sriov-nics-in-placement

*"skip-level" jobs this cycle (non SLURP).*
It was decided:

   - To continue testing it but testing master against Zed.
   - To move the jobs to experimental and periodic queues.


*ovn-bgp-agent roadmap.*
It was decided to add ovn-bgp-agent to the Neutron stadium. The migration
will be done during this release.
The current API, provided by networking-bgpvpn, is not enough. It is under
consideration to improve it or create a new one, just for OVN. It is also
needed to improve the current documentation: installation, current uses,
drivers available, etc.

*Extend OVN db sync tool.*
Now the OVN DB sync tool removes anything in the OVN NB DB that is not
present in the Neutron DB. That clashes with some deployments, for example
when using the OVN-IC to connect several nodes. E.g.:
http://dani.foroselectronica.es/ovn-cluster-interconnection-567/
It will be proposed a pluggable interface to make the sync tool aware of
these NB objects that have no counterpart in the Neutron DB but in other
OVN DB (ovn-ic-nb, for example).

*FIPS jobs, OS support.*
Currently this functionality is only tested in CentOS8.
CentOS9 has an issue with the conntrack module:
https://bugs.launchpad.net/neutron/+bug/1976323
These jobs are not tested in Ubuntu in the CI because this is a paid
feature.

*Vancouver PTG.*
We have registered the Neutron team for the Vancouver PTG. The topics to be
discussed will be tracked in
https://etherpad.opendev.org/p/neutron-vancouver-2023.

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/a666ece1/attachment.htm>

From Arne.Wiebalck at cern.ch  Mon Apr  3 11:35:33 2023
From: Arne.Wiebalck at cern.ch (Arne Wiebalck)
Date: Mon, 3 Apr 2023 11:35:33 +0000
Subject: [ironic] ARM Support in CI: Call for vendors / contributors /
 interested parties
In-Reply-To: <CA+sTGNfqAzE=bR16oXwBFyObKV8iz_RVkyB43t-ZemftdHsESQ@mail.gmail.com>
References: <CA+sTGNfqAzE=bR16oXwBFyObKV8iz_RVkyB43t-ZemftdHsESQ@mail.gmail.com>
Message-ID: <GV0P278MB09264C3EB7752AD0354DAFB9EF929@GV0P278MB0926.CHEP278.PROD.OUTLOOK.COM>

Jay,

We have our ARM servers fully managed by Ironic as well (via the Redfish driver),
including auto-discovery, benchmarking, burn-in and provisioning. They are set
up as hypervisors and we provision ARM VMs on them to our users.

We do not use the upstream IPA image, but build our own with IPAB (on an ARM
based runner).

Cheers,
 Arne

________________________________________
From: Jay Faulkner <jay at gr-oss.io>
Sent: Wednesday, 29 March 2023 20:39
To: OpenStack Discuss
Subject: [ironic] ARM Support in CI: Call for vendors / contributors / interested parties

Hi stackers,

Ironic has published an experimental Ironic Python Agent image for ARM64 (https://tarballs.opendev.org/openstack/ironic-python-agent-builder/dib/files/) and discussed promoting this image to supported via CI testing. However, we have a problem: there are no Ironic developers with easy access to ARM hardware at the moment, and no Ironic developers with free time to commit to improving our support of ARM hardware.

So we're putting out a call for help:
- If you're a hardware vendor and want your ARM hardware supported? Please come talk to the Ironic community about setting up third-party-CI.
- Are you an operator or contributor from a company invested in ARM bare metal? Please come join the Ironic community to help us build this support.

Thanks,
Jay Faulkner
Ironic PTL




From smooney at redhat.com  Mon Apr  3 12:33:55 2023
From: smooney at redhat.com (Sean Mooney)
Date: Mon, 03 Apr 2023 13:33:55 +0100
Subject: [nova][dev] image to local block device mapping not supported
In-Reply-To: <3b2e2326-3680-4845-a71c-9bbf7ea6adfb@app.fastmail.com>
References: <3b2e2326-3680-4845-a71c-9bbf7ea6adfb@app.fastmail.com>
Message-ID: <4ea436ac9afc02e69a4c5f447d4e049a41627708.camel@redhat.com>

On Mon, 2023-04-03 at 10:44 +0200, Nemanja Miletic wrote:
> Hello,
> 
> Nova does not support image to local block device mapping since issue in this bug is fixed:
> https://bugs.launchpad.net/nova/+bug/1377958
> 
> In particular I am interested in scenario best described with this command:
> openstack server create --flavor m1.small --network mgmt --image XXX \
> --block-device uuid=YYY,source_type=image,\
> destination_type=local,disk_bus=ide,device_type=cdrom,boot_index=1 testvm300
> 
> For above command nova gives error:
> Block Device Mapping is Invalid: Mapping image to local is not supported.
> 
> Libvirt does not have issues with having two block devices which have file source.
> 
> My question is what am I missing here? Why Nova does not support image to local block device mapping?
the simple answer is that if we allow this then you could eiasly fill the hosts root file system

in yoru exmaple you are using two diffent images but the size of the second image YYY would not be accounted for in the
placment  resouce allocation of local vm usage.

if you created a 100TB glance image as a qcow and then specifed it on a host that was configure ot use raw storage
that file will get converted and fill the host storage.
if the YYY image is a driver disk or install iso then generally we would suggest takign a differnt approch
if its a driver disk then you would boot a vm form the XXX image as normal and attach the iso as a cinder volume.
if it was a install iso then the normal workflow is described here https://docs.openstack.org/nova/rocky/user/launch-instance-using-ISO-image.html



> 
> Thank you for your help.
> Nemanja
> 



From smooney at redhat.com  Mon Apr  3 12:38:32 2023
From: smooney at redhat.com (Sean Mooney)
Date: Mon, 03 Apr 2023 13:38:32 +0100
Subject: [kolla] Image building question
In-Reply-To: <CABAODRcAm6K=JDyVWpqwjrOxVsCPG=ms7Ui79G1opySNiPdJVg@mail.gmail.com>
References: <CAPgF-fqFP1YENfG-XsrL2oJQeqzVhUTdJzn2_VwKsZvkvpeApQ@mail.gmail.com>
 <d419fa044dab2f07ff408fc10b7e708185310a48.camel@redhat.com>
 <CAPgF-fqm-OvCzd+My85P8MFe6uobwJ6y_OpFU2K+i7R2u6qdDA@mail.gmail.com>
 <93a78d3cdbc7fb8ca66545a981ca145c6ce21d7a.camel@redhat.com>
 <CAPgF-fpXdhgstwXkqtnrz=BQxKjkRgGRkP_uK-4S-993_OsQuQ@mail.gmail.com>
 <CABAODRcAm6K=JDyVWpqwjrOxVsCPG=ms7Ui79G1opySNiPdJVg@mail.gmail.com>
Message-ID: <cf125eedb3044002abba94e38b406b7d29383963.camel@redhat.com>

On Mon, 2023-04-03 at 07:18 +0700, Nguy?n H?u Kh?i wrote:
> Hello.
> I have a question.
> Do we need the kolla-ansible version that matches kolla to deploy openstack?
in general no.

the master branch can often be used to deploy stable/*
however its better to keep them alinged.

kolla has a pretty stable image api which means that it does not offten need
to modify how images are deployed and as a result some mismatch will not break things.

however over time thing do change that are incompatible across releases so unless you 
have a strong reason not to keep them alinged it best to use the same major release.
i.e. use a stable/zed version of kolla-ansible to deploy stable/zed images.

using other version of kolla-ansble woudl not be tested in ci so its would not be gurarentteed
to work. you might get lucky but unless you developing kolla-ansible there is little reason to use
missaligned versions.

> 
> Nguyen Huu Khoi
> 
> 
> On Sat, Apr 1, 2023 at 11:27?PM Satish Patel <satish.txt at gmail.com> wrote:
> 
> > Thank you sean,
> > 
> > I did following an it works hope this is correct way to customize
> > 
> > {% extends parent_template %}
> > 
> > # Horizon
> > {% block horizon_ubuntu_source_setup %}
> > RUN apt update -y
> > RUN apt install -y net-tools vim
> > RUN touch /root/foo
> > {% endblock %}
> > 
> > 
> > $ kolla-build --registry docker-reg:4000 -b ubuntu -t source --tag zed-v2
> > --template-override template-overrides.j2 --debug horizon
> > 
> > 
> > On Fri, Mar 31, 2023 at 1:31?PM Sean Mooney <smooney at redhat.com> wrote:
> > 
> > > On Fri, 2023-03-31 at 10:25 -0400, Satish Patel wrote:
> > > > Thank you Sean,
> > > > 
> > > > What a wonderful explanation of the process. Yes I can download images
> > > from
> > > > the public domain and push them to a local repository but in some cases
> > > I
> > > > would like to add my own tools like monitoring agents, utilities etc
> > > > for debugging so i decided to build my own images.
> > > > 
> > > > I believe https://tarballs.opendev.org is the right place to source
> > > > software correctly?
> > > that is the offcial location where all opendev/openstack projects are
> > > released
> > > and its the location distros use to build there packages.
> > > > 
> > > > If I want to add some tools or packages inside images then I should use
> > > > Dockerfile.j2 to add and compile images. correct?
> > > 
> > > yes so one of the great things about kolla images is tiem was taken to
> > > write
> > > down the image api when the project was first started
> > > https://docs.openstack.org/kolla/yoga/admin/kolla_api.html
> > > 
> > > over time the common usecaes were then docuemnted in the admin
> > > image-building guide
> > > 
> > > https://docs.openstack.org/kolla/yoga/admin/image-building.html#dockerfile-customisation
> > > 
> > > 
> > > all of the templated imnages have convension/contract that they provide
> > > delement that operator can
> > > use to add customisations.
> > > 
> > > for examplel the nova_base_footer block and be used to add addtional
> > > content to the nova-base image
> > > 
> > > https://github.com/openstack/kolla/blob/master/docker/nova/nova-base/Dockerfile.j2#L82
> > > 
> > > to customise the iamges you provide what is know as a template override
> > > file
> > > 
> > > the contrib folder has a number of exmaples
> > > 
> > > 
> > > https://github.com/openstack/kolla/blob/master/contrib/template-override/ovs-dpdk.j2
> > > 
> > > https://github.com/openstack/kolla/blob/master/contrib/neutron-plugins/template_override-networking-mlnx.j2
> > > 
> > > https://github.com/openstack/kolla/blob/master/contrib/neutron-plugins/template_override-vmware-nsx.j2
> > > 
> > > 
> > > the way they work is you starte it with
> > > 
> > > {% extends parent_template %}
> > > 
> > > then you just create a block that mages the name of the one you want to
> > > repalce
> > > {% extends parent_template %}
> > > 
> > > {% block nova_base_footer %}
> > >  RUN /bin/true
> > > {% endblock %}
> > > 
> > > 
> > > what ever content you put in the block will be injected directly into the
> > > rendered docer file
> > > 
> > > 
> > > 
> > > https://docs.openstack.org/kolla/yoga/admin/image-building.html#plugin-functionality
> > > 
> > > show how to use that for neutron
> > > 
> > > in addtion to replacing block you can set the conten of specal variables
> > > like horizon_packages_append or horizon_packages_remove
> > > 
> > > 
> > > https://docs.openstack.org/kolla/yoga/admin/image-building.html#packages-customisation
> > > 
> > > that allow you add an remove packages in a simple way
> > > there is also a set of macros that you can use
> > > 
> > > you include them with
> > > {% import "macros.j2" as macros with context %}
> > > 
> > > they are defiend here
> > > https://github.com/openstack/kolla/blob/master/docker/macros.j2
> > > 
> > > if you know that the docs exist the capablitys are coverd pretty well in
> > > the kolla docs you just need to know where to look
> > > hopefully that helps.
> > > 
> > > the ovs-dpdk template overide docs can be fouund here
> > > https://docs.openstack.org/kolla/yoga/admin/template-override/ovs-dpdk.html
> > > 
> > > its a liltle differnt then the other since there i used the template
> > > override mechanium to allow compiling ovs with dpdk form souces
> > > 
> > > kolla normlly does not support that but it serves as a demonstration for
> > > how operator can do that if they really need too.
> > > i.e. compile a replacment for a minary componet like mariadb. it salso
> > > show how to use git as the souce localtion instead
> > > of tars if that is your prefernce.
> > > 
> > > > 
> > > > ~S
> > > > 
> > > > On Fri, Mar 31, 2023 at 7:01?AM Sean Mooney <smooney at redhat.com> wrote:
> > > > 
> > > > > On Thu, 2023-03-30 at 16:49 -0400, Satish Patel wrote:
> > > > > > Folks,
> > > > > > 
> > > > > > I am playing with kolla image building to understand how it works.
> > > I am
> > > > > > using the following command to build images and wanted to check
> > > with you
> > > > > > folks if that is the correct way to do it.
> > > > > > 
> > > > > > $ kolla-build -b ubuntu -t source keystone nova neutron glance
> > > > > > 
> > > > > > Does the above command compile code from source or just download
> > > images
> > > > > > from remote repositories and re-compile them?
> > > > > > 
> > > > > openstack is mainly python so in general ther is no complie step.
> > > > > but to answer your question that builds the image using the source
> > > tarballs
> > > > > or the openstakc packages.
> > > > > 
> > > > > the defaults soruce locations are rendered into a file which you can
> > > > > override
> > > > > from the data stored in
> > > > > 
> > > https://github.com/openstack/kolla/blob/master/kolla/common/sources.py
> > > > > the other build config defaults are generated form this code
> > > > > https://github.com/openstack/kolla/blob/master/kolla/common/config.py
> > > > > 
> > > > > when you invoke kolla-build its executing
> > > > > https://github.com/openstack/kolla/blob/master/kolla/cmd/build.py
> > > > > but the main build workflow is here
> > > > > 
> > > https://github.com/openstack/kolla/blob/be15d6212f278027c257f9dd67e5b2719e9f730a/kolla/image/build.py#L95
> > > > > 
> > > > > the tl;dr is the build worklow starts by creating  build director and
> > > > > locating the docker file templats.
> > > > > in otherwords the content of the
> > > > > 
> > > https://github.com/openstack/kolla/tree/be15d6212f278027c257f9dd67e5b2719e9f730a/docker
> > > > > directory
> > > > > 
> > > > > each project has a direcoty in the docker directory and then each
> > > > > contaienr that project has has a directory in the project directory
> > > > > 
> > > > > so the aodh project has a aodh folder
> > > > > 
> > > https://github.com/openstack/kolla/tree/be15d6212f278027c257f9dd67e5b2719e9f730a/docker/aodh
> > > > > the convention is to have a <project>-base contaienr which handels the
> > > > > depency installation and then one addtional contaienr for each binary
> > > deamon
> > > > > the project has i.e. aodh-api
> > > > > 
> > > > > the name of the folder in teh project dir is used as the name of the
> > > > > contaienr
> > > > > 
> > > > > if we look at the content of the docker files we will see that they
> > > are
> > > > > not actuly dockerfiles
> > > > > 
> > > > > 
> > > https://github.com/openstack/kolla/blob/be15d6212f278027c257f9dd67e5b2719e9f730a/docker/aodh/aodh-api/Dockerfile.j2
> > > > > 
> > > > > they are jinja2 templates that produce docker files
> > > > > 
> > > > > kolla as far as i am aware has drop support for binary images and
> > > > > alternitiv distos
> > > > > 
> > > > > but looking at an older release we can se ehow this worked
> > > > > 
> > > > > 
> > > https://github.com/openstack/kolla/blob/stable/wallaby/docker/nova/nova-base/Dockerfile.j2#L13-L52
> > > > > 
> > > > > each docker file template would use the jinja2 to generate a set of
> > > > > concreate docker files form the template
> > > > > and make dession based on the parmater passed in.
> > > > > 
> > > > > so when you are invokeing
> > > > > kolla-build -b ubuntu -t source keystone nova neutron glance
> > > > > 
> > > > > what actully happening is that the -t flag is being set as teh
> > > > > install_type parmater in the the jinja2 environemtn when
> > > > > the docker file is rendered.
> > > > > 
> > > > > after all the docer files are rendered into normal docker files kolla
> > > just
> > > > > invokes the build.
> > > > > 
> > > > > in the case of a source build that inovles pre fetching the source tar
> > > > > from https://tarballs.opendev.org
> > > > > and puting it in the build directory so that it can be included into
> > > the
> > > > > contianer.
> > > > > 
> > > > > kolla also used to supprot git repo as a alternitve  source fromat
> > > > > 
> > > > > i have glossed over a lot of the details of how this actully work but
> > > that
> > > > > is the essence of what that command is doing
> > > > > creating a build dir, downloading the source, rendering the dockerfile
> > > > > templates to docker files, invokeing docker build on those
> > > > > and then taging them with the contaienr nameand build tag
> > > > > 
> > > > > 
> > > > > https://docs.openstack.org/kolla/latest/admin/image-building.html
> > > > > covers this form a high level
> > > > > 
> > > > > >   because in command output
> > > > > > I've not noticed anything related to the compiling process going on.
> > > > > > 
> > > > > > Here is the output of all images produced by kolla-build command.
> > > Do I
> > > > > need
> > > > > > anything else or is this enough to deploy kolla?
> > > > > you can deploy coll with what you have yes although since the kolla
> > > files
> > > > > are automaticaly
> > > > > built by ci kolla-ansible can just use the ones form the docker hub or
> > > > > quay instead you do not need to build them yourself
> > > > > 
> > > > > if you do build them your self then there is basically one other stpe
> > > that
> > > > > you shoudl take if this si a multi node deployment
> > > > > you should push the iamges to an interally host docker registry
> > > although
> > > > > based on the hostname in the prompt below
> > > > > it looks like you ahve alredy done that.
> > > > > > 
> > > > > > root at docker-reg:~# docker images
> > > > > > REPOSITORY                            TAG       IMAGE ID
> > >  CREATED
> > > > > >         SIZE
> > > > > > kolla/mariadb-server                  15.1.0    2a497eee8269   26
> > > minutes
> > > > > > ago      595MB
> > > > > > kolla/cron                            15.1.0    342877f26a8a   30
> > > minutes
> > > > > > ago      250MB
> > > > > > kolla/memcached                       15.1.0    0d19a4902644   31
> > > minutes
> > > > > > ago      250MB
> > > > > > kolla/mariadb-clustercheck            15.1.0    d84427d3c639   31
> > > minutes
> > > > > > ago      314MB
> > > > > > kolla/mariadb-base                    15.1.0    34447e3e59b6   31
> > > minutes
> > > > > > ago      314MB
> > > > > > kolla/keepalived                      15.1.0    82133b09fbf0   31
> > > minutes
> > > > > > ago      260MB
> > > > > > kolla/prometheus-memcached-exporter   15.1.0    6c2d605f70ee   31
> > > minutes
> > > > > > ago      262MB
> > > > > > <none>                                <none>    e66b228c2a07   31
> > > minutes
> > > > > > ago      248MB
> > > > > > kolla/rabbitmq                        15.1.0    8de5c39379d3   32
> > > minutes
> > > > > > ago      309MB
> > > > > > kolla/fluentd                         15.1.0    adfd19027862   33
> > > minutes
> > > > > > ago      519MB
> > > > > > kolla/haproxy-ssh                     15.1.0    514357ac4d36   36
> > > minutes
> > > > > > ago      255MB
> > > > > > kolla/haproxy                         15.1.0    e5b9cfdf6dfc   37
> > > minutes
> > > > > > ago      257MB
> > > > > > kolla/prometheus-haproxy-exporter     15.1.0    a679f65fd735   37
> > > minutes
> > > > > > ago      263MB
> > > > > > kolla/prometheus-base                 15.1.0    afeff3ed5dce   37
> > > minutes
> > > > > > ago      248MB
> > > > > > kolla/glance-api                      15.1.0    a2241f68f23a   38
> > > minutes
> > > > > > ago      1.04GB
> > > > > > kolla/glance-base                     15.1.0    7286772a03a4
> > >  About an
> > > > > > hour ago   1.03GB
> > > > > > kolla/neutron-infoblox-ipam-agent     15.1.0    f90ffc1a3326
> > >  About an
> > > > > > hour ago   1.05GB
> > > > > > kolla/neutron-server                  15.1.0    69c844a2e3a9
> > >  About an
> > > > > > hour ago   1.05GB
> > > > > > kolla/neutron-l3-agent                15.1.0    4d87e6963c96
> > >  About an
> > > > > > hour ago   1.05GB
> > > > > > <none>                                <none>    486da9a6562e
> > >  About an
> > > > > > hour ago   1.05GB
> > > > > > kolla/neutron-linuxbridge-agent       15.1.0    e5b3ca7e099c
> > >  About an
> > > > > > hour ago   1.04GB
> > > > > > kolla/neutron-bgp-dragent             15.1.0    ac37377820c6
> > >  About an
> > > > > > hour ago   1.04GB
> > > > > > kolla/ironic-neutron-agent            15.1.0    90993adcd74b
> > >  About an
> > > > > > hour ago   1.04GB
> > > > > > kolla/neutron-metadata-agent          15.1.0    8522f147f88d
> > >  About an
> > > > > > hour ago   1.04GB
> > > > > > kolla/neutron-sriov-agent             15.1.0    8a92ce7d13c0
> > >  About an
> > > > > > hour ago   1.04GB
> > > > > > kolla/neutron-dhcp-agent              15.1.0    5c214b0171f5
> > >  About an
> > > > > > hour ago   1.04GB
> > > > > > kolla/neutron-metering-agent          15.1.0    7b3b91ecd77b
> > >  About an
> > > > > > hour ago   1.04GB
> > > > > > kolla/neutron-openvswitch-agent       15.1.0    1f8807308814
> > >  About an
> > > > > > hour ago   1.04GB
> > > > > > kolla/neutron-base                    15.1.0    f85b6a2e2725
> > >  About an
> > > > > > hour ago   1.04GB
> > > > > > kolla/nova-libvirt                    15.1.0    0f3ecefe4752
> > >  About an
> > > > > > hour ago   987MB
> > > > > > kolla/nova-compute                    15.1.0    241b7e7fafbe
> > >  About an
> > > > > > hour ago   1.47GB
> > > > > > kolla/nova-spicehtml5proxy            15.1.0    b740820a7ad1
> > >  About an
> > > > > > hour ago   1.15GB
> > > > > > kolla/nova-novncproxy                 15.1.0    1ba2f443d5c3
> > >  About an
> > > > > > hour ago   1.22GB
> > > > > > kolla/nova-compute-ironic             15.1.0    716612107532
> > >  About an
> > > > > > hour ago   1.12GB
> > > > > > kolla/nova-ssh                        15.1.0    ae2397f4e1c1
> > >  About an
> > > > > > hour ago   1.11GB
> > > > > > kolla/nova-api                        15.1.0    2aef02667ff8
> > >  About an
> > > > > > hour ago   1.11GB
> > > > > > kolla/nova-conductor                  15.1.0    6f1da3400901
> > >  About an
> > > > > > hour ago   1.11GB
> > > > > > kolla/nova-scheduler                  15.1.0    628326776b1d
> > >  About an
> > > > > > hour ago   1.11GB
> > > > > > kolla/nova-serialproxy                15.1.0    28eb7a4a13f8
> > >  About an
> > > > > > hour ago   1.11GB
> > > > > > kolla/nova-base                       15.1.0    e47420013283
> > >  About an
> > > > > > hour ago   1.11GB
> > > > > > kolla/keystone                        15.1.0    e5530d829d5f   2
> > > hours
> > > > > ago
> > > > > >         947MB
> > > > > > kolla/keystone-ssh                    15.1.0    eaa7e3f3985a   2
> > > hours
> > > > > ago
> > > > > >         953MB
> > > > > > kolla/keystone-fernet                 15.1.0    8a4fa24853a8   2
> > > hours
> > > > > ago
> > > > > >         951MB
> > > > > > kolla/keystone-base                   15.1.0    b6f9562364a9   2
> > > hours
> > > > > ago
> > > > > >         945MB
> > > > > > kolla/barbican-base                   15.1.0    b2fdef1afb44   2
> > > hours
> > > > > ago
> > > > > >         915MB
> > > > > > kolla/barbican-keystone-listener      15.1.0    58bd59de2c63   2
> > > hours
> > > > > ago
> > > > > >         915MB
> > > > > > kolla/openstack-base                  15.1.0    c805b4b3b1c1   2
> > > hours
> > > > > ago
> > > > > >         893MB
> > > > > > kolla/base                            15.1.0    f68e9ef3dd30   2
> > > hours
> > > > > ago
> > > > > >         248MB
> > > > > > registry                              2         8db46f9d7550   19
> > > hours
> > > > > ago
> > > > > >        24.2MB
> > > > > > ubuntu                                22.04     08d22c0ceb15   3
> > > weeks
> > > > > ago
> > > > > >         77.8MB
> > > > > 
> > > > > 
> > > 
> > > 



From nemanja at nemanjamiletic.com  Mon Apr  3 13:05:42 2023
From: nemanja at nemanjamiletic.com (Nemanja Miletic)
Date: Mon, 03 Apr 2023 15:05:42 +0200
Subject: [nova][dev] image to local block device mapping not supported
In-Reply-To: <4ea436ac9afc02e69a4c5f447d4e049a41627708.camel@redhat.com>
References: <3b2e2326-3680-4845-a71c-9bbf7ea6adfb@app.fastmail.com>
 <4ea436ac9afc02e69a4c5f447d4e049a41627708.camel@redhat.com>
Message-ID: <81042532-9b57-4ca0-857f-adb215654096@app.fastmail.com>


On Mon, Apr 3, 2023, at 2:33 PM, Sean Mooney wrote:
> On Mon, 2023-04-03 at 10:44 +0200, Nemanja Miletic wrote:
>> Hello,
>> 
>> Nova does not support image to local block device mapping since issue in this bug is fixed:
>> https://bugs.launchpad.net/nova/+bug/1377958
>> 
>> In particular I am interested in scenario best described with this command:
>> openstack server create --flavor m1.small --network mgmt --image XXX \
>> --block-device uuid=YYY,source_type=image,\
>> destination_type=local,disk_bus=ide,device_type=cdrom,boot_index=1 testvm300
>> 
>> For above command nova gives error:
>> Block Device Mapping is Invalid: Mapping image to local is not supported.
>> 
>> Libvirt does not have issues with having two block devices which have file source.
>> 
>> My question is what am I missing here? Why Nova does not support image to local block device mapping?
> the simple answer is that if we allow this then you could eiasly fill 
> the hosts root file system
>
> in yoru exmaple you are using two diffent images but the size of the 
> second image YYY would not be accounted for in the
> placment  resouce allocation of local vm usage.
>
> if you created a 100TB glance image as a qcow and then specifed it on a 
> host that was configure ot use raw storage
> that file will get converted and fill the host storage.
> if the YYY image is a driver disk or install iso then generally we 
> would suggest takign a differnt approch
> if its a driver disk then you would boot a vm form the XXX image as 
> normal and attach the iso as a cinder volume.
> if it was a install iso then the normal workflow is described here 
> https://docs.openstack.org/nova/rocky/user/launch-instance-using-ISO-image.html
>

In my use case both boot image and CD-ROM need to be present on first
boot. (cd-rom contains bootstrap data for the image, can not use user-data
as it is limited to 64k). I have a cluster without Cinder (block
storage). The only workaround I see is to deploy Cinder with LVM backend on one
node and use volume as a destination_type for cd-rom. That is a waste as
cd-rom data can be thrown away after first boot but it seems like an only
option. Please correct me if I am wrong. I am also planing to use Heat to
deploy the image in an automated way so first booting and then attaching
cdrom is not an option. 


From dmendiza at redhat.com  Mon Apr  3 13:28:52 2023
From: dmendiza at redhat.com (Douglas Mendizabal)
Date: Mon, 3 Apr 2023 09:28:52 -0400
Subject: [barbican] database is growing and can not be purged
In-Reply-To: <CACfB1uuYTL9gbwd8aL2NUgkihfPuVxThQuPifpc5Azm5XXKOgg@mail.gmail.com>
References: <CACfB1ut8giZzcEKgGCy0CyEop8bbqeKnbSPH8owqqR6eLmQGPA@mail.gmail.com>
 <CACfB1uuYTL9gbwd8aL2NUgkihfPuVxThQuPifpc5Azm5XXKOgg@mail.gmail.com>
Message-ID: <6e16a154-f6e5-7a36-d432-37a21d4cad51@redhat.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 3/21/23 08:58, Pavlo Shchelokovskyy wrote:
 > Hi all,
 >
 > after having some thoughts, I came to another solution, that I think is
 > the most appropriate here, kind of a variation of option 1:
 >
 > 4. Castellan should cleanup intermediate resources before returning
 > secret ID(s) to the caller
 >
Hi Pavlo,

We discussed this issue during last week's PTG sessions [1], and we
agree that this approach makes sense from a Castellan point of view.

 > As I see it now, the root of the problem is in castellan's
 > BarbicanKeyManager and the way it hides implementation details from the
 > user.
 > Since it returns only IDs of created secrets to the user, the api caller
 > has no notion that something else has to be deleted once it is time for
 > this.
 > Since Barbican API is perfectly capable to delete orders and containers
 > without deleting the secrets they reference, this is what castellan
 > should do just before it returns IDs of generated secrets to the API 
caller.
 > The only small trouble is that with default 'legacy' API policies in
 > Barbican, not everybody who can create orders can delete them.. but this
 > can be accounted for with try..except.
 >
I think it would make sense to update the legacy policies to allow
users with the "creator" role to delete orders.  This change is similar
to a change we made to the Secrets policy to allow deletion by users
with the "creator" role as well. [2]

 > Please review the patch in this regard
 > https://review.opendev.org/c/openstack/castellan/+/877423
 > <https://review.opendev.org/c/openstack/castellan/+/877423>
 >

Thanks for the patch, I've added it to my review queue.

Additionally, we discussed some changes we'll make to the API this
cycle to hopefully make it easier to manage orders:

* Add a new API Mircoversion so we can
   * Add a new "genrated_by" field to the Secret and Container metadata
     that contains the order ID for secrets/containers that were created
     by an order.  This would be null for secrets not created by an Order.
   * Cascade delete the Order when the secret or container is deleted.

We'll also be looking at the barbican-manage CLI to make sure that
purging deleted secrets is working as expected.

Regards,
- - Douglas Mendiz?bal

[1] https://etherpad.opendev.org/p/march2023-ptg-barbican
[2] https://storyboard.openstack.org/#!/story/2009791
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEwcapj5oGTj2zd3XogB6WFOq/OrcFAmQq1FoACgkQgB6WFOq/
OrcZ3A/+LIFg19DbIPbDBXkCe2I500epuaVXK9TKoslZnKfc1cBlFA/KXJ6oT/Jt
QBi+5BtmwKr/EF7hS2zCW1s0wuq0IcFyqeXF3Ucy+++U124prNSMlyrpizamWxnq
nrz8YVpSQ268zgDgyzz95NCMUXqfzmkr/yEEZmLsrY/WKU3wIRJt8A/OOrtyhLcd
YYjAwGjXfEVPM6DoBNcR3tbaHEEf46CpbRumx4zcRGDiydrOjODX/Mm4DyL94gR9
qSfO5F9MvZLT+ntim/grTQ/lNMye5uKiCHEexDJSgP/hoHcPiUQo8SpQyRMcYB/e
Fxx10PactyiXumctuNBFuIT3rWiimsRzf5JIW9EEIoGjZEeT43dhs9C1sfRuuqHP
z6E6A/8/FpZlJny0QOCr4/mQvSQiFZI7dZMKrqZZOZ1viF6w0AAnYBR4E57/pmLp
pXTfRwFE2FeI6xPgpoxz4R28ky5BakyQSC5DSoy8gcVLfkKJPjbe27nrTgERGE+Y
S1/NDan3DJBcAkyBdD1NZaWw3Yvrx9EIc9H07genb+9bwdSY2/zc5VzP6dSyt78i
M9BFH1xMJxigKHB02YkonxbY895v1uHjaE7yJU+AhAjJ+Ep0Gy59Cwsg71AAmvtC
0AL4c56C4uWYjVTcigu3PdTdaFNXlM21yCZwuDLUwHPt1vF1eZA=
=ttcw
-----END PGP SIGNATURE-----



From nguyenhuukhoinw at gmail.com  Mon Apr  3 13:34:16 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Mon, 3 Apr 2023 20:34:16 +0700
Subject: [horizon]display quota volume type on horizon
Message-ID: <CABAODRf2FWL-fc+bWCdzWLCygy1NF29EWFyEZs7Mpn6X1HNBKQ@mail.gmail.com>

Hello.
I see that blueprint is very real case but it has not deployed yet.

https://blueprints.launchpad.net/horizon/+spec/quotas-per-cinder-volume-type

I am curious why it is abanddoned .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/5fe075a9/attachment.htm>

From rdhasman at redhat.com  Mon Apr  3 14:44:22 2023
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Mon, 3 Apr 2023 20:14:22 +0530
Subject: [ptls] PyPI maintainer cleanup - Action needed: Contact extra
 maintainers
In-Reply-To: <CA+sTGNd6vk47SwCMgcRz_qA5ChjJL+x7+qD8j692gHV1Q3am8Q@mail.gmail.com>
References: <CA+sTGNfCy+w9uLqpz3KFEGo14h7Qxy_6gRx7htceSDKLABgpzQ@mail.gmail.com>
 <CA+sTGNe-7TCy4qea+5WArWBzjtXyDE6LZ5665DvGOWX4HxmAzQ@mail.gmail.com>
 <CA+sTGNd6vk47SwCMgcRz_qA5ChjJL+x7+qD8j692gHV1Q3am8Q@mail.gmail.com>
Message-ID: <CAARK8KQo1KXiMVawrVT2t_a37zEakoAN-2m9L0DmcHNsnAckRg@mail.gmail.com>

Hi Jay,

We have some maintainers that are not active in the Cinder project for
quite some time.
I'm sure they will agree to the idea we have but it's not easy to reach
them for the changes
to be made (Tried to reach out but received no response).
I wanted to know if this problem is being faced by other projects also? and
Do we have a solution for such scenarios?

Thanks
Rajat Dhasmana

On Wed, Mar 22, 2023 at 9:55?PM Jay Faulkner <jay at gr-oss.io> wrote:

> Hey all,
>
> Wanted to remind you all: vPTG is a great time to address this issue! Even
> if the PyPI maintainers you would need to contact are emeritus
> contributors; you may have someone still on the project team who has
> contact with them. I strongly recommend you utilize this time to help clean
> your projects up.
>
> Thanks,
> Jay Faulkner
> TC Vice-Chair
>
> On Tue, Mar 21, 2023 at 9:03?AM Jay Faulkner <jay at gr-oss.io> wrote:
>
>> Thanks to those who have already taken action! Fifty extra maintainers
>> have already been removed, with around three hundred to go.
>>
>> Please reach out to me if you're having trouble finding current email
>> addresses for anyone, or having trouble with the process at all.
>>
>> Thanks,
>> Jay Faulkner
>> TC Vice-Chair
>>
>>
>> On Thu, Mar 16, 2023 at 3:22?PM Jay Faulkner <jay at gr-oss.io> wrote:
>>
>>> Hi PTLs,
>>>
>>> The TC recently voted[1] to require humans be removed from PyPI access
>>> for OpenStack-managed projects. This helps ensure all releases are created
>>> via releases team tooling and makes it less likely for a user account
>>> compromise to impact OpenStack packages.
>>>
>>> Many projects have already updated
>>> https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L33
>>> with a list of packages that contain extra maintainers. We'd like to
>>> request that PTLs, or their designate, reach out to any extra maintainers
>>> listed for projects you are responsible for and request they remove their
>>> access in accordance with policy. An example email, and detailed steps to
>>> follow have been provided at
>>> https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup-email-template
>>> .
>>>
>>> Thank you for your cooperation as we work to improve our security
>>> posture and harden against supply chain attacks.
>>>
>>> Thank you,
>>> Jay Faulkner
>>> TC Vice-Chair
>>>
>>> 1:
>>> https://opendev.org/openstack/governance/commit/979e339f899ef62d2a6871a99c99537744c5808d
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/67be70c1/attachment.htm>

From johnsomor at gmail.com  Mon Apr  3 14:51:41 2023
From: johnsomor at gmail.com (Michael Johnson)
Date: Mon, 3 Apr 2023 07:51:41 -0700
Subject: [designate] Proposal to deprecate the agent framework and agent
 based backends
In-Reply-To: <a43f7293-29c5-0c15-679c-7f794e976ae3@inovex.de>
References: <CAMH0MgJFtt_FJG3rWk7qyT=y_5ZUVrm1ZyTKOQ90T2R6hmBA5w@mail.gmail.com>
 <c8d3c12f-9807-11e1-582a-01c30e4a3f41@inovex.de>
 <CAMH0MgJAyyUyUgMM20+GLew_Tc-jXAEo9hDCfgtEqcQD2OVmQw@mail.gmail.com>
 <a43f7293-29c5-0c15-679c-7f794e976ae3@inovex.de>
Message-ID: <CAMH0MgK_dPF4YfzGbkoykpupNXoF0mMrzWWTW8F49pC0K4Z6=w@mail.gmail.com>

Hi Christian,

We just had the virtual PTG last week and discussed this topic[1].

As you know, we completed the specification document and merged it
during Antelope. So the community agrees on the plan to implement. At
this point it just needs developers to start work on the patches.

During the PTG session no one attending was able to pick up this
specification for development, so we did not highlight it as a feature
targeted for Bobcat. I did say that I am willing to help anyone that
has developer resources work on it, I just cannot lead that effort
during Bobcat.

So if you are willing to work on the patches, we will help out as we
can with reviews and answering questions, etc.

Michael

[1] https://etherpad.opendev.org/p/march2023-ptg-designate

On Mon, Apr 3, 2023 at 12:36?AM Christian Rohmann
<christian.rohmann at inovex.de> wrote:
>
> Hey Michael,
>
>
> On 18/01/2023 23:50, Michael Johnson wrote:
>
> Personally I think the specification is very close to being complete,
> I think we just need to agree on these last few design items and we
> can push for reviews.
>
> As I was looking at these agent based drivers, it was very obvious
> that the catalog zones may eliminate the need for some of the agent
> based drivers. That is awesome and your proposal to add catalog zone
> support is perfectly timed.
>
> Michael
>
>
> On Wed, Jan 18, 2023 at 2:19 PM Christian Rohmann
> <christian.rohmann at inovex.de> wrote:
>
> Hey Michael, openstack-discuss,
>
> On 17/01/2023 01:52, Michael Johnson wrote:
>
> 6. The introduction of catalog zones[6] may eliminate the need for
> some of the agent based backend drivers.
>
> I proposed the spec to have catalog zone support added to Designate, see
> https://review.opendev.org/c/openstack/designate-specs/+/849109.
>
>
> May I ask what the intended way forward with implementing the newly merged "catalog zones spec" is?
> Is this targeting the Bobcat release?
>
>
>
> Regards
>
>
> Christian


From sbauza at redhat.com  Mon Apr  3 14:57:31 2023
From: sbauza at redhat.com (Sylvain Bauza)
Date: Mon, 3 Apr 2023 16:57:31 +0200
Subject: [nova] 2023.2 Bobcat PTG summary
Message-ID: <CALOCmunNB4s+VmRxX+gO-pinCcwOARGDLF4jgMB7vOT49WwS+Q@mail.gmail.com>

Hey folks, that's a wrap ! I'm happy to say we had a very productive PTG
week with around more than 12 contributors each day. It was nice to see new
faces.

As a reminder, please don't open the main etherpad link [1] if you use a
Web browser with an automatic translation modification feature. If you do
it, then it would internally translate all the phrases directly in the
etherpad as if you were directly modifying the etherpad by yourself. Please
also make sure you don't accidentally remove or modify lines .

In order to prevent any misusage, this etherpad is a read-only copy of the
main one : https://etherpad.opendev.org/p/r.22d95e20f7133350dcad573c015ed7da

Last point but not the least, I'm a human who usually writes bugs [2],
including when it's about writing a report of the past week's discussions
and the actions taken. Don't feel offended or irritated if you read silly
notes of the very beloved chat you had, please rather fix it the opensource
way by correcting my errors with a reply on that thread.

Enough chat, please grab a coffee [3] (as it's a quite verbose email) and
jump straight on below.

### Operator hour ###
(specific and distinct read-only etherpad here :
https://etherpad.opendev.org/p/r.f94e6dda608450b6a4a5c9afc76e8a88 )
Yet again, we missed a few more operators in this room (at least we had 3
of them, thanks for those that were there !). I'm still wondering why they
are not joining a free session where they can discuss their concerns or
some wanted features. Anyway, that's what we discussed :
 - for the moment, no operators have tried to use the Yoga unified limits
feature.
 - operators are happy with the new default RBAC scopes. We could create a
small and quick admin-guide section for explaining that and pointing to the
oslo.policy documentation.
 - operators would love to use the (possibly) new virtiofs feature from
Bobcat for Manila shares (if we are able to merge it). That being said,
they think they couldn't provide it for their environments until Nova can
live-migrate the instances using the shares (which is not possible as for
the moment, even QEMU doesn't support it)
 - we also discussed a pain point from an operator and then we asked him to
provide a bug report (related to the vm state continuing to be ACTIVE after
shelving). For the moment, we can't reproduce the problem.

### Cross-project discussions ###

## Manila/Nova ###

# Prevent shares deletion while it's attached to an instance
 - Nova could add some traits to reflect the share type.
 - the Manila team will create a manila spec for adding a service-level (or
admin-level) lock API with a 'locked-by' parameter (or using service tokens
if set)

### Neutron/Nova ###
Read Neutron summary email [4] if you want more details.

 - We agreed on a delete_on_termination feature for ports. We need to see
if we can use some already existing Neutron API (tags) or if we need a
whole new API.
 - We are quite OK with the Napatech LinkVirt SmartNics feature, but we
need to review the spec and we also want some third-party CI support for it.
 - the Neutron team accepted to return a HTTP409 Conflict return code if a
duplicated port binding action is done by Nova and the Nova team agreed on
handling it.
 - About the SRIOV port tracking in Placement, the Nova team needs to help
the spec owner on how to work on it as it's a large and difficult design
(but we agreed on the first part of the design).

### Glance/Nova ###

Glance wants to add a new API for Image Direct URL access. Nova was quite
OK with this new API, but the Nova team was having some concerns about
upgrades and client calls to the new API. The Manila team agreed to create
a nova spec for discussing those.

### Cinder/Nova ###

- The Nova team is quite OK with the usecase for NFV encryption. Since the
design is quite simple, maybe this could be a specless feature, just using
traits for telling to Placement which computes support NFV encryption.
We're OK to test this with cinder NFV jobs and maybe also testing it with a
Nova periodic job depending on the implementation.
 - The Cinder team agreed on using its volume metadata API for tracking the
cinder volumes hardware models.

### Horizon/Nova ###

Horizon wanted to call the Placement API. We agreed on using the
openstackSDK for this as Placement doesn't have python bindings directly.
Some new methods may be added against the SDK for calling specific
Placement APIs if we think we may need those (instead of directly calling
Placement with the standard HTTP verbs and the API URIs)

### Nova-specific topics ###

# Antelope retrospective and process-related discussions

Shorter cycle than Zed, 6 features landed (same as Zed), 46 contributors
(down by 8 compared to Zed), 27 bugfixes (vs. 54 for Zed).
We were happy to not have a RC2 for the first time in the Nova history. The
bug triage backlog kept small.
 - We want to discuss on a better review cadence to not look at all the
implementations by the last weeks.
 - We want to get rid of Storyboard stories in Placement. We found and
agreed on a way forward.
 - We will set 5-years-old-and-more bug reports as Incomplete, so bug
reporters have 90 days to confirm that the bug is still present on master.
 -  We will add more contrib documentation for explaining more how to find
Gerrit changes for one-off reviewers and how to create some changes
 - We agreed on no longer automatically accepting an already-approved spec
from a previous cycle if no code is still not existing.
 - All efforts on porting our client calls to the SDK should be tagged in
Launchpad with the 'sdk' tag.
 - A Bobcat schedule will be proposed on next Tuesday weekly meeting with
feature and spec deadlines + some review days.
 - We also discussed what we should discuss in the Vancouver PTG.

# CI failures continuous improvement

- We want to test some alternative image but cirros (alpine as a potential
alternative) with a small footprint in some specific nova jobs
- We need to continue investigating on the volume detach/attach failures.
We may create a specific job that would do serialized volume checks as a
canary job for forcing the job to fail more frequently in order to dig down
further.
- (related) Sylvain will propose a Vancouver PTG cross-project session for
a CI debugging war room experience.

# The new release cadence

We had long arguments whether we should hold deprecations and removals this
cycle, given the releasenotes tooling isn't in place yet. As a reminder,
since Bobcat is a non-SLURP release, operators are able to skip it and just
look at the C releasenotes so we want to make sure we forward-port upgrade
notes for them. For the moment, no consensus in place, we defer the outcome
into a subsequent nova meeting and in the meantime, we raised the point to
the TC for guidance needs.

# The problem with hard affinity group policies

- We agreed on the fact that hard affinity/anti-affinity policies aren't
ideal (operators, if you read me, please prefer soft affinity/anti-affinity
policies for various reasons I won't explain here) but since we support
those policies and the use case is quite understandable, we need to find a
way to unblock instances that can't be easily-migrated from those kind of
groups (eg. try to move your instances off a host with hard Affinity
between them, good luck)
- A consensus has been reached to propose a new parameter for live-migrate,
evacuate and migrate that would only skip the hard affinity checks. A
backlog spec will be written capturing this consensus.
- Since a group policy may be violated, we'll also propose a new server
group API modification that would show if a group has its policy violated.

# Unified limits next steps

- We agreed on the fact we should move on and enable by default unified
limits in a close future, but we first need to provide a bit of tooling to
help the migration.
- tool could be a nova-manage command that would provide the existing quota
limits as a yaml file so we could inject those into keystone (to be further
defined during Bobcat)
- a nova-status upgrade check may be nice for yelling if operators forgot
to define their limits in keystone before upgrading to the release
(potentially C) that would default to unified limits
- testing in the grenade job is a feat.

# Frequently written objects may lead to exhaustion of DB primary keys
- We agreed on having all new primary keys to have BigInteger as data type.
Existing keys should use BigInt but there is a huge upgrade impact to
mitigate.
- Operators will be sollicited to know their preferences between a
costly-at-once data migration vs. a rolling data online migration for
existing tables.
- We will document which DB tables are safe to reindex (since their PKs
isn't normalized as a FK somewhere else)
- A backlog spec will capture all of the above

# Leftover volumes relationship when you directly call Cinder instead of
Nova for detaching
- Yup, this is a known issue and we should discuss this with the Cinder
team (unfortunately, we didn't did it this week)
- We maybe should have a nova-manage script that would cleanup the BDMs but
we're afraid of leaking some volume residues in the compute OS
- Anyway, we need to understand the main scope and we also need to discuss
about the preconditions ('when' should we call this tool and 'what' this
tool should be doing ?). Probably a spec.

# Misc but not the leasc (heh)

 - we will fill a rfe bug for lazy-loading instance name from system
metadata or update the nested field in the instance object (no additional
DB write)
 - we will add a new policy for cold-migrate specifically when a host is
passed as a parameter (admin-only as a default)
 - We agreed on continuing the effort on compute node hostname
robustification (the Bobcat spec seems not controversial)
 - We agreed on a few things about the server show command and the use of
the SDK. Some existing OSC patch may require a bit of rework but it would
cover most of the concerns we discussed.
 - we should fix the post-copy issue when you want to live-migrate a paused
instance by removing the post-copy migration flag if so.
 - we could enable virtio-blk trim support by default. It's both a bugfix
(we want to remove an exception) and a new feature (we want to enable it by
default) so we'll discuss whether we need a specless blueprint by a next
meeting.
 - we also discuss about a Generic VDPA support feature for Nova, and we
asked the owner to provide us a spec for explaining the usecase.

### That's it. ###

Yet again, I'm impressed. If you read that phrase, you're done with
reading. I just hope your coffee was good and the time you took reading
that email was worth it. If you have questions or want to reach me directly
on IRC, that's simple : I'm bauzas on #openstack-nova.

HTH,
-Sylvain (on behalf of the whole Nova community)


[1] https://etherpad.opendev.org/p/nova-bobcat-pt g (please remove the
empty char between 'pt' and 'g')
[2] Unfortunately, I'm very good at creating bugs as I discovered that
based on my 10-year unfortunate contributions to OpenStack.
[3] Or a tea, or whatever you prefer.
[4]
https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033115.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/fe1d2530/attachment-0001.htm>

From jay at gr-oss.io  Mon Apr  3 15:14:49 2023
From: jay at gr-oss.io (Jay Faulkner)
Date: Mon, 3 Apr 2023 08:14:49 -0700
Subject: [ptls] PyPI maintainer cleanup - Action needed: Contact extra
 maintainers
In-Reply-To: <CAARK8KQo1KXiMVawrVT2t_a37zEakoAN-2m9L0DmcHNsnAckRg@mail.gmail.com>
References: <CA+sTGNfCy+w9uLqpz3KFEGo14h7Qxy_6gRx7htceSDKLABgpzQ@mail.gmail.com>
 <CA+sTGNe-7TCy4qea+5WArWBzjtXyDE6LZ5665DvGOWX4HxmAzQ@mail.gmail.com>
 <CA+sTGNd6vk47SwCMgcRz_qA5ChjJL+x7+qD8j692gHV1Q3am8Q@mail.gmail.com>
 <CAARK8KQo1KXiMVawrVT2t_a37zEakoAN-2m9L0DmcHNsnAckRg@mail.gmail.com>
Message-ID: <CA+sTGNc3W=A5=bkob_9J1Uvc2jtBrvwgxtGpR3Tr+KburYURYA@mail.gmail.com>

Hey Rajat,

Thanks for talking to your contributors, and trying to find contacts for
older contributors. I do think we'll have a few projects in this state, and
the TC will likely take action to advance those. We wanted to clean up as
much as possible through cooperative action first.

Thanks,
Jay Faulkner
TC Vice-Chair

On Mon, Apr 3, 2023 at 7:44?AM Rajat Dhasmana <rdhasman at redhat.com> wrote:

> Hi Jay,
>
> We have some maintainers that are not active in the Cinder project for
> quite some time.
> I'm sure they will agree to the idea we have but it's not easy to reach
> them for the changes
> to be made (Tried to reach out but received no response).
> I wanted to know if this problem is being faced by other projects also?
> and Do we have a solution for such scenarios?
>
> Thanks
> Rajat Dhasmana
>
> On Wed, Mar 22, 2023 at 9:55?PM Jay Faulkner <jay at gr-oss.io> wrote:
>
>> Hey all,
>>
>> Wanted to remind you all: vPTG is a great time to address this issue!
>> Even if the PyPI maintainers you would need to contact are emeritus
>> contributors; you may have someone still on the project team who has
>> contact with them. I strongly recommend you utilize this time to help clean
>> your projects up.
>>
>> Thanks,
>> Jay Faulkner
>> TC Vice-Chair
>>
>> On Tue, Mar 21, 2023 at 9:03?AM Jay Faulkner <jay at gr-oss.io> wrote:
>>
>>> Thanks to those who have already taken action! Fifty extra maintainers
>>> have already been removed, with around three hundred to go.
>>>
>>> Please reach out to me if you're having trouble finding current email
>>> addresses for anyone, or having trouble with the process at all.
>>>
>>> Thanks,
>>> Jay Faulkner
>>> TC Vice-Chair
>>>
>>>
>>> On Thu, Mar 16, 2023 at 3:22?PM Jay Faulkner <jay at gr-oss.io> wrote:
>>>
>>>> Hi PTLs,
>>>>
>>>> The TC recently voted[1] to require humans be removed from PyPI access
>>>> for OpenStack-managed projects. This helps ensure all releases are created
>>>> via releases team tooling and makes it less likely for a user account
>>>> compromise to impact OpenStack packages.
>>>>
>>>> Many projects have already updated
>>>> https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L33
>>>> with a list of packages that contain extra maintainers. We'd like to
>>>> request that PTLs, or their designate, reach out to any extra maintainers
>>>> listed for projects you are responsible for and request they remove their
>>>> access in accordance with policy. An example email, and detailed steps to
>>>> follow have been provided at
>>>> https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup-email-template
>>>> .
>>>>
>>>> Thank you for your cooperation as we work to improve our security
>>>> posture and harden against supply chain attacks.
>>>>
>>>> Thank you,
>>>> Jay Faulkner
>>>> TC Vice-Chair
>>>>
>>>> 1:
>>>> https://opendev.org/openstack/governance/commit/979e339f899ef62d2a6871a99c99537744c5808d
>>>>
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/51882266/attachment.htm>

From richard.buregeya at bsc.rw  Mon Apr  3 15:18:05 2023
From: richard.buregeya at bsc.rw (Richard Buregeya)
Date: Mon, 3 Apr 2023 15:18:05 +0000
Subject: No subject
Message-ID: <DBBPR03MB671641ECA823C20815CDC232F0929@DBBPR03MB6716.eurprd03.prod.outlook.com>

Hello Team,

Hope you are doing well.

Any one with an idea if there is a modification in COA exam, I heard it is now a multiple question exams instead of practical exam,

Anyone with current information, kindly update me.


Thanks a lot!

Regards

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/d4cef095/attachment.htm>

From jimmy at openinfra.dev  Mon Apr  3 16:15:17 2023
From: jimmy at openinfra.dev (Jimmy McArthur)
Date: Mon, 3 Apr 2023 11:15:17 -0500
Subject: No subject
In-Reply-To: <DBBPR03MB671641ECA823C20815CDC232F0929@DBBPR03MB6716.eurprd03.prod.outlook.com>
References: <DBBPR03MB671641ECA823C20815CDC232F0929@DBBPR03MB6716.eurprd03.prod.outlook.com>
Message-ID: <3128971B-5A02-44E2-9F6E-6E01B82BFB31@openinfra.dev>

Hi Richard,

The COA is still a practical exam. You can find more details here: https://openstack.org/coa <https://openstack.org/coa> 

Cheers,
Jimmy




> On Apr 3, 2023, at 10:18 AM, Richard Buregeya <richard.buregeya at bsc.rw> wrote:
> 
> Hello Team,
>  
> Hope you are doing well.
>  
> Any one with an idea if there is a modification in COA exam, I heard it is now a multiple question exams instead of practical exam,
>  
> Anyone with current information, kindly update me.
>  
>  
> Thanks a lot!
>  
> Regards

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/9446110f/attachment-0001.htm>

From richard.buregeya at bsc.rw  Mon Apr  3 16:27:19 2023
From: richard.buregeya at bsc.rw (Richard Buregeya)
Date: Mon, 3 Apr 2023 16:27:19 +0000
Subject: No subject
In-Reply-To: <3128971B-5A02-44E2-9F6E-6E01B82BFB31@openinfra.dev>
References: <DBBPR03MB671641ECA823C20815CDC232F0929@DBBPR03MB6716.eurprd03.prod.outlook.com>
 <3128971B-5A02-44E2-9F6E-6E01B82BFB31@openinfra.dev>
Message-ID: <AM9PR03MB6705C59D076400A51B614C6AF0929@AM9PR03MB6705.eurprd03.prod.outlook.com>

Thanks @Jimmy McArthur<mailto:jimmy at openinfra.dev> appreciated.

From: Jimmy McArthur <jimmy at openinfra.dev>
Sent: Monday, April 3, 2023 6:15 PM
To: Richard Buregeya <richard.buregeya at bsc.rw>
Cc: openstack-discuss at lists.openstack.org
Subject: Re:

Hi Richard,

The COA is still a practical exam. You can find more details here: https://openstack.org/coa

Cheers,
Jimmy




On Apr 3, 2023, at 10:18 AM, Richard Buregeya <richard.buregeya at bsc.rw<mailto:richard.buregeya at bsc.rw>> wrote:

Hello Team,

Hope you are doing well.

Any one with an idea if there is a modification in COA exam, I heard it is now a multiple question exams instead of practical exam,

Anyone with current information, kindly update me.


Thanks a lot!

Regards

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/897f271e/attachment.htm>

From nguyenhuukhoinw at gmail.com  Mon Apr  3 00:18:33 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Mon, 3 Apr 2023 07:18:33 +0700
Subject: [kolla] Image building question
In-Reply-To: <CAPgF-fpXdhgstwXkqtnrz=BQxKjkRgGRkP_uK-4S-993_OsQuQ@mail.gmail.com>
References: <CAPgF-fqFP1YENfG-XsrL2oJQeqzVhUTdJzn2_VwKsZvkvpeApQ@mail.gmail.com>
 <d419fa044dab2f07ff408fc10b7e708185310a48.camel@redhat.com>
 <CAPgF-fqm-OvCzd+My85P8MFe6uobwJ6y_OpFU2K+i7R2u6qdDA@mail.gmail.com>
 <93a78d3cdbc7fb8ca66545a981ca145c6ce21d7a.camel@redhat.com>
 <CAPgF-fpXdhgstwXkqtnrz=BQxKjkRgGRkP_uK-4S-993_OsQuQ@mail.gmail.com>
Message-ID: <CABAODRcAm6K=JDyVWpqwjrOxVsCPG=ms7Ui79G1opySNiPdJVg@mail.gmail.com>

Hello.
I have a question.
Do we need the kolla-ansible version that matches kolla to deploy openstack?

Nguyen Huu Khoi


On Sat, Apr 1, 2023 at 11:27?PM Satish Patel <satish.txt at gmail.com> wrote:

> Thank you sean,
>
> I did following an it works hope this is correct way to customize
>
> {% extends parent_template %}
>
> # Horizon
> {% block horizon_ubuntu_source_setup %}
> RUN apt update -y
> RUN apt install -y net-tools vim
> RUN touch /root/foo
> {% endblock %}
>
>
> $ kolla-build --registry docker-reg:4000 -b ubuntu -t source --tag zed-v2
> --template-override template-overrides.j2 --debug horizon
>
>
> On Fri, Mar 31, 2023 at 1:31?PM Sean Mooney <smooney at redhat.com> wrote:
>
>> On Fri, 2023-03-31 at 10:25 -0400, Satish Patel wrote:
>> > Thank you Sean,
>> >
>> > What a wonderful explanation of the process. Yes I can download images
>> from
>> > the public domain and push them to a local repository but in some cases
>> I
>> > would like to add my own tools like monitoring agents, utilities etc
>> > for debugging so i decided to build my own images.
>> >
>> > I believe https://tarballs.opendev.org is the right place to source
>> > software correctly?
>> that is the offcial location where all opendev/openstack projects are
>> released
>> and its the location distros use to build there packages.
>> >
>> > If I want to add some tools or packages inside images then I should use
>> > Dockerfile.j2 to add and compile images. correct?
>>
>> yes so one of the great things about kolla images is tiem was taken to
>> write
>> down the image api when the project was first started
>> https://docs.openstack.org/kolla/yoga/admin/kolla_api.html
>>
>> over time the common usecaes were then docuemnted in the admin
>> image-building guide
>>
>> https://docs.openstack.org/kolla/yoga/admin/image-building.html#dockerfile-customisation
>>
>>
>> all of the templated imnages have convension/contract that they provide
>> delement that operator can
>> use to add customisations.
>>
>> for examplel the nova_base_footer block and be used to add addtional
>> content to the nova-base image
>>
>> https://github.com/openstack/kolla/blob/master/docker/nova/nova-base/Dockerfile.j2#L82
>>
>> to customise the iamges you provide what is know as a template override
>> file
>>
>> the contrib folder has a number of exmaples
>>
>>
>> https://github.com/openstack/kolla/blob/master/contrib/template-override/ovs-dpdk.j2
>>
>> https://github.com/openstack/kolla/blob/master/contrib/neutron-plugins/template_override-networking-mlnx.j2
>>
>> https://github.com/openstack/kolla/blob/master/contrib/neutron-plugins/template_override-vmware-nsx.j2
>>
>>
>> the way they work is you starte it with
>>
>> {% extends parent_template %}
>>
>> then you just create a block that mages the name of the one you want to
>> repalce
>> {% extends parent_template %}
>>
>> {% block nova_base_footer %}
>>  RUN /bin/true
>> {% endblock %}
>>
>>
>> what ever content you put in the block will be injected directly into the
>> rendered docer file
>>
>>
>>
>> https://docs.openstack.org/kolla/yoga/admin/image-building.html#plugin-functionality
>>
>> show how to use that for neutron
>>
>> in addtion to replacing block you can set the conten of specal variables
>> like horizon_packages_append or horizon_packages_remove
>>
>>
>> https://docs.openstack.org/kolla/yoga/admin/image-building.html#packages-customisation
>>
>> that allow you add an remove packages in a simple way
>> there is also a set of macros that you can use
>>
>> you include them with
>> {% import "macros.j2" as macros with context %}
>>
>> they are defiend here
>> https://github.com/openstack/kolla/blob/master/docker/macros.j2
>>
>> if you know that the docs exist the capablitys are coverd pretty well in
>> the kolla docs you just need to know where to look
>> hopefully that helps.
>>
>> the ovs-dpdk template overide docs can be fouund here
>> https://docs.openstack.org/kolla/yoga/admin/template-override/ovs-dpdk.html
>>
>> its a liltle differnt then the other since there i used the template
>> override mechanium to allow compiling ovs with dpdk form souces
>>
>> kolla normlly does not support that but it serves as a demonstration for
>> how operator can do that if they really need too.
>> i.e. compile a replacment for a minary componet like mariadb. it salso
>> show how to use git as the souce localtion instead
>> of tars if that is your prefernce.
>>
>> >
>> > ~S
>> >
>> > On Fri, Mar 31, 2023 at 7:01?AM Sean Mooney <smooney at redhat.com> wrote:
>> >
>> > > On Thu, 2023-03-30 at 16:49 -0400, Satish Patel wrote:
>> > > > Folks,
>> > > >
>> > > > I am playing with kolla image building to understand how it works.
>> I am
>> > > > using the following command to build images and wanted to check
>> with you
>> > > > folks if that is the correct way to do it.
>> > > >
>> > > > $ kolla-build -b ubuntu -t source keystone nova neutron glance
>> > > >
>> > > > Does the above command compile code from source or just download
>> images
>> > > > from remote repositories and re-compile them?
>> > > >
>> > > openstack is mainly python so in general ther is no complie step.
>> > > but to answer your question that builds the image using the source
>> tarballs
>> > > or the openstakc packages.
>> > >
>> > > the defaults soruce locations are rendered into a file which you can
>> > > override
>> > > from the data stored in
>> > >
>> https://github.com/openstack/kolla/blob/master/kolla/common/sources.py
>> > > the other build config defaults are generated form this code
>> > > https://github.com/openstack/kolla/blob/master/kolla/common/config.py
>> > >
>> > > when you invoke kolla-build its executing
>> > > https://github.com/openstack/kolla/blob/master/kolla/cmd/build.py
>> > > but the main build workflow is here
>> > >
>> https://github.com/openstack/kolla/blob/be15d6212f278027c257f9dd67e5b2719e9f730a/kolla/image/build.py#L95
>> > >
>> > > the tl;dr is the build worklow starts by creating  build director and
>> > > locating the docker file templats.
>> > > in otherwords the content of the
>> > >
>> https://github.com/openstack/kolla/tree/be15d6212f278027c257f9dd67e5b2719e9f730a/docker
>> > > directory
>> > >
>> > > each project has a direcoty in the docker directory and then each
>> > > contaienr that project has has a directory in the project directory
>> > >
>> > > so the aodh project has a aodh folder
>> > >
>> https://github.com/openstack/kolla/tree/be15d6212f278027c257f9dd67e5b2719e9f730a/docker/aodh
>> > > the convention is to have a <project>-base contaienr which handels the
>> > > depency installation and then one addtional contaienr for each binary
>> deamon
>> > > the project has i.e. aodh-api
>> > >
>> > > the name of the folder in teh project dir is used as the name of the
>> > > contaienr
>> > >
>> > > if we look at the content of the docker files we will see that they
>> are
>> > > not actuly dockerfiles
>> > >
>> > >
>> https://github.com/openstack/kolla/blob/be15d6212f278027c257f9dd67e5b2719e9f730a/docker/aodh/aodh-api/Dockerfile.j2
>> > >
>> > > they are jinja2 templates that produce docker files
>> > >
>> > > kolla as far as i am aware has drop support for binary images and
>> > > alternitiv distos
>> > >
>> > > but looking at an older release we can se ehow this worked
>> > >
>> > >
>> https://github.com/openstack/kolla/blob/stable/wallaby/docker/nova/nova-base/Dockerfile.j2#L13-L52
>> > >
>> > > each docker file template would use the jinja2 to generate a set of
>> > > concreate docker files form the template
>> > > and make dession based on the parmater passed in.
>> > >
>> > > so when you are invokeing
>> > > kolla-build -b ubuntu -t source keystone nova neutron glance
>> > >
>> > > what actully happening is that the -t flag is being set as teh
>> > > install_type parmater in the the jinja2 environemtn when
>> > > the docker file is rendered.
>> > >
>> > > after all the docer files are rendered into normal docker files kolla
>> just
>> > > invokes the build.
>> > >
>> > > in the case of a source build that inovles pre fetching the source tar
>> > > from https://tarballs.opendev.org
>> > > and puting it in the build directory so that it can be included into
>> the
>> > > contianer.
>> > >
>> > > kolla also used to supprot git repo as a alternitve  source fromat
>> > >
>> > > i have glossed over a lot of the details of how this actully work but
>> that
>> > > is the essence of what that command is doing
>> > > creating a build dir, downloading the source, rendering the dockerfile
>> > > templates to docker files, invokeing docker build on those
>> > > and then taging them with the contaienr nameand build tag
>> > >
>> > >
>> > > https://docs.openstack.org/kolla/latest/admin/image-building.html
>> > > covers this form a high level
>> > >
>> > > >   because in command output
>> > > > I've not noticed anything related to the compiling process going on.
>> > > >
>> > > > Here is the output of all images produced by kolla-build command.
>> Do I
>> > > need
>> > > > anything else or is this enough to deploy kolla?
>> > > you can deploy coll with what you have yes although since the kolla
>> files
>> > > are automaticaly
>> > > built by ci kolla-ansible can just use the ones form the docker hub or
>> > > quay instead you do not need to build them yourself
>> > >
>> > > if you do build them your self then there is basically one other stpe
>> that
>> > > you shoudl take if this si a multi node deployment
>> > > you should push the iamges to an interally host docker registry
>> although
>> > > based on the hostname in the prompt below
>> > > it looks like you ahve alredy done that.
>> > > >
>> > > > root at docker-reg:~# docker images
>> > > > REPOSITORY                            TAG       IMAGE ID
>>  CREATED
>> > > >         SIZE
>> > > > kolla/mariadb-server                  15.1.0    2a497eee8269   26
>> minutes
>> > > > ago      595MB
>> > > > kolla/cron                            15.1.0    342877f26a8a   30
>> minutes
>> > > > ago      250MB
>> > > > kolla/memcached                       15.1.0    0d19a4902644   31
>> minutes
>> > > > ago      250MB
>> > > > kolla/mariadb-clustercheck            15.1.0    d84427d3c639   31
>> minutes
>> > > > ago      314MB
>> > > > kolla/mariadb-base                    15.1.0    34447e3e59b6   31
>> minutes
>> > > > ago      314MB
>> > > > kolla/keepalived                      15.1.0    82133b09fbf0   31
>> minutes
>> > > > ago      260MB
>> > > > kolla/prometheus-memcached-exporter   15.1.0    6c2d605f70ee   31
>> minutes
>> > > > ago      262MB
>> > > > <none>                                <none>    e66b228c2a07   31
>> minutes
>> > > > ago      248MB
>> > > > kolla/rabbitmq                        15.1.0    8de5c39379d3   32
>> minutes
>> > > > ago      309MB
>> > > > kolla/fluentd                         15.1.0    adfd19027862   33
>> minutes
>> > > > ago      519MB
>> > > > kolla/haproxy-ssh                     15.1.0    514357ac4d36   36
>> minutes
>> > > > ago      255MB
>> > > > kolla/haproxy                         15.1.0    e5b9cfdf6dfc   37
>> minutes
>> > > > ago      257MB
>> > > > kolla/prometheus-haproxy-exporter     15.1.0    a679f65fd735   37
>> minutes
>> > > > ago      263MB
>> > > > kolla/prometheus-base                 15.1.0    afeff3ed5dce   37
>> minutes
>> > > > ago      248MB
>> > > > kolla/glance-api                      15.1.0    a2241f68f23a   38
>> minutes
>> > > > ago      1.04GB
>> > > > kolla/glance-base                     15.1.0    7286772a03a4
>>  About an
>> > > > hour ago   1.03GB
>> > > > kolla/neutron-infoblox-ipam-agent     15.1.0    f90ffc1a3326
>>  About an
>> > > > hour ago   1.05GB
>> > > > kolla/neutron-server                  15.1.0    69c844a2e3a9
>>  About an
>> > > > hour ago   1.05GB
>> > > > kolla/neutron-l3-agent                15.1.0    4d87e6963c96
>>  About an
>> > > > hour ago   1.05GB
>> > > > <none>                                <none>    486da9a6562e
>>  About an
>> > > > hour ago   1.05GB
>> > > > kolla/neutron-linuxbridge-agent       15.1.0    e5b3ca7e099c
>>  About an
>> > > > hour ago   1.04GB
>> > > > kolla/neutron-bgp-dragent             15.1.0    ac37377820c6
>>  About an
>> > > > hour ago   1.04GB
>> > > > kolla/ironic-neutron-agent            15.1.0    90993adcd74b
>>  About an
>> > > > hour ago   1.04GB
>> > > > kolla/neutron-metadata-agent          15.1.0    8522f147f88d
>>  About an
>> > > > hour ago   1.04GB
>> > > > kolla/neutron-sriov-agent             15.1.0    8a92ce7d13c0
>>  About an
>> > > > hour ago   1.04GB
>> > > > kolla/neutron-dhcp-agent              15.1.0    5c214b0171f5
>>  About an
>> > > > hour ago   1.04GB
>> > > > kolla/neutron-metering-agent          15.1.0    7b3b91ecd77b
>>  About an
>> > > > hour ago   1.04GB
>> > > > kolla/neutron-openvswitch-agent       15.1.0    1f8807308814
>>  About an
>> > > > hour ago   1.04GB
>> > > > kolla/neutron-base                    15.1.0    f85b6a2e2725
>>  About an
>> > > > hour ago   1.04GB
>> > > > kolla/nova-libvirt                    15.1.0    0f3ecefe4752
>>  About an
>> > > > hour ago   987MB
>> > > > kolla/nova-compute                    15.1.0    241b7e7fafbe
>>  About an
>> > > > hour ago   1.47GB
>> > > > kolla/nova-spicehtml5proxy            15.1.0    b740820a7ad1
>>  About an
>> > > > hour ago   1.15GB
>> > > > kolla/nova-novncproxy                 15.1.0    1ba2f443d5c3
>>  About an
>> > > > hour ago   1.22GB
>> > > > kolla/nova-compute-ironic             15.1.0    716612107532
>>  About an
>> > > > hour ago   1.12GB
>> > > > kolla/nova-ssh                        15.1.0    ae2397f4e1c1
>>  About an
>> > > > hour ago   1.11GB
>> > > > kolla/nova-api                        15.1.0    2aef02667ff8
>>  About an
>> > > > hour ago   1.11GB
>> > > > kolla/nova-conductor                  15.1.0    6f1da3400901
>>  About an
>> > > > hour ago   1.11GB
>> > > > kolla/nova-scheduler                  15.1.0    628326776b1d
>>  About an
>> > > > hour ago   1.11GB
>> > > > kolla/nova-serialproxy                15.1.0    28eb7a4a13f8
>>  About an
>> > > > hour ago   1.11GB
>> > > > kolla/nova-base                       15.1.0    e47420013283
>>  About an
>> > > > hour ago   1.11GB
>> > > > kolla/keystone                        15.1.0    e5530d829d5f   2
>> hours
>> > > ago
>> > > >         947MB
>> > > > kolla/keystone-ssh                    15.1.0    eaa7e3f3985a   2
>> hours
>> > > ago
>> > > >         953MB
>> > > > kolla/keystone-fernet                 15.1.0    8a4fa24853a8   2
>> hours
>> > > ago
>> > > >         951MB
>> > > > kolla/keystone-base                   15.1.0    b6f9562364a9   2
>> hours
>> > > ago
>> > > >         945MB
>> > > > kolla/barbican-base                   15.1.0    b2fdef1afb44   2
>> hours
>> > > ago
>> > > >         915MB
>> > > > kolla/barbican-keystone-listener      15.1.0    58bd59de2c63   2
>> hours
>> > > ago
>> > > >         915MB
>> > > > kolla/openstack-base                  15.1.0    c805b4b3b1c1   2
>> hours
>> > > ago
>> > > >         893MB
>> > > > kolla/base                            15.1.0    f68e9ef3dd30   2
>> hours
>> > > ago
>> > > >         248MB
>> > > > registry                              2         8db46f9d7550   19
>> hours
>> > > ago
>> > > >        24.2MB
>> > > > ubuntu                                22.04     08d22c0ceb15   3
>> weeks
>> > > ago
>> > > >         77.8MB
>> > >
>> > >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/87ef7a67/attachment-0001.htm>

From nguyenhuukhoinw at gmail.com  Mon Apr  3 12:55:56 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Mon, 3 Apr 2023 19:55:56 +0700
Subject: [kolla] Image building question
In-Reply-To: <cf125eedb3044002abba94e38b406b7d29383963.camel@redhat.com>
References: <CAPgF-fqFP1YENfG-XsrL2oJQeqzVhUTdJzn2_VwKsZvkvpeApQ@mail.gmail.com>
 <d419fa044dab2f07ff408fc10b7e708185310a48.camel@redhat.com>
 <CAPgF-fqm-OvCzd+My85P8MFe6uobwJ6y_OpFU2K+i7R2u6qdDA@mail.gmail.com>
 <93a78d3cdbc7fb8ca66545a981ca145c6ce21d7a.camel@redhat.com>
 <CAPgF-fpXdhgstwXkqtnrz=BQxKjkRgGRkP_uK-4S-993_OsQuQ@mail.gmail.com>
 <CABAODRcAm6K=JDyVWpqwjrOxVsCPG=ms7Ui79G1opySNiPdJVg@mail.gmail.com>
 <cf125eedb3044002abba94e38b406b7d29383963.camel@redhat.com>
Message-ID: <CABAODRfauxD3HLrKmuq2vk7tvOP+9GRsNUGrrEsG0HhT9j1e3g@mail.gmail.com>

Hello.
I mean if i use kolla-ansible 13.0.0 and kolla 13.0.0 then i upgrade kolla
to 13.8.0. I will use kolla 13.8.0 to build new images?

Nguyen Huu Khoi


On Mon, Apr 3, 2023 at 7:38?PM Sean Mooney <smooney at redhat.com> wrote:

> On Mon, 2023-04-03 at 07:18 +0700, Nguy?n H?u Kh?i wrote:
> > Hello.
> > I have a question.
> > Do we need the kolla-ansible version that matches kolla to deploy
> openstack?
> in general no.
>
> the master branch can often be used to deploy stable/*
> however its better to keep them alinged.
>
> kolla has a pretty stable image api which means that it does not offten
> need
> to modify how images are deployed and as a result some mismatch will not
> break things.
>
> however over time thing do change that are incompatible across releases so
> unless you
> have a strong reason not to keep them alinged it best to use the same
> major release.
> i.e. use a stable/zed version of kolla-ansible to deploy stable/zed images.
>
> using other version of kolla-ansble woudl not be tested in ci so its would
> not be gurarentteed
> to work. you might get lucky but unless you developing kolla-ansible there
> is little reason to use
> missaligned versions.
>
> >
> > Nguyen Huu Khoi
> >
> >
> > On Sat, Apr 1, 2023 at 11:27?PM Satish Patel <satish.txt at gmail.com>
> wrote:
> >
> > > Thank you sean,
> > >
> > > I did following an it works hope this is correct way to customize
> > >
> > > {% extends parent_template %}
> > >
> > > # Horizon
> > > {% block horizon_ubuntu_source_setup %}
> > > RUN apt update -y
> > > RUN apt install -y net-tools vim
> > > RUN touch /root/foo
> > > {% endblock %}
> > >
> > >
> > > $ kolla-build --registry docker-reg:4000 -b ubuntu -t source --tag
> zed-v2
> > > --template-override template-overrides.j2 --debug horizon
> > >
> > >
> > > On Fri, Mar 31, 2023 at 1:31?PM Sean Mooney <smooney at redhat.com>
> wrote:
> > >
> > > > On Fri, 2023-03-31 at 10:25 -0400, Satish Patel wrote:
> > > > > Thank you Sean,
> > > > >
> > > > > What a wonderful explanation of the process. Yes I can download
> images
> > > > from
> > > > > the public domain and push them to a local repository but in some
> cases
> > > > I
> > > > > would like to add my own tools like monitoring agents, utilities
> etc
> > > > > for debugging so i decided to build my own images.
> > > > >
> > > > > I believe https://tarballs.opendev.org is the right place to
> source
> > > > > software correctly?
> > > > that is the offcial location where all opendev/openstack projects are
> > > > released
> > > > and its the location distros use to build there packages.
> > > > >
> > > > > If I want to add some tools or packages inside images then I
> should use
> > > > > Dockerfile.j2 to add and compile images. correct?
> > > >
> > > > yes so one of the great things about kolla images is tiem was taken
> to
> > > > write
> > > > down the image api when the project was first started
> > > > https://docs.openstack.org/kolla/yoga/admin/kolla_api.html
> > > >
> > > > over time the common usecaes were then docuemnted in the admin
> > > > image-building guide
> > > >
> > > >
> https://docs.openstack.org/kolla/yoga/admin/image-building.html#dockerfile-customisation
> > > >
> > > >
> > > > all of the templated imnages have convension/contract that they
> provide
> > > > delement that operator can
> > > > use to add customisations.
> > > >
> > > > for examplel the nova_base_footer block and be used to add addtional
> > > > content to the nova-base image
> > > >
> > > >
> https://github.com/openstack/kolla/blob/master/docker/nova/nova-base/Dockerfile.j2#L82
> > > >
> > > > to customise the iamges you provide what is know as a template
> override
> > > > file
> > > >
> > > > the contrib folder has a number of exmaples
> > > >
> > > >
> > > >
> https://github.com/openstack/kolla/blob/master/contrib/template-override/ovs-dpdk.j2
> > > >
> > > >
> https://github.com/openstack/kolla/blob/master/contrib/neutron-plugins/template_override-networking-mlnx.j2
> > > >
> > > >
> https://github.com/openstack/kolla/blob/master/contrib/neutron-plugins/template_override-vmware-nsx.j2
> > > >
> > > >
> > > > the way they work is you starte it with
> > > >
> > > > {% extends parent_template %}
> > > >
> > > > then you just create a block that mages the name of the one you want
> to
> > > > repalce
> > > > {% extends parent_template %}
> > > >
> > > > {% block nova_base_footer %}
> > > >  RUN /bin/true
> > > > {% endblock %}
> > > >
> > > >
> > > > what ever content you put in the block will be injected directly
> into the
> > > > rendered docer file
> > > >
> > > >
> > > >
> > > >
> https://docs.openstack.org/kolla/yoga/admin/image-building.html#plugin-functionality
> > > >
> > > > show how to use that for neutron
> > > >
> > > > in addtion to replacing block you can set the conten of specal
> variables
> > > > like horizon_packages_append or horizon_packages_remove
> > > >
> > > >
> > > >
> https://docs.openstack.org/kolla/yoga/admin/image-building.html#packages-customisation
> > > >
> > > > that allow you add an remove packages in a simple way
> > > > there is also a set of macros that you can use
> > > >
> > > > you include them with
> > > > {% import "macros.j2" as macros with context %}
> > > >
> > > > they are defiend here
> > > > https://github.com/openstack/kolla/blob/master/docker/macros.j2
> > > >
> > > > if you know that the docs exist the capablitys are coverd pretty
> well in
> > > > the kolla docs you just need to know where to look
> > > > hopefully that helps.
> > > >
> > > > the ovs-dpdk template overide docs can be fouund here
> > > >
> https://docs.openstack.org/kolla/yoga/admin/template-override/ovs-dpdk.html
> > > >
> > > > its a liltle differnt then the other since there i used the template
> > > > override mechanium to allow compiling ovs with dpdk form souces
> > > >
> > > > kolla normlly does not support that but it serves as a demonstration
> for
> > > > how operator can do that if they really need too.
> > > > i.e. compile a replacment for a minary componet like mariadb. it
> salso
> > > > show how to use git as the souce localtion instead
> > > > of tars if that is your prefernce.
> > > >
> > > > >
> > > > > ~S
> > > > >
> > > > > On Fri, Mar 31, 2023 at 7:01?AM Sean Mooney <smooney at redhat.com>
> wrote:
> > > > >
> > > > > > On Thu, 2023-03-30 at 16:49 -0400, Satish Patel wrote:
> > > > > > > Folks,
> > > > > > >
> > > > > > > I am playing with kolla image building to understand how it
> works.
> > > > I am
> > > > > > > using the following command to build images and wanted to check
> > > > with you
> > > > > > > folks if that is the correct way to do it.
> > > > > > >
> > > > > > > $ kolla-build -b ubuntu -t source keystone nova neutron glance
> > > > > > >
> > > > > > > Does the above command compile code from source or just
> download
> > > > images
> > > > > > > from remote repositories and re-compile them?
> > > > > > >
> > > > > > openstack is mainly python so in general ther is no complie step.
> > > > > > but to answer your question that builds the image using the
> source
> > > > tarballs
> > > > > > or the openstakc packages.
> > > > > >
> > > > > > the defaults soruce locations are rendered into a file which you
> can
> > > > > > override
> > > > > > from the data stored in
> > > > > >
> > > >
> https://github.com/openstack/kolla/blob/master/kolla/common/sources.py
> > > > > > the other build config defaults are generated form this code
> > > > > >
> https://github.com/openstack/kolla/blob/master/kolla/common/config.py
> > > > > >
> > > > > > when you invoke kolla-build its executing
> > > > > >
> https://github.com/openstack/kolla/blob/master/kolla/cmd/build.py
> > > > > > but the main build workflow is here
> > > > > >
> > > >
> https://github.com/openstack/kolla/blob/be15d6212f278027c257f9dd67e5b2719e9f730a/kolla/image/build.py#L95
> > > > > >
> > > > > > the tl;dr is the build worklow starts by creating  build
> director and
> > > > > > locating the docker file templats.
> > > > > > in otherwords the content of the
> > > > > >
> > > >
> https://github.com/openstack/kolla/tree/be15d6212f278027c257f9dd67e5b2719e9f730a/docker
> > > > > > directory
> > > > > >
> > > > > > each project has a direcoty in the docker directory and then each
> > > > > > contaienr that project has has a directory in the project
> directory
> > > > > >
> > > > > > so the aodh project has a aodh folder
> > > > > >
> > > >
> https://github.com/openstack/kolla/tree/be15d6212f278027c257f9dd67e5b2719e9f730a/docker/aodh
> > > > > > the convention is to have a <project>-base contaienr which
> handels the
> > > > > > depency installation and then one addtional contaienr for each
> binary
> > > > deamon
> > > > > > the project has i.e. aodh-api
> > > > > >
> > > > > > the name of the folder in teh project dir is used as the name of
> the
> > > > > > contaienr
> > > > > >
> > > > > > if we look at the content of the docker files we will see that
> they
> > > > are
> > > > > > not actuly dockerfiles
> > > > > >
> > > > > >
> > > >
> https://github.com/openstack/kolla/blob/be15d6212f278027c257f9dd67e5b2719e9f730a/docker/aodh/aodh-api/Dockerfile.j2
> > > > > >
> > > > > > they are jinja2 templates that produce docker files
> > > > > >
> > > > > > kolla as far as i am aware has drop support for binary images and
> > > > > > alternitiv distos
> > > > > >
> > > > > > but looking at an older release we can se ehow this worked
> > > > > >
> > > > > >
> > > >
> https://github.com/openstack/kolla/blob/stable/wallaby/docker/nova/nova-base/Dockerfile.j2#L13-L52
> > > > > >
> > > > > > each docker file template would use the jinja2 to generate a set
> of
> > > > > > concreate docker files form the template
> > > > > > and make dession based on the parmater passed in.
> > > > > >
> > > > > > so when you are invokeing
> > > > > > kolla-build -b ubuntu -t source keystone nova neutron glance
> > > > > >
> > > > > > what actully happening is that the -t flag is being set as teh
> > > > > > install_type parmater in the the jinja2 environemtn when
> > > > > > the docker file is rendered.
> > > > > >
> > > > > > after all the docer files are rendered into normal docker files
> kolla
> > > > just
> > > > > > invokes the build.
> > > > > >
> > > > > > in the case of a source build that inovles pre fetching the
> source tar
> > > > > > from https://tarballs.opendev.org
> > > > > > and puting it in the build directory so that it can be included
> into
> > > > the
> > > > > > contianer.
> > > > > >
> > > > > > kolla also used to supprot git repo as a alternitve  source
> fromat
> > > > > >
> > > > > > i have glossed over a lot of the details of how this actully
> work but
> > > > that
> > > > > > is the essence of what that command is doing
> > > > > > creating a build dir, downloading the source, rendering the
> dockerfile
> > > > > > templates to docker files, invokeing docker build on those
> > > > > > and then taging them with the contaienr nameand build tag
> > > > > >
> > > > > >
> > > > > >
> https://docs.openstack.org/kolla/latest/admin/image-building.html
> > > > > > covers this form a high level
> > > > > >
> > > > > > >   because in command output
> > > > > > > I've not noticed anything related to the compiling process
> going on.
> > > > > > >
> > > > > > > Here is the output of all images produced by kolla-build
> command.
> > > > Do I
> > > > > > need
> > > > > > > anything else or is this enough to deploy kolla?
> > > > > > you can deploy coll with what you have yes although since the
> kolla
> > > > files
> > > > > > are automaticaly
> > > > > > built by ci kolla-ansible can just use the ones form the docker
> hub or
> > > > > > quay instead you do not need to build them yourself
> > > > > >
> > > > > > if you do build them your self then there is basically one other
> stpe
> > > > that
> > > > > > you shoudl take if this si a multi node deployment
> > > > > > you should push the iamges to an interally host docker registry
> > > > although
> > > > > > based on the hostname in the prompt below
> > > > > > it looks like you ahve alredy done that.
> > > > > > >
> > > > > > > root at docker-reg:~# docker images
> > > > > > > REPOSITORY                            TAG       IMAGE ID
> > > >  CREATED
> > > > > > >         SIZE
> > > > > > > kolla/mariadb-server                  15.1.0    2a497eee8269
>  26
> > > > minutes
> > > > > > > ago      595MB
> > > > > > > kolla/cron                            15.1.0    342877f26a8a
>  30
> > > > minutes
> > > > > > > ago      250MB
> > > > > > > kolla/memcached                       15.1.0    0d19a4902644
>  31
> > > > minutes
> > > > > > > ago      250MB
> > > > > > > kolla/mariadb-clustercheck            15.1.0    d84427d3c639
>  31
> > > > minutes
> > > > > > > ago      314MB
> > > > > > > kolla/mariadb-base                    15.1.0    34447e3e59b6
>  31
> > > > minutes
> > > > > > > ago      314MB
> > > > > > > kolla/keepalived                      15.1.0    82133b09fbf0
>  31
> > > > minutes
> > > > > > > ago      260MB
> > > > > > > kolla/prometheus-memcached-exporter   15.1.0    6c2d605f70ee
>  31
> > > > minutes
> > > > > > > ago      262MB
> > > > > > > <none>                                <none>    e66b228c2a07
>  31
> > > > minutes
> > > > > > > ago      248MB
> > > > > > > kolla/rabbitmq                        15.1.0    8de5c39379d3
>  32
> > > > minutes
> > > > > > > ago      309MB
> > > > > > > kolla/fluentd                         15.1.0    adfd19027862
>  33
> > > > minutes
> > > > > > > ago      519MB
> > > > > > > kolla/haproxy-ssh                     15.1.0    514357ac4d36
>  36
> > > > minutes
> > > > > > > ago      255MB
> > > > > > > kolla/haproxy                         15.1.0    e5b9cfdf6dfc
>  37
> > > > minutes
> > > > > > > ago      257MB
> > > > > > > kolla/prometheus-haproxy-exporter     15.1.0    a679f65fd735
>  37
> > > > minutes
> > > > > > > ago      263MB
> > > > > > > kolla/prometheus-base                 15.1.0    afeff3ed5dce
>  37
> > > > minutes
> > > > > > > ago      248MB
> > > > > > > kolla/glance-api                      15.1.0    a2241f68f23a
>  38
> > > > minutes
> > > > > > > ago      1.04GB
> > > > > > > kolla/glance-base                     15.1.0    7286772a03a4
> > > >  About an
> > > > > > > hour ago   1.03GB
> > > > > > > kolla/neutron-infoblox-ipam-agent     15.1.0    f90ffc1a3326
> > > >  About an
> > > > > > > hour ago   1.05GB
> > > > > > > kolla/neutron-server                  15.1.0    69c844a2e3a9
> > > >  About an
> > > > > > > hour ago   1.05GB
> > > > > > > kolla/neutron-l3-agent                15.1.0    4d87e6963c96
> > > >  About an
> > > > > > > hour ago   1.05GB
> > > > > > > <none>                                <none>    486da9a6562e
> > > >  About an
> > > > > > > hour ago   1.05GB
> > > > > > > kolla/neutron-linuxbridge-agent       15.1.0    e5b3ca7e099c
> > > >  About an
> > > > > > > hour ago   1.04GB
> > > > > > > kolla/neutron-bgp-dragent             15.1.0    ac37377820c6
> > > >  About an
> > > > > > > hour ago   1.04GB
> > > > > > > kolla/ironic-neutron-agent            15.1.0    90993adcd74b
> > > >  About an
> > > > > > > hour ago   1.04GB
> > > > > > > kolla/neutron-metadata-agent          15.1.0    8522f147f88d
> > > >  About an
> > > > > > > hour ago   1.04GB
> > > > > > > kolla/neutron-sriov-agent             15.1.0    8a92ce7d13c0
> > > >  About an
> > > > > > > hour ago   1.04GB
> > > > > > > kolla/neutron-dhcp-agent              15.1.0    5c214b0171f5
> > > >  About an
> > > > > > > hour ago   1.04GB
> > > > > > > kolla/neutron-metering-agent          15.1.0    7b3b91ecd77b
> > > >  About an
> > > > > > > hour ago   1.04GB
> > > > > > > kolla/neutron-openvswitch-agent       15.1.0    1f8807308814
> > > >  About an
> > > > > > > hour ago   1.04GB
> > > > > > > kolla/neutron-base                    15.1.0    f85b6a2e2725
> > > >  About an
> > > > > > > hour ago   1.04GB
> > > > > > > kolla/nova-libvirt                    15.1.0    0f3ecefe4752
> > > >  About an
> > > > > > > hour ago   987MB
> > > > > > > kolla/nova-compute                    15.1.0    241b7e7fafbe
> > > >  About an
> > > > > > > hour ago   1.47GB
> > > > > > > kolla/nova-spicehtml5proxy            15.1.0    b740820a7ad1
> > > >  About an
> > > > > > > hour ago   1.15GB
> > > > > > > kolla/nova-novncproxy                 15.1.0    1ba2f443d5c3
> > > >  About an
> > > > > > > hour ago   1.22GB
> > > > > > > kolla/nova-compute-ironic             15.1.0    716612107532
> > > >  About an
> > > > > > > hour ago   1.12GB
> > > > > > > kolla/nova-ssh                        15.1.0    ae2397f4e1c1
> > > >  About an
> > > > > > > hour ago   1.11GB
> > > > > > > kolla/nova-api                        15.1.0    2aef02667ff8
> > > >  About an
> > > > > > > hour ago   1.11GB
> > > > > > > kolla/nova-conductor                  15.1.0    6f1da3400901
> > > >  About an
> > > > > > > hour ago   1.11GB
> > > > > > > kolla/nova-scheduler                  15.1.0    628326776b1d
> > > >  About an
> > > > > > > hour ago   1.11GB
> > > > > > > kolla/nova-serialproxy                15.1.0    28eb7a4a13f8
> > > >  About an
> > > > > > > hour ago   1.11GB
> > > > > > > kolla/nova-base                       15.1.0    e47420013283
> > > >  About an
> > > > > > > hour ago   1.11GB
> > > > > > > kolla/keystone                        15.1.0    e5530d829d5f
>  2
> > > > hours
> > > > > > ago
> > > > > > >         947MB
> > > > > > > kolla/keystone-ssh                    15.1.0    eaa7e3f3985a
>  2
> > > > hours
> > > > > > ago
> > > > > > >         953MB
> > > > > > > kolla/keystone-fernet                 15.1.0    8a4fa24853a8
>  2
> > > > hours
> > > > > > ago
> > > > > > >         951MB
> > > > > > > kolla/keystone-base                   15.1.0    b6f9562364a9
>  2
> > > > hours
> > > > > > ago
> > > > > > >         945MB
> > > > > > > kolla/barbican-base                   15.1.0    b2fdef1afb44
>  2
> > > > hours
> > > > > > ago
> > > > > > >         915MB
> > > > > > > kolla/barbican-keystone-listener      15.1.0    58bd59de2c63
>  2
> > > > hours
> > > > > > ago
> > > > > > >         915MB
> > > > > > > kolla/openstack-base                  15.1.0    c805b4b3b1c1
>  2
> > > > hours
> > > > > > ago
> > > > > > >         893MB
> > > > > > > kolla/base                            15.1.0    f68e9ef3dd30
>  2
> > > > hours
> > > > > > ago
> > > > > > >         248MB
> > > > > > > registry                              2         8db46f9d7550
>  19
> > > > hours
> > > > > > ago
> > > > > > >        24.2MB
> > > > > > > ubuntu                                22.04     08d22c0ceb15
>  3
> > > > weeks
> > > > > > ago
> > > > > > >         77.8MB
> > > > > >
> > > > > >
> > > >
> > > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/1ba8ffd2/attachment-0001.htm>

From rguyett at datto.com  Mon Apr  3 13:12:32 2023
From: rguyett at datto.com (Reid Guyett)
Date: Mon, 3 Apr 2023 13:12:32 +0000
Subject: [SWIFT] ssync receiver crash
Message-ID: <DS7P221MB086677ADB01A2DDDE0624723A3929@DS7P221MB0866.NAMP221.PROD.OUTLOOK.COM>

Hello,

We recently upgraded our swift servers to 20.04 from 18.04. After the upgrades were completed we are seeing 1 server where the ssync receiver keeps crashing. The crash is preventing hand offs from being cleanup up in the cluster (50 servers). Looking for some advice to fix/workaround the issue. We have 20 clusters but are only seeing this issue in 1 cluster. It is strange to me that we only see this ssync receiver error in one server out of the ~1000 we are running.

OS: Ubuntu 20.04.5
Swift version: 2.25.2

On the receiver side we are seeing the following trace:

object-server: senderIp/d1/2166 EXCEPTION in ssync.Receiver:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/eventlet/wsgi.py", line 209, in _chunked_read
    self.chunk_length = int(rfile.readline().split(b";",1)[0], 16)
ValueError: invalid literal for int() with base 16: b''

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/swift/obj/ssync_receiver.py", line 166, in __call__
    for data in self.missing_check():
  File "/usr/lib/python3/dist-packages/swift/obj/ssync_receiver.py", line 340, in missing_check
    line = self.fp.readline(self.app.network_chunk_size)
  File "/usr/lib/python3/dist-packages/eventlet/wsgi.py", line 226, in readline
    return self._chunked_read(self.rfile, size, True)
  File "/usr/lib/python3/dist-packages/eventlet/wsgi.py", line 211, in _chunked_read
    raise ChunkReadError(err)
eventlet.wsgi.ChunkReadError: invalid literal for int() with base 16: b''


On the sender side we are seeing this message when I try to run the reconstructor manually with debug logging:
root at use1-saas-p6-paco-9:~# swift-object-reconstructor object-server.conf -p 27999 -v -o
object-reconstructor: Starting 271723
object-reconstructor: Spawned worker 271755 with {'override_partitions': [27999], 'override_devices': ['d10', 'd17', 'd19', 'd9', 'd29', 'd15', 'd2', 'd24', '
d32', 'd1', 'd8', 'd14', 'd11', 'd28', 'd27', 'd6', 'd7', 'd16', 'd13', 'd25', 'd26', 'd20', 'd18', 'd12', 'd4', 'd0', 'd22', 'd3', 'd5', 'd21', 'd33', 'd23',
 'd30', 'd34', 'd31'], 'multiprocess_worker_index': 0}
object-reconstructor: [worker 1/1 pid=271755] Running object reconstructor in script mode.
object-reconstructor: [worker 1/1 pid=271755] Run listdir on /srv/node/d22/objects-4/27999
object-reconstructor: [worker 1/1 pid=271755] recieverIP:6200/d31/27999 10.0 seconds: connect receive
object-reconstructor: [worker 1/1 pid=271755] 1/26820 (0.00%) partitions reconstructed in 10.14s (0.10/sec, 75h remaining)
object-reconstructor: [worker 1/1 pid=271755] Object reconstruction complete (once). (0.17 minutes)
object-reconstructor: Forked worker 271755 finished
object-reconstructor: Worker 271755 exited
object-reconstructor: Finished 271723
object-reconstructor: Exited 271723

Thanks!

Reid Guyett
Staff Storage Engineer
Datto, A Kaseya Company
www.datto.com<http://www.datto.com/>

Important Notice: This email is intended to be received only by persons entitled to receive the confidential and legally privileged information it presumptively contains, and this notice constitutes identification as such. Any reading, disclosure, copying, distribution or use of this information by or to someone who is not the intended recipient, is prohibited. If you received this email in error, please notify us immediately at legal at kaseya.com, and then delete it. To opt-out of receiving emails Please click here<https://info.kaseya.com/email-subscription-center.html>. The term 'this e-mail' includes any and all attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/ecdea8e6/attachment.htm>

From richard.buregeya at bsc.rw  Mon Apr  3 16:39:55 2023
From: richard.buregeya at bsc.rw (Richard Buregeya)
Date: Mon, 3 Apr 2023 16:39:55 +0000
Subject: No subject
In-Reply-To: <AM9PR03MB6705C59D076400A51B614C6AF0929@AM9PR03MB6705.eurprd03.prod.outlook.com>
References: <DBBPR03MB671641ECA823C20815CDC232F0929@DBBPR03MB6716.eurprd03.prod.outlook.com>
 <3128971B-5A02-44E2-9F6E-6E01B82BFB31@openinfra.dev>
 <AM9PR03MB6705C59D076400A51B614C6AF0929@AM9PR03MB6705.eurprd03.prod.outlook.com>
Message-ID: <AM9PR03MB6705652785085FF563AB3B11F0929@AM9PR03MB6705.eurprd03.prod.outlook.com>

Thanks @Jimmy McArthur<mailto:jimmy at openinfra.dev>

From: Richard Buregeya <richard.buregeya at bsc.rw>
Sent: Monday, April 3, 2023 6:27 PM
To: Jimmy McArthur <jimmy at openinfra.dev>
Cc: openstack-discuss at lists.openstack.org
Subject: RE:

Thanks @Jimmy McArthur<mailto:jimmy at openinfra.dev> appreciated.

From: Jimmy McArthur <jimmy at openinfra.dev<mailto:jimmy at openinfra.dev>>
Sent: Monday, April 3, 2023 6:15 PM
To: Richard Buregeya <richard.buregeya at bsc.rw<mailto:richard.buregeya at bsc.rw>>
Cc: openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>
Subject: Re:

Hi Richard,

The COA is still a practical exam. You can find more details here: https://openstack.org/coa

Cheers,
Jimmy



On Apr 3, 2023, at 10:18 AM, Richard Buregeya <richard.buregeya at bsc.rw<mailto:richard.buregeya at bsc.rw>> wrote:

Hello Team,

Hope you are doing well.

Any one with an idea if there is a modification in COA exam, I heard it is now a multiple question exams instead of practical exam,

Anyone with current information, kindly update me.


Thanks a lot!

Regards

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/54316a7a/attachment-0001.htm>

From manchandavishal143 at gmail.com  Mon Apr  3 17:02:43 2023
From: manchandavishal143 at gmail.com (vishal manchanda)
Date: Mon, 3 Apr 2023 22:32:43 +0530
Subject: [horizon]display quota volume type on horizon
In-Reply-To: <CABAODRf2FWL-fc+bWCdzWLCygy1NF29EWFyEZs7Mpn6X1HNBKQ@mail.gmail.com>
References: <CABAODRf2FWL-fc+bWCdzWLCygy1NF29EWFyEZs7Mpn6X1HNBKQ@mail.gmail.com>
Message-ID: <CADrq38vSthyNmVLUXLvZ=hMw_KZ8HK-49Qc_MdJ9DHZnqLfRCQ@mail.gmail.com>

Hi Nguy?n,

I can see a bp[1] and a patch[2] as well up for this feature.
I think the author of the patch no longer works with the horizon.
Let me update and fix the CI and update the unit test to make it ready for
review.
Let's see if we can add this feature to the horizon in the bobcat cycle.

Thanks & regards,
Vishal Manchanda

[1]
https://blueprints.launchpad.net/horizon/+spec/quotas-per-cinder-volume-type
[2] https://review.opendev.org/c/openstack/horizon/+/511472

On Mon, Apr 3, 2023 at 7:05?PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Hello.
> I see that blueprint is very real case but it has not deployed yet.
>
>
> https://blueprints.launchpad.net/horizon/+spec/quotas-per-cinder-volume-type
>
> I am curious why it is abanddoned .
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/6a20f5c3/attachment.htm>

From lbezdick at redhat.com  Mon Apr  3 16:40:01 2023
From: lbezdick at redhat.com (Lukas Bezdicka)
Date: Mon, 3 Apr 2023 18:40:01 +0200
Subject: [tripleo] Nominate dbengt for tripleo-core !
Message-ID: <CAEggtay7MKKCUuDzvhhUitv=EgBRZMPjcdQ7cEDpjp0y04+SEg@mail.gmail.com>

Hello,

I'd like to nominate Daniel Bengtsson as tripleo-core. He works in upgrades
and he'll have to maintain train, wallaby and zed for quite a while. He is
a long term contributor to tripleo and oslo.

I trust his judgement and I hope you'll support his nomination!

Thanks,
Lukas Bezdicka
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/1357cb62/attachment.htm>

From gmann at ghanshyammann.com  Mon Apr  3 17:14:04 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 03 Apr 2023 10:14:04 -0700
Subject: [ptls] PyPI maintainer cleanup - Action needed: Contact extra
 maintainers
In-Reply-To: <CA+sTGNc3W=A5=bkob_9J1Uvc2jtBrvwgxtGpR3Tr+KburYURYA@mail.gmail.com>
References: <CA+sTGNfCy+w9uLqpz3KFEGo14h7Qxy_6gRx7htceSDKLABgpzQ@mail.gmail.com>
 <CA+sTGNe-7TCy4qea+5WArWBzjtXyDE6LZ5665DvGOWX4HxmAzQ@mail.gmail.com>
 <CA+sTGNd6vk47SwCMgcRz_qA5ChjJL+x7+qD8j692gHV1Q3am8Q@mail.gmail.com>
 <CAARK8KQo1KXiMVawrVT2t_a37zEakoAN-2m9L0DmcHNsnAckRg@mail.gmail.com>
 <CA+sTGNc3W=A5=bkob_9J1Uvc2jtBrvwgxtGpR3Tr+KburYURYA@mail.gmail.com>
Message-ID: <187481c90d2.11980753e126814.6520585411434567985@ghanshyammann.com>

Thanks Rajat,

Yes, we have many such cases, please add those repo/additional maintainers in etherpad and TC will take the next action.
Also, do not forget to update the status of the already cleaned-up repo.

-gmann

 ---- On Mon, 03 Apr 2023 08:14:49 -0700  Jay Faulkner  wrote --- 
 > Hey Rajat,
 > Thanks for talking to your contributors, and trying to find contacts for older contributors. I do think we'll have a few projects in this state, and the TC will likely take action to advance those. We wanted to clean up as much as possible through cooperative action first.
 > Thanks,Jay FaulknerTC Vice-Chair
 > 
 > On Mon, Apr 3, 2023 at 7:44?AM Rajat Dhasmana rdhasman at redhat.com> wrote:
 > Hi Jay,
 > We have some maintainers that are not active?in the Cinder project for quite?some time.I'm sure they will agree to the idea we have but it's not easy to reach them for the changesto be made (Tried to reach out but received no response).I wanted to know if this problem is being faced by other projects also? and Do we have a solution for such scenarios?
 > ThanksRajat Dhasmana
 > On Wed, Mar 22, 2023 at 9:55?PM Jay Faulkner jay at gr-oss.io> wrote:
 > Hey all,
 > Wanted to remind you all: vPTG is a great time to address this issue! Even if the PyPI maintainers you would need to contact are emeritus contributors; you may have someone still on the project team who has contact with them. I strongly recommend you utilize this time to help clean your projects up.
 > Thanks,Jay FaulknerTC Vice-Chair
 > 
 > On Tue, Mar 21, 2023 at 9:03?AM Jay Faulkner jay at gr-oss.io> wrote:
 > Thanks to those who have already taken action! Fifty extra maintainers have already been removed, with around three hundred to go. 
 > 
 > Please reach out to me if you're having trouble finding current email addresses for anyone, or having trouble with the process at all.
 > Thanks,Jay FaulknerTC Vice-Chair
 > 
 > 
 > On Thu, Mar 16, 2023 at 3:22?PM Jay Faulkner jay at gr-oss.io> wrote:
 > Hi PTLs,
 > The TC recently voted[1] to require humans be removed from PyPI access for OpenStack-managed projects. This helps ensure all releases are created via releases team tooling and makes it less likely for a user account compromise to impact OpenStack packages.
 > Many projects have already updated https://etherpad.opendev.org/p/openstack-ppi-maintainers-cleanup#L33 with a list of packages that contain extra maintainers. We'd like to request that PTLs, or their designate, reach out to any extra maintainers listed for projects you are responsible for and request they remove their access in accordance with policy. An example email, and detailed steps to follow havebeen provided at https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup-email-template.
 > Thank you for your cooperation as we work to improve our security posture and harden against supply chain attacks.
 > Thank you,Jay FaulknerTC Vice-Chair
 > 1: https://opendev.org/openstack/governance/commit/979e339f899ef62d2a6871a99c99537744c5808d
 > 
 > 


From rdhasman at redhat.com  Mon Apr  3 17:25:59 2023
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Mon, 3 Apr 2023 22:55:59 +0530
Subject: [ptls] PyPI maintainer cleanup - Action needed: Contact extra
 maintainers
In-Reply-To: <187481c90d2.11980753e126814.6520585411434567985@ghanshyammann.com>
References: <CA+sTGNfCy+w9uLqpz3KFEGo14h7Qxy_6gRx7htceSDKLABgpzQ@mail.gmail.com>
 <CA+sTGNe-7TCy4qea+5WArWBzjtXyDE6LZ5665DvGOWX4HxmAzQ@mail.gmail.com>
 <CA+sTGNd6vk47SwCMgcRz_qA5ChjJL+x7+qD8j692gHV1Q3am8Q@mail.gmail.com>
 <CAARK8KQo1KXiMVawrVT2t_a37zEakoAN-2m9L0DmcHNsnAckRg@mail.gmail.com>
 <CA+sTGNc3W=A5=bkob_9J1Uvc2jtBrvwgxtGpR3Tr+KburYURYA@mail.gmail.com>
 <187481c90d2.11980753e126814.6520585411434567985@ghanshyammann.com>
Message-ID: <CAARK8KSfBWFEcYNMs4hB6e_+QwxvefbXg4f4tBUWE4DX++xtDA@mail.gmail.com>

Hi,

Thank you for your replies. The status of cinder repos is updated on the
etherpad L#71 [1].
Out of 7 repos, 2 have maintainers that aren't much active recently and
other repos either
don't require changes or the needed changes are done.

1) os-brick: Mike Perez (thingee)
2) python-brick-cinderclient-ext: Ivan Kolodyazhny (e0ne)

[1] https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup#L71

Thanks
Rajat Dhasmana

On Mon, Apr 3, 2023 at 10:44?PM Ghanshyam Mann <gmann at ghanshyammann.com>
wrote:

> Thanks Rajat,
>
> Yes, we have many such cases, please add those repo/additional maintainers
> in etherpad and TC will take the next action.
> Also, do not forget to update the status of the already cleaned-up repo.
>
> -gmann
>
>  ---- On Mon, 03 Apr 2023 08:14:49 -0700  Jay Faulkner  wrote ---
>  > Hey Rajat,
>  > Thanks for talking to your contributors, and trying to find contacts
> for older contributors. I do think we'll have a few projects in this state,
> and the TC will likely take action to advance those. We wanted to clean up
> as much as possible through cooperative action first.
>  > Thanks,Jay FaulknerTC Vice-Chair
>  >
>  > On Mon, Apr 3, 2023 at 7:44?AM Rajat Dhasmana rdhasman at redhat.com>
> wrote:
>  > Hi Jay,
>  > We have some maintainers that are not active in the Cinder project for
> quite some time.I'm sure they will agree to the idea we have but it's not
> easy to reach them for the changesto be made (Tried to reach out but
> received no response).I wanted to know if this problem is being faced by
> other projects also? and Do we have a solution for such scenarios?
>  > ThanksRajat Dhasmana
>  > On Wed, Mar 22, 2023 at 9:55?PM Jay Faulkner jay at gr-oss.io> wrote:
>  > Hey all,
>  > Wanted to remind you all: vPTG is a great time to address this issue!
> Even if the PyPI maintainers you would need to contact are emeritus
> contributors; you may have someone still on the project team who has
> contact with them. I strongly recommend you utilize this time to help clean
> your projects up.
>  > Thanks,Jay FaulknerTC Vice-Chair
>  >
>  > On Tue, Mar 21, 2023 at 9:03?AM Jay Faulkner jay at gr-oss.io> wrote:
>  > Thanks to those who have already taken action! Fifty extra maintainers
> have already been removed, with around three hundred to go.
>  >
>  > Please reach out to me if you're having trouble finding current email
> addresses for anyone, or having trouble with the process at all.
>  > Thanks,Jay FaulknerTC Vice-Chair
>  >
>  >
>  > On Thu, Mar 16, 2023 at 3:22?PM Jay Faulkner jay at gr-oss.io> wrote:
>  > Hi PTLs,
>  > The TC recently voted[1] to require humans be removed from PyPI access
> for OpenStack-managed projects. This helps ensure all releases are created
> via releases team tooling and makes it less likely for a user account
> compromise to impact OpenStack packages.
>  > Many projects have already updated
> https://etherpad.opendev.org/p/openstack-ppi-maintainers-cleanup#L33 with
> a list of packages that contain extra maintainers. We'd like to request
> that PTLs, or their designate, reach out to any extra maintainers listed
> for projects you are responsible for and request they remove their access
> in accordance with policy. An example email, and detailed steps to follow
> havebeen provided at
> https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup-email-template
> .
>  > Thank you for your cooperation as we work to improve our security
> posture and harden against supply chain attacks.
>  > Thank you,Jay FaulknerTC Vice-Chair
>  > 1:
> https://opendev.org/openstack/governance/commit/979e339f899ef62d2a6871a99c99537744c5808d
>  >
>  >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/220149de/attachment-0001.htm>

From johfulto at redhat.com  Mon Apr  3 17:50:28 2023
From: johfulto at redhat.com (John Fulton)
Date: Mon, 3 Apr 2023 13:50:28 -0400
Subject: [tripleo] Nominate dbengt for tripleo-core !
In-Reply-To: <CAEggtay7MKKCUuDzvhhUitv=EgBRZMPjcdQ7cEDpjp0y04+SEg@mail.gmail.com>
References: <CAEggtay7MKKCUuDzvhhUitv=EgBRZMPjcdQ7cEDpjp0y04+SEg@mail.gmail.com>
Message-ID: <CAE66OMDnvgB9iN5sdNMbCe_+SscaapW1f2VvZG2rG-9M9S-=6g@mail.gmail.com>

+1

On Mon, Apr 3, 2023 at 1:14?PM Lukas Bezdicka <lbezdick at redhat.com> wrote:
>
> Hello,
>
> I'd like to nominate Daniel Bengtsson as tripleo-core. He works in upgrades and he'll have to maintain train, wallaby and zed for quite a while. He is a long term contributor to tripleo and oslo.
>
> I trust his judgement and I hope you'll support his nomination!
>
> Thanks,
> Lukas Bezdicka



From christian.rohmann at inovex.de  Mon Apr  3 17:56:29 2023
From: christian.rohmann at inovex.de (Christian Rohmann)
Date: Mon, 3 Apr 2023 19:56:29 +0200
Subject: [designate] Proposal to deprecate the agent framework and agent
 based backends
In-Reply-To: <CAMH0MgK_dPF4YfzGbkoykpupNXoF0mMrzWWTW8F49pC0K4Z6=w@mail.gmail.com>
References: <CAMH0MgJFtt_FJG3rWk7qyT=y_5ZUVrm1ZyTKOQ90T2R6hmBA5w@mail.gmail.com>
 <c8d3c12f-9807-11e1-582a-01c30e4a3f41@inovex.de>
 <CAMH0MgJAyyUyUgMM20+GLew_Tc-jXAEo9hDCfgtEqcQD2OVmQw@mail.gmail.com>
 <a43f7293-29c5-0c15-679c-7f794e976ae3@inovex.de>
 <CAMH0MgK_dPF4YfzGbkoykpupNXoF0mMrzWWTW8F49pC0K4Z6=w@mail.gmail.com>
Message-ID: <16546577-07af-c24a-5ff6-c45eeeba9517@inovex.de>

Hey Michael,


On 03/04/2023 16:51, Michael Johnson wrote:
> We just had the virtual PTG last week and discussed this topic[1].
> [1]https://etherpad.opendev.org/p/march2023-ptg-designate

Sorry I missed that opportunity to ask / discuss there.

> As you know, we completed the specification document and merged it
> during Antelope. So the community agrees on the plan to implement. At
> this point it just needs developers to start work on the patches.
>
> During the PTG session no one attending was able to pick up this
> specification for development, so we did not highlight it as a feature
> targeted for Bobcat. I did say that I am willing to help anyone that
> has developer resources work on it, I just cannot lead that effort
> during Bobcat.
>
> So if you are willing to work on the patches, we will help out as we
> can with reviews and answering questions, etc.

I started a discussion internally about devoting some hours to at least 
get this off the ground.
Does this spec need a "move" to Bobcat or other planning or acceptance 
process to aim for that release instead of Antelope?

And I am in no way asking for a fast-lane or special treatment. I would 
just like to be able advertise this as:
"If we write the code, someone is going to look at it and helps to get 
this merged for Bobcat."


Thanks for the fruitful discussions and again for picking up on this 
whole idea.


Christian




From johnsomor at gmail.com  Mon Apr  3 18:51:50 2023
From: johnsomor at gmail.com (Michael Johnson)
Date: Mon, 3 Apr 2023 11:51:50 -0700
Subject: [designate] Proposal to deprecate the agent framework and agent
 based backends
In-Reply-To: <16546577-07af-c24a-5ff6-c45eeeba9517@inovex.de>
References: <CAMH0MgJFtt_FJG3rWk7qyT=y_5ZUVrm1ZyTKOQ90T2R6hmBA5w@mail.gmail.com>
 <c8d3c12f-9807-11e1-582a-01c30e4a3f41@inovex.de>
 <CAMH0MgJAyyUyUgMM20+GLew_Tc-jXAEo9hDCfgtEqcQD2OVmQw@mail.gmail.com>
 <a43f7293-29c5-0c15-679c-7f794e976ae3@inovex.de>
 <CAMH0MgK_dPF4YfzGbkoykpupNXoF0mMrzWWTW8F49pC0K4Z6=w@mail.gmail.com>
 <16546577-07af-c24a-5ff6-c45eeeba9517@inovex.de>
Message-ID: <CAMH0Mg+EX3vEKKX_BJCja4ePweWAkjTsc5rEvVoRSpERD7Pd5Q@mail.gmail.com>

Comments below,

Michael

On Mon, Apr 3, 2023 at 10:56?AM Christian Rohmann
<christian.rohmann at inovex.de> wrote:
>
> Hey Michael,
>
>
> On 03/04/2023 16:51, Michael Johnson wrote:
> > We just had the virtual PTG last week and discussed this topic[1].
> > [1]https://etherpad.opendev.org/p/march2023-ptg-designate
>
> Sorry I missed that opportunity to ask / discuss there.
>
> > As you know, we completed the specification document and merged it
> > during Antelope. So the community agrees on the plan to implement. At
> > this point it just needs developers to start work on the patches.
> >
> > During the PTG session no one attending was able to pick up this
> > specification for development, so we did not highlight it as a feature
> > targeted for Bobcat. I did say that I am willing to help anyone that
> > has developer resources work on it, I just cannot lead that effort
> > during Bobcat.
> >
> > So if you are willing to work on the patches, we will help out as we
> > can with reviews and answering questions, etc.
>
> I started a discussion internally about devoting some hours to at least
> get this off the ground.
> Does this spec need a "move" to Bobcat or other planning or acceptance
> process to aim for that release instead of Antelope?

The spec does not need to move. We are all set to start development
when someone is ready to work on it.

> And I am in no way asking for a fast-lane or special treatment. I would
> just like to be able advertise this as:
> "If we write the code, someone is going to look at it and helps to get
> this merged for Bobcat."

I think that is a fair statement. Just note that others in the
community may not have a lot of time to co-develop on it.

> Thanks for the fruitful discussions and again for picking up on this
> whole idea.
>
>
> Christian
>
>


From sgolovat at redhat.com  Mon Apr  3 20:31:58 2023
From: sgolovat at redhat.com (Sergii Golovatiuk)
Date: Mon, 3 Apr 2023 22:31:58 +0200
Subject: [tripleo] Nominate dbengt for tripleo-core !
In-Reply-To: <CAEggtay7MKKCUuDzvhhUitv=EgBRZMPjcdQ7cEDpjp0y04+SEg@mail.gmail.com>
References: <CAEggtay7MKKCUuDzvhhUitv=EgBRZMPjcdQ7cEDpjp0y04+SEg@mail.gmail.com>
Message-ID: <CALeCkHO7+0zsP6hJyOxFjB4TVS=CqnWNjGrFYw2z_VNBqSJwyQ@mail.gmail.com>

+1

??, 3 ???. 2023??. ? 18:40, Lukas Bezdicka <lbezdick at redhat.com>:

> Hello,
>
> I'd like to nominate Daniel Bengtsson as tripleo-core. He works in
> upgrades and he'll have to maintain train, wallaby and zed for quite a
> while. He is a long term contributor to tripleo and oslo.
>
> I trust his judgement and I hope you'll support his nomination!
>
> Thanks,
> Lukas Bezdicka
>


-- 
Sergii Golovatiuk

Senior Software Developer

Red Hat  <https://www.redhat.com/>
<https://www.redhat.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/95cee5c9/attachment.htm>

From johnsomor at gmail.com  Mon Apr  3 21:20:14 2023
From: johnsomor at gmail.com (Michael Johnson)
Date: Mon, 3 Apr 2023 14:20:14 -0700
Subject: [designate][ptg] Designate Bobcat (2023.2) PTG summary
Message-ID: <CAMH0Mg+yM0wCzcZtS-V7FOwPeaKc14ZzMjsyWkQps08X5zJEew@mail.gmail.com>

We accomplished some big tasks in Antelope: Finishing the shared zones
feature, adding support for SQL Alchemy 2.x, and hard zone deletes.

For the Bobcat series, Designate had a pretty straightforward PTG
session with good discussion. The focus areas for Bobcat are going to
be on the batch serial number update patch[1] (deferred from Antelope)
and improving the multiple pools feature[2][3]. Multiple DNS server
pools have been a feature in Designate for a number of years now, but
we need to improve the test coverage and documentation.
Other minor work anticipated for Bobcat is to update the RBAC testing
to account for the RBAC "Direction Change"[4] in support of enabling
the new Keystone default roles as the default RBAC configuration.

We also discussed the new specification that merged during Antelope[5]
to add support for catalog zones. This specification is merged and
ready for development, but it was not clear that there are developers
planning to work on it during Bobcat. We hope this feature can at
least get started during the Bobcat series.

Thank you to everyone that participated!

Michael

[1] https://review.opendev.org/c/openstack/designate/+/871255
[2] https://review.opendev.org/c/openstack/designate/+/857978
[3] https://review.opendev.org/c/openstack/designate-tempest-plugin/+/871184
[4] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#direction-change
[5] https://specs.openstack.org/openstack/designate-specs/specs/antelope/catalog-zones.html


From alsotoes at gmail.com  Mon Apr  3 23:39:39 2023
From: alsotoes at gmail.com (Alvaro Soto)
Date: Mon, 3 Apr 2023 17:39:39 -0600
Subject: [ironic] ARM Support in CI: Call for vendors / contributors /
 interested parties
In-Reply-To: <GV0P278MB09264C3EB7752AD0354DAFB9EF929@GV0P278MB0926.CHEP278.PROD.OUTLOOK.COM>
References: <CA+sTGNfqAzE=bR16oXwBFyObKV8iz_RVkyB43t-ZemftdHsESQ@mail.gmail.com>
 <GV0P278MB09264C3EB7752AD0354DAFB9EF929@GV0P278MB0926.CHEP278.PROD.OUTLOOK.COM>
Message-ID: <CA+eLJkbS6qh+cMQy_TvUgn-RTxcQa9wxZmQTx7X+AiNoCNXqZQ@mail.gmail.com>

Hey ironic team,
I'm adding Luis Felipe who is R&D manager at IDTOLU and it's interested in
helping with this project \o/
I hope it helps!

Cheers!

On Mon, Apr 3, 2023 at 5:39?AM Arne Wiebalck <Arne.Wiebalck at cern.ch> wrote:

> Jay,
>
> We have our ARM servers fully managed by Ironic as well (via the Redfish
> driver),
> including auto-discovery, benchmarking, burn-in and provisioning. They are
> set
> up as hypervisors and we provision ARM VMs on them to our users.
>
> We do not use the upstream IPA image, but build our own with IPAB (on an
> ARM
> based runner).
>
> Cheers,
>  Arne
>
> ________________________________________
> From: Jay Faulkner <jay at gr-oss.io>
> Sent: Wednesday, 29 March 2023 20:39
> To: OpenStack Discuss
> Subject: [ironic] ARM Support in CI: Call for vendors / contributors /
> interested parties
>
> Hi stackers,
>
> Ironic has published an experimental Ironic Python Agent image for ARM64 (
> https://tarballs.opendev.org/openstack/ironic-python-agent-builder/dib/files/)
> and discussed promoting this image to supported via CI testing. However, we
> have a problem: there are no Ironic developers with easy access to ARM
> hardware at the moment, and no Ironic developers with free time to commit
> to improving our support of ARM hardware.
>
> So we're putting out a call for help:
> - If you're a hardware vendor and want your ARM hardware supported? Please
> come talk to the Ironic community about setting up third-party-CI.
> - Are you an operator or contributor from a company invested in ARM bare
> metal? Please come join the Ironic community to help us build this support.
>
> Thanks,
> Jay Faulkner
> Ironic PTL
>
>
>
>

-- 

Alvaro Soto

*Note: My work hours may not be your work hours. Please do not feel the
need to respond during a time that is not convenient for you.*
----------------------------------------------------------
Great people talk about ideas,
ordinary people talk about things,
small people talk... about other people.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/b96e2200/attachment-0001.htm>

From nguyenhuukhoinw at gmail.com  Tue Apr  4 00:04:27 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Tue, 4 Apr 2023 07:04:27 +0700
Subject: [horizon]display quota volume type on horizon
In-Reply-To: <CADrq38vSthyNmVLUXLvZ=hMw_KZ8HK-49Qc_MdJ9DHZnqLfRCQ@mail.gmail.com>
References: <CABAODRf2FWL-fc+bWCdzWLCygy1NF29EWFyEZs7Mpn6X1HNBKQ@mail.gmail.com>
 <CADrq38vSthyNmVLUXLvZ=hMw_KZ8HK-49Qc_MdJ9DHZnqLfRCQ@mail.gmail.com>
Message-ID: <CABAODRc76qnJ_n5_mgN=T0hRa07j=DTuBSc78k2X8zcLMCdVPg@mail.gmail.com>

Great, thanks for the update.
Nguyen Huu Khoi


On Tue, Apr 4, 2023 at 12:02?AM vishal manchanda <
manchandavishal143 at gmail.com> wrote:

> Hi Nguy?n,
>
> I can see a bp[1] and a patch[2] as well up for this feature.
> I think the author of the patch no longer works with the horizon.
> Let me update and fix the CI and update the unit test to make it ready for
> review.
> Let's see if we can add this feature to the horizon in the bobcat cycle.
>
> Thanks & regards,
> Vishal Manchanda
>
> [1]
> https://blueprints.launchpad.net/horizon/+spec/quotas-per-cinder-volume-type
> [2] https://review.opendev.org/c/openstack/horizon/+/511472
>
> On Mon, Apr 3, 2023 at 7:05?PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> wrote:
>
>> Hello.
>> I see that blueprint is very real case but it has not deployed yet.
>>
>>
>> https://blueprints.launchpad.net/horizon/+spec/quotas-per-cinder-volume-type
>>
>> I am curious why it is abanddoned .
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/275764b6/attachment.htm>

From jamesleong123098 at gmail.com  Tue Apr  4 03:12:24 2023
From: jamesleong123098 at gmail.com (James Leong)
Date: Mon, 3 Apr 2023 22:12:24 -0500
Subject: [horizon][domain][yoga][kolla-ansible] horizon display failed to
 display domain tab
Message-ID: <CA+_ZFmG0CKSudcW3RwQ_ONyk71gc2g3=rb_wrGArJuYrStaPjA@mail.gmail.com>

Hi all,

I am playing around with the domain. I have used kolla-ansible as a
deployment tool for deploying the yoga version of OpenStack. However, after
deploying a fresh OpenStack, I was not able to view the domain tab on my
dashboard. Every time when I want to create a new domain, I have to go to
my terminal and create it manually without any GUI. Is there any other
configuration I have to enable in the globals.yml file other than setting
"horizon_keystone_multidomain: "True"?

Thanks for your help
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230403/baf3d1d5/attachment.htm>

From tkajinam at redhat.com  Tue Apr  4 03:35:08 2023
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Tue, 4 Apr 2023 12:35:08 +0900
Subject: [nova][heat] The next steps to "fix" libvirt problems in Ubuntu
 Jammy
In-Reply-To: <25dab368b2c68cc18ae83a52927c94561f46a77d.camel@redhat.com>
References: <CAL_crJQ+gdTu6ohhuYQsjhQeQvpHbwqWxnoUSU9gGaYCee2m7g@mail.gmail.com>
 <CALOCmukx_Lm09pw5n0xW63FQOnCS9LSiEJuYUb4uefixQiLfEg@mail.gmail.com>
 <CAL_crJQkPaoSCyXmYP_ULr8SHd5WjDn=DCX_tT07Wo=XrmyZ1g@mail.gmail.com>
 <25dab368b2c68cc18ae83a52927c94561f46a77d.camel@redhat.com>
Message-ID: <CAL_crJRGeqk9NKtz4tUtmv9rTN3_HfOJUH_jWRBQPEt9pyke5A@mail.gmail.com>

Thanks Sean for these replies. These make sense to me.

As I mentioned in my earlier reply, I run c9s jobs several times and I did
confirm the issue
can be reproduced in c9s.
# The attempts can be found here:
https://review.opendev.org/c/openstack/heat/+/879014/1

The interesting finding was that the issue appears in c9s much less
frequently than Ubuntu.
(The issue is reproduced in c9s once but I didn't hit it during recheck
while ubuntu jobs were
 consistently blocked by the libvirt problem.)

I don't know what is causing that difference but sharing my observation
just in case that sounds
also interesting to the other people.


On Thu, Mar 30, 2023 at 8:18?PM Sean Mooney <smooney at redhat.com> wrote:

> On Thu, 2023-03-30 at 19:54 +0900, Takashi Kajinami wrote:
> > Thank you, Sylvain, for all these inputs !
> >
> > On Thu, Mar 30, 2023 at 7:10?PM Sylvain Bauza <sbauza at redhat.com> wrote:
> >
> > >
> > >
> > > Le jeu. 30 mars 2023 ? 06:16, Takashi Kajinami <tkajinam at redhat.com> a
> > > ?crit :
> > >
> > > > Hello,
> > > >
> > > >
> > > > Since we migrated our jobs from Ubuntu Focal to Ubuntu Jammy, heat
> gate
> > > > jobs have
> > > > become very flaky. Further investigation revealed that the issue is
> > > > related to something
> > > > in libvirt from Ubuntu Jammy and that prevents detaching devices from
> > > > instances[1].
> > > >
> > > > The same problem appears in different jobs[2] and we workaround the
> > > > problem by disabling
> > > > some affected jobs. In heat we also disabled some flaky tests but
> because
> > > > of this we no longer
> > > > run basic scenario tests which deploys instance/volume/network in a
> > > > single stack, which means
> > > > we lost the quite basic test coverage.
> > > >
> > > > My question is, is there anyone in the Nova team working on "fixing"
> this
> > > > problem ?
> > > > We might be able to implement some workaround (like checking status
> of
> > > > the instances before
> > > > attempting to delete it) but this should be fixed in libvirt side
> IMO, as
> > > > this looks like a "regression"
> > > > in Ubuntu Jammy.
> > > > Probably we should report a bug against the libvirt package in
> Ubuntu but
> > > > I'd like to hear some
> > > > thoughts from the nova team because they are more directly affected
> by
> > > > this problem.
> > > >
> > > >
> > >
> > > FWIW, we discussed about it yesterday on our vPTG :
> > > https://etherpad.opendev.org/p/nova-bobcat-ptg#L289
> > >
> > > Most of the problems come from the volume detach thing. We also merged
> > > some Tempest changes for not trying to cleanup some volumes if the
> test was
> > > OK (thanks Dan for this). We also added more verifications to ask SSH
> to
> > > wait for a bit of time before calling the instance.
> > > Eventually, as you see in the etherpad, we didn't found any solutions
> but
> > > we'll try to add some canary job for testing multiple times volume
> > > attachs/detachs.
> > >
> >
> > > We'll also continue to discuss on the CI failures during every Nova
> weekly
> > > meetings (Tuesdays at 1600UTC on #openstack-nova) and I'll want to ask a
> > > cross-project session for the Vancouver pPTG for Tempest/Cinder/Nova
> and
> > > others.
> > > I leave other SMEs to reply on your other points, like for c9s.
> > >
> >
> > It's good to hear that the issue is still getting attention. I'll catch
> up
> > the discussion by reading the etherpad
> > and will try to attend follow-up discussions if possible, especially if I
> > can attend Vancouver vPTG.
> >
> > I know some changes have been proposed to check ssh-ability to workaround
> > the problem (though
> > the comment in the vPTG session indicates  that does not fully solve the
> > problem) but it's still annoying
> > because we don't really block resource deletions based on instance status
> > (especially its internal status)
> > so we eventually need some solutions here to avoid this problem, IMHO.
> >
> >
> > >
> > > > I'm now trying to set up a centos stream 9 job in Heat repo to see
> > > > whether this can be reproduced
> > > > if we use centos stream 9. I've been running that specific scenario
> test
> > > > in centos stream 9 jobs
> > > > in puppet repos but I've never seen this issue, so I suspect the
> issue is
> > > > really specific to libvirt
> > > > in Jammy.
> > > >
> > >
> > >
> > > Well, maybe I'm wrong, but no, we also have a centos9stream issue for
> > > volume detachs :
> > > https://bugs.launchpad.net/nova/+bug/1960346
> > >
> > >
> > I just managed to launch a c9s job in heat but it seems the issue is
> > reproducible in c9s as well[1].
>
> ya i replied in paralle in my other reply i noted that we saw this issue
> first in c9s then in ubuntu and we also see this in our internal downstram
> ci.
>
> changing the distro we use for the devstack jobs wont help unless we
> downgrade libvirt and qemu to before the
> orginal change in lbvirt was done. which would break other things.
> > I'll rerun the job a few more times to see how frequent the issue appears
> > in c9s compared to
> > ubuntu.
> > We do not run many tests in puppet jobs so that might be the reason I've
> > never hit it in
> > puppet jobs.
> >
> > [1] https://review.opendev.org/c/openstack/heat/+/879014
> >
> >
> > >
> > >
> > > > [1] https://bugs.launchpad.net/nova/+bug/1998274
> > > > [2] https://bugs.launchpad.net/nova/+bug/1998148
> > > >
> > > > Thank you,
> > > > Takashi
> > > >
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/bb4fa67a/attachment.htm>

From fpantano at redhat.com  Tue Apr  4 05:45:23 2023
From: fpantano at redhat.com (Francesco Pantano)
Date: Tue, 4 Apr 2023 07:45:23 +0200
Subject: [tripleo] Nominate dbengt for tripleo-core !
In-Reply-To: <CALeCkHO7+0zsP6hJyOxFjB4TVS=CqnWNjGrFYw2z_VNBqSJwyQ@mail.gmail.com>
References: <CAEggtay7MKKCUuDzvhhUitv=EgBRZMPjcdQ7cEDpjp0y04+SEg@mail.gmail.com>
 <CALeCkHO7+0zsP6hJyOxFjB4TVS=CqnWNjGrFYw2z_VNBqSJwyQ@mail.gmail.com>
Message-ID: <CAJy1LSHEY_NibzhsrrcdsHh6EnOorLv_5csPWhsMgMYp1qi3qQ@mail.gmail.com>

+1

On Mon, Apr 3, 2023 at 10:41?PM Sergii Golovatiuk <sgolovat at redhat.com>
wrote:

> +1
>
> ??, 3 ???. 2023??. ? 18:40, Lukas Bezdicka <lbezdick at redhat.com>:
>
>> Hello,
>>
>> I'd like to nominate Daniel Bengtsson as tripleo-core. He works in
>> upgrades and he'll have to maintain train, wallaby and zed for quite a
>> while. He is a long term contributor to tripleo and oslo.
>>
>> I trust his judgement and I hope you'll support his nomination!
>>
>> Thanks,
>> Lukas Bezdicka
>>
>
>
> --
> Sergii Golovatiuk
>
> Senior Software Developer
>
> Red Hat  <https://www.redhat.com/>
> <https://www.redhat.com/>
>


-- 
Francesco Pantano
GPG KEY: F41BD75C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/6cb6e0a7/attachment-0001.htm>

From jake.yip at ardc.edu.au  Tue Apr  4 06:08:26 2023
From: jake.yip at ardc.edu.au (Jake Yip)
Date: Tue, 4 Apr 2023 16:08:26 +1000
Subject: Propose Dale Smith as Magnum Caore
Message-ID: <3ddb89c6-3841-52d9-bf4d-87c64a7c76a6@ardc.edu.au>

Hi all,

I would like to propose Dale Smith as a Magnum Core Reviewer.

Dale is a contributor to Magnum, and also takes care of Magnum at his 
place of employment - Catalyst Cloud NZ.

As many Magnum contributors are ourselves operators, I think it is 
important that we have representation from different cloud providers to 
help guide and shape Magnum going forward.

He will replace Feilong, who is the former PTL and used to work in 
Catalyst Cloud, in the Core Team.

We thank Feilong for his contributions and welcome Dale.

Regards,
Jake
-- 
Jake Yip
Technical Lead, ARDC Nectar Research Cloud


From dpawlik at redhat.com  Tue Apr  4 06:30:12 2023
From: dpawlik at redhat.com (Daniel Pawlik)
Date: Tue, 4 Apr 2023 08:30:12 +0200
Subject: Opensearch service upgrade
In-Reply-To: <CAEZjfK7ALV+P5wGT_miD1czZx_JfhtdaXogkLaBDMhZB4zEKnw@mail.gmail.com>
References: <CAEZjfK7ALV+P5wGT_miD1czZx_JfhtdaXogkLaBDMhZB4zEKnw@mail.gmail.com>
Message-ID: <CAEZjfK6yX3f9xGPzwA0gJzi2gtaG5gXZxBn=TEEn=wXoRUAMkA@mail.gmail.com>

Hello,

The upgrade of OpenSearch [1] to version 2.5 is completed.
Do not hesitate to reach me on #opendev if spotted any issue.

Dan

[1]
https://opensearch.logs.openstack.org/_dashboards/app/discover?security_tenant=global

On Fri, Mar 17, 2023 at 4:42?PM Daniel Pawlik <dpawlik at redhat.com> wrote:

> Hello,
>
> We would like to notify you that the Opensearch service [1] would be
> updated to a newer version on 03.04.2023 at 12:00 PM UTC.
>
> This procedure might take a while, depending of the cluster size. During
> that time, the Opensearch service would not be available.
>
> If anyone has any doubts, please reply to the email.
>
> Dan
>
> [1] - https://opensearch.logs.openstack.org/_dashboards/app/home
>


-- 
Regards,
Daniel Pawlik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/3e3adfc6/attachment.htm>

From sbauza at redhat.com  Tue Apr  4 06:52:56 2023
From: sbauza at redhat.com (Sylvain Bauza)
Date: Tue, 4 Apr 2023 08:52:56 +0200
Subject: [nova] 2023.2 Bobcat PTG summary
In-Reply-To: <CALOCmunNB4s+VmRxX+gO-pinCcwOARGDLF4jgMB7vOT49WwS+Q@mail.gmail.com>
References: <CALOCmunNB4s+VmRxX+gO-pinCcwOARGDLF4jgMB7vOT49WwS+Q@mail.gmail.com>
Message-ID: <CALOCmunefm9=bt2sO9fSkGZEq5xu2h7bKN0SdBigPid1xCWmcQ@mail.gmail.com>

Whoops, made a typo. See below.


Le lun. 3 avr. 2023 ? 16:57, Sylvain Bauza <sbauza at redhat.com> a ?crit :

> Hey folks, that's a wrap ! I'm happy to say we had a very productive PTG
> week with around more than 12 contributors each day. It was nice to see new
> faces.
>
> As a reminder, please don't open the main etherpad link [1] if you use a
> Web browser with an automatic translation modification feature. If you do
> it, then it would internally translate all the phrases directly in the
> etherpad as if you were directly modifying the etherpad by yourself. Please
> also make sure you don't accidentally remove or modify lines .
>
> In order to prevent any misusage, this etherpad is a read-only copy of the
> main one :
> https://etherpad.opendev.org/p/r.22d95e20f7133350dcad573c015ed7da
>
> Last point but not the least, I'm a human who usually writes bugs [2],
> including when it's about writing a report of the past week's discussions
> and the actions taken. Don't feel offended or irritated if you read silly
> notes of the very beloved chat you had, please rather fix it the opensource
> way by correcting my errors with a reply on that thread.
>
> Enough chat, please grab a coffee [3] (as it's a quite verbose email) and
> jump straight on below.
>
> ### Operator hour ###
> (specific and distinct read-only etherpad here :
> https://etherpad.opendev.org/p/r.f94e6dda608450b6a4a5c9afc76e8a88 )
> Yet again, we missed a few more operators in this room (at least we had 3
> of them, thanks for those that were there !). I'm still wondering why they
> are not joining a free session where they can discuss their concerns or
> some wanted features. Anyway, that's what we discussed :
>  - for the moment, no operators have tried to use the Yoga unified limits
> feature.
>  - operators are happy with the new default RBAC scopes. We could create a
> small and quick admin-guide section for explaining that and pointing to the
> oslo.policy documentation.
>  - operators would love to use the (possibly) new virtiofs feature from
> Bobcat for Manila shares (if we are able to merge it). That being said,
> they think they couldn't provide it for their environments until Nova can
> live-migrate the instances using the shares (which is not possible as for
> the moment, even QEMU doesn't support it)
>  - we also discussed a pain point from an operator and then we asked him
> to provide a bug report (related to the vm state continuing to be ACTIVE
> after shelving). For the moment, we can't reproduce the problem.
>
> ### Cross-project discussions ###
>
> ## Manila/Nova ###
>
> # Prevent shares deletion while it's attached to an instance
>  - Nova could add some traits to reflect the share type.
>  - the Manila team will create a manila spec for adding a service-level
> (or admin-level) lock API with a 'locked-by' parameter (or using service
> tokens if set)
>
> ### Neutron/Nova ###
> Read Neutron summary email [4] if you want more details.
>
>  - We agreed on a delete_on_termination feature for ports. We need to see
> if we can use some already existing Neutron API (tags) or if we need a
> whole new API.
>  - We are quite OK with the Napatech LinkVirt SmartNics feature, but we
> need to review the spec and we also want some third-party CI support for it.
>  - the Neutron team accepted to return a HTTP409 Conflict return code if a
> duplicated port binding action is done by Nova and the Nova team agreed on
> handling it.
>  - About the SRIOV port tracking in Placement, the Nova team needs to help
> the spec owner on how to work on it as it's a large and difficult design
> (but we agreed on the first part of the design).
>
> ### Glance/Nova ###
>
> Glance wants to add a new API for Image Direct URL access. Nova was quite
> OK with this new API, but the Nova team was having some concerns about
> upgrades and client calls to the new API. The Manila team agreed to create
> a nova spec for discussing those.
>
> ### Cinder/Nova ###
>
> - The Nova team is quite OK with the usecase for NFV encryption. Since the
> design is quite simple, maybe this could be a specless feature, just using
> traits for telling to Placement which computes support NFV encryption.
> We're OK to test this with cinder NFV jobs and maybe also testing it with a
> Nova periodic job depending on the implementation.
>


Hah, you should read NFS encryption (Network File System) and of course
*not* NFV encryption (Networking Function Virtualization) (or maybe you
wondered why then we discussed this with the Cinder team ? ;-) )

>  - The Cinder team agreed on using its volume metadata API for tracking
> the cinder volumes hardware models.
>
> ### Horizon/Nova ###
>
> Horizon wanted to call the Placement API. We agreed on using the
> openstackSDK for this as Placement doesn't have python bindings directly.
> Some new methods may be added against the SDK for calling specific
> Placement APIs if we think we may need those (instead of directly calling
> Placement with the standard HTTP verbs and the API URIs)
>
> ### Nova-specific topics ###
>
> # Antelope retrospective and process-related discussions
>
> Shorter cycle than Zed, 6 features landed (same as Zed), 46 contributors
> (down by 8 compared to Zed), 27 bugfixes (vs. 54 for Zed).
> We were happy to not have a RC2 for the first time in the Nova history.
> The bug triage backlog kept small.
>  - We want to discuss on a better review cadence to not look at all the
> implementations by the last weeks.
>  - We want to get rid of Storyboard stories in Placement. We found and
> agreed on a way forward.
>  - We will set 5-years-old-and-more bug reports as Incomplete, so bug
> reporters have 90 days to confirm that the bug is still present on master.
>  -  We will add more contrib documentation for explaining more how to find
> Gerrit changes for one-off reviewers and how to create some changes
>  - We agreed on no longer automatically accepting an already-approved spec
> from a previous cycle if no code is still not existing.
>  - All efforts on porting our client calls to the SDK should be tagged in
> Launchpad with the 'sdk' tag.
>  - A Bobcat schedule will be proposed on next Tuesday weekly meeting with
> feature and spec deadlines + some review days.
>  - We also discussed what we should discuss in the Vancouver PTG.
>
> # CI failures continuous improvement
>
> - We want to test some alternative image but cirros (alpine as a potential
> alternative) with a small footprint in some specific nova jobs
> - We need to continue investigating on the volume detach/attach failures.
> We may create a specific job that would do serialized volume checks as a
> canary job for forcing the job to fail more frequently in order to dig down
> further.
> - (related) Sylvain will propose a Vancouver PTG cross-project session for
> a CI debugging war room experience.
>
> # The new release cadence
>
> We had long arguments whether we should hold deprecations and removals
> this cycle, given the releasenotes tooling isn't in place yet. As a
> reminder, since Bobcat is a non-SLURP release, operators are able to skip
> it and just look at the C releasenotes so we want to make sure we
> forward-port upgrade notes for them. For the moment, no consensus in place,
> we defer the outcome into a subsequent nova meeting and in the meantime, we
> raised the point to the TC for guidance needs.
>
> # The problem with hard affinity group policies
>
> - We agreed on the fact that hard affinity/anti-affinity policies aren't
> ideal (operators, if you read me, please prefer soft affinity/anti-affinity
> policies for various reasons I won't explain here) but since we support
> those policies and the use case is quite understandable, we need to find a
> way to unblock instances that can't be easily-migrated from those kind of
> groups (eg. try to move your instances off a host with hard Affinity
> between them, good luck)
> - A consensus has been reached to propose a new parameter for
> live-migrate, evacuate and migrate that would only skip the hard affinity
> checks. A backlog spec will be written capturing this consensus.
> - Since a group policy may be violated, we'll also propose a new server
> group API modification that would show if a group has its policy violated.
>
> # Unified limits next steps
>
> - We agreed on the fact we should move on and enable by default unified
> limits in a close future, but we first need to provide a bit of tooling to
> help the migration.
> - tool could be a nova-manage command that would provide the existing
> quota limits as a yaml file so we could inject those into keystone (to be
> further defined during Bobcat)
> - a nova-status upgrade check may be nice for yelling if operators forgot
> to define their limits in keystone before upgrading to the release
> (potentially C) that would default to unified limits
> - testing in the grenade job is a feat.
>
> # Frequently written objects may lead to exhaustion of DB primary keys
> - We agreed on having all new primary keys to have BigInteger as data
> type. Existing keys should use BigInt but there is a huge upgrade impact to
> mitigate.
> - Operators will be sollicited to know their preferences between a
> costly-at-once data migration vs. a rolling data online migration for
> existing tables.
> - We will document which DB tables are safe to reindex (since their PKs
> isn't normalized as a FK somewhere else)
> - A backlog spec will capture all of the above
>
> # Leftover volumes relationship when you directly call Cinder instead of
> Nova for detaching
> - Yup, this is a known issue and we should discuss this with the Cinder
> team (unfortunately, we didn't did it this week)
> - We maybe should have a nova-manage script that would cleanup the BDMs
> but we're afraid of leaking some volume residues in the compute OS
> - Anyway, we need to understand the main scope and we also need to discuss
> about the preconditions ('when' should we call this tool and 'what' this
> tool should be doing ?). Probably a spec.
>
> # Misc but not the leasc (heh)
>
>  - we will fill a rfe bug for lazy-loading instance name from system
> metadata or update the nested field in the instance object (no additional
> DB write)
>  - we will add a new policy for cold-migrate specifically when a host is
> passed as a parameter (admin-only as a default)
>  - We agreed on continuing the effort on compute node hostname
> robustification (the Bobcat spec seems not controversial)
>  - We agreed on a few things about the server show command and the use of
> the SDK. Some existing OSC patch may require a bit of rework but it would
> cover most of the concerns we discussed.
>  - we should fix the post-copy issue when you want to live-migrate a
> paused instance by removing the post-copy migration flag if so.
>  - we could enable virtio-blk trim support by default. It's both a bugfix
> (we want to remove an exception) and a new feature (we want to enable it by
> default) so we'll discuss whether we need a specless blueprint by a next
> meeting.
>  - we also discuss about a Generic VDPA support feature for Nova, and we
> asked the owner to provide us a spec for explaining the usecase.
>
> ### That's it. ###
>
> Yet again, I'm impressed. If you read that phrase, you're done with
> reading. I just hope your coffee was good and the time you took reading
> that email was worth it. If you have questions or want to reach me directly
> on IRC, that's simple : I'm bauzas on #openstack-nova.
>
> HTH,
> -Sylvain (on behalf of the whole Nova community)
>
>
> [1] https://etherpad.opendev.org/p/nova-bobcat-pt g (please remove the
> empty char between 'pt' and 'g')
> [2] Unfortunately, I'm very good at creating bugs as I discovered that
> based on my 10-year unfortunate contributions to OpenStack.
> [3] Or a tea, or whatever you prefer.
> [4]
> https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033115.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/2cd8e872/attachment-0001.htm>

From ralonsoh at redhat.com  Tue Apr  4 07:45:52 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Tue, 4 Apr 2023 09:45:52 +0200
Subject: [neutron] Neutron drivers meeting
Message-ID: <CAECr9X6ste=1wzs5n4DfrzKSkx=1CORChkVuvGT=sb6kbRtGdw@mail.gmail.com>

Hello Neutrinos:

Next Neutron drivers meeting (April 7) will be cancelled. This is Easter
week and most people will have Friday as a holiday.

See you next week.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/c644f93a/attachment.htm>

From skaplons at redhat.com  Tue Apr  4 07:54:16 2023
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Tue, 04 Apr 2023 09:54:16 +0200
Subject: [Neutron] CI meeting 04.04.2023 cancelled
Message-ID: <2306563.cJImm0v6r3@p1>

Hi,

I have overlapping internal meeting this week and will not be able to run Neutron CI meeting. So lets cancel it and meet next week. See You there.

-- 
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: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/b416180e/attachment.sig>

From rdhasman at redhat.com  Tue Apr  4 08:39:01 2023
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Tue, 4 Apr 2023 14:09:01 +0530
Subject: [nova][cinder] Providing ephemeral storage to instances - Cinder
 or Nova
In-Reply-To: <c510ca65d6cfc89ba975c701b1eda9f01a018097.camel@redhat.com>
References: <9d7f3d0a-5e99-7880-f573-6ccd53be47b0@inovex.de>
 <c510ca65d6cfc89ba975c701b1eda9f01a018097.camel@redhat.com>
Message-ID: <CAARK8KSRbTYf6sgX2cya5tyxJoSkQOfPFWXXifDmnK3TBFqXBg@mail.gmail.com>

On Sat, Mar 25, 2023 at 12:27?AM Sean Mooney <smooney at redhat.com> wrote:

> i responed in line but just a waring this is a usecase we ahve heard
> before.
> there is no simple option im afraid and there are many many sharp edges
> and severl littel know features/limitatiosn that your question puts you
> right in the
> middel of.
>
> On Fri, 2023-03-24 at 16:28 +0100, Christian Rohmann wrote:
> > Hello OpenStack-discuss,
> >
> > I am currently looking into how one can provide fast ephemeral storage
> > (backed by local NVME drives) to instances.
> >
> >
> > There seem to be two approaches and I would love to double-check my
> > thoughts and assumptions.
> >
> > 1) *Via Nova* instance storage and the configurable "ephemeral" volume
> > for a flavor
> >
> > a) We currently use Ceph RBD als image_type
> > (
> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.images_type),
>
> > so instance images are stored in Ceph, not locally on disk. I believe
> > this setting will also cause ephemeral volumes (destination_local) to be
> > placed on a RBD and not /var/lib/nova/instances?
> it should be in ceph yes we do not support havign the root/swap/ephemral
> disk use diffent storage locatiosn
> > Or is there a setting to set a different backend for local block devices
> > providing "ephemeral" storage? So RBD for the root disk and a local LVM
> > VG for ephemeral?
> no that would be a new feature and not a trivial one as yo uwould have to
> make
> sure it works for live migration and cold migration.
>
> >
> > b) Will an ephemeral volume also be migrated when the instance is
> > shutoff as with live-migration?
> its hsoudl be. its not included in snapshots so its not presergved
> when shelving. that means corss cell cold migration will not preserve the
> disk.
>
> but for a normal cold migration it shoudl be scp'd or rsynced with the
> root disk
> if you are using the raw/qcow/flat images type if i remember correctly.
> with RBD or other shared storage like nfs it really sould be preserved.
>
> one other thing to note is ironic and only ironic support the
> preserve_ephemeral option in the rebuild api.
>
> libvirt will wipte the ephmeral disk if you rebuild or evacuate.
> > Or will there be an new volume created on the target host? I am asking
> > because I want to avoid syncing 500G or 1T when it's only "ephemeral"
> > and the instance will not expect any data on it on the next boot.
> i would perssonally consider it a bug if it was not transfered.
> that does not mean that could not change in the future.
> this is a very virt driver specific behaivor by the way and nto one that
> is partically well docuemnted.
> the ephemeral shoudl mostly exist for the lifetime of an instance. not the
> lifetime of a vm
>
> for exmple it should nto get recreate vai a simple reboot or live migration
> it should not get created for cold migration or rezise.
> but it will get wipted for shelve_offload, cross cell resize and evacuate.
> >
> > c) Is the size of the ephemeral storage for flavors a fixed size or just
> > the upper bound for users? So if I limit this to 1T, will such a flavor
> > always provision a block device with his size?
> flavor.ephemeral_gb is an upper bound and end users can devide that
> between multipel ephermal disks
> on the same instance.  so if its 100G you can ask for 2 50G epmeeral disks
>
> you specify the toplogy of the epmermeral disk using the
> block_device_mapping_v2 parmater on the server
> create.
> this has been automated in recent version of the openstack client
>
> so you can do
>
> openstack server creeate  --ephemeral size=50,format=ext4 --ephemeral
> size=50,format=vfat ...
>
>
> https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html#cmdoption-openstack-server-create-ephemeral
> this is limted by
>
> https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.max_local_block_devices
>
> >
> > I suppose using LVM this will be thin provisioned anyways?
> to use the lvm backend with libvirt you set
>
> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.images_volume_group
> to identify which lvm VG to use.
>
>
> https://docs.openstack.org/nova/latest/configuration/config.html#libvirt.sparse_logical_volumes
> might enable thin provsion or it might
> work without it but see the note
>
> """
> Warning
>
> This option is deprecated for removal since 18.0.0. Its value may be
> silently ignored in the future.
>
> Reason
>
>     Sparse logical volumes is a feature that is not tested hence not
> supported. LVM logical volumes are preallocated by default. If you want thin
> provisioning, use Cinder thin-provisioned volumes.
> """
>
> the nova lvm supprot has been in maintance mode for many years.
>
> im not opposed to improving it just calling out that it has bugs and noone
> has really
> worked on adressing them in 4 or 5 years which is sad becasue it out
> performnce raw for local
> storage perfroamce and if thin provisioning still work it shoudl
> outperform qcow too for a simialr usecase.
>
> you are well into undefined behavior land however at this point
>
> we do not test it so we assume untile told otherwise that its broken.
>
>
> >
> >
> > 2) *Via Cinder*, running cinder-volume on each compute node to provide a
> > volume type "ephemeral", using e.g. the LVM driver
> >
> > a) While not really "ephemeral" and bound to the instance lifecycle,
> > this would allow users to provision ephemeral volume just as they need
> them.
> > I suppose I could use backend specific quotas
> > (
> https://docs.openstack.org/cinder/latest/cli/cli-cinder-quotas.html#view-block-storage-quotas)
>
> > to
> > limit the number of size of such volumes?
> >
> > b) Do I need to use the instance locality filter
> > (
> https://docs.openstack.org/cinder/latest/contributor/api/cinder.scheduler.filters.instance_locality_filter.html)
>
> > then?
>
> That is an option but not ideally since it stilll means conencting to the
> volume via iscsi or nvmeof even if its effectlvy via localhost
> so you still have the the network layer overhead.
>
>
I haven't tried it so I'm not 100% sure if it works but we do support local
attach with the RBD connector.
While creating the connector object, we can pass "do_local_attach"=True[1]
and that should do local attach when we call
connect volume for the RBD connector.
>From a quick search, I can see all the consumers of this code are:
1) cinderlib[3]
2) nova hyperv driver[4]
3) python-brick-cinderclient-ext[5]
4) freezer[6]
5) zun[7]

It's interesting to see a project called compute-hyperv[8] (similar to
nova's hyperv driver) using it as well. Not sure why it's created
separately though.

[1]
https://opendev.org/openstack/os-brick/src/commit/28ffcdbfa138859859beca2f80627c076269be56/os_brick/initiator/connectors/rbd.py
[2]
https://opendev.org/openstack/os-brick/src/commit/28ffcdbfa138859859beca2f80627c076269be56/os_brick/initiator/connectors/rbd.py#L263-L267
[3]
https://opendev.org/openstack/cinderlib/src/commit/9c37686f358e9228446cd85e19db26a56b2f9cbe/cinderlib/objects.py#L779
[4]
https://opendev.org/openstack/nova/src/commit/29de62bf3b3bf5eda8986bc94babf1c94d67bd4e/nova/virt/hyperv/volumeops.py#L378
[5]
https://opendev.org/openstack/python-brick-cinderclient-ext/src/branch/master/brick_cinderclient_ext/client.py
[6]
https://opendev.org/openstack/freezer/src/commit/5effc1382833ad111249bcd279b11fbe95e10a6b/freezer/engine/osbrick/client.py#L78
[7]
https://opendev.org/openstack/zun/src/commit/0288a4517846d07ee5724f86ebe34e364dc2bbe9/zun/volume/cinder_workflow.py#L60-L61
[8]
https://opendev.org/openstack/compute-hyperv/src/commit/4393891fa8356aa31b13bd57cf96cb5109acc7c3/compute_hyperv/nova/volumeops.py#L780

when i alas brought up this topic in a diffent context the alternitive to
> cinder and nova was to add a lvm cyborg driver
> so that it could parttion local nvme devices and expose that to a guest.
> but i never wrote that and i dotn think anyone else has.
> if you had a slightly diffent usecase such as providing an entire nvme or
> sata device to a guest the cyborge would be how you would do
> that. nova pci passhtough is not an option as it is not multi tenant safe.
> its expclsively for stateless device not disk so we do not
> have a way to rease the data when done. cyborg with htere driver modle can
> fullfile the multi tenancy requirement.
> we have previously rejected adding this capabliyt into nova so i dont
> expect us to add it any tiem in teh near to medium term.
>
> we are trying to keep nova device manamgnet to stateless only.
> That said we added intel PMEM/NVDIM supprot to nova and did handle both
> optionl data transfer and multi tancny but that was a non trivial amount of
> work
>
>
> >
> > c)  Since a volume will always be bound to a certain host, I suppose
> > this will cause side-effects to instance scheduling?
> > With the volume remaining after an instance has been destroyed (beating
> > the purpose of it being "ephemeral") I suppose any other instance
> > attaching this volume will
> > be scheduling on this very machine?
> >
> no nova would have no knowage about the volume locality out of the box
> >  Is there any way around this? Maybe
> > a driver setting to have such volumes "self-destroy" if they are not
> > attached anymore?
> we hate those kind of config options nova would not know that its bound to
> the host at the schduler level and
> we would nto really want to add orcstration logic like that for "something
> its oke to delete our tenatns data"
> by default today if you cold/live migrated the vm would move but the
> voluem vould not and you would end up accessing it remotely.
>
> you woudl have to then do a volume migration sepreately in cinder i think.
> >
> > d) Same question as with Nova: What happens when an instance is
> > live-migrated?
> >
> i think i anser this above?
> >
> >
> > Maybe others also have this use case and you can share your solution(s)?
> adding a cyborg driver for lvm storage and integrateing that with nova
> would like be the simpelt option
>
> you coudl extend nova but as i said we have rejected that in the past.
> that said the generic resouce table we added for pemem was made generic so
> that future resocues like local block
> device could be tracked there without db changes.
>
> supproting differnt image_type backend for root,swap and ephmeral would be
> possibel.
> its an invasive change but might be more natural then teh resouce tabel
> approch.
> you coudl reuse more fo the code and inherit much fo the exiting
> fucntionality btu makeing sure you dont break
> anything in the process woudl take a lot of testing.
>
> > Thanks and with regards
> >
> >
> > Christian
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/5ae6e24e/attachment-0001.htm>

From eblock at nde.ag  Tue Apr  4 08:50:07 2023
From: eblock at nde.ag (Eugen Block)
Date: Tue, 04 Apr 2023 08:50:07 +0000
Subject: [horizon][domain][yoga][kolla-ansible] horizon display failed
 to display domain tab
In-Reply-To: <CA+_ZFmG0CKSudcW3RwQ_ONyk71gc2g3=rb_wrGArJuYrStaPjA@mail.gmail.com>
Message-ID: <20230404085007.Horde.GRUkGTBzTqfkCRlrT9LeH3A@webmail.nde.ag>

Hi,

I'm not familiar with kolla-ansible but in order to view the domains  
tab you not only require the change in horizon:

OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True
(and optional: OPENSTACK_KEYSTONE_DOMAIN_DROPDOWN = True)

but also a new role:

root at control01:~# openstack role add --domain Default --user admin admin

So my admin user gets the admin role for the "Default" domain. After  
that I can see the domains tab in the dashboard.

Hope this helps!
Eugen

Zitat von James Leong <jamesleong123098 at gmail.com>:

> Hi all,
>
> I am playing around with the domain. I have used kolla-ansible as a
> deployment tool for deploying the yoga version of OpenStack. However, after
> deploying a fresh OpenStack, I was not able to view the domain tab on my
> dashboard. Every time when I want to create a new domain, I have to go to
> my terminal and create it manually without any GUI. Is there any other
> configuration I have to enable in the globals.yml file other than setting
> "horizon_keystone_multidomain: "True"?
>
> Thanks for your help
> James





From franck.vedel at univ-grenoble-alpes.fr  Tue Apr  4 09:36:39 2023
From: franck.vedel at univ-grenoble-alpes.fr (Franck VEDEL)
Date: Tue, 4 Apr 2023 11:36:39 +0200
Subject: [horizon][domain][yoga][kolla-ansible] horizon display failed to
 display domain tab
In-Reply-To: <CA+_ZFmG0CKSudcW3RwQ_ONyk71gc2g3=rb_wrGArJuYrStaPjA@mail.gmail.com>
References: <CA+_ZFmG0CKSudcW3RwQ_ONyk71gc2g3=rb_wrGArJuYrStaPjA@mail.gmail.com>
Message-ID: <28C8370B-12A5-4461-B168-BA522F9BE1F1@univ-grenoble-alpes.fr>

Hi, 
if this could help?


# more /etc/kolla/config/keystone/keystone.conf
[identity]
domain_specific_drivers_enabled = True
domain_config_dir = /etc/keystone/domains

# ls /etc/kolla/config/keystone/domains/
cacert.pem  keystone.tprt2.conf  keystone.tprt.conf


For me, it works !


Franck 


> Le 4 avr. 2023 ? 05:12, James Leong <jamesleong123098 at gmail.com> a ?crit :
> 
> Hi all,
> 
> I am playing around with the domain. I have used kolla-ansible as a deployment tool for deploying the yoga version of OpenStack. However, after deploying a fresh OpenStack, I was not able to view the domain tab on my dashboard. Every time when I want to create a new domain, I have to go to my terminal and create it manually without any GUI. Is there any other configuration I have to enable in the globals.yml file other than setting "horizon_keystone_multidomain: "True"?
> 
> Thanks for your help
> James

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/0ed50b15/attachment.htm>

From bartelme at gmail.com  Tue Apr  4 12:08:57 2023
From: bartelme at gmail.com (John Bartelme)
Date: Tue, 4 Apr 2023 08:08:57 -0400
Subject: [neutron][OpenStack-ansible] Performance issues with trunk ports
Message-ID: <CADC88Ce0xV3RytP2yi3+mJQOdtv8F_NuCGgbUu3g2_Z6AT7Jcg@mail.gmail.com>

Hello,

I'm currently experiencing some pretty severe performance issues with my
openstack-ansible deployed cluster(yoga) while deploying trunk ports and
I'm looking for some help determining what might be the cause of this poor
performance.

In my simplest case I'm deploying 2 servers each with one trunk port each.
The first trunk has 2 subports and the second 6 subports. Both servers also
have 3 other regular ports. When deploying the first trunk port its
subports are often provisioned quickly and the second trunk port takes
anywhere from 30 seconds to 18 minutes. This happens even when I isolate
neutron-server to a single physical machine with 44(88 threads) and 256GB
ram. Further diagnosis has shown me some things i didn't quite understand.
My deployment with OpenStack-ansible deploys neutron-server with 16 uWSGI
processes and neutron-rpc-server with 16 rpc workers. However the way that
the trunk RPC server is implemented it is only run on the parent RPC thread
and instead runs in all of the uWSGI processes as well. This means that
most of my trunk RPC calls are being handled by the uWSGI instead of the
RPC workers. When the parent RPC thread handles the trunk port creation
calls I constantly see creation times of 1-1.5 seconds. I've isolated it so
that this thread does all of the trunk RPC calls and this works quite well
but this doesn't seem ideal. What could be causing such poor performance in
the uWSGI side of the house? I'm having a really hard time getting a good
feeling for what might be slowing it down so much. I'm wondering if it
could be green thread preemption but I really don't know. I've tried
setting 'enable-threads' false for uWSGI but I don't think that is
improving performance. Putting the profiled decorator on
update_subport_bindings shows different places taking longer every time,
but in general a lot of time(tottime, i.e. not subfunction time) spent in
webob/dec.py(__call__), paste/urlmap.py(__call__),
webob/request.py(call_application),webob/request.py(send). What else can I
do to try and look for why this is taking so long?

As a side question it seems counterintuitive that the uWSGI handles most of
the trunk RPC calls and not the RPC workers?

A couple other notes about my environment that could indicate my challenges:

I had to disable rabbitmq heartbeats for neutron as they kept not getting
sent reliably and connections were terminated. I tried with
heartbeat_in_pthread both true and false but still had issues. It looks
like nova also sometimes experiences this but not near as often.

I was overzealous with my vxlan ranges in my first configuration and gave
it a range of 10,000,000 not realizing that would create that many rows in
the database. Looking into that I saw that pymysql in my cluster takes 3.5
minutes to retrieve those rows. mysql CLI only takes 4 seconds. Perhaps
that is just the overhead of pymysql? I've greatly scaled down the vxlan
range now.

I'm provisioning the 2 servers with a heat template that contains around
200 custom resources. For 198 of the resources they are set to
conditionally not create any OpenStack native resources. Deploying this
template of mostly no-op resources still takes about 3 minutes.

Horizon works but almost every page load take a few seconds to load. I'm
not sure if that is normal or not.

Thanks for any help anyone can provide.

john


From katonalala at gmail.com  Tue Apr  4 12:27:58 2023
From: katonalala at gmail.com (Lajos Katona)
Date: Tue, 4 Apr 2023 14:27:58 +0200
Subject: [neutron][OpenStack-ansible] Performance issues with trunk ports
In-Reply-To: <CADC88Ce0xV3RytP2yi3+mJQOdtv8F_NuCGgbUu3g2_Z6AT7Jcg@mail.gmail.com>
References: <CADC88Ce0xV3RytP2yi3+mJQOdtv8F_NuCGgbUu3g2_Z6AT7Jcg@mail.gmail.com>
Message-ID: <CALg0jK=FLJvXpQfcFFf=uRFFdL=tTGLLjox8UiK_RuJ3cWchfA@mail.gmail.com>

Hi,
could you open a bug report on https://bugs.launchpad.net/neutron/ for the
trunk issue with reproduction steps?
It is also important which backend you use? OVS or something else?

Thanks in advance
Lajos Katona (lajoskatona)

John Bartelme <bartelme at gmail.com> ezt ?rta (id?pont: 2023. ?pr. 4., K,
14:15):

> Hello,
>
> I'm currently experiencing some pretty severe performance issues with my
> openstack-ansible deployed cluster(yoga) while deploying trunk ports and
> I'm looking for some help determining what might be the cause of this poor
> performance.
>
> In my simplest case I'm deploying 2 servers each with one trunk port each.
> The first trunk has 2 subports and the second 6 subports. Both servers also
> have 3 other regular ports. When deploying the first trunk port its
> subports are often provisioned quickly and the second trunk port takes
> anywhere from 30 seconds to 18 minutes. This happens even when I isolate
> neutron-server to a single physical machine with 44(88 threads) and 256GB
> ram. Further diagnosis has shown me some things i didn't quite understand.
> My deployment with OpenStack-ansible deploys neutron-server with 16 uWSGI
> processes and neutron-rpc-server with 16 rpc workers. However the way that
> the trunk RPC server is implemented it is only run on the parent RPC thread
> and instead runs in all of the uWSGI processes as well. This means that
> most of my trunk RPC calls are being handled by the uWSGI instead of the
> RPC workers. When the parent RPC thread handles the trunk port creation
> calls I constantly see creation times of 1-1.5 seconds. I've isolated it so
> that this thread does all of the trunk RPC calls and this works quite well
> but this doesn't seem ideal. What could be causing such poor performance in
> the uWSGI side of the house? I'm having a really hard time getting a good
> feeling for what might be slowing it down so much. I'm wondering if it
> could be green thread preemption but I really don't know. I've tried
> setting 'enable-threads' false for uWSGI but I don't think that is
> improving performance. Putting the profiled decorator on
> update_subport_bindings shows different places taking longer every time,
> but in general a lot of time(tottime, i.e. not subfunction time) spent in
> webob/dec.py(__call__), paste/urlmap.py(__call__),
> webob/request.py(call_application),webob/request.py(send). What else can I
> do to try and look for why this is taking so long?
>
> As a side question it seems counterintuitive that the uWSGI handles most of
> the trunk RPC calls and not the RPC workers?
>
> A couple other notes about my environment that could indicate my
> challenges:
>
> I had to disable rabbitmq heartbeats for neutron as they kept not getting
> sent reliably and connections were terminated. I tried with
> heartbeat_in_pthread both true and false but still had issues. It looks
> like nova also sometimes experiences this but not near as often.
>
> I was overzealous with my vxlan ranges in my first configuration and gave
> it a range of 10,000,000 not realizing that would create that many rows in
> the database. Looking into that I saw that pymysql in my cluster takes 3.5
> minutes to retrieve those rows. mysql CLI only takes 4 seconds. Perhaps
> that is just the overhead of pymysql? I've greatly scaled down the vxlan
> range now.
>
> I'm provisioning the 2 servers with a heat template that contains around
> 200 custom resources. For 198 of the resources they are set to
> conditionally not create any OpenStack native resources. Deploying this
> template of mostly no-op resources still takes about 3 minutes.
>
> Horizon works but almost every page load take a few seconds to load. I'm
> not sure if that is normal or not.
>
> Thanks for any help anyone can provide.
>
> john
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/fb2cbca5/attachment.htm>

From bartelme at gmail.com  Tue Apr  4 13:11:58 2023
From: bartelme at gmail.com (John Bartelme)
Date: Tue, 4 Apr 2023 09:11:58 -0400
Subject: [neutron][OpenStack-ansible] Performance issues with trunk ports
In-Reply-To: <CALg0jK=FLJvXpQfcFFf=uRFFdL=tTGLLjox8UiK_RuJ3cWchfA@mail.gmail.com>
References: <CADC88Ce0xV3RytP2yi3+mJQOdtv8F_NuCGgbUu3g2_Z6AT7Jcg@mail.gmail.com>
 <CALg0jK=FLJvXpQfcFFf=uRFFdL=tTGLLjox8UiK_RuJ3cWchfA@mail.gmail.com>
Message-ID: <CADC88CfbA5RQS9MLetr70H60cSZ6u1aTms4Az56MtrMS3kWXuQ@mail.gmail.com>

When you say trunk issue do you mean about the RPC calls going to
uWSGI threads or this general issue with long times.  For the long
times I'm not sure I have enough detail to write a bug but I could for
the RPC calls.

Also I'm using LinuxBridge on the backend.

Thanks, john

On 4/4/23, Lajos Katona <katonalala at gmail.com> wrote:
> Hi,
> could you open a bug report on https://bugs.launchpad.net/neutron/ for the
> trunk issue with reproduction steps?
> It is also important which backend you use? OVS or something else?
>
> Thanks in advance
> Lajos Katona (lajoskatona)
>
> John Bartelme <bartelme at gmail.com> ezt ?rta (id?pont: 2023. ?pr. 4., K,
> 14:15):
>
>> Hello,
>>
>> I'm currently experiencing some pretty severe performance issues with my
>> openstack-ansible deployed cluster(yoga) while deploying trunk ports and
>> I'm looking for some help determining what might be the cause of this
>> poor
>> performance.
>>
>> In my simplest case I'm deploying 2 servers each with one trunk port
>> each.
>> The first trunk has 2 subports and the second 6 subports. Both servers
>> also
>> have 3 other regular ports. When deploying the first trunk port its
>> subports are often provisioned quickly and the second trunk port takes
>> anywhere from 30 seconds to 18 minutes. This happens even when I isolate
>> neutron-server to a single physical machine with 44(88 threads) and 256GB
>> ram. Further diagnosis has shown me some things i didn't quite
>> understand.
>> My deployment with OpenStack-ansible deploys neutron-server with 16 uWSGI
>> processes and neutron-rpc-server with 16 rpc workers. However the way
>> that
>> the trunk RPC server is implemented it is only run on the parent RPC
>> thread
>> and instead runs in all of the uWSGI processes as well. This means that
>> most of my trunk RPC calls are being handled by the uWSGI instead of the
>> RPC workers. When the parent RPC thread handles the trunk port creation
>> calls I constantly see creation times of 1-1.5 seconds. I've isolated it
>> so
>> that this thread does all of the trunk RPC calls and this works quite
>> well
>> but this doesn't seem ideal. What could be causing such poor performance
>> in
>> the uWSGI side of the house? I'm having a really hard time getting a good
>> feeling for what might be slowing it down so much. I'm wondering if it
>> could be green thread preemption but I really don't know. I've tried
>> setting 'enable-threads' false for uWSGI but I don't think that is
>> improving performance. Putting the profiled decorator on
>> update_subport_bindings shows different places taking longer every time,
>> but in general a lot of time(tottime, i.e. not subfunction time) spent in
>> webob/dec.py(__call__), paste/urlmap.py(__call__),
>> webob/request.py(call_application),webob/request.py(send). What else can
>> I
>> do to try and look for why this is taking so long?
>>
>> As a side question it seems counterintuitive that the uWSGI handles most
>> of
>> the trunk RPC calls and not the RPC workers?
>>
>> A couple other notes about my environment that could indicate my
>> challenges:
>>
>> I had to disable rabbitmq heartbeats for neutron as they kept not getting
>> sent reliably and connections were terminated. I tried with
>> heartbeat_in_pthread both true and false but still had issues. It looks
>> like nova also sometimes experiences this but not near as often.
>>
>> I was overzealous with my vxlan ranges in my first configuration and gave
>> it a range of 10,000,000 not realizing that would create that many rows
>> in
>> the database. Looking into that I saw that pymysql in my cluster takes
>> 3.5
>> minutes to retrieve those rows. mysql CLI only takes 4 seconds. Perhaps
>> that is just the overhead of pymysql? I've greatly scaled down the vxlan
>> range now.
>>
>> I'm provisioning the 2 servers with a heat template that contains around
>> 200 custom resources. For 198 of the resources they are set to
>> conditionally not create any OpenStack native resources. Deploying this
>> template of mostly no-op resources still takes about 3 minutes.
>>
>> Horizon works but almost every page load take a few seconds to load. I'm
>> not sure if that is normal or not.
>>
>> Thanks for any help anyone can provide.
>>
>> john
>>
>>
>


From katonalala at gmail.com  Tue Apr  4 13:14:32 2023
From: katonalala at gmail.com (Lajos Katona)
Date: Tue, 4 Apr 2023 15:14:32 +0200
Subject: [neutron][OpenStack-ansible] Performance issues with trunk ports
In-Reply-To: <CADC88CfbA5RQS9MLetr70H60cSZ6u1aTms4Az56MtrMS3kWXuQ@mail.gmail.com>
References: <CADC88Ce0xV3RytP2yi3+mJQOdtv8F_NuCGgbUu3g2_Z6AT7Jcg@mail.gmail.com>
 <CALg0jK=FLJvXpQfcFFf=uRFFdL=tTGLLjox8UiK_RuJ3cWchfA@mail.gmail.com>
 <CADC88CfbA5RQS9MLetr70H60cSZ6u1aTms4Az56MtrMS3kWXuQ@mail.gmail.com>
Message-ID: <CALg0jKkqQ4-v7pgPmeFV7zdu9TbZrvEP9MggpM_3WZx4Q8wdVg@mail.gmail.com>

Hi,
Perfect, please do that.

Lajos

John Bartelme <bartelme at gmail.com> ezt ?rta (id?pont: 2023. ?pr. 4., K,
15:12):

> When you say trunk issue do you mean about the RPC calls going to
> uWSGI threads or this general issue with long times.  For the long
> times I'm not sure I have enough detail to write a bug but I could for
> the RPC calls.
>
> Also I'm using LinuxBridge on the backend.
>
> Thanks, john
>
> On 4/4/23, Lajos Katona <katonalala at gmail.com> wrote:
> > Hi,
> > could you open a bug report on https://bugs.launchpad.net/neutron/ for
> the
> > trunk issue with reproduction steps?
> > It is also important which backend you use? OVS or something else?
> >
> > Thanks in advance
> > Lajos Katona (lajoskatona)
> >
> > John Bartelme <bartelme at gmail.com> ezt ?rta (id?pont: 2023. ?pr. 4., K,
> > 14:15):
> >
> >> Hello,
> >>
> >> I'm currently experiencing some pretty severe performance issues with my
> >> openstack-ansible deployed cluster(yoga) while deploying trunk ports and
> >> I'm looking for some help determining what might be the cause of this
> >> poor
> >> performance.
> >>
> >> In my simplest case I'm deploying 2 servers each with one trunk port
> >> each.
> >> The first trunk has 2 subports and the second 6 subports. Both servers
> >> also
> >> have 3 other regular ports. When deploying the first trunk port its
> >> subports are often provisioned quickly and the second trunk port takes
> >> anywhere from 30 seconds to 18 minutes. This happens even when I isolate
> >> neutron-server to a single physical machine with 44(88 threads) and
> 256GB
> >> ram. Further diagnosis has shown me some things i didn't quite
> >> understand.
> >> My deployment with OpenStack-ansible deploys neutron-server with 16
> uWSGI
> >> processes and neutron-rpc-server with 16 rpc workers. However the way
> >> that
> >> the trunk RPC server is implemented it is only run on the parent RPC
> >> thread
> >> and instead runs in all of the uWSGI processes as well. This means that
> >> most of my trunk RPC calls are being handled by the uWSGI instead of the
> >> RPC workers. When the parent RPC thread handles the trunk port creation
> >> calls I constantly see creation times of 1-1.5 seconds. I've isolated it
> >> so
> >> that this thread does all of the trunk RPC calls and this works quite
> >> well
> >> but this doesn't seem ideal. What could be causing such poor performance
> >> in
> >> the uWSGI side of the house? I'm having a really hard time getting a
> good
> >> feeling for what might be slowing it down so much. I'm wondering if it
> >> could be green thread preemption but I really don't know. I've tried
> >> setting 'enable-threads' false for uWSGI but I don't think that is
> >> improving performance. Putting the profiled decorator on
> >> update_subport_bindings shows different places taking longer every time,
> >> but in general a lot of time(tottime, i.e. not subfunction time) spent
> in
> >> webob/dec.py(__call__), paste/urlmap.py(__call__),
> >> webob/request.py(call_application),webob/request.py(send). What else can
> >> I
> >> do to try and look for why this is taking so long?
> >>
> >> As a side question it seems counterintuitive that the uWSGI handles most
> >> of
> >> the trunk RPC calls and not the RPC workers?
> >>
> >> A couple other notes about my environment that could indicate my
> >> challenges:
> >>
> >> I had to disable rabbitmq heartbeats for neutron as they kept not
> getting
> >> sent reliably and connections were terminated. I tried with
> >> heartbeat_in_pthread both true and false but still had issues. It looks
> >> like nova also sometimes experiences this but not near as often.
> >>
> >> I was overzealous with my vxlan ranges in my first configuration and
> gave
> >> it a range of 10,000,000 not realizing that would create that many rows
> >> in
> >> the database. Looking into that I saw that pymysql in my cluster takes
> >> 3.5
> >> minutes to retrieve those rows. mysql CLI only takes 4 seconds. Perhaps
> >> that is just the overhead of pymysql? I've greatly scaled down the vxlan
> >> range now.
> >>
> >> I'm provisioning the 2 servers with a heat template that contains around
> >> 200 custom resources. For 198 of the resources they are set to
> >> conditionally not create any OpenStack native resources. Deploying this
> >> template of mostly no-op resources still takes about 3 minutes.
> >>
> >> Horizon works but almost every page load take a few seconds to load. I'm
> >> not sure if that is normal or not.
> >>
> >> Thanks for any help anyone can provide.
> >>
> >> john
> >>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/31b30605/attachment-0001.htm>

From satish.txt at gmail.com  Tue Apr  4 13:14:53 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Tue, 4 Apr 2023 09:14:53 -0400
Subject: [kolla-ansible] bootstrap-server docker version question
Message-ID: <CAPgF-frS7FQnQ=QsdWf1qpWJ2mai2NOUPa2GijLvmmp8ovYY2Q@mail.gmail.com>

Folks,

Playing with kolla and i decided to use docker.io installation (ubuntu
20.04) on controller nodes but when i run bootstrap-server it removed
docker.io and installed docker-ce version.

Question:
What is the best docker version to run in production for operator point of
view and better support and stability. docker.io maintained by debian
community and native support with Ubuntu distro. docker-ce is maintained by
the docker community which has better features etc but rapid growth but
does that matter for kolla?

Just curious, what if I add compute nodes in an existing cluster after many
months? In that case the docker-ce version will be changed. How to maintain
or pin docker-ce version?

~S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/e9ba6be8/attachment.htm>

From noonedeadpunk at gmail.com  Tue Apr  4 13:28:29 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Tue, 4 Apr 2023 15:28:29 +0200
Subject: [neutron][OpenStack-ansible] Performance issues with trunk ports
In-Reply-To: <CALg0jKkqQ4-v7pgPmeFV7zdu9TbZrvEP9MggpM_3WZx4Q8wdVg@mail.gmail.com>
References: <CADC88Ce0xV3RytP2yi3+mJQOdtv8F_NuCGgbUu3g2_Z6AT7Jcg@mail.gmail.com>
 <CALg0jK=FLJvXpQfcFFf=uRFFdL=tTGLLjox8UiK_RuJ3cWchfA@mail.gmail.com>
 <CADC88CfbA5RQS9MLetr70H60cSZ6u1aTms4Az56MtrMS3kWXuQ@mail.gmail.com>
 <CALg0jKkqQ4-v7pgPmeFV7zdu9TbZrvEP9MggpM_3WZx4Q8wdVg@mail.gmail.com>
Message-ID: <CAPd_6AsJaZczpa-WJsw7aanmOqmk6rZM5q6tUhF_PXcWUwyDBQ@mail.gmail.com>

Hi John,

Have you tried out of interest to set "neutron_use_uwsgi: false" in your
user_variables.yml and re-run os-neutron-install playbook to see if that
just solves your issue?

You might also need to restart service manually after that as we're having
a known bug (scheduled to be fixed soon) that will skip service restart if
only systemd service file is changed. Not sure if neutron role is affected
or not though, but decided to mention that it might be needed.


??, 4 ???. 2023 ?., 15:19 Lajos Katona <katonalala at gmail.com>:

> Hi,
> Perfect, please do that.
>
> Lajos
>
> John Bartelme <bartelme at gmail.com> ezt ?rta (id?pont: 2023. ?pr. 4., K,
> 15:12):
>
>> When you say trunk issue do you mean about the RPC calls going to
>> uWSGI threads or this general issue with long times.  For the long
>> times I'm not sure I have enough detail to write a bug but I could for
>> the RPC calls.
>>
>> Also I'm using LinuxBridge on the backend.
>>
>> Thanks, john
>>
>> On 4/4/23, Lajos Katona <katonalala at gmail.com> wrote:
>> > Hi,
>> > could you open a bug report on https://bugs.launchpad.net/neutron/ for
>> the
>> > trunk issue with reproduction steps?
>> > It is also important which backend you use? OVS or something else?
>> >
>> > Thanks in advance
>> > Lajos Katona (lajoskatona)
>> >
>> > John Bartelme <bartelme at gmail.com> ezt ?rta (id?pont: 2023. ?pr. 4., K,
>> > 14:15):
>> >
>> >> Hello,
>> >>
>> >> I'm currently experiencing some pretty severe performance issues with
>> my
>> >> openstack-ansible deployed cluster(yoga) while deploying trunk ports
>> and
>> >> I'm looking for some help determining what might be the cause of this
>> >> poor
>> >> performance.
>> >>
>> >> In my simplest case I'm deploying 2 servers each with one trunk port
>> >> each.
>> >> The first trunk has 2 subports and the second 6 subports. Both servers
>> >> also
>> >> have 3 other regular ports. When deploying the first trunk port its
>> >> subports are often provisioned quickly and the second trunk port takes
>> >> anywhere from 30 seconds to 18 minutes. This happens even when I
>> isolate
>> >> neutron-server to a single physical machine with 44(88 threads) and
>> 256GB
>> >> ram. Further diagnosis has shown me some things i didn't quite
>> >> understand.
>> >> My deployment with OpenStack-ansible deploys neutron-server with 16
>> uWSGI
>> >> processes and neutron-rpc-server with 16 rpc workers. However the way
>> >> that
>> >> the trunk RPC server is implemented it is only run on the parent RPC
>> >> thread
>> >> and instead runs in all of the uWSGI processes as well. This means that
>> >> most of my trunk RPC calls are being handled by the uWSGI instead of
>> the
>> >> RPC workers. When the parent RPC thread handles the trunk port creation
>> >> calls I constantly see creation times of 1-1.5 seconds. I've isolated
>> it
>> >> so
>> >> that this thread does all of the trunk RPC calls and this works quite
>> >> well
>> >> but this doesn't seem ideal. What could be causing such poor
>> performance
>> >> in
>> >> the uWSGI side of the house? I'm having a really hard time getting a
>> good
>> >> feeling for what might be slowing it down so much. I'm wondering if it
>> >> could be green thread preemption but I really don't know. I've tried
>> >> setting 'enable-threads' false for uWSGI but I don't think that is
>> >> improving performance. Putting the profiled decorator on
>> >> update_subport_bindings shows different places taking longer every
>> time,
>> >> but in general a lot of time(tottime, i.e. not subfunction time) spent
>> in
>> >> webob/dec.py(__call__), paste/urlmap.py(__call__),
>> >> webob/request.py(call_application),webob/request.py(send). What else
>> can
>> >> I
>> >> do to try and look for why this is taking so long?
>> >>
>> >> As a side question it seems counterintuitive that the uWSGI handles
>> most
>> >> of
>> >> the trunk RPC calls and not the RPC workers?
>> >>
>> >> A couple other notes about my environment that could indicate my
>> >> challenges:
>> >>
>> >> I had to disable rabbitmq heartbeats for neutron as they kept not
>> getting
>> >> sent reliably and connections were terminated. I tried with
>> >> heartbeat_in_pthread both true and false but still had issues. It looks
>> >> like nova also sometimes experiences this but not near as often.
>> >>
>> >> I was overzealous with my vxlan ranges in my first configuration and
>> gave
>> >> it a range of 10,000,000 not realizing that would create that many rows
>> >> in
>> >> the database. Looking into that I saw that pymysql in my cluster takes
>> >> 3.5
>> >> minutes to retrieve those rows. mysql CLI only takes 4 seconds. Perhaps
>> >> that is just the overhead of pymysql? I've greatly scaled down the
>> vxlan
>> >> range now.
>> >>
>> >> I'm provisioning the 2 servers with a heat template that contains
>> around
>> >> 200 custom resources. For 198 of the resources they are set to
>> >> conditionally not create any OpenStack native resources. Deploying this
>> >> template of mostly no-op resources still takes about 3 minutes.
>> >>
>> >> Horizon works but almost every page load take a few seconds to load.
>> I'm
>> >> not sure if that is normal or not.
>> >>
>> >> Thanks for any help anyone can provide.
>> >>
>> >> john
>> >>
>> >>
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/9ebc3946/attachment.htm>

From ralonsoh at redhat.com  Tue Apr  4 13:29:21 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Tue, 4 Apr 2023 15:29:21 +0200
Subject: [neutron][ovn-bgp-agent] Make ovn-bgp-agent a Neutron stadium project
Message-ID: <CAECr9X4ETkE95kuWLjBoHEtfryPJ+LqWNgWqBktwYGwhQijTtg@mail.gmail.com>

Hello all:

During the last PTG, it was discussed and accepted to migrate the
ovn-bgp-agent project [1] to the Neutron stadium umbrella. This mail is a
heads-up for anyone using it. In the next days (maybe today), Lucas will
send the corresponding patches for "governance" and "project-config"
repositories in order to start this migration.

If you have any questions, please ask them in this email or via IRC in the
#openstack-neutron channel.

Regards.

[1]https://opendev.org/x/ovn-bgp-agent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/c13d4dce/attachment.htm>

From maksim.malchuk at gmail.com  Tue Apr  4 13:54:07 2023
From: maksim.malchuk at gmail.com (Maksim Malchuk)
Date: Tue, 4 Apr 2023 16:54:07 +0300
Subject: [kolla-ansible] bootstrap-server docker version question
In-Reply-To: <CAPgF-frS7FQnQ=QsdWf1qpWJ2mai2NOUPa2GijLvmmp8ovYY2Q@mail.gmail.com>
References: <CAPgF-frS7FQnQ=QsdWf1qpWJ2mai2NOUPa2GijLvmmp8ovYY2Q@mail.gmail.com>
Message-ID: <CAE_fguDnG386zvfu6gcwUkKhZg11+UEECOdE-ZWAnYbsr5Y+ug@mail.gmail.com>

Hi Satish,

We used Docker-CE because RedHat based distros don't have Docker packages.
It's fine to use docker.io for Ubuntu instead of docker-ce. It should work
much more stable.


On Tue, Apr 4, 2023 at 4:21?PM Satish Patel <satish.txt at gmail.com> wrote:

> Folks,
>
> Playing with kolla and i decided to use docker.io installation (ubuntu
> 20.04) on controller nodes but when i run bootstrap-server it removed
> docker.io and installed docker-ce version.
>
> Question:
> What is the best docker version to run in production for operator point of
> view and better support and stability. docker.io maintained by debian
> community and native support with Ubuntu distro. docker-ce is maintained by
> the docker community which has better features etc but rapid growth but
> does that matter for kolla?
>
> Just curious, what if I add compute nodes in an existing cluster after
> many months? In that case the docker-ce version will be changed. How to
> maintain or pin docker-ce version?
>
> ~S
>
>
>
>

-- 
Regards,
Maksim Malchuk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/d2aaffb1/attachment-0001.htm>

From beagles at redhat.com  Tue Apr  4 14:07:06 2023
From: beagles at redhat.com (Brent Eagles)
Date: Tue, 4 Apr 2023 11:37:06 -0230
Subject: [tripleo] Nominate dbengt for tripleo-core !
In-Reply-To: <CAEggtay7MKKCUuDzvhhUitv=EgBRZMPjcdQ7cEDpjp0y04+SEg@mail.gmail.com>
References: <CAEggtay7MKKCUuDzvhhUitv=EgBRZMPjcdQ7cEDpjp0y04+SEg@mail.gmail.com>
Message-ID: <ZCwvCt1L1TVyBwUJ@knife.localdomain>

+1

On Mon, Apr 03, 2023 at 06:40:01PM +0200, Lukas Bezdicka wrote:
> Hello,
>
> I'd like to nominate Daniel Bengtsson as tripleo-core. He works in upgrades
> and he'll have to maintain train, wallaby and zed for quite a while. He is
> a long term contributor to tripleo and oslo.
>
> I trust his judgement and I hope you'll support his nomination!
>
> Thanks,
> Lukas Bezdicka



From gregory.orange at pawsey.org.au  Tue Apr  4 14:16:46 2023
From: gregory.orange at pawsey.org.au (Gregory Orange)
Date: Tue, 4 Apr 2023 22:16:46 +0800
Subject: [kolla-ansible] bootstrap-server docker version question
In-Reply-To: <CAPgF-frS7FQnQ=QsdWf1qpWJ2mai2NOUPa2GijLvmmp8ovYY2Q@mail.gmail.com>
References: <CAPgF-frS7FQnQ=QsdWf1qpWJ2mai2NOUPa2GijLvmmp8ovYY2Q@mail.gmail.com>
Message-ID: <483a2891-10de-9eb8-723f-5e2f2f9aa3d0@pawsey.org.au>

On 4/4/23 21:14, Satish Patel wrote:
> Just curious, what if I add compute nodes in an existing cluster after 
> many months? In that case the docker-ce version will be changed. How to 
> maintain or pin docker-ce version?

Aptly has been useful to us for a few years, for various Ubuntu packages 
we want to pin. We also use apt-mirror but that's a simpler tool without 
the snapshot and publish features of aptly.


From dwilde at redhat.com  Tue Apr  4 14:34:04 2023
From: dwilde at redhat.com (Dave Wilde)
Date: Tue, 4 Apr 2023 09:34:04 -0500
Subject: [keystone] Weekly Meeting Cancelled (04-Apr 2023)
Message-ID: <9e74add8-bc96-4c0f-b311-83cb203fde14@Spark>

Hi folks,

I'm cancelling the Keystone weekly meeting this week (04-Apr 2023) due to a conflict that I have.??Please reach out to me on IRC or via email if you need anything.

Thanks!

/Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/5d7c08a8/attachment.htm>

From eblock at nde.ag  Tue Apr  4 14:34:28 2023
From: eblock at nde.ag (Eugen Block)
Date: Tue, 04 Apr 2023 14:34:28 +0000
Subject: [openstackclient] openstack cli broken after update to Wallaby
Message-ID: <20230404143428.Horde.MIPd5a2pT3yB3Ki3PoJBmOt@webmail.nde.ag>

Hi *,

today I upgraded my virtual test environment from V to W when (Ubuntu  
20.04) all of a sudden cli commands didn't work anymore with this  
stack trace:

---snip---
root at control01:~# openstack network agent list
Traceback (most recent call last):
   File "/usr/bin/openstack", line 6, in <module>
     from openstackclient.shell import main
   File "/usr/lib/python3/dist-packages/openstackclient/shell.py",  
line 23, in <module>
     from osc_lib import shell
   File "/usr/lib/python3/dist-packages/osc_lib/shell.py", line 24, in <module>
     from cliff import app
   File "/usr/lib/python3/dist-packages/cliff/app.py", line 22, in <module>
     import cmd2
   File "/usr/lib/python3/dist-packages/cmd2.py", line 585, in <module>
     _ = pyperclip.paste()
   File "/usr/lib/python3/dist-packages/pyperclip/__init__.py", line  
667, in lazy_load_stub_paste
     copy, paste = determine_clipboard()
   File "/usr/lib/python3/dist-packages/pyperclip/__init__.py", line  
558, in determine_clipboard
     return init_gi_clipboard()
   File "/usr/lib/python3/dist-packages/pyperclip/__init__.py", line  
167, in init_gi_clipboard
     gi.require_version('Gtk', '3.0')
   File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in  
require_version
     raise ValueError('Namespace %s not available' % namespace)
ValueError: Namespace Gtk not available
---snip---

I found this bug [1] describing the same issue but there has been no  
progress. I posted my comments there as well. I found one way to get  
the openstack shell to work by installing libgtk-3-dev (I found a hint  
in a search engine). Apparently, python3-cmd2 requires  
python3-pyperclip which requires python3-gi and so on. Is this really  
the desired way? I didn't notice anything in the release notes (maybe  
I missed it). When comparing to a different environment (Victoria on  
baremetal) I see that libgtk-3 is installed there (not -dev though),  
but even with libgtk-3-0 the error message was still present. So the  
question is, which dependencies are missing where? It's not really  
obvious to me. Could this already be fixed in Xena? If it is fixed  
there I could do the double upgrade, of course, especially since  
Wallaby is already under extended maintenance. Any comments are  
appreciated.

Thanks,
Eugen

[1]  
https://bugs.launchpad.net/ubuntu/+source/python-openstackclient/+bug/1945661



From satish.txt at gmail.com  Tue Apr  4 14:37:39 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Tue, 4 Apr 2023 10:37:39 -0400
Subject: [kolla-ansible] bootstrap-server docker version question
In-Reply-To: <CAE_fguDnG386zvfu6gcwUkKhZg11+UEECOdE-ZWAnYbsr5Y+ug@mail.gmail.com>
References: <CAPgF-frS7FQnQ=QsdWf1qpWJ2mai2NOUPa2GijLvmmp8ovYY2Q@mail.gmail.com>
 <CAE_fguDnG386zvfu6gcwUkKhZg11+UEECOdE-ZWAnYbsr5Y+ug@mail.gmail.com>
Message-ID: <CAPgF-fovY_b2CtuP=6KJyH3qhn4iffZRS8M0skQj2dRnAL5rOg@mail.gmail.com>

Thank Maksim,

How do i tell bootstrap-server to don't use docker-ce and just use docker.io?
are there any setting to tell?

On Tue, Apr 4, 2023 at 9:54?AM Maksim Malchuk <maksim.malchuk at gmail.com>
wrote:

> Hi Satish,
>
> We used Docker-CE because RedHat based distros don't have Docker packages.
> It's fine to use docker.io for Ubuntu instead of docker-ce. It should
> work much more stable.
>
>
> On Tue, Apr 4, 2023 at 4:21?PM Satish Patel <satish.txt at gmail.com> wrote:
>
>> Folks,
>>
>> Playing with kolla and i decided to use docker.io installation (ubuntu
>> 20.04) on controller nodes but when i run bootstrap-server it removed
>> docker.io and installed docker-ce version.
>>
>> Question:
>> What is the best docker version to run in production for operator point
>> of view and better support and stability. docker.io maintained by debian
>> community and native support with Ubuntu distro. docker-ce is maintained by
>> the docker community which has better features etc but rapid growth but
>> does that matter for kolla?
>>
>> Just curious, what if I add compute nodes in an existing cluster after
>> many months? In that case the docker-ce version will be changed. How to
>> maintain or pin docker-ce version?
>>
>> ~S
>>
>>
>>
>>
>
> --
> Regards,
> Maksim Malchuk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/0d3d7891/attachment.htm>

From bartelme at gmail.com  Tue Apr  4 14:43:32 2023
From: bartelme at gmail.com (John Bartelme)
Date: Tue, 4 Apr 2023 10:43:32 -0400
Subject: [neutron][OpenStack-ansible] Performance issues with trunk ports
In-Reply-To: <CALg0jKkqQ4-v7pgPmeFV7zdu9TbZrvEP9MggpM_3WZx4Q8wdVg@mail.gmail.com>
References: <CADC88Ce0xV3RytP2yi3+mJQOdtv8F_NuCGgbUu3g2_Z6AT7Jcg@mail.gmail.com>
 <CALg0jK=FLJvXpQfcFFf=uRFFdL=tTGLLjox8UiK_RuJ3cWchfA@mail.gmail.com>
 <CADC88CfbA5RQS9MLetr70H60cSZ6u1aTms4Az56MtrMS3kWXuQ@mail.gmail.com>
 <CALg0jKkqQ4-v7pgPmeFV7zdu9TbZrvEP9MggpM_3WZx4Q8wdVg@mail.gmail.com>
Message-ID: <CADC88CcMyaF2eoH5ryKO1PN9fM7a76ufp2JtKcOTmF5CoUorXQ@mail.gmail.com>

Dmitriy wrote:
> Have you tried out of interest to set "neutron_use_uwsgi: false" in your user_variables.yml

     Thank you for that suggestion.  I did think about changing that
option but reading up on some of the change logs it looked like
everything is trying to be migrated over to uWSGI.  When I set that
option things are indeed much better.  The update_subport_bindings RPC
call is still not being handled by the RPC worker threads but the
neutron-server parent thread is able to handle the calls and much more
quickly than the uWSGI threads were, i.e. in that 1-2 second
timeframe.   What are the ramifications of not using uWSGI?  Is this
an ok configuration for a production deployment?  Are there any
thoughts as to why the uWSGI threads are having such performance
issues?  Thanks so much for all of the help.

     I?ll continue to write up a bug for RPC threads not handling
update_subport_bindings calls and for uWSGI handling them which may be
unexpected.

     Thanks, john

On 4/4/23, Lajos Katona <katonalala at gmail.com> wrote:
> Hi,
> Perfect, please do that.
>
> Lajos
>
> John Bartelme <bartelme at gmail.com> ezt ?rta (id?pont: 2023. ?pr. 4., K,
> 15:12):
>
>> When you say trunk issue do you mean about the RPC calls going to
>> uWSGI threads or this general issue with long times.  For the long
>> times I'm not sure I have enough detail to write a bug but I could for
>> the RPC calls.
>>
>> Also I'm using LinuxBridge on the backend.
>>
>> Thanks, john
>>
>> On 4/4/23, Lajos Katona <katonalala at gmail.com> wrote:
>> > Hi,
>> > could you open a bug report on https://bugs.launchpad.net/neutron/ for
>> the
>> > trunk issue with reproduction steps?
>> > It is also important which backend you use? OVS or something else?
>> >
>> > Thanks in advance
>> > Lajos Katona (lajoskatona)
>> >
>> > John Bartelme <bartelme at gmail.com> ezt ?rta (id?pont: 2023. ?pr. 4., K,
>> > 14:15):
>> >
>> >> Hello,
>> >>
>> >> I'm currently experiencing some pretty severe performance issues with
>> >> my
>> >> openstack-ansible deployed cluster(yoga) while deploying trunk ports
>> >> and
>> >> I'm looking for some help determining what might be the cause of this
>> >> poor
>> >> performance.
>> >>
>> >> In my simplest case I'm deploying 2 servers each with one trunk port
>> >> each.
>> >> The first trunk has 2 subports and the second 6 subports. Both servers
>> >> also
>> >> have 3 other regular ports. When deploying the first trunk port its
>> >> subports are often provisioned quickly and the second trunk port takes
>> >> anywhere from 30 seconds to 18 minutes. This happens even when I
>> >> isolate
>> >> neutron-server to a single physical machine with 44(88 threads) and
>> 256GB
>> >> ram. Further diagnosis has shown me some things i didn't quite
>> >> understand.
>> >> My deployment with OpenStack-ansible deploys neutron-server with 16
>> uWSGI
>> >> processes and neutron-rpc-server with 16 rpc workers. However the way
>> >> that
>> >> the trunk RPC server is implemented it is only run on the parent RPC
>> >> thread
>> >> and instead runs in all of the uWSGI processes as well. This means
>> >> that
>> >> most of my trunk RPC calls are being handled by the uWSGI instead of
>> >> the
>> >> RPC workers. When the parent RPC thread handles the trunk port
>> >> creation
>> >> calls I constantly see creation times of 1-1.5 seconds. I've isolated
>> >> it
>> >> so
>> >> that this thread does all of the trunk RPC calls and this works quite
>> >> well
>> >> but this doesn't seem ideal. What could be causing such poor
>> >> performance
>> >> in
>> >> the uWSGI side of the house? I'm having a really hard time getting a
>> good
>> >> feeling for what might be slowing it down so much. I'm wondering if it
>> >> could be green thread preemption but I really don't know. I've tried
>> >> setting 'enable-threads' false for uWSGI but I don't think that is
>> >> improving performance. Putting the profiled decorator on
>> >> update_subport_bindings shows different places taking longer every
>> >> time,
>> >> but in general a lot of time(tottime, i.e. not subfunction time) spent
>> in
>> >> webob/dec.py(__call__), paste/urlmap.py(__call__),
>> >> webob/request.py(call_application),webob/request.py(send). What else
>> >> can
>> >> I
>> >> do to try and look for why this is taking so long?
>> >>
>> >> As a side question it seems counterintuitive that the uWSGI handles
>> >> most
>> >> of
>> >> the trunk RPC calls and not the RPC workers?
>> >>
>> >> A couple other notes about my environment that could indicate my
>> >> challenges:
>> >>
>> >> I had to disable rabbitmq heartbeats for neutron as they kept not
>> getting
>> >> sent reliably and connections were terminated. I tried with
>> >> heartbeat_in_pthread both true and false but still had issues. It
>> >> looks
>> >> like nova also sometimes experiences this but not near as often.
>> >>
>> >> I was overzealous with my vxlan ranges in my first configuration and
>> gave
>> >> it a range of 10,000,000 not realizing that would create that many
>> >> rows
>> >> in
>> >> the database. Looking into that I saw that pymysql in my cluster takes
>> >> 3.5
>> >> minutes to retrieve those rows. mysql CLI only takes 4 seconds.
>> >> Perhaps
>> >> that is just the overhead of pymysql? I've greatly scaled down the
>> >> vxlan
>> >> range now.
>> >>
>> >> I'm provisioning the 2 servers with a heat template that contains
>> >> around
>> >> 200 custom resources. For 198 of the resources they are set to
>> >> conditionally not create any OpenStack native resources. Deploying
>> >> this
>> >> template of mostly no-op resources still takes about 3 minutes.
>> >>
>> >> Horizon works but almost every page load take a few seconds to load.
>> >> I'm
>> >> not sure if that is normal or not.
>> >>
>> >> Thanks for any help anyone can provide.
>> >>
>> >> john
>> >>
>> >>
>> >
>>
>


From maksim.malchuk at gmail.com  Tue Apr  4 15:06:49 2023
From: maksim.malchuk at gmail.com (Maksim Malchuk)
Date: Tue, 4 Apr 2023 18:06:49 +0300
Subject: [kolla-ansible] bootstrap-server docker version question
In-Reply-To: <CAPgF-fovY_b2CtuP=6KJyH3qhn4iffZRS8M0skQj2dRnAL5rOg@mail.gmail.com>
References: <CAPgF-frS7FQnQ=QsdWf1qpWJ2mai2NOUPa2GijLvmmp8ovYY2Q@mail.gmail.com>
 <CAE_fguDnG386zvfu6gcwUkKhZg11+UEECOdE-ZWAnYbsr5Y+ug@mail.gmail.com>
 <CAPgF-fovY_b2CtuP=6KJyH3qhn4iffZRS8M0skQj2dRnAL5rOg@mail.gmail.com>
Message-ID: <CAE_fguAo0H5AMwkS3ck=d_gHcjZqqsxC_wE3B0__-7xO_NSw4A@mail.gmail.com>

Satish, you should change atl east these defaults:

# Docker APT repository configuration.
docker_apt_url: "https://download.docker.com/linux/{{
ansible_facts.distribution | lower }}"
docker_apt_repo: "deb {{ docker_apt_url }} {{
ansible_facts.distribution_release }} stable"
docker_apt_key_file: "gpg"
docker_apt_key_id: "0EBFCD88"
docker_apt_package: "docker-ce"

On Tue, Apr 4, 2023 at 5:37?PM Satish Patel <satish.txt at gmail.com> wrote:

> Thank Maksim,
>
> How do i tell bootstrap-server to don't use docker-ce and just use
> docker.io? are there any setting to tell?
>
> On Tue, Apr 4, 2023 at 9:54?AM Maksim Malchuk <maksim.malchuk at gmail.com>
> wrote:
>
>> Hi Satish,
>>
>> We used Docker-CE because RedHat based distros don't have Docker
>> packages. It's fine to use docker.io for Ubuntu instead of docker-ce. It
>> should work much more stable.
>>
>>
>> On Tue, Apr 4, 2023 at 4:21?PM Satish Patel <satish.txt at gmail.com> wrote:
>>
>>> Folks,
>>>
>>> Playing with kolla and i decided to use docker.io installation (ubuntu
>>> 20.04) on controller nodes but when i run bootstrap-server it removed
>>> docker.io and installed docker-ce version.
>>>
>>> Question:
>>> What is the best docker version to run in production for operator point
>>> of view and better support and stability. docker.io maintained by
>>> debian community and native support with Ubuntu distro. docker-ce is
>>> maintained by the docker community which has better features etc but rapid
>>> growth but does that matter for kolla?
>>>
>>> Just curious, what if I add compute nodes in an existing cluster after
>>> many months? In that case the docker-ce version will be changed. How to
>>> maintain or pin docker-ce version?
>>>
>>> ~S
>>>
>>>
>>>
>>>
>>
>> --
>> Regards,
>> Maksim Malchuk
>>
>>

-- 
Regards,
Maksim Malchuk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/91481a89/attachment.htm>

From gregory.orange at pawsey.org.au  Tue Apr  4 15:09:41 2023
From: gregory.orange at pawsey.org.au (Gregory Orange)
Date: Tue, 4 Apr 2023 23:09:41 +0800
Subject: [kolla-ansible] bootstrap-server docker version question
In-Reply-To: <CAPgF-fovY_b2CtuP=6KJyH3qhn4iffZRS8M0skQj2dRnAL5rOg@mail.gmail.com>
References: <CAPgF-frS7FQnQ=QsdWf1qpWJ2mai2NOUPa2GijLvmmp8ovYY2Q@mail.gmail.com>
 <CAE_fguDnG386zvfu6gcwUkKhZg11+UEECOdE-ZWAnYbsr5Y+ug@mail.gmail.com>
 <CAPgF-fovY_b2CtuP=6KJyH3qhn4iffZRS8M0skQj2dRnAL5rOg@mail.gmail.com>
Message-ID: <cd945940-7169-9cfd-a03e-d7a6089d4a30@pawsey.org.au>

On 4/4/23 22:37, Satish Patel wrote:
> How do i tell bootstrap-server to don't use docker-ce and just use 
> docker.io <http://docker.io>? are there any setting to tell?

A quick grep (well, ack) through /usr/local/share/kolla-ansible showed 
me this:

ansible/roles/baremetal/defaults/main.yml
10:docker_apt_package: "docker-ce"
19:docker_yum_package: "docker-ce"

So I would say try changing that variable in your globals.yml and see if 
that does the trick.


From jay at gr-oss.io  Tue Apr  4 15:34:05 2023
From: jay at gr-oss.io (Jay Faulkner)
Date: Tue, 4 Apr 2023 08:34:05 -0700
Subject: [ironic] ARM Support in CI: Call for vendors / contributors /
 interested parties
In-Reply-To: <CA+eLJkbS6qh+cMQy_TvUgn-RTxcQa9wxZmQTx7X+AiNoCNXqZQ@mail.gmail.com>
References: <CA+sTGNfqAzE=bR16oXwBFyObKV8iz_RVkyB43t-ZemftdHsESQ@mail.gmail.com>
 <GV0P278MB09264C3EB7752AD0354DAFB9EF929@GV0P278MB0926.CHEP278.PROD.OUTLOOK.COM>
 <CA+eLJkbS6qh+cMQy_TvUgn-RTxcQa9wxZmQTx7X+AiNoCNXqZQ@mail.gmail.com>
Message-ID: <CA+sTGNfD7+w9F-rvxi5D=p4ma4ARF_86D+7T7NMJedWRgUscfQ@mail.gmail.com>

Thanks Alvaro, I'll look forward to meeting you and Luis!

In addition to all the activity on the list, Ironic also had a contributor
come and volunteer to help setup VM-based ARM CI on IRC.

We still are looking for contributors, but now there's a much stronger
emphasis on getting third party CI.

Thank you to the community for responding positively for this call to help!

--
Jay Faulkner
Ironic PTL

On Mon, Apr 3, 2023 at 4:39?PM Alvaro Soto <alsotoes at gmail.com> wrote:

> Hey ironic team,
> I'm adding Luis Felipe who is R&D manager at IDTOLU and it's interested in
> helping with this project \o/
> I hope it helps!
>
> Cheers!
>
> On Mon, Apr 3, 2023 at 5:39?AM Arne Wiebalck <Arne.Wiebalck at cern.ch>
> wrote:
>
>> Jay,
>>
>> We have our ARM servers fully managed by Ironic as well (via the Redfish
>> driver),
>> including auto-discovery, benchmarking, burn-in and provisioning. They
>> are set
>> up as hypervisors and we provision ARM VMs on them to our users.
>>
>> We do not use the upstream IPA image, but build our own with IPAB (on an
>> ARM
>> based runner).
>>
>> Cheers,
>>  Arne
>>
>> ________________________________________
>> From: Jay Faulkner <jay at gr-oss.io>
>> Sent: Wednesday, 29 March 2023 20:39
>> To: OpenStack Discuss
>> Subject: [ironic] ARM Support in CI: Call for vendors / contributors /
>> interested parties
>>
>> Hi stackers,
>>
>> Ironic has published an experimental Ironic Python Agent image for ARM64 (
>> https://tarballs.opendev.org/openstack/ironic-python-agent-builder/dib/files/)
>> and discussed promoting this image to supported via CI testing. However, we
>> have a problem: there are no Ironic developers with easy access to ARM
>> hardware at the moment, and no Ironic developers with free time to commit
>> to improving our support of ARM hardware.
>>
>> So we're putting out a call for help:
>> - If you're a hardware vendor and want your ARM hardware supported?
>> Please come talk to the Ironic community about setting up third-party-CI.
>> - Are you an operator or contributor from a company invested in ARM bare
>> metal? Please come join the Ironic community to help us build this support.
>>
>> Thanks,
>> Jay Faulkner
>> Ironic PTL
>>
>>
>>
>>
>
> --
>
> Alvaro Soto
>
> *Note: My work hours may not be your work hours. Please do not feel the
> need to respond during a time that is not convenient for you.*
> ----------------------------------------------------------
> Great people talk about ideas,
> ordinary people talk about things,
> small people talk... about other people.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/8e6e1f0f/attachment.htm>

From bartelme at gmail.com  Tue Apr  4 16:06:48 2023
From: bartelme at gmail.com (John Bartelme)
Date: Tue, 4 Apr 2023 12:06:48 -0400
Subject: [neutron][OpenStack-ansible] Performance issues with trunk ports
In-Reply-To: <CALg0jKkqQ4-v7pgPmeFV7zdu9TbZrvEP9MggpM_3WZx4Q8wdVg@mail.gmail.com>
References: <CADC88Ce0xV3RytP2yi3+mJQOdtv8F_NuCGgbUu3g2_Z6AT7Jcg@mail.gmail.com>
 <CALg0jK=FLJvXpQfcFFf=uRFFdL=tTGLLjox8UiK_RuJ3cWchfA@mail.gmail.com>
 <CADC88CfbA5RQS9MLetr70H60cSZ6u1aTms4Az56MtrMS3kWXuQ@mail.gmail.com>
 <CALg0jKkqQ4-v7pgPmeFV7zdu9TbZrvEP9MggpM_3WZx4Q8wdVg@mail.gmail.com>
Message-ID: <CADC88CcLMZgS6WJiBYT8VwWCGY2Z4QAB=aH6rdb2E+5FBmJjEg@mail.gmail.com>

Hi Lajos,

I've created https://bugs.launchpad.net/neutron/+bug/2015275.  Please
let me know if you have any questions or concerns.

Thanks, john

On 4/4/23, Lajos Katona <katonalala at gmail.com> wrote:
> Hi,
> Perfect, please do that.
>
> Lajos
>
> John Bartelme <bartelme at gmail.com> ezt ?rta (id?pont: 2023. ?pr. 4., K,
> 15:12):
>
>> When you say trunk issue do you mean about the RPC calls going to
>> uWSGI threads or this general issue with long times.  For the long
>> times I'm not sure I have enough detail to write a bug but I could for
>> the RPC calls.
>>
>> Also I'm using LinuxBridge on the backend.
>>
>> Thanks, john
>>
>> On 4/4/23, Lajos Katona <katonalala at gmail.com> wrote:
>> > Hi,
>> > could you open a bug report on https://bugs.launchpad.net/neutron/ for
>> the
>> > trunk issue with reproduction steps?
>> > It is also important which backend you use? OVS or something else?
>> >
>> > Thanks in advance
>> > Lajos Katona (lajoskatona)
>> >
>> > John Bartelme <bartelme at gmail.com> ezt ?rta (id?pont: 2023. ?pr. 4., K,
>> > 14:15):
>> >
>> >> Hello,
>> >>
>> >> I'm currently experiencing some pretty severe performance issues with
>> >> my
>> >> openstack-ansible deployed cluster(yoga) while deploying trunk ports
>> >> and
>> >> I'm looking for some help determining what might be the cause of this
>> >> poor
>> >> performance.
>> >>
>> >> In my simplest case I'm deploying 2 servers each with one trunk port
>> >> each.
>> >> The first trunk has 2 subports and the second 6 subports. Both servers
>> >> also
>> >> have 3 other regular ports. When deploying the first trunk port its
>> >> subports are often provisioned quickly and the second trunk port takes
>> >> anywhere from 30 seconds to 18 minutes. This happens even when I
>> >> isolate
>> >> neutron-server to a single physical machine with 44(88 threads) and
>> 256GB
>> >> ram. Further diagnosis has shown me some things i didn't quite
>> >> understand.
>> >> My deployment with OpenStack-ansible deploys neutron-server with 16
>> uWSGI
>> >> processes and neutron-rpc-server with 16 rpc workers. However the way
>> >> that
>> >> the trunk RPC server is implemented it is only run on the parent RPC
>> >> thread
>> >> and instead runs in all of the uWSGI processes as well. This means
>> >> that
>> >> most of my trunk RPC calls are being handled by the uWSGI instead of
>> >> the
>> >> RPC workers. When the parent RPC thread handles the trunk port
>> >> creation
>> >> calls I constantly see creation times of 1-1.5 seconds. I've isolated
>> >> it
>> >> so
>> >> that this thread does all of the trunk RPC calls and this works quite
>> >> well
>> >> but this doesn't seem ideal. What could be causing such poor
>> >> performance
>> >> in
>> >> the uWSGI side of the house? I'm having a really hard time getting a
>> good
>> >> feeling for what might be slowing it down so much. I'm wondering if it
>> >> could be green thread preemption but I really don't know. I've tried
>> >> setting 'enable-threads' false for uWSGI but I don't think that is
>> >> improving performance. Putting the profiled decorator on
>> >> update_subport_bindings shows different places taking longer every
>> >> time,
>> >> but in general a lot of time(tottime, i.e. not subfunction time) spent
>> in
>> >> webob/dec.py(__call__), paste/urlmap.py(__call__),
>> >> webob/request.py(call_application),webob/request.py(send). What else
>> >> can
>> >> I
>> >> do to try and look for why this is taking so long?
>> >>
>> >> As a side question it seems counterintuitive that the uWSGI handles
>> >> most
>> >> of
>> >> the trunk RPC calls and not the RPC workers?
>> >>
>> >> A couple other notes about my environment that could indicate my
>> >> challenges:
>> >>
>> >> I had to disable rabbitmq heartbeats for neutron as they kept not
>> getting
>> >> sent reliably and connections were terminated. I tried with
>> >> heartbeat_in_pthread both true and false but still had issues. It
>> >> looks
>> >> like nova also sometimes experiences this but not near as often.
>> >>
>> >> I was overzealous with my vxlan ranges in my first configuration and
>> gave
>> >> it a range of 10,000,000 not realizing that would create that many
>> >> rows
>> >> in
>> >> the database. Looking into that I saw that pymysql in my cluster takes
>> >> 3.5
>> >> minutes to retrieve those rows. mysql CLI only takes 4 seconds.
>> >> Perhaps
>> >> that is just the overhead of pymysql? I've greatly scaled down the
>> >> vxlan
>> >> range now.
>> >>
>> >> I'm provisioning the 2 servers with a heat template that contains
>> >> around
>> >> 200 custom resources. For 198 of the resources they are set to
>> >> conditionally not create any OpenStack native resources. Deploying
>> >> this
>> >> template of mostly no-op resources still takes about 3 minutes.
>> >>
>> >> Horizon works but almost every page load take a few seconds to load.
>> >> I'm
>> >> not sure if that is normal or not.
>> >>
>> >> Thanks for any help anyone can provide.
>> >>
>> >> john
>> >>
>> >>
>> >
>>
>


From noonedeadpunk at gmail.com  Tue Apr  4 16:08:35 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Tue, 4 Apr 2023 18:08:35 +0200
Subject: [neutron][OpenStack-ansible] Performance issues with trunk ports
In-Reply-To: <CADC88CcMyaF2eoH5ryKO1PN9fM7a76ufp2JtKcOTmF5CoUorXQ@mail.gmail.com>
References: <CADC88Ce0xV3RytP2yi3+mJQOdtv8F_NuCGgbUu3g2_Z6AT7Jcg@mail.gmail.com>
 <CALg0jK=FLJvXpQfcFFf=uRFFdL=tTGLLjox8UiK_RuJ3cWchfA@mail.gmail.com>
 <CADC88CfbA5RQS9MLetr70H60cSZ6u1aTms4Az56MtrMS3kWXuQ@mail.gmail.com>
 <CALg0jKkqQ4-v7pgPmeFV7zdu9TbZrvEP9MggpM_3WZx4Q8wdVg@mail.gmail.com>
 <CADC88CcMyaF2eoH5ryKO1PN9fM7a76ufp2JtKcOTmF5CoUorXQ@mail.gmail.com>
Message-ID: <CAPd_6AvrRS8b_ZQvHXmjJwO46wjb05z9Oc3Pk9aOafse=T8ZKA@mail.gmail.com>

Yes, totally, that would be great to sort out why using uWSGI make
such difference in performance. I was just trying to provide you with
a fix solution in the meantime, if its needed and affecting your
production deployment.

Also, if neutron_use_uwsgi is set to false, neutron-rpc-server should
be stopped as this service is not used for scenario without uWSGI at
all. Though I can imagine having a bug in OpenStack-Ansible that we
leave neutron-rpc-server running when switching from uwsgi to
eventlet, despite it not needed for that scenario.

In addition to that, I'm not sure about the current state, but during
Zed uWSGI known not to work at all with OVN driver, for instance. It
could be fixed now though.

??, 4 ???. 2023??. ? 16:47, John Bartelme <bartelme at gmail.com>:
>
> Dmitriy wrote:
> > Have you tried out of interest to set "neutron_use_uwsgi: false" in your user_variables.yml
>
>      Thank you for that suggestion.  I did think about changing that
> option but reading up on some of the change logs it looked like
> everything is trying to be migrated over to uWSGI.  When I set that
> option things are indeed much better.  The update_subport_bindings RPC
> call is still not being handled by the RPC worker threads but the
> neutron-server parent thread is able to handle the calls and much more
> quickly than the uWSGI threads were, i.e. in that 1-2 second
> timeframe.   What are the ramifications of not using uWSGI?  Is this
> an ok configuration for a production deployment?  Are there any
> thoughts as to why the uWSGI threads are having such performance
> issues?  Thanks so much for all of the help.
>
>      I?ll continue to write up a bug for RPC threads not handling
> update_subport_bindings calls and for uWSGI handling them which may be
> unexpected.
>
>      Thanks, john
>
> On 4/4/23, Lajos Katona <katonalala at gmail.com> wrote:
> > Hi,
> > Perfect, please do that.
> >
> > Lajos
> >
> > John Bartelme <bartelme at gmail.com> ezt ?rta (id?pont: 2023. ?pr. 4., K,
> > 15:12):
> >
> >> When you say trunk issue do you mean about the RPC calls going to
> >> uWSGI threads or this general issue with long times.  For the long
> >> times I'm not sure I have enough detail to write a bug but I could for
> >> the RPC calls.
> >>
> >> Also I'm using LinuxBridge on the backend.
> >>
> >> Thanks, john
> >>
> >> On 4/4/23, Lajos Katona <katonalala at gmail.com> wrote:
> >> > Hi,
> >> > could you open a bug report on https://bugs.launchpad.net/neutron/ for
> >> the
> >> > trunk issue with reproduction steps?
> >> > It is also important which backend you use? OVS or something else?
> >> >
> >> > Thanks in advance
> >> > Lajos Katona (lajoskatona)
> >> >
> >> > John Bartelme <bartelme at gmail.com> ezt ?rta (id?pont: 2023. ?pr. 4., K,
> >> > 14:15):
> >> >
> >> >> Hello,
> >> >>
> >> >> I'm currently experiencing some pretty severe performance issues with
> >> >> my
> >> >> openstack-ansible deployed cluster(yoga) while deploying trunk ports
> >> >> and
> >> >> I'm looking for some help determining what might be the cause of this
> >> >> poor
> >> >> performance.
> >> >>
> >> >> In my simplest case I'm deploying 2 servers each with one trunk port
> >> >> each.
> >> >> The first trunk has 2 subports and the second 6 subports. Both servers
> >> >> also
> >> >> have 3 other regular ports. When deploying the first trunk port its
> >> >> subports are often provisioned quickly and the second trunk port takes
> >> >> anywhere from 30 seconds to 18 minutes. This happens even when I
> >> >> isolate
> >> >> neutron-server to a single physical machine with 44(88 threads) and
> >> 256GB
> >> >> ram. Further diagnosis has shown me some things i didn't quite
> >> >> understand.
> >> >> My deployment with OpenStack-ansible deploys neutron-server with 16
> >> uWSGI
> >> >> processes and neutron-rpc-server with 16 rpc workers. However the way
> >> >> that
> >> >> the trunk RPC server is implemented it is only run on the parent RPC
> >> >> thread
> >> >> and instead runs in all of the uWSGI processes as well. This means
> >> >> that
> >> >> most of my trunk RPC calls are being handled by the uWSGI instead of
> >> >> the
> >> >> RPC workers. When the parent RPC thread handles the trunk port
> >> >> creation
> >> >> calls I constantly see creation times of 1-1.5 seconds. I've isolated
> >> >> it
> >> >> so
> >> >> that this thread does all of the trunk RPC calls and this works quite
> >> >> well
> >> >> but this doesn't seem ideal. What could be causing such poor
> >> >> performance
> >> >> in
> >> >> the uWSGI side of the house? I'm having a really hard time getting a
> >> good
> >> >> feeling for what might be slowing it down so much. I'm wondering if it
> >> >> could be green thread preemption but I really don't know. I've tried
> >> >> setting 'enable-threads' false for uWSGI but I don't think that is
> >> >> improving performance. Putting the profiled decorator on
> >> >> update_subport_bindings shows different places taking longer every
> >> >> time,
> >> >> but in general a lot of time(tottime, i.e. not subfunction time) spent
> >> in
> >> >> webob/dec.py(__call__), paste/urlmap.py(__call__),
> >> >> webob/request.py(call_application),webob/request.py(send). What else
> >> >> can
> >> >> I
> >> >> do to try and look for why this is taking so long?
> >> >>
> >> >> As a side question it seems counterintuitive that the uWSGI handles
> >> >> most
> >> >> of
> >> >> the trunk RPC calls and not the RPC workers?
> >> >>
> >> >> A couple other notes about my environment that could indicate my
> >> >> challenges:
> >> >>
> >> >> I had to disable rabbitmq heartbeats for neutron as they kept not
> >> getting
> >> >> sent reliably and connections were terminated. I tried with
> >> >> heartbeat_in_pthread both true and false but still had issues. It
> >> >> looks
> >> >> like nova also sometimes experiences this but not near as often.
> >> >>
> >> >> I was overzealous with my vxlan ranges in my first configuration and
> >> gave
> >> >> it a range of 10,000,000 not realizing that would create that many
> >> >> rows
> >> >> in
> >> >> the database. Looking into that I saw that pymysql in my cluster takes
> >> >> 3.5
> >> >> minutes to retrieve those rows. mysql CLI only takes 4 seconds.
> >> >> Perhaps
> >> >> that is just the overhead of pymysql? I've greatly scaled down the
> >> >> vxlan
> >> >> range now.
> >> >>
> >> >> I'm provisioning the 2 servers with a heat template that contains
> >> >> around
> >> >> 200 custom resources. For 198 of the resources they are set to
> >> >> conditionally not create any OpenStack native resources. Deploying
> >> >> this
> >> >> template of mostly no-op resources still takes about 3 minutes.
> >> >>
> >> >> Horizon works but almost every page load take a few seconds to load.
> >> >> I'm
> >> >> not sure if that is normal or not.
> >> >>
> >> >> Thanks for any help anyone can provide.
> >> >>
> >> >> john
> >> >>
> >> >>
> >> >
> >>
> >
>


From gmann at ghanshyammann.com  Tue Apr  4 18:19:36 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Tue, 04 Apr 2023 11:19:36 -0700
Subject: [policy][rbac] RBAC 2023.2 Bobcat cycle vPTG discussions summary
Message-ID: <1874d7eebc0.1240e7b21225761.2715079050099639853@ghanshyammann.com>

Hello Everyone,

We discussed the RBAC goal on Tuesday. I am summarizing the discussion here.

Goal document: https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html
Tracking: https://etherpad.opendev.org/p/rbac-goal-tracking

Current progress:
=============

Phase-1 (project personas and drop system scope):
------------------------------------------------------------
Projects completed:
* Nova
* Neutron
* Glance
* Manila
* Ironic (no change needed)
* Octavia
* Placement
* Service that completed Phase 1 in Zed and enabled scope and new defaults by default (enforce_scope=True & enforce_new_defaults=True by default):
** Nova
** Glance

Projects in progress:
* Cinder (almost completed. not using system scope, but have not added scope=['project'] to the default rules (currently, no scope is specified)
* Magnum
** https://review.opendev.org/c/openstack/magnum/+/874945
* Tacker
** https://review.opendev.org/q/topic:bp%252Fimplement-project-personas

Pending work (for phase-2|3):
* Keystone implements a new default role called manager:
** https://review.opendev.org/c/openstack/keystone/+/822601
* Keystone implements a new default role called service:
** https://review.opendev.org/c/openstack/keystone/+/863420

Phase-2 (service role):
--------------------------
In-progress:
* Keystone:
** bootstrap support for servicerole:
*** https://review.opendev.org/c/openstack/keystone/+/863420
** bootstrap support for manager role:
*** https://review.opendev.org/c/openstack/keystone/+/822601
*Nova
** https://review.opendev.org/c/openstack/nova/+/864594

Other discussion:
=============

*Service role
We discussed the service role and how the policy will add the service role. It is correct to
add service as well as user role as default if that API is supposed to be called by the service
as well as the user role. For example, if Manila is talking to Nova, Cinder, or Neutron via APIs,
it needs to use a service role to interact, and Nova, Cinder, and Neutron can update such API
rules to allow for service roles also.

* Update the goal timeline for removing deprecated rules as per the SLURP release. 
** Need at least 1 SLURP release between enabling the new default and removal.
** Action: gmann to update this in the goal document.

*Testing:
** Manila has a lot of tests and running on the stable release
** Tempest and devstack ready to implement the test
** The current job with nova, cinder, neutron, glance with the scope and new default enable
*** https://zuul.openstack.org/builds?job_name=tempest-full-enforce-scope-new-defaults&skip=0
* Tempest now has a project reader/member same project_id

* Related sessions:
** Tacker
*** Title: Secure RBAC: Implement support of project-personas in Tacker [Continue from Antelope release] (manpreetk)
*** Etherpad:  https://etherpad.opendev.org/p/tacker-bobcat-ptg#L136
** Glance
*** Title: Secure RBAC
*** Etherpad: https://etherpad.opendev.org/p/glance-bobcat-ptg#L53
** Neutron
*** Title: (slaweq) Secure RBAC - phase 2 description and review of the existing API calls
*** Etherpad: https://etherpad.opendev.org/p/neutron-bobcat-ptg#L358

<feel free to add here if I missed any related sessions>

I will continue holding the biweekly meeting to discuss progress and any query on RBAC.
- https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popup_Team#Meeting

-gmann


From franck.vedel at univ-grenoble-alpes.fr  Tue Apr  4 18:48:09 2023
From: franck.vedel at univ-grenoble-alpes.fr (Franck VEDEL)
Date: Tue, 4 Apr 2023 20:48:09 +0200
Subject: [kolla-ansible][yoga][neutron][neutron-dhcp]ERRORS.... Need to
 understand
Message-ID: <21ECAC28-E3C9-4B18-8393-03C20F86F961@univ-grenoble-alpes.fr>

Hello.

I come back to you to try to understand my problem.
My installation is based on kolla-ansible, Yoga, Centos-Stream.
For some time, without understanding why, neutron_dhcp no longer works on external networks and the networks of my students' projects. This generates many error messages, which are difficult to understand.

Could this be a bug in this version? Before, it worked very well, but I have the impression that when the number of network increases (i?m not sure), from a moment, dhcp does not work anymore.
What is the way to find the problem?

Here are examples of errors that won't stop even if no one creates more instances of them

2023-04-04 20:36:52.870 7 ERROR neutron.agent.dhcp.agent     device, namespace, scope, broadcast)
2023-04-04 20:36:52.870 7 ERROR neutron.agent.dhcp.agent   File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/priv_context.py", line 272, in _wrap
2023-04-04 20:36:52.870 7 ERROR neutron.agent.dhcp.agent     r_call_timeout)
2023-04-04 20:36:52.870 7 ERROR neutron.agent.dhcp.agent   File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py", line 215, in remote_call
2023-04-04 20:36:52.870 7 ERROR neutron.agent.dhcp.agent     raise exc_type(*result[2])
2023-04-04 20:36:52.870 7 ERROR neutron.agent.dhcp.agent neutron.privileged.agent.linux.ip_lib.InvalidArgument: Invalid parameter/value used on interface tap73cd30e2-35, namespace qdhcp-395f1edb-de6d-4dd8-b31b-69a53780c012.
2023-04-04 20:36:52.870 7 ERROR neutron.agent.dhcp.agent
2023-04-04 20:36:52.871 7 INFO neutron.agent.dhcp.agent [-] Finished network 395f1edb-de6d-4dd8-b31b-69a53780c012 dhcp configuration
2023-04-04 20:36:52.872 7 INFO neutron.agent.dhcp.agent [-] Starting network 8db375e0-28d2-4379-9330-397dc9b4f2b1 dhcp configuration
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent [-] Unable to enable dhcp for 8db375e0-28d2-4379-9330-397dc9b4f2b1.: neutron.privileged.agent.linux.ip_lib.InvalidArgument: Invalid parameter/value used on interface tap1c220d25-b9, namespace qdhcp-8db375e0-28d2-4379-9330-397dc9b4f2b1.
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent Traceback (most recent call last):
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent   File "/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/agent/dhcp/agent.py", line 218, in call_driver
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent     rv = getattr(driver, action)(**action_kwargs)
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent   File "/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/agent/linux/dhcp.py", line 274, in enable
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent     common_utils.wait_until_true(self._enable, timeout=300)
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent   File "/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/common/utils.py", line 717, in wait_until_true
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent     while not predicate():
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent   File "/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/agent/linux/dhcp.py", line 286, in _enable
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent     interface_name = self.device_manager.setup(self.network)
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent   File "/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/agent/linux/dhcp.py", line 1779, in setup
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent     namespace=network.namespace)
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent   File "/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/agent/linux/interface.py", line 152, in init_l3
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent     device.addr.add(ip_cidr)
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent   File "/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/agent/linux/ip_lib.py", line 537, in add
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent     add_broadcast)
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent   File "/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/agent/linux/ip_lib.py", line 823, in add_ip_address
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent     device, namespace, scope, broadcast)
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent   File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/priv_context.py", line 272, in _wrap
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent     r_call_timeout)
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent   File "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py", line 215, in remote_call
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent     raise exc_type(*result[2])
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent neutron.privileged.agent.linux.ip_lib.InvalidArgument: Invalid parameter/value used on interface tap1c220d25-b9, namespace qdhcp-8db375e0-28d2-4379-9330-397dc9b4f2b1.
2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent

Thanks a lot




Franck

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/8cd435da/attachment-0001.htm>

From stefanbryzga at gmail.com  Tue Apr  4 06:46:59 2023
From: stefanbryzga at gmail.com (Stefan Bryzga)
Date: Tue, 4 Apr 2023 08:46:59 +0200
Subject: [kolla-ansible][zed][15.1.0] Horizon failed to load trunk and QoS
Message-ID: <CAJc0DSZEdHwWRONvwJdG7O=om3yP9xShOJ8w+PPR_O5be4_9qQ@mail.gmail.com>

Hi all,

Some time ago I deployed a small cluster with kolla-ansible v15.1.0. Before
deployment I enabled neutron_qos and neutron_trunk flags in
/etc/kolla/globals.yml. Both functions work fine via cli and I can create
new entries via dashboard however horizon won't display created trunks/qos
on the page (It shows "No items to display"). In web browser console I get
this error while loading page:

TypeError: Cannot read properties of undefined (reading 'data')
    at addTrackBy (output.0a9483334bbd.js:1115:59)
    at processQueue (output.43a09e34a303.js:1581:786)
    at output.43a09e34a303.js:1585:110
    at Scope.$digest (output.43a09e34a303.js:1636:200)
    at Scope.$apply (output.43a09e34a303.js:1643:269)
    at done (output.43a09e34a303.js:1356:123)
    at completeRequest (output.43a09e34a303.js:1375:20)
    at XMLHttpRequest.requestLoaded (output.43a09e34a303.js:1368:1)
'Possibly unhandled rejection: {}'

Does anyone knows how to fix this? Should I modify any configs to
display new entries in horizon?

Best Regards,
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/eb9b40f7/attachment.htm>

From stefanbryzga at gmail.com  Tue Apr  4 08:31:51 2023
From: stefanbryzga at gmail.com (Stefan Bryzga)
Date: Tue, 4 Apr 2023 10:31:51 +0200
Subject: [kolla-ansible][zed][15.1.0] Horizon failed to load trunk and QoS
Message-ID: <CAJc0DSYJsLr0oUFxXCzxVBwya-LReBXacER3U_6jjgOVmq19vg@mail.gmail.com>

Hi all,

Some time ago I deployed a small cluster with kolla-ansible v15.1.0. Before
deployment I enabled neutron_qos and neutron_trunk flags in
/etc/kolla/globals.yml. Both functions work fine via cli and I can create
new entries via dashboard however horizon won't display created trunks/qos
on the page (It shows "No items to display"). In web browser console I get
this error while loading page:

TypeError: Cannot read properties of undefined (reading 'data')
    at addTrackBy (output.0a9483334bbd.js:1115:59)
    at processQueue (output.43a09e34a303.js:1581:786)
    at output.43a09e34a303.js:1585:110
    at Scope.$digest (output.43a09e34a303.js:1636:200)
    at Scope.$apply (output.43a09e34a303.js:1643:269)
    at done (output.43a09e34a303.js:1356:123)
    at completeRequest (output.43a09e34a303.js:1375:20)
    at XMLHttpRequest.requestLoaded (output.43a09e34a303.js:1368:1)
'Possibly unhandled rejection: {}'

Does anyone knows how to fix this? Should I modify any configs to
display new entries in horizon?

Best Regards,
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/f3ccb3c0/attachment.htm>

From jonathan.rosser at rd.bbc.co.uk  Tue Apr  4 20:12:54 2023
From: jonathan.rosser at rd.bbc.co.uk (Jonathan Rosser)
Date: Tue, 4 Apr 2023 21:12:54 +0100
Subject: [ironic] ARM Support in CI: Call for vendors / contributors /
 interested parties
In-Reply-To: <CA+sTGNefqNaOOpAGj-O0LDqSitsF2KxZPmgC=rGOZjxkRpqcxA@mail.gmail.com>
References: <CA+sTGNfqAzE=bR16oXwBFyObKV8iz_RVkyB43t-ZemftdHsESQ@mail.gmail.com>
 <6faf5514-2ac8-9e8b-c543-0f8125b4001b@rd.bbc.co.uk>
 <CA+sTGNefqNaOOpAGj-O0LDqSitsF2KxZPmgC=rGOZjxkRpqcxA@mail.gmail.com>
Message-ID: <728b14da-c275-e59b-0345-ad246a4ced26@rd.bbc.co.uk>

Hi Jay,

We did not need to make any changes to Ironic.

At the time we first got things working I don't think there was a 
published ARM64 image, but it would have been of great benefit as it was 
another component to bootstrap and have uncertainty about if we had done 
it properly.

I've uploaded the published experimental image to our environment and 
will have an opportunity to test that soon.

Jon.

On 31/03/2023 17:01, Jay Faulkner wrote:
> Thanks for responding, Jonathan!
>
> Did you have to make any downstream changes to Ironic for this to 
> work? Are you using our published ARM64 image or using their own?
>
> Thanks,
> Jay Faulkner
> Ironic PTL
>
>
> On Fri, Mar 31, 2023 at 7:56?AM Jonathan Rosser 
> <jonathan.rosser at rd.bbc.co.uk> wrote:
>
>     I have Ironic working with Supermicro MegaDC / Ampere CPU in a
>     R12SPD-A
>     system board using the ipmi driver.
>
>     Jon.
>
>     On 29/03/2023 19:39, Jay Faulkner wrote:
>     > Hi stackers,
>     >
>     > Ironic has published an experimental Ironic Python Agent image for
>     > ARM64
>     >
>     (https://tarballs.opendev.org/openstack/ironic-python-agent-builder/dib/files/)
>
>     > and discussed promoting this image to supported via CI testing.
>     > However, we have a problem: there are no Ironic developers with
>     easy
>     > access to ARM hardware at the moment, and no Ironic developers with
>     > free time to commit to improving our support of ARM hardware.
>     >
>     > So we're putting out a call for help:
>     > - If you're a hardware vendor and want your ARM hardware supported?
>     > Please come talk to the Ironic community about setting up
>     third-party-CI.
>     > - Are you an operator or contributor from a company invested in ARM
>     > bare metal? Please come join the Ironic community to help us build
>     > this support.
>     >
>     > Thanks,
>     > Jay Faulkner
>     > Ironic PTL
>     >
>     >
>


From jamesleong123098 at gmail.com  Tue Apr  4 20:40:17 2023
From: jamesleong123098 at gmail.com (James Leong)
Date: Tue, 4 Apr 2023 15:40:17 -0500
Subject: [horizon][domain][yoga][kolla-ansible] horizon display failed to
 display domain tab
In-Reply-To: <28C8370B-12A5-4461-B168-BA522F9BE1F1@univ-grenoble-alpes.fr>
References: <CA+_ZFmG0CKSudcW3RwQ_ONyk71gc2g3=rb_wrGArJuYrStaPjA@mail.gmail.com>
 <28C8370B-12A5-4461-B168-BA522F9BE1F1@univ-grenoble-alpes.fr>
Message-ID: <CA+_ZFmFee2OvATqv-mGk05co7tSJ=OU9u4GxgMJtSb4Qxsep0Q@mail.gmail.com>

Awesome, thanks. I was able to view the domain tab by adding admin role to
admin mentioned by Eugen. Thanks again for your suggestion.

Best,
James

On Tue, Apr 4, 2023 at 4:36?AM Franck VEDEL <
franck.vedel at univ-grenoble-alpes.fr> wrote:

> Hi,
> if this could help?
>
>
> # more /etc/kolla/config/keystone/keystone.conf
> [identity]
> domain_specific_drivers_enabled = True
> domain_config_dir = /etc/keystone/domains
>
> # ls /etc/kolla/config/keystone/domains/
> cacert.pem  keystone.tprt2.conf  keystone.tprt.conf
>
>
> For me, it works !
>
>
> Franck
>
>
> Le 4 avr. 2023 ? 05:12, James Leong <jamesleong123098 at gmail.com> a ?crit :
>
> Hi all,
>
> I am playing around with the domain. I have used kolla-ansible as a
> deployment tool for deploying the yoga version of OpenStack. However, after
> deploying a fresh OpenStack, I was not able to view the domain tab on my
> dashboard. Every time when I want to create a new domain, I have to go to
> my terminal and create it manually without any GUI. Is there any other
> configuration I have to enable in the globals.yml file other than setting
> "horizon_keystone_multidomain: "True"?
>
> Thanks for your help
> James
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/c42517fd/attachment.htm>

From jamesleong123098 at gmail.com  Tue Apr  4 20:41:18 2023
From: jamesleong123098 at gmail.com (James Leong)
Date: Tue, 4 Apr 2023 15:41:18 -0500
Subject: [horizon][domain][yoga][kolla-ansible] horizon display failed to
 display domain tab
In-Reply-To: <CA+_ZFmFee2OvATqv-mGk05co7tSJ=OU9u4GxgMJtSb4Qxsep0Q@mail.gmail.com>
References: <CA+_ZFmG0CKSudcW3RwQ_ONyk71gc2g3=rb_wrGArJuYrStaPjA@mail.gmail.com>
 <28C8370B-12A5-4461-B168-BA522F9BE1F1@univ-grenoble-alpes.fr>
 <CA+_ZFmFee2OvATqv-mGk05co7tSJ=OU9u4GxgMJtSb4Qxsep0Q@mail.gmail.com>
Message-ID: <CA+_ZFmFrW5eOUpnnoF-7NMiB8EWNNMVsg-ygDWa+W0UpA=L1Tg@mail.gmail.com>

Hi,
Thank you Eugen for bringing this up about the admin role. This works out
on my side.

Best,
James

On Tue, Apr 4, 2023 at 3:40?PM James Leong <jamesleong123098 at gmail.com>
wrote:

> Awesome, thanks. I was able to view the domain tab by adding admin role to
> admin mentioned by Eugen. Thanks again for your suggestion.
>
> Best,
> James
>
> On Tue, Apr 4, 2023 at 4:36?AM Franck VEDEL <
> franck.vedel at univ-grenoble-alpes.fr> wrote:
>
>> Hi,
>> if this could help?
>>
>>
>> # more /etc/kolla/config/keystone/keystone.conf
>> [identity]
>> domain_specific_drivers_enabled = True
>> domain_config_dir = /etc/keystone/domains
>>
>> # ls /etc/kolla/config/keystone/domains/
>> cacert.pem  keystone.tprt2.conf  keystone.tprt.conf
>>
>>
>> For me, it works !
>>
>>
>> Franck
>>
>>
>> Le 4 avr. 2023 ? 05:12, James Leong <jamesleong123098 at gmail.com> a ?crit
>> :
>>
>> Hi all,
>>
>> I am playing around with the domain. I have used kolla-ansible as a
>> deployment tool for deploying the yoga version of OpenStack. However, after
>> deploying a fresh OpenStack, I was not able to view the domain tab on my
>> dashboard. Every time when I want to create a new domain, I have to go to
>> my terminal and create it manually without any GUI. Is there any other
>> configuration I have to enable in the globals.yml file other than setting
>> "horizon_keystone_multidomain: "True"?
>>
>> Thanks for your help
>> James
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/ba3177e5/attachment-0001.htm>

From alsotoes at gmail.com  Tue Apr  4 20:52:59 2023
From: alsotoes at gmail.com (Alvaro Soto)
Date: Tue, 4 Apr 2023 14:52:59 -0600
Subject: [ironic] ARM Support in CI: Call for vendors / contributors /
 interested parties
In-Reply-To: <728b14da-c275-e59b-0345-ad246a4ced26@rd.bbc.co.uk>
References: <CA+sTGNfqAzE=bR16oXwBFyObKV8iz_RVkyB43t-ZemftdHsESQ@mail.gmail.com>
 <6faf5514-2ac8-9e8b-c543-0f8125b4001b@rd.bbc.co.uk>
 <CA+sTGNefqNaOOpAGj-O0LDqSitsF2KxZPmgC=rGOZjxkRpqcxA@mail.gmail.com>
 <728b14da-c275-e59b-0345-ad246a4ced26@rd.bbc.co.uk>
Message-ID: <CA+eLJkapBkbKFNA__bGwh2UYo+PtS4CMo0N90iK2OtJDz5bhOg@mail.gmail.com>

I saw CentOS 8/9 and Debian images; any plans on working with Ubuntu?

Cheers!

On Tue, Apr 4, 2023 at 2:16?PM Jonathan Rosser <jonathan.rosser at rd.bbc.co.uk>
wrote:

> Hi Jay,
>
> We did not need to make any changes to Ironic.
>
> At the time we first got things working I don't think there was a
> published ARM64 image, but it would have been of great benefit as it was
> another component to bootstrap and have uncertainty about if we had done
> it properly.
>
> I've uploaded the published experimental image to our environment and
> will have an opportunity to test that soon.
>
> Jon.
>
> On 31/03/2023 17:01, Jay Faulkner wrote:
> > Thanks for responding, Jonathan!
> >
> > Did you have to make any downstream changes to Ironic for this to
> > work? Are you using our published ARM64 image or using their own?
> >
> > Thanks,
> > Jay Faulkner
> > Ironic PTL
> >
> >
> > On Fri, Mar 31, 2023 at 7:56?AM Jonathan Rosser
> > <jonathan.rosser at rd.bbc.co.uk> wrote:
> >
> >     I have Ironic working with Supermicro MegaDC / Ampere CPU in a
> >     R12SPD-A
> >     system board using the ipmi driver.
> >
> >     Jon.
> >
> >     On 29/03/2023 19:39, Jay Faulkner wrote:
> >     > Hi stackers,
> >     >
> >     > Ironic has published an experimental Ironic Python Agent image for
> >     > ARM64
> >     >
> >     (
> https://tarballs.opendev.org/openstack/ironic-python-agent-builder/dib/files/
> )
> >
> >     > and discussed promoting this image to supported via CI testing.
> >     > However, we have a problem: there are no Ironic developers with
> >     easy
> >     > access to ARM hardware at the moment, and no Ironic developers with
> >     > free time to commit to improving our support of ARM hardware.
> >     >
> >     > So we're putting out a call for help:
> >     > - If you're a hardware vendor and want your ARM hardware supported?
> >     > Please come talk to the Ironic community about setting up
> >     third-party-CI.
> >     > - Are you an operator or contributor from a company invested in ARM
> >     > bare metal? Please come join the Ironic community to help us build
> >     > this support.
> >     >
> >     > Thanks,
> >     > Jay Faulkner
> >     > Ironic PTL
> >     >
> >     >
> >
>
>

-- 

Alvaro Soto

*Note: My work hours may not be your work hours. Please do not feel the
need to respond during a time that is not convenient for you.*
----------------------------------------------------------
Great people talk about ideas,
ordinary people talk about things,
small people talk... about other people.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/3a265746/attachment.htm>

From kristin at openinfra.dev  Tue Apr  4 20:55:42 2023
From: kristin at openinfra.dev (Kristin Barrientos)
Date: Tue, 4 Apr 2023 15:55:42 -0500
Subject: OpenInfra Live - April 6 at 9 a.m. CT / 14:00 UTC 
Message-ID: <39FD7BE5-F24C-4463-8594-682FD1B90C3D@openinfra.dev>

Hi everyone,

This week?s OpenInfra Live episode is brought to you by the OpenStack Large Scale SIG.

Episode: Large Scale Ops Deep Dive: Soci?t? G?n?rale

In the "Large Scale Ops Deep Dive" series, a panel of OpenStack operators invites special guests to talk about their deployment and discuss their operations. For this episode, our guest will be Guillaume Allard from Soci?t? G?n?rale, one of France?s largest banks.
Speakers: Guillaume Allard, Arnaud Morin, Thierry Carrez, Belmiro Moreira, Mohammed Naser and Kristin Barrientos 

Date and time: April 6, 2023, at 9 a.m. CT (14:00 UTC)

You can watch us live on:
YouTube: https://www.youtube.com/live/ZIjpEZSu1gw?feature=share
LinkedIn: https://www.linkedin.com/video/event/urn:li:ugcPost:7043641363350908928/

WeChat: recording will be posted on OpenStack WeChat after the live stream

Have an idea for a future episode? Share it now at ideas.openinfra.live <https://openinfrafoundation.formstack.com/forms/openinfralive>. 

Thanks, 

Kristin Barrientos
Marketing Coordinator 
OpenInfra Foundation




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/2a59a00a/attachment.htm>

From haleyb.dev at gmail.com  Tue Apr  4 22:00:07 2023
From: haleyb.dev at gmail.com (Brian Haley)
Date: Tue, 4 Apr 2023 18:00:07 -0400
Subject: [kolla-ansible][yoga][neutron][neutron-dhcp]ERRORS.... Need to
 understand
In-Reply-To: <21ECAC28-E3C9-4B18-8393-03C20F86F961@univ-grenoble-alpes.fr>
References: <21ECAC28-E3C9-4B18-8393-03C20F86F961@univ-grenoble-alpes.fr>
Message-ID: <72a0a33f-af52-50b8-f059-fc7a5ccca20e@gmail.com>

Hi,

This has almost the same trace as a bug I've been working on, 
https://bugs.launchpad.net/bugs/1988069

You could confirm by looking in the namespace:

$ sudo ip netns exec qdhcp-8db375e0-28d2-4379-9330-397dc9b4f2b1 ip a

If you see any mtu value less than 68 then it is the same issue.

Fix is to increase the mtu on network 
8db375e0-28d2-4379-9330-397dc9b4f2b1 to at least 68, preferably 1450 or 
so depending on your overlay.

If that's not it please file a new bug with all the above info provided.

The other possibilities are a kernel issue, or the pyroute2 library, 
both of which have caused issues configuring IP addresses in namespaces.

-Brian

On 4/4/23 2:48 PM, Franck VEDEL wrote:
> Hello.
> 
> I come back to you to try to understand my problem.
> My installation is based on kolla-ansible, Yoga, Centos-Stream.
> For some time, without understanding why, neutron_dhcp no longer works 
> on external networks and the networks of my students' projects. This 
> generates many error messages, which are difficult to understand.
> 
> Could this be a bug in this version? Before, it worked very well, but I 
> have the impression that when the number of network increases (i?m not 
> sure), from a moment, dhcp does not work anymore.
> What is the way to find the problem?
> 
> Here are examples of errors that won't stop even if no one creates more 
> instances of them
> 
> 2023-04-04 20:36:52.870 7 ERROR neutron.agent.dhcp.agent ? ? device, 
> namespace, scope, broadcast)
> 2023-04-04 20:36:52.870 7 ERROR neutron.agent.dhcp.agent ? File 
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/priv_context.py", line 272, in _wrap
> 2023-04-04 20:36:52.870 7 ERROR neutron.agent.dhcp.agent ? ? r_call_timeout)
> 2023-04-04 20:36:52.870 7 ERROR neutron.agent.dhcp.agent ? File 
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py", line 215, in remote_call
> 2023-04-04 20:36:52.870 7 ERROR neutron.agent.dhcp.agent ? ? raise 
> exc_type(*result[2])
> 2023-04-04 20:36:52.870 7 ERROR neutron.agent.dhcp.agent 
> neutron.privileged.agent.linux.ip_lib.InvalidArgument: Invalid 
> parameter/value used on interface tap73cd30e2-35, namespace 
> qdhcp-395f1edb-de6d-4dd8-b31b-69a53780c012.
> 2023-04-04 20:36:52.870 7 ERROR neutron.agent.dhcp.agent
> 2023-04-04 20:36:52.871 7 INFO neutron.agent.dhcp.agent [-] Finished 
> network 395f1edb-de6d-4dd8-b31b-69a53780c012 dhcp configuration
> 2023-04-04 20:36:52.872 7 INFO neutron.agent.dhcp.agent [-] Starting 
> network 8db375e0-28d2-4379-9330-397dc9b4f2b1 dhcp configuration
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent [-] Unable to 
> enable dhcp for 8db375e0-28d2-4379-9330-397dc9b4f2b1.: 
> neutron.privileged.agent.linux.ip_lib.InvalidArgument: Invalid 
> parameter/value used on interface tap1c220d25-b9, namespace 
> qdhcp-8db375e0-28d2-4379-9330-397dc9b4f2b1.
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent Traceback (most 
> recent call last):
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent ? File 
> "/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/agent/dhcp/agent.py", line 218, in call_driver
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent ? ? rv = 
> getattr(driver, action)(**action_kwargs)
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent ? File 
> "/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/agent/linux/dhcp.py", line 274, in enable
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent     
> common_utils.wait_until_true(self._enable, timeout=300)
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent ? File 
> "/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/common/utils.py", line 717, in wait_until_true
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent ? ? while not 
> predicate():
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent ? File 
> "/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/agent/linux/dhcp.py", line 286, in _enable
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent     
> interface_name = self.device_manager.setup(self.network)
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent ? File 
> "/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/agent/linux/dhcp.py", line 1779, in setup
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent     
> namespace=network.namespace)
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent ? File 
> "/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/agent/linux/interface.py", line 152, in init_l3
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent     
> device.addr.add(ip_cidr)
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent ? File 
> "/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/agent/linux/ip_lib.py", line 537, in add
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent ? ? add_broadcast)
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent ? File 
> "/var/lib/kolla/venv/lib/python3.6/site-packages/neutron/agent/linux/ip_lib.py", line 823, in add_ip_address
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent ? ? device, 
> namespace, scope, broadcast)
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent ? File 
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/priv_context.py", line 272, in _wrap
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent ? ? r_call_timeout)
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent ? File 
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py", line 215, in remote_call
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent ? ? raise 
> exc_type(*result[2])
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent 
> neutron.privileged.agent.linux.ip_lib.InvalidArgument: Invalid 
> parameter/value used on interface tap1c220d25-b9, namespace 
> qdhcp-8db375e0-28d2-4379-9330-397dc9b4f2b1.
> 2023-04-04 20:36:53.587 7 ERROR neutron.agent.dhcp.agent
> 
> Thanks a lot
> 
> 
> 
> 
> Franck
> 


From miguel at mlavalle.com  Tue Apr  4 23:30:40 2023
From: miguel at mlavalle.com (Miguel Lavalle)
Date: Tue, 4 Apr 2023 18:30:40 -0500
Subject: [neutron] bug deputy report March 27th - April 2nd
Message-ID: <CAEzGLDgoZHtpXOnGfbP1StkFGdij50iGLBnCVi9Y3yjQNkHpOg@mail.gmail.com>

Here's last week's bugs deputy report:

Medium
======

https://bugs.launchpad.net/neutron/+bug/2012944
neutron-remove-duplicated-port-bindings
does not write to stdout. Valid bug. Assigned to mlavalle

https://bugs.launchpad.net/neutron/+bug/2013326 Trying to activate port
binding as regular user causes error 500. Assigned to slaweq


Low:
==========

https://bugs.launchpad.net/neutron/+bug/2012912 [neutron-lib][stable]
Wallaby CI n-t-p, test "test_qos_dscp_create_and_update" failing. This bug
is addressed by https://review.opendev.org/c/openstack/neutron-lib/+/879441.
No further action seems likely


RFEs
====

https://bugs.launchpad.net/neutron/+bug/2013228 [rfe] Non-admin users
unable to create SR-IOV switch dev ports. Discussed during the PTG during
the Neutron / Nova session, pending further discussion in drivers meeting

https://bugs.launchpad.net/neutron/+bug/2013540 [RFE] Add support for
Napatech LinkVirt SmartNICs. Discussed during the PTG, pending further
discussion in drivers meeting
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/3d928cbc/attachment.htm>

From nguyenhuukhoinw at gmail.com  Tue Apr  4 23:39:31 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Wed, 5 Apr 2023 06:39:31 +0700
Subject: [kolla][kolla-ansible] Kolla-Ansible mirror update and kolla images
Message-ID: <CABAODRfu_PCJhgwbk5K5_voX08=KF=SHgJKPpA_eW8e12Spbjw@mail.gmail.com>

Hello.

I have a question.

I use kolla-ansible 13.0.0 and kolla 13.0.0 images then I upgrade
kolla-ansible to 13.8.0. I will use kolla 13.8.0 to build new images?

Thank you. Regards

Nguyen Huu Khoi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230405/2945b6f4/attachment.htm>

From rdhasman at redhat.com  Wed Apr  5 04:33:19 2023
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Wed, 5 Apr 2023 10:03:19 +0530
Subject: [cinder] 2023.2 Bobcat Meeting Etherpad
Message-ID: <CAARK8KSGKinW=FqhFW5SRxynHyOQPJ0TE8+CW0RZrL=8L89YcQ@mail.gmail.com>

Hello Argonauts,

As we're done with the 2023.2 Bobcat PTG, we will be moving to a new
etherpad for cinder meetings for the 2023.2 Bobcat development cycle.
Please add topics (if you have any) to the etherpad for the meeting on 05
April, 2023 (Today).

Etherpad: https://etherpad.opendev.org/p/cinder-bobcat-meetings

Thanks
Rajat Dhasmana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230405/e57575b3/attachment.htm>

From akekane at redhat.com  Wed Apr  5 06:44:31 2023
From: akekane at redhat.com (Abhishek Kekane)
Date: Wed, 5 Apr 2023 12:14:31 +0530
Subject: [Glance] Bobcat PTG summary
Message-ID: <CALOt+SS5hstT+hRb7T3hSovCFFnB_P9WKsYF+_DwMC+56_9LEA@mail.gmail.com>

Hi Team,

We had our seventh virtual PTG between 27th March to 31st March 2023.
Thanks to everyone who joined the virtual PTG sessions. Using bluejeans app
we had lots of discussion around different topics for glance, glance +
cinder, fips and Secure RBAC. You can find the topics discussed in etherpad
[1] with Notes from the session and which also includes the recordings of
each discussion.

Here I am going to highlight a few important topics which we are going to
target this cycle.

# Glance Image Direct URL access - OSSN-0090
This is the most important and high priority work item for us in this
cycle. We are going to move the spec to the current cycle and implement
glance, client and osc side work this cycle. We are also going to implement
tempest side work for the same. Once it is completed, Rajat (current cinder
PTL) is  going to write consumer side spec for nova and cinder.

https://bluejeans.com/s/dKF1IG2h8PC chapter 2 (from 22 minutes onward)

# Bridge gap between Glance client and OSC
Last cycle we have prepared the list of missing commands [2] and started
submitting patches to implement the same. Our biggest hurdle at the moment
is lack of reviews from the osc team (which has only one/two cores). Glance
PTL is going to communicate with TC/existing core(s) of OSC whether they
can add any glance core to the team so that we can prioritize our work and
get reviews immediately. This cycle we are planning to complete this work.

Recording: https://bluejeans.com/s/XZoRGceEhW3/ - Chapter 4

# Default glance to configure multistore
Efforts has been started from last cycle but this work needs to be divided
in small parts such as removing unnecessary tests, migrating existing tests
to support multistore and so on. This cycle we are going to ensure that
existing tests are supporting multistore configs.

Recording: https://bluejeans.com/s/XZoRGceEhW3/ - Chapter 3

# Secure RBAC
So far we are good with the goals decided by the community. This cycle PTL
is going to discuss with the QE/TC team regarding deprecation of policies
(migrating policies to use manager role) and decide further action.

Recording: https://bluejeans.com/s/RHgqQi28_Hk/ - chapter 1

# Fips Overview
ade_lee is going to submit some patches for us and we are going to help him
in debugging failures if there are any.

Recording: https://bluejeans.com/s/RHgqQi28_Hk/ - chapter 5

# Native Image encryption
Finally the Barbican work is complete and we can move ahead with glance
side work in this cycle. We need to move glance side spec to Bobcat and
check whether there will be any changes in the implementation. Luzi is
going to work on glance changes and the team is going to assist her in
reviews and testing.

Recording: https://bluejeans.com/s/RHgqQi28_Hk/ - chapter 3

# RBD deferred deletion
Eric from cinder team is working on PoC/code for glance-store side changes
for the same. Once we have PoC ready, the glance team will assist him to
create a detailed spec and start working on tests for the same.

https://bluejeans.com/s/dKF1IG2h8PC - chapter 2


Apart from above topics you can find other miscellaneous topics discussed
in PTG etherpad [1] along with milestone wise priorities at the end.
If you have any questions/suggestions then please join us in our weekly
meeting (each Thursday #openstack-meeting irc channel at 1400 UTC).

[1] https://etherpad.opendev.org/p/glance-bobcat-ptg
[2]
https://docs.google.com/spreadsheets/d/1tlipscCDeWmYGz3Hfp74czPW7BBJb4ST84qXOeROkaE/edit?usp=sharing

Thanks and Regards,

Abhishek Kekane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230405/b99ee2b8/attachment.htm>

From franck.vedel at univ-grenoble-alpes.fr  Wed Apr  5 06:57:34 2023
From: franck.vedel at univ-grenoble-alpes.fr (Franck VEDEL)
Date: Wed, 5 Apr 2023 08:57:34 +0200
Subject: [kolla-ansible][yoga][neutron][neutron-dhcp]ERRORS.... Need to
 understand
In-Reply-To: <72a0a33f-af52-50b8-f059-fc7a5ccca20e@gmail.com>
References: <21ECAC28-E3C9-4B18-8393-03C20F86F961@univ-grenoble-alpes.fr>
 <72a0a33f-af52-50b8-f059-fc7a5ccca20e@gmail.com>
Message-ID: <8A7DB337-4B32-4A96-99E3-8E8430BED3C2@univ-grenoble-alpes.fr>

Hi , and thanks a lot for your help.

so
$ sudo ip netns exec qdhcp-8db375e0-28d2-4379-9330-397dc9b4f2b1 ip a
3401: tap1c220d25-b9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 68 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether fa:16:3e:20:ef:bc brd ff:ff:ff:ff:ff:ff
    inet 169.254.169.254/32 brd 169.254.169.254 scope global tap1c220d25-b9
       valid_lft forever preferred_lft forever
    inet 10.1.42.1/24 brd 10.1.42.255 scope global tap1c220d25-b9
       valid_lft forever preferred_lft forever


$tail -f /var/log/kolla/neutron/neutron-dhcp-agent.log |grep 8db375e0-28d2-4379-9330-397dc9b4f2b1
2023-04-05 08:36:11.558 7 INFO neutron.agent.dhcp.agent [-] Starting network 8db375e0-28d2-4379-9330-397dc9b4f2b1 dhcp configuration
2023-04-05 08:36:12.532 7 ERROR neutron.agent.dhcp.agent [-] Unable to enable dhcp for 8db375e0-28d2-4379-9330-397dc9b4f2b1.: neutron.privileged.agent.linux.ip_lib.InvalidArgument: Invalid parameter/value used on interface tap1c220d25-b9, namespace qdhcp-8db375e0-28d2-4379-9330-397dc9b4f2b1.
2023-04-05 08:36:12.532 7 ERROR neutron.agent.dhcp.agent neutron.privileged.agent.linux.ip_lib.InvalidArgument: Invalid parameter/value used on interface tap1c220d25-b9, namespace qdhcp-8db375e0-28d2-4379-9330-397dc9b4f2b1.
2023-04-05 08:36:12.534 7 INFO neutron.agent.dhcp.agent [-] Finished network 8db375e0-28d2-4379-9330-397dc9b4f2b1 dhcp configuration

 openstack network show 8db375e0-28d2-4379-9330-397dc9b4f2b1
+---------------------------+--------------------------------------+
| Field                     | Value                                |
+---------------------------+--------------------------------------+
| admin_state_up            | UP                                   |
| availability_zone_hints   |                                      |
| availability_zones        | nova                                 |
| created_at                | 2023-04-04T11:49:47Z                 |
| description               |                                      |
| dns_domain                | None                                 |
| id                        | 8db375e0-28d2-4379-9330-397dc9b4f2b1 |
| ipv4_address_scope        | None                                 |
| ipv6_address_scope        | None                                 |
| is_default                | None                                 |
| is_vlan_transparent       | None                                 |
| mtu                       | 68                                   |
| name                      | NET1                                 |
| port_security_enabled     | True                                 |
| project_id                | 6d6cbcbb6e8d4264bcd13dd8b3d79466     |
| provider:network_type     | vxlan                                |
| provider:physical_network | None                                 |
| provider:segmentation_id  | 456                                  |
| qos_policy_id             | None                                 |
| revision_number           | 2                                    |
| router:external           | Internal                             |
| segments                  | None                                 |
| shared                    | False                                |
| status                    | ACTIVE                               |
| subnets                   | b72cf65c-1a22-4165-a55b-884bcc9c636a |
| tags                      |                                      |
| updated_at                | 2023-04-04T11:49:47Z                 |
+---------------------------+???????????????????+

$openstack subnet show b72cf65c-1a22-4165-a55b-884bcc9c636a
+----------------------+--------------------------------------+
| Field                | Value                                |
+----------------------+--------------------------------------+
| allocation_pools     | 10.1.42.1-10.1.42.253                |
| cidr                 | 10.1.42.0/24                         |
| created_at           | 2023-04-04T11:49:47Z                 |
| description          |                                      |
| dns_nameservers      |                                      |
| dns_publish_fixed_ip | None                                 |
| enable_dhcp          | True                                 |
| gateway_ip           | 10.1.42.254                          |
| host_routes          |                                      |
| id                   | b72cf65c-1a22-4165-a55b-884bcc9c636a |
| ip_version           | 4                                    |
| ipv6_address_mode    | None                                 |
| ipv6_ra_mode         | None                                 |
| name                 |                                      |
| network_id           | 8db375e0-28d2-4379-9330-397dc9b4f2b1 |
| project_id           | 6d6cbcbb6e8d4264bcd13dd8b3d79466     |
| revision_number      | 0                                    |
| segment_id           | None                                 |
| service_types        |                                      |
| subnetpool_id        | None                                 |
| tags                 |                                      |
| updated_at           | 2023-04-04T11:49:47Z                 |
+----------------------+--------------------------------------+


Since yesterday, we have a lot of network (2 per students , 100 students) , so a lot of errors:
In the log of dnsmask we can see this:
Apr  5 08:55:02 dnsmasq-dhcp[2466928]: read /var/lib/neutron/dhcp/7d33855e-03a8-431b-9cf8-64f8e95b8f93/host
Apr  5 08:55:02 dnsmasq-dhcp[2466928]: read /var/lib/neutron/dhcp/7d33855e-03a8-431b-9cf8-64f8e95b8f93/opts
Apr  5 08:55:05 dnsmasq-dhcp[609053]: DHCPDISCOVER(tap5af0e639-f3) fa:16:3e:8d:86:b9 no address available
Apr  5 08:55:05 dnsmasq-dhcp[4572]: DHCPDISCOVER(tap6fe70972-c9) fa:16:3e:6d:dc:c8 no address available


You say: If that's not it please file a new bug with all the above info provided.
How can I do that ?

Thanks a lot 

Franck




> Le 5 avr. 2023 ? 00:00, Brian Haley <haleyb.dev at gmail.com> a ?crit :
> 
> 8db375e0-28d2-4379-9330-397dc9b4f2b1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230405/4d83ec0d/attachment-0001.htm>

From artem.goncharov at gmail.com  Wed Apr  5 07:23:34 2023
From: artem.goncharov at gmail.com (Artem Goncharov)
Date: Wed, 5 Apr 2023 09:23:34 +0200
Subject: [Glance] Bobcat PTG summary
In-Reply-To: <CALOt+SS5hstT+hRb7T3hSovCFFnB_P9WKsYF+_DwMC+56_9LEA@mail.gmail.com>
References: <CALOt+SS5hstT+hRb7T3hSovCFFnB_P9WKsYF+_DwMC+56_9LEA@mail.gmail.com>
Message-ID: <40D3DB03-3D45-4C08-9B80-CE7F2D47F2F7@gmail.com>

Hi,

Feedback from SDK/OSC team on one item that got my attention

> 
> # Bridge gap between Glance client and OSC
> Last cycle we have prepared the list of missing commands [2] and started submitting patches to implement the same. Our biggest hurdle at the moment is lack of reviews from the osc team (which has only one/two cores). Glance PTL is going to communicate with TC/existing core(s) of OSC whether they can add any glance core to the team so that we can prioritize our work and get reviews immediately. This cycle we are planning to complete this work. 
> 

At the moment SDK/CLI core group is having 27 members, which should be already a sign. We have an agreement with all teams and add certain members into the core group to be able to review changes for their corresponding services (with a limitation that they are NOT by default setting W+1).
You have noticed pretty correct - at the moment there is not so much activity on our side due to lack of reviewers. But that is not blocking any change once there is a +2 review from the service representatives. That means that if Glance team opens change and another Glance team member leaves +2 those changes are having absolutely different priority and we normally approving them fast (unless there is something preventing that). What we want to prevent is that every team is pulling project into their direction breaking certain rules or conventions.

Please provide me the list of members you would like to get SDK/CLI core rights and I would gladly add them (one more time - no workflow+1)

Artem

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230405/ac5c74fb/attachment.htm>

From akekane at redhat.com  Wed Apr  5 07:28:18 2023
From: akekane at redhat.com (Abhishek Kekane)
Date: Wed, 5 Apr 2023 12:58:18 +0530
Subject: [Glance] Bobcat PTG summary
In-Reply-To: <40D3DB03-3D45-4C08-9B80-CE7F2D47F2F7@gmail.com>
References: <CALOt+SS5hstT+hRb7T3hSovCFFnB_P9WKsYF+_DwMC+56_9LEA@mail.gmail.com>
 <40D3DB03-3D45-4C08-9B80-CE7F2D47F2F7@gmail.com>
Message-ID: <CALOt+SRuwnKGy-rL7BJfXipqXb7n+H3sk_Z_K5jdP8NgMZ0Svg@mail.gmail.com>

On Wed, Apr 5, 2023 at 12:53?PM Artem Goncharov <artem.goncharov at gmail.com>
wrote:

> Hi,
>
> Feedback from SDK/OSC team on one item that got my attention
>
>
> # Bridge gap between Glance client and OSC
> Last cycle we have prepared the list of missing commands [2] and started
> submitting patches to implement the same. Our biggest hurdle at the moment
> is lack of reviews from the osc team (which has only one/two cores). Glance
> PTL is going to communicate with TC/existing core(s) of OSC whether they
> can add any glance core to the team so that we can prioritize our work and
> get reviews immediately. This cycle we are planning to complete this work.
>
>
> At the moment SDK/CLI core group is having 27 members, which should be
> already a sign. We have an agreement with all teams and add certain members
> into the core group to be able to review changes for their corresponding
> services (with a limitation that they are NOT by default setting W+1).
> You have noticed pretty correct - at the moment there is not so much
> activity on our side due to lack of reviewers. But that is not blocking any
> change once there is a +2 review from the service representatives. That
> means that if Glance team opens change and another Glance team member
> leaves +2 those changes are having absolutely different priority and we
> normally approving them fast (unless there is something preventing that).
> What we want to prevent is that every team is pulling project into their
> direction breaking certain rules or conventions.
>
> Please provide me the list of members you would like to get SDK/CLI core
> rights and I would gladly add them (one more time - no workflow+1)
>
> Artem
>
> Hi Artem,

Thank you for your immediate response, I will discuss this with Glance PTL
and let you know the name of interested member(s) by this Friday.

Thanks,

Abhishek Kekane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230405/1818f9b9/attachment.htm>

From marios at redhat.com  Wed Apr  5 08:04:07 2023
From: marios at redhat.com (Marios Andreou)
Date: Wed, 5 Apr 2023 11:04:07 +0300
Subject: [tripleo] hold rechecks content provider gate blocker
Message-ID: <CAM51kHXpCS0noueSBE=NO86ev_bvQL=15W1PydoWpHo-PcNyPg@mail.gmail.com>

Hello tripleo

we have a gate blocker at [1] hitting the centos-9-content-provider jobs.

The tripleo CI team is tracking this - please hold rechecks until it
we have a resolution or workaround

regards, marios

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



From geguileo at redhat.com  Wed Apr  5 09:16:38 2023
From: geguileo at redhat.com (Gorka Eguileor)
Date: Wed, 5 Apr 2023 11:16:38 +0200
Subject: Does Openstack support the notion of cinder backend in
 maintenance mode?
In-Reply-To: <CAB7j8cXE-=kLRzVF6TtE-OTGNan=JB=WzoUYqedPtFYd5E8q9g@mail.gmail.com>
References: <CAJV_UBB2R7GZrWWYcOqOuf2U3xFBN+RWAe4GxqhgqLUow5fJnA@mail.gmail.com>
 <CAB7j8cWpiz6WfhTeGof7ZdhskmwXwkwzYY=WSpPco0M78cko2A@mail.gmail.com>
 <CAJV_UBBZpOsPg92W41=qnyonqpr4Kis1C5qffv=MXUp47bYUYw@mail.gmail.com>
 <CAB7j8cU9zYX=XhEF2aJNS6WSWJOSxAUNA=Zm2erMKLAwXO_Dcg@mail.gmail.com>
 <CAB7j8cXE-=kLRzVF6TtE-OTGNan=JB=WzoUYqedPtFYd5E8q9g@mail.gmail.com>
Message-ID: <20230405091638.jzu5vhswzlhtfwwn@localhost>

On 02/04, Ignazio Cassano wrote:
> In other words, when you disable a cinder backend you cannot allocate
> volumes on it.
> This is what you want.
> Ignazio
>

Hi,

A clarification for anyone reading this, please pay careful attention to
Ignazio's wording, it's important: "cannot allocate volumes".

Just because Cinder won't allocate new volumes it doesn't mean that all
operations on the backend are disabled.  In fact, scheduling operations
are disabled and everything else isn't.

This means that volumes can be deleted, they can be attached, snapshot
can be deleted, backups can be created...

Cheers,
Gorka.


>
> Il Dom 2 Apr 2023, 18:10 Ignazio Cassano <ignaziocassano at gmail.com> ha
> scritto:
>
> > If you read the link I sent you, you can note that it disable a backend
> > before removing it. So you can exclude the removing section.
> > Another way can be excluding the backend from enabled backends in
> > cinder.conf and restarting cinser services.
> > Ignazio
> >
> > Il Dom 2 Apr 2023, 15:17 wodel youchi <wodel.youchi at gmail.com> ha scritto:
> >
> >> Thank you,
> >>
> >> Maybe my question was not clear enough.
> >> Let's say I have a  cinder-volume with nfs as backend and I need to take
> >> down the nfs server for maintenance, can I put the cinder-volume-nfs into
> >> some sort of maintenance mode, work on the nfs server bring it back, then
> >> reactivate the cinder-volume-nfs?
> >>
> >> Regards.
> >>
> >> Le dim. 2 avr. 2023 ? 13:54, Ignazio Cassano <ignaziocassano at gmail.com>
> >> a ?crit :
> >>
> >>> Or using the openstack command :
> >>>
> >>> https://platform9.com/kb/openstack/deleting-a-cinder-service-from-host
> >>>
> >>> Il Dom 2 Apr 2023, 14:46 wodel youchi <wodel.youchi at gmail.com> ha
> >>> scritto:
> >>>
> >>>> Hi,
> >>>>
> >>>> When you have multiple cinder backends, and you need to take down one
> >>>> of them for maintenance purposes, what is the best way to proceed?
> >>>> Does Openstack have the notion of : cinder backend in maintenance mode?
> >>>>
> >>>> Regards.
> >>>>
> >>>



From elfosardo at gmail.com  Wed Apr  5 09:24:04 2023
From: elfosardo at gmail.com (Riccardo Pittau)
Date: Wed, 5 Apr 2023 11:24:04 +0200
Subject: [ironic] ARM Support in CI: Call for vendors / contributors /
 interested parties
In-Reply-To: <CA+eLJkapBkbKFNA__bGwh2UYo+PtS4CMo0N90iK2OtJDz5bhOg@mail.gmail.com>
References: <CA+sTGNfqAzE=bR16oXwBFyObKV8iz_RVkyB43t-ZemftdHsESQ@mail.gmail.com>
 <6faf5514-2ac8-9e8b-c543-0f8125b4001b@rd.bbc.co.uk>
 <CA+sTGNefqNaOOpAGj-O0LDqSitsF2KxZPmgC=rGOZjxkRpqcxA@mail.gmail.com>
 <728b14da-c275-e59b-0345-ad246a4ced26@rd.bbc.co.uk>
 <CA+eLJkapBkbKFNA__bGwh2UYo+PtS4CMo0N90iK2OtJDz5bhOg@mail.gmail.com>
Message-ID: <CAORRS=krh+v3cE8cXbc06DUo6ektHJ1F-4HP+ZHmiL-8pQ90ZA@mail.gmail.com>

Hey Alvaro,

We've discussed support for ubuntu arm64 image during the last weekly
meeting on Monday and agreed to provide it.
I plan to start working on that this week in the
ironic-python-agent-builder repository.

Ciao
Riccardo

On Tue, Apr 4, 2023 at 11:00?PM Alvaro Soto <alsotoes at gmail.com> wrote:

> I saw CentOS 8/9 and Debian images; any plans on working with Ubuntu?
>
> Cheers!
>
> On Tue, Apr 4, 2023 at 2:16?PM Jonathan Rosser <
> jonathan.rosser at rd.bbc.co.uk> wrote:
>
>> Hi Jay,
>>
>> We did not need to make any changes to Ironic.
>>
>> At the time we first got things working I don't think there was a
>> published ARM64 image, but it would have been of great benefit as it was
>> another component to bootstrap and have uncertainty about if we had done
>> it properly.
>>
>> I've uploaded the published experimental image to our environment and
>> will have an opportunity to test that soon.
>>
>> Jon.
>>
>> On 31/03/2023 17:01, Jay Faulkner wrote:
>> > Thanks for responding, Jonathan!
>> >
>> > Did you have to make any downstream changes to Ironic for this to
>> > work? Are you using our published ARM64 image or using their own?
>> >
>> > Thanks,
>> > Jay Faulkner
>> > Ironic PTL
>> >
>> >
>> > On Fri, Mar 31, 2023 at 7:56?AM Jonathan Rosser
>> > <jonathan.rosser at rd.bbc.co.uk> wrote:
>> >
>> >     I have Ironic working with Supermicro MegaDC / Ampere CPU in a
>> >     R12SPD-A
>> >     system board using the ipmi driver.
>> >
>> >     Jon.
>> >
>> >     On 29/03/2023 19:39, Jay Faulkner wrote:
>> >     > Hi stackers,
>> >     >
>> >     > Ironic has published an experimental Ironic Python Agent image for
>> >     > ARM64
>> >     >
>> >     (
>> https://tarballs.opendev.org/openstack/ironic-python-agent-builder/dib/files/
>> )
>> >
>> >     > and discussed promoting this image to supported via CI testing.
>> >     > However, we have a problem: there are no Ironic developers with
>> >     easy
>> >     > access to ARM hardware at the moment, and no Ironic developers
>> with
>> >     > free time to commit to improving our support of ARM hardware.
>> >     >
>> >     > So we're putting out a call for help:
>> >     > - If you're a hardware vendor and want your ARM hardware
>> supported?
>> >     > Please come talk to the Ironic community about setting up
>> >     third-party-CI.
>> >     > - Are you an operator or contributor from a company invested in
>> ARM
>> >     > bare metal? Please come join the Ironic community to help us build
>> >     > this support.
>> >     >
>> >     > Thanks,
>> >     > Jay Faulkner
>> >     > Ironic PTL
>> >     >
>> >     >
>> >
>>
>>
>
> --
>
> Alvaro Soto
>
> *Note: My work hours may not be your work hours. Please do not feel the
> need to respond during a time that is not convenient for you.*
> ----------------------------------------------------------
> Great people talk about ideas,
> ordinary people talk about things,
> small people talk... about other people.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230405/b89171de/attachment-0001.htm>

From ralonsoh at redhat.com  Wed Apr  5 11:30:20 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Wed, 5 Apr 2023 13:30:20 +0200
Subject: [neutron][OpenStack-ansible] Performance issues with trunk ports
In-Reply-To: <CAPd_6AvrRS8b_ZQvHXmjJwO46wjb05z9Oc3Pk9aOafse=T8ZKA@mail.gmail.com>
References: <CADC88Ce0xV3RytP2yi3+mJQOdtv8F_NuCGgbUu3g2_Z6AT7Jcg@mail.gmail.com>
 <CALg0jK=FLJvXpQfcFFf=uRFFdL=tTGLLjox8UiK_RuJ3cWchfA@mail.gmail.com>
 <CADC88CfbA5RQS9MLetr70H60cSZ6u1aTms4Az56MtrMS3kWXuQ@mail.gmail.com>
 <CALg0jKkqQ4-v7pgPmeFV7zdu9TbZrvEP9MggpM_3WZx4Q8wdVg@mail.gmail.com>
 <CADC88CcMyaF2eoH5ryKO1PN9fM7a76ufp2JtKcOTmF5CoUorXQ@mail.gmail.com>
 <CAPd_6AvrRS8b_ZQvHXmjJwO46wjb05z9Oc3Pk9aOafse=T8ZKA@mail.gmail.com>
Message-ID: <CAECr9X6k=oM3dTMu7Ovgyh-ubm8g9LYkkuRV=GqYoEdV5=TxAw@mail.gmail.com>

Hello John:

About the Trunk plugin and the RPC calls. This is a flaw in the design of
the Trunk service plugin. The RPC backend instantiated and the RPC calls
registered during the Neutron manager initialization. This is done before
the API and RPC workers are created. Because of this, the Trunk plugin RPC
calls are attended by the main thread only. That is something to be
improved for sure.

About the VXLAN ranges. It is recommended to limit the range that could be
used by Neutron. 4 seconds is still a lot of time for a table so simple
(two columns without any external reference). But for sure 3 minutes is not
practical. You need to investigate the poor performance of this engine with
this table. But as commented, in order to mitigate that poor performance,
you can probably reduce to 1K or 2K the number of VXLAN ranges.

I'll check the launchpad bug reported. Thanks!

Regards.

On Tue, Apr 4, 2023 at 6:09?PM Dmitriy Rabotyagov <noonedeadpunk at gmail.com>
wrote:

> Yes, totally, that would be great to sort out why using uWSGI make
> such difference in performance. I was just trying to provide you with
> a fix solution in the meantime, if its needed and affecting your
> production deployment.
>
> Also, if neutron_use_uwsgi is set to false, neutron-rpc-server should
> be stopped as this service is not used for scenario without uWSGI at
> all. Though I can imagine having a bug in OpenStack-Ansible that we
> leave neutron-rpc-server running when switching from uwsgi to
> eventlet, despite it not needed for that scenario.
>
> In addition to that, I'm not sure about the current state, but during
> Zed uWSGI known not to work at all with OVN driver, for instance. It
> could be fixed now though.
>
> ??, 4 ???. 2023??. ? 16:47, John Bartelme <bartelme at gmail.com>:
> >
> > Dmitriy wrote:
> > > Have you tried out of interest to set "neutron_use_uwsgi: false" in
> your user_variables.yml
> >
> >      Thank you for that suggestion.  I did think about changing that
> > option but reading up on some of the change logs it looked like
> > everything is trying to be migrated over to uWSGI.  When I set that
> > option things are indeed much better.  The update_subport_bindings RPC
> > call is still not being handled by the RPC worker threads but the
> > neutron-server parent thread is able to handle the calls and much more
> > quickly than the uWSGI threads were, i.e. in that 1-2 second
> > timeframe.   What are the ramifications of not using uWSGI?  Is this
> > an ok configuration for a production deployment?  Are there any
> > thoughts as to why the uWSGI threads are having such performance
> > issues?  Thanks so much for all of the help.
> >
> >      I?ll continue to write up a bug for RPC threads not handling
> > update_subport_bindings calls and for uWSGI handling them which may be
> > unexpected.
> >
> >      Thanks, john
> >
> > On 4/4/23, Lajos Katona <katonalala at gmail.com> wrote:
> > > Hi,
> > > Perfect, please do that.
> > >
> > > Lajos
> > >
> > > John Bartelme <bartelme at gmail.com> ezt ?rta (id?pont: 2023. ?pr. 4.,
> K,
> > > 15:12):
> > >
> > >> When you say trunk issue do you mean about the RPC calls going to
> > >> uWSGI threads or this general issue with long times.  For the long
> > >> times I'm not sure I have enough detail to write a bug but I could for
> > >> the RPC calls.
> > >>
> > >> Also I'm using LinuxBridge on the backend.
> > >>
> > >> Thanks, john
> > >>
> > >> On 4/4/23, Lajos Katona <katonalala at gmail.com> wrote:
> > >> > Hi,
> > >> > could you open a bug report on https://bugs.launchpad.net/neutron/
> for
> > >> the
> > >> > trunk issue with reproduction steps?
> > >> > It is also important which backend you use? OVS or something else?
> > >> >
> > >> > Thanks in advance
> > >> > Lajos Katona (lajoskatona)
> > >> >
> > >> > John Bartelme <bartelme at gmail.com> ezt ?rta (id?pont: 2023. ?pr.
> 4., K,
> > >> > 14:15):
> > >> >
> > >> >> Hello,
> > >> >>
> > >> >> I'm currently experiencing some pretty severe performance issues
> with
> > >> >> my
> > >> >> openstack-ansible deployed cluster(yoga) while deploying trunk
> ports
> > >> >> and
> > >> >> I'm looking for some help determining what might be the cause of
> this
> > >> >> poor
> > >> >> performance.
> > >> >>
> > >> >> In my simplest case I'm deploying 2 servers each with one trunk
> port
> > >> >> each.
> > >> >> The first trunk has 2 subports and the second 6 subports. Both
> servers
> > >> >> also
> > >> >> have 3 other regular ports. When deploying the first trunk port its
> > >> >> subports are often provisioned quickly and the second trunk port
> takes
> > >> >> anywhere from 30 seconds to 18 minutes. This happens even when I
> > >> >> isolate
> > >> >> neutron-server to a single physical machine with 44(88 threads) and
> > >> 256GB
> > >> >> ram. Further diagnosis has shown me some things i didn't quite
> > >> >> understand.
> > >> >> My deployment with OpenStack-ansible deploys neutron-server with 16
> > >> uWSGI
> > >> >> processes and neutron-rpc-server with 16 rpc workers. However the
> way
> > >> >> that
> > >> >> the trunk RPC server is implemented it is only run on the parent
> RPC
> > >> >> thread
> > >> >> and instead runs in all of the uWSGI processes as well. This means
> > >> >> that
> > >> >> most of my trunk RPC calls are being handled by the uWSGI instead
> of
> > >> >> the
> > >> >> RPC workers. When the parent RPC thread handles the trunk port
> > >> >> creation
> > >> >> calls I constantly see creation times of 1-1.5 seconds. I've
> isolated
> > >> >> it
> > >> >> so
> > >> >> that this thread does all of the trunk RPC calls and this works
> quite
> > >> >> well
> > >> >> but this doesn't seem ideal. What could be causing such poor
> > >> >> performance
> > >> >> in
> > >> >> the uWSGI side of the house? I'm having a really hard time getting
> a
> > >> good
> > >> >> feeling for what might be slowing it down so much. I'm wondering
> if it
> > >> >> could be green thread preemption but I really don't know. I've
> tried
> > >> >> setting 'enable-threads' false for uWSGI but I don't think that is
> > >> >> improving performance. Putting the profiled decorator on
> > >> >> update_subport_bindings shows different places taking longer every
> > >> >> time,
> > >> >> but in general a lot of time(tottime, i.e. not subfunction time)
> spent
> > >> in
> > >> >> webob/dec.py(__call__), paste/urlmap.py(__call__),
> > >> >> webob/request.py(call_application),webob/request.py(send). What
> else
> > >> >> can
> > >> >> I
> > >> >> do to try and look for why this is taking so long?
> > >> >>
> > >> >> As a side question it seems counterintuitive that the uWSGI handles
> > >> >> most
> > >> >> of
> > >> >> the trunk RPC calls and not the RPC workers?
> > >> >>
> > >> >> A couple other notes about my environment that could indicate my
> > >> >> challenges:
> > >> >>
> > >> >> I had to disable rabbitmq heartbeats for neutron as they kept not
> > >> getting
> > >> >> sent reliably and connections were terminated. I tried with
> > >> >> heartbeat_in_pthread both true and false but still had issues. It
> > >> >> looks
> > >> >> like nova also sometimes experiences this but not near as often.
> > >> >>
> > >> >> I was overzealous with my vxlan ranges in my first configuration
> and
> > >> gave
> > >> >> it a range of 10,000,000 not realizing that would create that many
> > >> >> rows
> > >> >> in
> > >> >> the database. Looking into that I saw that pymysql in my cluster
> takes
> > >> >> 3.5
> > >> >> minutes to retrieve those rows. mysql CLI only takes 4 seconds.
> > >> >> Perhaps
> > >> >> that is just the overhead of pymysql? I've greatly scaled down the
> > >> >> vxlan
> > >> >> range now.
> > >> >>
> > >> >> I'm provisioning the 2 servers with a heat template that contains
> > >> >> around
> > >> >> 200 custom resources. For 198 of the resources they are set to
> > >> >> conditionally not create any OpenStack native resources. Deploying
> > >> >> this
> > >> >> template of mostly no-op resources still takes about 3 minutes.
> > >> >>
> > >> >> Horizon works but almost every page load take a few seconds to
> load.
> > >> >> I'm
> > >> >> not sure if that is normal or not.
> > >> >>
> > >> >> Thanks for any help anyone can provide.
> > >> >>
> > >> >> john
> > >> >>
> > >> >>
> > >> >
> > >>
> > >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230405/68aa4fce/attachment.htm>

From mnasiadka at gmail.com  Wed Apr  5 12:02:21 2023
From: mnasiadka at gmail.com (=?UTF-8?Q?Micha=C5=82_Nasiadka?=)
Date: Wed, 5 Apr 2023 14:02:21 +0200
Subject: [kolla] weekly meeting cancelled today
Message-ID: <CANhpHj_LrE7O74Ke0FXQ_Aciw_e2ggaxNU-8Nu=dTC8s8u=iSg@mail.gmail.com>

Hello Koalas,

Weekly meeting cancelled today.

Please note that our weekly meeting time for next week and onwards has
changed to 13:00 UTC due to DST changes.

Best regards,
Michal
-- 
Micha? Nasiadka
mnasiadka at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230405/765c7f16/attachment.htm>

From eblock at nde.ag  Wed Apr  5 12:11:22 2023
From: eblock at nde.ag (Eugen Block)
Date: Wed, 05 Apr 2023 12:11:22 +0000
Subject: [openstackclient] openstack cli broken after update to Wallaby
In-Reply-To: <20230404143428.Horde.MIPd5a2pT3yB3Ki3PoJBmOt@webmail.nde.ag>
Message-ID: <20230405121122.Horde.vYqpCCVOCkEmWr_L0Hwg2IH@webmail.nde.ag>

Update:
I reinstalled my lab environment with Wallaby from scratch, no  
upgrade, still the same error.
Then I reinstalled with Xena, with the same error. What am I missing here?
This is the Xena version of python3-openstackclient:

root at control01:~# apt show python3-openstackclient
Package: python3-openstackclient
Version: 5.6.0-0ubuntu1~cloud0

Any comments would be appreciated!
Thanks,
Eugen


Zitat von Eugen Block <eblock at nde.ag>:

> Hi *,
>
> today I upgraded my virtual test environment from V to W when  
> (Ubuntu 20.04) all of a sudden cli commands didn't work anymore with  
> this stack trace:
>
> ---snip---
> root at control01:~# openstack network agent list
> Traceback (most recent call last):
>   File "/usr/bin/openstack", line 6, in <module>
>     from openstackclient.shell import main
>   File "/usr/lib/python3/dist-packages/openstackclient/shell.py",  
> line 23, in <module>
>     from osc_lib import shell
>   File "/usr/lib/python3/dist-packages/osc_lib/shell.py", line 24,  
> in <module>
>     from cliff import app
>   File "/usr/lib/python3/dist-packages/cliff/app.py", line 22, in <module>
>     import cmd2
>   File "/usr/lib/python3/dist-packages/cmd2.py", line 585, in <module>
>     _ = pyperclip.paste()
>   File "/usr/lib/python3/dist-packages/pyperclip/__init__.py", line  
> 667, in lazy_load_stub_paste
>     copy, paste = determine_clipboard()
>   File "/usr/lib/python3/dist-packages/pyperclip/__init__.py", line  
> 558, in determine_clipboard
>     return init_gi_clipboard()
>   File "/usr/lib/python3/dist-packages/pyperclip/__init__.py", line  
> 167, in init_gi_clipboard
>     gi.require_version('Gtk', '3.0')
>   File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in  
> require_version
>     raise ValueError('Namespace %s not available' % namespace)
> ValueError: Namespace Gtk not available
> ---snip---
>
> I found this bug [1] describing the same issue but there has been no  
> progress. I posted my comments there as well. I found one way to get  
> the openstack shell to work by installing libgtk-3-dev (I found a  
> hint in a search engine). Apparently, python3-cmd2 requires  
> python3-pyperclip which requires python3-gi and so on. Is this  
> really the desired way? I didn't notice anything in the release  
> notes (maybe I missed it). When comparing to a different environment  
> (Victoria on baremetal) I see that libgtk-3 is installed there (not  
> -dev though), but even with libgtk-3-0 the error message was still  
> present. So the question is, which dependencies are missing where?  
> It's not really obvious to me. Could this already be fixed in Xena?  
> If it is fixed there I could do the double upgrade, of course,  
> especially since Wallaby is already under extended maintenance. Any  
> comments are appreciated.
>
> Thanks,
> Eugen
>
> [1]  
> https://bugs.launchpad.net/ubuntu/+source/python-openstackclient/+bug/1945661





From james.slagle at gmail.com  Wed Apr  5 12:16:59 2023
From: james.slagle at gmail.com (James Slagle)
Date: Wed, 5 Apr 2023 08:16:59 -0400
Subject: [tripleo] Nominate dbengt for tripleo-core !
In-Reply-To: <CAEggtay7MKKCUuDzvhhUitv=EgBRZMPjcdQ7cEDpjp0y04+SEg@mail.gmail.com>
References: <CAEggtay7MKKCUuDzvhhUitv=EgBRZMPjcdQ7cEDpjp0y04+SEg@mail.gmail.com>
Message-ID: <CAHV77z9D59GTy8_Or=iJc-2wit53W-3d3PGEA4zPPpMuhSKYWA@mail.gmail.com>

On Mon, Apr 3, 2023 at 1:17?PM Lukas Bezdicka <lbezdick at redhat.com> wrote:
> I'd like to nominate Daniel Bengtsson as tripleo-core. He works in upgrades and he'll have to maintain train, wallaby and zed for quite a while. He is a long term contributor to tripleo and oslo.

+1 from me. However, I'd like to clarify that Daniel does not intend
to maintain Zed. It was shared on the thread about the future of
TripleO[1], that the project team does not intend to maintain Zed.
There were no volunteers who indicated they were willing to do so on
that thread. I don't believe it to be the case that this tripleo-core
nomination is proposing that Daniel maintain Zed. If that is accurate,
then +1, otherwise I think we need some more clarification about the
intent.

[1] https://lists.openstack.org/pipermail/openstack-discuss/2023-March/thread.html




-- 
-- James Slagle
--


From marios at redhat.com  Wed Apr  5 12:41:06 2023
From: marios at redhat.com (Marios Andreou)
Date: Wed, 5 Apr 2023 15:41:06 +0300
Subject: [tripleo] hold rechecks content provider gate blocker
In-Reply-To: <CAM51kHXpCS0noueSBE=NO86ev_bvQL=15W1PydoWpHo-PcNyPg@mail.gmail.com>
References: <CAM51kHXpCS0noueSBE=NO86ev_bvQL=15W1PydoWpHo-PcNyPg@mail.gmail.com>
Message-ID: <CAM51kHUsBOwAjJbB5Qo1ikcCSNnV2xCHP5pb4RCLCNYVQbbvyA@mail.gmail.com>

an update:

we have a workaround with
https://review.opendev.org/c/openstack/tripleo-quickstart/+/879535/
and it is currently in the gate

The content providers will be unblocked once that merges

thank you

On Wed, Apr 5, 2023 at 11:04?AM Marios Andreou <marios at redhat.com> wrote:
>
> Hello tripleo
>
> we have a gate blocker at [1] hitting the centos-9-content-provider jobs.
>
> The tripleo CI team is tracking this - please hold rechecks until it
> we have a resolution or workaround
>
> regards, marios
>
> [1] https://bugs.launchpad.net/tripleo/+bug/2015309



From eblock at nde.ag  Wed Apr  5 13:12:04 2023
From: eblock at nde.ag (Eugen Block)
Date: Wed, 05 Apr 2023 13:12:04 +0000
Subject: [openstackclient] openstack cli broken after update to Wallaby
 [closed]
In-Reply-To: <20230405121122.Horde.vYqpCCVOCkEmWr_L0Hwg2IH@webmail.nde.ag>
References: <20230404143428.Horde.MIPd5a2pT3yB3Ki3PoJBmOt@webmail.nde.ag>
 <20230405121122.Horde.vYqpCCVOCkEmWr_L0Hwg2IH@webmail.nde.ag>
Message-ID: <20230405131204.Horde.T9C_7UQfwr56F9vdaT2OBg8@webmail.nde.ag>

I think this thread is invalid. It must have something to do with my  
VM image where I'm testing all of this. When I removed a lot of  
packages which I refer to openstack and then reinstalled only  
python3-openstackclient it works as expected in W, X and Y releases. I  
just didn't test the upgrade yet after cleaning up properly.  
Hopefully, this won't be an issue during the actual upgrade of the  
baremetal nodes.

Thanks,
Eugen

Zitat von Eugen Block <eblock at nde.ag>:

> Update:
> I reinstalled my lab environment with Wallaby from scratch, no  
> upgrade, still the same error.
> Then I reinstalled with Xena, with the same error. What am I missing here?
> This is the Xena version of python3-openstackclient:
>
> root at control01:~# apt show python3-openstackclient
> Package: python3-openstackclient
> Version: 5.6.0-0ubuntu1~cloud0
>
> Any comments would be appreciated!
> Thanks,
> Eugen
>
>
> Zitat von Eugen Block <eblock at nde.ag>:
>
>> Hi *,
>>
>> today I upgraded my virtual test environment from V to W when  
>> (Ubuntu 20.04) all of a sudden cli commands didn't work anymore  
>> with this stack trace:
>>
>> ---snip---
>> root at control01:~# openstack network agent list
>> Traceback (most recent call last):
>>  File "/usr/bin/openstack", line 6, in <module>
>>    from openstackclient.shell import main
>>  File "/usr/lib/python3/dist-packages/openstackclient/shell.py",  
>> line 23, in <module>
>>    from osc_lib import shell
>>  File "/usr/lib/python3/dist-packages/osc_lib/shell.py", line 24,  
>> in <module>
>>    from cliff import app
>>  File "/usr/lib/python3/dist-packages/cliff/app.py", line 22, in <module>
>>    import cmd2
>>  File "/usr/lib/python3/dist-packages/cmd2.py", line 585, in <module>
>>    _ = pyperclip.paste()
>>  File "/usr/lib/python3/dist-packages/pyperclip/__init__.py", line  
>> 667, in lazy_load_stub_paste
>>    copy, paste = determine_clipboard()
>>  File "/usr/lib/python3/dist-packages/pyperclip/__init__.py", line  
>> 558, in determine_clipboard
>>    return init_gi_clipboard()
>>  File "/usr/lib/python3/dist-packages/pyperclip/__init__.py", line  
>> 167, in init_gi_clipboard
>>    gi.require_version('Gtk', '3.0')
>>  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in  
>> require_version
>>    raise ValueError('Namespace %s not available' % namespace)
>> ValueError: Namespace Gtk not available
>> ---snip---
>>
>> I found this bug [1] describing the same issue but there has been  
>> no progress. I posted my comments there as well. I found one way to  
>> get the openstack shell to work by installing libgtk-3-dev (I found  
>> a hint in a search engine). Apparently, python3-cmd2 requires  
>> python3-pyperclip which requires python3-gi and so on. Is this  
>> really the desired way? I didn't notice anything in the release  
>> notes (maybe I missed it). When comparing to a different  
>> environment (Victoria on baremetal) I see that libgtk-3 is  
>> installed there (not -dev though), but even with libgtk-3-0 the  
>> error message was still present. So the question is, which  
>> dependencies are missing where? It's not really obvious to me.  
>> Could this already be fixed in Xena? If it is fixed there I could  
>> do the double upgrade, of course, especially since Wallaby is  
>> already under extended maintenance. Any comments are appreciated.
>>
>> Thanks,
>> Eugen
>>
>> [1]  
>> https://bugs.launchpad.net/ubuntu/+source/python-openstackclient/+bug/1945661





From Danny.Webb at thehutgroup.com  Wed Apr  5 13:29:11 2023
From: Danny.Webb at thehutgroup.com (Danny Webb)
Date: Wed, 5 Apr 2023 13:29:11 +0000
Subject: [openstackclient] openstack cli broken after update to Wallaby
 [closed]
In-Reply-To: <20230405131204.Horde.T9C_7UQfwr56F9vdaT2OBg8@webmail.nde.ag>
References: <20230404143428.Horde.MIPd5a2pT3yB3Ki3PoJBmOt@webmail.nde.ag>
 <20230405121122.Horde.vYqpCCVOCkEmWr_L0Hwg2IH@webmail.nde.ag>
 <20230405131204.Horde.T9C_7UQfwr56F9vdaT2OBg8@webmail.nde.ag>
Message-ID: <LO2P265MB5773EEE661BE5004CB1909479A909@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>

We tend to use python virtualenvs for the openstack cli as there are varying dependencies for the releases.  It also allows you to have multiple cli versions installed without conflicts.
________________________________
From: Eugen Block <eblock at nde.ag>
Sent: 05 April 2023 14:12
To: openstack-discuss at lists.openstack.org <openstack-discuss at lists.openstack.org>
Subject: Re: [openstackclient] openstack cli broken after update to Wallaby [closed]

CAUTION: This email originates from outside THG

I think this thread is invalid. It must have something to do with my
VM image where I'm testing all of this. When I removed a lot of
packages which I refer to openstack and then reinstalled only
python3-openstackclient it works as expected in W, X and Y releases. I
just didn't test the upgrade yet after cleaning up properly.
Hopefully, this won't be an issue during the actual upgrade of the
baremetal nodes.

Thanks,
Eugen

Zitat von Eugen Block <eblock at nde.ag>:

> Update:
> I reinstalled my lab environment with Wallaby from scratch, no
> upgrade, still the same error.
> Then I reinstalled with Xena, with the same error. What am I missing here?
> This is the Xena version of python3-openstackclient:
>
> root at control01:~# apt show python3-openstackclient
> Package: python3-openstackclient
> Version: 5.6.0-0ubuntu1~cloud0
>
> Any comments would be appreciated!
> Thanks,
> Eugen
>
>
> Zitat von Eugen Block <eblock at nde.ag>:
>
>> Hi *,
>>
>> today I upgraded my virtual test environment from V to W when
>> (Ubuntu 20.04) all of a sudden cli commands didn't work anymore
>> with this stack trace:
>>
>> ---snip---
>> root at control01:~# openstack network agent list
>> Traceback (most recent call last):
>> File "/usr/bin/openstack", line 6, in <module>
>> from openstackclient.shell import main
>> File "/usr/lib/python3/dist-packages/openstackclient/shell.py",
>> line 23, in <module>
>> from osc_lib import shell
>> File "/usr/lib/python3/dist-packages/osc_lib/shell.py", line 24,
>> in <module>
>> from cliff import app
>> File "/usr/lib/python3/dist-packages/cliff/app.py", line 22, in <module>
>> import cmd2
>> File "/usr/lib/python3/dist-packages/cmd2.py", line 585, in <module>
>> _ = pyperclip.paste()
>> File "/usr/lib/python3/dist-packages/pyperclip/__init__.py", line
>> 667, in lazy_load_stub_paste
>> copy, paste = determine_clipboard()
>> File "/usr/lib/python3/dist-packages/pyperclip/__init__.py", line
>> 558, in determine_clipboard
>> return init_gi_clipboard()
>> File "/usr/lib/python3/dist-packages/pyperclip/__init__.py", line
>> 167, in init_gi_clipboard
>> gi.require_version('Gtk', '3.0')
>> File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in
>> require_version
>> raise ValueError('Namespace %s not available' % namespace)
>> ValueError: Namespace Gtk not available
>> ---snip---
>>
>> I found this bug [1] describing the same issue but there has been
>> no progress. I posted my comments there as well. I found one way to
>> get the openstack shell to work by installing libgtk-3-dev (I found
>> a hint in a search engine). Apparently, python3-cmd2 requires
>> python3-pyperclip which requires python3-gi and so on. Is this
>> really the desired way? I didn't notice anything in the release
>> notes (maybe I missed it). When comparing to a different
>> environment (Victoria on baremetal) I see that libgtk-3 is
>> installed there (not -dev though), but even with libgtk-3-0 the
>> error message was still present. So the question is, which
>> dependencies are missing where? It's not really obvious to me.
>> Could this already be fixed in Xena? If it is fixed there I could
>> do the double upgrade, of course, especially since Wallaby is
>> already under extended maintenance. Any comments are appreciated.
>>
>> Thanks,
>> Eugen
>>
>> [1]
>> https://bugs.launchpad.net/ubuntu/+source/python-openstackclient/+bug/1945661<https://bugs.launchpad.net/ubuntu/+source/python-openstackclient/+bug/1945661>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230405/16f5847c/attachment-0001.htm>

From haleyb.dev at gmail.com  Wed Apr  5 13:37:35 2023
From: haleyb.dev at gmail.com (Brian Haley)
Date: Wed, 5 Apr 2023 09:37:35 -0400
Subject: [kolla-ansible][yoga][neutron][neutron-dhcp]ERRORS.... Need to
 understand
In-Reply-To: <8A7DB337-4B32-4A96-99E3-8E8430BED3C2@univ-grenoble-alpes.fr>
References: <21ECAC28-E3C9-4B18-8393-03C20F86F961@univ-grenoble-alpes.fr>
 <72a0a33f-af52-50b8-f059-fc7a5ccca20e@gmail.com>
 <8A7DB337-4B32-4A96-99E3-8E8430BED3C2@univ-grenoble-alpes.fr>
Message-ID: <cb5d0b83-102f-6b95-3208-c8fc20efb133@gmail.com>

Hi,

On 4/5/23 2:57 AM, Franck VEDEL wrote:
> Hi , and thanks a lot for your help.
> 
> so
> $ sudo ip netns exec qdhcp-8db375e0-28d2-4379-9330-397dc9b4f2b1 ip a
> 3401: tap1c220d25-b9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 68qdisc 
> noqueue state UNKNOWN group default qlen 1000
>  ? ? link/ether fa:16:3e:20:ef:bc brd ff:ff:ff:ff:ff:ff
>  ? ? inet 169.254.169.254/32 brd 169.254.169.254 scope global tap1c220d25-b9
>  ? ? ? ?valid_lft forever preferred_lft forever
>  ? ? inet 10.1.42.1/24 brd 10.1.42.255 scope global tap1c220d25-b9
>  ? ? ? ?valid_lft forever preferred_lft forever

Ok, so it is as I thought, someone has set a very small mtu on a network.

> $tail -f /var/log/kolla/neutron/neutron-dhcp-agent.log |grep 
> 8db375e0-28d2-4379-9330-397dc9b4f2b1
> 2023-04-05 08:36:11.558 7 INFO neutron.agent.dhcp.agent [-] Starting 
> network 8db375e0-28d2-4379-9330-397dc9b4f2b1 dhcp configuration
> 2023-04-05 08:36:12.532 7 ERROR neutron.agent.dhcp.agent [-] Unable to 
> enable dhcp for 8db375e0-28d2-4379-9330-397dc9b4f2b1.: 
> neutron.privileged.agent.linux.ip_lib.InvalidArgument: Invalid 
> parameter/value used on interface tap1c220d25-b9, namespace 
> qdhcp-8db375e0-28d2-4379-9330-397dc9b4f2b1.
> 2023-04-05 08:36:12.532 7 ERROR neutron.agent.dhcp.agent 
> neutron.privileged.agent.linux.ip_lib.InvalidArgument: Invalid 
> parameter/value used on interface tap1c220d25-b9, namespace 
> qdhcp-8db375e0-28d2-4379-9330-397dc9b4f2b1.
> 2023-04-05 08:36:12.534 7 INFO neutron.agent.dhcp.agent [-] Finished 
> network 8db375e0-28d2-4379-9330-397dc9b4f2b1 dhcp configuration
> 
> openstack network show 8db375e0-28d2-4379-9330-397dc9b4f2b1
> +---------------------------+--------------------------------------+
> | Field ? ? ? ? ? ? ? ? ? ? | Value ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> +---------------------------+--------------------------------------+
> | admin_state_up ? ? ? ? ? ?| UP ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | availability_zone_hints ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> | availability_zones ? ? ? ?| nova ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | created_at ? ? ? ? ? ? ? ?| 2023-04-04T11:49:47Z ? ? ? ? ? ? ? ? |
> | description ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> | dns_domain ? ? ? ? ? ? ? ?| None ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | id ? ? ? ? ? ? ? ? ? ? ? ?| 8db375e0-28d2-4379-9330-397dc9b4f2b1 |
> | ipv4_address_scope ? ? ? ?| None ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | ipv6_address_scope ? ? ? ?| None ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | is_default ? ? ? ? ? ? ? ?| None ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | is_vlan_transparent ? ? ? | None ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | mtu ? ? ? ? ? ? ? ? ? ? ? |68 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | name ? ? ? ? ? ? ? ? ? ? ?| NET1 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | port_security_enabled ? ? | True ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | project_id ? ? ? ? ? ? ? ?| 6d6cbcbb6e8d4264bcd13dd8b3d79466 ? ? |
> | provider:network_type ? ? | vxlan ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> | provider:physical_network | None ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | provider:segmentation_id ?| 456 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> | qos_policy_id ? ? ? ? ? ? | None ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | revision_number ? ? ? ? ? | 2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> | router:external ? ? ? ? ? | Internal ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | segments ? ? ? ? ? ? ? ? ?| None ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | shared ? ? ? ? ? ? ? ? ? ?| False ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> | status ? ? ? ? ? ? ? ? ? ?| ACTIVE ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | subnets ? ? ? ? ? ? ? ? ? |b72cf65c-1a22-4165-a55b-884bcc9c636a|
> | tags ? ? ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> | updated_at ? ? ? ? ? ? ? ?| 2023-04-04T11:49:47Z ? ? ? ? ? ? ? ? |
> +---------------------------+???????????????????+

Increasing the mtu on this network to at least 1280 should fix the issue 
with DHCP, that is the IPv6 minimum mtu and most likely causing the 
issue. You should check other networks and use the same value, but it is 
probably 1450 given the overlay is vxlan.

Since this is a known issue, there is no need for a new bug, but for 
your reference you can go to https://bugs.launchpad.net/neutron to 
search and file a new one.

Thanks,

-Brian


> 
> $openstack subnet showb72cf65c-1a22-4165-a55b-884bcc9c636a
> +----------------------+--------------------------------------+
> | Field ? ? ? ? ? ? ? ?| Value ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> +----------------------+--------------------------------------+
> | allocation_pools ? ? | 10.1.42.1-10.1.42.253 ? ? ? ? ? ? ? ?|
> | cidr ? ? ? ? ? ? ? ? | 10.1.42.0/24 ? ? ? ? ? ? ? ? ? ? ? ? |
> | created_at ? ? ? ? ? | 2023-04-04T11:49:47Z ? ? ? ? ? ? ? ? |
> | description ? ? ? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> | dns_nameservers ? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> | dns_publish_fixed_ip | None ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | enable_dhcp ? ? ? ? ?| True ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | gateway_ip ? ? ? ? ? | 10.1.42.254 ? ? ? ? ? ? ? ? ? ? ? ? ?|
> | host_routes ? ? ? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> | id ? ? ? ? ? ? ? ? ? | b72cf65c-1a22-4165-a55b-884bcc9c636a |
> | ip_version ? ? ? ? ? | 4 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> | ipv6_address_mode ? ?| None ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | ipv6_ra_mode ? ? ? ? | None ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | name ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> | network_id ? ? ? ? ? | 8db375e0-28d2-4379-9330-397dc9b4f2b1 |
> | project_id ? ? ? ? ? | 6d6cbcbb6e8d4264bcd13dd8b3d79466 ? ? |
> | revision_number ? ? ?| 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> | segment_id ? ? ? ? ? | None ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | service_types ? ? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> | subnetpool_id ? ? ? ?| None ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? |
> | tags ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?|
> | updated_at ? ? ? ? ? | 2023-04-04T11:49:47Z ? ? ? ? ? ? ? ? |
> +----------------------+--------------------------------------+
> 
> 
> Since yesterday, we have a lot of network (2 per students , 100 
> students) , so a lot of errors:
> In the log of dnsmask we can see this:
> Apr ?5 08:55:02 dnsmasq-dhcp[2466928]: read 
> /var/lib/neutron/dhcp/7d33855e-03a8-431b-9cf8-64f8e95b8f93/host
> Apr ?5 08:55:02 dnsmasq-dhcp[2466928]: read 
> /var/lib/neutron/dhcp/7d33855e-03a8-431b-9cf8-64f8e95b8f93/opts
> Apr ?5 08:55:05 dnsmasq-dhcp[609053]: DHCPDISCOVER(tap5af0e639-f3) 
> fa:16:3e:8d:86:b9 no address available
> Apr ?5 08:55:05 dnsmasq-dhcp[4572]: DHCPDISCOVER(tap6fe70972-c9) 
> fa:16:3e:6d:dc:c8 no address available
> 
> 
> You say: If that's not it please file a new bug with all the above info 
> provided.
> How can I do that ?
> 
> Thanks a lot
> 
> Franck
> 
> 
> 
> 
>> Le 5 avr. 2023 ? 00:00, Brian Haley <haleyb.dev at gmail.com 
>> <mailto:haleyb.dev at gmail.com>> a ?crit :
>>
>> 8db375e0-28d2-4379-9330-397dc9b4f2b1
> 


From ces.eduardo98 at gmail.com  Tue Apr  4 23:35:38 2023
From: ces.eduardo98 at gmail.com (Carlos Silva)
Date: Tue, 4 Apr 2023 20:35:38 -0300
Subject: [manila] Bobcat vPTG summary
Message-ID: <CAE51gQKBroyt3wWtJMCLFKH-TgZBihaQSLYt0NYeemnB0SrMvQ@mail.gmail.com>

Hello, Zorillas and interested stackers!

Thank you for attending last week's PTG. We had productive discussions and
came up with good plans for this cycle!

Here is a summary of the topics we spoke about during the PTG. The etherpad
with all the notes is available in [0]. If you would like to see the
recordings for those discussions, they are available on the Manila Youtube
channel [1].


   - *Share Transfer Future development*


   - Share transfers feature was introduced in Antelope but it has a couple
   of possible enhancements, such as: transferring shares that have snapshots,
   replicated shares, share networks alongside its share servers and shares.


   - Snapshots shouldn't be very difficult to cover but we would need to
   keep in mind quota allocations while doing so.


   - Transferring shares with replicas is the bigger challenge, considering
   we need to work with modifying the access rules.


   - The next step would be to work on transferring share networks.
   - AIs: Haixin plans to work on this feature during Bobcat.



   - *S-RBAC changes in Bobcat*


   - For the Bobcat cycle, we will focus on:


   - Ensure we are landing even more tests and enabling the oslo policy
   defaults.


   - Modify the testing we are doing to use the reader role to test
   read-only API, opposed to the member role.


   - Audit all cross service interactions and isolate actions performed by
   the "service" user.


   - Push for the completion of unit tests for Secure RBAC


   - AIs: Manila team will continue promoting events to get tests reviewed
   and implemented



   - *Cross project discussion with Nova for VirtIO FS *


   - Manila and Nova team discussed approaches for avoiding shares to be
   deleted while they are attached to instances.


   - We have agreed that an admin/service level API for locking/unlocking
   shares deletion would be the best solution to avoid shares being deleted
   while mounted. This API would ideally be a 'locked by <consumer>' action
   instead of a simple boolean


   - As part of this cross-project effort, the Manila team has also been
   focusing on getting more APIs available in OpenStack SDK. We have been
   making great progress with it and we plan to have all APIs nova is using
   merged in the OpenStack SDK by the bobcat cycle.


   - AIs:


   - Manila team to write a spec describing the behavior of the
   locking/unlocking API for share.


   - Manila team to focus on having all APIs nova is using in OpenStack SDK
   by the Bobcat cycle.



   - *Scalable NFS Ganesha for CephFS - state of the kitchen*


   - We have shared a status of what was our focus during the previous
   release and some important bugs that have been fixed.


   - Updates on moving from a standalone ganesha to a cephadm deployed:


   - There are three changes being worked on at the moment, after past
   discussions:


   - Ensure that the shares access rules will be applied when moving from
   the old to the new server


   - Ensure that the share exists in both old and new ganesha servers and
   to reapply all access rules in both


   - Change to represent export locations from both old and new export
   locations while both cephfs_nfs_cluster_id and ganesha_server_ips are
   present in the backend.


   - With these three changes we would cover all the scenarios considering
   release upgrades.


   - The changes are being tested and need feedback.


   - A job for automated testing is in progress. We are targeting to have a
   multi-node CI job that will be capable of deploying ganesha using cephadm
   and run tests using it.


   - AI: carloss and gouthamr will pursue closure for the three changes
   related to the upgrades and ashrodri will continue to work on the
   multi-node testing job.



   - *SQLAlchemy 2.0 and other DB challenges/changes*


   - DB testing is failing sporadically in the CI and we were discussing
   possible changes to avoid rechecks caused by sporadic failures.


   - We intend to work on missing indexes for queries, so we can gain
   performance in the database.


   - Implementing __repr__ to manila models


   - Other people are already doing this and this could be of huge help for
   debugging, as one of the operators suggested in the session


   - We will investigate and apply this in Manila


   - AIs: gouthamr will open bugs for tracking the work on the joinedloads
   and a blueprint for the missing indexes.


   - Sqlalchemy 2.0 changes have already started and we have a list of
   changes yet to merge. stephenfin is doing a great work on the changes.


   - AIs: manila team to review the changes proposed by stephenfin



   - *Create share from replicated snapshot / keep source share on replica
   promote*


   - Users of this feature are looking for a way to test the inactive
   replicas before actually promoting them and if everything is correct, they
   continue with the promotion.


   - One suggestion to get this working would be having a replication pause
   API, which would make the inactive instance able to be mounted


   - We do think this feature could be relevant and some suggestions from
   the Manila team are:


   - Letting users know if they can pause/unpause replication even before
   they create their share replicas


   - Making users able to know about errors in the API (something similar
   to the check mechanism on security-service-update)


   - AIs: carthaca and team will work on a spec and will discuss it further
   with the Manila team.



   - *Tech debt:*


   - We brought up the current issues with our CI, mostly caused by tests
   being very resource intensive.


   - We discussed approaches for scenario testing and thought it is worth
   it trying to create containers to mount share during scenario tests instead
   of spawning VMs.


   - Also, the audience has mentioned that it is difficult to keep track of
   all of these issues and it would be better if we had them documented
   somewhere, and that we could bring these up more often.


   - Migration to Ubuntu 22 is yet to complete for some jobs due to
   failures in package installation and the usage of quagga.


   - AIs:


   - carloss will work on a wiki with tech debt items and will bring this
   up more often in the manila weekly meetings, so if people are available in
   that time frame to work on them, they will have more chances to raise their
   hands.


   - carloss and gouthamr will work to fix the issues with jobs yet to
   migrate to Ubuntu 22



   - *Scheduler data placement based on vendor specific tool*


   - NetApp has a tool called Active IQ that uses machine learning to
   identify what is the best pool of disks to place a request based on custom
   parameters (latency, iops and so on)


   - They are thinking of trying to have this tool interact with Manila, so
   it would also benefit from their tool when NetApp is the only storage
   vendor in the cloud.


   - The suggestion is to have a new weigher that will make calls to the
   storage based on the request and use Active IQ response to identify where
   the share should be placed.


   - Testing this feature could be a challenge, considering that it's not
   straightforward to foresee what a weigher would return in a given moment


   - AIs: felipe_rodriguess alongside the NetApp team will work on a spec
   so this can be further discussed.


[0] https://etherpad.opendev.org/p/manila-bobcat-ptg
[1]
https://www.youtube.com/watch?v=gefbYrzRD04&list=PLnpzT0InFrqDW_djitgCiFzwhBFdvoRBC

Thank you!
carloss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230404/adcf6191/attachment-0001.htm>

From nguyenhuukhoinw at gmail.com  Wed Apr  5 14:48:45 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Wed, 5 Apr 2023 21:48:45 +0700
Subject: [cinder]cannot lauch instance with cinder volume
Message-ID: <CABAODReyES2btdt5aZB28_UYWNDz45M7p7K2w7_WgJfAWqpOUg@mail.gmail.com>

Hello guys.
I am using kolla-ansible yoga to deploy an openstack cluster, but when I
launch an instance with volume, it has errors.
but I can create volume first and boot from it. I am using Powerstore
5000Tb. Is it a bug?


672 ERROR oslo_messaging.rpc.server
[req-1a822ccd-1d3a-4f9a-a453-22d04f07f816 47cefefdadbe4bb584d8cf983de71eb5
708d7af8178143aab263d3942a124ec8 - - -] Exception during message handling:
cinder.exception.ImageCopyFailure: Failed to copy image to volume: Bad or
unexpected response from the storage volume backend API: Unable to fetch
connection information from backend: Bad or unexpected response from the
storage volume backend API: Failed to create PowerStore host .
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server Traceback (most
recent call last):
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server   File
"/var/lib/kolla/venv/lib/python3.8/site-packages/cinder/volume/driver.py",
line 1045, in _attach_volume
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server     conn =
self.initialize_connection(volume, properties)
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server   File
"/var/lib/kolla/venv/lib/python3.8/site-packages/cinder/volume/drivers/dell_emc/powerstore/driver.py",
line 153, in initialize_connection
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server     return
self.adapter.initialize_connection(volume, connector, **kwargs)
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server   File
"/var/lib/kolla/venv/lib/python3.8/site-packages/cinder/volume/drivers/dell_emc/powerstore/adapter.py",
line 272, in initialize_connection
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server
connection_properties = self._connect_volume(volume, connector)
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server   File
"/var/lib/kolla/venv/lib/python3.8/site-packages/cinder/volume/drivers/dell_emc/powerstore/adapter.py",
line 613, in _connect_volume
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server
chap_credentials, volume_lun = self._create_host_and_attach(
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server   File
"/var/lib/kolla/venv/lib/python3.8/site-packages/cinder/volume/drivers/dell_emc/powerstore/adapter.py",
line 602, in _create_host_and_attach
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server     host,
chap_credentials = self._create_host_if_not_exist(connector)
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server   File
"/var/lib/kolla/venv/lib/python3.8/site-packages/decorator.py", line 232,
in fun
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server     return
caller(func, *(extras + args), **kw)
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server   File
"/var/lib/kolla/venv/lib/python3.8/site-packages/cinder/coordination.py",
line 195, in _synchronized
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server     return
f(*a, **k)
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server   File
"/var/lib/kolla/venv/lib/python3.8/site-packages/cinder/volume/drivers/dell_emc/powerstore/adapter.py",
line 446, in _create_host_if_not_exist
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server     host =
self.client.create_host(host_name, ports)
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server   File
"/var/lib/kolla/venv/lib/python3.8/site-packages/cinder/volume/drivers/dell_emc/powerstore/client.py",
line 302, in create_host
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server     raise
exception.VolumeBackendAPIException(data=msg)
2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server
cinder.exception.VolumeBackendAPIException: Bad or unexpected response from
the storage volume backend API: Failed to create PowerStore host .



Nguyen Huu Khoi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230405/f9ca3484/attachment.htm>

From jay at gr-oss.io  Wed Apr  5 15:24:52 2023
From: jay at gr-oss.io (Jay Faulkner)
Date: Wed, 5 Apr 2023 08:24:52 -0700
Subject: [ironic][ptg] 2023.2 Work Items
Message-ID: <CA+sTGNfU7-8r=erVa9UiGr7b97ERgjC3936kAUmqkEgVfSEbjQ@mail.gmail.com>

Hey all,

As usual, I documented items we talked about working on in Bobcat in a
spec. Please go have a look and review it:
https://review.opendev.org/c/openstack/ironic-specs/+/879381

This will hopefully be published very soon at
https://specs.openstack.org/openstack/ironic-specs/#themes as our 2023.2
work items.

Thanks everyone for participating in our vPTG this cycle!

--
Jay Faulkner
Ironic PTL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230405/cb967dc2/attachment.htm>

From noonedeadpunk at gmail.com  Wed Apr  5 15:44:55 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Wed, 5 Apr 2023 17:44:55 +0200
Subject: [all] Hold your rechecks
Message-ID: <CAPd_6Av=uqJRUm2YDZty+wd6ZLBR_9tCW9y+GGE-0wZFa4ZVNw@mail.gmail.com>

Hi everyone,

Due to the recent update of gnupg2 package for CentOS Stream 9 to the
version 2.3.3-3, a lot of repositories, including BaseOS and NFV, are
failing to pass GPG check [1]. This affects all latest images,
including container and cloud ones. At the moment, images used in Zuul
are not affected, but this might change with the next periodic rebuild
unless the related BZ report is fixed.
Explicit execution of `rpm --import` can be used as a temporary workaround.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2184640


From satish.txt at gmail.com  Wed Apr  5 15:46:01 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 5 Apr 2023 11:46:01 -0400
Subject: multi-region deployment within datacenter scenario
Message-ID: <CAPgF-fqT1oVa-bYGFdzXUrTpLpuECiuo6RcuvxbnJ-8WZt_avA@mail.gmail.com>

Folks,

This is a very broad question and could have many answers but still wanted
to ask to see what people are thinking and doing.

We have DC with multiple racks and around 600 nodes so we are planning to
create 3 private openstack and each with 200 nodes. In other data centers
we have multiple 200 nodes openstack clusters and life is good. In the new
datacenter I am thinking of deploying the same way openstack but shared
keystone between multiple openstack environments to have a single place for
identification and I am going to call it 3 regions even it's in a single
DC. Hope shared keystone is helpful/easier for doing terrafrom work and
selecting region easily.

Other option I was thinking about to deploy cellv2 technology and put all
600 nodes in single cloud but always worried for operation point of view.
Now sure how many people running cellv2 successfully without pain. (Except
CERN)

If people running multi-region openstack cloud then please share some
thought and idea to make life easier. Not looking for best solution but
just clue to get idea to deploy and manage multiple openstack.

Thanks in advance.
S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230405/b8cd5b0e/attachment.htm>

From sbauza at redhat.com  Wed Apr  5 16:09:35 2023
From: sbauza at redhat.com (Sylvain Bauza)
Date: Wed, 5 Apr 2023 18:09:35 +0200
Subject: [all] Hold your rechecks
In-Reply-To: <CAPd_6Av=uqJRUm2YDZty+wd6ZLBR_9tCW9y+GGE-0wZFa4ZVNw@mail.gmail.com>
References: <CAPd_6Av=uqJRUm2YDZty+wd6ZLBR_9tCW9y+GGE-0wZFa4ZVNw@mail.gmail.com>
Message-ID: <CALOCmukk8j6Wc6Hb4dkeGVn7okWOWX-GL_T7zUF=kAKiXqJgkw@mail.gmail.com>

Le mer. 5 avr. 2023 ? 17:50, Dmitriy Rabotyagov <noonedeadpunk at gmail.com> a
?crit :

> Hi everyone,
>
> Due to the recent update of gnupg2 package for CentOS Stream 9 to the
> version 2.3.3-3, a lot of repositories, including BaseOS and NFV, are
> failing to pass GPG check [1]. This affects all latest images,
> including container and cloud ones. At the moment, images used in Zuul
> are not affected, but this might change with the next periodic rebuild
> unless the related BZ report is fixed.
> Explicit execution of `rpm --import` can be used as a temporary workaround.
>
>
To clarify, projects that run centos9stream jobs in check pipeline should
hold their rechecks, for sure, but for other services like Nova which
*don't* run c9s jobs on check (only on periodic-weekly), then they
shouldn't have those issues, right?
-S


> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2184640
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230405/d9dae63d/attachment-0001.htm>

From noonedeadpunk at gmail.com  Wed Apr  5 16:22:29 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Wed, 5 Apr 2023 18:22:29 +0200
Subject: [all] Hold your rechecks
In-Reply-To: <CALOCmukk8j6Wc6Hb4dkeGVn7okWOWX-GL_T7zUF=kAKiXqJgkw@mail.gmail.com>
References: <CAPd_6Av=uqJRUm2YDZty+wd6ZLBR_9tCW9y+GGE-0wZFa4ZVNw@mail.gmail.com>
 <CALOCmukk8j6Wc6Hb4dkeGVn7okWOWX-GL_T7zUF=kAKiXqJgkw@mail.gmail.com>
Message-ID: <CAPd_6AuCrCiHK9VZMGON_uNb=_Y-aZ3BL9BfugGG2rFDGscfiQ@mail.gmail.com>

Yes, sorry, I should have clarified that.
Only projects that do have CentOS 9 Stream jobs in their pipelines and
that are Voting should hold rechecks in case of issues with CentOS
jobs related to failed GPG check of packages/repos.

??, 5 ???. 2023??. ? 18:09, Sylvain Bauza <sbauza at redhat.com>:
>
>
>
> Le mer. 5 avr. 2023 ? 17:50, Dmitriy Rabotyagov <noonedeadpunk at gmail.com> a ?crit :
>>
>> Hi everyone,
>>
>> Due to the recent update of gnupg2 package for CentOS Stream 9 to the
>> version 2.3.3-3, a lot of repositories, including BaseOS and NFV, are
>> failing to pass GPG check [1]. This affects all latest images,
>> including container and cloud ones. At the moment, images used in Zuul
>> are not affected, but this might change with the next periodic rebuild
>> unless the related BZ report is fixed.
>> Explicit execution of `rpm --import` can be used as a temporary workaround.
>>
>
> To clarify, projects that run centos9stream jobs in check pipeline should hold their rechecks, for sure, but for other services like Nova which *don't* run c9s jobs on check (only on periodic-weekly), then they shouldn't have those issues, right?
> -S
>
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2184640
>>


From franck.vedel at univ-grenoble-alpes.fr  Wed Apr  5 20:15:41 2023
From: franck.vedel at univ-grenoble-alpes.fr (Franck VEDEL)
Date: Wed, 5 Apr 2023 22:15:41 +0200
Subject: [kolla-ansible][yoga][neutron][neutron-dhcp]ERRORS.... Need to
 understand
In-Reply-To: <cb5d0b83-102f-6b95-3208-c8fc20efb133@gmail.com>
References: <21ECAC28-E3C9-4B18-8393-03C20F86F961@univ-grenoble-alpes.fr>
 <72a0a33f-af52-50b8-f059-fc7a5ccca20e@gmail.com>
 <8A7DB337-4B32-4A96-99E3-8E8430BED3C2@univ-grenoble-alpes.fr>
 <cb5d0b83-102f-6b95-3208-c8fc20efb133@gmail.com>
Message-ID: <87EFAC21-369A-4E2D-885C-98B777AD1D2C@univ-grenoble-alpes.fr>

Hi,
thanks a lot Brian, 
and thanks to Sahid (for his help today, in french :) )
Problem is very small MTU.
a user (student) created a network with a small mtu (on the day of the final exam) and for the rest of the day, no more dhcp....
The problem is addressed here: https://bugs.launchpad.net/neutron/+bug/1988069 <https://bugs.launchpad.net/neutron/+bug/1988069>

Before I have time to update, if it happens again, I will know what to do?

Thanks a lot


Franck VEDEL
D?p. R?seaux Informatiques & T?l?coms
IUT1 - Univ GRENOBLE Alpes
0476824462
Stages, Alternance, Emploi.



> Le 5 avr. 2023 ? 15:37, Brian Haley <haleyb.dev at gmail.com> a ?crit :
> 
> Hi,
> 
> On 4/5/23 2:57 AM, Franck VEDEL wrote:
>> Hi , and thanks a lot for your help.
>> so
>> $ sudo ip netns exec qdhcp-8db375e0-28d2-4379-9330-397dc9b4f2b1 ip a
>> 3401: tap1c220d25-b9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 68qdisc noqueue state UNKNOWN group default qlen 1000
>>     link/ether fa:16:3e:20:ef:bc brd ff:ff:ff:ff:ff:ff
>>     inet 169.254.169.254/32 brd 169.254.169.254 scope global tap1c220d25-b9
>>        valid_lft forever preferred_lft forever
>>     inet 10.1.42.1/24 brd 10.1.42.255 scope global tap1c220d25-b9
>>        valid_lft forever preferred_lft forever
> 
> Ok, so it is as I thought, someone has set a very small mtu on a network.
> 
>> $tail -f /var/log/kolla/neutron/neutron-dhcp-agent.log |grep 8db375e0-28d2-4379-9330-397dc9b4f2b1
>> 2023-04-05 08:36:11.558 7 INFO neutron.agent.dhcp.agent [-] Starting network 8db375e0-28d2-4379-9330-397dc9b4f2b1 dhcp configuration
>> 2023-04-05 08:36:12.532 7 ERROR neutron.agent.dhcp.agent [-] Unable to enable dhcp for 8db375e0-28d2-4379-9330-397dc9b4f2b1.: neutron.privileged.agent.linux.ip_lib.InvalidArgument: Invalid parameter/value used on interface tap1c220d25-b9, namespace qdhcp-8db375e0-28d2-4379-9330-397dc9b4f2b1.
>> 2023-04-05 08:36:12.532 7 ERROR neutron.agent.dhcp.agent neutron.privileged.agent.linux.ip_lib.InvalidArgument: Invalid parameter/value used on interface tap1c220d25-b9, namespace qdhcp-8db375e0-28d2-4379-9330-397dc9b4f2b1.
>> 2023-04-05 08:36:12.534 7 INFO neutron.agent.dhcp.agent [-] Finished network 8db375e0-28d2-4379-9330-397dc9b4f2b1 dhcp configuration
>> openstack network show 8db375e0-28d2-4379-9330-397dc9b4f2b1
>> +---------------------------+--------------------------------------+
>> | Field                     | Value                                |
>> +---------------------------+--------------------------------------+
>> | admin_state_up            | UP                                   |
>> | availability_zone_hints   |                                      |
>> | availability_zones        | nova                                 |
>> | created_at                | 2023-04-04T11:49:47Z                 |
>> | description               |                                      |
>> | dns_domain                | None                                 |
>> | id                        | 8db375e0-28d2-4379-9330-397dc9b4f2b1 |
>> | ipv4_address_scope        | None                                 |
>> | ipv6_address_scope        | None                                 |
>> | is_default                | None                                 |
>> | is_vlan_transparent       | None                                 |
>> | mtu                       |68                               |
>> | name                      | NET1                                 |
>> | port_security_enabled     | True                                 |
>> | project_id                | 6d6cbcbb6e8d4264bcd13dd8b3d79466     |
>> | provider:network_type     | vxlan                                |
>> | provider:physical_network | None                                 |
>> | provider:segmentation_id  | 456                                  |
>> | qos_policy_id             | None                                 |
>> | revision_number           | 2                                    |
>> | router:external           | Internal                             |
>> | segments                  | None                                 |
>> | shared                    | False                                |
>> | status                    | ACTIVE                               |
>> | subnets                   |b72cf65c-1a22-4165-a55b-884bcc9c636a|
>> | tags                      |                                      |
>> | updated_at                | 2023-04-04T11:49:47Z                 |
>> +---------------------------+???????????????????+
> 
> Increasing the mtu on this network to at least 1280 should fix the issue with DHCP, that is the IPv6 minimum mtu and most likely causing the issue. You should check other networks and use the same value, but it is probably 1450 given the overlay is vxlan.
> 
> Since this is a known issue, there is no need for a new bug, but for your reference you can go to https://bugs.launchpad.net/neutron <https://bugs.launchpad.net/neutron> to search and file a new one.
> 
> Thanks,
> 
> -Brian
> 
> 
>> $openstack subnet showb72cf65c-1a22-4165-a55b-884bcc9c636a
>> +----------------------+--------------------------------------+
>> | Field                | Value                                |
>> +----------------------+--------------------------------------+
>> | allocation_pools     | 10.1.42.1-10.1.42.253                |
>> | cidr                 | 10.1.42.0/24                         |
>> | created_at           | 2023-04-04T11:49:47Z                 |
>> | description          |                                      |
>> | dns_nameservers      |                                      |
>> | dns_publish_fixed_ip | None                                 |
>> | enable_dhcp          | True                                 |
>> | gateway_ip           | 10.1.42.254                          |
>> | host_routes          |                                      |
>> | id                   | b72cf65c-1a22-4165-a55b-884bcc9c636a |
>> | ip_version           | 4                                    |
>> | ipv6_address_mode    | None                                 |
>> | ipv6_ra_mode         | None                                 |
>> | name                 |                                      |
>> | network_id           | 8db375e0-28d2-4379-9330-397dc9b4f2b1 |
>> | project_id           | 6d6cbcbb6e8d4264bcd13dd8b3d79466     |
>> | revision_number      | 0                                    |
>> | segment_id           | None                                 |
>> | service_types        |                                      |
>> | subnetpool_id        | None                                 |
>> | tags                 |                                      |
>> | updated_at           | 2023-04-04T11:49:47Z                 |
>> +----------------------+--------------------------------------+
>> Since yesterday, we have a lot of network (2 per students , 100 students) , so a lot of errors:
>> In the log of dnsmask we can see this:
>> Apr  5 08:55:02 dnsmasq-dhcp[2466928]: read /var/lib/neutron/dhcp/7d33855e-03a8-431b-9cf8-64f8e95b8f93/host
>> Apr  5 08:55:02 dnsmasq-dhcp[2466928]: read /var/lib/neutron/dhcp/7d33855e-03a8-431b-9cf8-64f8e95b8f93/opts
>> Apr  5 08:55:05 dnsmasq-dhcp[609053]: DHCPDISCOVER(tap5af0e639-f3) fa:16:3e:8d:86:b9 no address available
>> Apr  5 08:55:05 dnsmasq-dhcp[4572]: DHCPDISCOVER(tap6fe70972-c9) fa:16:3e:6d:dc:c8 no address available
>> You say: If that's not it please file a new bug with all the above info provided.
>> How can I do that ?
>> Thanks a lot
>> Franck
>>> Le 5 avr. 2023 ? 00:00, Brian Haley <haleyb.dev at gmail.com <mailto:haleyb.dev at gmail.com> <mailto:haleyb.dev at gmail.com <mailto:haleyb.dev at gmail.com>>> a ?crit :
>>> 
>>> 8db375e0-28d2-4379-9330-397dc9b4f2b1

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230405/c04bfa46/attachment-0001.htm>

From acozyurt at gmail.com  Wed Apr  5 21:35:56 2023
From: acozyurt at gmail.com (=?UTF-8?Q?Can_=C3=96zyurt?=)
Date: Thu, 6 Apr 2023 00:35:56 +0300
Subject: multi-region deployment within datacenter scenario
In-Reply-To: <CAPgF-fqT1oVa-bYGFdzXUrTpLpuECiuo6RcuvxbnJ-8WZt_avA@mail.gmail.com>
References: <CAPgF-fqT1oVa-bYGFdzXUrTpLpuECiuo6RcuvxbnJ-8WZt_avA@mail.gmail.com>
Message-ID: <CAMf4N72V5vMVdWEyU2c+MM_Xx25ZviRijnkM-eYsqTVbyVkCyg@mail.gmail.com>

It's totally okay to use regions as AZs if that's what you need,
unless you are planning to deploy in another city. Then you will be
already exhausting the term region and you will have been left with
much more to deal with. Ultimately it comes down to needs and future
plans.

Secondly, I think you should be fine with a single cell anyway as we
have much more in one cell. However experience may vary depending on
the volume and characteristics of the daily workload and the design of
the control plane, so maybe you should take someone else's word with
more in-depth knowledge for the guidance.

Cheers.

On Wed, 5 Apr 2023 at 18:47, Satish Patel <satish.txt at gmail.com> wrote:
>
> Folks,
>
> This is a very broad question and could have many answers but still wanted to ask to see what people are thinking and doing.
>
> We have DC with multiple racks and around 600 nodes so we are planning to create 3 private openstack and each with 200 nodes. In other data centers we have multiple 200 nodes openstack clusters and life is good. In the new datacenter I am thinking of deploying the same way openstack but shared keystone between multiple openstack environments to have a single place for identification and I am going to call it 3 regions even it's in a single DC. Hope shared keystone is helpful/easier for doing terrafrom work and selecting region easily.
>
> Other option I was thinking about to deploy cellv2 technology and put all 600 nodes in single cloud but always worried for operation point of view. Now sure how many people running cellv2 successfully without pain. (Except CERN)
>
> If people running multi-region openstack cloud then please share some thought and idea to make life easier. Not looking for best solution but just clue to get idea to deploy and manage multiple openstack.
>
> Thanks in advance.
> S
>
>


From cboylan at sapwetik.org  Wed Apr  5 21:37:45 2023
From: cboylan at sapwetik.org (Clark Boylan)
Date: Wed, 05 Apr 2023 14:37:45 -0700
Subject: [openstackclient] openstack cli broken after update to Wallaby
In-Reply-To: <20230404143428.Horde.MIPd5a2pT3yB3Ki3PoJBmOt@webmail.nde.ag>
References: <20230404143428.Horde.MIPd5a2pT3yB3Ki3PoJBmOt@webmail.nde.ag>
Message-ID: <bee8d618-ec90-478c-9ae9-b4c146137189@app.fastmail.com>

On Tue, Apr 4, 2023, at 7:34 AM, Eugen Block wrote:
> Hi *,
>
> today I upgraded my virtual test environment from V to W when (Ubuntu  
> 20.04) all of a sudden cli commands didn't work anymore with this  
> stack trace:
>
> ---snip---
> root at control01:~# openstack network agent list
> Traceback (most recent call last):
>    File "/usr/bin/openstack", line 6, in <module>
>      from openstackclient.shell import main
>    File "/usr/lib/python3/dist-packages/openstackclient/shell.py",  
> line 23, in <module>
>      from osc_lib import shell
>    File "/usr/lib/python3/dist-packages/osc_lib/shell.py", line 24, in <module>
>      from cliff import app
>    File "/usr/lib/python3/dist-packages/cliff/app.py", line 22, in <module>
>      import cmd2
>    File "/usr/lib/python3/dist-packages/cmd2.py", line 585, in <module>
>      _ = pyperclip.paste()
>    File "/usr/lib/python3/dist-packages/pyperclip/__init__.py", line  
> 667, in lazy_load_stub_paste
>      copy, paste = determine_clipboard()
>    File "/usr/lib/python3/dist-packages/pyperclip/__init__.py", line  
> 558, in determine_clipboard
>      return init_gi_clipboard()
>    File "/usr/lib/python3/dist-packages/pyperclip/__init__.py", line  
> 167, in init_gi_clipboard
>      gi.require_version('Gtk', '3.0')
>    File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in  
> require_version
>      raise ValueError('Namespace %s not available' % namespace)
> ValueError: Namespace Gtk not available
> ---snip---
>
> I found this bug [1] describing the same issue but there has been no  
> progress. I posted my comments there as well. I found one way to get  
> the openstack shell to work by installing libgtk-3-dev (I found a hint  
> in a search engine). Apparently, python3-cmd2 requires  
> python3-pyperclip which requires python3-gi and so on. Is this really  
> the desired way? I didn't notice anything in the release notes (maybe  
> I missed it). When comparing to a different environment (Victoria on  
> baremetal) I see that libgtk-3 is installed there (not -dev though),  
> but even with libgtk-3-0 the error message was still present. So the  
> question is, which dependencies are missing where? It's not really  
> obvious to me. Could this already be fixed in Xena? If it is fixed  
> there I could do the double upgrade, of course, especially since  
> Wallaby is already under extended maintenance. Any comments are  
> appreciated.

I know you've marked this invalid elsewhere, but I think there is an interesting problem somewhere here. In particular I've cloned https://github.com/asweigart/pyperclip which backs the pyperclip pypi package https://pypi.org/project/pyperclip/. Reading determine_clipboard() it seems to do all this extra work (on Linux anyway) if DISPLAY is set. One easy workaround may be to unset that env var in your terminals when running openstackclient.

That said looking more closely init_gi_clipboard() isn't in the current code base. Looking at the history of the project:
`git log -p | grep init_gi_clipboard` produces no results either. This makes me wonder where that is coming from and what version/source of pyperclip you are using. If I grab pyperclip 1.8.2 (which is the upper constraints version for wallaby and xena) from pypi this function doesn't appear to exist there either. It is possible they rewrote their git history at some point, but best I can tell your version of pyperclip doesn't share code or history with the version on pypi specified in upper constraints for wallaby and xena.

Also it looks like if you install xsel or xclip that pyperclip will prefer those tools over the gtk bindings.

>
> Thanks,
> Eugen
>
> [1]  
> https://bugs.launchpad.net/ubuntu/+source/python-openstackclient/+bug/1945661


From fungi at yuggoth.org  Wed Apr  5 22:20:27 2023
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 5 Apr 2023 22:20:27 +0000
Subject: [openstackclient] openstack cli broken after update to Wallaby
In-Reply-To: <bee8d618-ec90-478c-9ae9-b4c146137189@app.fastmail.com>
References: <20230404143428.Horde.MIPd5a2pT3yB3Ki3PoJBmOt@webmail.nde.ag>
 <bee8d618-ec90-478c-9ae9-b4c146137189@app.fastmail.com>
Message-ID: <20230405222027.i7t7zipwpjrdz5y5@yuggoth.org>

On 2023-04-05 14:37:45 -0700 (-0700), Clark Boylan wrote:
[...]
> That said looking more closely init_gi_clipboard() isn't in the
> current code base. Looking at the history of the project:
> `git log -p | grep init_gi_clipboard` produces no results either.
> This makes me wonder where that is coming from and what
> version/source of pyperclip you are using. If I grab pyperclip
> 1.8.2 (which is the upper constraints version for wallaby and
> xena) from pypi this function doesn't appear to exist there
> either. It is possible they rewrote their git history at some
> point, but best I can tell your version of pyperclip doesn't share
> code or history with the version on pypi specified in upper
> constraints for wallaby and xena.
[...]

Tracking this down, it looks like a pyperclip package from a Linux
distribution is leaking into that environment. The relevant
functions can be found added by Ubuntu's
0001-Switch-from-GTK-2-to-GTK-3-to-avoid-import-of-mutual.patch
which references https://bugzilla.gnome.org/show_bug.cgi?id=709183
as the reason for its inclusion. Other distros have copies of this
patch into their packages as well (at least Debian does, not sure
which others might), but mixing packages of Python libs from a Linux
distribution and from PyPI in the same environment is a recipe for
disaster.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230405/8d9c5d1a/attachment.sig>

From satish.txt at gmail.com  Thu Apr  6 00:24:51 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 5 Apr 2023 20:24:51 -0400
Subject: multi-region deployment within datacenter scenario
In-Reply-To: <CAMf4N72V5vMVdWEyU2c+MM_Xx25ZviRijnkM-eYsqTVbyVkCyg@mail.gmail.com>
References: <CAPgF-fqT1oVa-bYGFdzXUrTpLpuECiuo6RcuvxbnJ-8WZt_avA@mail.gmail.com>
 <CAMf4N72V5vMVdWEyU2c+MM_Xx25ZviRijnkM-eYsqTVbyVkCyg@mail.gmail.com>
Message-ID: <CAPgF-fqSEQQDmEygJ+ybsjj7YC8tb-mO8hBrOs=xmLe=MatfWQ@mail.gmail.com>

Hi Can,

You are saying a single control plan can handle 600 compute nodes?

On Wed, Apr 5, 2023 at 5:36?PM Can ?zyurt <acozyurt at gmail.com> wrote:

> It's totally okay to use regions as AZs if that's what you need,
> unless you are planning to deploy in another city. Then you will be
> already exhausting the term region and you will have been left with
> much more to deal with. Ultimately it comes down to needs and future
> plans.
>
> Secondly, I think you should be fine with a single cell anyway as we
> have much more in one cell. However experience may vary depending on
> the volume and characteristics of the daily workload and the design of
> the control plane, so maybe you should take someone else's word with
> more in-depth knowledge for the guidance.
>
> Cheers.
>
> On Wed, 5 Apr 2023 at 18:47, Satish Patel <satish.txt at gmail.com> wrote:
> >
> > Folks,
> >
> > This is a very broad question and could have many answers but still
> wanted to ask to see what people are thinking and doing.
> >
> > We have DC with multiple racks and around 600 nodes so we are planning
> to create 3 private openstack and each with 200 nodes. In other data
> centers we have multiple 200 nodes openstack clusters and life is good. In
> the new datacenter I am thinking of deploying the same way openstack but
> shared keystone between multiple openstack environments to have a single
> place for identification and I am going to call it 3 regions even it's in a
> single DC. Hope shared keystone is helpful/easier for doing terrafrom work
> and selecting region easily.
> >
> > Other option I was thinking about to deploy cellv2 technology and put
> all 600 nodes in single cloud but always worried for operation point of
> view. Now sure how many people running cellv2 successfully without pain.
> (Except CERN)
> >
> > If people running multi-region openstack cloud then please share some
> thought and idea to make life easier. Not looking for best solution but
> just clue to get idea to deploy and manage multiple openstack.
> >
> > Thanks in advance.
> > S
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230405/90d1bef1/attachment.htm>

From gregory.orange at pawsey.org.au  Thu Apr  6 01:59:24 2023
From: gregory.orange at pawsey.org.au (Gregory Orange)
Date: Thu, 6 Apr 2023 09:59:24 +0800
Subject: [neutron] [kolla-ansible] alembic mismatch, schema differences
Message-ID: <d7cae712-bf0c-9144-38cb-ad8fe61f6d54@pawsey.org.au>

Hi all,

We've caused ourselves some bother with our neutron database, and I 
found the following thread instructive, so I hope we can get some help 
to resolve the bother.
https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031312.html

We're running kolla-ansible train (yes, upgrades planned). We wanted to 
test something with a wallaby container, and while mainly just pulling 
train versions of containers on a single compute node, we also changed 
openstack_release variable to wallaby in globals.yml - this was the mistake.

Later that day, we ran kolla-ansible deploy --limit $HOST for a new 
compute node. We stopped at the following error, realising the above 
mistake.
---
2023-04-05 12:25:50.487 7 ERROR nova 
nova.exception.TooOldComputeService: Current Nova version does not 
support computes older than Victoria but the minimum compute service 
level in your cell is 40 and the oldest supported service level is 52.
2023-04-05 12:25:50.487 7 ERROR nova
---

Now when we deploy a node it gets to task "Running Neutron bootstrap 
container" and gives error:
----
"alembic.script.revision.ResolutionError: No such revision or branch 
'6135a7bd4425'"
----

Using insight from the above list thread, I fetched DB entries:
MariaDB [neutron]> select * from alembic_version;
+--------------+
| version_num  |
+--------------+
| 5c85685d616d |
| 6135a7bd4425 |
+--------------+

Running the same from the test cluster which was deployed in the same way:
MariaDB [neutron]> select * from alembic_version;
+--------------+
| version_num  |
+--------------+
| 5c85685d616d |
| c613d0b82681 |
+--------------+

Also, comparing `neutron-db-manage history --verbose` across the two 
clusters, output is the same in both test and prod, except for the order 
of 2 lines:
----
-Branches into: 56893333aa52, 30018084ed99
-Branches into: c40fbb377ad, 67c8e8d61d5
+Branches into: 30018084ed99, 56893333aa52
+Branches into: 67c8e8d61d5, c40fbb377ad
----

Finally, I looked at the schema of the neutron database across the two. 
There are significant differences.
for i in `mysql neutron -bNe "show tables;"`; do echo "TABLE: $i"; mysql 
neutron -e "desc $i;"; done > prod-neutron-descs
Repeat for test.
$ cat prod-neutron-descs | nc termbin.com 9999
https://termbin.com/8ppi
$ cat test-neutron-descs | nc termbin.com 9999
https://termbin.com/cfqz

Our cluster and Neutron in particular is operating fine, but we can't 
deploy new nodes to it.

May I have some help on how to resolve this?

Thank you,
Greg.


From nguyenhuukhoinw at gmail.com  Thu Apr  6 03:02:48 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Thu, 6 Apr 2023 10:02:48 +0700
Subject: [cinder]cannot lauch instance with cinder volume
In-Reply-To: <CABAODReyES2btdt5aZB28_UYWNDz45M7p7K2w7_WgJfAWqpOUg@mail.gmail.com>
References: <CABAODReyES2btdt5aZB28_UYWNDz45M7p7K2w7_WgJfAWqpOUg@mail.gmail.com>
Message-ID: <CABAODRep0JhsLKGDmxpr+GV0JX2oFUvuvHMKom+vcNtV2Rw_iQ@mail.gmail.com>

Hello guys.
I update this error happened because when I destroy and redeploy I
don't remove hosts and its initiator. just remove them, it will be ok.
Nguyen Huu Khoi


On Wed, Apr 5, 2023 at 9:48?PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Hello guys.
> I am using kolla-ansible yoga to deploy an openstack cluster, but when I
> launch an instance with volume, it has errors.
> but I can create volume first and boot from it. I am using Powerstore
> 5000Tb. Is it a bug?
>
>
> 672 ERROR oslo_messaging.rpc.server
> [req-1a822ccd-1d3a-4f9a-a453-22d04f07f816 47cefefdadbe4bb584d8cf983de71eb5
> 708d7af8178143aab263d3942a124ec8 - - -] Exception during message handling:
> cinder.exception.ImageCopyFailure: Failed to copy image to volume: Bad or
> unexpected response from the storage volume backend API: Unable to fetch
> connection information from backend: Bad or unexpected response from the
> storage volume backend API: Failed to create PowerStore host .
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server Traceback
> (most recent call last):
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.8/site-packages/cinder/volume/driver.py",
> line 1045, in _attach_volume
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server     conn =
> self.initialize_connection(volume, properties)
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.8/site-packages/cinder/volume/drivers/dell_emc/powerstore/driver.py",
> line 153, in initialize_connection
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server     return
> self.adapter.initialize_connection(volume, connector, **kwargs)
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.8/site-packages/cinder/volume/drivers/dell_emc/powerstore/adapter.py",
> line 272, in initialize_connection
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server
> connection_properties = self._connect_volume(volume, connector)
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.8/site-packages/cinder/volume/drivers/dell_emc/powerstore/adapter.py",
> line 613, in _connect_volume
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server
> chap_credentials, volume_lun = self._create_host_and_attach(
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.8/site-packages/cinder/volume/drivers/dell_emc/powerstore/adapter.py",
> line 602, in _create_host_and_attach
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server     host,
> chap_credentials = self._create_host_if_not_exist(connector)
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.8/site-packages/decorator.py", line 232,
> in fun
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server     return
> caller(func, *(extras + args), **kw)
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.8/site-packages/cinder/coordination.py",
> line 195, in _synchronized
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server     return
> f(*a, **k)
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.8/site-packages/cinder/volume/drivers/dell_emc/powerstore/adapter.py",
> line 446, in _create_host_if_not_exist
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server     host =
> self.client.create_host(host_name, ports)
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.8/site-packages/cinder/volume/drivers/dell_emc/powerstore/client.py",
> line 302, in create_host
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server     raise
> exception.VolumeBackendAPIException(data=msg)
> 2023-04-05 21:24:30.886 672 ERROR oslo_messaging.rpc.server
> cinder.exception.VolumeBackendAPIException: Bad or unexpected response from
> the storage volume backend API: Failed to create PowerStore host .
>
>
>
> Nguyen Huu Khoi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/cd068257/attachment.htm>

From pdeore at redhat.com  Thu Apr  6 05:38:56 2023
From: pdeore at redhat.com (Pranali Deore)
Date: Thu, 6 Apr 2023 11:08:56 +0530
Subject: [Glance] Weekly Meeting Cancelled
Message-ID: <CADkbuWjrWpykFD0w8ziso2m_O__=xOFzhE83N0sPuSD8itdymg@mail.gmail.com>

Hi All,

Canceling today's glance weekly meeting, I'm on sick leave today.

See you next week !

Thanks,
Pranali D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/35f9377b/attachment.htm>

From acozyurt at gmail.com  Thu Apr  6 06:54:17 2023
From: acozyurt at gmail.com (=?UTF-8?Q?Can_=C3=96zyurt?=)
Date: Thu, 6 Apr 2023 09:54:17 +0300
Subject: multi-region deployment within datacenter scenario
In-Reply-To: <CAPgF-fqSEQQDmEygJ+ybsjj7YC8tb-mO8hBrOs=xmLe=MatfWQ@mail.gmail.com>
References: <CAPgF-fqT1oVa-bYGFdzXUrTpLpuECiuo6RcuvxbnJ-8WZt_avA@mail.gmail.com>
 <CAMf4N72V5vMVdWEyU2c+MM_Xx25ZviRijnkM-eYsqTVbyVkCyg@mail.gmail.com>
 <CAPgF-fqSEQQDmEygJ+ybsjj7YC8tb-mO8hBrOs=xmLe=MatfWQ@mail.gmail.com>
Message-ID: <CAMf4N71pBZAoubGCtTMh+O-sJG28+EmgRuzGYrBBidtQ-AFJMw@mail.gmail.com>

Hi,

Technically yes. We have had more than a thousand nodes in a single
cell for years on production. But we are considering adding more cells
as we grow bigger and bigger.

On Thu, 6 Apr 2023 at 03:25, Satish Patel <satish.txt at gmail.com> wrote:
>
> Hi Can,
>
> You are saying a single control plan can handle 600 compute nodes?
>
> On Wed, Apr 5, 2023 at 5:36?PM Can ?zyurt <acozyurt at gmail.com> wrote:
>>
>> It's totally okay to use regions as AZs if that's what you need,
>> unless you are planning to deploy in another city. Then you will be
>> already exhausting the term region and you will have been left with
>> much more to deal with. Ultimately it comes down to needs and future
>> plans.
>>
>> Secondly, I think you should be fine with a single cell anyway as we
>> have much more in one cell. However experience may vary depending on
>> the volume and characteristics of the daily workload and the design of
>> the control plane, so maybe you should take someone else's word with
>> more in-depth knowledge for the guidance.
>>
>> Cheers.
>>
>> On Wed, 5 Apr 2023 at 18:47, Satish Patel <satish.txt at gmail.com> wrote:
>> >
>> > Folks,
>> >
>> > This is a very broad question and could have many answers but still wanted to ask to see what people are thinking and doing.
>> >
>> > We have DC with multiple racks and around 600 nodes so we are planning to create 3 private openstack and each with 200 nodes. In other data centers we have multiple 200 nodes openstack clusters and life is good. In the new datacenter I am thinking of deploying the same way openstack but shared keystone between multiple openstack environments to have a single place for identification and I am going to call it 3 regions even it's in a single DC. Hope shared keystone is helpful/easier for doing terrafrom work and selecting region easily.
>> >
>> > Other option I was thinking about to deploy cellv2 technology and put all 600 nodes in single cloud but always worried for operation point of view. Now sure how many people running cellv2 successfully without pain. (Except CERN)
>> >
>> > If people running multi-region openstack cloud then please share some thought and idea to make life easier. Not looking for best solution but just clue to get idea to deploy and manage multiple openstack.
>> >
>> > Thanks in advance.
>> > S
>> >
>> >


From eblock at nde.ag  Thu Apr  6 07:31:53 2023
From: eblock at nde.ag (Eugen Block)
Date: Thu, 06 Apr 2023 07:31:53 +0000
Subject: [openstackclient] openstack cli broken after update to Wallaby
In-Reply-To: <20230405222027.i7t7zipwpjrdz5y5@yuggoth.org>
References: <20230404143428.Horde.MIPd5a2pT3yB3Ki3PoJBmOt@webmail.nde.ag>
 <bee8d618-ec90-478c-9ae9-b4c146137189@app.fastmail.com>
 <20230405222027.i7t7zipwpjrdz5y5@yuggoth.org>
Message-ID: <20230406073153.Horde.p_0uBnyvKZpLcjMf4D_jCr0@webmail.nde.ag>

Hi, thanks for your efforts. I don't mind continuing this discussion.  
I just reset my VM to the snapshot which I use as a starting point.  
There is currently no pyperclip installed:

root at control01:~# dpkg -l | grep pyperclip

root at control01:~# apt-cache search pyperclip
python3-pyperclip - Cross-platform clipboard module for Python3

root at control01:~# apt show python3-pyperclip
Package: python3-pyperclip
Version: 1.7.0-1

The package would be installed from the main repo  
(ubuntu-2004-amd64-main-amd64). This is the state before I install any  
openstack related packages.

> Also it looks like if you install xsel or xclip that pyperclip will  
> prefer those tools over the gtk bindings.

I did try that with xsel but it didn't work either.

> Other distros have copies of this patch into their packages as well  
> (at least Debian does, not sure
which others might), but mixing packages of Python libs from a Linux  
distribution and from PyPI in the same environment is a recipe for  
disaster.

I understand, but how does PyPI get into this environment? How could I  
find out?

Thanks,
Eugen

Zitat von Jeremy Stanley <fungi at yuggoth.org>:

> On 2023-04-05 14:37:45 -0700 (-0700), Clark Boylan wrote:
> [...]
>> That said looking more closely init_gi_clipboard() isn't in the
>> current code base. Looking at the history of the project:
>> `git log -p | grep init_gi_clipboard` produces no results either.
>> This makes me wonder where that is coming from and what
>> version/source of pyperclip you are using. If I grab pyperclip
>> 1.8.2 (which is the upper constraints version for wallaby and
>> xena) from pypi this function doesn't appear to exist there
>> either. It is possible they rewrote their git history at some
>> point, but best I can tell your version of pyperclip doesn't share
>> code or history with the version on pypi specified in upper
>> constraints for wallaby and xena.
> [...]
>
> Tracking this down, it looks like a pyperclip package from a Linux
> distribution is leaking into that environment. The relevant
> functions can be found added by Ubuntu's
> 0001-Switch-from-GTK-2-to-GTK-3-to-avoid-import-of-mutual.patch
> which references https://bugzilla.gnome.org/show_bug.cgi?id=709183
> as the reason for its inclusion. Other distros have copies of this
> patch into their packages as well (at least Debian does, not sure
> which others might), but mixing packages of Python libs from a Linux
> distribution and from PyPI in the same environment is a recipe for
> disaster.
> --
> Jeremy Stanley





From rdhasman at redhat.com  Thu Apr  6 07:33:04 2023
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Thu, 6 Apr 2023 13:03:04 +0530
Subject: [cinder]multi backend SAN and Ceph
In-Reply-To: <CABAODReQ-GY07WO-H=+2WYvWK+4BLx7BzDe2j=fNRFjFRKxQZA@mail.gmail.com>
References: <CABAODRet93Qw7eLtd0ZAkhRCq1E++nA91LW+o+1FidfUuottvQ@mail.gmail.com>
 <CAPd_6Avs0G3+JdULtY1P7oQ1XaPaROHg-Xk+m4XRPh8ZhBTQ8g@mail.gmail.com>
 <CABAODReQ-GY07WO-H=+2WYvWK+4BLx7BzDe2j=fNRFjFRKxQZA@mail.gmail.com>
Message-ID: <CAARK8KSZXs_Y9PM_KEKS9uGY8CUB0xwn7k7onb-AX2=GUA5+8A@mail.gmail.com>

Hi Nguy?n,

Cinder does support configuring multiple storage backends where each
backend runs under its own cinder-volume service.
Different deployments will have different ways to configure multiple
backends and you can refer to their documentation.
You can configure a specific volume type for a particular backend and
retype between the two backends if possible (there
are checks that won't allow it in certain conditions).
You can follow this[1] documentation for reference. Hope that helps.

[1] https://docs.openstack.org/cinder/latest/admin/multi-backend.html

Thanks
Rajat Dhasmana

On Sun, Apr 2, 2023 at 11:31?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> I ask becasuse I have no see docs which talked about.
> I will lab and update you.
> Many thanks for quick response. Have a nice weekend.
>
>
>
> On Sun, Apr 2, 2023, 12:43 PM Dmitriy Rabotyagov <noonedeadpunk at gmail.com>
> wrote:
>
>> I don't see any reason why this won't be possible. Though, I would likely
>> used different sets of cinder-volume services for that, as while Ceph does
>> support active-active setup, I'm not sure your NAS driver does - it's worth
>> checking your specific driver with this matrix:
>> https://docs.openstack.org/cinder/latest/reference/support-matrix.html
>>
>> Regarding changing volume types, I assume you mean basically volume
>> retypes. It actually depends on the format of images that are stored on the
>> backend, as cinder does not execute type conversion during retype. So if
>> your NAS storage stores in RAW as Ceph does, this should work, I assume.
>>
>> ??, 2 ???. 2023 ?., 06:48 Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>:
>>
>>> Hello.
>>> I have a question that could we use both SAN and Ceph for multi backend?
>>> If yes can we change volume type from SAN to Ceph and otherwise?
>>> Thanks.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/12fb1a3a/attachment.htm>

From rdhasman at redhat.com  Thu Apr  6 07:39:02 2023
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Thu, 6 Apr 2023 13:09:02 +0530
Subject: Does cinder-backup support multi-backend?
In-Reply-To: <CABAODReU3fBhPi0co77y=2qXM+u1u8mVpH4XxRiXVoX12_hsnw@mail.gmail.com>
References: <CAJV_UBAwDcy7Adob712AVYa0uK0txsoJbi3U83Fjy2G6UFhyiQ@mail.gmail.com>
 <CABAODRfY9v6muyZw34yxk25npgFUc4LfTe594Ng8VUUXA334DQ@mail.gmail.com>
 <CABAODRd=ps4S8pPcHgSkpdyKzbwtkS6_YXzUZpx1dU71NXNDRg@mail.gmail.com>
 <CABAODRedjYcb0NDeemMHCfSMSiken=iaDQqpkQQVq57dE+XiaA@mail.gmail.com>
 <CABAODReU3fBhPi0co77y=2qXM+u1u8mVpH4XxRiXVoX12_hsnw@mail.gmail.com>
Message-ID: <CAARK8KTgRYDGG=ZsckZD_3-_yXR8NpHAzZa-4sT_m-iPto2KrQ@mail.gmail.com>

Hi Wodel,

Currently configuring multiple cinder backup backends is not supported.
This was brought up in our last cinder meeting on 06 April, 2023[1].
A spec was proposed to implement this[2] but there aren't any patches to
implement this.
Christian Rohmann (crohmann on IRC) has shown interest in this topic, so
probably you can contact him about the details and can collaborate on the
effort.

[1]
https://meetings.opendev.org/irclogs/%23openstack-meeting-alt/%23openstack-meeting-alt.2023-04-05.log.html#t2023-04-05T14:50:24
[2] https://review.opendev.org/c/openstack/cinder-specs/+/712301

Thanks
Rajat Dhasmana

On Sun, Apr 2, 2023 at 6:49?PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> https://blueprints.launchpad.net/cinder/+spec/backup-backends-configuration
>
> I just read and test later.
>
> On Sun, Apr 2, 2023, 8:05 PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> wrote:
>
>> Oh. Sr. U asked for cinder-backup. My mistake.
>>
>> On Sun, Apr 2, 2023, 8:03 PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
>> wrote:
>>
>>> I just ask today.
>>> https://docs.openstack.org/cinder/latest/reference/support-matrix.html
>>>
>>>
>>> https://www.google.com/amp/s/www.openstackfaq.com/cinder-multiple-backends/%3famp
>>>
>>> On Sun, Apr 2, 2023, 8:00 PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
>>> wrote:
>>>
>>>> Yes, it can be done.
>>>>
>>>> On Sun, Apr 2, 2023, 7:58 PM wodel youchi <wodel.youchi at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Could cinder-backup be configured with multiple-backends, ceph and nfs
>>>>> for example?
>>>>>
>>>>> Regards.
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/85947654/attachment.htm>

From rdhasman at redhat.com  Thu Apr  6 08:40:21 2023
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Thu, 6 Apr 2023 14:10:21 +0530
Subject: [cinder] 2023.2 Bobcat PTG Summary
Message-ID: <CAARK8KQWFOr+e7w4VCn6Zfwm+DQ5Ru-biv1C8ZW0KvTjcYSVTA@mail.gmail.com>

Hello,

Please find the summary of 2023.2 Bobcat PTG in the wiki page[1]. It
includes recordings, summary and action items for each topic. More details
can be found in the PTG etherpad[2].

I would recommend everyone to please look for the action items assigned to
you to plan it according to the cycle deadlines.

[1] https://wiki.openstack.org/wiki/CinderBobcatPTGSummary
[2] https://etherpad.opendev.org/p/bobcat-ptg-cinder

Thanks
Rajat Dhasmana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/4354ca50/attachment.htm>

From richard.buregeya at bsc.rw  Thu Apr  6 08:53:18 2023
From: richard.buregeya at bsc.rw (Richard Buregeya)
Date: Thu, 6 Apr 2023 08:53:18 +0000
Subject: No subject
In-Reply-To: <AM9PR03MB6705652785085FF563AB3B11F0929@AM9PR03MB6705.eurprd03.prod.outlook.com>
References: <DBBPR03MB671641ECA823C20815CDC232F0929@DBBPR03MB6716.eurprd03.prod.outlook.com>
 <3128971B-5A02-44E2-9F6E-6E01B82BFB31@openinfra.dev>
 <AM9PR03MB6705C59D076400A51B614C6AF0929@AM9PR03MB6705.eurprd03.prod.outlook.com>
 <AM9PR03MB6705652785085FF563AB3B11F0929@AM9PR03MB6705.eurprd03.prod.outlook.com>
Message-ID: <DBBPR03MB6716DA498F2D96BD91CA9D40F0919@DBBPR03MB6716.eurprd03.prod.outlook.com>

Hello Team,

Is there anywhere I can get valid Exam dumps for COA exam,

If anyone can assist me.

Regards

From: Richard Buregeya
Sent: Monday, April 3, 2023 6:40 PM
To: Richard Buregeya <richard.buregeya at bsc.rw>; Jimmy McArthur <jimmy at openinfra.dev>
Cc: openstack-discuss at lists.openstack.org
Subject: RE:

Thanks @Jimmy McArthur<mailto:jimmy at openinfra.dev>

From: Richard Buregeya <richard.buregeya at bsc.rw<mailto:richard.buregeya at bsc.rw>>
Sent: Monday, April 3, 2023 6:27 PM
To: Jimmy McArthur <jimmy at openinfra.dev<mailto:jimmy at openinfra.dev>>
Cc: openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>
Subject: RE:

Thanks @Jimmy McArthur<mailto:jimmy at openinfra.dev> appreciated.

From: Jimmy McArthur <jimmy at openinfra.dev<mailto:jimmy at openinfra.dev>>
Sent: Monday, April 3, 2023 6:15 PM
To: Richard Buregeya <richard.buregeya at bsc.rw<mailto:richard.buregeya at bsc.rw>>
Cc: openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>
Subject: Re:

Hi Richard,

The COA is still a practical exam. You can find more details here: https://openstack.org/coa

Cheers,
Jimmy



On Apr 3, 2023, at 10:18 AM, Richard Buregeya <richard.buregeya at bsc.rw<mailto:richard.buregeya at bsc.rw>> wrote:

Hello Team,

Hope you are doing well.

Any one with an idea if there is a modification in COA exam, I heard it is now a multiple question exams instead of practical exam,

Anyone with current information, kindly update me.


Thanks a lot!

Regards

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/4c085b41/attachment-0001.htm>

From noonedeadpunk at gmail.com  Thu Apr  6 09:19:39 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Thu, 6 Apr 2023 11:19:39 +0200
Subject: [nova][cinder] future of rebuild without reimaging
In-Reply-To: <m2edpiywyc.fsf@caffeine.hv.danplanet.com>
References: <CAHeS+38pM+g76j6X6GMWLoy2S2B-fj4p7Le5EQo8cXc8fkBY8A@mail.gmail.com>
 <CALOCmumjtDnb6mLgyNL0j5TsXXdzVBLr_3=T1W1kH33v0tkx5w@mail.gmail.com>
 <m28rfxdevr.fsf@caffeine.hv.danplanet.com>
 <CAHeS+3-B2Q-2JGGUmehi97qdqKD8SD3jjuZwYCZnqAav=bN_ng@mail.gmail.com>
 <m2edpiywyc.fsf@caffeine.hv.danplanet.com>
Message-ID: <CAPd_6AuKkTNq6MZyKA2_ZuRdGAu-W4T1ocOtCN7KC-0RYj-aOQ@mail.gmail.com>

I think I just came up with another "usecase" or better say missing
functionality. So in case VM is stuck in `unshelving` state, for
example due to messaging issues or smth, there's no clean way of
recovering VM from this state.
Given you will reset state to active - you won't be able to execute
`stop` since VM is not assigned to any compute (and fail with
"instance not ready"), as it was shelved. So then rebuild could be
used, since it will pass VM to be assigned to some host as a result.
Another way around would be of course updating the database, setting
VM back to `shelved_offloaded` and trying to unshelve again, but I
hate messing up with DB.

I think this kinda brings me back to Sean's point of having an API
call to re-create a VM while keeping it's data, as that would cover
such corner-cases as well.

??, 21 ???. 2023??. ? 15:59, Dan Smith <dms at danplanet.com>:
>
> > Basically they have an additional and unusual compute host recovery
> > process, where a compute host after a failure is brought back by the
> > same name. Then they rebuild the servers on the same compute host
> > where the servers were running before. When the server's disk was
> > backed by a volume, so its content was not lost by the compute host
> > failure, they don't want to lose it either in the recovery process.
> > The evacute operation clearly would be a better fit to do this, but
> > that disallows evacuating to the "same" host. For a long time rebuild
> > just allowed "evacuating to the same host". So they went with it.
>
> Aside from the "should this be possible" question, is rebuild even
> required in this case? For the non-volume-backed instances, we need
> rebuild to re-download the image and create the root disk. If it's
> really required for volume-backed instances, I'm guessing there's just
> some trivial amount of state that isn't in place on recovery that the
> rebuild "solves". It is indeed a very odd fringe use-case that is an
> obvious mis-use of the function.
>
> > At the moment I did not find a prohibition in the documentation to
> > bring back a failed compute host by the same name. If I missed it or
> > this is not recommended for any reason, please let me know.
>
> I'm not sure why this would be specifically documented, but since
> compute nodes are not fully stateless, your scenario is basically
> "delete part of the state of the system and expect things to keep
> working" which I don't think is reasonable (nor something we should need
> to document).
>
> Your scenario is basically the same as one where your /var/lib/nova is
> mounted on a disk that doesn't come up after reboot, or on NFS that was
> unavailable at boot. If nova were to say "meh, a bunch of state
> disappeared, I must be a rebuilt compute host" then it would potentially
> destroy (or desynchronize) actual state in other nodes (i.e. the
> database) for a transient/accidental situation. TBH, we might should
> even explicitly *block* rebuild on an instance that appears to be
> missing its on-disk state to avoid users, who don't know the state of the
> infra, from doing this to try to unblock their instances while ops are
> doing maintenance.
>
> I will point out that bringing back a compute node under the same name
> (without cleaning the residue first) is strikingly similar to renaming a
> compute host, which we do *not* support. As of Antelope, the compute
> node would detect your scenario as a potential rename and refuse to
> start, again because of state that has been lost in the system. So just
> FYI that an actual blocker to your scenario is coming :)
>
> > Clearly in many clouds evacuating can fully replace what they do here.
> > I believe they may have chosen this unusual compute host recovery
> > option to have some kind of recovery process for very small
> > deployments, where you don't always have space to evacuate before you
> > rebuilt the failed compute host. And this collided with a deployment
> > system which reuses host names.
> >
> > At this point I'm not sure if this really belongs to the rebuild
> > operation. Could easily be better addressed in evacuate. Or in the
> > deployment system not reusing hostnames.
>
> Evacuate can't work for this case either because it requires the compute
> node to be down to perform. As you note, bringing it back under a
> different name would solve that problem. However, neither "evacuate to
> same host" or "use rebuild for this recovery procedure" are reasonable,
> IMHO.
>
> --Dan
>


From mkopec at redhat.com  Thu Apr  6 09:37:51 2023
From: mkopec at redhat.com (Martin Kopec)
Date: Thu, 6 Apr 2023 11:37:51 +0200
Subject: [qa][ptg] QA Bobcat vPTG summary
Message-ID: <CAKZGdE2Sj_V+ELF1TyDRD=B8DOVjOyeF4oZMbsB72NXAFnRmfQ@mail.gmail.com>

Hi everyone,

here is a summary of the discussions. The full agenda can be found here [1].

== Antelope Retrospective ==
Good things: kudos to all who are still around and help with reviews,
patches, bug fixes
Bad things: unstable gate due to tox update, timeouts, job flakiness
(mainly multinode job)

== uWSGI is in the maintenance mode ==
This doesn't require an immediate action as it's still in the maintenance
mode = any bugs should be fixed and until we need new features we don't
have to rush into replacing it.
We should have it on the watchlist though and potentially test some
alternatives - I've put this as one of the priority items for this cycle
[2].

== FIPS interop testing ==
We had a FIPS goal since the last PTG [3].
The patches [4] and [5] were to have FIPS on ubuntu and these [6] and [7]
are to add FIPS on a centos job.
The next goal is to have a FIPS job on Rocky linux as it's more stable than
centos.

== Retiring Patrole ==
We are going to retire Patrole project. 2 main facts that speak in favor of
retiring:
Fact 1: plugins have enough RBAC tests (and are writing more to test SRBAC)
- therefore patrole is not needed, the testing coverage got by the plugins
is enough.
Fact 2: patrole gates have been broken for a long time and no one was
affected by that.

== Additional PyPi maintainer cleanup ==
Only 2 projects from QA left with additional maintainers:
* openstack/os-performance-tools - additional maintainer SpamapS (Clint
Byrum)
* openstack/patrole - additional maintainer DavidPurcell
If you know any of them, please, tell them to reach out to me. I've sent
emails to them, but maybe the email addresses I found aren't checked
regularly anymore.

== Tempest/Devstack gate stability ==
Several precautions have been done such as reduce mysql memory [8] or
reduce the number of tests executed per job, increase of a timeout etc [9].
However, those precautions are mainly workarounds. The important note is
that the instability was only highlighted by our testing, not caused by it.
Many problems are inefficiencies in openstack software, e.g.:
* openstack-client issues a new token for every operation
* python startup time - entrypoint lookup
* privesp processes in aggregate use more memory than nova (every service
runs their own copy)
* inefficient ansible code, etc
Any volunteers who would like to first analyse the situation, find which of
those inefficiencies are the biggest culprits and how big effect they have
on the system?

[1] https://etherpad.opendev.org/p/qa-bobcat-ptg
[2] https://etherpad.opendev.org/p/qa-bobcat-priority
[3] https://etherpad.opendev.org/p/antelope-ptg-interop
[4] https://review.opendev.org/c/zuul/zuul-jobs/+/866881
[5] https://review.opendev.org/c/zuul/zuul-jobs/+/873893
[6] https://review.opendev.org/c/openstack/devstack/+/871606
[7] https://review.opendev.org/c/openstack/tempest/+/873697
[8] https://review.opendev.org/c/openstack/devstack/+/873646
[9] https://review.opendev.org/q/topic:bug%252F2004780

Regards,
-- 
Martin Kopec
Principal Software Quality Engineer
Red Hat EMEA
IM: kopecmartin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/fbc22288/attachment.htm>

From smooney at redhat.com  Thu Apr  6 10:56:21 2023
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 06 Apr 2023 11:56:21 +0100
Subject: [nova][cinder] future of rebuild without reimaging
In-Reply-To: <CAPd_6AuKkTNq6MZyKA2_ZuRdGAu-W4T1ocOtCN7KC-0RYj-aOQ@mail.gmail.com>
References: <CAHeS+38pM+g76j6X6GMWLoy2S2B-fj4p7Le5EQo8cXc8fkBY8A@mail.gmail.com>
 <CALOCmumjtDnb6mLgyNL0j5TsXXdzVBLr_3=T1W1kH33v0tkx5w@mail.gmail.com>
 <m28rfxdevr.fsf@caffeine.hv.danplanet.com>
 <CAHeS+3-B2Q-2JGGUmehi97qdqKD8SD3jjuZwYCZnqAav=bN_ng@mail.gmail.com>
 <m2edpiywyc.fsf@caffeine.hv.danplanet.com>
 <CAPd_6AuKkTNq6MZyKA2_ZuRdGAu-W4T1ocOtCN7KC-0RYj-aOQ@mail.gmail.com>
Message-ID: <c7e7c68a0e49ce8f9f5415db9895f936b1f9892e.camel@redhat.com>

On Thu, 2023-04-06 at 11:19 +0200, Dmitriy Rabotyagov wrote:
> I think I just came up with another "usecase" or better say missing
> functionality. So in case VM is stuck in `unshelving` state, for
> example due to messaging issues or smth, there's no clean way of
> recovering VM from this state.
rebuild would not eb corrct to use there.

> Given you will reset state to active?
> 
that is not safe to do.
the correct fix would be reset it to shevle_offloaded which you currntly would have
to do in the db.
> - you won't be able to execute
> `stop` since VM is not assigned to any compute (and fail with
> "instance not ready"), as it was shelved. So then rebuild could be
> used, since it will pass VM to be assigned to some host as a result.
> Another way around would be of course updating the database, setting
> VM back to `shelved_offloaded` and trying to unshelve again, but I
> hate messing up with DB.
> 
> I think this kinda brings me back to Sean's point of having an API
> call to re-create a VM while keeping it's data, as that would cover
> such corner-cases as well.
well we have talked about allowing reset-state reset to other states in the past
or allowing evacuate to work.
i proablywoul dnot allow the recreate api to work in that broken state.

the recreate api was not intended for error recovery.
it was intented to fullfile two usercases
1.) unify rebuild and resize so you can do either or both from a singel api call.
2.) update your vm so that it gets the latest flavor extra_specs and image properies appleis
witout data lose.
> 
> ??, 21 ???. 2023??. ? 15:59, Dan Smith <dms at danplanet.com>:
> > 
> > > Basically they have an additional and unusual compute host recovery
> > > process, where a compute host after a failure is brought back by the
> > > same name. Then they rebuild the servers on the same compute host
> > > where the servers were running before. When the server's disk was
> > > backed by a volume, so its content was not lost by the compute host
> > > failure, they don't want to lose it either in the recovery process.
> > > The evacute operation clearly would be a better fit to do this, but
> > > that disallows evacuating to the "same" host. For a long time rebuild
> > > just allowed "evacuating to the same host". So they went with it.
> > 
> > Aside from the "should this be possible" question, is rebuild even
> > required in this case?
> > 
if your vm is boot form voluem or you are using the ceph image backend for nova or nova on nfs
then i think all that is requried is hard reboot. there are no port updates/bindings and hard reboot
both plugs the netowrk interface into ovs or whatever the backend is on the host but also invokes
os-brick to do the same for the volumes. so its not clear to my why rebuild woudl be required in a
shared storage case.
> >  For the non-volume-backed instances, we need
> > rebuild to re-download the image and create the root disk.
> > 
yes although when you had the hardware failure you could have used evacuate to rebuild the vm on another
host. if you could not do that because the vm was pinned to that host then the existing rebuild command
is sufficent. if the failure was a motherboard or simialr and the data on disk was not lost then
a hard reboot should also be enough for vms with local storage. rebuild would only be required if the data
was lost.
> >  If it's
> > really required for volume-backed instances, I'm guessing there's just
> > some trivial amount of state that isn't in place on recovery that the
> > rebuild "solves". It is indeed a very odd fringe use-case that is an
> > obvious mis-use of the function.
ya if hard reboot/power on is not enough i think there is a trival bug there.
we are obviouly missing somethign that should be done. power_on/hard reboot
are intended to be abel to recreate the vm with its data after the host had been power off and powered on again.
so it is ment to do everything required to be able to start the instance. nova has all the info in its database
to do that without needing to call the other service like cinder and neutorn.

it woudl be good to know what actully fails if you just do hard reboot and capature that in a bug report.

> > 
> > > At the moment I did not find a prohibition in the documentation to
> > > bring back a failed compute host by the same name. If I missed it or
> > > this is not recommended for any reason, please let me know.
> > 
> > I'm not sure why this would be specifically documented, but since
> > compute nodes are not fully stateless, your scenario is basically
> > "delete part of the state of the system and expect things to keep
> > working" which I don't think is reasonable (nor something we should need
> > to document).
> > 
> > Your scenario is basically the same as one where your /var/lib/nova is
> > mounted on a disk that doesn't come up after reboot, or on NFS that was
> > unavailable at boot. If nova were to say "meh, a bunch of state
> > disappeared, I must be a rebuilt compute host" then it would potentially
> > destroy (or desynchronize) actual state in other nodes (i.e. the
> > database) for a transient/accidental situation. TBH, we might should
> > even explicitly *block* rebuild on an instance that appears to be
> > missing its on-disk state to avoid users, who don't know the state of the
> > infra, from doing this to try to unblock their instances while ops are
> > doing maintenance.
> > 
> > I will point out that bringing back a compute node under the same name
> > (without cleaning the residue first) is strikingly similar to renaming a
> > compute host, which we do *not* support. As of Antelope, the compute
> > node would detect your scenario as a potential rename and refuse to
> > start, again because of state that has been lost in the system. So just
> > FYI that an actual blocker to your scenario is coming :)
> > 
> > > Clearly in many clouds evacuating can fully replace what they do here.
> > > I believe they may have chosen this unusual compute host recovery
> > > option to have some kind of recovery process for very small
> > > deployments, where you don't always have space to evacuate before you
> > > rebuilt the failed compute host. And this collided with a deployment
> > > system which reuses host names.
> > > 
> > > At this point I'm not sure if this really belongs to the rebuild
> > > operation. Could easily be better addressed in evacuate. Or in the
> > > deployment system not reusing hostnames.
> > 
> > Evacuate can't work for this case either because it requires the compute
> > node to be down to perform. As you note, bringing it back under a
> > different name would solve that problem. However, neither "evacuate to
> > same host" or "use rebuild for this recovery procedure" are reasonable,
> > IMHO.
> > 
> > --Dan
> > 
> 



From noonedeadpunk at gmail.com  Thu Apr  6 11:17:12 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Thu, 6 Apr 2023 13:17:12 +0200
Subject: [nova][cinder] future of rebuild without reimaging
In-Reply-To: <c7e7c68a0e49ce8f9f5415db9895f936b1f9892e.camel@redhat.com>
References: <CAHeS+38pM+g76j6X6GMWLoy2S2B-fj4p7Le5EQo8cXc8fkBY8A@mail.gmail.com>
 <CALOCmumjtDnb6mLgyNL0j5TsXXdzVBLr_3=T1W1kH33v0tkx5w@mail.gmail.com>
 <m28rfxdevr.fsf@caffeine.hv.danplanet.com>
 <CAHeS+3-B2Q-2JGGUmehi97qdqKD8SD3jjuZwYCZnqAav=bN_ng@mail.gmail.com>
 <m2edpiywyc.fsf@caffeine.hv.danplanet.com>
 <CAPd_6AuKkTNq6MZyKA2_ZuRdGAu-W4T1ocOtCN7KC-0RYj-aOQ@mail.gmail.com>
 <c7e7c68a0e49ce8f9f5415db9895f936b1f9892e.camel@redhat.com>
Message-ID: <CAPd_6AvWBTjm00EA+5eGmfZUwKGW+vO4fDHoETbA-o+1xHA4Xw@mail.gmail.com>

To be frank I wasn't trying to do hard reboot in that case .Til that
it was unobvious for me that it should work or be used at all in such
weird scenarios. Like docs say nothing about how hard reboot can be
leveraged [1]. So my impression was that hard reboot simply triggers
`virsh destroy; virsh create` in the contrary to `virsh reboot` for
soft one and that's kind of it, rather than taking care of re-wiring
everything.

My biggest problem with DB updates, is that set of users who can
execute admin commands towards openstack APIs != set of users who have
root access to the hardware or database. So while indeed recovery from
such failures could be escalated, at least verifying if the issue is
intermittent or not is kinda helpful as well. So having a way to
recover from such states via API would be an improvement.

[1] https://docs.openstack.org/nova/latest/user/reboot.html

??, 6 ???. 2023??. ? 12:56, Sean Mooney <smooney at redhat.com>:
>
> On Thu, 2023-04-06 at 11:19 +0200, Dmitriy Rabotyagov wrote:
> > I think I just came up with another "usecase" or better say missing
> > functionality. So in case VM is stuck in `unshelving` state, for
> > example due to messaging issues or smth, there's no clean way of
> > recovering VM from this state.
> rebuild would not eb corrct to use there.
>
> > Given you will reset state to active
> >
> that is not safe to do.
> the correct fix would be reset it to shevle_offloaded which you currntly would have
> to do in the db.
> > - you won't be able to execute
> > `stop` since VM is not assigned to any compute (and fail with
> > "instance not ready"), as it was shelved. So then rebuild could be
> > used, since it will pass VM to be assigned to some host as a result.
> > Another way around would be of course updating the database, setting
> > VM back to `shelved_offloaded` and trying to unshelve again, but I
> > hate messing up with DB.
> >
> > I think this kinda brings me back to Sean's point of having an API
> > call to re-create a VM while keeping it's data, as that would cover
> > such corner-cases as well.
> well we have talked about allowing reset-state reset to other states in the past
> or allowing evacuate to work.
> i proablywoul dnot allow the recreate api to work in that broken state.
>
> the recreate api was not intended for error recovery.
> it was intented to fullfile two usercases
> 1.) unify rebuild and resize so you can do either or both from a singel api call.
> 2.) update your vm so that it gets the latest flavor extra_specs and image properies appleis
> witout data lose.
> >
> > ??, 21 ???. 2023??. ? 15:59, Dan Smith <dms at danplanet.com>:
> > >
> > > > Basically they have an additional and unusual compute host recovery
> > > > process, where a compute host after a failure is brought back by the
> > > > same name. Then they rebuild the servers on the same compute host
> > > > where the servers were running before. When the server's disk was
> > > > backed by a volume, so its content was not lost by the compute host
> > > > failure, they don't want to lose it either in the recovery process.
> > > > The evacute operation clearly would be a better fit to do this, but
> > > > that disallows evacuating to the "same" host. For a long time rebuild
> > > > just allowed "evacuating to the same host". So they went with it.
> > >
> > > Aside from the "should this be possible" question, is rebuild even
> > > required in this case?
> > >
> if your vm is boot form voluem or you are using the ceph image backend for nova or nova on nfs
> then i think all that is requried is hard reboot. there are no port updates/bindings and hard reboot
> both plugs the netowrk interface into ovs or whatever the backend is on the host but also invokes
> os-brick to do the same for the volumes. so its not clear to my why rebuild woudl be required in a
> shared storage case.
> > >  For the non-volume-backed instances, we need
> > > rebuild to re-download the image and create the root disk.
> > >
> yes although when you had the hardware failure you could have used evacuate to rebuild the vm on another
> host. if you could not do that because the vm was pinned to that host then the existing rebuild command
> is sufficent. if the failure was a motherboard or simialr and the data on disk was not lost then
> a hard reboot should also be enough for vms with local storage. rebuild would only be required if the data
> was lost.
> > >  If it's
> > > really required for volume-backed instances, I'm guessing there's just
> > > some trivial amount of state that isn't in place on recovery that the
> > > rebuild "solves". It is indeed a very odd fringe use-case that is an
> > > obvious mis-use of the function.
> ya if hard reboot/power on is not enough i think there is a trival bug there.
> we are obviouly missing somethign that should be done. power_on/hard reboot
> are intended to be abel to recreate the vm with its data after the host had been power off and powered on again.
> so it is ment to do everything required to be able to start the instance. nova has all the info in its database
> to do that without needing to call the other service like cinder and neutorn.
>
> it woudl be good to know what actully fails if you just do hard reboot and capature that in a bug report.
>
> > >
> > > > At the moment I did not find a prohibition in the documentation to
> > > > bring back a failed compute host by the same name. If I missed it or
> > > > this is not recommended for any reason, please let me know.
> > >
> > > I'm not sure why this would be specifically documented, but since
> > > compute nodes are not fully stateless, your scenario is basically
> > > "delete part of the state of the system and expect things to keep
> > > working" which I don't think is reasonable (nor something we should need
> > > to document).
> > >
> > > Your scenario is basically the same as one where your /var/lib/nova is
> > > mounted on a disk that doesn't come up after reboot, or on NFS that was
> > > unavailable at boot. If nova were to say "meh, a bunch of state
> > > disappeared, I must be a rebuilt compute host" then it would potentially
> > > destroy (or desynchronize) actual state in other nodes (i.e. the
> > > database) for a transient/accidental situation. TBH, we might should
> > > even explicitly *block* rebuild on an instance that appears to be
> > > missing its on-disk state to avoid users, who don't know the state of the
> > > infra, from doing this to try to unblock their instances while ops are
> > > doing maintenance.
> > >
> > > I will point out that bringing back a compute node under the same name
> > > (without cleaning the residue first) is strikingly similar to renaming a
> > > compute host, which we do *not* support. As of Antelope, the compute
> > > node would detect your scenario as a potential rename and refuse to
> > > start, again because of state that has been lost in the system. So just
> > > FYI that an actual blocker to your scenario is coming :)
> > >
> > > > Clearly in many clouds evacuating can fully replace what they do here.
> > > > I believe they may have chosen this unusual compute host recovery
> > > > option to have some kind of recovery process for very small
> > > > deployments, where you don't always have space to evacuate before you
> > > > rebuilt the failed compute host. And this collided with a deployment
> > > > system which reuses host names.
> > > >
> > > > At this point I'm not sure if this really belongs to the rebuild
> > > > operation. Could easily be better addressed in evacuate. Or in the
> > > > deployment system not reusing hostnames.
> > >
> > > Evacuate can't work for this case either because it requires the compute
> > > node to be down to perform. As you note, bringing it back under a
> > > different name would solve that problem. However, neither "evacuate to
> > > same host" or "use rebuild for this recovery procedure" are reasonable,
> > > IMHO.
> > >
> > > --Dan
> > >
> >
>


From sbauza at redhat.com  Thu Apr  6 11:28:59 2023
From: sbauza at redhat.com (Sylvain Bauza)
Date: Thu, 6 Apr 2023 13:28:59 +0200
Subject: [nova][cinder] future of rebuild without reimaging
In-Reply-To: <CAPd_6AuKkTNq6MZyKA2_ZuRdGAu-W4T1ocOtCN7KC-0RYj-aOQ@mail.gmail.com>
References: <CAHeS+38pM+g76j6X6GMWLoy2S2B-fj4p7Le5EQo8cXc8fkBY8A@mail.gmail.com>
 <CALOCmumjtDnb6mLgyNL0j5TsXXdzVBLr_3=T1W1kH33v0tkx5w@mail.gmail.com>
 <m28rfxdevr.fsf@caffeine.hv.danplanet.com>
 <CAHeS+3-B2Q-2JGGUmehi97qdqKD8SD3jjuZwYCZnqAav=bN_ng@mail.gmail.com>
 <m2edpiywyc.fsf@caffeine.hv.danplanet.com>
 <CAPd_6AuKkTNq6MZyKA2_ZuRdGAu-W4T1ocOtCN7KC-0RYj-aOQ@mail.gmail.com>
Message-ID: <CALOCmukDD1GEVNm0Ky=NxvnzuamM98+FOiM7FtTrQSyrFwAuUw@mail.gmail.com>

Le jeu. 6 avr. 2023 ? 11:25, Dmitriy Rabotyagov <noonedeadpunk at gmail.com> a
?crit :

> I think I just came up with another "usecase" or better say missing
> functionality. So in case VM is stuck in `unshelving` state, for
> example due to messaging issues or smth, there's no clean way of
> recovering VM from this state.
> Given you will reset state to active - you won't be able to execute
> `stop` since VM is not assigned to any compute (and fail with
> "instance not ready"), as it was shelved. So then rebuild could be
> used, since it will pass VM to be assigned to some host as a result.
> Another way around would be of course updating the database, setting
> VM back to `shelved_offloaded` and trying to unshelve again, but I
> hate messing up with DB.
>
> I think this kinda brings me back to Sean's point of having an API
> call to re-create a VM while keeping it's data, as that would cover
> such corner-cases as well.
>
>
FWIW, we agreed on the vPTG to add another separate policy for cold-migrate
(when the 'host' parameter is provided), so you could just modify the
existing cold-migrate policy (without the 'host' parameter by default) to
be able to be called by an end-user.
If so, an user could ask to move their instances and restart them by this,
and if they see some problem, they could then revert the migration.

I should be working on it by the next weeks hopefully.
-Sylvain

??, 21 ???. 2023??. ? 15:59, Dan Smith <dms at danplanet.com>:
> >
> > > Basically they have an additional and unusual compute host recovery
> > > process, where a compute host after a failure is brought back by the
> > > same name. Then they rebuild the servers on the same compute host
> > > where the servers were running before. When the server's disk was
> > > backed by a volume, so its content was not lost by the compute host
> > > failure, they don't want to lose it either in the recovery process.
> > > The evacute operation clearly would be a better fit to do this, but
> > > that disallows evacuating to the "same" host. For a long time rebuild
> > > just allowed "evacuating to the same host". So they went with it.
> >
> > Aside from the "should this be possible" question, is rebuild even
> > required in this case? For the non-volume-backed instances, we need
> > rebuild to re-download the image and create the root disk. If it's
> > really required for volume-backed instances, I'm guessing there's just
> > some trivial amount of state that isn't in place on recovery that the
> > rebuild "solves". It is indeed a very odd fringe use-case that is an
> > obvious mis-use of the function.
> >
> > > At the moment I did not find a prohibition in the documentation to
> > > bring back a failed compute host by the same name. If I missed it or
> > > this is not recommended for any reason, please let me know.
> >
> > I'm not sure why this would be specifically documented, but since
> > compute nodes are not fully stateless, your scenario is basically
> > "delete part of the state of the system and expect things to keep
> > working" which I don't think is reasonable (nor something we should need
> > to document).
> >
> > Your scenario is basically the same as one where your /var/lib/nova is
> > mounted on a disk that doesn't come up after reboot, or on NFS that was
> > unavailable at boot. If nova were to say "meh, a bunch of state
> > disappeared, I must be a rebuilt compute host" then it would potentially
> > destroy (or desynchronize) actual state in other nodes (i.e. the
> > database) for a transient/accidental situation. TBH, we might should
> > even explicitly *block* rebuild on an instance that appears to be
> > missing its on-disk state to avoid users, who don't know the state of the
> > infra, from doing this to try to unblock their instances while ops are
> > doing maintenance.
> >
> > I will point out that bringing back a compute node under the same name
> > (without cleaning the residue first) is strikingly similar to renaming a
> > compute host, which we do *not* support. As of Antelope, the compute
> > node would detect your scenario as a potential rename and refuse to
> > start, again because of state that has been lost in the system. So just
> > FYI that an actual blocker to your scenario is coming :)
> >
> > > Clearly in many clouds evacuating can fully replace what they do here.
> > > I believe they may have chosen this unusual compute host recovery
> > > option to have some kind of recovery process for very small
> > > deployments, where you don't always have space to evacuate before you
> > > rebuilt the failed compute host. And this collided with a deployment
> > > system which reuses host names.
> > >
> > > At this point I'm not sure if this really belongs to the rebuild
> > > operation. Could easily be better addressed in evacuate. Or in the
> > > deployment system not reusing hostnames.
> >
> > Evacuate can't work for this case either because it requires the compute
> > node to be down to perform. As you note, bringing it back under a
> > different name would solve that problem. However, neither "evacuate to
> > same host" or "use rebuild for this recovery procedure" are reasonable,
> > IMHO.
> >
> > --Dan
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/e218fe09/attachment.htm>

From wodel.youchi at gmail.com  Thu Apr  6 11:44:26 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Thu, 6 Apr 2023 12:44:26 +0100
Subject: [kolla-ansible] updating procedure
Message-ID: <CAJV_UBDTLHb-Lxuz5-gCx4x1Uqa=1YjyeJ540rRD2ZG2PdcFKA@mail.gmail.com>

Hi,

This is what documentation says about updating kolla-ansible : "Inside a
series, it is usually sufficient to just update the kolla-ansible package,
rebuild (if needed) and pull the images, and run kolla-ansible deploy
again. Please follow release notes to check if there are any issues to be
aware of."

So to summarize, the procedure is like this :
1 - update kolla-ansible
2 - Download the latest containers of the used version
3 - In my case publish them in the local registry
4 - launch kolla-ansible deploy

My question :
Can I do the update directly , especially on the compute nodes, or do I
have to empty some of them by moving VMs and execute the update on the
empty nodes only, then proceed with the same logic with the rest of the
nodes?

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/63300c9e/attachment-0001.htm>

From fungi at yuggoth.org  Thu Apr  6 11:46:28 2023
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Thu, 6 Apr 2023 11:46:28 +0000
Subject: [openstackclient][ubuntu] openstack cli broken after update to
 Wallaby
In-Reply-To: <20230406073153.Horde.p_0uBnyvKZpLcjMf4D_jCr0@webmail.nde.ag>
References: <20230404143428.Horde.MIPd5a2pT3yB3Ki3PoJBmOt@webmail.nde.ag>
 <bee8d618-ec90-478c-9ae9-b4c146137189@app.fastmail.com>
 <20230405222027.i7t7zipwpjrdz5y5@yuggoth.org>
 <20230406073153.Horde.p_0uBnyvKZpLcjMf4D_jCr0@webmail.nde.ag>
Message-ID: <20230406114627.p3hwbgo3vqqkv2xj@yuggoth.org>

On 2023-04-06 07:31:53 +0000 (+0000), Eugen Block wrote:
[...]
> The package would be installed from the main repo
> (ubuntu-2004-amd64-main-amd64). This is the state before I install
> any openstack related packages.
[...]
> I understand, but how does PyPI get into this environment? How
> could I find out?
[...]

Oh, sorry, this is probably an incorrect assumption on my part.

If the bug you're experiencing is with the OpenStack client
installed from Ubuntu's packages, then you need to report that
traceback to Canonical/Ubuntu. It mentions code paths which aren't
present in the pyperclip we test with upstream, because we don't
test with Ubuntu's packages of Python libraries, so may be a problem
specific to Ubuntu's own packages.

The general rule is that when encountering a bug while using a
downstream distribution of any application, you should report the
bug to the distribution you're using rather than to the upstream
development community, because distributions often patch things in
order to make their collection of software more consistent and
coinstallable, and therefore have a better idea of whether a problem
you're encountering is one of their own making or something they
should pass upstream to be investigated in the software itself.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/a7383cbe/attachment.sig>

From smooney at redhat.com  Thu Apr  6 11:47:48 2023
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 06 Apr 2023 12:47:48 +0100
Subject: [nova][cinder] future of rebuild without reimaging
In-Reply-To: <CALOCmukDD1GEVNm0Ky=NxvnzuamM98+FOiM7FtTrQSyrFwAuUw@mail.gmail.com>
References: <CAHeS+38pM+g76j6X6GMWLoy2S2B-fj4p7Le5EQo8cXc8fkBY8A@mail.gmail.com>
 <CALOCmumjtDnb6mLgyNL0j5TsXXdzVBLr_3=T1W1kH33v0tkx5w@mail.gmail.com>
 <m28rfxdevr.fsf@caffeine.hv.danplanet.com>
 <CAHeS+3-B2Q-2JGGUmehi97qdqKD8SD3jjuZwYCZnqAav=bN_ng@mail.gmail.com>
 <m2edpiywyc.fsf@caffeine.hv.danplanet.com>
 <CAPd_6AuKkTNq6MZyKA2_ZuRdGAu-W4T1ocOtCN7KC-0RYj-aOQ@mail.gmail.com>
 <CALOCmukDD1GEVNm0Ky=NxvnzuamM98+FOiM7FtTrQSyrFwAuUw@mail.gmail.com>
Message-ID: <037cdc0a78bb5392a8bba2b473f47041a9691a1b.camel@redhat.com>

On Thu, 2023-04-06 at 13:28 +0200, Sylvain Bauza wrote:
> Le jeu. 6 avr. 2023 ? 11:25, Dmitriy Rabotyagov <noonedeadpunk at gmail.com> a
> ?crit :
> 
> > I think I just came up with another "usecase" or better say missing
> > functionality. So in case VM is stuck in `unshelving` state, for
> > example due to messaging issues or smth, there's no clean way of
> > recovering VM from this state.
> > Given you will reset state to active - you won't be able to execute
> > `stop` since VM is not assigned to any compute (and fail with
> > "instance not ready"), as it was shelved. So then rebuild could be
> > used, since it will pass VM to be assigned to some host as a result.
> > Another way around would be of course updating the database, setting
> > VM back to `shelved_offloaded` and trying to unshelve again, but I
> > hate messing up with DB.
> > 
> > I think this kinda brings me back to Sean's point of having an API
> > call to re-create a VM while keeping it's data, as that would cover
> > such corner-cases as well.
> > 
> > 
> FWIW, we agreed on the vPTG to add another separate policy for cold-migrate
> (when the 'host' parameter is provided), so you could just modify the
> existing cold-migrate policy (without the 'host' parameter by default) to
> be able to be called by an end-user.
> If so, an user could ask to move their instances and restart them by this,
> and if they see some problem, they could then revert the migration.
> 
> I should be working on it by the next weeks hopefully.

that would help as long as the vm is not stuck in an error state.
i.e. it wont help in the stuck in unshelving case.
but it would help in the noisy neighbour case potentially.
> -Sylvain
> 
> ??, 21 ???. 2023??. ? 15:59, Dan Smith <dms at danplanet.com>:
> > > 
> > > > Basically they have an additional and unusual compute host recovery
> > > > process, where a compute host after a failure is brought back by the
> > > > same name. Then they rebuild the servers on the same compute host
> > > > where the servers were running before. When the server's disk was
> > > > backed by a volume, so its content was not lost by the compute host
> > > > failure, they don't want to lose it either in the recovery process.
> > > > The evacute operation clearly would be a better fit to do this, but
> > > > that disallows evacuating to the "same" host. For a long time rebuild
> > > > just allowed "evacuating to the same host". So they went with it.
> > > 
> > > Aside from the "should this be possible" question, is rebuild even
> > > required in this case? For the non-volume-backed instances, we need
> > > rebuild to re-download the image and create the root disk. If it's
> > > really required for volume-backed instances, I'm guessing there's just
> > > some trivial amount of state that isn't in place on recovery that the
> > > rebuild "solves". It is indeed a very odd fringe use-case that is an
> > > obvious mis-use of the function.
> > > 
> > > > At the moment I did not find a prohibition in the documentation to
> > > > bring back a failed compute host by the same name. If I missed it or
> > > > this is not recommended for any reason, please let me know.
> > > 
> > > I'm not sure why this would be specifically documented, but since
> > > compute nodes are not fully stateless, your scenario is basically
> > > "delete part of the state of the system and expect things to keep
> > > working" which I don't think is reasonable (nor something we should need
> > > to document).
> > > 
> > > Your scenario is basically the same as one where your /var/lib/nova is
> > > mounted on a disk that doesn't come up after reboot, or on NFS that was
> > > unavailable at boot. If nova were to say "meh, a bunch of state
> > > disappeared, I must be a rebuilt compute host" then it would potentially
> > > destroy (or desynchronize) actual state in other nodes (i.e. the
> > > database) for a transient/accidental situation. TBH, we might should
> > > even explicitly *block* rebuild on an instance that appears to be
> > > missing its on-disk state to avoid users, who don't know the state of the
> > > infra, from doing this to try to unblock their instances while ops are
> > > doing maintenance.
> > > 
> > > I will point out that bringing back a compute node under the same name
> > > (without cleaning the residue first) is strikingly similar to renaming a
> > > compute host, which we do *not* support. As of Antelope, the compute
> > > node would detect your scenario as a potential rename and refuse to
> > > start, again because of state that has been lost in the system. So just
> > > FYI that an actual blocker to your scenario is coming :)
> > > 
> > > > Clearly in many clouds evacuating can fully replace what they do here.
> > > > I believe they may have chosen this unusual compute host recovery
> > > > option to have some kind of recovery process for very small
> > > > deployments, where you don't always have space to evacuate before you
> > > > rebuilt the failed compute host. And this collided with a deployment
> > > > system which reuses host names.
> > > > 
> > > > At this point I'm not sure if this really belongs to the rebuild
> > > > operation. Could easily be better addressed in evacuate. Or in the
> > > > deployment system not reusing hostnames.
> > > 
> > > Evacuate can't work for this case either because it requires the compute
> > > node to be down to perform. As you note, bringing it back under a
> > > different name would solve that problem. However, neither "evacuate to
> > > same host" or "use rebuild for this recovery procedure" are reasonable,
> > > IMHO.
> > > 
> > > --Dan
> > > 
> > 
> > 



From jimmy at openinfra.dev  Thu Apr  6 11:53:31 2023
From: jimmy at openinfra.dev (Jimmy McArthur)
Date: Thu, 6 Apr 2023 06:53:31 -0500
Subject: No subject
In-Reply-To: <DBBPR03MB6716DA498F2D96BD91CA9D40F0919@DBBPR03MB6716.eurprd03.prod.outlook.com>
References: <DBBPR03MB671641ECA823C20815CDC232F0929@DBBPR03MB6716.eurprd03.prod.outlook.com>
 <3128971B-5A02-44E2-9F6E-6E01B82BFB31@openinfra.dev>
 <AM9PR03MB6705C59D076400A51B614C6AF0929@AM9PR03MB6705.eurprd03.prod.outlook.com>
 <AM9PR03MB6705652785085FF563AB3B11F0929@AM9PR03MB6705.eurprd03.prod.outlook.com>
 <DBBPR03MB6716DA498F2D96BD91CA9D40F0919@DBBPR03MB6716.eurprd03.prod.outlook.com>
Message-ID: <6B11CBB4-E2C1-40E2-8BC9-27FCB6E4A1CD@openinfra.dev>

Hi Richard,

Can you clarify the ask here? 

Cheers,
Jimmy




> On Apr 6, 2023, at 3:53 AM, Richard Buregeya <richard.buregeya at bsc.rw> wrote:
> 
> Hello Team,
>  
> Is there anywhere I can get valid Exam dumps for COA exam,
>  
> If anyone can assist me.
>  
> Regards
>  
> From: Richard Buregeya 
> Sent: Monday, April 3, 2023 6:40 PM
> To: Richard Buregeya <richard.buregeya at bsc.rw <mailto:richard.buregeya at bsc.rw>>; Jimmy McArthur <jimmy at openinfra.dev <mailto:jimmy at openinfra.dev>>
> Cc: openstack-discuss at lists.openstack.org <mailto:openstack-discuss at lists.openstack.org>
> Subject: RE: 
>  
> Thanks @Jimmy McArthur <mailto:jimmy at openinfra.dev>
>  
> From: Richard Buregeya <richard.buregeya at bsc.rw <mailto:richard.buregeya at bsc.rw>> 
> Sent: Monday, April 3, 2023 6:27 PM
> To: Jimmy McArthur <jimmy at openinfra.dev <mailto:jimmy at openinfra.dev>>
> Cc: openstack-discuss at lists.openstack.org <mailto:openstack-discuss at lists.openstack.org>
> Subject: RE: 
>  
> Thanks @Jimmy McArthur <mailto:jimmy at openinfra.dev> appreciated.
>  
> From: Jimmy McArthur <jimmy at openinfra.dev <mailto:jimmy at openinfra.dev>> 
> Sent: Monday, April 3, 2023 6:15 PM
> To: Richard Buregeya <richard.buregeya at bsc.rw <mailto:richard.buregeya at bsc.rw>>
> Cc: openstack-discuss at lists.openstack.org <mailto:openstack-discuss at lists.openstack.org>
> Subject: Re: 
>  
> Hi Richard,
>  
> The COA is still a practical exam. You can find more details here: https://openstack.org/coa <https://openstack.org/coa> 
>  
> Cheers,
> Jimmy
>  
>  
> 
>  
> 
> On Apr 3, 2023, at 10:18 AM, Richard Buregeya <richard.buregeya at bsc.rw <mailto:richard.buregeya at bsc.rw>> wrote:
>  
> Hello Team,
>  
> Hope you are doing well.
>  
> Any one with an idea if there is a modification in COA exam, I heard it is now a multiple question exams instead of practical exam,
>  
> Anyone with current information, kindly update me.
>  
>  
> Thanks a lot!
>  
> Regards

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/ef0c5a51/attachment-0001.htm>

From smooney at redhat.com  Thu Apr  6 12:01:32 2023
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 06 Apr 2023 13:01:32 +0100
Subject: [nova][cinder] future of rebuild without reimaging
In-Reply-To: <CAPd_6AvWBTjm00EA+5eGmfZUwKGW+vO4fDHoETbA-o+1xHA4Xw@mail.gmail.com>
References: <CAHeS+38pM+g76j6X6GMWLoy2S2B-fj4p7Le5EQo8cXc8fkBY8A@mail.gmail.com>
 <CALOCmumjtDnb6mLgyNL0j5TsXXdzVBLr_3=T1W1kH33v0tkx5w@mail.gmail.com>
 <m28rfxdevr.fsf@caffeine.hv.danplanet.com>
 <CAHeS+3-B2Q-2JGGUmehi97qdqKD8SD3jjuZwYCZnqAav=bN_ng@mail.gmail.com>
 <m2edpiywyc.fsf@caffeine.hv.danplanet.com>
 <CAPd_6AuKkTNq6MZyKA2_ZuRdGAu-W4T1ocOtCN7KC-0RYj-aOQ@mail.gmail.com>
 <c7e7c68a0e49ce8f9f5415db9895f936b1f9892e.camel@redhat.com>
 <CAPd_6AvWBTjm00EA+5eGmfZUwKGW+vO4fDHoETbA-o+1xHA4Xw@mail.gmail.com>
Message-ID: <efef5751083c0454f6e4cbad6c3393b7455bd1c7.camel@redhat.com>

On Thu, 2023-04-06 at 13:17 +0200, Dmitriy Rabotyagov wrote:
> To be frank I wasn't trying to do hard reboot in that case .Til that
> it was unobvious for me that it should work or be used at all in such
> weird scenarios. Like docs say nothing about how hard reboot can be
> leveraged [1]. So my impression was that hard reboot simply triggers
> `virsh destroy; virsh create` in the contrary to `virsh reboot` for
> soft one and that's kind of it, rather than taking care of re-wiring
> everything.

hard reboot is the primary way to recover a vm form error where that error
state is not related to a live migration failure.

it can be used in the case of live migraiton if you first check the host and node
field on the instance point at the host where the vm is.

this is why hard reboot support a vm state of ERROR
https://docs.openstack.org/api-ref/compute/?expanded=reboot-server-reboot-action-detail#reboot-server-reboot-action

almost all other instance operator will not allow a vm to be in ERROR state.

but in general becasue server start is optional in the api and hard reboot is required
hard reboot is the primary way to start a vm after a host reboot.
https://docs.openstack.org/nova/latest/user/support-matrix.html
 so regardless of the usecase of recoving
form error by regenerating the domain, repluggin the port and remounting the volumes it also need to support
the same for the reboot case as linux bridge for example would not preserv the network config across reboots
and host mounted volumes (iscsi) simialrly gets reset on a host reboot.

so ya the real differce betwen soft reboot and hard reboot with the libvirt dirver is soft reboot
only restates the os in the qemu porcess and hard reboot recreates everything including host configurtion using
the data in the nova db.

im not really sure how to make that more obvious in the api docs.
we proably could add a note about using hardreboot not rebuild in such cases.
> 
> My biggest problem with DB updates, is that set of users who can
> execute admin commands towards openstack APIs != set of users who have
> root access to the hardware or database. So while indeed recovery from
> such failures could be escalated, at least verifying if the issue is
> intermittent or not is kinda helpful as well. So having a way to
> recover from such states via API would be an improvement.
> 
> [1] https://docs.openstack.org/nova/latest/user/reboot.html
> 
> ??, 6 ???. 2023??. ? 12:56, Sean Mooney <smooney at redhat.com>:
> > 
> > On Thu, 2023-04-06 at 11:19 +0200, Dmitriy Rabotyagov wrote:
> > > I think I just came up with another "usecase" or better say missing
> > > functionality. So in case VM is stuck in `unshelving` state, for
> > > example due to messaging issues or smth, there's no clean way of
> > > recovering VM from this state.
> > rebuild would not eb corrct to use there.
> > 
> > > Given you will reset state to active
> > > 
> > that is not safe to do.
> > the correct fix would be reset it to shevle_offloaded which you currntly would have
> > to do in the db.
> > > - you won't be able to execute
> > > `stop` since VM is not assigned to any compute (and fail with
> > > "instance not ready"), as it was shelved. So then rebuild could be
> > > used, since it will pass VM to be assigned to some host as a result.
> > > Another way around would be of course updating the database, setting
> > > VM back to `shelved_offloaded` and trying to unshelve again, but I
> > > hate messing up with DB.
> > > 
> > > I think this kinda brings me back to Sean's point of having an API
> > > call to re-create a VM while keeping it's data, as that would cover
> > > such corner-cases as well.
> > well we have talked about allowing reset-state reset to other states in the past
> > or allowing evacuate to work.
> > i proablywoul dnot allow the recreate api to work in that broken state.
> > 
> > the recreate api was not intended for error recovery.
> > it was intented to fullfile two usercases
> > 1.) unify rebuild and resize so you can do either or both from a singel api call.
> > 2.) update your vm so that it gets the latest flavor extra_specs and image properies appleis
> > witout data lose.
> > > 
> > > ??, 21 ???. 2023??. ? 15:59, Dan Smith <dms at danplanet.com>:
> > > > 
> > > > > Basically they have an additional and unusual compute host recovery
> > > > > process, where a compute host after a failure is brought back by the
> > > > > same name. Then they rebuild the servers on the same compute host
> > > > > where the servers were running before. When the server's disk was
> > > > > backed by a volume, so its content was not lost by the compute host
> > > > > failure, they don't want to lose it either in the recovery process.
> > > > > The evacute operation clearly would be a better fit to do this, but
> > > > > that disallows evacuating to the "same" host. For a long time rebuild
> > > > > just allowed "evacuating to the same host". So they went with it.
> > > > 
> > > > Aside from the "should this be possible" question, is rebuild even
> > > > required in this case?
> > > > 
> > if your vm is boot form voluem or you are using the ceph image backend for nova or nova on nfs
> > then i think all that is requried is hard reboot. there are no port updates/bindings and hard reboot
> > both plugs the netowrk interface into ovs or whatever the backend is on the host but also invokes
> > os-brick to do the same for the volumes. so its not clear to my why rebuild woudl be required in a
> > shared storage case.
> > > >  For the non-volume-backed instances, we need
> > > > rebuild to re-download the image and create the root disk.
> > > > 
> > yes although when you had the hardware failure you could have used evacuate to rebuild the vm on another
> > host. if you could not do that because the vm was pinned to that host then the existing rebuild command
> > is sufficent. if the failure was a motherboard or simialr and the data on disk was not lost then
> > a hard reboot should also be enough for vms with local storage. rebuild would only be required if the data
> > was lost.
> > > >  If it's
> > > > really required for volume-backed instances, I'm guessing there's just
> > > > some trivial amount of state that isn't in place on recovery that the
> > > > rebuild "solves". It is indeed a very odd fringe use-case that is an
> > > > obvious mis-use of the function.
> > ya if hard reboot/power on is not enough i think there is a trival bug there.
> > we are obviouly missing somethign that should be done. power_on/hard reboot
> > are intended to be abel to recreate the vm with its data after the host had been power off and powered on again.
> > so it is ment to do everything required to be able to start the instance. nova has all the info in its database
> > to do that without needing to call the other service like cinder and neutorn.
> > 
> > it woudl be good to know what actully fails if you just do hard reboot and capature that in a bug report.
> > 
> > > > 
> > > > > At the moment I did not find a prohibition in the documentation to
> > > > > bring back a failed compute host by the same name. If I missed it or
> > > > > this is not recommended for any reason, please let me know.
> > > > 
> > > > I'm not sure why this would be specifically documented, but since
> > > > compute nodes are not fully stateless, your scenario is basically
> > > > "delete part of the state of the system and expect things to keep
> > > > working" which I don't think is reasonable (nor something we should need
> > > > to document).
> > > > 
> > > > Your scenario is basically the same as one where your /var/lib/nova is
> > > > mounted on a disk that doesn't come up after reboot, or on NFS that was
> > > > unavailable at boot. If nova were to say "meh, a bunch of state
> > > > disappeared, I must be a rebuilt compute host" then it would potentially
> > > > destroy (or desynchronize) actual state in other nodes (i.e. the
> > > > database) for a transient/accidental situation. TBH, we might should
> > > > even explicitly *block* rebuild on an instance that appears to be
> > > > missing its on-disk state to avoid users, who don't know the state of the
> > > > infra, from doing this to try to unblock their instances while ops are
> > > > doing maintenance.
> > > > 
> > > > I will point out that bringing back a compute node under the same name
> > > > (without cleaning the residue first) is strikingly similar to renaming a
> > > > compute host, which we do *not* support. As of Antelope, the compute
> > > > node would detect your scenario as a potential rename and refuse to
> > > > start, again because of state that has been lost in the system. So just
> > > > FYI that an actual blocker to your scenario is coming :)
> > > > 
> > > > > Clearly in many clouds evacuating can fully replace what they do here.
> > > > > I believe they may have chosen this unusual compute host recovery
> > > > > option to have some kind of recovery process for very small
> > > > > deployments, where you don't always have space to evacuate before you
> > > > > rebuilt the failed compute host. And this collided with a deployment
> > > > > system which reuses host names.
> > > > > 
> > > > > At this point I'm not sure if this really belongs to the rebuild
> > > > > operation. Could easily be better addressed in evacuate. Or in the
> > > > > deployment system not reusing hostnames.
> > > > 
> > > > Evacuate can't work for this case either because it requires the compute
> > > > node to be down to perform. As you note, bringing it back under a
> > > > different name would solve that problem. However, neither "evacuate to
> > > > same host" or "use rebuild for this recovery procedure" are reasonable,
> > > > IMHO.
> > > > 
> > > > --Dan
> > > > 
> > > 
> > 
> 



From Danny.Webb at thehutgroup.com  Thu Apr  6 12:04:40 2023
From: Danny.Webb at thehutgroup.com (Danny Webb)
Date: Thu, 6 Apr 2023 12:04:40 +0000
Subject: No subject
In-Reply-To: <DBBPR03MB6716DA498F2D96BD91CA9D40F0919@DBBPR03MB6716.eurprd03.prod.outlook.com>
References: <DBBPR03MB671641ECA823C20815CDC232F0929@DBBPR03MB6716.eurprd03.prod.outlook.com>
 <3128971B-5A02-44E2-9F6E-6E01B82BFB31@openinfra.dev>
 <AM9PR03MB6705C59D076400A51B614C6AF0929@AM9PR03MB6705.eurprd03.prod.outlook.com>
 <AM9PR03MB6705652785085FF563AB3B11F0929@AM9PR03MB6705.eurprd03.prod.outlook.com>
 <DBBPR03MB6716DA498F2D96BD91CA9D40F0919@DBBPR03MB6716.eurprd03.prod.outlook.com>
Message-ID: <LO2P265MB5773CDEBF98F44A80464080D9A919@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>

https://www.oreilly.com/library/view/certified-openstack-administrator/9781484288047/
[https://www.oreilly.com/library/cover/9781484288047/]<https://www.oreilly.com/library/view/certified-openstack-administrator/9781484288047/>
Certified OpenStack Administrator Study Guide : Get Everything You Need for the COA Exam<https://www.oreilly.com/library/view/certified-openstack-administrator/9781484288047/>
Gain a better understanding of how to work with the modern OpenStack IaaS Cloud platform. This updated book is designed to help you pass the latest ?Yoga? version of the ? - Selection from Certified OpenStack Administrator Study Guide : Get Everything You Need for the COA Exam [Book]
www.oreilly.com

________________________________
From: Richard Buregeya <richard.buregeya at bsc.rw>
Sent: 06 April 2023 09:53
To: Jimmy McArthur <jimmy at openinfra.dev>
Cc: openstack-discuss at lists.openstack.org <openstack-discuss at lists.openstack.org>
Subject: RE:


CAUTION: This email originates from outside THG

________________________________

Hello Team,



Is there anywhere I can get valid Exam dumps for COA exam,



If anyone can assist me.



Regards



From: Richard Buregeya
Sent: Monday, April 3, 2023 6:40 PM
To: Richard Buregeya <richard.buregeya at bsc.rw>; Jimmy McArthur <jimmy at openinfra.dev>
Cc: openstack-discuss at lists.openstack.org
Subject: RE:



Thanks @Jimmy McArthur<mailto:jimmy at openinfra.dev>



From: Richard Buregeya <richard.buregeya at bsc.rw<mailto:richard.buregeya at bsc.rw>>
Sent: Monday, April 3, 2023 6:27 PM
To: Jimmy McArthur <jimmy at openinfra.dev<mailto:jimmy at openinfra.dev>>
Cc: openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>
Subject: RE:



Thanks @Jimmy McArthur<mailto:jimmy at openinfra.dev> appreciated.



From: Jimmy McArthur <jimmy at openinfra.dev<mailto:jimmy at openinfra.dev>>
Sent: Monday, April 3, 2023 6:15 PM
To: Richard Buregeya <richard.buregeya at bsc.rw<mailto:richard.buregeya at bsc.rw>>
Cc: openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>
Subject: Re:



Hi Richard,



The COA is still a practical exam. You can find more details here: https://openstack.org/coa<https://openstack.org/coa>



Cheers,

Jimmy







On Apr 3, 2023, at 10:18 AM, Richard Buregeya <richard.buregeya at bsc.rw<mailto:richard.buregeya at bsc.rw>> wrote:



Hello Team,



Hope you are doing well.



Any one with an idea if there is a modification in COA exam, I heard it is now a multiple question exams instead of practical exam,



Anyone with current information, kindly update me.





Thanks a lot!



Regards


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/ec39a459/attachment-0001.htm>

From smooney at redhat.com  Thu Apr  6 12:10:07 2023
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 06 Apr 2023 13:10:07 +0100
Subject: [kolla-ansible] updating procedure
In-Reply-To: <CAJV_UBDTLHb-Lxuz5-gCx4x1Uqa=1YjyeJ540rRD2ZG2PdcFKA@mail.gmail.com>
References: <CAJV_UBDTLHb-Lxuz5-gCx4x1Uqa=1YjyeJ540rRD2ZG2PdcFKA@mail.gmail.com>
Message-ID: <30d2a125cea45ee7fe705f48e21aa7b24e72be0b.camel@redhat.com>

On Thu, 2023-04-06 at 12:44 +0100, wodel youchi wrote:
> Hi,
> 
> This is what documentation says about updating kolla-ansible : "Inside a
> series, it is usually sufficient to just update the kolla-ansible package,
> rebuild (if needed) and pull the images, and run kolla-ansible deploy
> again. Please follow release notes to check if there are any issues to be
> aware of."
> 
> So to summarize, the procedure is like this :
> 1 - update kolla-ansible
> 2 - Download the latest containers of the used version
> 3 - In my case publish them in the local registry
> 4 - launch kolla-ansible deploy
> 
> My question :
> Can I do the update directly , especially on the compute nodes, or do I
> have to empty some of them by moving VMs and execute the update on the
> empty nodes only, then proceed with the same logic with the rest of the
> nodes?
in general yes. however depending on the option you selected there can be some downtime.
for example recreating the libvirt/nova-comptue contaienr will not cause teh vm to stop running.
the libvirt contaienr runs with pid=host so the qemu process is not actully runing in the contaienr.
obvioulsy if you have started using the host installed libvirt feature then that is also true.

if you are using kernel ovs then restart the ovs contaienr to update it does not impact the datapath
since that is runningin the ovs kernel module your are just updating the contol plane when you upgrade the
contianer.


stateless services like nova-api will also just work

where you have to be careful is any contaienr that is in the datapath.

for example if you are using iscsid to export cinder lvm
since cinder lvm is not HA the restart of iscsid can cause the vms to loose access to storage.

if your using ceph that is not a problem.


if your using ovn you may similar have some connectiv issue while the distributed contoelrs are recomputing
ther flows.
in general the flow cache in ovs is enough to hide that but new connections wont be establised until the new contaienr starts up properly.

that is why its imporant to pull the images first to keep that start up time as short as possible.

i dont know how many users of kolla actully use the inplace upgrade with production workload.
you can obviouly drain a compute of vms and use --limit to update only empty comptues and live migrate workloads around too.

but in principal i belive inplcae upgrade should be possible.

the kolla team can confirm but when i used to use kolla for an internal dev cloud in my previous job (with ceph) i did not move instances
when i upgraded the cluster.
> 
> Regards.



From nguyenhuukhoinw at gmail.com  Thu Apr  6 12:12:54 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Thu, 6 Apr 2023 19:12:54 +0700
Subject: [kolla-ansible] updating procedure
In-Reply-To: <CAJV_UBDTLHb-Lxuz5-gCx4x1Uqa=1YjyeJ540rRD2ZG2PdcFKA@mail.gmail.com>
References: <CAJV_UBDTLHb-Lxuz5-gCx4x1Uqa=1YjyeJ540rRD2ZG2PdcFKA@mail.gmail.com>
Message-ID: <CABAODRcsNa_DJheoVLzr0sTkFrz=c-oTvxsm6yg0vU--1S6RNQ@mail.gmail.com>

Same question.
Could we have more detail document and step about it,?

On Thu, Apr 6, 2023, 6:50 PM wodel youchi <wodel.youchi at gmail.com> wrote:

> Hi,
>
> This is what documentation says about updating kolla-ansible : "Inside a
> series, it is usually sufficient to just update the kolla-ansible package,
> rebuild (if needed) and pull the images, and run kolla-ansible deploy
> again. Please follow release notes to check if there are any issues to be
> aware of."
>
> So to summarize, the procedure is like this :
> 1 - update kolla-ansible
> 2 - Download the latest containers of the used version
> 3 - In my case publish them in the local registry
> 4 - launch kolla-ansible deploy
>
> My question :
> Can I do the update directly , especially on the compute nodes, or do I
> have to empty some of them by moving VMs and execute the update on the
> empty nodes only, then proceed with the same logic with the rest of the
> nodes?
>
> Regards.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/cc32f603/attachment.htm>

From eblock at nde.ag  Thu Apr  6 13:02:03 2023
From: eblock at nde.ag (Eugen Block)
Date: Thu, 06 Apr 2023 13:02:03 +0000
Subject: [openstackclient][ubuntu] openstack cli broken after update to
 Wallaby
In-Reply-To: <20230406114627.p3hwbgo3vqqkv2xj@yuggoth.org>
References: <20230404143428.Horde.MIPd5a2pT3yB3Ki3PoJBmOt@webmail.nde.ag>
 <bee8d618-ec90-478c-9ae9-b4c146137189@app.fastmail.com>
 <20230405222027.i7t7zipwpjrdz5y5@yuggoth.org>
 <20230406073153.Horde.p_0uBnyvKZpLcjMf4D_jCr0@webmail.nde.ag>
 <20230406114627.p3hwbgo3vqqkv2xj@yuggoth.org>
Message-ID: <20230406130203.Horde.ewtWR4kfdSgpi_Fe-mg-a_8@webmail.nde.ag>

Thanks, I'm still not sure if it actually is a bug, to be honest. I  
compared the list of packages between V and W and W contains almost  
double the amount. From ceph to librte (not sure what those are for)  
the differences are huge, for example W contains the openvswitch  
packages while in V they are from the main update repo. I will try to  
get to the bottom of this and if it actually is a bug I'll report it  
to Canonical.

Thanks for your input!
Eugen

Zitat von Jeremy Stanley <fungi at yuggoth.org>:

> On 2023-04-06 07:31:53 +0000 (+0000), Eugen Block wrote:
> [...]
>> The package would be installed from the main repo
>> (ubuntu-2004-amd64-main-amd64). This is the state before I install
>> any openstack related packages.
> [...]
>> I understand, but how does PyPI get into this environment? How
>> could I find out?
> [...]
>
> Oh, sorry, this is probably an incorrect assumption on my part.
>
> If the bug you're experiencing is with the OpenStack client
> installed from Ubuntu's packages, then you need to report that
> traceback to Canonical/Ubuntu. It mentions code paths which aren't
> present in the pyperclip we test with upstream, because we don't
> test with Ubuntu's packages of Python libraries, so may be a problem
> specific to Ubuntu's own packages.
>
> The general rule is that when encountering a bug while using a
> downstream distribution of any application, you should report the
> bug to the distribution you're using rather than to the upstream
> development community, because distributions often patch things in
> order to make their collection of software more consistent and
> coinstallable, and therefore have a better idea of whether a problem
> you're encountering is one of their own making or something they
> should pass upstream to be investigated in the software itself.
> --
> Jeremy Stanley





From mkopec at redhat.com  Thu Apr  6 14:11:38 2023
From: mkopec at redhat.com (Martin Kopec)
Date: Thu, 6 Apr 2023 16:11:38 +0200
Subject: [interop][ptg] Interop Bobcat vPTG summary
Message-ID: <CAKZGdE3M_m9NpNtQq7S1HY0ASVso_RO8gq61c3pnzeVAT2+0Qg@mail.gmail.com>

Hi everyone,

here is a summary of the discussions. The full agenda can be found here [1].

== Current pain points and challenges of interop testing ==
The current guidelines don't contain complex enough tests - apart from api
tests we should also have more functional tests which mock users'
interactions with the cloud - we should test as a real user would use the
cloud.

People could fake the refstack results - after a discussion we came to an
agreement that those people would always find a way, there is no need for
coming up with sophisticated ways to prevent it. The point of Interop is to
provide a check for vendors/users to see where they stand with their
product based on the agreed standards.

Use of Interop's tooling is complicated - there have been reports that
users struggle with refstack-client and tempest. There is an ongoing effort
to create a refstack container which would contain all necessary tools and
could be run with just one command.

Passing the Interop's guidelines means interoperability on which level?
Passing the guidelines should mean being in compliance with the beforehand
community agreed upon standards.

Getting vendors running the interop tests more often - we only came up with
the strategies which are already being used, such as expirations and
guideline versioning.

== Future strategy ==
The future strategy could be summarized in 3 points:
* discuss the possibility for using sdk-based and tobiko testing
* better describe to users the expectations they should have for clouds
which assert interoperability
* look into expiration of older standards and require that compliant
providers indicate to users which version of the standard they last
tested/passed

[1] https://etherpad.opendev.org/p/bobcat-ptg-interop

Regards,
-- 
Martin Kopec
Principal Software Quality Engineer
Red Hat EMEA
IM: kopecmartin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/353151ad/attachment.htm>

From thremes172 at gmail.com  Thu Apr  6 15:21:58 2023
From: thremes172 at gmail.com (kaqiu pi)
Date: Thu, 6 Apr 2023 23:21:58 +0800
Subject: [nova][cinder] why volumes can only be attached and dettached for
 running instances
Message-ID: <CAJbin1BMNgYycd4782ujS_1BDFNWJUrgxzJ-TPm+j1dK0-Yttg@mail.gmail.com>

hello,

I can only attached and dettached volumes for running instances in
openstack.


I would like to ask the reason for this design. And is there any
danger if this restriction is turned on through custom modification in
a private scene?


Thank you so much.
Yours
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/e9d8020d/attachment-0001.htm>

From satish.txt at gmail.com  Thu Apr  6 15:36:58 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Thu, 6 Apr 2023 11:36:58 -0400
Subject: multi-region deployment within datacenter scenario
In-Reply-To: <CAMf4N71pBZAoubGCtTMh+O-sJG28+EmgRuzGYrBBidtQ-AFJMw@mail.gmail.com>
References: <CAPgF-fqT1oVa-bYGFdzXUrTpLpuECiuo6RcuvxbnJ-8WZt_avA@mail.gmail.com>
 <CAMf4N72V5vMVdWEyU2c+MM_Xx25ZviRijnkM-eYsqTVbyVkCyg@mail.gmail.com>
 <CAPgF-fqSEQQDmEygJ+ybsjj7YC8tb-mO8hBrOs=xmLe=MatfWQ@mail.gmail.com>
 <CAMf4N71pBZAoubGCtTMh+O-sJG28+EmgRuzGYrBBidtQ-AFJMw@mail.gmail.com>
Message-ID: <CAPgF-fpfJBWJLxCm9ACXHn1HabNHK5VLj51zZfy3MpdpCS=kFA@mail.gmail.com>

Hi Can,

Thank you for sharing information. I am surprised how you are running that
many nodes with a single control plan. Could you share info about how many
controllers you have? Do you have separate rabbitMQ nodes/DB nodes etc.

I have 350 compute nodes with 3x controller nodes and it works fine but the
problem is slowness. I felt it was a little slower compared to smaller
environments. Also I googled about it and most people suggested using 100
nodes per deployment for easy management.

In my deployment I have all vlan based tenants so my network nodes are kind
of useless and just for DHCP. mostly i am worried about RabbitMQ.


On Thu, Apr 6, 2023 at 2:54?AM Can ?zyurt <acozyurt at gmail.com> wrote:

> Hi,
>
> Technically yes. We have had more than a thousand nodes in a single
> cell for years on production. But we are considering adding more cells
> as we grow bigger and bigger.
>
> On Thu, 6 Apr 2023 at 03:25, Satish Patel <satish.txt at gmail.com> wrote:
> >
> > Hi Can,
> >
> > You are saying a single control plan can handle 600 compute nodes?
> >
> > On Wed, Apr 5, 2023 at 5:36?PM Can ?zyurt <acozyurt at gmail.com> wrote:
> >>
> >> It's totally okay to use regions as AZs if that's what you need,
> >> unless you are planning to deploy in another city. Then you will be
> >> already exhausting the term region and you will have been left with
> >> much more to deal with. Ultimately it comes down to needs and future
> >> plans.
> >>
> >> Secondly, I think you should be fine with a single cell anyway as we
> >> have much more in one cell. However experience may vary depending on
> >> the volume and characteristics of the daily workload and the design of
> >> the control plane, so maybe you should take someone else's word with
> >> more in-depth knowledge for the guidance.
> >>
> >> Cheers.
> >>
> >> On Wed, 5 Apr 2023 at 18:47, Satish Patel <satish.txt at gmail.com> wrote:
> >> >
> >> > Folks,
> >> >
> >> > This is a very broad question and could have many answers but still
> wanted to ask to see what people are thinking and doing.
> >> >
> >> > We have DC with multiple racks and around 600 nodes so we are
> planning to create 3 private openstack and each with 200 nodes. In other
> data centers we have multiple 200 nodes openstack clusters and life is
> good. In the new datacenter I am thinking of deploying the same way
> openstack but shared keystone between multiple openstack environments to
> have a single place for identification and I am going to call it 3 regions
> even it's in a single DC. Hope shared keystone is helpful/easier for doing
> terrafrom work and selecting region easily.
> >> >
> >> > Other option I was thinking about to deploy cellv2 technology and put
> all 600 nodes in single cloud but always worried for operation point of
> view. Now sure how many people running cellv2 successfully without pain.
> (Except CERN)
> >> >
> >> > If people running multi-region openstack cloud then please share some
> thought and idea to make life easier. Not looking for best solution but
> just clue to get idea to deploy and manage multiple openstack.
> >> >
> >> > Thanks in advance.
> >> > S
> >> >
> >> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/233e3cc7/attachment.htm>

From smooney at redhat.com  Thu Apr  6 16:27:56 2023
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 06 Apr 2023 17:27:56 +0100
Subject: [nova][cinder] why volumes can only be attached and dettached
 for running instances
In-Reply-To: <CAJbin1BMNgYycd4782ujS_1BDFNWJUrgxzJ-TPm+j1dK0-Yttg@mail.gmail.com>
References: <CAJbin1BMNgYycd4782ujS_1BDFNWJUrgxzJ-TPm+j1dK0-Yttg@mail.gmail.com>
Message-ID: <d81a813f3d90a2efddd38fe7d8e4ea586c9d0cd9.camel@redhat.com>

On Thu, 2023-04-06 at 23:21 +0800, kaqiu pi wrote:
> hello,
> 
> I can only attached and dettached volumes for running instances in
> openstack.
nova allows you to attach volume to instance that are stopped.
instance in the shelve offloaded state required micoverion  v2.20 and multi attach requires  v2.60
https://docs.openstack.org/api-ref/compute/?expanded=attach-a-volume-to-an-instance-detail#attach-a-volume-to-an-instance

for volume attachment to work with virtio blk you need to hanve enough pci slots in teh vm free for the pci hotplug to succeed.

if you are using vritio-scsi via hw_disk_bus=scsi the pci requirement does not apply.

> 
> 
> I would like to ask the reason for this design. And is there any
> danger if this restriction is turned on through custom modification in
> a private scene?
> 
> 
> Thank you so much.
> Yours



From acozyurt at gmail.com  Thu Apr  6 16:43:55 2023
From: acozyurt at gmail.com (=?UTF-8?Q?Can_=C3=96zyurt?=)
Date: Thu, 6 Apr 2023 19:43:55 +0300
Subject: multi-region deployment within datacenter scenario
In-Reply-To: <CAPgF-fpfJBWJLxCm9ACXHn1HabNHK5VLj51zZfy3MpdpCS=kFA@mail.gmail.com>
References: <CAPgF-fqT1oVa-bYGFdzXUrTpLpuECiuo6RcuvxbnJ-8WZt_avA@mail.gmail.com>
 <CAMf4N72V5vMVdWEyU2c+MM_Xx25ZviRijnkM-eYsqTVbyVkCyg@mail.gmail.com>
 <CAPgF-fqSEQQDmEygJ+ybsjj7YC8tb-mO8hBrOs=xmLe=MatfWQ@mail.gmail.com>
 <CAMf4N71pBZAoubGCtTMh+O-sJG28+EmgRuzGYrBBidtQ-AFJMw@mail.gmail.com>
 <CAPgF-fpfJBWJLxCm9ACXHn1HabNHK5VLj51zZfy3MpdpCS=kFA@mail.gmail.com>
Message-ID: <CAMf4N71_hnqJ_THvKZ123wONzonJFrKjFqBBQrnoKg3g=8ueBg@mail.gmail.com>

Hi Satish,

We have separate RMQ/DB nodes. I think 5 and 7 nodes respectively. Yet
all these nodes are listed under [control] as well, they still get
other controller components deployed on them. However I think the big
difference is that they are high-end bare metal servers: apps have
plenty of resources to run on. Big machines, easy life.

As to slowiness: I never noticed any slowiness when I work through
APIs or Horizon. Maybe I got used to it and forgot how fast it used to
be. If you have strict response time policies, it may not be ideal.
But since it's a private cloud,  we consider it as a simple trade-off.

I don't want to jinx it for myself but we haven't had a RMQ issue for
a while now. I have heard people taking care of small clusters
complain about RMQ too: at this point I am not sure if RMQ has a
scaling problem or it's just luck of a draw.

As I said above, it comes down to choice. We chose this way because we
can tolerate its shortcomings.

On Thu, 6 Apr 2023 at 18:37, Satish Patel <satish.txt at gmail.com> wrote:
>
> Hi Can,
>
> Thank you for sharing information. I am surprised how you are running that many nodes with a single control plan. Could you share info about how many controllers you have? Do you have separate rabbitMQ nodes/DB nodes etc.
>
> I have 350 compute nodes with 3x controller nodes and it works fine but the problem is slowness. I felt it was a little slower compared to smaller environments. Also I googled about it and most people suggested using 100 nodes per deployment for easy management.
>
> In my deployment I have all vlan based tenants so my network nodes are kind of useless and just for DHCP. mostly i am worried about RabbitMQ.
>
>
> On Thu, Apr 6, 2023 at 2:54?AM Can ?zyurt <acozyurt at gmail.com> wrote:
>>
>> Hi,
>>
>> Technically yes. We have had more than a thousand nodes in a single
>> cell for years on production. But we are considering adding more cells
>> as we grow bigger and bigger.
>>
>> On Thu, 6 Apr 2023 at 03:25, Satish Patel <satish.txt at gmail.com> wrote:
>> >
>> > Hi Can,
>> >
>> > You are saying a single control plan can handle 600 compute nodes?
>> >
>> > On Wed, Apr 5, 2023 at 5:36?PM Can ?zyurt <acozyurt at gmail.com> wrote:
>> >>
>> >> It's totally okay to use regions as AZs if that's what you need,
>> >> unless you are planning to deploy in another city. Then you will be
>> >> already exhausting the term region and you will have been left with
>> >> much more to deal with. Ultimately it comes down to needs and future
>> >> plans.
>> >>
>> >> Secondly, I think you should be fine with a single cell anyway as we
>> >> have much more in one cell. However experience may vary depending on
>> >> the volume and characteristics of the daily workload and the design of
>> >> the control plane, so maybe you should take someone else's word with
>> >> more in-depth knowledge for the guidance.
>> >>
>> >> Cheers.
>> >>
>> >> On Wed, 5 Apr 2023 at 18:47, Satish Patel <satish.txt at gmail.com> wrote:
>> >> >
>> >> > Folks,
>> >> >
>> >> > This is a very broad question and could have many answers but still wanted to ask to see what people are thinking and doing.
>> >> >
>> >> > We have DC with multiple racks and around 600 nodes so we are planning to create 3 private openstack and each with 200 nodes. In other data centers we have multiple 200 nodes openstack clusters and life is good. In the new datacenter I am thinking of deploying the same way openstack but shared keystone between multiple openstack environments to have a single place for identification and I am going to call it 3 regions even it's in a single DC. Hope shared keystone is helpful/easier for doing terrafrom work and selecting region easily.
>> >> >
>> >> > Other option I was thinking about to deploy cellv2 technology and put all 600 nodes in single cloud but always worried for operation point of view. Now sure how many people running cellv2 successfully without pain. (Except CERN)
>> >> >
>> >> > If people running multi-region openstack cloud then please share some thought and idea to make life easier. Not looking for best solution but just clue to get idea to deploy and manage multiple openstack.
>> >> >
>> >> > Thanks in advance.
>> >> > S
>> >> >
>> >> >


From noonedeadpunk at gmail.com  Thu Apr  6 17:40:06 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Thu, 6 Apr 2023 19:40:06 +0200
Subject: [nova][cinder] why volumes can only be attached and dettached for
 running instances
In-Reply-To: <d81a813f3d90a2efddd38fe7d8e4ea586c9d0cd9.camel@redhat.com>
References: <CAJbin1BMNgYycd4782ujS_1BDFNWJUrgxzJ-TPm+j1dK0-Yttg@mail.gmail.com>
 <d81a813f3d90a2efddd38fe7d8e4ea586c9d0cd9.camel@redhat.com>
Message-ID: <CAPd_6AtXaoPAzp+dfAJdc06Xb+n1fDhaq6yCV0RfOqy6Aox_Lg@mail.gmail.com>

Just in case, attach/detach of root volumes is still not possible even in
shelve_offlodaded state, despite it was proposed couple of times with
following spec [1]

[1]
https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/detach-boot-volume.html

??, 6 ???. 2023 ?., 18:32 Sean Mooney <smooney at redhat.com>:

> On Thu, 2023-04-06 at 23:21 +0800, kaqiu pi wrote:
> > hello,
> >
> > I can only attached and dettached volumes for running instances in
> > openstack.
> nova allows you to attach volume to instance that are stopped.
> instance in the shelve offloaded state required micoverion  v2.20 and
> multi attach requires  v2.60
>
> https://docs.openstack.org/api-ref/compute/?expanded=attach-a-volume-to-an-instance-detail#attach-a-volume-to-an-instance
>
> for volume attachment to work with virtio blk you need to hanve enough pci
> slots in teh vm free for the pci hotplug to succeed.
>
> if you are using vritio-scsi via hw_disk_bus=scsi the pci requirement does
> not apply.
>
> >
> >
> > I would like to ask the reason for this design. And is there any
> > danger if this restriction is turned on through custom modification in
> > a private scene?
> >
> >
> > Thank you so much.
> > Yours
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/35551ace/attachment-0001.htm>

From satish.txt at gmail.com  Thu Apr  6 17:52:34 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Thu, 6 Apr 2023 13:52:34 -0400
Subject: multi-region deployment within datacenter scenario
In-Reply-To: <CAMf4N71_hnqJ_THvKZ123wONzonJFrKjFqBBQrnoKg3g=8ueBg@mail.gmail.com>
References: <CAPgF-fqT1oVa-bYGFdzXUrTpLpuECiuo6RcuvxbnJ-8WZt_avA@mail.gmail.com>
 <CAMf4N72V5vMVdWEyU2c+MM_Xx25ZviRijnkM-eYsqTVbyVkCyg@mail.gmail.com>
 <CAPgF-fqSEQQDmEygJ+ybsjj7YC8tb-mO8hBrOs=xmLe=MatfWQ@mail.gmail.com>
 <CAMf4N71pBZAoubGCtTMh+O-sJG28+EmgRuzGYrBBidtQ-AFJMw@mail.gmail.com>
 <CAPgF-fpfJBWJLxCm9ACXHn1HabNHK5VLj51zZfy3MpdpCS=kFA@mail.gmail.com>
 <CAMf4N71_hnqJ_THvKZ123wONzonJFrKjFqBBQrnoKg3g=8ueBg@mail.gmail.com>
Message-ID: <CAPgF-fr-k=p1vsfv+R3N5ZFY0n=-nrC+eBnX=NF3-N6Hz=8sDw@mail.gmail.com>

Thanks!!! It's helpful. We are using an openstack-ansible tool for
deployment. Ma

On Thu, Apr 6, 2023 at 12:44?PM Can ?zyurt <acozyurt at gmail.com> wrote:

> Hi Satish,
>
> We have separate RMQ/DB nodes. I think 5 and 7 nodes respectively. Yet
> all these nodes are listed under [control] as well, they still get
> other controller components deployed on them. However I think the big
> difference is that they are high-end bare metal servers: apps have
> plenty of resources to run on. Big machines, easy life.
>
> As to slowiness: I never noticed any slowiness when I work through
> APIs or Horizon. Maybe I got used to it and forgot how fast it used to
> be. If you have strict response time policies, it may not be ideal.
> But since it's a private cloud,  we consider it as a simple trade-off.
>
> I don't want to jinx it for myself but we haven't had a RMQ issue for
> a while now. I have heard people taking care of small clusters
> complain about RMQ too: at this point I am not sure if RMQ has a
> scaling problem or it's just luck of a draw.
>
> As I said above, it comes down to choice. We chose this way because we
> can tolerate its shortcomings.
>
> On Thu, 6 Apr 2023 at 18:37, Satish Patel <satish.txt at gmail.com> wrote:
> >
> > Hi Can,
> >
> > Thank you for sharing information. I am surprised how you are running
> that many nodes with a single control plan. Could you share info about how
> many controllers you have? Do you have separate rabbitMQ nodes/DB nodes etc.
> >
> > I have 350 compute nodes with 3x controller nodes and it works fine but
> the problem is slowness. I felt it was a little slower compared to smaller
> environments. Also I googled about it and most people suggested using 100
> nodes per deployment for easy management.
> >
> > In my deployment I have all vlan based tenants so my network nodes are
> kind of useless and just for DHCP. mostly i am worried about RabbitMQ.
> >
> >
> > On Thu, Apr 6, 2023 at 2:54?AM Can ?zyurt <acozyurt at gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> Technically yes. We have had more than a thousand nodes in a single
> >> cell for years on production. But we are considering adding more cells
> >> as we grow bigger and bigger.
> >>
> >> On Thu, 6 Apr 2023 at 03:25, Satish Patel <satish.txt at gmail.com> wrote:
> >> >
> >> > Hi Can,
> >> >
> >> > You are saying a single control plan can handle 600 compute nodes?
> >> >
> >> > On Wed, Apr 5, 2023 at 5:36?PM Can ?zyurt <acozyurt at gmail.com> wrote:
> >> >>
> >> >> It's totally okay to use regions as AZs if that's what you need,
> >> >> unless you are planning to deploy in another city. Then you will be
> >> >> already exhausting the term region and you will have been left with
> >> >> much more to deal with. Ultimately it comes down to needs and future
> >> >> plans.
> >> >>
> >> >> Secondly, I think you should be fine with a single cell anyway as we
> >> >> have much more in one cell. However experience may vary depending on
> >> >> the volume and characteristics of the daily workload and the design
> of
> >> >> the control plane, so maybe you should take someone else's word with
> >> >> more in-depth knowledge for the guidance.
> >> >>
> >> >> Cheers.
> >> >>
> >> >> On Wed, 5 Apr 2023 at 18:47, Satish Patel <satish.txt at gmail.com>
> wrote:
> >> >> >
> >> >> > Folks,
> >> >> >
> >> >> > This is a very broad question and could have many answers but
> still wanted to ask to see what people are thinking and doing.
> >> >> >
> >> >> > We have DC with multiple racks and around 600 nodes so we are
> planning to create 3 private openstack and each with 200 nodes. In other
> data centers we have multiple 200 nodes openstack clusters and life is
> good. In the new datacenter I am thinking of deploying the same way
> openstack but shared keystone between multiple openstack environments to
> have a single place for identification and I am going to call it 3 regions
> even it's in a single DC. Hope shared keystone is helpful/easier for doing
> terrafrom work and selecting region easily.
> >> >> >
> >> >> > Other option I was thinking about to deploy cellv2 technology and
> put all 600 nodes in single cloud but always worried for operation point of
> view. Now sure how many people running cellv2 successfully without pain.
> (Except CERN)
> >> >> >
> >> >> > If people running multi-region openstack cloud then please share
> some thought and idea to make life easier. Not looking for best solution
> but just clue to get idea to deploy and manage multiple openstack.
> >> >> >
> >> >> > Thanks in advance.
> >> >> > S
> >> >> >
> >> >> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/36b476f0/attachment.htm>

From fungi at yuggoth.org  Thu Apr  6 18:17:34 2023
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Thu, 6 Apr 2023 18:17:34 +0000
Subject: [tc] May 2023 OpenInfra Board Sync
Message-ID: <20230406181733.ywtxuapkwvvh7tlz@yuggoth.org>

The Open Infrastructure Foundation Board of Directors is endeavoring
to engage in regular check-ins with official OpenInfra projects. The
goal is for a loosely structured discussion one-hour in length,
involving members of the board and the OpenStack TC, along with
other interested community members. This is not intended to be a
formal presentation, and no materials need to be prepared in
advance. I've started an Etherpad where participants can brainstorm
potential topics of conversation, time-permitting:
https://etherpad.opendev.org/p/2023-05-board-openstack-sync

Immediately following the February 8 discussion, I proposed to
schedule the next call for 20:00 UTC on Wednesday, May 10 and heard
no objections, so I've attached a calendar file which can serve as a
convenient schedule hold for this, in case anyone needs it.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2023-05-board-openstack-sync.ics
Type: text/calendar
Size: 620 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/21807197/attachment.ics>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/21807197/attachment.sig>

From yasufum.o at gmail.com  Thu Apr  6 18:25:48 2023
From: yasufum.o at gmail.com (Yasufumi Ogawa)
Date: Fri, 7 Apr 2023 03:25:48 +0900
Subject: [tacker][ptg] Tacker PTG Summary
Message-ID: <1c0b6fee-0b8d-89dc-f086-f4f27b88174c@gmail.com>

Hi team,

Thank you for joining our three days vPTG sessions for Tacker bobcat. It 
was three days and we had about 20 attendees each day. You can find all 
the result of discussions in [1] and cross project session with 
Keystone, Ironic and Barbican for supporting external authz for OAuth2.0 
[2]. Here is a summary of our vPTG.

- We shared several issues of functional tests have been suffered us for 
unexpected failures through the latest cycles and agree to revise the 
tests. Current target include refactoring messed directory structure and 
useless logs, reducing too much timeouts or redefining test scenarios.

- For docs, there is no instruction for supported versions of k8s, helm 
or prometheus introduced in Tacker in the latest releases. There is also 
something missing instructions or too old contents. We've agreed to make 
a plan to update the docs and complete TODOs in bobcat.

- Enable tacker to get error messages of management driver as a 
requirement from operators.

- Share the current status of secure RBAC support in Tacker and remained 
tasks mainly for implementing unit and functional tests and documentation.

- We agreed to introduct a new feature for supporting external key 
manager for authn credentials with encryption for security and custom 
resources for the latest k8s cluster APIs.

- Discussed a requirement for supporting terraform infra-driver for some 
usecases deloying telco systems on cloud-based infra, and roughly agreed 
to include the feature into Tacker although we need to have some more 
surveys for implementation details.

- We've had several proposals for improving our dev scheme such as 
introducing type annotation, plantUML for docs or so.

- Shared the current status of Pypi maintainer cleanup.

[1] https://etherpad.opendev.org/p/tacker-bobcat-ptg
[2] https://etherpad.opendev.org/p/bobcat-ptg-ext_oauth2_server


From akanevsk at redhat.com  Thu Apr  6 18:31:36 2023
From: akanevsk at redhat.com (Arkady Kanevsky)
Date: Thu, 6 Apr 2023 13:31:36 -0500
Subject: [interop][ptg] Interop Bobcat vPTG summary
In-Reply-To: <CAKZGdE3M_m9NpNtQq7S1HY0ASVso_RO8gq61c3pnzeVAT2+0Qg@mail.gmail.com>
References: <CAKZGdE3M_m9NpNtQq7S1HY0ASVso_RO8gq61c3pnzeVAT2+0Qg@mail.gmail.com>
Message-ID: <CAEbdGYNcy1_U6kfiR4tiF-E5-Mn_ZLRAiyFeF3cwgh38X3kmDw@mail.gmail.com>

Thanks Martin

On Thu, Apr 6, 2023 at 9:13?AM Martin Kopec <mkopec at redhat.com> wrote:

> Hi everyone,
>
> here is a summary of the discussions. The full agenda can be found here
> [1].
>
> == Current pain points and challenges of interop testing ==
> The current guidelines don't contain complex enough tests - apart from api
> tests we should also have more functional tests which mock users'
> interactions with the cloud - we should test as a real user would use the
> cloud.
>
> People could fake the refstack results - after a discussion we came to an
> agreement that those people would always find a way, there is no need for
> coming up with sophisticated ways to prevent it. The point of Interop is to
> provide a check for vendors/users to see where they stand with their
> product based on the agreed standards.
>
> Use of Interop's tooling is complicated - there have been reports that
> users struggle with refstack-client and tempest. There is an ongoing effort
> to create a refstack container which would contain all necessary tools and
> could be run with just one command.
>
> Passing the Interop's guidelines means interoperability on which level?
> Passing the guidelines should mean being in compliance with the beforehand
> community agreed upon standards.
>
> Getting vendors running the interop tests more often - we only came up
> with the strategies which are already being used, such as expirations and
> guideline versioning.
>
> == Future strategy ==
> The future strategy could be summarized in 3 points:
> * discuss the possibility for using sdk-based and tobiko testing
> * better describe to users the expectations they should have for clouds
> which assert interoperability
> * look into expiration of older standards and require that compliant
> providers indicate to users which version of the standard they last
> tested/passed
>
> [1] https://etherpad.opendev.org/p/bobcat-ptg-interop
>
> Regards,
> --
> Martin Kopec
> Principal Software Quality Engineer
> Red Hat EMEA
> IM: kopecmartin
>
>
>
>

-- 
Arkady Kanevsky, Ph.D.
Phone: 972 707-6456
Corporate Phone: 919 729-5744 ext. 8176456
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/a45bf2eb/attachment-0001.htm>

From maksim.malchuk at gmail.com  Thu Apr  6 18:46:02 2023
From: maksim.malchuk at gmail.com (Maksim Malchuk)
Date: Thu, 6 Apr 2023 21:46:02 +0300
Subject: multi-region deployment within datacenter scenario
In-Reply-To: <CAPgF-fqSEQQDmEygJ+ybsjj7YC8tb-mO8hBrOs=xmLe=MatfWQ@mail.gmail.com>
References: <CAPgF-fqT1oVa-bYGFdzXUrTpLpuECiuo6RcuvxbnJ-8WZt_avA@mail.gmail.com>
 <CAMf4N72V5vMVdWEyU2c+MM_Xx25ZviRijnkM-eYsqTVbyVkCyg@mail.gmail.com>
 <CAPgF-fqSEQQDmEygJ+ybsjj7YC8tb-mO8hBrOs=xmLe=MatfWQ@mail.gmail.com>
Message-ID: <CAE_fguBTZGa3yeoPYRO5B-zbtcdLz9BVPRC92hpNZpsTmHoDWg@mail.gmail.com>

Three control plane nodes with one nova-cell can handle up to 3000-5000 vms
without any problems. But RabbitMQ and Nova need some tuning for
timeouts/limits to raise the defaults.


On Thu, Apr 6, 2023 at 3:31?AM Satish Patel <satish.txt at gmail.com> wrote:

> Hi Can,
>
> You are saying a single control plan can handle 600 compute nodes?
>
> On Wed, Apr 5, 2023 at 5:36?PM Can ?zyurt <acozyurt at gmail.com> wrote:
>
>> It's totally okay to use regions as AZs if that's what you need,
>> unless you are planning to deploy in another city. Then you will be
>> already exhausting the term region and you will have been left with
>> much more to deal with. Ultimately it comes down to needs and future
>> plans.
>>
>> Secondly, I think you should be fine with a single cell anyway as we
>> have much more in one cell. However experience may vary depending on
>> the volume and characteristics of the daily workload and the design of
>> the control plane, so maybe you should take someone else's word with
>> more in-depth knowledge for the guidance.
>>
>> Cheers.
>>
>> On Wed, 5 Apr 2023 at 18:47, Satish Patel <satish.txt at gmail.com> wrote:
>> >
>> > Folks,
>> >
>> > This is a very broad question and could have many answers but still
>> wanted to ask to see what people are thinking and doing.
>> >
>> > We have DC with multiple racks and around 600 nodes so we are planning
>> to create 3 private openstack and each with 200 nodes. In other data
>> centers we have multiple 200 nodes openstack clusters and life is good. In
>> the new datacenter I am thinking of deploying the same way openstack but
>> shared keystone between multiple openstack environments to have a single
>> place for identification and I am going to call it 3 regions even it's in a
>> single DC. Hope shared keystone is helpful/easier for doing terrafrom work
>> and selecting region easily.
>> >
>> > Other option I was thinking about to deploy cellv2 technology and put
>> all 600 nodes in single cloud but always worried for operation point of
>> view. Now sure how many people running cellv2 successfully without pain.
>> (Except CERN)
>> >
>> > If people running multi-region openstack cloud then please share some
>> thought and idea to make life easier. Not looking for best solution but
>> just clue to get idea to deploy and manage multiple openstack.
>> >
>> > Thanks in advance.
>> > S
>> >
>> >
>>
>

-- 
Regards,
Maksim Malchuk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/2af481e2/attachment.htm>

From satish.txt at gmail.com  Thu Apr  6 19:53:34 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Thu, 6 Apr 2023 15:53:34 -0400
Subject: multi-region deployment within datacenter scenario
In-Reply-To: <CAOSYKmifdDfaeBA1=mQa3CeqxangDiVYH5D8M_N4p9nVzihuMA@mail.gmail.com>
References: <CAPgF-fqT1oVa-bYGFdzXUrTpLpuECiuo6RcuvxbnJ-8WZt_avA@mail.gmail.com>
 <CAOSYKmifdDfaeBA1=mQa3CeqxangDiVYH5D8M_N4p9nVzihuMA@mail.gmail.com>
Message-ID: <CAPgF-foq=8He=Q4Ro38Cu=MXkSaewBXEgL9hiUzihQBUktPV5A@mail.gmail.com>

Hi Piotr,

Basically we use a vlan base tenant so the network node has very less
usage. All my vms talk directly to the physical network and go out via the
edge router. Our VM churn rate is also low because it's a private cloud. I
am thinking of creating 3x API nodes and 3x RabbitMQ/DB nodes (total 6
nodes control plane and hope it works fine).

One big advantage of having multiple pods (deployments) so during upgrade
or any issue we have backup to work.


On Thu, Apr 6, 2023 at 3:42?PM Piotr Misiak <piotrmisiak1984 at gmail.com>
wrote:

> Hi Satish,
>
> Nova is well designed to handle hundreds of nodes. I would take a look at
> Neutron instead, because it doesn?t scale very well. It depends on how your
> networking configuration and use cases look like.
>
> BR,
> Piotr
>
> On Wed, 5 Apr 2023 at 17:46 Satish Patel <satish.txt at gmail.com> wrote:
>
>> Folks,
>>
>> This is a very broad question and could have many answers but still
>> wanted to ask to see what people are thinking and doing.
>>
>> We have DC with multiple racks and around 600 nodes so we are planning to
>> create 3 private openstack and each with 200 nodes. In other data centers
>> we have multiple 200 nodes openstack clusters and life is good. In the new
>> datacenter I am thinking of deploying the same way openstack but shared
>> keystone between multiple openstack environments to have a single place for
>> identification and I am going to call it 3 regions even it's in a single
>> DC. Hope shared keystone is helpful/easier for doing terrafrom work and
>> selecting region easily.
>>
>> Other option I was thinking about to deploy cellv2 technology and put all
>> 600 nodes in single cloud but always worried for operation point of view.
>> Now sure how many people running cellv2 successfully without pain. (Except
>> CERN)
>>
>> If people running multi-region openstack cloud then please share some
>> thought and idea to make life easier. Not looking for best solution but
>> just clue to get idea to deploy and manage multiple openstack.
>>
>> Thanks in advance.
>> S
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/7e5b99a3/attachment.htm>

From toheeb.olawale.to23 at gmail.com  Thu Apr  6 21:09:57 2023
From: toheeb.olawale.to23 at gmail.com (Toheeb Oyekola)
Date: Thu, 6 Apr 2023 22:09:57 +0100
Subject: [outreachy][cinder] Unable to generate api-ref samples for snapshot
 transfer
Message-ID: <CABPq-iOV1BgQJDvAbKRiSMtOCMQuLLPCBtWZSGqQ3mf55yy+6w@mail.gmail.com>

Hi,

I am trying to generate api-ref doc from template by running "tox -e
snaphot_transfer" but I keep getting the same error pasted in the link
https://paste.openstack.org/show/bFPbWKQAKRbIds4R0wWn
and I have installed the missing dependency as shown below, anyone have an
Idea what the issue could have been?

Thanks for your time.



[image: image.png]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/45f22657/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 38186 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230406/45f22657/attachment-0001.png>

From nguyenhuukhoinw at gmail.com  Fri Apr  7 00:28:29 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Fri, 7 Apr 2023 07:28:29 +0700
Subject: [kolla-ansible] updating procedure
In-Reply-To: <30d2a125cea45ee7fe705f48e21aa7b24e72be0b.camel@redhat.com>
References: <CAJV_UBDTLHb-Lxuz5-gCx4x1Uqa=1YjyeJ540rRD2ZG2PdcFKA@mail.gmail.com>
 <30d2a125cea45ee7fe705f48e21aa7b24e72be0b.camel@redhat.com>
Message-ID: <CABAODRfM__xa_OexRKbHRZ4MD4NtZ54kV3mn52=qYT7yx7U_fg@mail.gmail.com>

Thanks a lot.
That is what I am looking for some days.
Nguyen Huu Khoi


On Thu, Apr 6, 2023 at 7:16?PM Sean Mooney <smooney at redhat.com> wrote:

> On Thu, 2023-04-06 at 12:44 +0100, wodel youchi wrote:
> > Hi,
> >
> > This is what documentation says about updating kolla-ansible : "Inside a
> > series, it is usually sufficient to just update the kolla-ansible
> package,
> > rebuild (if needed) and pull the images, and run kolla-ansible deploy
> > again. Please follow release notes to check if there are any issues to be
> > aware of."
> >
> > So to summarize, the procedure is like this :
> > 1 - update kolla-ansible
> > 2 - Download the latest containers of the used version
> > 3 - In my case publish them in the local registry
> > 4 - launch kolla-ansible deploy
> >
> > My question :
> > Can I do the update directly , especially on the compute nodes, or do I
> > have to empty some of them by moving VMs and execute the update on the
> > empty nodes only, then proceed with the same logic with the rest of the
> > nodes?
> in general yes. however depending on the option you selected there can be
> some downtime.
> for example recreating the libvirt/nova-comptue contaienr will not cause
> teh vm to stop running.
> the libvirt contaienr runs with pid=host so the qemu process is not
> actully runing in the contaienr.
> obvioulsy if you have started using the host installed libvirt feature
> then that is also true.
>
> if you are using kernel ovs then restart the ovs contaienr to update it
> does not impact the datapath
> since that is runningin the ovs kernel module your are just updating the
> contol plane when you upgrade the
> contianer.
>
>
> stateless services like nova-api will also just work
>
> where you have to be careful is any contaienr that is in the datapath.
>
> for example if you are using iscsid to export cinder lvm
> since cinder lvm is not HA the restart of iscsid can cause the vms to
> loose access to storage.
>
> if your using ceph that is not a problem.
>
>
> if your using ovn you may similar have some connectiv issue while the
> distributed contoelrs are recomputing
> ther flows.
> in general the flow cache in ovs is enough to hide that but new
> connections wont be establised until the new contaienr starts up properly.
>
> that is why its imporant to pull the images first to keep that start up
> time as short as possible.
>
> i dont know how many users of kolla actully use the inplace upgrade with
> production workload.
> you can obviouly drain a compute of vms and use --limit to update only
> empty comptues and live migrate workloads around too.
>
> but in principal i belive inplcae upgrade should be possible.
>
> the kolla team can confirm but when i used to use kolla for an internal
> dev cloud in my previous job (with ceph) i did not move instances
> when i upgraded the cluster.
> >
> > Regards.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230407/31453f58/attachment.htm>

From rosmaita.fossdev at gmail.com  Fri Apr  7 13:49:58 2023
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Fri, 7 Apr 2023 09:49:58 -0400
Subject: [outreachy][cinder] Unable to generate api-ref samples for
 snapshot transfer
In-Reply-To: <CABPq-iOV1BgQJDvAbKRiSMtOCMQuLLPCBtWZSGqQ3mf55yy+6w@mail.gmail.com>
References: <CABPq-iOV1BgQJDvAbKRiSMtOCMQuLLPCBtWZSGqQ3mf55yy+6w@mail.gmail.com>
Message-ID: <835e8e9c-18de-966e-d067-dc3df5bc0874@gmail.com>

Hi Toheeb.  Thanks for working on this!

On 4/6/23 5:09 PM, Toheeb Oyekola wrote:
> Hi,
> 
> I am trying?to generate api-ref doc from template by running "tox -e 
> snaphot_transfer" but I keep getting the?same error pasted in the link 
> https://paste.openstack.org/show/bFPbWKQAKRbIds4R0wWn 
> <https://paste.openstack.org/show/bFPbWKQAKRbIds4R0wWn>
> and I have installed the missing dependency as shown below, anyone have 
> an Idea what the issue could have been?

There are two reasons you might be seeing the ModuleNotFoundError:
1 - dependency missing
2 - you have the dependency, but the module isn't in that version

What you're seeing is #2.  SQLAlchemy 2.0 doesn't contain the 
sqlalchemy.databases module:

[master] wha'ppen? .tox/venv/bin/pip freeze | grep -i sqlalchemy==
SQLAlchemy==2.0.9
[master] wha'ppen? .tox/venv/bin/python
Python 3.10.10 ...
 >>> from sqlalchemy.databases import sqlite as sa_base
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'sqlalchemy.databases'
 >>>

But this module does exist in SQLAlchemy 1.4:

[master] wha'ppen? .tox/py310/bin/pip freeze | grep -i sqlalchemy==
SQLAlchemy==1.4.41
[master] wha'ppen? .tox/py310/bin/python
Python 3.10.10 ...
 >>> from sqlalchemy.databases import sqlite as sa_base
 >>>

The cinder tox.ini file uses upper-constraints to force tox to install 
the appropriate versions of dependencies.  Right now, that's 
SQLAlchemy===1.4.41, which you can see if you search this file:

https://opendev.org/openstack/requirements/raw/branch/master/upper-constraints.txt

The cinder tox.ini file uses upper constraints here:

https://opendev.org/openstack/cinder/src/commit/42ef47ba26ab15c526afa7eec7f243bd1c97f770/tox.ini#L58

I think what may be happening in your case is that you've set up a 
custom tox testenv named 'snapshot_transfer' and it is using the tox 
default install_command, that doesn't constrain dependencies, and so 
you're winding up with SQLAlchemy 2.0.  Make sure that it contains this 
line from the "regular" api-samples testenv:

https://opendev.org/openstack/cinder/src/commit/42ef47ba26ab15c526afa7eec7f243bd1c97f770/tox.ini#L71

By the way, if you just want to run your new snapshot_transfers tests, 
you can use the "regular" api-samples testenv like this:

tox -e api-samples -- api_sample_tests.test_snapshots

That runs all the tests in 
cinder/tests/functional/api_sample_tests/test_snapshots.py ; just adjust 
it to the name of your file containing the snapshot transfers tests.


Or you may be doing all this stuff already and the problem may be 
something else entirely.

> 
> Thanks for your time.
> 
> 
> 
> image.png



From nguyenhuukhoinw at gmail.com  Fri Apr  7 14:25:13 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Fri, 7 Apr 2023 21:25:13 +0700
Subject: [kolla-ansible]ask about multi region deploymet
Message-ID: <CABAODRdjnJ9sU9e9YaAWqiQUogmD=EWA76Az3t+7Zoe-ky2jZQ@mail.gmail.com>

Hello.

I have read about kolla ansible multi regions.
Can i ask that do we need 2 deployment host? And can we use 3 controller
each region?
I searched on Internet, I see that controller just sit on region one only?
Please advise.
Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230407/296fc434/attachment.htm>

From noonedeadpunk at gmail.com  Fri Apr  7 15:20:35 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Fri, 7 Apr 2023 17:20:35 +0200
Subject: [all] Hold your rechecks
In-Reply-To: <CAPd_6AuCrCiHK9VZMGON_uNb=_Y-aZ3BL9BfugGG2rFDGscfiQ@mail.gmail.com>
References: <CAPd_6Av=uqJRUm2YDZty+wd6ZLBR_9tCW9y+GGE-0wZFa4ZVNw@mail.gmail.com>
 <CALOCmukk8j6Wc6Hb4dkeGVn7okWOWX-GL_T7zUF=kAKiXqJgkw@mail.gmail.com>
 <CAPd_6AuCrCiHK9VZMGON_uNb=_Y-aZ3BL9BfugGG2rFDGscfiQ@mail.gmail.com>
Message-ID: <CAPd_6AuSz5BPfVeZTnM--cS3TvKuqDEMw4yocGCwQ7NxE+M6DA@mail.gmail.com>

Hi everyone,

CentOS 9 Stream has rolled back gpupg version to 2.3.3-2 and this has
already hit mirrors. So there should be no hard blockers present, so
feel free to recheck CentOS jobs.

??, 5 ???. 2023??. ? 18:22, Dmitriy Rabotyagov <noonedeadpunk at gmail.com>:
>
> Yes, sorry, I should have clarified that.
> Only projects that do have CentOS 9 Stream jobs in their pipelines and
> that are Voting should hold rechecks in case of issues with CentOS
> jobs related to failed GPG check of packages/repos.
>
> ??, 5 ???. 2023??. ? 18:09, Sylvain Bauza <sbauza at redhat.com>:
> >
> >
> >
> > Le mer. 5 avr. 2023 ? 17:50, Dmitriy Rabotyagov <noonedeadpunk at gmail.com> a ?crit :
> >>
> >> Hi everyone,
> >>
> >> Due to the recent update of gnupg2 package for CentOS Stream 9 to the
> >> version 2.3.3-3, a lot of repositories, including BaseOS and NFV, are
> >> failing to pass GPG check [1]. This affects all latest images,
> >> including container and cloud ones. At the moment, images used in Zuul
> >> are not affected, but this might change with the next periodic rebuild
> >> unless the related BZ report is fixed.
> >> Explicit execution of `rpm --import` can be used as a temporary workaround.
> >>
> >
> > To clarify, projects that run centos9stream jobs in check pipeline should hold their rechecks, for sure, but for other services like Nova which *don't* run c9s jobs on check (only on periodic-weekly), then they shouldn't have those issues, right?
> > -S
> >
> >>
> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2184640
> >>


From zhouxinyong at inspur.com  Fri Apr  7 03:10:00 2023
From: zhouxinyong at inspur.com (=?utf-8?B?SmVycnkgWmhvdSAo5ZGo6ZGr5YuHKQ==?=)
Date: Fri, 7 Apr 2023 03:10:00 +0000
Subject: =?utf-8?B?562U5aSNOiBbcHRsXSBOZWVkIFBUTCB2b2x1bnRlZXIgZm9yIE9wZW5TdGFj?=
 =?utf-8?Q?k_Sahara?=
In-Reply-To: <7d2aa6aaffb844e3b28517cdba3b7c54@inspur.com>
References: <1870a9accaa.ca4d3931996653.2888367201531485088@ghanshyammann.com>
 <5133a1c69a4e4d579514eccaa03dd8cd@inspur.com>
 <7d2aa6aaffb844e3b28517cdba3b7c54@inspur.com>
Message-ID: <1cceee9b4afa459d9c64c1c106304b85@inspur.com>

Hi Gmann,
  I can lead this project.

-----????-----
???: Ghanshyam Mann <gmann at ghanshyammann.com>
????: 2023?3?23? 2:35
???: Qiujunting <qiujunting at inspur.com>; openstack-discuss 
<openstack-discuss at lists.openstack.org>
??: [ptl] Need PTL volunteer for OpenStack Sahara

Hi Qiu,

I am reaching out to you as you were PTL for OpenStack Sahara project in the 
last cycle.

There is no PTL candidate for the next cycle (2023.2), and it is on the 
leaderless project list. Please check if you or anyone you know would like to 
lead this project.

- https://etherpad.opendev.org/p/2023.2-leaderless

Also, if anyone else would like to help leading this project, this is time to 
let TC knows.

-gmann


From nguyenhuukhoinw at gmail.com  Sat Apr  8 10:37:33 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Sat, 8 Apr 2023 17:37:33 +0700
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3 controller
 was be down
Message-ID: <CABAODRdLhuX77ny=exdhe6rpxfOKFXfn5WOFD0yL8oHK6ZXv4g@mail.gmail.com>

Hello everyone.

I want to summary for who meets problems with Openstack when deploy cluster
with 3 controller using Kolla Ansible

Scenario: 1 of 3 controller is down

1. Login horizon and use API such as nova, cinder will be very slow

fix by:

nano:
kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2

or which service need caches

add as below

[cache]
backend = oslo_cache.memcache_pool
enabled = True
memcache_servers = {{ kolla_internal_vip_address }}:{{ memcached_port }}
memcache_dead_retry = 0.25
memcache_socket_timeout = 900

https://review.opendev.org/c/openstack/kolla-ansible/+/849487

but it is not the end

2. Cannot launch instance or mapping block device(stuck at this step)

nano kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2

"policies":[
    {"vhost": "/", "name": "ha-all", "pattern":
"^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition":
{"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
    {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all",
"pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"},
"priority":0}
    {% endif %}
  ]

nano /etc/kollla/global.conf

[oslo_messaging_rabbit]
kombu_reconnect_delay=0.5


https://bugs.launchpad.net/oslo.messaging/+bug/1993149
https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html

I used Xena 13.4 and Yoga 14.8.1.

Above bugs are critical, but I see that it was not fixed. I am just an
operator and I want to share what I encountered for new people who come to
Openstack


Nguyen Huu Khoi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230408/e11a5159/attachment.htm>

From satish.txt at gmail.com  Sun Apr  9 03:16:43 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Sat, 8 Apr 2023 23:16:43 -0400
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CABAODRdLhuX77ny=exdhe6rpxfOKFXfn5WOFD0yL8oHK6ZXv4g@mail.gmail.com>
References: <CABAODRdLhuX77ny=exdhe6rpxfOKFXfn5WOFD0yL8oHK6ZXv4g@mail.gmail.com>
Message-ID: <CAPgF-fqwuGRa3Mf6euhW=kUSGNhNURTqguG6=fi=_2hiTqO0sQ@mail.gmail.com>

Are you proposing a solution or just raising an issue?

I did find it strange that kolla-ansible doesn't support HA queue by
default. That is a disaster because when one of the nodes goes down it will
make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have to add
HA policy to make queue HA otherwise you will endup in problem.

On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Hello everyone.
>
> I want to summary for who meets problems with Openstack when deploy
> cluster with 3 controller using Kolla Ansible
>
> Scenario: 1 of 3 controller is down
>
> 1. Login horizon and use API such as nova, cinder will be very slow
>
> fix by:
>
> nano:
> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
>
> or which service need caches
>
> add as below
>
> [cache]
> backend = oslo_cache.memcache_pool
> enabled = True
> memcache_servers = {{ kolla_internal_vip_address }}:{{ memcached_port }}
> memcache_dead_retry = 0.25
> memcache_socket_timeout = 900
>
> https://review.opendev.org/c/openstack/kolla-ansible/+/849487
>
> but it is not the end
>
> 2. Cannot launch instance or mapping block device(stuck at this step)
>
> nano kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
>
> "policies":[
>     {"vhost": "/", "name": "ha-all", "pattern":
> "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition":
> {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
>     {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all",
> "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"},
> "priority":0}
>     {% endif %}
>   ]
>
> nano /etc/kollla/global.conf
>
> [oslo_messaging_rabbit]
> kombu_reconnect_delay=0.5
>
>
> https://bugs.launchpad.net/oslo.messaging/+bug/1993149
> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
>
> I used Xena 13.4 and Yoga 14.8.1.
>
> Above bugs are critical, but I see that it was not fixed. I am just an
> operator and I want to share what I encountered for new people who come to
> Openstack
>
>
> Nguyen Huu Khoi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230408/d8a6ec18/attachment.htm>

From nguyenhuukhoinw at gmail.com  Sun Apr  9 03:23:31 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Sun, 9 Apr 2023 10:23:31 +0700
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CAPgF-fqwuGRa3Mf6euhW=kUSGNhNURTqguG6=fi=_2hiTqO0sQ@mail.gmail.com>
References: <CABAODRdLhuX77ny=exdhe6rpxfOKFXfn5WOFD0yL8oHK6ZXv4g@mail.gmail.com>
 <CAPgF-fqwuGRa3Mf6euhW=kUSGNhNURTqguG6=fi=_2hiTqO0sQ@mail.gmail.com>
Message-ID: <CABAODRd+Q3YNWxtxmaxgrDP=q2fYDDBZj=s6y8yUEx=k0wy2xQ@mail.gmail.com>

I just summarized what I did after googling. and hope we will fix some
patches.

Especially

[oslo_messaging_rabbit]
kombu_reconnect_delay=0.5

Nguyen Huu Khoi


On Sun, Apr 9, 2023 at 10:16?AM Satish Patel <satish.txt at gmail.com> wrote:

> Are you proposing a solution or just raising an issue?
>
> I did find it strange that kolla-ansible doesn't support HA queue by
> default. That is a disaster because when one of the nodes goes down it will
> make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have to add
> HA policy to make queue HA otherwise you will endup in problem.
>
> On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> wrote:
>
>> Hello everyone.
>>
>> I want to summary for who meets problems with Openstack when deploy
>> cluster with 3 controller using Kolla Ansible
>>
>> Scenario: 1 of 3 controller is down
>>
>> 1. Login horizon and use API such as nova, cinder will be very slow
>>
>> fix by:
>>
>> nano:
>> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
>> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
>> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
>> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
>> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
>>
>> or which service need caches
>>
>> add as below
>>
>> [cache]
>> backend = oslo_cache.memcache_pool
>> enabled = True
>> memcache_servers = {{ kolla_internal_vip_address }}:{{ memcached_port }}
>> memcache_dead_retry = 0.25
>> memcache_socket_timeout = 900
>>
>> https://review.opendev.org/c/openstack/kolla-ansible/+/849487
>>
>> but it is not the end
>>
>> 2. Cannot launch instance or mapping block device(stuck at this step)
>>
>> nano kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
>>
>> "policies":[
>>     {"vhost": "/", "name": "ha-all", "pattern":
>> "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition":
>> {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
>>     {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all",
>> "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"},
>> "priority":0}
>>     {% endif %}
>>   ]
>>
>> nano /etc/kollla/global.conf
>>
>> [oslo_messaging_rabbit]
>> kombu_reconnect_delay=0.5
>>
>>
>> https://bugs.launchpad.net/oslo.messaging/+bug/1993149
>> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
>>
>> I used Xena 13.4 and Yoga 14.8.1.
>>
>> Above bugs are critical, but I see that it was not fixed. I am just an
>> operator and I want to share what I encountered for new people who come to
>> Openstack
>>
>>
>> Nguyen Huu Khoi
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230409/511e956d/attachment.htm>

From satish.txt at gmail.com  Sun Apr  9 04:10:08 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Sun, 9 Apr 2023 00:10:08 -0400
Subject: [kolla ansible] SRIOV compute deployment question
Message-ID: <CAPgF-fq0ObLqH_2GFJSWnrjqPk76afnSpL942yMmK6UXnBV=pw@mail.gmail.com>

Folks,

I have deployed SRIOV compute but i found it deployed sriov-agent and
openvswitch-agent together. If I am not mistaken then we don't need
openvswitch agent on sriov computes nodes so how do i tell kolla to not
deploy openvswitch-agent on sriov compute nodes?

Here is the output on the compute node.

root at kolla-comp-sriov-1-1:~# docker ps --filter name=agent
CONTAINER ID   IMAGE
COMMAND                  CREATED        STATUS
 PORTS     NAMES
92af9870ee5b   docker-reg:4000/kolla/neutron-sriov-agent:zed
"dumb-init --single-?"   32 hours ago   Up 31 hours (healthy)
        neutron_sriov_agent
14aea45e8b47   docker-reg:4000/kolla/neutron-openvswitch-agent:zed
"dumb-init --single-?"   32 hours ago   Up 3 seconds (health: starting)
        neutron_openvswitch_agent

Configuration:

(venv-kolla) root at kolla-infra-1-1:/var/lib/nova# cat
/etc/kolla/config/neutron/kolla-comp-sriov-1-1/sriov_agent.ini
[sriov_nic]
physical_device_mappings = physnet1:eno50


(venv-kolla) root at kolla-infra-1-1:/var/lib/nova# cat
/etc/kolla/config/neutron/kolla-comp-sriov-1-1/ml2_conf.ini
[ml2]
mechanism_drivers = sriovnicswitch

[ml2_type_vlan]
network_vlan_ranges = physnet1:30:50
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230409/22c6641f/attachment.htm>

From wodel.youchi at gmail.com  Sun Apr  9 15:27:40 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Sun, 9 Apr 2023 16:27:40 +0100
Subject: [kolla-ansible][yoga] how to configure cinder to connect to iscsi
 target?
Message-ID: <CAJV_UBB74c78b8r1iLMdk_sX9vrFFiE4VSyOqgt=4=x15qRnYA@mail.gmail.com>

Hi,
I am trying to configure cinder to connect to an iscsi target. I am using
targetcli as my target server.

I have tested the connection from the node using iscsiadm and it works from
the OS.

Now I am trying to use the iscsid container to do the job.

I added this to my globals.yml
enable_iscsid: "yes"
enable_cinder_backend_iscsi: "yes"
enable_cinder_backend_lvm: "no"

And I created the cinder.conf file like this
[DEFAULT]
enabled_backends = rbd1,nfs-1,*lvmtnas *

# add follows to the end
[lvmtnas]
target_helper = lioadm
target_protocol = iscsi
target_ip_address = 20.1.0.32 (my target server)
volume_backend_name = lvmtnas
# volume group name created
volume_group = *vg_volume01 *
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
use_chap_auth = false

I did create the vg_volume01 on the LUN prior to the test.

I did a deploy, the container has been created, but nothing happened, it's
like I am missing something.

docker logs iscsid fome one the compute nodes
+ sudo -E kolla_set_configs
INFO:__main__:Loading config file at
/var/lib/kolla/config_files/config.json
INFO:__main__:Validating config file
INFO:__main__:Kolla config strategy set to: COPY_ALWAYS
INFO:__main__:Copying service configuration files
INFO:__main__:Writing out command to execute
++ cat /run_command
+ CMD='iscsid -d 8 -f'
+ ARGS=
+ sudo kolla_copy_cacerts
+ [[ ! -n '' ]]
+ . kolla_extend_start
++ [[ ! -f /etc/iscsi/initiatorname.iscsi ]]
+ echo 'Running command: '\''iscsid -d 8 -f'\'''
+ exec iscsid -d 8 -f
Running command: 'iscsid -d 8 -f'
iscsid: sysfs_init: sysfs_path='/sys'
iscsid: in ctldev_open
iscsid: created NETLINK_ISCSI socket...
iscsid: InitiatorName=iqn.1994-05.com.redhat:2a318909ad8
iscsid: InitiatorName=iqn.1994-05.com.redhat:2a318909ad8
iscsid: InitiatorAlias=computehci01
iscsid: Max file limits 1048576 1048576
iscsid: current time 258465
iscsid: nothing on pend_list, deactivating alarm


Any idea?

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230409/8092a9a4/attachment.htm>

From wodel.youchi at gmail.com  Sun Apr  9 10:47:41 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Sun, 9 Apr 2023 11:47:41 +0100
Subject: [Kolla-ansible][Yoga] Cannot live migrate VMs
Message-ID: <CAJV_UBDGYOJG8iuEbD3eELbvDHVyCmOv--w=oJ8h=iYF4vehXg@mail.gmail.com>

Hi,

I cannot live-migrate any VM I have.
All my compute nodes are enabled. I have a few VMs, I am in the testing
phase.
I tried to live-migrate toward an empty node, then toward a node which
already had a VM in it. It is the same problem.

In the log files I have :

Source node :
Source

> ==> /var/log/kolla/nova/nova-compute.log <==
> 2023-04-09 11:32:49.419 7 INFO nova.compute.resource_tracker
> [req-4e91d562-d7ad-4585-a827-3db6277fd81e - - - - -] [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Updating resource usage from
> migration f60eb077-8e1c-404a-aca5-64e5609ca02c
> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [-] [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Pre live migration failed at
> computehci02: oslo_messaging.rpc.client.RemoteError: Remote error:
> ClientException Gateway Time-out (HTTP 504)
> ['Traceback (most recent call last):\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py",
> line 165, in _process_incoming\n    res =
> self.dispatcher.dispatch(message)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
> line 309, in dispatch\n    return self._do_dispatch(endpoint, method, ctxt,
> args)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
> line 229, in _do_dispatch\n    result = func(ctxt, **new_args)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
> line 72, in wrapped\n    context, exc, binary)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 227, in __exit__\n    self.force_reraise()\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 200, in force_reraise\n    raise self.value\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
> line 63, in wrapped\n    return f(self, context, *args, **kw)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py",
> line 1439, in decorated_function\n    return function(self, context, *args,
> **kwargs)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> line 213, in decorated_function\n    kwargs[\'instance\'], e,
> sys.exc_info())\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 227, in __exit__\n    self.force_reraise()\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 200, in force_reraise\n    raise self.value\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> line 201, in decorated_function\n    return function(self, context, *args,
> **kwargs)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> line 8367, in pre_live_migration\n    bdm.save()\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 227, in __exit__\n    self.force_reraise()\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 200, in force_reraise\n    raise self.value\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> line 8304, in pre_live_migration\n    connector=connector,
> mountpoint=bdm.device_name)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> line 395, in wrapper\n    res = method(self, ctx, *args, **kwargs)\n', '
>  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> line 433, in wrapper\n    res = method(self, ctx, volume_id, *args,
> **kwargs)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> line 813, in attachment_create\n    instance_uuid=instance_id)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 227, in __exit__\n    self.force_reraise()\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 200, in force_reraise\n    raise self.value\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> line 801, in attachment_create\n    volume_id, _connector, instance_id)\n',
> '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py",
> line 421, in substitution\n    return method.func(obj, *args, **kwargs)\n',
> '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py",
> line 39, in create\n    retval = self._create(\'/attachments\', body,
> \'attachment\')\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py",
> line 306, in _create\n    resp, body = self.api.client.post(url,
> body=body)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
> line 227, in post\n    return self._cs_request(url, \'POST\', **kwargs)\n',
> '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
> line 215, in _cs_request\n    return self.request(url, method,
> **kwargs)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
> line 201, in request\n    raise exceptions.from_response(resp, body)\n',
> 'cinderclient.exceptions.ClientException: Gateway Time-out (HTTP 504)\n'].
> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Traceback (most recent call last):
> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> line 8501, in _do_pre_live_migration_from_source
> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     block_migration, disk, dest,
> migrate_data)
> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/rpcapi.py",
> line 948, in pre_live_migration
> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     **msg_args)
> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/client.py",
> line 192, in call
> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     retry=self.retry,
> transport_options=self.transport_options)
> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/transport.py",
> line 128, in _send
> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
> transport_options=transport_options)
> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py",
> line 691, in send
> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
> transport_options=transport_options)
> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py",
> line 681, in _send
> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     raise result
> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
> oslo_messaging.rpc.client.RemoteError: Remote error: ClientException
> Gateway Time-out (HTTP 504)
> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] ['Traceback (most recent call
> last):\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py",
> line 165, in _process_incoming\n    res =
> self.dispatcher.dispatch(message)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
> line 309, in dispatch\n    return self._do_dispatch(endpoint, method, ctxt,
> args)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
> line 229, in _do_dispatch\n    result = func(ctxt, **new_args)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
> line 72, in wrapped\n    context, exc, binary)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 227, in __exit__\n    self.force_reraise()\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 200, in force_reraise\n    raise self.value\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
> line 63, in wrapped\n    return f(self, context, *args, **kw)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py",
> line 1439, in decorated_function\n    return function(self, context, *args,
> **kwargs)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> line 213, in decorated_function\n    kwargs[\'instance\'], e,
> sys.exc_info())\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 227, in __exit__\n    self.force_reraise()\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 200, in force_reraise\n    raise self.value\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> line 201, in decorated_function\n    return function(self, context, *args,
> **kwargs)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> line 8367, in pre_live_migration\n    bdm.save()\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 227, in __exit__\n    self.force_reraise()\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 200, in force_reraise\n    raise self.value\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> line 8304, in pre_live_migration\n    connector=connector,
> mountpoint=bdm.device_name)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> line 395, in wrapper\n    res = method(self, ctx, *args, **kwargs)\n', '
>  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> line 433, in wrapper\n    res = method(self, ctx, volume_id, *args,
> **kwargs)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> line 813, in attachment_create\n    instance_uuid=instance_id)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 227, in __exit__\n    self.force_reraise()\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 200, in force_reraise\n    raise self.value\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> line 801, in attachment_create\n    volume_id, _connector, instance_id)\n',
> '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py",
> line 421, in substitution\n    return method.func(obj, *args, **kwargs)\n',
> '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py",
> line 39, in create\n    retval = self._create(\'/attachments\', body,
> \'attachment\')\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py",
> line 306, in _create\n    resp, body = self.api.client.post(url,
> body=body)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
> line 227, in post\n    return self._cs_request(url, \'POST\', **kwargs)\n',
> '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
> line 215, in _cs_request\n    return self.request(url, method,
> **kwargs)\n', '  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
> line 201, in request\n    raise exceptions.from_response(resp, body)\n',
> 'cinderclient.exceptions.ClientException: Gateway Time-out (HTTP 504)\n'].
> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
> 2023-04-09 11:33:30.157 7 INFO nova.compute.manager [-] [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Swapping old allocation on
> dict_keys(['2857ae62-3519-4b13-b700-858c827dd78d']) held by migration
> f60eb077-8e1c-404a-aca5-64e5609ca02c for instance



In the destination node :

> nova-compute.log
>
>
>
>
> *2023-04-09 11:32:30.052 7 WARNING os_brick.initiator.connectors.nvmeof
> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 - default default] Process execution error
> in _get_host_uuid: Unexpected error while running command.Command: blkid
> overlay -s UUID -o valueExit code: 2Stdout: ''Stderr: '':
> oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while
> running command.*
>
> 2023-04-09 11:33:05.354 7 INFO nova.compute.resource_tracker
> [req-9d480442-87f7-4d4e-a866-c46d645ac7f2 - - - - -] [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Updating resource usage from
> migration f60eb077-8e1c-404a-aca5-64e5609ca02c
> 2023-04-09 11:33:05.392 7 WARNING nova.compute.resource_tracker
> [req-9d480442-87f7-4d4e-a866-c46d645ac7f2 - - - - -] Instance
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7 has been moved to another host
> computehci01(computehci01). There are allocations remaining against the
> source host that might need to be removed: {'resources': {'VCPU': 1,
> 'MEMORY_MB': 2048}}.
> 2023-04-09 11:33:30.086 7 ERROR nova.volume.cinder
> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Create attachment failed for volume
> 3d7bd0af-5e4c-48fc-a027-f6c9dd6280bb. Error: Gateway Time-out (HTTP 504)
> Code: 504: cinderclient.exceptions.ClientException: Gateway Time-out (HTTP
> 504)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 - default default] Exception during
> message handling: cinderclient.exceptions.ClientException: Gateway Time-out
> (HTTP 504)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server Traceback (most
> recent call last):
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py",
> line 165, in _process_incoming
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     res =
> self.dispatcher.dispatch(message)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
> line 309, in dispatch
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
> self._do_dispatch(endpoint, method, ctxt, args)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
> line 229, in _do_dispatch
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     result =
> func(ctxt, **new_args)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
> line 72, in wrapped
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     context,
> exc, binary)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 227, in __exit__
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> self.force_reraise()
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 200, in force_reraise
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
> self.value
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
> line 63, in wrapped
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
> f(self, context, *args, **kw)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py",
> line 1439, in decorated_function
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
> function(self, context, *args, **kwargs)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> line 213, in decorated_function
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> kwargs['instance'], e, sys.exc_info())
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 227, in __exit__
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> self.force_reraise()
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 200, in force_reraise
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
> self.value
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> line 201, in decorated_function
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
> function(self, context, *args, **kwargs)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> line 8367, in pre_live_migration
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     bdm.save()
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 227, in __exit__
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> self.force_reraise()
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 200, in force_reraise
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
> self.value
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> line 8304, in pre_live_migration
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> connector=connector, mountpoint=bdm.device_name)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> line 395, in wrapper
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     res =
> method(self, ctx, *args, **kwargs)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> line 433, in wrapper
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     res =
> method(self, ctx, volume_id, *args, **kwargs)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> line 813, in attachment_create
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> instance_uuid=instance_id)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 227, in __exit__
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> self.force_reraise()
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 200, in force_reraise
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
> self.value
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> line 801, in attachment_create
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     volume_id,
> _connector, instance_id)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py",
> line 421, in substitution
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
> method.func(obj, *args, **kwargs)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py",
> line 39, in create
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     retval =
> self._create('/attachments', body, 'attachment')
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py",
> line 306, in _create
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     resp, body =
> self.api.client.post(url, body=body)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
> line 227, in post
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
> self._cs_request(url, 'POST', **kwargs)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
> line 215, in _cs_request
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
> self.request(url, method, **kwargs)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
> line 201, in request
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
> exceptions.from_response(resp, body)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> cinderclient.exceptions.ClientException: Gateway Time-out (HTTP 504)
> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> 2023-04-09 11:33:30.238 7 INFO nova.virt.block_device
> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Attempting to driver detach volume
> 3d7bd0af-5e4c-48fc-a027-f6c9dd6280bb from mountpoint /dev/vda
> 2023-04-09 11:33:30.239 7 WARNING nova.virt.block_device
> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Detaching volume from unknown instance
> 2023-04-09 11:33:30.240 7 WARNING nova.virt.libvirt.driver
> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] During detach_volume, instance
> disappeared.: nova.exception.InstanceNotFound: Instance
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7 could not be found.
> 2023-04-09 11:33:30.678 7 INFO nova.virt.libvirt.driver [-] [instance:
> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Instance destroyed successfully.
> 2023-04-09 11:33:30.682 7 INFO os_vif
> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 - default default] Successfully unplugged
> vif
> VIFBridge(active=True,address=fa:16:3e:9b:92:46,bridge_name='qbr46651303-65',has_traffic_filtering=True,id=46651303-65e1-4809-95cc-7c2d97acf16b,network=Network(532470c1-dd2f-4505-8557-ba24e9d4062b),plugin='ovs',port_profile=VIFPortProfileOpenVSwitch,preserve_on_delete=False,vif_name='tap46651303-65')
>

All I can see is




*b0f76b5c6dcb457fa716762bbf954837 - default default] Process execution
error in _get_host_uuid: Unexpected error while running command.Command:
blkid overlay -s UUID -o valueExit code: 2Stdout: ''Stderr: '':
oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while
running command.*

Searching the web I didn't find anything useful about this error, and I
don't know if it's the origin of the problem.

My default storage is ceph rbd, I have an HCI deployment, and all my VMs
are for now created on Ceph only. But I have configured two other cinder
backends, NFS and LVM, but they are node used for now.

Thanks in advance.

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230409/e0dad245/attachment-0001.htm>

From tkajinam at redhat.com  Mon Apr 10 02:26:03 2023
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Mon, 10 Apr 2023 11:26:03 +0900
Subject: [ironic][nova][neutron][oslo][sdk][swift][charm] netifaces has been
 archived
Message-ID: <CAL_crJQKP0rUoYRrk68_rHN9DnrXAtarPNPj3ju672w4NMag8Q@mail.gmail.com>

Hello,


I recently (actually, this morning) noticed the netifaces library[1] was
archived a while ago,
because the maintenor could no longer continue Open Source contributions,
unfortunately[2].

[1] https://github.com/al45tair/netifaces
[2] https://github.com/al45tair/netifaces/issues/78

I quickly searched the repositories and found some projects which have
netifaces
in their requirements.txt . We might need to look for alternatives (or
offer to maintain
the project, which is always the best) before we face any problems caused by
that unmaintained library.

Thank you,
Takashi Kajinami
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230410/2e5be0f3/attachment.htm>

From iurygregory at gmail.com  Mon Apr 10 02:41:19 2023
From: iurygregory at gmail.com (Iury Gregory)
Date: Mon, 10 Apr 2023 03:41:19 +0100
Subject: [ironic][nova][neutron][oslo][sdk][swift][charm] netifaces has
 been archived
In-Reply-To: <CAL_crJQKP0rUoYRrk68_rHN9DnrXAtarPNPj3ju672w4NMag8Q@mail.gmail.com>
References: <CAL_crJQKP0rUoYRrk68_rHN9DnrXAtarPNPj3ju672w4NMag8Q@mail.gmail.com>
Message-ID: <CAJqPaj8GViMnvHyapXVQ1H99KuJ7c6CfZ7_E65U=DLwBHX4Sew@mail.gmail.com>

Thanks for looking at it Takashi!

I will bring up this topic with the ironic community during the weekly
meeting (due to holidays we probably won't have a meeting on April 11, but
I will add to the agenda and try to discuss in the irc with contributors)

Em seg., 10 de abr. de 2023 ?s 03:28, Takashi Kajinami <tkajinam at redhat.com>
escreveu:

> Hello,
>
>
> I recently (actually, this morning) noticed the netifaces library[1] was
> archived a while ago,
> because the maintenor could no longer continue Open Source contributions,
> unfortunately[2].
>
> [1] https://github.com/al45tair/netifaces
> [2] https://github.com/al45tair/netifaces/issues/78
>
> I quickly searched the repositories and found some projects which have
> netifaces
> in their requirements.txt . We might need to look for alternatives (or
> offer to maintain
> the project, which is always the best) before we face any problems caused
> by
> that unmaintained library.
>
> Thank you,
> Takashi Kajinami
>


-- 
*Att[]'s*

*Iury Gregory Melo Ferreira *
*MSc in Computer Science at UFCG*
*Ironic PTL *
*Senior Software Engineer at Red Hat Brazil*
*Social*: https://www.linkedin.com/in/iurygregory
*E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230410/0275eabe/attachment.htm>

From tkajinam at redhat.com  Mon Apr 10 02:52:51 2023
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Mon, 10 Apr 2023 11:52:51 +0900
Subject: [ironic][nova][neutron][oslo][sdk][swift][charm] netifaces has
 been archived
In-Reply-To: <CAJqPaj8GViMnvHyapXVQ1H99KuJ7c6CfZ7_E65U=DLwBHX4Sew@mail.gmail.com>
References: <CAL_crJQKP0rUoYRrk68_rHN9DnrXAtarPNPj3ju672w4NMag8Q@mail.gmail.com>
 <CAJqPaj8GViMnvHyapXVQ1H99KuJ7c6CfZ7_E65U=DLwBHX4Sew@mail.gmail.com>
Message-ID: <CAL_crJRGcZFBSwir3D6P-gpusmocaNYTdM6QfZHyDhquQBVb3Q@mail.gmail.com>

On Mon, Apr 10, 2023 at 11:41?AM Iury Gregory <iurygregory at gmail.com> wrote:

> Thanks for looking at it Takashi!
>
> I will bring up this topic with the ironic community during the weekly
> meeting (due to holidays we probably won't have a meeting on April 11, but
> I will add to the agenda and try to discuss in the irc with contributors)
>

Thanks !
Just fyi, among all the ironic repos, ironic-python-agent is the only one
using the library.
It's good that the core ironic is not affected, though IIUC ipa is one of
the key components
for baremetal provisioning so we still need a plan to handle the situation.


>
> Em seg., 10 de abr. de 2023 ?s 03:28, Takashi Kajinami <
> tkajinam at redhat.com> escreveu:
>
>> Hello,
>>
>>
>> I recently (actually, this morning) noticed the netifaces library[1] was
>> archived a while ago,
>> because the maintenor could no longer continue Open Source contributions,
>> unfortunately[2].
>>
>> [1] https://github.com/al45tair/netifaces
>> [2] https://github.com/al45tair/netifaces/issues/78
>>
>> I quickly searched the repositories and found some projects which have
>> netifaces
>> in their requirements.txt . We might need to look for alternatives (or
>> offer to maintain
>> the project, which is always the best) before we face any problems caused
>> by
>> that unmaintained library.
>>
>> Thank you,
>> Takashi Kajinami
>>
>
>
> --
> *Att[]'s*
>
> *Iury Gregory Melo Ferreira *
> *MSc in Computer Science at UFCG*
> *Ironic PTL *
> *Senior Software Engineer at Red Hat Brazil*
> *Social*: https://www.linkedin.com/in/iurygregory
> *E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230410/8dd8d56c/attachment.htm>

From nguyenhuukhoinw at gmail.com  Mon Apr 10 05:32:58 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Mon, 10 Apr 2023 12:32:58 +0700
Subject: [kolla-ansible][yoga] how to configure cinder to connect to iscsi
 target?
In-Reply-To: <CAJV_UBB74c78b8r1iLMdk_sX9vrFFiE4VSyOqgt=4=x15qRnYA@mail.gmail.com>
References: <CAJV_UBB74c78b8r1iLMdk_sX9vrFFiE4VSyOqgt=4=x15qRnYA@mail.gmail.com>
Message-ID: <CABAODRePq2e7Fddt2atTxSCTv401bNp5YS-_1hUSq3NgZe_hLA@mail.gmail.com>

what is your controller status?
Nguyen Huu Khoi


On Sun, Apr 9, 2023 at 10:36?PM wodel youchi <wodel.youchi at gmail.com> wrote:

> Hi,
> I am trying to configure cinder to connect to an iscsi target. I am using
> targetcli as my target server.
>
> I have tested the connection from the node using iscsiadm and it works
> from the OS.
>
> Now I am trying to use the iscsid container to do the job.
>
> I added this to my globals.yml
> enable_iscsid: "yes"
> enable_cinder_backend_iscsi: "yes"
> enable_cinder_backend_lvm: "no"
>
> And I created the cinder.conf file like this
> [DEFAULT]
> enabled_backends = rbd1,nfs-1,*lvmtnas *
>
> # add follows to the end
> [lvmtnas]
> target_helper = lioadm
> target_protocol = iscsi
> target_ip_address = 20.1.0.32 (my target server)
> volume_backend_name = lvmtnas
> # volume group name created
> volume_group = *vg_volume01 *
> volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
> use_chap_auth = false
>
> I did create the vg_volume01 on the LUN prior to the test.
>
> I did a deploy, the container has been created, but nothing happened, it's
> like I am missing something.
>
> docker logs iscsid fome one the compute nodes
> + sudo -E kolla_set_configs
> INFO:__main__:Loading config file at
> /var/lib/kolla/config_files/config.json
> INFO:__main__:Validating config file
> INFO:__main__:Kolla config strategy set to: COPY_ALWAYS
> INFO:__main__:Copying service configuration files
> INFO:__main__:Writing out command to execute
> ++ cat /run_command
> + CMD='iscsid -d 8 -f'
> + ARGS=
> + sudo kolla_copy_cacerts
> + [[ ! -n '' ]]
> + . kolla_extend_start
> ++ [[ ! -f /etc/iscsi/initiatorname.iscsi ]]
> + echo 'Running command: '\''iscsid -d 8 -f'\'''
> + exec iscsid -d 8 -f
> Running command: 'iscsid -d 8 -f'
> iscsid: sysfs_init: sysfs_path='/sys'
> iscsid: in ctldev_open
> iscsid: created NETLINK_ISCSI socket...
> iscsid: InitiatorName=iqn.1994-05.com.redhat:2a318909ad8
> iscsid: InitiatorName=iqn.1994-05.com.redhat:2a318909ad8
> iscsid: InitiatorAlias=computehci01
> iscsid: Max file limits 1048576 1048576
> iscsid: current time 258465
> iscsid: nothing on pend_list, deactivating alarm
>
>
> Any idea?
>
> Regards.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230410/547d0ba6/attachment-0001.htm>

From knikolla at bu.edu  Mon Apr 10 12:18:00 2023
From: knikolla at bu.edu (Nikolla, Kristi)
Date: Mon, 10 Apr 2023 12:18:00 +0000
Subject: [tc] Technical Committee next weekly meeting on 2023 Apr 11 at 1800
 UTC
Message-ID: <D01595B0-7908-4879-B3BB-1A971C83621B@bu.edu>

Hi all,

This is a reminder that the next weekly Technical Committee meeting is to be held tomorrow (April 11) at 1800 UTC on #openstack-tc on OFTC IRC

Note: This is the first meeting with the new meeting time, please update your calendars accordingly moving forward.

Items can be proposed by editing the wiki page at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

At the end of today I will finalize the agenda and send out another email.

Thank you,
Kristi Nikolla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230410/2e9bbe92/attachment.htm>

From juliaashleykreger at gmail.com  Mon Apr 10 13:15:39 2023
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Mon, 10 Apr 2023 06:15:39 -0700
Subject: [ironic][nova][neutron][oslo][sdk][swift][charm] netifaces has
 been archived
In-Reply-To: <CAL_crJRGcZFBSwir3D6P-gpusmocaNYTdM6QfZHyDhquQBVb3Q@mail.gmail.com>
References: <CAL_crJQKP0rUoYRrk68_rHN9DnrXAtarPNPj3ju672w4NMag8Q@mail.gmail.com>
 <CAJqPaj8GViMnvHyapXVQ1H99KuJ7c6CfZ7_E65U=DLwBHX4Sew@mail.gmail.com>
 <CAL_crJRGcZFBSwir3D6P-gpusmocaNYTdM6QfZHyDhquQBVb3Q@mail.gmail.com>
Message-ID: <CAF7gwdiG2C9dEgtNo1Qfo1vodySEemUNPfvz0V9U4PKK0FfhvQ@mail.gmail.com>

For ironic specifically, I think this is a case where we should just
refactor the netutils.py to remove the netifaces use and backport as
needed. The usage is kind in the grand scheme of things.

-Julia

On Sun, Apr 9, 2023 at 7:57?PM Takashi Kajinami <tkajinam at redhat.com> wrote:

>
>
> On Mon, Apr 10, 2023 at 11:41?AM Iury Gregory <iurygregory at gmail.com>
> wrote:
>
>> Thanks for looking at it Takashi!
>>
>> I will bring up this topic with the ironic community during the weekly
>> meeting (due to holidays we probably won't have a meeting on April 11, but
>> I will add to the agenda and try to discuss in the irc with contributors)
>>
>
> Thanks !
> Just fyi, among all the ironic repos, ironic-python-agent is the only one
> using the library.
> It's good that the core ironic is not affected, though IIUC ipa is one of
> the key components
> for baremetal provisioning so we still need a plan to handle the situation.
>
>
>>
>> Em seg., 10 de abr. de 2023 ?s 03:28, Takashi Kajinami <
>> tkajinam at redhat.com> escreveu:
>>
>>> Hello,
>>>
>>>
>>> I recently (actually, this morning) noticed the netifaces library[1] was
>>> archived a while ago,
>>> because the maintenor could no longer continue Open Source
>>> contributions, unfortunately[2].
>>>
>>> [1] https://github.com/al45tair/netifaces
>>> [2] https://github.com/al45tair/netifaces/issues/78
>>>
>>> I quickly searched the repositories and found some projects which have
>>> netifaces
>>> in their requirements.txt . We might need to look for alternatives (or
>>> offer to maintain
>>> the project, which is always the best) before we face any problems
>>> caused by
>>> that unmaintained library.
>>>
>>> Thank you,
>>> Takashi Kajinami
>>>
>>
>>
>> --
>> *Att[]'s*
>>
>> *Iury Gregory Melo Ferreira *
>> *MSc in Computer Science at UFCG*
>> *Ironic PTL *
>> *Senior Software Engineer at Red Hat Brazil*
>> *Social*: https://www.linkedin.com/in/iurygregory
>> *E-mail:  iurygregory at gmail.com <iurygregory at gmail.com>*
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230410/7c4a94d1/attachment.htm>

From pdeore at redhat.com  Mon Apr 10 13:22:15 2023
From: pdeore at redhat.com (Pranali Deore)
Date: Mon, 10 Apr 2023 18:52:15 +0530
Subject: [Glance] Bobcat PTG summary
In-Reply-To: <40D3DB03-3D45-4C08-9B80-CE7F2D47F2F7@gmail.com>
References: <CALOt+SS5hstT+hRb7T3hSovCFFnB_P9WKsYF+_DwMC+56_9LEA@mail.gmail.com>
 <40D3DB03-3D45-4C08-9B80-CE7F2D47F2F7@gmail.com>
Message-ID: <CADkbuWgP2GbyNg5rCativbFYhuHRzd_Y4T_NgigQ=ApAMneh=w@mail.gmail.com>

On Wed, Apr 5, 2023 at 12:57?PM Artem Goncharov <artem.goncharov at gmail.com>
wrote:

> Hi,
>
> Feedback from SDK/OSC team on one item that got my attention
>
>
> # Bridge gap between Glance client and OSC
> Last cycle we have prepared the list of missing commands [2] and started
> submitting patches to implement the same. Our biggest hurdle at the moment
> is lack of reviews from the osc team (which has only one/two cores). Glance
> PTL is going to communicate with TC/existing core(s) of OSC whether they
> can add any glance core to the team so that we can prioritize our work and
> get reviews immediately. This cycle we are planning to complete this work.
>
>
> At the moment SDK/CLI core group is having 27 members, which should be
> already a sign. We have an agreement with all teams and add certain members
> into the core group to be able to review changes for their corresponding
> services (with a limitation that they are NOT by default setting W+1).
> You have noticed pretty correct - at the moment there is not so much
> activity on our side due to lack of reviewers. But that is not blocking any
> change once there is a +2 review from the service representatives. That
> means that if Glance team opens change and another Glance team member
> leaves +2 those changes are having absolutely different priority and we
> normally approving them fast (unless there is something preventing that).
> What we want to prevent is that every team is pulling project into their
> direction breaking certain rules or conventions.
>
> Please provide me the list of members you would like to get SDK/CLI core
> rights and I would gladly add them (one more time - no workflow+1)
>
> Artem
>
>
Hi Artem,

We have the discussion in the team and Abhishek & Cyril are ready to join
the SDK/CLI core group to speed up the reviews on glance related changes.
Please provide the SDK/CLI core rights to @Abhishek Kekane
<akekane at redhat.com> & @Cyril Roelandt <cyril at redhat.com>.


Thanks,
Pranali Deore
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230410/931f68e1/attachment-0001.htm>

From gmann at ghanshyammann.com  Mon Apr 10 16:09:37 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 10 Apr 2023 09:09:37 -0700
Subject: =?UTF-8?Q?Re:_=E7=AD=94=E5=A4=8D:_[ptl]_Need_PTL_vol?=
 =?UTF-8?Q?unteer_for_OpenStack_Sahara?=
In-Reply-To: <f477d35f70f04f448533e422dd5ca38b@inspur.com>
References: <1870a9accaa.ca4d3931996653.2888367201531485088@ghanshyammann.com>
 <5133a1c69a4e4d579514eccaa03dd8cd@inspur.com>
 <7d2aa6aaffb844e3b28517cdba3b7c54@inspur.com>
 <1cceee9b4afa459d9c64c1c106304b85@inspur.com>
 <f477d35f70f04f448533e422dd5ca38b@inspur.com>
Message-ID: <1876bee150d.ee4aa6ae296851.8453515049256805786@ghanshyammann.com>

Thanks Jerry, Brin for the updates and showing interest in Sahara project.

In PTG discussion, there were some concern on  Sahara maintenance even 
we had PTL volunteer to lead this project but not much things got merged and
gate was broken many times. But let me discuss it in TC meeting tomorrow and
update here.

-gmann

 ---- On Mon, 10 Apr 2023 00:22:08 -0700  Brin Zhang(???)  wrote --- 
 > Hi Gmann,
 > ????Jerry Zhou works the same company as qiujunting (Qiujunting has out of the office, so he cannot response us, I am so sorry), and he will be involved in Sahara.
 > ????Hope TC can add him in Sahara team, let him gradually complete the maintenance of the Sahara project.
 > ????Thanks.
 > 
 > brinzhang
 > 
 > -----????-----
 > ???: Jerry Zhou (???) zhouxinyong at inspur.com> 
 > ????: 2023?4?7? 11:10
 > ???: gmann at ghanshyammann.com; Juntingqiu Qiujunting (???) qiujunting at inspur.com>
 > ??: openstack-discuss at lists.openstack.org; Tom Guo(??2810) guotao.bj at inspur.com>; Brin Zhang(???) zhangbailin at inspur.com>; Weiting Kong (???) kongweiting at inspur.com>
 > ??: ??: [ptl] Need PTL volunteer for OpenStack Sahara
 > 
 > Hi Gmann,
 >   I can lead this project.
 > 
 > -----????-----
 > ???: Ghanshyam Mann gmann at ghanshyammann.com>
 > ????: 2023?3?23? 2:35
 > ???: Qiujunting qiujunting at inspur.com>; openstack-discuss openstack-discuss at lists.openstack.org>
 > ??: [ptl] Need PTL volunteer for OpenStack Sahara
 > 
 > Hi Qiu,
 > 
 > I am reaching out to you as you were PTL for OpenStack Sahara project in the last cycle.
 > 
 > There is no PTL candidate for the next cycle (2023.2), and it is on the leaderless project list. Please check if you or anyone you know would like to lead this project.
 > 
 > - https://etherpad.opendev.org/p/2023.2-leaderless
 > 
 > Also, if anyone else would like to help leading this project, this is time to let TC knows.
 > 
 > -gmann
 > 
 > 


From nfleishman at student.ccaeagles.org  Mon Apr 10 22:17:03 2023
From: nfleishman at student.ccaeagles.org (Trey Fleishman)
Date: Mon, 10 Apr 2023 18:17:03 -0400
Subject: StackOver Flow Error: 2103 ERROR oslo.messaging._drivers.impl_rabbit
 Connection failed: failed to resolve broker hostname
Message-ID: <CAF_4gkcPBznYiWd1o+HF8vYY3ObqtTTZ_McEvyyWJ+SHfrMNtg@mail.gmail.com>

Hello all,
Recently I tried installing Openstack via this
<https://docs.openstack.org/install-guide/openstack-services.html> guide.
Upon completion of all the steps including the dashboard step, I was
greeted with this error inside the nova_schedular.log file, after I tried
creating an instance.

2103 ERROR oslo.messaging._drivers.impl_rabbit Connection failed: failed to
resolve broker hostname: OSError: failed to resolve broker hostname

When I try to create an instance it hangs in the "scheduling" state and
throws this error. I have not configured anything in the "oslo.messaging"
section of the Nova config file. I believe that under the [default] section
this is what's causing the issue, but the password and hostname are fine.

transport_url =
rabbit://openstack:BnE9LLfCtjdPvpEnZUnPytSyrfUxE8th at controller

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230410/11d2c5b7/attachment.htm>

From knikolla at bu.edu  Mon Apr 10 22:32:56 2023
From: knikolla at bu.edu (Nikolla, Kristi)
Date: Mon, 10 Apr 2023 22:32:56 +0000
Subject: [tc] Technical Committee next weekly meeting on 2023 Apr 11 at
 1800 UTC
In-Reply-To: <D01595B0-7908-4879-B3BB-1A971C83621B@bu.edu>
References: <D01595B0-7908-4879-B3BB-1A971C83621B@bu.edu>
Message-ID: <F0E24B59-7AC4-4FF2-8D61-FCA4D2B5DE51@bu.edu>

Please find below the agenda for tomorrow's technical committee meeting (April 11 at 1800 UTC on #openstack-tc)

* Roll call
* Follow up on past action items
* Gate health check
* 2023.2 cycle Leaderless projects
** https://etherpad.opendev.org/p/2023.2-leaderless
* Recurring tasks check
** Bare 'recheck' state
*** https://etherpad.opendev.org/p/recheck-weekly-summary
* Open Reviews
** https://review.opendev.org/q/projects:openstack/governance+is:open

On Apr 10, 2023, at 8:18 AM, Nikolla, Kristi <knikolla at bu.edu> wrote:

Hi all,

This is a reminder that the next weekly Technical Committee meeting is to be held tomorrow (April 11) at 1800 UTC on #openstack-tc on OFTC IRC

Note: This is the first meeting with the new meeting time, please update your calendars accordingly moving forward.

Items can be proposed by editing the wiki page at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

At the end of today I will finalize the agenda and send out another email.

Thank you,
Kristi Nikolla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230410/d18f1ae2/attachment.htm>

From noonedeadpunk at gmail.com  Tue Apr 11 04:51:44 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Tue, 11 Apr 2023 06:51:44 +0200
Subject: StackOver Flow Error: 2103 ERROR
 oslo.messaging._drivers.impl_rabbit
 Connection failed: failed to resolve broker hostname
In-Reply-To: <CAF_4gkcPBznYiWd1o+HF8vYY3ObqtTTZ_McEvyyWJ+SHfrMNtg@mail.gmail.com>
References: <CAF_4gkcPBznYiWd1o+HF8vYY3ObqtTTZ_McEvyyWJ+SHfrMNtg@mail.gmail.com>
Message-ID: <CAPd_6As8FOZV2LEr2JhrU_HBdwGEQ8AW-=b29=8gGK2bEt1o7Q@mail.gmail.com>

Hi Trey,

Have you defined a record in your /etc/hosts for "controller", as according
to the error service simply can not resolve this hostname to an IP address.

Also I can suggest trying out one of the following OpenStack deployment
tools:
https://docs.openstack.org/zed/deploy/index.html

Most of them have All-In-One guides that can spawn an opestack sandbox to
play with.

??, 11 ???. 2023 ?., 00:21 Trey Fleishman <nfleishman at student.ccaeagles.org
>:

> Hello all,
> Recently I tried installing Openstack via this
> <https://docs.openstack.org/install-guide/openstack-services.html> guide.
> Upon completion of all the steps including the dashboard step, I was
> greeted with this error inside the nova_schedular.log file, after I tried
> creating an instance.
>
> 2103 ERROR oslo.messaging._drivers.impl_rabbit Connection failed: failed
> to resolve broker hostname: OSError: failed to resolve broker hostname
>
> When I try to create an instance it hangs in the "scheduling" state and
> throws this error. I have not configured anything in the "oslo.messaging"
> section of the Nova config file. I believe that under the [default] section
> this is what's causing the issue, but the password and hostname are fine.
>
> transport_url =
> rabbit://openstack:BnE9LLfCtjdPvpEnZUnPytSyrfUxE8th at controller
>
> Thanks!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/1fd6fd4c/attachment-0001.htm>

From skaplons at redhat.com  Tue Apr 11 07:52:42 2023
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Tue, 11 Apr 2023 09:52:42 +0200
Subject: [ironic][nova][neutron][oslo][sdk][swift][charm] netifaces has
 been archived
In-Reply-To: <CAL_crJQKP0rUoYRrk68_rHN9DnrXAtarPNPj3ju672w4NMag8Q@mail.gmail.com>
References: <CAL_crJQKP0rUoYRrk68_rHN9DnrXAtarPNPj3ju672w4NMag8Q@mail.gmail.com>
Message-ID: <4331878.7UeB5E0nlk@p1>

Hi,

Dnia poniedzia?ek, 10 kwietnia 2023 04:26:03 CEST Takashi Kajinami pisze:
> Hello,
> 
> 
> I recently (actually, this morning) noticed the netifaces library[1] was
> archived a while ago,
> because the maintenor could no longer continue Open Source contributions,
> unfortunately[2].
> 
> [1] https://github.com/al45tair/netifaces
> [2] https://github.com/al45tair/netifaces/issues/78
> 
> I quickly searched the repositories and found some projects which have
> netifaces
> in their requirements.txt . We might need to look for alternatives (or
> offer to maintain
> the project, which is always the best) before we face any problems caused by
> that unmaintained library.
> 
> Thank you,
> Takashi Kajinami
> 

Thx Takashi. I just opened LP https://bugs.launchpad.net/neutron/+bug/2015844 for Neutron. We are using it only in windows ip_lib module so it's not really critical thing for us but indeed would be great to remove that dependency from Neutron.

-- 
Slawek Kaplonski
Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/15bdb3ad/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: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/15bdb3ad/attachment.sig>

From tkajinam at redhat.com  Tue Apr 11 08:49:44 2023
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Tue, 11 Apr 2023 17:49:44 +0900
Subject: [ptl] Need PTL volunteer for OpenStack Winstackers
In-Reply-To: <1873468752c.bf93124c180931.3029567703559224707@ghanshyammann.com>
References: <1870a6b7a1d.114e70a2d994244.3514791188773000084@ghanshyammann.com>
 <A8A3517C-9022-4D13-9784-B3CB41B422DA@cloudbasesolutions.com>
 <1873468752c.bf93124c180931.3029567703559224707@ghanshyammann.com>
Message-ID: <CAL_crJQn0h0w4zyCV_HLZrYQ4YwsKwVzcbtGAxzdN8REx06g+w@mail.gmail.com>

This probably causes a bit wider effect than just retiring the winstackers
project.

I see some projects (cinde, designate, glance and os-brick) depend on
os-win which is under
governance of winstackers and will be retired. Also, even some more
projects (Neutron, os-vif,
ovsdbapp, oslo.log, etc) supports windows without os-win.

If we retire Winstackers, then is it reasonable to remove all
implementations to support Windows ?



On Fri, Mar 31, 2023 at 6:29?AM Ghanshyam Mann <gmann at ghanshyammann.com>
wrote:

> Thanks, Lucian, for the updates and email link.
>
> As the next step, we will discuss it in TC and take the next action.
>
> -gmann
>
>  ---- On Thu, 30 Mar 2023 00:11:38 -0700  Lucian Petrut  wrote ---
>  > Hi,
>  > Thanks for reaching out. As mentioned here [1], Cloudbase Solutions can
> no longer lead the Winstackers project. Since there weren?t any other
> interested parties, I think there?s no other option but to retire the
> project.
>  > [1]
> https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html
>  > Regards,Lucian Petrut
>  >
>  > On 22 Mar 2023, at 19:43, Ghanshyam Mann gmann at ghanshyammann.com>
> wrote:
>  > Hi Lukas,
>  >
>  > I am reaching out to you as you were PTL for OpenStack Winstackers
> project in the last cycle.
>  >
>  > There is no PTL candidate for the next cycle (2023.2), and it is on the
> leaderless project list. Please
>  > check if you or anyone you know would like to lead this project.
>  >
>  > - https://etherpad.opendev.org/p/2023.2-leaderless
>  >
>  > Also, if anyone else would like to help leading this project, this is
> time to let TC knows.
>  >
>  > -gmann
>  >
>  >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/0eb2629d/attachment.htm>

From skaplons at redhat.com  Tue Apr 11 09:01:38 2023
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Tue, 11 Apr 2023 11:01:38 +0200
Subject: [ptl] Need PTL volunteer for OpenStack Winstackers
In-Reply-To: <CAL_crJQn0h0w4zyCV_HLZrYQ4YwsKwVzcbtGAxzdN8REx06g+w@mail.gmail.com>
References: <1870a6b7a1d.114e70a2d994244.3514791188773000084@ghanshyammann.com>
 <1873468752c.bf93124c180931.3029567703559224707@ghanshyammann.com>
 <CAL_crJQn0h0w4zyCV_HLZrYQ4YwsKwVzcbtGAxzdN8REx06g+w@mail.gmail.com>
Message-ID: <2832840.mvXUDI8C0e@p1>

Hi,

Dnia wtorek, 11 kwietnia 2023 10:49:44 CEST Takashi Kajinami pisze:
> This probably causes a bit wider effect than just retiring the winstackers
> project.
> 
> I see some projects (cinde, designate, glance and os-brick) depend on
> os-win which is under
> governance of winstackers and will be retired. Also, even some more
> projects (Neutron, os-vif,
> ovsdbapp, oslo.log, etc) supports windows without os-win.
> 
> If we retire Winstackers, then is it reasonable to remove all
> implementations to support Windows ?

That's very good question IMO. And, from Neutron perspective very important according to the removal of netifaces dependency - it would be much easier to remove it by removing all "windows" module from Neutron repo rather than refactoring it.

> 
> 
> 
> On Fri, Mar 31, 2023 at 6:29?AM Ghanshyam Mann <gmann at ghanshyammann.com>
> wrote:
> 
> > Thanks, Lucian, for the updates and email link.
> >
> > As the next step, we will discuss it in TC and take the next action.
> >
> > -gmann
> >
> >  ---- On Thu, 30 Mar 2023 00:11:38 -0700  Lucian Petrut  wrote ---
> >  > Hi,
> >  > Thanks for reaching out. As mentioned here [1], Cloudbase Solutions can
> > no longer lead the Winstackers project. Since there weren?t any other
> > interested parties, I think there?s no other option but to retire the
> > project.
> >  > [1]
> > https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html
> >  > Regards,Lucian Petrut
> >  >
> >  > On 22 Mar 2023, at 19:43, Ghanshyam Mann gmann at ghanshyammann.com>
> > wrote:
> >  > Hi Lukas,
> >  >
> >  > I am reaching out to you as you were PTL for OpenStack Winstackers
> > project in the last cycle.
> >  >
> >  > There is no PTL candidate for the next cycle (2023.2), and it is on the
> > leaderless project list. Please
> >  > check if you or anyone you know would like to lead this project.
> >  >
> >  > - https://etherpad.opendev.org/p/2023.2-leaderless
> >  >
> >  > Also, if anyone else would like to help leading this project, this is
> > time to let TC knows.
> >  >
> >  > -gmann
> >  >
> >  >
> >
> >
> 


-- 
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: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/e9d5e410/attachment.sig>

From eblock at nde.ag  Tue Apr 11 09:16:38 2023
From: eblock at nde.ag (Eugen Block)
Date: Tue, 11 Apr 2023 09:16:38 +0000
Subject: [neutron] [kolla-ansible] alembic mismatch, schema differences
In-Reply-To: <d7cae712-bf0c-9144-38cb-ad8fe61f6d54@pawsey.org.au>
Message-ID: <20230411091638.Horde.18FVI49lop_QXhPAphY0Z47@webmail.nde.ag>

Hi,

I don't really have more input than what I reported in the mentioned  
thread. I'm also not familiar with kolla-ansible, unfortunately. But I  
would check for files with the non-existing revision number on the  
control node(s)? Something like this depending on your distro could  
reveal something:

# find  
/usr/lib/python3/dist-packages/neutron/db/migration/alembic_migrations/versions/ -name  
*6135a7bd4425*

If there are files that don't belong there remove them and retry the  
neutron-db-manage commands with the correct revisions in the table.  
But if you're using containers I'd be curious how those files would  
get there... Does a release change in the globals.yaml also redeploy  
control containers? But on the other hand, you seem to have deployed  
only a compute node with wallaby? I hope someone with kolla-ansible  
experience can chime in here.

Sorry if I can't be more helpful...

Eugen

Zitat von Gregory Orange <gregory.orange at pawsey.org.au>:

> Hi all,
>
> We've caused ourselves some bother with our neutron database, and I  
> found the following thread instructive, so I hope we can get some  
> help to resolve the bother.
> https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031312.html
>
> We're running kolla-ansible train (yes, upgrades planned). We wanted  
> to test something with a wallaby container, and while mainly just  
> pulling train versions of containers on a single compute node, we  
> also changed openstack_release variable to wallaby in globals.yml -  
> this was the mistake.
>
> Later that day, we ran kolla-ansible deploy --limit $HOST for a new  
> compute node. We stopped at the following error, realising the above  
> mistake.
> ---
> 2023-04-05 12:25:50.487 7 ERROR nova  
> nova.exception.TooOldComputeService: Current Nova version does not  
> support computes older than Victoria but the minimum compute service  
> level in your cell is 40 and the oldest supported service level is 52.
> 2023-04-05 12:25:50.487 7 ERROR nova
> ---
>
> Now when we deploy a node it gets to task "Running Neutron bootstrap  
> container" and gives error:
> ----
> "alembic.script.revision.ResolutionError: No such revision or branch  
> '6135a7bd4425'"
> ----
>
> Using insight from the above list thread, I fetched DB entries:
> MariaDB [neutron]> select * from alembic_version;
> +--------------+
> | version_num  |
> +--------------+
> | 5c85685d616d |
> | 6135a7bd4425 |
> +--------------+
>
> Running the same from the test cluster which was deployed in the same way:
> MariaDB [neutron]> select * from alembic_version;
> +--------------+
> | version_num  |
> +--------------+
> | 5c85685d616d |
> | c613d0b82681 |
> +--------------+
>
> Also, comparing `neutron-db-manage history --verbose` across the two  
> clusters, output is the same in both test and prod, except for the  
> order of 2 lines:
> ----
> -Branches into: 56893333aa52, 30018084ed99
> -Branches into: c40fbb377ad, 67c8e8d61d5
> +Branches into: 30018084ed99, 56893333aa52
> +Branches into: 67c8e8d61d5, c40fbb377ad
> ----
>
> Finally, I looked at the schema of the neutron database across the  
> two. There are significant differences.
> for i in `mysql neutron -bNe "show tables;"`; do echo "TABLE: $i";  
> mysql neutron -e "desc $i;"; done > prod-neutron-descs
> Repeat for test.
> $ cat prod-neutron-descs | nc termbin.com 9999
> https://termbin.com/8ppi
> $ cat test-neutron-descs | nc termbin.com 9999
> https://termbin.com/cfqz
>
> Our cluster and Neutron in particular is operating fine, but we  
> can't deploy new nodes to it.
>
> May I have some help on how to resolve this?
>
> Thank you,
> Greg.





From eblock at nde.ag  Tue Apr 11 09:49:55 2023
From: eblock at nde.ag (Eugen Block)
Date: Tue, 11 Apr 2023 09:49:55 +0000
Subject: [openstackclient] openstack cli broken after update to Wallaby
In-Reply-To: <bee8d618-ec90-478c-9ae9-b4c146137189@app.fastmail.com>
References: <20230404143428.Horde.MIPd5a2pT3yB3Ki3PoJBmOt@webmail.nde.ag>
 <bee8d618-ec90-478c-9ae9-b4c146137189@app.fastmail.com>
Message-ID: <20230411094955.Horde.U7eCCfFaFrgiGd0xAmXkZ3U@webmail.nde.ag>

Hi Clark,

you were on the right track with the DISPLAY variable. I had some  
other stuff on the plate and today I started a new approach. Long  
story short, I have an alias for ssh in my bash profile (our admin set  
that up years ago) which hasn't bit me until now:

alias ssh='ssh -X'

This seems to work fine on Leap 15.2 and Victoria, though, but I'll  
just need to make sure not to use the alias on Ubuntu, I guess. Maybe  
I'll remove the alias entirely.

Thanks!
Eugen

Zitat von Clark Boylan <cboylan at sapwetik.org>:

> On Tue, Apr 4, 2023, at 7:34 AM, Eugen Block wrote:
>> Hi *,
>>
>> today I upgraded my virtual test environment from V to W when (Ubuntu
>> 20.04) all of a sudden cli commands didn't work anymore with this
>> stack trace:
>>
>> ---snip---
>> root at control01:~# openstack network agent list
>> Traceback (most recent call last):
>>    File "/usr/bin/openstack", line 6, in <module>
>>      from openstackclient.shell import main
>>    File "/usr/lib/python3/dist-packages/openstackclient/shell.py",
>> line 23, in <module>
>>      from osc_lib import shell
>>    File "/usr/lib/python3/dist-packages/osc_lib/shell.py", line 24,  
>> in <module>
>>      from cliff import app
>>    File "/usr/lib/python3/dist-packages/cliff/app.py", line 22, in <module>
>>      import cmd2
>>    File "/usr/lib/python3/dist-packages/cmd2.py", line 585, in <module>
>>      _ = pyperclip.paste()
>>    File "/usr/lib/python3/dist-packages/pyperclip/__init__.py", line
>> 667, in lazy_load_stub_paste
>>      copy, paste = determine_clipboard()
>>    File "/usr/lib/python3/dist-packages/pyperclip/__init__.py", line
>> 558, in determine_clipboard
>>      return init_gi_clipboard()
>>    File "/usr/lib/python3/dist-packages/pyperclip/__init__.py", line
>> 167, in init_gi_clipboard
>>      gi.require_version('Gtk', '3.0')
>>    File "/usr/lib/python3/dist-packages/gi/__init__.py", line 129, in
>> require_version
>>      raise ValueError('Namespace %s not available' % namespace)
>> ValueError: Namespace Gtk not available
>> ---snip---
>>
>> I found this bug [1] describing the same issue but there has been no
>> progress. I posted my comments there as well. I found one way to get
>> the openstack shell to work by installing libgtk-3-dev (I found a hint
>> in a search engine). Apparently, python3-cmd2 requires
>> python3-pyperclip which requires python3-gi and so on. Is this really
>> the desired way? I didn't notice anything in the release notes (maybe
>> I missed it). When comparing to a different environment (Victoria on
>> baremetal) I see that libgtk-3 is installed there (not -dev though),
>> but even with libgtk-3-0 the error message was still present. So the
>> question is, which dependencies are missing where? It's not really
>> obvious to me. Could this already be fixed in Xena? If it is fixed
>> there I could do the double upgrade, of course, especially since
>> Wallaby is already under extended maintenance. Any comments are
>> appreciated.
>
> I know you've marked this invalid elsewhere, but I think there is an  
> interesting problem somewhere here. In particular I've cloned  
> https://github.com/asweigart/pyperclip which backs the pyperclip  
> pypi package https://pypi.org/project/pyperclip/. Reading  
> determine_clipboard() it seems to do all this extra work (on Linux  
> anyway) if DISPLAY is set. One easy workaround may be to unset that  
> env var in your terminals when running openstackclient.
>
> That said looking more closely init_gi_clipboard() isn't in the  
> current code base. Looking at the history of the project:
> `git log -p | grep init_gi_clipboard` produces no results either.  
> This makes me wonder where that is coming from and what  
> version/source of pyperclip you are using. If I grab pyperclip 1.8.2  
> (which is the upper constraints version for wallaby and xena) from  
> pypi this function doesn't appear to exist there either. It is  
> possible they rewrote their git history at some point, but best I  
> can tell your version of pyperclip doesn't share code or history  
> with the version on pypi specified in upper constraints for wallaby  
> and xena.
>
> Also it looks like if you install xsel or xclip that pyperclip will  
> prefer those tools over the gtk bindings.
>
>>
>> Thanks,
>> Eugen
>>
>> [1]
>> https://bugs.launchpad.net/ubuntu/+source/python-openstackclient/+bug/1945661





From Danny.Webb at thehutgroup.com  Tue Apr 11 11:17:57 2023
From: Danny.Webb at thehutgroup.com (Danny Webb)
Date: Tue, 11 Apr 2023 11:17:57 +0000
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CAPgF-fqwuGRa3Mf6euhW=kUSGNhNURTqguG6=fi=_2hiTqO0sQ@mail.gmail.com>
References: <CABAODRdLhuX77ny=exdhe6rpxfOKFXfn5WOFD0yL8oHK6ZXv4g@mail.gmail.com>
 <CAPgF-fqwuGRa3Mf6euhW=kUSGNhNURTqguG6=fi=_2hiTqO0sQ@mail.gmail.com>
Message-ID: <LO2P265MB5773607CCA9FDB60EC9037C39A9A9@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>

This commit explains why they largely removed HA queue durability:

https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90a9a912588af0a180
________________________________
From: Satish Patel <satish.txt at gmail.com>
Sent: 09 April 2023 04:16
To: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org>
Subject: Re: [openstack][sharing][kolla ansible]Problems when 1 of 3 controller was be down


CAUTION: This email originates from outside THG

________________________________
Are you proposing a solution or just raising an issue?

I did find it strange that kolla-ansible doesn't support HA queue by default. That is a disaster because when one of the nodes goes down it will make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have to add HA policy to make queue HA otherwise you will endup in problem.

On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com<mailto:nguyenhuukhoinw at gmail.com>> wrote:
Hello everyone.

I want to summary for who meets problems with Openstack when deploy cluster with 3 controller using Kolla Ansible

Scenario: 1 of 3 controller is down

1. Login horizon and use API such as nova, cinder will be very slow

fix by:

nano:
kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2

or which service need caches

add as below

[cache]
backend = oslo_cache.memcache_pool
enabled = True
memcache_servers = {{ kolla_internal_vip_address }}:{{ memcached_port }}
memcache_dead_retry = 0.25
memcache_socket_timeout = 900

https://review.opendev.org/c/openstack/kolla-ansible/+/849487<https://review.opendev.org/c/openstack/kolla-ansible/+/849487>

but it is not the end

2. Cannot launch instance or mapping block device(stuck at this step)

nano kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2

"policies":[
    {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
    {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all", "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"}, "priority":0}
    {% endif %}
  ]

nano /etc/kollla/global.conf

[oslo_messaging_rabbit]
kombu_reconnect_delay=0.5


https://bugs.launchpad.net/oslo.messaging/+bug/1993149<https://bugs.launchpad.net/oslo.messaging/+bug/1993149>
https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html<https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html>

I used Xena 13.4 and Yoga 14.8.1.

Above bugs are critical, but I see that it was not fixed. I am just an operator and I want to share what I encountered for new people who come to Openstack


Nguyen Huu Khoi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/03813a16/attachment-0001.htm>

From nguyenhuukhoinw at gmail.com  Tue Apr 11 11:27:19 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Tue, 11 Apr 2023 18:27:19 +0700
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <LO2P265MB5773607CCA9FDB60EC9037C39A9A9@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
References: <CABAODRdLhuX77ny=exdhe6rpxfOKFXfn5WOFD0yL8oHK6ZXv4g@mail.gmail.com>
 <CAPgF-fqwuGRa3Mf6euhW=kUSGNhNURTqguG6=fi=_2hiTqO0sQ@mail.gmail.com>
 <LO2P265MB5773607CCA9FDB60EC9037C39A9A9@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <CABAODRfjqYP4QY9KROd03SQjm+XFQ0C7xMApaahVJ2N8T6=+zQ@mail.gmail.com>

Yes.
But cluster cannot work properly without it. :(

On Tue, Apr 11, 2023, 6:18 PM Danny Webb <Danny.Webb at thehutgroup.com> wrote:

> This commit explains why they largely removed HA queue durability:
>
>
> https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90a9a912588af0a180
> ------------------------------
> *From:* Satish Patel <satish.txt at gmail.com>
> *Sent:* 09 April 2023 04:16
> *To:* Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> *Cc:* OpenStack Discuss <openstack-discuss at lists.openstack.org>
> *Subject:* Re: [openstack][sharing][kolla ansible]Problems when 1 of 3
> controller was be down
>
>
> * CAUTION: This email originates from outside THG *
> ------------------------------
> Are you proposing a solution or just raising an issue?
>
> I did find it strange that kolla-ansible doesn't support HA queue by
> default. That is a disaster because when one of the nodes goes down it will
> make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have to add
> HA policy to make queue HA otherwise you will endup in problem.
>
> On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> wrote:
>
> Hello everyone.
>
> I want to summary for who meets problems with Openstack when deploy
> cluster with 3 controller using Kolla Ansible
>
> Scenario: 1 of 3 controller is down
>
> 1. Login horizon and use API such as nova, cinder will be very slow
>
> fix by:
>
> nano:
> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
>
> or which service need caches
>
> add as below
>
> [cache]
> backend = oslo_cache.memcache_pool
> enabled = True
> memcache_servers = {{ kolla_internal_vip_address }}:{{ memcached_port }}
> memcache_dead_retry = 0.25
> memcache_socket_timeout = 900
>
> https://review.opendev.org/c/openstack/kolla-ansible/+/849487
>
> but it is not the end
>
> 2. Cannot launch instance or mapping block device(stuck at this step)
>
> nano kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
>
> "policies":[
>     {"vhost": "/", "name": "ha-all", "pattern":
> "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition":
> {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
>     {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all",
> "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"},
> "priority":0}
>     {% endif %}
>   ]
>
> nano /etc/kollla/global.conf
>
> [oslo_messaging_rabbit]
> kombu_reconnect_delay=0.5
>
>
> https://bugs.launchpad.net/oslo.messaging/+bug/1993149
> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
>
> I used Xena 13.4 and Yoga 14.8.1.
>
> Above bugs are critical, but I see that it was not fixed. I am just an
> operator and I want to share what I encountered for new people who come to
> Openstack
>
>
> Nguyen Huu Khoi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/720b7a0e/attachment.htm>

From bence.romsics at gmail.com  Tue Apr 11 11:43:33 2023
From: bence.romsics at gmail.com (Bence Romsics)
Date: Tue, 11 Apr 2023 13:43:33 +0200
Subject: [neutron] bug deputy report for week of 2023-04-03
Message-ID: <CAHeS+3-aez57hyDnVX+vtQ4KEzKg5QCq5PiDH=2fMzgkShr_Qw@mail.gmail.com>

Hi All,

We had the following new bugs reported last week:

Critical:
* https://bugs.launchpad.net/neutron/+bug/2015065
[tempest] "test_security_group_rules_create" unstable in
"neutron-ovs-grenade-dvr-multinode"
unassigned

High:
* https://bugs.launchpad.net/neutron/+bug/2015364
[skip-level] OVN tests constantly failing
unassigned
* https://bugs.launchpad.net/neutron/+bug/2015376
[OVN] min-BW rule, defined in the LSP.options field, must be
accompanied with a max-BW value
unassigned
* https://bugs.launchpad.net/neutron/+bug/2015728
ovs/ovn source(with master branch) deployments broken
workarounds proposed/merged by Yatin:
https://review.opendev.org/c/openstack/neutron/+/879938
https://review.opendev.org/c/openstack/ovn-octavia-provider/+/879939
* https://bugs.launchpad.net/neutron/+bug/2015090
neutron.agent.dhcp.agent TypeError: 'bool' object is not subscriptable
Technically unassigned, but I believe Sahid may be working on it.

Medium:
* https://bugs.launchpad.net/neutron/+bug/2015388
Deleting network does not remove network namespace
fix proposed by Brian: https://review.opendev.org/c/openstack/neutron/+/880006
* https://bugs.launchpad.net/neutron/+bug/2015377
[ovn] If dhcp port is deleted from neutron, it is never recreated
fix proposed by Brian: https://review.opendev.org/c/openstack/neutron/+/879913

RFE:
* https://bugs.launchpad.net/neutron/+bug/2015471
[RFE] Add ERSPAN for tap-as-a-service with OVS and OVN

Triage still in progress:
* https://bugs.launchpad.net/neutron/+bug/2015449
Remote security groups don't allow traffic from floating IPs
This issue may be undocumented behavior, the following question could
be discussed on the weekly meeting:
https://meetings.opendev.org/irclogs/%23openstack-neutron/%23openstack-neutron.2023-04-06.log.html#t2023-04-06T12:40:39
* https://bugs.launchpad.net/neutron/+bug/2015275
Trunk port update_subport_bindings RPC call not processed by RPC workers

Cheers,
Bence (rubasov)


From wodel.youchi at gmail.com  Tue Apr 11 12:15:00 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Tue, 11 Apr 2023 13:15:00 +0100
Subject: [kolla-ansible][yoga] how to configure cinder to connect to iscsi
 target?
In-Reply-To: <CABAODRePq2e7Fddt2atTxSCTv401bNp5YS-_1hUSq3NgZe_hLA@mail.gmail.com>
References: <CAJV_UBB74c78b8r1iLMdk_sX9vrFFiE4VSyOqgt=4=x15qRnYA@mail.gmail.com>
 <CABAODRePq2e7Fddt2atTxSCTv401bNp5YS-_1hUSq3NgZe_hLA@mail.gmail.com>
Message-ID: <CAJV_UBDrXxBMskVzQwPJtoCQAy5VU91e9KYcwXWchf2e8rM51w@mail.gmail.com>

Hi,

What do you mean by controller status?

After some digging I found that, when using
cinder.volume.drivers.lvm.LVMVolumeDriver, it seems that cinder searches
for the VG, and the VG must exist.
Seeing some examples like this [1], it's like the configuration is made to
expose a local disk as an iscsi LUN.

The VG was created on a local disk, then it was exposed as LUN. So just to
be sure, is cinder.volume.drivers.lvm.LVMVolumeDriver with target_protocol
= iscsi, intended to expose a local VG on compute nodes as iscsi LUNs?

My other question is : Can I configure cinder with  Tagetcli as external
iscsi storage?


[1] :
https://www.server-world.info/en/note?os=CentOS_Stream_8&p=openstack_yoga2&f=12

Regards.

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Mon, Apr 10, 2023, 06:33 Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> what is your controller status?
> Nguyen Huu Khoi
>
>
> On Sun, Apr 9, 2023 at 10:36?PM wodel youchi <wodel.youchi at gmail.com>
> wrote:
>
>> Hi,
>> I am trying to configure cinder to connect to an iscsi target. I am using
>> targetcli as my target server.
>>
>> I have tested the connection from the node using iscsiadm and it works
>> from the OS.
>>
>> Now I am trying to use the iscsid container to do the job.
>>
>> I added this to my globals.yml
>> enable_iscsid: "yes"
>> enable_cinder_backend_iscsi: "yes"
>> enable_cinder_backend_lvm: "no"
>>
>> And I created the cinder.conf file like this
>> [DEFAULT]
>> enabled_backends = rbd1,nfs-1,*lvmtnas *
>>
>> # add follows to the end
>> [lvmtnas]
>> target_helper = lioadm
>> target_protocol = iscsi
>> target_ip_address = 20.1.0.32 (my target server)
>> volume_backend_name = lvmtnas
>> # volume group name created
>> volume_group = *vg_volume01 *
>> volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
>> use_chap_auth = false
>>
>> I did create the vg_volume01 on the LUN prior to the test.
>>
>> I did a deploy, the container has been created, but nothing happened,
>> it's like I am missing something.
>>
>> docker logs iscsid fome one the compute nodes
>> + sudo -E kolla_set_configs
>> INFO:__main__:Loading config file at
>> /var/lib/kolla/config_files/config.json
>> INFO:__main__:Validating config file
>> INFO:__main__:Kolla config strategy set to: COPY_ALWAYS
>> INFO:__main__:Copying service configuration files
>> INFO:__main__:Writing out command to execute
>> ++ cat /run_command
>> + CMD='iscsid -d 8 -f'
>> + ARGS=
>> + sudo kolla_copy_cacerts
>> + [[ ! -n '' ]]
>> + . kolla_extend_start
>> ++ [[ ! -f /etc/iscsi/initiatorname.iscsi ]]
>> + echo 'Running command: '\''iscsid -d 8 -f'\'''
>> + exec iscsid -d 8 -f
>> Running command: 'iscsid -d 8 -f'
>> iscsid: sysfs_init: sysfs_path='/sys'
>> iscsid: in ctldev_open
>> iscsid: created NETLINK_ISCSI socket...
>> iscsid: InitiatorName=iqn.1994-05.com.redhat:2a318909ad8
>> iscsid: InitiatorName=iqn.1994-05.com.redhat:2a318909ad8
>> iscsid: InitiatorAlias=computehci01
>> iscsid: Max file limits 1048576 1048576
>> iscsid: current time 258465
>> iscsid: nothing on pend_list, deactivating alarm
>>
>>
>> Any idea?
>>
>> Regards.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/44f4f7f3/attachment.htm>

From mnasiadka at gmail.com  Tue Apr 11 12:42:04 2023
From: mnasiadka at gmail.com (=?UTF-8?Q?Micha=C5=82_Nasiadka?=)
Date: Tue, 11 Apr 2023 14:42:04 +0200
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CABAODRfjqYP4QY9KROd03SQjm+XFQ0C7xMApaahVJ2N8T6=+zQ@mail.gmail.com>
References: <CABAODRdLhuX77ny=exdhe6rpxfOKFXfn5WOFD0yL8oHK6ZXv4g@mail.gmail.com>
 <CAPgF-fqwuGRa3Mf6euhW=kUSGNhNURTqguG6=fi=_2hiTqO0sQ@mail.gmail.com>
 <LO2P265MB5773607CCA9FDB60EC9037C39A9A9@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <CABAODRfjqYP4QY9KROd03SQjm+XFQ0C7xMApaahVJ2N8T6=+zQ@mail.gmail.com>
Message-ID: <CANhpHj-5iOtHaGZHMgEOz1C_P9BW8AOw0RGV8zYgCUuphST=eg@mail.gmail.com>

Hello,

RabbitMQ HA has been backported into stable releases, and it?s documented
here:
https://docs.openstack.org/kolla-ansible/yoga/reference/message-queues/rabbitmq.html#high-availability

Best regards,
Michal

W dniu wt., 11.04.2023 o 13:32 Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
napisa?(a):

> Yes.
> But cluster cannot work properly without it. :(
>
> On Tue, Apr 11, 2023, 6:18 PM Danny Webb <Danny.Webb at thehutgroup.com>
> wrote:
>
>> This commit explains why they largely removed HA queue durability:
>>
>>
>> https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90a9a912588af0a180
>> ------------------------------
>> *From:* Satish Patel <satish.txt at gmail.com>
>> *Sent:* 09 April 2023 04:16
>> *To:* Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
>> *Cc:* OpenStack Discuss <openstack-discuss at lists.openstack.org>
>> *Subject:* Re: [openstack][sharing][kolla ansible]Problems when 1 of 3
>> controller was be down
>>
>>
>> * CAUTION: This email originates from outside THG *
>> ------------------------------
>> Are you proposing a solution or just raising an issue?
>>
>> I did find it strange that kolla-ansible doesn't support HA queue by
>> default. That is a disaster because when one of the nodes goes down it will
>> make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have to add
>> HA policy to make queue HA otherwise you will endup in problem.
>>
>> On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
>> wrote:
>>
>> Hello everyone.
>>
>> I want to summary for who meets problems with Openstack when deploy
>> cluster with 3 controller using Kolla Ansible
>>
>> Scenario: 1 of 3 controller is down
>>
>> 1. Login horizon and use API such as nova, cinder will be very slow
>>
>> fix by:
>>
>> nano:
>> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
>> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
>> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
>> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
>> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
>>
>> or which service need caches
>>
>> add as below
>>
>> [cache]
>> backend = oslo_cache.memcache_pool
>> enabled = True
>> memcache_servers = {{ kolla_internal_vip_address }}:{{ memcached_port }}
>> memcache_dead_retry = 0.25
>> memcache_socket_timeout = 900
>>
>> https://review.opendev.org/c/openstack/kolla-ansible/+/849487
>>
>> but it is not the end
>>
>> 2. Cannot launch instance or mapping block device(stuck at this step)
>>
>> nano kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
>>
>> "policies":[
>>     {"vhost": "/", "name": "ha-all", "pattern":
>> "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition":
>> {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
>>     {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all",
>> "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"},
>> "priority":0}
>>     {% endif %}
>>   ]
>>
>> nano /etc/kollla/global.conf
>>
>> [oslo_messaging_rabbit]
>> kombu_reconnect_delay=0.5
>>
>>
>> https://bugs.launchpad.net/oslo.messaging/+bug/1993149
>> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
>>
>> I used Xena 13.4 and Yoga 14.8.1.
>>
>> Above bugs are critical, but I see that it was not fixed. I am just an
>> operator and I want to share what I encountered for new people who come to
>> Openstack
>>
>>
>> Nguyen Huu Khoi
>>
>> --
Micha? Nasiadka
mnasiadka at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/d6e75111/attachment-0001.htm>

From michal.arbet at ultimum.io  Tue Apr 11 13:18:30 2023
From: michal.arbet at ultimum.io (Michal Arbet)
Date: Tue, 11 Apr 2023 15:18:30 +0200
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CANhpHj-5iOtHaGZHMgEOz1C_P9BW8AOw0RGV8zYgCUuphST=eg@mail.gmail.com>
References: <CABAODRdLhuX77ny=exdhe6rpxfOKFXfn5WOFD0yL8oHK6ZXv4g@mail.gmail.com>
 <CAPgF-fqwuGRa3Mf6euhW=kUSGNhNURTqguG6=fi=_2hiTqO0sQ@mail.gmail.com>
 <LO2P265MB5773607CCA9FDB60EC9037C39A9A9@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <CABAODRfjqYP4QY9KROd03SQjm+XFQ0C7xMApaahVJ2N8T6=+zQ@mail.gmail.com>
 <CANhpHj-5iOtHaGZHMgEOz1C_P9BW8AOw0RGV8zYgCUuphST=eg@mail.gmail.com>
Message-ID: <CAKz7_JSSsTOT5M+v-By-bUDsigSurhBNxZSp7bmFQm1J9Dwy4Q@mail.gmail.com>

Hi,

Btw, why we have such option set to false ?
Michal Arbet
Openstack Engineer

Ultimum Technologies a.s.
Na Po???? 1047/26, 11000 Praha 1
Czech Republic

+420 604 228 897
michal.arbet at ultimum.io
*https://ultimum.io <https://ultimum.io/>*

LinkedIn <https://www.linkedin.com/company/ultimum-technologies> | Twitter
<https://twitter.com/ultimumtech> | Facebook
<https://www.facebook.com/ultimumtechnologies/timeline>


?t 11. 4. 2023 v 14:48 odes?latel Micha? Nasiadka <mnasiadka at gmail.com>
napsal:

> Hello,
>
> RabbitMQ HA has been backported into stable releases, and it?s documented
> here:
>
> https://docs.openstack.org/kolla-ansible/yoga/reference/message-queues/rabbitmq.html#high-availability
>
> Best regards,
> Michal
>
> W dniu wt., 11.04.2023 o 13:32 Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> napisa?(a):
>
>> Yes.
>> But cluster cannot work properly without it. :(
>>
>> On Tue, Apr 11, 2023, 6:18 PM Danny Webb <Danny.Webb at thehutgroup.com>
>> wrote:
>>
>>> This commit explains why they largely removed HA queue durability:
>>>
>>>
>>> https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90a9a912588af0a180
>>> ------------------------------
>>> *From:* Satish Patel <satish.txt at gmail.com>
>>> *Sent:* 09 April 2023 04:16
>>> *To:* Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
>>> *Cc:* OpenStack Discuss <openstack-discuss at lists.openstack.org>
>>> *Subject:* Re: [openstack][sharing][kolla ansible]Problems when 1 of 3
>>> controller was be down
>>>
>>>
>>> * CAUTION: This email originates from outside THG *
>>> ------------------------------
>>> Are you proposing a solution or just raising an issue?
>>>
>>> I did find it strange that kolla-ansible doesn't support HA queue by
>>> default. That is a disaster because when one of the nodes goes down it will
>>> make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have to add
>>> HA policy to make queue HA otherwise you will endup in problem.
>>>
>>> On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <
>>> nguyenhuukhoinw at gmail.com> wrote:
>>>
>>> Hello everyone.
>>>
>>> I want to summary for who meets problems with Openstack when deploy
>>> cluster with 3 controller using Kolla Ansible
>>>
>>> Scenario: 1 of 3 controller is down
>>>
>>> 1. Login horizon and use API such as nova, cinder will be very slow
>>>
>>> fix by:
>>>
>>> nano:
>>> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
>>> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
>>> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
>>> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
>>> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
>>>
>>> or which service need caches
>>>
>>> add as below
>>>
>>> [cache]
>>> backend = oslo_cache.memcache_pool
>>> enabled = True
>>> memcache_servers = {{ kolla_internal_vip_address }}:{{ memcached_port }}
>>> memcache_dead_retry = 0.25
>>> memcache_socket_timeout = 900
>>>
>>> https://review.opendev.org/c/openstack/kolla-ansible/+/849487
>>>
>>> but it is not the end
>>>
>>> 2. Cannot launch instance or mapping block device(stuck at this step)
>>>
>>> nano kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
>>>
>>> "policies":[
>>>     {"vhost": "/", "name": "ha-all", "pattern":
>>> "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition":
>>> {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
>>>     {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all",
>>> "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"},
>>> "priority":0}
>>>     {% endif %}
>>>   ]
>>>
>>> nano /etc/kollla/global.conf
>>>
>>> [oslo_messaging_rabbit]
>>> kombu_reconnect_delay=0.5
>>>
>>>
>>> https://bugs.launchpad.net/oslo.messaging/+bug/1993149
>>> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
>>>
>>> I used Xena 13.4 and Yoga 14.8.1.
>>>
>>> Above bugs are critical, but I see that it was not fixed. I am just an
>>> operator and I want to share what I encountered for new people who come to
>>> Openstack
>>>
>>>
>>> Nguyen Huu Khoi
>>>
>>> --
> Micha? Nasiadka
> mnasiadka at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/3e87a02a/attachment.htm>

From dwilde at redhat.com  Tue Apr 11 13:18:43 2023
From: dwilde at redhat.com (Dave Wilde)
Date: Tue, 11 Apr 2023 08:18:43 -0500
Subject: [keystone] Weekly Meeting Cancelled (11-Apr-2023)
Message-ID: <57ef0e9a-047f-45ed-8bf7-e342b4b4750b@Spark>

Hi Folks,

Unfortunately I have to cancel the weekly meeting today.??Please reach out to me directly via email if you need anything.??Due to equipment failure my IRC availability is spotty.

Thanks!

/Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/e22fe532/attachment.htm>

From nguyenhuukhoinw at gmail.com  Tue Apr 11 13:48:37 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Tue, 11 Apr 2023 20:48:37 +0700
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CANhpHj-5iOtHaGZHMgEOz1C_P9BW8AOw0RGV8zYgCUuphST=eg@mail.gmail.com>
References: <CABAODRdLhuX77ny=exdhe6rpxfOKFXfn5WOFD0yL8oHK6ZXv4g@mail.gmail.com>
 <CAPgF-fqwuGRa3Mf6euhW=kUSGNhNURTqguG6=fi=_2hiTqO0sQ@mail.gmail.com>
 <LO2P265MB5773607CCA9FDB60EC9037C39A9A9@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <CABAODRfjqYP4QY9KROd03SQjm+XFQ0C7xMApaahVJ2N8T6=+zQ@mail.gmail.com>
 <CANhpHj-5iOtHaGZHMgEOz1C_P9BW8AOw0RGV8zYgCUuphST=eg@mail.gmail.com>
Message-ID: <CABAODRdWDBw=9Ub8BwM+=+F562uvXsRcrYqJhqFXv8CnW0h+EA@mail.gmail.com>

Thank for your response.
I set in global.yml.
om_enable_rabbitmq_high_availability: "true"
But it wont work so i need add policies for rabbitmq.

On Tue, Apr 11, 2023, 7:42 PM Micha? Nasiadka <mnasiadka at gmail.com> wrote:

> Hello,
>
> RabbitMQ HA has been backported into stable releases, and it?s documented
> here:
>
> https://docs.openstack.org/kolla-ansible/yoga/reference/message-queues/rabbitmq.html#high-availability
>
> Best regards,
> Michal
>
> W dniu wt., 11.04.2023 o 13:32 Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> napisa?(a):
>
>> Yes.
>> But cluster cannot work properly without it. :(
>>
>> On Tue, Apr 11, 2023, 6:18 PM Danny Webb <Danny.Webb at thehutgroup.com>
>> wrote:
>>
>>> This commit explains why they largely removed HA queue durability:
>>>
>>>
>>> https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90a9a912588af0a180
>>> ------------------------------
>>> *From:* Satish Patel <satish.txt at gmail.com>
>>> *Sent:* 09 April 2023 04:16
>>> *To:* Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
>>> *Cc:* OpenStack Discuss <openstack-discuss at lists.openstack.org>
>>> *Subject:* Re: [openstack][sharing][kolla ansible]Problems when 1 of 3
>>> controller was be down
>>>
>>>
>>> * CAUTION: This email originates from outside THG *
>>> ------------------------------
>>> Are you proposing a solution or just raising an issue?
>>>
>>> I did find it strange that kolla-ansible doesn't support HA queue by
>>> default. That is a disaster because when one of the nodes goes down it will
>>> make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have to add
>>> HA policy to make queue HA otherwise you will endup in problem.
>>>
>>> On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <
>>> nguyenhuukhoinw at gmail.com> wrote:
>>>
>>> Hello everyone.
>>>
>>> I want to summary for who meets problems with Openstack when deploy
>>> cluster with 3 controller using Kolla Ansible
>>>
>>> Scenario: 1 of 3 controller is down
>>>
>>> 1. Login horizon and use API such as nova, cinder will be very slow
>>>
>>> fix by:
>>>
>>> nano:
>>> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
>>> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
>>> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
>>> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
>>> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
>>>
>>> or which service need caches
>>>
>>> add as below
>>>
>>> [cache]
>>> backend = oslo_cache.memcache_pool
>>> enabled = True
>>> memcache_servers = {{ kolla_internal_vip_address }}:{{ memcached_port }}
>>> memcache_dead_retry = 0.25
>>> memcache_socket_timeout = 900
>>>
>>> https://review.opendev.org/c/openstack/kolla-ansible/+/849487
>>>
>>> but it is not the end
>>>
>>> 2. Cannot launch instance or mapping block device(stuck at this step)
>>>
>>> nano kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
>>>
>>> "policies":[
>>>     {"vhost": "/", "name": "ha-all", "pattern":
>>> "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition":
>>> {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
>>>     {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all",
>>> "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"},
>>> "priority":0}
>>>     {% endif %}
>>>   ]
>>>
>>> nano /etc/kollla/global.conf
>>>
>>> [oslo_messaging_rabbit]
>>> kombu_reconnect_delay=0.5
>>>
>>>
>>> https://bugs.launchpad.net/oslo.messaging/+bug/1993149
>>> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
>>>
>>> I used Xena 13.4 and Yoga 14.8.1.
>>>
>>> Above bugs are critical, but I see that it was not fixed. I am just an
>>> operator and I want to share what I encountered for new people who come to
>>> Openstack
>>>
>>>
>>> Nguyen Huu Khoi
>>>
>>> --
> Micha? Nasiadka
> mnasiadka at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/35b2f08a/attachment-0001.htm>

From noonedeadpunk at gmail.com  Tue Apr 11 13:53:17 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Tue, 11 Apr 2023 15:53:17 +0200
Subject: StackOver Flow Error: 2103 ERROR
 oslo.messaging._drivers.impl_rabbit
 Connection failed: failed to resolve broker hostname
In-Reply-To: <CAF_4gkd75x=+jGms5G_HGB251a0aBCkF6FvsaafPaxAPRJQ8Xg@mail.gmail.com>
References: <CAF_4gkcPBznYiWd1o+HF8vYY3ObqtTTZ_McEvyyWJ+SHfrMNtg@mail.gmail.com>
 <CAPd_6As8FOZV2LEr2JhrU_HBdwGEQ8AW-=b29=8gGK2bEt1o7Q@mail.gmail.com>
 <CAF_4gkd75x=+jGms5G_HGB251a0aBCkF6FvsaafPaxAPRJQ8Xg@mail.gmail.com>
Message-ID: <CAPd_6Atg6nVvZ_mNYhwiUbBR=C4_0geZqM7etuo5k-gvzPUKsg@mail.gmail.com>

If you're going to go prod I would for sure use some deployment tool rather
then manual deployment, as further operations and scaling up would be way
easier.

What error do you get with existing hosts record?

??, 11 ???. 2023 ?., 14:57 Trey Fleishman <nfleishman at student.ccaeagles.org
>:

> Hello Dmitriy,
>
> That is what I thought too, in my host file I define the hostname as the
> correct IP address, and if I change the "controller" hostname to some
> factitious IP I get a different error. I've tried putting the IP instead of
> the hostname, but to no avail. I can successfully ping the hostname from
> the machine. I would also rather not use a tool as I plan to go production
> once I get my two node setup functional. I am not sure if this might be a
> configuration issue, or maybe a bug.
> Trey Fleishman
> Student and IT Intern
> (704) 750 - 1740
> *Calvary Chapel Fort Lauderdale*
> 2401 W. Cypress Creek Rd., Ft. Lauderdale, FL 33309
> CalvaryFTL.org
>
>
> On Tue, Apr 11, 2023 at 12:54?AM Dmitriy Rabotyagov <
> noonedeadpunk at gmail.com> wrote:
>
>> Hi Trey,
>>
>> Have you defined a record in your /etc/hosts for "controller", as
>> according to the error service simply can not resolve this hostname to an
>> IP address.
>>
>> Also I can suggest trying out one of the following OpenStack deployment
>> tools:
>> https://docs.openstack.org/zed/deploy/index.html
>>
>> Most of them have All-In-One guides that can spawn an opestack sandbox to
>> play with.
>>
>> ??, 11 ???. 2023 ?., 00:21 Trey Fleishman <
>> nfleishman at student.ccaeagles.org>:
>>
>>> Hello all,
>>> Recently I tried installing Openstack via this
>>> <https://docs.openstack.org/install-guide/openstack-services.html>
>>> guide. Upon completion of all the steps including the dashboard step, I was
>>> greeted with this error inside the nova_schedular.log file, after I tried
>>> creating an instance.
>>>
>>> 2103 ERROR oslo.messaging._drivers.impl_rabbit Connection failed: failed
>>> to resolve broker hostname: OSError: failed to resolve broker hostname
>>>
>>> When I try to create an instance it hangs in the "scheduling" state and
>>> throws this error. I have not configured anything in the "oslo.messaging"
>>> section of the Nova config file. I believe that under the [default] section
>>> this is what's causing the issue, but the password and hostname are fine.
>>>
>>> transport_url =
>>> rabbit://openstack:BnE9LLfCtjdPvpEnZUnPytSyrfUxE8th at controller
>>>
>>> Thanks!
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/b04fd455/attachment.htm>

From nguyenhuukhoinw at gmail.com  Tue Apr 11 13:57:05 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Tue, 11 Apr 2023 20:57:05 +0700
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CABAODRdWDBw=9Ub8BwM+=+F562uvXsRcrYqJhqFXv8CnW0h+EA@mail.gmail.com>
References: <CABAODRdLhuX77ny=exdhe6rpxfOKFXfn5WOFD0yL8oHK6ZXv4g@mail.gmail.com>
 <CAPgF-fqwuGRa3Mf6euhW=kUSGNhNURTqguG6=fi=_2hiTqO0sQ@mail.gmail.com>
 <LO2P265MB5773607CCA9FDB60EC9037C39A9A9@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <CABAODRfjqYP4QY9KROd03SQjm+XFQ0C7xMApaahVJ2N8T6=+zQ@mail.gmail.com>
 <CANhpHj-5iOtHaGZHMgEOz1C_P9BW8AOw0RGV8zYgCUuphST=eg@mail.gmail.com>
 <CABAODRdWDBw=9Ub8BwM+=+F562uvXsRcrYqJhqFXv8CnW0h+EA@mail.gmail.com>
Message-ID: <CABAODReGTxYa9pJ-3cVGdf9gPuzsEe0Neec5TbZrSYxYs4dT9A@mail.gmail.com>

The most important what I mean that without above config, our cluster will
not work prolerly if 1 of 3 controller is down. I tested with Xena and Yoga
by using kolla-ansible.

On Tue, Apr 11, 2023, 8:48 PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Thank for your response.
> I set in global.yml.
> om_enable_rabbitmq_high_availability: "true"
> But it wont work so i need add policies for rabbitmq.
>
> On Tue, Apr 11, 2023, 7:42 PM Micha? Nasiadka <mnasiadka at gmail.com> wrote:
>
>> Hello,
>>
>> RabbitMQ HA has been backported into stable releases, and it?s documented
>> here:
>>
>> https://docs.openstack.org/kolla-ansible/yoga/reference/message-queues/rabbitmq.html#high-availability
>>
>> Best regards,
>> Michal
>>
>> W dniu wt., 11.04.2023 o 13:32 Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
>> napisa?(a):
>>
>>> Yes.
>>> But cluster cannot work properly without it. :(
>>>
>>> On Tue, Apr 11, 2023, 6:18 PM Danny Webb <Danny.Webb at thehutgroup.com>
>>> wrote:
>>>
>>>> This commit explains why they largely removed HA queue durability:
>>>>
>>>>
>>>> https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90a9a912588af0a180
>>>> ------------------------------
>>>> *From:* Satish Patel <satish.txt at gmail.com>
>>>> *Sent:* 09 April 2023 04:16
>>>> *To:* Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
>>>> *Cc:* OpenStack Discuss <openstack-discuss at lists.openstack.org>
>>>> *Subject:* Re: [openstack][sharing][kolla ansible]Problems when 1 of 3
>>>> controller was be down
>>>>
>>>>
>>>> * CAUTION: This email originates from outside THG *
>>>> ------------------------------
>>>> Are you proposing a solution or just raising an issue?
>>>>
>>>> I did find it strange that kolla-ansible doesn't support HA queue by
>>>> default. That is a disaster because when one of the nodes goes down it will
>>>> make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have to add
>>>> HA policy to make queue HA otherwise you will endup in problem.
>>>>
>>>> On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <
>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>
>>>> Hello everyone.
>>>>
>>>> I want to summary for who meets problems with Openstack when deploy
>>>> cluster with 3 controller using Kolla Ansible
>>>>
>>>> Scenario: 1 of 3 controller is down
>>>>
>>>> 1. Login horizon and use API such as nova, cinder will be very slow
>>>>
>>>> fix by:
>>>>
>>>> nano:
>>>> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
>>>> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
>>>> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
>>>> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
>>>> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
>>>>
>>>> or which service need caches
>>>>
>>>> add as below
>>>>
>>>> [cache]
>>>> backend = oslo_cache.memcache_pool
>>>> enabled = True
>>>> memcache_servers = {{ kolla_internal_vip_address }}:{{ memcached_port }}
>>>> memcache_dead_retry = 0.25
>>>> memcache_socket_timeout = 900
>>>>
>>>> https://review.opendev.org/c/openstack/kolla-ansible/+/849487
>>>>
>>>> but it is not the end
>>>>
>>>> 2. Cannot launch instance or mapping block device(stuck at this step)
>>>>
>>>> nano kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
>>>>
>>>> "policies":[
>>>>     {"vhost": "/", "name": "ha-all", "pattern":
>>>> "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition":
>>>> {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
>>>>     {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all",
>>>> "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"},
>>>> "priority":0}
>>>>     {% endif %}
>>>>   ]
>>>>
>>>> nano /etc/kollla/global.conf
>>>>
>>>> [oslo_messaging_rabbit]
>>>> kombu_reconnect_delay=0.5
>>>>
>>>>
>>>> https://bugs.launchpad.net/oslo.messaging/+bug/1993149
>>>> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
>>>>
>>>> I used Xena 13.4 and Yoga 14.8.1.
>>>>
>>>> Above bugs are critical, but I see that it was not fixed. I am just an
>>>> operator and I want to share what I encountered for new people who come to
>>>> Openstack
>>>>
>>>>
>>>> Nguyen Huu Khoi
>>>>
>>>> --
>> Micha? Nasiadka
>> mnasiadka at gmail.com
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/261cb4b0/attachment-0001.htm>

From smooney at redhat.com  Tue Apr 11 14:03:55 2023
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 11 Apr 2023 15:03:55 +0100
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CAKz7_JSSsTOT5M+v-By-bUDsigSurhBNxZSp7bmFQm1J9Dwy4Q@mail.gmail.com>
References: <CABAODRdLhuX77ny=exdhe6rpxfOKFXfn5WOFD0yL8oHK6ZXv4g@mail.gmail.com>
 <CAPgF-fqwuGRa3Mf6euhW=kUSGNhNURTqguG6=fi=_2hiTqO0sQ@mail.gmail.com>
 <LO2P265MB5773607CCA9FDB60EC9037C39A9A9@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <CABAODRfjqYP4QY9KROd03SQjm+XFQ0C7xMApaahVJ2N8T6=+zQ@mail.gmail.com>
 <CANhpHj-5iOtHaGZHMgEOz1C_P9BW8AOw0RGV8zYgCUuphST=eg@mail.gmail.com>
 <CAKz7_JSSsTOT5M+v-By-bUDsigSurhBNxZSp7bmFQm1J9Dwy4Q@mail.gmail.com>
Message-ID: <f242b2bd3a04bd73593ec14394ff9b9ccf447d13.camel@redhat.com>

On Tue, 2023-04-11 at 15:18 +0200, Michal Arbet wrote:
> Hi,
> 
> Btw, why we have such option set to false ?
it has a pretty big performance penalty if combined with durable queue
and in generall its questionable if it should be used going forward.

there is an argument to be made that ha/mirrored queues and durable queue shoudl be replaced
with https://www.rabbitmq.com/quorum-queues.html


the other thing to consider is that this needs to eb set per vhost
so if two serivce share a vhost it needs to be set to the same value.

in general for notificaiton both ha and durable queues shoudl be disabled as notifcation are intented
to be fire and forget
for rpc calls or casts having relibale deliver is imporant but how you acive that is archittur dependent.
meaning using ha queue is not alwasy the corrct default.
if you need to scale to many request per secodn you are better off using durable queuse with storge on something like
ceph/nfs and an active/backup deployment with one rabbit per openstack service. you might choose to run such a rabbit
cluster in a k8s env for example using persitent voluems.

in other cases simple ha queues and a shred rabbit is fine for small scale deployments.
quorum queue may also make more sense.

this is why rabbit is called out in the production arctechture guide
https://docs.openstack.org/kolla-ansible/latest/admin/production-architecture-guide.html#other-core-services
and why there is an option to opt into ha/durable queues since that is often enough for small scale deployments.
https://docs.openstack.org/kolla-ansible/latest/reference/message-queues/rabbitmq.html#high-availability











> Michal Arbet
> Openstack Engineer
> 
> Ultimum Technologies a.s.
> Na Po???? 1047/26, 11000 Praha 1
> Czech Republic
> 
> +420 604 228 897
> michal.arbet at ultimum.io
> *https://ultimum.io <https://ultimum.io/>*
> 
> LinkedIn <https://www.linkedin.com/company/ultimum-technologies> | Twitter
> <https://twitter.com/ultimumtech> | Facebook
> <https://www.facebook.com/ultimumtechnologies/timeline>
> 
> 
> ?t 11. 4. 2023 v 14:48 odes?latel Micha? Nasiadka <mnasiadka at gmail.com>
> napsal:
> 
> > Hello,
> > 
> > RabbitMQ HA has been backported into stable releases, and it?s documented
> > here:
> > 
> > https://docs.openstack.org/kolla-ansible/yoga/reference/message-queues/rabbitmq.html#high-availability
> > 
> > Best regards,
> > Michal
> > 
> > W dniu wt., 11.04.2023 o 13:32 Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> > napisa?(a):
> > 
> > > Yes.
> > > But cluster cannot work properly without it. :(
> > > 
> > > On Tue, Apr 11, 2023, 6:18 PM Danny Webb <Danny.Webb at thehutgroup.com>
> > > wrote:
> > > 
> > > > This commit explains why they largely removed HA queue durability:
> > > > 
> > > > 
> > > > https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90a9a912588af0a180
> > > > ------------------------------
> > > > *From:* Satish Patel <satish.txt at gmail.com>
> > > > *Sent:* 09 April 2023 04:16
> > > > *To:* Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> > > > *Cc:* OpenStack Discuss <openstack-discuss at lists.openstack.org>
> > > > *Subject:* Re: [openstack][sharing][kolla ansible]Problems when 1 of 3
> > > > controller was be down
> > > > 
> > > > 
> > > > * CAUTION: This email originates from outside THG *
> > > > ------------------------------
> > > > Are you proposing a solution or just raising an issue?
> > > > 
> > > > I did find it strange that kolla-ansible doesn't support HA queue by
> > > > default. That is a disaster because when one of the nodes goes down it will
> > > > make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have to add
> > > > HA policy to make queue HA otherwise you will endup in problem.
> > > > 
> > > > On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <
> > > > nguyenhuukhoinw at gmail.com> wrote:
> > > > 
> > > > Hello everyone.
> > > > 
> > > > I want to summary for who meets problems with Openstack when deploy
> > > > cluster with 3 controller using Kolla Ansible
> > > > 
> > > > Scenario: 1 of 3 controller is down
> > > > 
> > > > 1. Login horizon and use API such as nova, cinder will be very slow
> > > > 
> > > > fix by:
> > > > 
> > > > nano:
> > > > kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
> > > > kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
> > > > kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
> > > > kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
> > > > kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
> > > > 
> > > > or which service need caches
> > > > 
> > > > add as below
> > > > 
> > > > [cache]
> > > > backend = oslo_cache.memcache_pool
> > > > enabled = True
> > > > memcache_servers = {{ kolla_internal_vip_address }}:{{ memcached_port }}
> > > > memcache_dead_retry = 0.25
> > > > memcache_socket_timeout = 900
> > > > 
> > > > https://review.opendev.org/c/openstack/kolla-ansible/+/849487
> > > > 
> > > > but it is not the end
> > > > 
> > > > 2. Cannot launch instance or mapping block device(stuck at this step)
> > > > 
> > > > nano kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
> > > > 
> > > > "policies":[
> > > >     {"vhost": "/", "name": "ha-all", "pattern":
> > > > "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition":
> > > > {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
> > > >     {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all",
> > > > "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"},
> > > > "priority":0}
> > > >     {% endif %}
> > > >   ]
> > > > 
> > > > nano /etc/kollla/global.conf
> > > > 
> > > > [oslo_messaging_rabbit]
> > > > kombu_reconnect_delay=0.5
> > > > 
> > > > 
> > > > https://bugs.launchpad.net/oslo.messaging/+bug/1993149
> > > > https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
> > > > 
> > > > I used Xena 13.4 and Yoga 14.8.1.
> > > > 
> > > > Above bugs are critical, but I see that it was not fixed. I am just an
> > > > operator and I want to share what I encountered for new people who come to
> > > > Openstack
> > > > 
> > > > 
> > > > Nguyen Huu Khoi
> > > > 
> > > > --
> > Micha? Nasiadka
> > mnasiadka at gmail.com
> > 



From nfleishman at student.ccaeagles.org  Tue Apr 11 14:10:05 2023
From: nfleishman at student.ccaeagles.org (Trey Fleishman)
Date: Tue, 11 Apr 2023 10:10:05 -0400
Subject: StackOver Flow Error: 2103 ERROR
 oslo.messaging._drivers.impl_rabbit
 Connection failed: failed to resolve broker hostname
In-Reply-To: <CAPd_6Atg6nVvZ_mNYhwiUbBR=C4_0geZqM7etuo5k-gvzPUKsg@mail.gmail.com>
References: <CAF_4gkcPBznYiWd1o+HF8vYY3ObqtTTZ_McEvyyWJ+SHfrMNtg@mail.gmail.com>
 <CAPd_6As8FOZV2LEr2JhrU_HBdwGEQ8AW-=b29=8gGK2bEt1o7Q@mail.gmail.com>
 <CAF_4gkd75x=+jGms5G_HGB251a0aBCkF6FvsaafPaxAPRJQ8Xg@mail.gmail.com>
 <CAPd_6Atg6nVvZ_mNYhwiUbBR=C4_0geZqM7etuo5k-gvzPUKsg@mail.gmail.com>
Message-ID: <CAF_4gkfGpw3P8u51MQokgo4hm=REbniGt95w5bdOwj+r_T0C+g@mail.gmail.com>

2103 ERROR oslo.messaging._drivers.impl_rabbit Connection failed: failed to
resolve broker hostname: OSError: failed to resolve broker hostname


On Tue, Apr 11, 2023 at 9:54?AM Dmitriy Rabotyagov <noonedeadpunk at gmail.com>
wrote:

> If you're going to go prod I would for sure use some deployment tool
> rather then manual deployment, as further operations and scaling up would
> be way easier.
>
> What error do you get with existing hosts record?
>
> ??, 11 ???. 2023 ?., 14:57 Trey Fleishman <
> nfleishman at student.ccaeagles.org>:
>
>> Hello Dmitriy,
>>
>> That is what I thought too, in my host file I define the hostname as the
>> correct IP address, and if I change the "controller" hostname to some
>> factitious IP I get a different error. I've tried putting the IP instead of
>> the hostname, but to no avail. I can successfully ping the hostname from
>> the machine. I would also rather not use a tool as I plan to go production
>> once I get my two node setup functional. I am not sure if this might be a
>> configuration issue, or maybe a bug.
>> Trey Fleishman
>> Student and IT Intern
>> (704) 750 - 1740
>> *Calvary Chapel Fort Lauderdale*
>> 2401 W. Cypress Creek Rd., Ft. Lauderdale, FL 33309
>> CalvaryFTL.org
>>
>>
>> On Tue, Apr 11, 2023 at 12:54?AM Dmitriy Rabotyagov <
>> noonedeadpunk at gmail.com> wrote:
>>
>>> Hi Trey,
>>>
>>> Have you defined a record in your /etc/hosts for "controller", as
>>> according to the error service simply can not resolve this hostname to an
>>> IP address.
>>>
>>> Also I can suggest trying out one of the following OpenStack deployment
>>> tools:
>>> https://docs.openstack.org/zed/deploy/index.html
>>>
>>> Most of them have All-In-One guides that can spawn an opestack sandbox
>>> to play with.
>>>
>>> ??, 11 ???. 2023 ?., 00:21 Trey Fleishman <
>>> nfleishman at student.ccaeagles.org>:
>>>
>>>> Hello all,
>>>> Recently I tried installing Openstack via this
>>>> <https://docs.openstack.org/install-guide/openstack-services.html>
>>>> guide. Upon completion of all the steps including the dashboard step, I was
>>>> greeted with this error inside the nova_schedular.log file, after I tried
>>>> creating an instance.
>>>>
>>>> 2103 ERROR oslo.messaging._drivers.impl_rabbit Connection failed:
>>>> failed to resolve broker hostname: OSError: failed to resolve broker
>>>> hostname
>>>>
>>>> When I try to create an instance it hangs in the "scheduling" state and
>>>> throws this error. I have not configured anything in the "oslo.messaging"
>>>> section of the Nova config file. I believe that under the [default] section
>>>> this is what's causing the issue, but the password and hostname are fine.
>>>>
>>>> transport_url =
>>>> rabbit://openstack:BnE9LLfCtjdPvpEnZUnPytSyrfUxE8th at controller
>>>>
>>>> Thanks!
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/6d389c80/attachment.htm>

From satish.txt at gmail.com  Tue Apr 11 15:06:11 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Tue, 11 Apr 2023 11:06:11 -0400
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <f242b2bd3a04bd73593ec14394ff9b9ccf447d13.camel@redhat.com>
References: <CABAODRdLhuX77ny=exdhe6rpxfOKFXfn5WOFD0yL8oHK6ZXv4g@mail.gmail.com>
 <CAPgF-fqwuGRa3Mf6euhW=kUSGNhNURTqguG6=fi=_2hiTqO0sQ@mail.gmail.com>
 <LO2P265MB5773607CCA9FDB60EC9037C39A9A9@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <CABAODRfjqYP4QY9KROd03SQjm+XFQ0C7xMApaahVJ2N8T6=+zQ@mail.gmail.com>
 <CANhpHj-5iOtHaGZHMgEOz1C_P9BW8AOw0RGV8zYgCUuphST=eg@mail.gmail.com>
 <CAKz7_JSSsTOT5M+v-By-bUDsigSurhBNxZSp7bmFQm1J9Dwy4Q@mail.gmail.com>
 <f242b2bd3a04bd73593ec14394ff9b9ccf447d13.camel@redhat.com>
Message-ID: <CAPgF-fq6yJJd981e=YWQ7sxPC=En5widGGECYjR3LTEwVBwxiw@mail.gmail.com>

This is what i am doing in my deployment, not sure if this is right or not
but it works for me and survives my cluster all reboot.

# cat /etc/kolla/config/rabbitmq/definitions.json

{

"vhosts": [{

"name": "/"

}],

"users": [{

"name": "openstack",

"password": "Password123",

"tags": "administrator"

},

{

"name": "monitoring",

"password": "Password321",

"tags": "monitoring"

}

],

"permissions": [{

"user": "openstack",

"vhost": "/",

"configure": ".*",

"write": ".*",

"read": ".*"

},

{

"user": "monitoring",

"vhost": "/",

"configure": "^$",

"write": "^$",

"read": ".*"

}

],

"policies": [{

"vhost": "/",

"name": "ha-all",

"pattern": "^(?!(amq\\.)|(.*_fanout_)|(reply_)).*",

"apply-to": "all",

"definition": {

"ha-mode": "all"

},

"priority": 0

}]

}

On Tue, Apr 11, 2023 at 10:04?AM Sean Mooney <smooney at redhat.com> wrote:

> On Tue, 2023-04-11 at 15:18 +0200, Michal Arbet wrote:
> > Hi,
> >
> > Btw, why we have such option set to false ?
> it has a pretty big performance penalty if combined with durable queue
> and in generall its questionable if it should be used going forward.
>
> there is an argument to be made that ha/mirrored queues and durable queue
> shoudl be replaced
> with https://www.rabbitmq.com/quorum-queues.html
>
>
> the other thing to consider is that this needs to eb set per vhost
> so if two serivce share a vhost it needs to be set to the same value.
>
> in general for notificaiton both ha and durable queues shoudl be disabled
> as notifcation are intented
> to be fire and forget
> for rpc calls or casts having relibale deliver is imporant but how you
> acive that is archittur dependent.
> meaning using ha queue is not alwasy the corrct default.
> if you need to scale to many request per secodn you are better off using
> durable queuse with storge on something like
> ceph/nfs and an active/backup deployment with one rabbit per openstack
> service. you might choose to run such a rabbit
> cluster in a k8s env for example using persitent voluems.
>
> in other cases simple ha queues and a shred rabbit is fine for small scale
> deployments.
> quorum queue may also make more sense.
>
> this is why rabbit is called out in the production arctechture guide
>
> https://docs.openstack.org/kolla-ansible/latest/admin/production-architecture-guide.html#other-core-services
> and why there is an option to opt into ha/durable queues since that is
> often enough for small scale deployments.
>
> https://docs.openstack.org/kolla-ansible/latest/reference/message-queues/rabbitmq.html#high-availability
>
>
>
>
>
>
>
>
>
>
>
> > Michal Arbet
> > Openstack Engineer
> >
> > Ultimum Technologies a.s.
> > Na Po???? 1047/26, 11000 Praha 1
> > Czech Republic
> >
> > +420 604 228 897
> > michal.arbet at ultimum.io
> > *https://ultimum.io <https://ultimum.io/>*
> >
> > LinkedIn <https://www.linkedin.com/company/ultimum-technologies> |
> Twitter
> > <https://twitter.com/ultimumtech> | Facebook
> > <https://www.facebook.com/ultimumtechnologies/timeline>
> >
> >
> > ?t 11. 4. 2023 v 14:48 odes?latel Micha? Nasiadka <mnasiadka at gmail.com>
> > napsal:
> >
> > > Hello,
> > >
> > > RabbitMQ HA has been backported into stable releases, and it?s
> documented
> > > here:
> > >
> > >
> https://docs.openstack.org/kolla-ansible/yoga/reference/message-queues/rabbitmq.html#high-availability
> > >
> > > Best regards,
> > > Michal
> > >
> > > W dniu wt., 11.04.2023 o 13:32 Nguy?n H?u Kh?i <
> nguyenhuukhoinw at gmail.com>
> > > napisa?(a):
> > >
> > > > Yes.
> > > > But cluster cannot work properly without it. :(
> > > >
> > > > On Tue, Apr 11, 2023, 6:18 PM Danny Webb <Danny.Webb at thehutgroup.com
> >
> > > > wrote:
> > > >
> > > > > This commit explains why they largely removed HA queue durability:
> > > > >
> > > > >
> > > > >
> https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90a9a912588af0a180
> > > > > ------------------------------
> > > > > *From:* Satish Patel <satish.txt at gmail.com>
> > > > > *Sent:* 09 April 2023 04:16
> > > > > *To:* Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> > > > > *Cc:* OpenStack Discuss <openstack-discuss at lists.openstack.org>
> > > > > *Subject:* Re: [openstack][sharing][kolla ansible]Problems when 1
> of 3
> > > > > controller was be down
> > > > >
> > > > >
> > > > > * CAUTION: This email originates from outside THG *
> > > > > ------------------------------
> > > > > Are you proposing a solution or just raising an issue?
> > > > >
> > > > > I did find it strange that kolla-ansible doesn't support HA queue
> by
> > > > > default. That is a disaster because when one of the nodes goes
> down it will
> > > > > make the whole rabbitMQ unacceptable. Whenever i deploy kolla i
> have to add
> > > > > HA policy to make queue HA otherwise you will endup in problem.
> > > > >
> > > > > On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <
> > > > > nguyenhuukhoinw at gmail.com> wrote:
> > > > >
> > > > > Hello everyone.
> > > > >
> > > > > I want to summary for who meets problems with Openstack when deploy
> > > > > cluster with 3 controller using Kolla Ansible
> > > > >
> > > > > Scenario: 1 of 3 controller is down
> > > > >
> > > > > 1. Login horizon and use API such as nova, cinder will be very slow
> > > > >
> > > > > fix by:
> > > > >
> > > > > nano:
> > > > > kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
> > > > > kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
> > > > > kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
> > > > > kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
> > > > > kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
> > > > >
> > > > > or which service need caches
> > > > >
> > > > > add as below
> > > > >
> > > > > [cache]
> > > > > backend = oslo_cache.memcache_pool
> > > > > enabled = True
> > > > > memcache_servers = {{ kolla_internal_vip_address }}:{{
> memcached_port }}
> > > > > memcache_dead_retry = 0.25
> > > > > memcache_socket_timeout = 900
> > > > >
> > > > > https://review.opendev.org/c/openstack/kolla-ansible/+/849487
> > > > >
> > > > > but it is not the end
> > > > >
> > > > > 2. Cannot launch instance or mapping block device(stuck at this
> step)
> > > > >
> > > > > nano
> kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
> > > > >
> > > > > "policies":[
> > > > >     {"vhost": "/", "name": "ha-all", "pattern":
> > > > > "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all",
> "definition":
> > > > > {"ha-mode":"all"}, "priority":0}{% if project_name ==
> 'outward_rabbitmq' %},
> > > > >     {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name":
> "ha-all",
> > > > > "pattern": ".*", "apply-to": "all", "definition":
> {"ha-mode":"all"},
> > > > > "priority":0}
> > > > >     {% endif %}
> > > > >   ]
> > > > >
> > > > > nano /etc/kollla/global.conf
> > > > >
> > > > > [oslo_messaging_rabbit]
> > > > > kombu_reconnect_delay=0.5
> > > > >
> > > > >
> > > > > https://bugs.launchpad.net/oslo.messaging/+bug/1993149
> > > > >
> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
> > > > >
> > > > > I used Xena 13.4 and Yoga 14.8.1.
> > > > >
> > > > > Above bugs are critical, but I see that it was not fixed. I am
> just an
> > > > > operator and I want to share what I encountered for new people who
> come to
> > > > > Openstack
> > > > >
> > > > >
> > > > > Nguyen Huu Khoi
> > > > >
> > > > > --
> > > Micha? Nasiadka
> > > mnasiadka at gmail.com
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/c62995d2/attachment-0001.htm>

From mnasiadka at gmail.com  Tue Apr 11 15:18:01 2023
From: mnasiadka at gmail.com (=?utf-8?Q?Micha=C5=82_Nasiadka?=)
Date: Tue, 11 Apr 2023 17:18:01 +0200
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CAKz7_JSSsTOT5M+v-By-bUDsigSurhBNxZSp7bmFQm1J9Dwy4Q@mail.gmail.com>
References: <CABAODRdLhuX77ny=exdhe6rpxfOKFXfn5WOFD0yL8oHK6ZXv4g@mail.gmail.com>
 <CAPgF-fqwuGRa3Mf6euhW=kUSGNhNURTqguG6=fi=_2hiTqO0sQ@mail.gmail.com>
 <LO2P265MB5773607CCA9FDB60EC9037C39A9A9@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <CABAODRfjqYP4QY9KROd03SQjm+XFQ0C7xMApaahVJ2N8T6=+zQ@mail.gmail.com>
 <CANhpHj-5iOtHaGZHMgEOz1C_P9BW8AOw0RGV8zYgCUuphST=eg@mail.gmail.com>
 <CAKz7_JSSsTOT5M+v-By-bUDsigSurhBNxZSp7bmFQm1J9Dwy4Q@mail.gmail.com>
Message-ID: <DE448BAA-8251-4E15-A4CA-0BA83495F710@gmail.com>

Hi Michal, 

Feel free to propose change of default in master branch, but I don?t think we can change the default in stable branches without impacting users.

Best regards,
Michal

> On 11 Apr 2023, at 15:18, Michal Arbet <michal.arbet at ultimum.io> wrote:
> 
> Hi,
> 
> Btw, why we have such option set to false ? 
> Michal Arbet
> Openstack Engineer
> 
> Ultimum Technologies a.s.
> Na Po???? 1047/26, 11000 Praha 1
> Czech Republic
> 
> +420 604 228 897 <> 
> michal.arbet at ultimum.io <mailto:michal.arbet at ultimum.io>
> https://ultimum.io <https://ultimum.io/>
> 
> LinkedIn <https://www.linkedin.com/company/ultimum-technologies> | Twitter <https://twitter.com/ultimumtech> | Facebook <https://www.facebook.com/ultimumtechnologies/timeline>
> 
> 
> ?t 11. 4. 2023 v 14:48 odes?latel Micha? Nasiadka <mnasiadka at gmail.com <mailto:mnasiadka at gmail.com>> napsal:
>> Hello,
>> 
>> RabbitMQ HA has been backported into stable releases, and it?s documented here: 
>> https://docs.openstack.org/kolla-ansible/yoga/reference/message-queues/rabbitmq.html#high-availability
>> 
>> Best regards,
>> Michal
>> 
>> W dniu wt., 11.04.2023 o 13:32 Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> napisa?(a):
>>> Yes.
>>> But cluster cannot work properly without it. :(
>>> 
>>> On Tue, Apr 11, 2023, 6:18 PM Danny Webb <Danny.Webb at thehutgroup.com <mailto:Danny.Webb at thehutgroup.com>> wrote:
>>>> This commit explains why they largely removed HA queue durability:
>>>> 
>>>> https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90a9a912588af0a180
>>>> From: Satish Patel <satish.txt at gmail.com <mailto:satish.txt at gmail.com>>
>>>> Sent: 09 April 2023 04:16
>>>> To: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>>
>>>> Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org <mailto:openstack-discuss at lists.openstack.org>>
>>>> Subject: Re: [openstack][sharing][kolla ansible]Problems when 1 of 3 controller was be down
>>>>  
>>>> 
>>>> CAUTION: This email originates from outside THG
>>>> 
>>>> Are you proposing a solution or just raising an issue? 
>>>> 
>>>> I did find it strange that kolla-ansible doesn't support HA queue by default. That is a disaster because when one of the nodes goes down it will make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have to add HA policy to make queue HA otherwise you will endup in problem. 
>>>> 
>>>> On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> wrote:
>>>> Hello everyone.
>>>> 
>>>> I want to summary for who meets problems with Openstack when deploy cluster with 3 controller using Kolla Ansible
>>>> 
>>>> Scenario: 1 of 3 controller is down
>>>> 
>>>> 1. Login horizon and use API such as nova, cinder will be very slow
>>>> 
>>>> fix by:
>>>> 
>>>> nano:
>>>> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
>>>> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
>>>> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
>>>> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
>>>> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
>>>> 
>>>> or which service need caches
>>>>  
>>>> add as below
>>>> 
>>>> [cache]
>>>> backend = oslo_cache.memcache_pool
>>>> enabled = True
>>>> memcache_servers = {{ kolla_internal_vip_address }}:{{ memcached_port }}
>>>> memcache_dead_retry = 0.25
>>>> memcache_socket_timeout = 900
>>>> 
>>>> https://review.opendev.org/c/openstack/kolla-ansible/+/849487
>>>> 
>>>> but it is not the end
>>>> 
>>>> 2. Cannot launch instance or mapping block device(stuck at this step)
>>>> 
>>>> nano kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
>>>>   
>>>> "policies":[
>>>>     {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
>>>>     {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all", "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"}, "priority":0}
>>>>     {% endif %}
>>>>   ]
>>>> 
>>>> nano /etc/kollla/global.conf
>>>> 
>>>> [oslo_messaging_rabbit]
>>>> kombu_reconnect_delay=0.5
>>>> 
>>>> 
>>>> https://bugs.launchpad.net/oslo.messaging/+bug/1993149
>>>> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
>>>> 
>>>> I used Xena 13.4 and Yoga 14.8.1.
>>>> 
>>>> Above bugs are critical, but I see that it was not fixed. I am just an operator and I want to share what I encountered for new people who come to Openstack
>>>> 
>>>> 
>>>> Nguyen Huu Khoi
>> -- 
>> Micha? Nasiadka
>> mnasiadka at gmail.com <mailto:mnasiadka at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/e63d354a/attachment.htm>

From kennelson11 at gmail.com  Tue Apr 11 15:44:57 2023
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Tue, 11 Apr 2023 10:44:57 -0500
Subject: In Person PTG June 2023 Teams List
Message-ID: <CAJ6yrQjNMaU7Gx_kmCk0r-20_WZgEapPpwDe8nmcUi2NhZyKZw@mail.gmail.com>

Hello Everyone!

The June 2023 Project Teams List is official!

Projects + Teams

   - OpenInfra Foundation Teams
   -
      - Diversity & Inclusion Working Group
      - Environmental Sustainability Working Group
      - Kata Containers
      - StarlingX
   - OpenStack
   -
      - Service Teams
      -
         - Cinder
         - Cyborg
         - Designate
         - Heat
         - Ironic
         - Keystone
         - Manila
         - Neutron
         - Nova
         - OpenStack-Ansible
         - Puppet OpenStack
         - QA
         - SDK/CLI/AOC
         - Tacker
         - Telemetry
      - Other OpenStack Teams
      -
         - Security SIG
         - Technical Committee
         - Scientific SIG


If your team was planning to meet and isn?t in this list, please contact
ptg at openinfra.dev IMMEDIATELY.

In a couple weeks,  I will be contacting moderators to sign up for time via
the PTGBot[1] once I have it configured for the teams that are signed up to
attend the event.

Otherwise, please don't forget to register[2] ? prices go up May 5th!

Thanks!
-Kendall (diablo_rojo)

[1] PTGBot Docs:
https://github.com/openstack/ptgbot#open-infrastructure-ptg-bot
[2] PTG Registration: https://vancouver2023.openinfra.dev/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/3483a527/attachment-0001.htm>

From gmann at ghanshyammann.com  Tue Apr 11 17:28:11 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Tue, 11 Apr 2023 10:28:11 -0700
Subject: [ptl] Need PTL volunteer for OpenStack Winstackers
In-Reply-To: <2832840.mvXUDI8C0e@p1>
References: <1870a6b7a1d.114e70a2d994244.3514791188773000084@ghanshyammann.com>
 <1873468752c.bf93124c180931.3029567703559224707@ghanshyammann.com>
 <CAL_crJQn0h0w4zyCV_HLZrYQ4YwsKwVzcbtGAxzdN8REx06g+w@mail.gmail.com>
 <2832840.mvXUDI8C0e@p1>
Message-ID: <187715c5f64.10fd9250b398749.6791795632701673310@ghanshyammann.com>

 ---- On Tue, 11 Apr 2023 02:01:38 -0700  Slawek Kaplonski  wrote --- 
 > Hi,
 > 
 > Dnia wtorek, 11 kwietnia 2023 10:49:44 CEST Takashi Kajinami pisze:
 > > This probably causes a bit wider effect than just retiring the winstackers
 > > project.
 > > 
 > > I see some projects (cinde, designate, glance and os-brick) depend on
 > > os-win which is under
 > > governance of winstackers and will be retired. Also, even some more
 > > projects (Neutron, os-vif,
 > > ovsdbapp, oslo.log, etc) supports windows without os-win.
 > > 
 > > If we retire Winstackers, then is it reasonable to remove all
 > > implementations to support Windows ?
 > 
 > That's very good question IMO. And, from Neutron perspective very important according to the removal of netifaces dependency - it would be much easier to remove it by removing all "windows" module from Neutron repo rather than refactoring it.

I agree. Thanks, Takashi for raising it. 

If we retire Winstackers then yes, it means all dependencies of any functionality (user-facing or internal)
need to be removed also. This is not a good situation for us as window support of OpenStack, if I am
not wrong, Cloudbase is the only company maintaining and supporting the window support since starting.
If there is any company having their customer based on windows then this is the right time to step up and help
in maintaining this project. Otherway (based on project wants and have the bandwidth) is to implement the
alternate way in projects for window support (the one you mentioned has window support ).

-gmann

 > 
 > > 
 > > 
 > > 
 > > On Fri, Mar 31, 2023 at 6:29?AM Ghanshyam Mann gmann at ghanshyammann.com>
 > > wrote:
 > > 
 > > > Thanks, Lucian, for the updates and email link.
 > > >
 > > > As the next step, we will discuss it in TC and take the next action.
 > > >
 > > > -gmann
 > > >
 > > >  ---- On Thu, 30 Mar 2023 00:11:38 -0700  Lucian Petrut  wrote ---
 > > >  > Hi,
 > > >  > Thanks for reaching out. As mentioned here [1], Cloudbase Solutions can
 > > > no longer lead the Winstackers project. Since there weren?t any other
 > > > interested parties, I think there?s no other option but to retire the
 > > > project.
 > > >  > [1]
 > > > https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html
 > > >  > Regards,Lucian Petrut
 > > >  >
 > > >  > On 22 Mar 2023, at 19:43, Ghanshyam Mann gmann at ghanshyammann.com>
 > > > wrote:
 > > >  > Hi Lukas,
 > > >  >
 > > >  > I am reaching out to you as you were PTL for OpenStack Winstackers
 > > > project in the last cycle.
 > > >  >
 > > >  > There is no PTL candidate for the next cycle (2023.2), and it is on the
 > > > leaderless project list. Please
 > > >  > check if you or anyone you know would like to lead this project.
 > > >  >
 > > >  > - https://etherpad.opendev.org/p/2023.2-leaderless
 > > >  >
 > > >  > Also, if anyone else would like to help leading this project, this is
 > > > time to let TC knows.
 > > >  >
 > > >  > -gmann
 > > >  >
 > > >  >
 > > >
 > > >
 > > 
 > 
 > 
 > -- 
 > Slawek Kaplonski
 > Principal Software Engineer
 > Red Hat


From tkajinam at redhat.com  Wed Apr 12 01:32:40 2023
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Wed, 12 Apr 2023 10:32:40 +0900
Subject: [ptl] Need PTL volunteer for OpenStack Winstackers
In-Reply-To: <187715c5f64.10fd9250b398749.6791795632701673310@ghanshyammann.com>
References: <1870a6b7a1d.114e70a2d994244.3514791188773000084@ghanshyammann.com>
 <1873468752c.bf93124c180931.3029567703559224707@ghanshyammann.com>
 <CAL_crJQn0h0w4zyCV_HLZrYQ4YwsKwVzcbtGAxzdN8REx06g+w@mail.gmail.com>
 <2832840.mvXUDI8C0e@p1>
 <187715c5f64.10fd9250b398749.6791795632701673310@ghanshyammann.com>
Message-ID: <CAL_crJSDDiwhcG_eLUefJ_UEaM7avtGEA-KzS4e3oi+cnie9Xw@mail.gmail.com>

On Wed, Apr 12, 2023 at 2:28?AM Ghanshyam Mann <gmann at ghanshyammann.com>
wrote:

>  ---- On Tue, 11 Apr 2023 02:01:38 -0700  Slawek Kaplonski  wrote ---
>  > Hi,
>  >
>  > Dnia wtorek, 11 kwietnia 2023 10:49:44 CEST Takashi Kajinami pisze:
>  > > This probably causes a bit wider effect than just retiring the
> winstackers
>  > > project.
>  > >
>  > > I see some projects (cinde, designate, glance and os-brick) depend on
>  > > os-win which is under
>  > > governance of winstackers and will be retired. Also, even some more
>  > > projects (Neutron, os-vif,
>  > > ovsdbapp, oslo.log, etc) supports windows without os-win.
>  > >
>  > > If we retire Winstackers, then is it reasonable to remove all
>  > > implementations to support Windows ?
>  >
>  > That's very good question IMO. And, from Neutron perspective very
> important according to the removal of netifaces dependency - it would be
> much easier to remove it by removing all "windows" module from Neutron repo
> rather than refactoring it.
>
> I agree. Thanks, Takashi for raising it.
>
> If we retire Winstackers then yes, it means all dependencies of any
> functionality (user-facing or internal)
> need to be removed also. This is not a good situation for us as window
> support of OpenStack, if I am
> not wrong, Cloudbase is the only company maintaining and supporting the
> window support since starting.
> If there is any company having their customer based on windows then this
> is the right time to step up and help
> in maintaining this project. Otherway (based on project wants and have the
> bandwidth) is to implement the
> alternate way in projects for window support (the one you mentioned has
> window support ).
>
> Please correct me if I'm wrong but what cloudbase has been maintaining is
support for windows *guest*
instead of windows *host. *My previous question was about Windows host
support (whether we can remove
all implementations to run OpenStack services in windows hosts, instead of
linux hosts) and guest support
can be kept now.


> -gmann
>
>  >
>  > >
>  > >
>  > >
>  > > On Fri, Mar 31, 2023 at 6:29?AM Ghanshyam Mann
> gmann at ghanshyammann.com>
>  > > wrote:
>  > >
>  > > > Thanks, Lucian, for the updates and email link.
>  > > >
>  > > > As the next step, we will discuss it in TC and take the next action.
>  > > >
>  > > > -gmann
>  > > >
>  > > >  ---- On Thu, 30 Mar 2023 00:11:38 -0700  Lucian Petrut  wrote ---
>  > > >  > Hi,
>  > > >  > Thanks for reaching out. As mentioned here [1], Cloudbase
> Solutions can
>  > > > no longer lead the Winstackers project. Since there weren?t any
> other
>  > > > interested parties, I think there?s no other option but to retire
> the
>  > > > project.
>  > > >  > [1]
>  > > >
> https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html
>  > > >  > Regards,Lucian Petrut
>  > > >  >
>  > > >  > On 22 Mar 2023, at 19:43, Ghanshyam Mann gmann at ghanshyammann.com
> >
>  > > > wrote:
>  > > >  > Hi Lukas,
>  > > >  >
>  > > >  > I am reaching out to you as you were PTL for OpenStack
> Winstackers
>  > > > project in the last cycle.
>  > > >  >
>  > > >  > There is no PTL candidate for the next cycle (2023.2), and it is
> on the
>  > > > leaderless project list. Please
>  > > >  > check if you or anyone you know would like to lead this project.
>  > > >  >
>  > > >  > - https://etherpad.opendev.org/p/2023.2-leaderless
>  > > >  >
>  > > >  > Also, if anyone else would like to help leading this project,
> this is
>  > > > time to let TC knows.
>  > > >  >
>  > > >  > -gmann
>  > > >  >
>  > > >  >
>  > > >
>  > > >
>  > >
>  >
>  >
>  > --
>  > Slawek Kaplonski
>  > Principal Software Engineer
>  > Red Hat
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/40b038cb/attachment.htm>

From satish.txt at gmail.com  Wed Apr 12 02:45:13 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Tue, 11 Apr 2023 22:45:13 -0400
Subject: [kolla-ansible][mariadb] socat: Connection reset by peer
Message-ID: <CAPgF-fp7eZa+Hn6CEUvt7fw=S4PQsKmNuuy8+evp8oEBoQWuBA@mail.gmail.com>

Folks,

I am getting the following errors in logs constantly and continually. I
have 3 node galera clusters. Everything looks good except this error making
me nervous. I have deployed Zed release of kolla openstack.

==> /var/log/kolla/mariadb/mariadb-clustercheck.log <==
2023/04/12 02:42:16 socat[1574755] W read(7, 0x5653c4a4c000, 8192):
Connection reset by peer
2023/04/12 02:42:16 socat[1574761] W read(7, 0x5653c4a4c000, 8192):
Connection reset by peer
2023/04/12 02:42:16 socat[1574755] W read(6, 0x5653c4a4c000, 8192):
Connection reset by peer
2023/04/12 02:42:16 socat[1574761] W read(6, 0x5653c4a4c000, 8192):
Connection reset by peer
2023/04/12 02:42:18 socat[1574767] W read(7, 0x5653c4a4c000, 8192):
Connection reset by peer
2023/04/12 02:42:18 socat[1574767] W read(6, 0x5653c4a4c000, 8192):
Connection reset by peer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/bd79fa4c/attachment.htm>

From alsotoes at gmail.com  Wed Apr 12 03:07:24 2023
From: alsotoes at gmail.com (Alvaro Soto)
Date: Tue, 11 Apr 2023 21:07:24 -0600
Subject: [kolla-ansible][mariadb] socat: Connection reset by peer
In-Reply-To: <CAPgF-fp7eZa+Hn6CEUvt7fw=S4PQsKmNuuy8+evp8oEBoQWuBA@mail.gmail.com>
References: <CAPgF-fp7eZa+Hn6CEUvt7fw=S4PQsKmNuuy8+evp8oEBoQWuBA@mail.gmail.com>
Message-ID: <CA+eLJkaeY4Gb8Gk7wVZg4sbU-zcdJjpfYFd__-Y_6B7t_uGwrg@mail.gmail.com>

Hey,
I don't have too much kolla hands-on experience, but it'll be nice if you
can post SOCAT configurations, specific to the MySQL health check.
Also, the number 8192 is the default maximum connection value; could you
check if you are hitting that limit?

Cheers!

On Tue, Apr 11, 2023 at 8:49?PM Satish Patel <satish.txt at gmail.com> wrote:

> Folks,
>
> I am getting the following errors in logs constantly and continually. I
> have 3 node galera clusters. Everything looks good except this error making
> me nervous. I have deployed Zed release of kolla openstack.
>
> ==> /var/log/kolla/mariadb/mariadb-clustercheck.log <==
> 2023/04/12 02:42:16 socat[1574755] W read(7, 0x5653c4a4c000, 8192):
> Connection reset by peer
> 2023/04/12 02:42:16 socat[1574761] W read(7, 0x5653c4a4c000, 8192):
> Connection reset by peer
> 2023/04/12 02:42:16 socat[1574755] W read(6, 0x5653c4a4c000, 8192):
> Connection reset by peer
> 2023/04/12 02:42:16 socat[1574761] W read(6, 0x5653c4a4c000, 8192):
> Connection reset by peer
> 2023/04/12 02:42:18 socat[1574767] W read(7, 0x5653c4a4c000, 8192):
> Connection reset by peer
> 2023/04/12 02:42:18 socat[1574767] W read(6, 0x5653c4a4c000, 8192):
> Connection reset by peer
>


-- 

Alvaro Soto

*Note: My work hours may not be your work hours. Please do not feel the
need to respond during a time that is not convenient for you.*
----------------------------------------------------------
Great people talk about ideas,
ordinary people talk about things,
small people talk... about other people.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/7b8b0771/attachment-0001.htm>

From kkloppenborg at rwts.com.au  Wed Apr 12 06:19:58 2023
From: kkloppenborg at rwts.com.au (Karl Kloppenborg)
Date: Wed, 12 Apr 2023 06:19:58 +0000
Subject: CYBORG HTTP400 create trait OWNER_CYBORG
Message-ID: <TY2PR0101MB22086EDAAAFFFEED8A7F0E54F49B9@TY2PR0101MB2208.apcprd01.prod.exchangelabs.com>

Hi Cyborg Team,
Karl from the Openstack-Helm group.

I?ve hit a really an issue I cannot seem to overcome, Cyborg is detecting GPU Profiles from a NVIDIA A40, and it goes to create the record but cyborg-conductor errors with
```
[cyborg-conductor-6fc477ff8b-cw5lf cyborg-conductor] 2023-04-12 06:17:37.581 1 INFO cyborg.conductor.manager [None req-600fcdcf-a620-466a-ba6c-cdfbf6bf83e2 - - - - - -] Failed to add device DriverDevice(controlpath_id=DriverControlPathID,created_at=<?>,deployable_list=[DriverDeployable],model='NVIDIA Corporation Device',std_board_info='{"product_id": "2235", "controller": "3D controller"}',stub=False,type='GPU',updated_at=<?>,vendor='10de',vendor_board_info='{"vendor_info": "gpu_vb_info"}'). Reason: Failed to create trait OWNER_CYBORG: HTTP 400: {"errors": [{"status": 400, "title": "Bad Request", "detail": "The server could not comply with the request since it is either malformed or otherwise incorrect.\n\n The trait is invalid. A valid trait must be no longer than 255 characters, start with the prefix \"CUSTOM_\" and use following characters: \"A\"-\"Z\", \"0\"-\"9\" and \"_\"  ", "request_id": "req-24634fad-b312-4ad3-9482-09d6df2b26c2"}]}
```

It appears Cyborg is attempting to create the trait OWNER_CYBORG but I cannot seem to get it to stop that, can I please have some assistance from the Cyborg team to overcome this?

Kind Regards,
--
Karl Kloppenborg, (BCompSc, CNCF-[KCNA, CKA, CKAD], LFCE, CompTIA Linux+ XK0-004)
Managing Director, Invention Labs.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/1f0136aa/attachment.htm>

From smooney at redhat.com  Wed Apr 12 06:50:51 2023
From: smooney at redhat.com (Sean Mooney)
Date: Wed, 12 Apr 2023 07:50:51 +0100
Subject: [ptl] Need PTL volunteer for OpenStack Winstackers
In-Reply-To: <CAL_crJSDDiwhcG_eLUefJ_UEaM7avtGEA-KzS4e3oi+cnie9Xw@mail.gmail.com>
References: <1870a6b7a1d.114e70a2d994244.3514791188773000084@ghanshyammann.com>
 <1873468752c.bf93124c180931.3029567703559224707@ghanshyammann.com>
 <CAL_crJQn0h0w4zyCV_HLZrYQ4YwsKwVzcbtGAxzdN8REx06g+w@mail.gmail.com>
 <2832840.mvXUDI8C0e@p1>
 <187715c5f64.10fd9250b398749.6791795632701673310@ghanshyammann.com>
 <CAL_crJSDDiwhcG_eLUefJ_UEaM7avtGEA-KzS4e3oi+cnie9Xw@mail.gmail.com>
Message-ID: <CAHmFs2VaHmZF+yUgfWhxXyDZh2951h1d9TJjPOxYwKVUsG=HRQ@mail.gmail.com>

On Wed, Apr 12, 2023 at 2:42?AM Takashi Kajinami <tkajinam at redhat.com> wrote:
>
>
>
> On Wed, Apr 12, 2023 at 2:28?AM Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
>>
>>  ---- On Tue, 11 Apr 2023 02:01:38 -0700  Slawek Kaplonski  wrote ---
>>  > Hi,
>>  >
>>  > Dnia wtorek, 11 kwietnia 2023 10:49:44 CEST Takashi Kajinami pisze:
>>  > > This probably causes a bit wider effect than just retiring the winstackers
>>  > > project.
>>  > >
>>  > > I see some projects (cinde, designate, glance and os-brick) depend on
>>  > > os-win which is under
>>  > > governance of winstackers and will be retired. Also, even some more
>>  > > projects (Neutron, os-vif,
>>  > > ovsdbapp, oslo.log, etc) supports windows without os-win.
>>  > >
>>  > > If we retire Winstackers, then is it reasonable to remove all
>>  > > implementations to support Windows ?
>>  >
>>  > That's very good question IMO. And, from Neutron perspective very important according to the removal of netifaces dependency - it would be much easier to remove it by removing all "windows" module from Neutron repo rather than refactoring it.
>>
>> I agree. Thanks, Takashi for raising it.
>>
>> If we retire Winstackers then yes, it means all dependencies of any functionality (user-facing or internal)
>> need to be removed also. This is not a good situation for us as window support of OpenStack, if I am
>> not wrong, Cloudbase is the only company maintaining and supporting the window support since starting.
>> If there is any company having their customer based on windows then this is the right time to step up and help
>> in maintaining this project. Otherway (based on project wants and have the bandwidth) is to implement the
>> alternate way in projects for window support (the one you mentioned has window support ).
>>
> Please correct me if I'm wrong but what cloudbase has been maintaining is support for windows guest
> instead of windows host.
that is incorrect cloudbase provide the third party ci that test
deploying openstack compute nodes on windows.
that is the in/out of tree hyperV virt driver and the ovs on windows
supprot used with os-vif and neuton ml2/ovs plugsins on windows.

while we are happy to review fixes for hyper v /windows hows we now no
longer have any way to test these changes in ci ro locally as we
don't have a maintained way to deploy devstack on hyper v/windows hosts.

out side fo the cloud base init package which is optional there is no
depency on cloudbase to support windows guest.
that is unaffected. but windows host support is now effectivly
unmainated and untested.

> My previous question was about Windows host support (whether we can remove
> all implementations to run OpenStack services in windows hosts, instead of linux hosts) and guest support
> can be kept now.
>
>>
>> -gmann
>>
>>  >
>>  > >
>>  > >
>>  > >
>>  > > On Fri, Mar 31, 2023 at 6:29?AM Ghanshyam Mann gmann at ghanshyammann.com>
>>  > > wrote:
>>  > >
>>  > > > Thanks, Lucian, for the updates and email link.
>>  > > >
>>  > > > As the next step, we will discuss it in TC and take the next action.
>>  > > >
>>  > > > -gmann
>>  > > >
>>  > > >  ---- On Thu, 30 Mar 2023 00:11:38 -0700  Lucian Petrut  wrote ---
>>  > > >  > Hi,
>>  > > >  > Thanks for reaching out. As mentioned here [1], Cloudbase Solutions can
>>  > > > no longer lead the Winstackers project. Since there weren?t any other
>>  > > > interested parties, I think there?s no other option but to retire the
>>  > > > project.
>>  > > >  > [1]
>>  > > > https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html
>>  > > >  > Regards,Lucian Petrut
>>  > > >  >
>>  > > >  > On 22 Mar 2023, at 19:43, Ghanshyam Mann gmann at ghanshyammann.com>
>>  > > > wrote:
>>  > > >  > Hi Lukas,
>>  > > >  >
>>  > > >  > I am reaching out to you as you were PTL for OpenStack Winstackers
>>  > > > project in the last cycle.
>>  > > >  >
>>  > > >  > There is no PTL candidate for the next cycle (2023.2), and it is on the
>>  > > > leaderless project list. Please
>>  > > >  > check if you or anyone you know would like to lead this project.
>>  > > >  >
>>  > > >  > - https://etherpad.opendev.org/p/2023.2-leaderless
>>  > > >  >
>>  > > >  > Also, if anyone else would like to help leading this project, this is
>>  > > > time to let TC knows.
>>  > > >  >
>>  > > >  > -gmann
>>  > > >  >
>>  > > >  >
>>  > > >
>>  > > >
>>  > >
>>  >
>>  >
>>  > --
>>  > Slawek Kaplonski
>>  > Principal Software Engineer
>>  > Red Hat
>>



From skaplons at redhat.com  Wed Apr 12 07:03:37 2023
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Wed, 12 Apr 2023 09:03:37 +0200
Subject: [ptl] Need PTL volunteer for OpenStack Winstackers
In-Reply-To: <CAHmFs2VaHmZF+yUgfWhxXyDZh2951h1d9TJjPOxYwKVUsG=HRQ@mail.gmail.com>
References: <1870a6b7a1d.114e70a2d994244.3514791188773000084@ghanshyammann.com>
 <CAL_crJSDDiwhcG_eLUefJ_UEaM7avtGEA-KzS4e3oi+cnie9Xw@mail.gmail.com>
 <CAHmFs2VaHmZF+yUgfWhxXyDZh2951h1d9TJjPOxYwKVUsG=HRQ@mail.gmail.com>
Message-ID: <2682938.mvXUDI8C0e@p1>

Hi,

Dnia ?roda, 12 kwietnia 2023 08:50:51 CEST Sean Mooney pisze:
> On Wed, Apr 12, 2023 at 2:42?AM Takashi Kajinami <tkajinam at redhat.com> wrote:
> >
> >
> >
> > On Wed, Apr 12, 2023 at 2:28?AM Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
> >>
> >>  ---- On Tue, 11 Apr 2023 02:01:38 -0700  Slawek Kaplonski  wrote ---
> >>  > Hi,
> >>  >
> >>  > Dnia wtorek, 11 kwietnia 2023 10:49:44 CEST Takashi Kajinami pisze:
> >>  > > This probably causes a bit wider effect than just retiring the winstackers
> >>  > > project.
> >>  > >
> >>  > > I see some projects (cinde, designate, glance and os-brick) depend on
> >>  > > os-win which is under
> >>  > > governance of winstackers and will be retired. Also, even some more
> >>  > > projects (Neutron, os-vif,
> >>  > > ovsdbapp, oslo.log, etc) supports windows without os-win.
> >>  > >
> >>  > > If we retire Winstackers, then is it reasonable to remove all
> >>  > > implementations to support Windows ?
> >>  >
> >>  > That's very good question IMO. And, from Neutron perspective very important according to the removal of netifaces dependency - it would be much easier to remove it by removing all "windows" module from Neutron repo rather than refactoring it.
> >>
> >> I agree. Thanks, Takashi for raising it.
> >>
> >> If we retire Winstackers then yes, it means all dependencies of any functionality (user-facing or internal)
> >> need to be removed also. This is not a good situation for us as window support of OpenStack, if I am
> >> not wrong, Cloudbase is the only company maintaining and supporting the window support since starting.
> >> If there is any company having their customer based on windows then this is the right time to step up and help
> >> in maintaining this project. Otherway (based on project wants and have the bandwidth) is to implement the
> >> alternate way in projects for window support (the one you mentioned has window support ).
> >>
> > Please correct me if I'm wrong but what cloudbase has been maintaining is support for windows guest
> > instead of windows host.
> that is incorrect cloudbase provide the third party ci that test
> deploying openstack compute nodes on windows.
> that is the in/out of tree hyperV virt driver and the ovs on windows
> supprot used with os-vif and neuton ml2/ovs plugsins on windows.

Exactly. In neutron we have ovs-agent related code to run it on windows host, like e.g.: https://github.com/openstack/neutron/tree/master/neutron/agent/windows

> 
> while we are happy to review fixes for hyper v /windows hows we now no
> longer have any way to test these changes in ci ro locally as we
> don't have a maintained way to deploy devstack on hyper v/windows hosts.
> 
> out side fo the cloud base init package which is optional there is no
> depency on cloudbase to support windows guest.
> that is unaffected. but windows host support is now effectivly
> unmainated and untested.
> 
> > My previous question was about Windows host support (whether we can remove
> > all implementations to run OpenStack services in windows hosts, instead of linux hosts) and guest support
> > can be kept now.
> >
> >>
> >> -gmann
> >>
> >>  >
> >>  > >
> >>  > >
> >>  > >
> >>  > > On Fri, Mar 31, 2023 at 6:29?AM Ghanshyam Mann gmann at ghanshyammann.com>
> >>  > > wrote:
> >>  > >
> >>  > > > Thanks, Lucian, for the updates and email link.
> >>  > > >
> >>  > > > As the next step, we will discuss it in TC and take the next action.
> >>  > > >
> >>  > > > -gmann
> >>  > > >
> >>  > > >  ---- On Thu, 30 Mar 2023 00:11:38 -0700  Lucian Petrut  wrote ---
> >>  > > >  > Hi,
> >>  > > >  > Thanks for reaching out. As mentioned here [1], Cloudbase Solutions can
> >>  > > > no longer lead the Winstackers project. Since there weren?t any other
> >>  > > > interested parties, I think there?s no other option but to retire the
> >>  > > > project.
> >>  > > >  > [1]
> >>  > > > https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html
> >>  > > >  > Regards,Lucian Petrut
> >>  > > >  >
> >>  > > >  > On 22 Mar 2023, at 19:43, Ghanshyam Mann gmann at ghanshyammann.com>
> >>  > > > wrote:
> >>  > > >  > Hi Lukas,
> >>  > > >  >
> >>  > > >  > I am reaching out to you as you were PTL for OpenStack Winstackers
> >>  > > > project in the last cycle.
> >>  > > >  >
> >>  > > >  > There is no PTL candidate for the next cycle (2023.2), and it is on the
> >>  > > > leaderless project list. Please
> >>  > > >  > check if you or anyone you know would like to lead this project.
> >>  > > >  >
> >>  > > >  > - https://etherpad.opendev.org/p/2023.2-leaderless
> >>  > > >  >
> >>  > > >  > Also, if anyone else would like to help leading this project, this is
> >>  > > > time to let TC knows.
> >>  > > >  >
> >>  > > >  > -gmann
> >>  > > >  >
> >>  > > >  >
> >>  > > >
> >>  > > >
> >>  > >
> >>  >
> >>  >
> >>  > --
> >>  > Slawek Kaplonski
> >>  > Principal Software Engineer
> >>  > Red Hat
> >>
> 
> 


-- 
Slawek Kaplonski
Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/2f6528fa/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: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/2f6528fa/attachment-0001.sig>

From christian.rohmann at inovex.de  Wed Apr 12 07:06:15 2023
From: christian.rohmann at inovex.de (Christian Rohmann)
Date: Wed, 12 Apr 2023 09:06:15 +0200
Subject: Does cinder-backup support multi-backend?
In-Reply-To: <CAARK8KTgRYDGG=ZsckZD_3-_yXR8NpHAzZa-4sT_m-iPto2KrQ@mail.gmail.com>
References: <CAJV_UBAwDcy7Adob712AVYa0uK0txsoJbi3U83Fjy2G6UFhyiQ@mail.gmail.com>
 <CABAODRfY9v6muyZw34yxk25npgFUc4LfTe594Ng8VUUXA334DQ@mail.gmail.com>
 <CABAODRd=ps4S8pPcHgSkpdyKzbwtkS6_YXzUZpx1dU71NXNDRg@mail.gmail.com>
 <CABAODRedjYcb0NDeemMHCfSMSiken=iaDQqpkQQVq57dE+XiaA@mail.gmail.com>
 <CABAODReU3fBhPi0co77y=2qXM+u1u8mVpH4XxRiXVoX12_hsnw@mail.gmail.com>
 <CAARK8KTgRYDGG=ZsckZD_3-_yXR8NpHAzZa-4sT_m-iPto2KrQ@mail.gmail.com>
Message-ID: <0966efa7-8b53-8b84-255d-cefaeddd0384@inovex.de>

Wondel, Kh?i,


On 06/04/2023 09:39, Rajat Dhasmana wrote:
> Currently configuring multiple cinder backup?backends is not supported.
> This was brought up in our last cinder meeting on 06 April, 2023[1].
> A spec was proposed to implement this[2] but there aren't?any patches 
> to implement this.
> Christian Rohmann (crohmann on IRC) has shown interest in this topic, 
> so probably you can contact him about the details and can collaborate 
> on the effort.
>
> [1] 
> https://meetings.opendev.org/irclogs/%23openstack-meeting-alt/%23openstack-meeting-alt.2023-04-05.log.html#t2023-04-05T14:50:24
> [2] https://review.opendev.org/c/openstack/cinder-specs/+/712301


I am just as interested as you to have this feature.
First to allow transitioning from one backup backend to another, but 
also to offer multiple "types" of backups.
One could i.e. be "onsite" the other "offsite".

I gladly rework the spec and propose it for Bobcat. But I do not have 
the capacity to implement this.
Yes, cinder itself and the already present support for different volume 
types could serve as some kind of blueprint, but having more than one 
type of backup storage likely is a little more complicated to implement 
and transition to as it first appears.

So what are your thoughts on the matter then?


Regards

Christian





From tkajinam at redhat.com  Wed Apr 12 07:09:51 2023
From: tkajinam at redhat.com (Takashi Kajinami)
Date: Wed, 12 Apr 2023 16:09:51 +0900
Subject: [ptl] Need PTL volunteer for OpenStack Winstackers
In-Reply-To: <CAHmFs2VaHmZF+yUgfWhxXyDZh2951h1d9TJjPOxYwKVUsG=HRQ@mail.gmail.com>
References: <1870a6b7a1d.114e70a2d994244.3514791188773000084@ghanshyammann.com>
 <1873468752c.bf93124c180931.3029567703559224707@ghanshyammann.com>
 <CAL_crJQn0h0w4zyCV_HLZrYQ4YwsKwVzcbtGAxzdN8REx06g+w@mail.gmail.com>
 <2832840.mvXUDI8C0e@p1>
 <187715c5f64.10fd9250b398749.6791795632701673310@ghanshyammann.com>
 <CAL_crJSDDiwhcG_eLUefJ_UEaM7avtGEA-KzS4e3oi+cnie9Xw@mail.gmail.com>
 <CAHmFs2VaHmZF+yUgfWhxXyDZh2951h1d9TJjPOxYwKVUsG=HRQ@mail.gmail.com>
Message-ID: <CAL_crJQSOkBvbtYtRXDJuS3PNXVJm_n00Yp2MnFXZYfSsXSXPw@mail.gmail.com>

On Wed, Apr 12, 2023 at 3:51?PM Sean Mooney <smooney at redhat.com> wrote:

> On Wed, Apr 12, 2023 at 2:42?AM Takashi Kajinami <tkajinam at redhat.com>
> wrote:
> >
> >
> >
> > On Wed, Apr 12, 2023 at 2:28?AM Ghanshyam Mann <gmann at ghanshyammann.com>
> wrote:
> >>
> >>  ---- On Tue, 11 Apr 2023 02:01:38 -0700  Slawek Kaplonski  wrote ---
> >>  > Hi,
> >>  >
> >>  > Dnia wtorek, 11 kwietnia 2023 10:49:44 CEST Takashi Kajinami pisze:
> >>  > > This probably causes a bit wider effect than just retiring the
> winstackers
> >>  > > project.
> >>  > >
> >>  > > I see some projects (cinde, designate, glance and os-brick) depend
> on
> >>  > > os-win which is under
> >>  > > governance of winstackers and will be retired. Also, even some more
> >>  > > projects (Neutron, os-vif,
> >>  > > ovsdbapp, oslo.log, etc) supports windows without os-win.
> >>  > >
> >>  > > If we retire Winstackers, then is it reasonable to remove all
> >>  > > implementations to support Windows ?
> >>  >
> >>  > That's very good question IMO. And, from Neutron perspective very
> important according to the removal of netifaces dependency - it would be
> much easier to remove it by removing all "windows" module from Neutron repo
> rather than refactoring it.
> >>
> >> I agree. Thanks, Takashi for raising it.
> >>
> >> If we retire Winstackers then yes, it means all dependencies of any
> functionality (user-facing or internal)
> >> need to be removed also. This is not a good situation for us as window
> support of OpenStack, if I am
> >> not wrong, Cloudbase is the only company maintaining and supporting the
> window support since starting.
> >> If there is any company having their customer based on windows then
> this is the right time to step up and help
> >> in maintaining this project. Otherway (based on project wants and have
> the bandwidth) is to implement the
> >> alternate way in projects for window support (the one you mentioned has
> window support ).
> >>
> > Please correct me if I'm wrong but what cloudbase has been maintaining
> is support for windows guest
> > instead of windows host.
> that is incorrect cloudbase provide the third party ci that test
> deploying openstack compute nodes on windows.
> that is the in/out of tree hyperV virt driver and the ovs on windows
> supprot used with os-vif and neuton ml2/ovs plugsins on windows.
>

Thanks.

I was confused by some conversation logs in #openstack-tc and it was indeed
mentioned cloudbase no longer maintains Winstackers (= Windows host support)
earlier in this thread.


> while we are happy to review fixes for hyper v /windows hows we now no
> longer have any way to test these changes in ci ro locally as we
> don't have a maintained way to deploy devstack on hyper v/windows hosts.
>
> out side fo the cloud base init package which is optional there is no
> depency on cloudbase to support windows guest.
> that is unaffected. but windows host support is now effectivly
> unmainated and untested.
>

I completely agree with this statement.


> > My previous question was about Windows host support (whether we can
> remove
> > all implementations to run OpenStack services in windows hosts, instead
> of linux hosts) and guest support
> > can be kept now.
> >
> >>
> >> -gmann
> >>
> >>  >
> >>  > >
> >>  > >
> >>  > >
> >>  > > On Fri, Mar 31, 2023 at 6:29?AM Ghanshyam Mann
> gmann at ghanshyammann.com>
> >>  > > wrote:
> >>  > >
> >>  > > > Thanks, Lucian, for the updates and email link.
> >>  > > >
> >>  > > > As the next step, we will discuss it in TC and take the next
> action.
> >>  > > >
> >>  > > > -gmann
> >>  > > >
> >>  > > >  ---- On Thu, 30 Mar 2023 00:11:38 -0700  Lucian Petrut  wrote
> ---
> >>  > > >  > Hi,
> >>  > > >  > Thanks for reaching out. As mentioned here [1], Cloudbase
> Solutions can
> >>  > > > no longer lead the Winstackers project. Since there weren?t any
> other
> >>  > > > interested parties, I think there?s no other option but to
> retire the
> >>  > > > project.
> >>  > > >  > [1]
> >>  > > >
> https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html
> >>  > > >  > Regards,Lucian Petrut
> >>  > > >  >
> >>  > > >  > On 22 Mar 2023, at 19:43, Ghanshyam Mann
> gmann at ghanshyammann.com>
> >>  > > > wrote:
> >>  > > >  > Hi Lukas,
> >>  > > >  >
> >>  > > >  > I am reaching out to you as you were PTL for OpenStack
> Winstackers
> >>  > > > project in the last cycle.
> >>  > > >  >
> >>  > > >  > There is no PTL candidate for the next cycle (2023.2), and it
> is on the
> >>  > > > leaderless project list. Please
> >>  > > >  > check if you or anyone you know would like to lead this
> project.
> >>  > > >  >
> >>  > > >  > - https://etherpad.opendev.org/p/2023.2-leaderless
> >>  > > >  >
> >>  > > >  > Also, if anyone else would like to help leading this project,
> this is
> >>  > > > time to let TC knows.
> >>  > > >  >
> >>  > > >  > -gmann
> >>  > > >  >
> >>  > > >  >
> >>  > > >
> >>  > > >
> >>  > >
> >>  >
> >>  >
> >>  > --
> >>  > Slawek Kaplonski
> >>  > Principal Software Engineer
> >>  > Red Hat
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/27ea0c79/attachment.htm>

From christian.rohmann at inovex.de  Wed Apr 12 07:14:40 2023
From: christian.rohmann at inovex.de (Christian Rohmann)
Date: Wed, 12 Apr 2023 09:14:40 +0200
Subject: [designate] Proposal to deprecate the agent framework and agent
 based backends
In-Reply-To: <CAMH0Mg+EX3vEKKX_BJCja4ePweWAkjTsc5rEvVoRSpERD7Pd5Q@mail.gmail.com>
References: <CAMH0MgJFtt_FJG3rWk7qyT=y_5ZUVrm1ZyTKOQ90T2R6hmBA5w@mail.gmail.com>
 <c8d3c12f-9807-11e1-582a-01c30e4a3f41@inovex.de>
 <CAMH0MgJAyyUyUgMM20+GLew_Tc-jXAEo9hDCfgtEqcQD2OVmQw@mail.gmail.com>
 <a43f7293-29c5-0c15-679c-7f794e976ae3@inovex.de>
 <CAMH0MgK_dPF4YfzGbkoykpupNXoF0mMrzWWTW8F49pC0K4Z6=w@mail.gmail.com>
 <16546577-07af-c24a-5ff6-c45eeeba9517@inovex.de>
 <CAMH0Mg+EX3vEKKX_BJCja4ePweWAkjTsc5rEvVoRSpERD7Pd5Q@mail.gmail.com>
Message-ID: <a259d4bc-9b17-259c-c9dd-07e450b209cc@inovex.de>

Hey Michael, all,

On 03/04/2023 20:51, Michael Johnson wrote:
>> I started a discussion internally about devoting some hours to at least
>> get this off the ground.
>> Does this spec need a "move" to Bobcat or other planning or acceptance
>> process to aim for that release instead of Antelope?
> The spec does not need to move. We are all set to start development
> when someone is ready to work on it.
>
>> And I am in no way asking for a fast-lane or special treatment. I would
>> just like to be able advertise this as:
>> "If we write the code, someone is going to look at it and helps to get
>> this merged for Bobcat."
> I think that is a fair statement. Just note that others in the
> community may not have a lot of time to co-develop on it.
>
We agreed to pick this up and implement the catalog zone support.
So expect a change to appear for review at some point ;-)


Regards


Christian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/7c59f240/attachment-0001.htm>

From ralonsoh at redhat.com  Wed Apr 12 07:24:51 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Wed, 12 Apr 2023 09:24:51 +0200
Subject: [neutron] Deprecation of the neutronclient CLI code
Message-ID: <CAECr9X6DYffC5aq_0MactTckMvmLUZ11XnNP2pN7Q_So50+7ag@mail.gmail.com>

Hello all:

Since this release [1], the python-neutronclient project will no longer
provide CLI support. Any Neutron related CLI command should be executed
using python-openstackclient (OSC). This deprecation and removal was
announced in [2] and was initially planned for Zed release. We have been
working during the last releases to finish the migration and provide all
the commands in OSC.

In case you find any missing command, argument or output, please open a bug
in the Neutron site of launchpad and we'll address it. You can also install
a previous (Antelope) version of neutronclient if you missed the migration
window.

The python-neutronclient will still be available to provide the Networking
API python bindings [3].

Regards.

[1]https://review.opendev.org/c/openstack/python-neutronclient/+/871711
[2]
https://docs.openstack.org/python-neutronclient/latest/contributor/transition_to_osc.html
[3]https://docs.openstack.org/python-neutronclient/ocata/usage/library.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/c669cdec/attachment.htm>

From eblock at nde.ag  Wed Apr 12 07:30:21 2023
From: eblock at nde.ag (Eugen Block)
Date: Wed, 12 Apr 2023 07:30:21 +0000
Subject: [Kolla-ansible][Yoga] Cannot live migrate VMs
In-Reply-To: <CAJV_UBDGYOJG8iuEbD3eELbvDHVyCmOv--w=oJ8h=iYF4vehXg@mail.gmail.com>
Message-ID: <20230412073021.Horde.F1lstMW1fv-TZnzECX76xx8@webmail.nde.ag>

Hi,

this seems to be related to cinder, do you see anything in the  
cinder-volume.log?

Zitat von wodel youchi <wodel.youchi at gmail.com>:

> Hi,
>
> I cannot live-migrate any VM I have.
> All my compute nodes are enabled. I have a few VMs, I am in the testing
> phase.
> I tried to live-migrate toward an empty node, then toward a node which
> already had a VM in it. It is the same problem.
>
> In the log files I have :
>
> Source node :
> Source
>
>> ==> /var/log/kolla/nova/nova-compute.log <==
>> 2023-04-09 11:32:49.419 7 INFO nova.compute.resource_tracker
>> [req-4e91d562-d7ad-4585-a827-3db6277fd81e - - - - -] [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Updating resource usage from
>> migration f60eb077-8e1c-404a-aca5-64e5609ca02c
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [-] [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Pre live migration failed at
>> computehci02: oslo_messaging.rpc.client.RemoteError: Remote error:
>> ClientException Gateway Time-out (HTTP 504)
>> ['Traceback (most recent call last):\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py",
>> line 165, in _process_incoming\n    res =
>> self.dispatcher.dispatch(message)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>> line 309, in dispatch\n    return self._do_dispatch(endpoint, method, ctxt,
>> args)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>> line 229, in _do_dispatch\n    result = func(ctxt, **new_args)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>> line 72, in wrapped\n    context, exc, binary)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise\n    raise self.value\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>> line 63, in wrapped\n    return f(self, context, *args, **kw)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py",
>> line 1439, in decorated_function\n    return function(self, context, *args,
>> **kwargs)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 213, in decorated_function\n    kwargs[\'instance\'], e,
>> sys.exc_info())\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise\n    raise self.value\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 201, in decorated_function\n    return function(self, context, *args,
>> **kwargs)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 8367, in pre_live_migration\n    bdm.save()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise\n    raise self.value\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 8304, in pre_live_migration\n    connector=connector,
>> mountpoint=bdm.device_name)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 395, in wrapper\n    res = method(self, ctx, *args, **kwargs)\n', '
>>  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 433, in wrapper\n    res = method(self, ctx, volume_id, *args,
>> **kwargs)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 813, in attachment_create\n    instance_uuid=instance_id)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise\n    raise self.value\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 801, in attachment_create\n    volume_id, _connector, instance_id)\n',
>> '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py",
>> line 421, in substitution\n    return method.func(obj, *args, **kwargs)\n',
>> '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py",
>> line 39, in create\n    retval = self._create(\'/attachments\', body,
>> \'attachment\')\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py",
>> line 306, in _create\n    resp, body = self.api.client.post(url,
>> body=body)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> line 227, in post\n    return self._cs_request(url, \'POST\', **kwargs)\n',
>> '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> line 215, in _cs_request\n    return self.request(url, method,
>> **kwargs)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> line 201, in request\n    raise exceptions.from_response(resp, body)\n',
>> 'cinderclient.exceptions.ClientException: Gateway Time-out (HTTP 504)\n'].
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Traceback (most recent call last):
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 8501, in _do_pre_live_migration_from_source
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     block_migration, disk, dest,
>> migrate_data)
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/rpcapi.py",
>> line 948, in pre_live_migration
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     **msg_args)
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/client.py",
>> line 192, in call
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     retry=self.retry,
>> transport_options=self.transport_options)
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/transport.py",
>> line 128, in _send
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
>> transport_options=transport_options)
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>> line 691, in send
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
>> transport_options=transport_options)
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>> line 681, in _send
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     raise result
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
>> oslo_messaging.rpc.client.RemoteError: Remote error: ClientException
>> Gateway Time-out (HTTP 504)
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] ['Traceback (most recent call
>> last):\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py",
>> line 165, in _process_incoming\n    res =
>> self.dispatcher.dispatch(message)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>> line 309, in dispatch\n    return self._do_dispatch(endpoint, method, ctxt,
>> args)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>> line 229, in _do_dispatch\n    result = func(ctxt, **new_args)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>> line 72, in wrapped\n    context, exc, binary)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise\n    raise self.value\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>> line 63, in wrapped\n    return f(self, context, *args, **kw)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py",
>> line 1439, in decorated_function\n    return function(self, context, *args,
>> **kwargs)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 213, in decorated_function\n    kwargs[\'instance\'], e,
>> sys.exc_info())\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise\n    raise self.value\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 201, in decorated_function\n    return function(self, context, *args,
>> **kwargs)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 8367, in pre_live_migration\n    bdm.save()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise\n    raise self.value\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 8304, in pre_live_migration\n    connector=connector,
>> mountpoint=bdm.device_name)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 395, in wrapper\n    res = method(self, ctx, *args, **kwargs)\n', '
>>  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 433, in wrapper\n    res = method(self, ctx, volume_id, *args,
>> **kwargs)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 813, in attachment_create\n    instance_uuid=instance_id)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise\n    raise self.value\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 801, in attachment_create\n    volume_id, _connector, instance_id)\n',
>> '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py",
>> line 421, in substitution\n    return method.func(obj, *args, **kwargs)\n',
>> '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py",
>> line 39, in create\n    retval = self._create(\'/attachments\', body,
>> \'attachment\')\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py",
>> line 306, in _create\n    resp, body = self.api.client.post(url,
>> body=body)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> line 227, in post\n    return self._cs_request(url, \'POST\', **kwargs)\n',
>> '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> line 215, in _cs_request\n    return self.request(url, method,
>> **kwargs)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> line 201, in request\n    raise exceptions.from_response(resp, body)\n',
>> 'cinderclient.exceptions.ClientException: Gateway Time-out (HTTP 504)\n'].
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
>> 2023-04-09 11:33:30.157 7 INFO nova.compute.manager [-] [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Swapping old allocation on
>> dict_keys(['2857ae62-3519-4b13-b700-858c827dd78d']) held by migration
>> f60eb077-8e1c-404a-aca5-64e5609ca02c for instance
>
>
>
> In the destination node :
>
>> nova-compute.log
>>
>>
>>
>>
>> *2023-04-09 11:32:30.052 7 WARNING os_brick.initiator.connectors.nvmeof
>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default default] Process execution error
>> in _get_host_uuid: Unexpected error while running command.Command: blkid
>> overlay -s UUID -o valueExit code: 2Stdout: ''Stderr: '':
>> oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while
>> running command.*
>>
>> 2023-04-09 11:33:05.354 7 INFO nova.compute.resource_tracker
>> [req-9d480442-87f7-4d4e-a866-c46d645ac7f2 - - - - -] [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Updating resource usage from
>> migration f60eb077-8e1c-404a-aca5-64e5609ca02c
>> 2023-04-09 11:33:05.392 7 WARNING nova.compute.resource_tracker
>> [req-9d480442-87f7-4d4e-a866-c46d645ac7f2 - - - - -] Instance
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7 has been moved to another host
>> computehci01(computehci01). There are allocations remaining against the
>> source host that might need to be removed: {'resources': {'VCPU': 1,
>> 'MEMORY_MB': 2048}}.
>> 2023-04-09 11:33:30.086 7 ERROR nova.volume.cinder
>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Create attachment failed for volume
>> 3d7bd0af-5e4c-48fc-a027-f6c9dd6280bb. Error: Gateway Time-out (HTTP 504)
>> Code: 504: cinderclient.exceptions.ClientException: Gateway Time-out (HTTP
>> 504)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default default] Exception during
>> message handling: cinderclient.exceptions.ClientException: Gateway Time-out
>> (HTTP 504)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server Traceback (most
>> recent call last):
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py",
>> line 165, in _process_incoming
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     res =
>> self.dispatcher.dispatch(message)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>> line 309, in dispatch
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> self._do_dispatch(endpoint, method, ctxt, args)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>> line 229, in _do_dispatch
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     result =
>> func(ctxt, **new_args)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>> line 72, in wrapped
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     context,
>> exc, binary)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> self.force_reraise()
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>> self.value
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>> line 63, in wrapped
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> f(self, context, *args, **kw)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py",
>> line 1439, in decorated_function
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> function(self, context, *args, **kwargs)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 213, in decorated_function
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> kwargs['instance'], e, sys.exc_info())
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> self.force_reraise()
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>> self.value
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 201, in decorated_function
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> function(self, context, *args, **kwargs)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 8367, in pre_live_migration
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     bdm.save()
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> self.force_reraise()
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>> self.value
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 8304, in pre_live_migration
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> connector=connector, mountpoint=bdm.device_name)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 395, in wrapper
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     res =
>> method(self, ctx, *args, **kwargs)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 433, in wrapper
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     res =
>> method(self, ctx, volume_id, *args, **kwargs)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 813, in attachment_create
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> instance_uuid=instance_id)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> self.force_reraise()
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>> self.value
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 801, in attachment_create
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     volume_id,
>> _connector, instance_id)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py",
>> line 421, in substitution
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> method.func(obj, *args, **kwargs)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py",
>> line 39, in create
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     retval =
>> self._create('/attachments', body, 'attachment')
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py",
>> line 306, in _create
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     resp, body =
>> self.api.client.post(url, body=body)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> line 227, in post
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> self._cs_request(url, 'POST', **kwargs)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> line 215, in _cs_request
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> self.request(url, method, **kwargs)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> line 201, in request
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>> exceptions.from_response(resp, body)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> cinderclient.exceptions.ClientException: Gateway Time-out (HTTP 504)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> 2023-04-09 11:33:30.238 7 INFO nova.virt.block_device
>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Attempting to driver detach volume
>> 3d7bd0af-5e4c-48fc-a027-f6c9dd6280bb from mountpoint /dev/vda
>> 2023-04-09 11:33:30.239 7 WARNING nova.virt.block_device
>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Detaching volume from unknown instance
>> 2023-04-09 11:33:30.240 7 WARNING nova.virt.libvirt.driver
>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] During detach_volume, instance
>> disappeared.: nova.exception.InstanceNotFound: Instance
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7 could not be found.
>> 2023-04-09 11:33:30.678 7 INFO nova.virt.libvirt.driver [-] [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Instance destroyed successfully.
>> 2023-04-09 11:33:30.682 7 INFO os_vif
>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default default] Successfully unplugged
>> vif
>> VIFBridge(active=True,address=fa:16:3e:9b:92:46,bridge_name='qbr46651303-65',has_traffic_filtering=True,id=46651303-65e1-4809-95cc-7c2d97acf16b,network=Network(532470c1-dd2f-4505-8557-ba24e9d4062b),plugin='ovs',port_profile=VIFPortProfileOpenVSwitch,preserve_on_delete=False,vif_name='tap46651303-65')
>>
>
> All I can see is
>
>
>
>
> *b0f76b5c6dcb457fa716762bbf954837 - default default] Process execution
> error in _get_host_uuid: Unexpected error while running command.Command:
> blkid overlay -s UUID -o valueExit code: 2Stdout: ''Stderr: '':
> oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while
> running command.*
>
> Searching the web I didn't find anything useful about this error, and I
> don't know if it's the origin of the problem.
>
> My default storage is ceph rbd, I have an HCI deployment, and all my VMs
> are for now created on Ceph only. But I have configured two other cinder
> backends, NFS and LVM, but they are node used for now.
>
> Thanks in advance.
>
> Regards.





From sbauza at redhat.com  Wed Apr 12 07:46:32 2023
From: sbauza at redhat.com (Sylvain Bauza)
Date: Wed, 12 Apr 2023 09:46:32 +0200
Subject: [ptl] Need PTL volunteer for OpenStack Winstackers
In-Reply-To: <CAHmFs2VaHmZF+yUgfWhxXyDZh2951h1d9TJjPOxYwKVUsG=HRQ@mail.gmail.com>
References: <1870a6b7a1d.114e70a2d994244.3514791188773000084@ghanshyammann.com>
 <1873468752c.bf93124c180931.3029567703559224707@ghanshyammann.com>
 <CAL_crJQn0h0w4zyCV_HLZrYQ4YwsKwVzcbtGAxzdN8REx06g+w@mail.gmail.com>
 <2832840.mvXUDI8C0e@p1>
 <187715c5f64.10fd9250b398749.6791795632701673310@ghanshyammann.com>
 <CAL_crJSDDiwhcG_eLUefJ_UEaM7avtGEA-KzS4e3oi+cnie9Xw@mail.gmail.com>
 <CAHmFs2VaHmZF+yUgfWhxXyDZh2951h1d9TJjPOxYwKVUsG=HRQ@mail.gmail.com>
Message-ID: <CALOCmunYewLhbN4Yu53fqRuuSGptKEtnd=5UxPNRxZDS_V+0Vg@mail.gmail.com>

Le mer. 12 avr. 2023 ? 08:56, Sean Mooney <smooney at redhat.com> a ?crit :

> On Wed, Apr 12, 2023 at 2:42?AM Takashi Kajinami <tkajinam at redhat.com>
> wrote:
> >
> >
> >
> > On Wed, Apr 12, 2023 at 2:28?AM Ghanshyam Mann <gmann at ghanshyammann.com>
> wrote:
> >>
> >>  ---- On Tue, 11 Apr 2023 02:01:38 -0700  Slawek Kaplonski  wrote ---
> >>  > Hi,
> >>  >
> >>  > Dnia wtorek, 11 kwietnia 2023 10:49:44 CEST Takashi Kajinami pisze:
> >>  > > This probably causes a bit wider effect than just retiring the
> winstackers
> >>  > > project.
> >>  > >
> >>  > > I see some projects (cinde, designate, glance and os-brick) depend
> on
> >>  > > os-win which is under
> >>  > > governance of winstackers and will be retired. Also, even some more
> >>  > > projects (Neutron, os-vif,
> >>  > > ovsdbapp, oslo.log, etc) supports windows without os-win.
> >>  > >
> >>  > > If we retire Winstackers, then is it reasonable to remove all
> >>  > > implementations to support Windows ?
> >>  >
> >>  > That's very good question IMO. And, from Neutron perspective very
> important according to the removal of netifaces dependency - it would be
> much easier to remove it by removing all "windows" module from Neutron repo
> rather than refactoring it.
> >>
> >> I agree. Thanks, Takashi for raising it.
> >>
> >> If we retire Winstackers then yes, it means all dependencies of any
> functionality (user-facing or internal)
> >> need to be removed also. This is not a good situation for us as window
> support of OpenStack, if I am
> >> not wrong, Cloudbase is the only company maintaining and supporting the
> window support since starting.
> >> If there is any company having their customer based on windows then
> this is the right time to step up and help
> >> in maintaining this project. Otherway (based on project wants and have
> the bandwidth) is to implement the
> >> alternate way in projects for window support (the one you mentioned has
> window support ).
> >>
> > Please correct me if I'm wrong but what cloudbase has been maintaining
> is support for windows guest
> > instead of windows host.
> that is incorrect cloudbase provide the third party ci that test
> deploying openstack compute nodes on windows.
> that is the in/out of tree hyperV virt driver and the ovs on windows
> supprot used with os-vif and neuton ml2/ovs plugsins on windows.
>
> while we are happy to review fixes for hyper v /windows hows we now no
> longer have any way to test these changes in ci ro locally as we
> don't have a maintained way to deploy devstack on hyper v/windows hosts.
>
> out side fo the cloud base init package which is optional there is no
> depency on cloudbase to support windows guest.
> that is unaffected. but windows host support is now effectivly
> unmainated and untested.
>
>
FWIW, the Nova project usually follows a procedure for virt drivers that
are no longer tested by a 3rd party CI.
If no maintainers can continue to verify that a in-tree virt driver won't
have any regression, then the Nova community deprecates the virt driver.

Here, that means that by a next release, we will deprecate Hyper-V virt
driver unless someone tells us that they can help.
-Sylvain (which will create a specific ML thread for it)

> My previous question was about Windows host support (whether we can remove
> > all implementations to run OpenStack services in windows hosts, instead
> of linux hosts) and guest support
> > can be kept now.
> >
> >>
> >> -gmann
> >>
> >>  >
> >>  > >
> >>  > >
> >>  > >
> >>  > > On Fri, Mar 31, 2023 at 6:29?AM Ghanshyam Mann
> gmann at ghanshyammann.com>
> >>  > > wrote:
> >>  > >
> >>  > > > Thanks, Lucian, for the updates and email link.
> >>  > > >
> >>  > > > As the next step, we will discuss it in TC and take the next
> action.
> >>  > > >
> >>  > > > -gmann
> >>  > > >
> >>  > > >  ---- On Thu, 30 Mar 2023 00:11:38 -0700  Lucian Petrut  wrote
> ---
> >>  > > >  > Hi,
> >>  > > >  > Thanks for reaching out. As mentioned here [1], Cloudbase
> Solutions can
> >>  > > > no longer lead the Winstackers project. Since there weren?t any
> other
> >>  > > > interested parties, I think there?s no other option but to
> retire the
> >>  > > > project.
> >>  > > >  > [1]
> >>  > > >
> https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html
> >>  > > >  > Regards,Lucian Petrut
> >>  > > >  >
> >>  > > >  > On 22 Mar 2023, at 19:43, Ghanshyam Mann
> gmann at ghanshyammann.com>
> >>  > > > wrote:
> >>  > > >  > Hi Lukas,
> >>  > > >  >
> >>  > > >  > I am reaching out to you as you were PTL for OpenStack
> Winstackers
> >>  > > > project in the last cycle.
> >>  > > >  >
> >>  > > >  > There is no PTL candidate for the next cycle (2023.2), and it
> is on the
> >>  > > > leaderless project list. Please
> >>  > > >  > check if you or anyone you know would like to lead this
> project.
> >>  > > >  >
> >>  > > >  > - https://etherpad.opendev.org/p/2023.2-leaderless
> >>  > > >  >
> >>  > > >  > Also, if anyone else would like to help leading this project,
> this is
> >>  > > > time to let TC knows.
> >>  > > >  >
> >>  > > >  > -gmann
> >>  > > >  >
> >>  > > >  >
> >>  > > >
> >>  > > >
> >>  > >
> >>  >
> >>  >
> >>  > --
> >>  > Slawek Kaplonski
> >>  > Principal Software Engineer
> >>  > Red Hat
> >>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/0a7eac76/attachment.htm>

From mattc at stackhpc.com  Wed Apr 12 08:20:58 2023
From: mattc at stackhpc.com (Matt Crees)
Date: Wed, 12 Apr 2023 09:20:58 +0100
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
Message-ID: <CAHsN3DO5jMQPtxz2yUdWa=jjgG3Y3Y6GDcJQmmtpQVNkSwh55Q@mail.gmail.com>

Hi all,

It seems worth noting here that there is a fix ongoing in
oslo.messaging which will resolve the issues with HA failing when one
node is down. See here:
https://review.opendev.org/c/openstack/oslo.messaging/+/866617
In the meantime, we have also found that setting kombu_reconnect_delay
= 0.5 does resolve this issue.

As for why om_enable_rabbitmq_high_availability is currently
defaulting to false, as Michal said enabling it in stable releases
will impact users. This is because it enables durable queues, and the
migration from transient to durable queues is not a seamless
procedure. It requires that the state of RabbitMQ is reset and that
the OpenStack services which use RabbitMQ are restarted to recreate
the queues.

I think that there is some merit in changing this default value. But
if we did this, we should either add additional support to automate
the migration from transient to durable queues, or at the very least
provide some decent docs on the manual procedure.

However, as classic queue mirroring is deprecated in RabbitMQ (to be
removed in RabbitMQ 4.0) we should maybe consider switching to quorum
queues soon. Then it may be beneficial to leave the classic queue
mirroring + durable queues setup as False by default. This is because
the migration between queue types (durable or quorum) can take several
hours on larger deployments. So it might be worth making sure the
default values only require one migration to quorum queues in the
future, rather than two (durable queues now and then quorum queues in
the future).

We will need to make this switch eventually, but right now RabbitMQ
4.0 does not even have a set release date, so it's not the most urgent
change.

Cheers,
Matt

>Hi Michal,
>
>Feel free to propose change of default in master branch, but I don?t think we can change the default in stable branches without impacting users.
>
>Best regards,
>Michal
>
>> On 11 Apr 2023, at 15:18, Michal Arbet <michal.arbet at ultimum.io> wrote:
>>
>> Hi,
>>
>> Btw, why we have such option set to false ?
>> Michal Arbet
>> Openstack Engineer
>>
>> Ultimum Technologies a.s.
>> Na Po???? 1047/26, 11000 Praha 1
>> Czech Republic
>>
>> +420 604 228 897 <>
>> michal.arbet at ultimum.io <mailto:michal.arbet at ultimum.io>
>> https://ultimum.io <https://ultimum.io/>
>>
>> LinkedIn <https://www.linkedin.com/company/ultimum-technologies> | Twitter <https://twitter.com/ultimumtech> | Facebook <https://www.facebook.com/ultimumtechnologies/timeline>
>>
>>
>> ?t 11. 4. 2023 v 14:48 odes?latel Micha? Nasiadka <mnasiadka at gmail.com <mailto:mnasiadka at gmail.com>> napsal:
>>> Hello,
>>>
>>> RabbitMQ HA has been backported into stable releases, and it?s documented here:
>>> https://docs.openstack.org/kolla-ansible/yoga/reference/message-queues/rabbitmq.html#high-availability
>>>
>>> Best regards,
>>> Michal
>>>
>>> W dniu wt., 11.04.2023 o 13:32 Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> napisa?(a):
>>>> Yes.
>>>> But cluster cannot work properly without it. :(
>>>>
>>>> On Tue, Apr 11, 2023, 6:18 PM Danny Webb <Danny.Webb at thehutgroup.com <mailto:Danny.Webb at thehutgroup.com>> wrote:
>>>>> This commit explains why they largely removed HA queue durability:
>>>>>
>>>>> https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90a9a912588af0a180
>>>>> From: Satish Patel <satish.txt at gmail.com <mailto:satish.txt at gmail.com>>
>>>>> Sent: 09 April 2023 04:16
>>>>> To: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>>
>>>>> Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org <mailto:openstack-discuss at lists.openstack.org>>
>>>>> Subject: Re: [openstack][sharing][kolla ansible]Problems when 1 of 3 controller was be down
>>>>>
>>>>>
>>>>> CAUTION: This email originates from outside THG
>>>>>
>>>>> Are you proposing a solution or just raising an issue?
>>>>>
>>>>> I did find it strange that kolla-ansible doesn't support HA queue by default. That is a disaster because when one of the nodes goes down it will make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have to add HA policy to make queue HA otherwise you will endup in problem.
>>>>>
>>>>> On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> wrote:
>>>>> Hello everyone.
>>>>>
>>>>> I want to summary for who meets problems with Openstack when deploy cluster with 3 controller using Kolla Ansible
>>>>>
>>>>> Scenario: 1 of 3 controller is down
>>>>>
>>>>> 1. Login horizon and use API such as nova, cinder will be very slow
>>>>>
>>>>> fix by:
>>>>>
>>>>> nano:
>>>>> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
>>>>> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
>>>>> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
>>>>> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
>>>>> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
>>>>>
>>>>> or which service need caches
>>>>>
>>>>> add as below
>>>>>
>>>>> [cache]
>>>>> backend = oslo_cache.memcache_pool
>>>>> enabled = True
>>>>> memcache_servers = {{ kolla_internal_vip_address }}:{{ memcached_port }}
>>>>> memcache_dead_retry = 0.25
>>>>> memcache_socket_timeout = 900
>>>>>
>>>>> https://review.opendev.org/c/openstack/kolla-ansible/+/849487
>>>>>
>>>>> but it is not the end
>>>>>
>>>>> 2. Cannot launch instance or mapping block device(stuck at this step)
>>>>>
>>>>> nano kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
>>>>>
>>>>> "policies":[
>>>>> {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
>>>>> {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all", "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"}, "priority":0}
>>>>> {% endif %}
>>>>> ]
>>>>>
>>>>> nano /etc/kollla/global.conf
>>>>>
>>>>> [oslo_messaging_rabbit]
>>>>> kombu_reconnect_delay=0.5
>>>>>
>>>>>
>>>>> https://bugs.launchpad.net/oslo.messaging/+bug/1993149
>>>>> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
>>>>>
>>>>> I used Xena 13.4 and Yoga 14.8.1.
>>>>>
>>>>> Above bugs are critical, but I see that it was not fixed. I am just an operator and I want to share what I encountered for new people who come to Openstack
>>>>>
>>>>>
>>>>> Nguyen Huu Khoi
>>> --
>>> Micha? Nasiadka
>>> mnasiadka at gmail.com <mailto:mnasiadka at gmail.com>


From satish.txt at gmail.com  Wed Apr 12 14:34:44 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 12 Apr 2023 10:34:44 -0400
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CAHsN3DO5jMQPtxz2yUdWa=jjgG3Y3Y6GDcJQmmtpQVNkSwh55Q@mail.gmail.com>
References: <CAHsN3DO5jMQPtxz2yUdWa=jjgG3Y3Y6GDcJQmmtpQVNkSwh55Q@mail.gmail.com>
Message-ID: <CAPgF-fr1k4pQs5j6DtV5OeeCgcgjmcW7gdMS75vtxnAEx8V=sw@mail.gmail.com>

Hi Matt,

How do I set kombu_reconnect_delay=0.5 option?

Something like the following in global.yml?

kombu_reconnect_delay: 0.5

On Wed, Apr 12, 2023 at 4:23?AM Matt Crees <mattc at stackhpc.com> wrote:

> Hi all,
>
> It seems worth noting here that there is a fix ongoing in
> oslo.messaging which will resolve the issues with HA failing when one
> node is down. See here:
> https://review.opendev.org/c/openstack/oslo.messaging/+/866617
> In the meantime, we have also found that setting kombu_reconnect_delay
> = 0.5 does resolve this issue.
>
> As for why om_enable_rabbitmq_high_availability is currently
> defaulting to false, as Michal said enabling it in stable releases
> will impact users. This is because it enables durable queues, and the
> migration from transient to durable queues is not a seamless
> procedure. It requires that the state of RabbitMQ is reset and that
> the OpenStack services which use RabbitMQ are restarted to recreate
> the queues.
>
> I think that there is some merit in changing this default value. But
> if we did this, we should either add additional support to automate
> the migration from transient to durable queues, or at the very least
> provide some decent docs on the manual procedure.
>
> However, as classic queue mirroring is deprecated in RabbitMQ (to be
> removed in RabbitMQ 4.0) we should maybe consider switching to quorum
> queues soon. Then it may be beneficial to leave the classic queue
> mirroring + durable queues setup as False by default. This is because
> the migration between queue types (durable or quorum) can take several
> hours on larger deployments. So it might be worth making sure the
> default values only require one migration to quorum queues in the
> future, rather than two (durable queues now and then quorum queues in
> the future).
>
> We will need to make this switch eventually, but right now RabbitMQ
> 4.0 does not even have a set release date, so it's not the most urgent
> change.
>
> Cheers,
> Matt
>
> >Hi Michal,
> >
> >Feel free to propose change of default in master branch, but I don?t
> think we can change the default in stable branches without impacting users.
> >
> >Best regards,
> >Michal
> >
> >> On 11 Apr 2023, at 15:18, Michal Arbet <michal.arbet at ultimum.io> wrote:
> >>
> >> Hi,
> >>
> >> Btw, why we have such option set to false ?
> >> Michal Arbet
> >> Openstack Engineer
> >>
> >> Ultimum Technologies a.s.
> >> Na Po???? 1047/26, 11000 Praha 1
> >> Czech Republic
> >>
> >> +420 604 228 897 <>
> >> michal.arbet at ultimum.io <mailto:michal.arbet at ultimum.io>
> >> https://ultimum.io <https://ultimum.io/>
> >>
> >> LinkedIn <https://www.linkedin.com/company/ultimum-technologies> |
> Twitter <https://twitter.com/ultimumtech> | Facebook <
> https://www.facebook.com/ultimumtechnologies/timeline>
> >>
> >>
> >> ?t 11. 4. 2023 v 14:48 odes?latel Micha? Nasiadka <mnasiadka at gmail.com
> <mailto:mnasiadka at gmail.com>> napsal:
> >>> Hello,
> >>>
> >>> RabbitMQ HA has been backported into stable releases, and it?s
> documented here:
> >>>
> https://docs.openstack.org/kolla-ansible/yoga/reference/message-queues/rabbitmq.html#high-availability
> >>>
> >>> Best regards,
> >>> Michal
> >>>
> >>> W dniu wt., 11.04.2023 o 13:32 Nguy?n H?u Kh?i <
> nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> napisa?(a):
> >>>> Yes.
> >>>> But cluster cannot work properly without it. :(
> >>>>
> >>>> On Tue, Apr 11, 2023, 6:18 PM Danny Webb <Danny.Webb at thehutgroup.com
> <mailto:Danny.Webb at thehutgroup.com>> wrote:
> >>>>> This commit explains why they largely removed HA queue durability:
> >>>>>
> >>>>>
> https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90a9a912588af0a180
> >>>>> From: Satish Patel <satish.txt at gmail.com <mailto:
> satish.txt at gmail.com>>
> >>>>> Sent: 09 April 2023 04:16
> >>>>> To: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:
> nguyenhuukhoinw at gmail.com>>
> >>>>> Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org
> <mailto:openstack-discuss at lists.openstack.org>>
> >>>>> Subject: Re: [openstack][sharing][kolla ansible]Problems when 1 of 3
> controller was be down
> >>>>>
> >>>>>
> >>>>> CAUTION: This email originates from outside THG
> >>>>>
> >>>>> Are you proposing a solution or just raising an issue?
> >>>>>
> >>>>> I did find it strange that kolla-ansible doesn't support HA queue by
> default. That is a disaster because when one of the nodes goes down it will
> make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have to add
> HA policy to make queue HA otherwise you will endup in problem.
> >>>>>
> >>>>> On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <
> nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> wrote:
> >>>>> Hello everyone.
> >>>>>
> >>>>> I want to summary for who meets problems with Openstack when deploy
> cluster with 3 controller using Kolla Ansible
> >>>>>
> >>>>> Scenario: 1 of 3 controller is down
> >>>>>
> >>>>> 1. Login horizon and use API such as nova, cinder will be very slow
> >>>>>
> >>>>> fix by:
> >>>>>
> >>>>> nano:
> >>>>> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
> >>>>> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
> >>>>> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
> >>>>> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
> >>>>> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
> >>>>>
> >>>>> or which service need caches
> >>>>>
> >>>>> add as below
> >>>>>
> >>>>> [cache]
> >>>>> backend = oslo_cache.memcache_pool
> >>>>> enabled = True
> >>>>> memcache_servers = {{ kolla_internal_vip_address }}:{{
> memcached_port }}
> >>>>> memcache_dead_retry = 0.25
> >>>>> memcache_socket_timeout = 900
> >>>>>
> >>>>> https://review.opendev.org/c/openstack/kolla-ansible/+/849487
> >>>>>
> >>>>> but it is not the end
> >>>>>
> >>>>> 2. Cannot launch instance or mapping block device(stuck at this step)
> >>>>>
> >>>>> nano
> kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
> >>>>>
> >>>>> "policies":[
> >>>>> {"vhost": "/", "name": "ha-all", "pattern":
> "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition":
> {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
> >>>>> {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all",
> "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"},
> "priority":0}
> >>>>> {% endif %}
> >>>>> ]
> >>>>>
> >>>>> nano /etc/kollla/global.conf
> >>>>>
> >>>>> [oslo_messaging_rabbit]
> >>>>> kombu_reconnect_delay=0.5
> >>>>>
> >>>>>
> >>>>> https://bugs.launchpad.net/oslo.messaging/+bug/1993149
> >>>>>
> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
> >>>>>
> >>>>> I used Xena 13.4 and Yoga 14.8.1.
> >>>>>
> >>>>> Above bugs are critical, but I see that it was not fixed. I am just
> an operator and I want to share what I encountered for new people who come
> to Openstack
> >>>>>
> >>>>>
> >>>>> Nguyen Huu Khoi
> >>> --
> >>> Micha? Nasiadka
> >>> mnasiadka at gmail.com <mailto:mnasiadka at gmail.com>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/fdf8bf42/attachment.htm>

From gmann at ghanshyammann.com  Wed Apr 12 14:40:41 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 12 Apr 2023 07:40:41 -0700
Subject: [ptl] Need PTL volunteer for OpenStack Winstackers
In-Reply-To: <CAL_crJQSOkBvbtYtRXDJuS3PNXVJm_n00Yp2MnFXZYfSsXSXPw@mail.gmail.com>
References: <1870a6b7a1d.114e70a2d994244.3514791188773000084@ghanshyammann.com>
 <1873468752c.bf93124c180931.3029567703559224707@ghanshyammann.com>
 <CAL_crJQn0h0w4zyCV_HLZrYQ4YwsKwVzcbtGAxzdN8REx06g+w@mail.gmail.com>
 <2832840.mvXUDI8C0e@p1>
 <187715c5f64.10fd9250b398749.6791795632701673310@ghanshyammann.com>
 <CAL_crJSDDiwhcG_eLUefJ_UEaM7avtGEA-KzS4e3oi+cnie9Xw@mail.gmail.com>
 <CAHmFs2VaHmZF+yUgfWhxXyDZh2951h1d9TJjPOxYwKVUsG=HRQ@mail.gmail.com>
 <CAL_crJQSOkBvbtYtRXDJuS3PNXVJm_n00Yp2MnFXZYfSsXSXPw@mail.gmail.com>
Message-ID: <18775e960e1.c3946935484233.5763279760546115948@ghanshyammann.com>

 ---- On Wed, 12 Apr 2023 00:09:51 -0700  Takashi Kajinami  wrote --- 
 > 
 > 
 > On Wed, Apr 12, 2023 at 3:51?PM Sean Mooney smooney at redhat.com> wrote:
 > On Wed, Apr 12, 2023 at 2:42?AM Takashi Kajinami tkajinam at redhat.com> wrote:
 > >
 > >
 > >
 > > On Wed, Apr 12, 2023 at 2:28?AM Ghanshyam Mann gmann at ghanshyammann.com> wrote:
 > >>
 > >>? ---- On Tue, 11 Apr 2023 02:01:38 -0700? Slawek Kaplonski? wrote ---
 > >>? > Hi,
 > >>? >
 > >>? > Dnia wtorek, 11 kwietnia 2023 10:49:44 CEST Takashi Kajinami pisze:
 > >>? > > This probably causes a bit wider effect than just retiring the winstackers
 > >>? > > project.
 > >>? > >
 > >>? > > I see some projects (cinde, designate, glance and os-brick) depend on
 > >>? > > os-win which is under
 > >>? > > governance of winstackers and will be retired. Also, even some more
 > >>? > > projects (Neutron, os-vif,
 > >>? > > ovsdbapp, oslo.log, etc) supports windows without os-win.
 > >>? > >
 > >>? > > If we retire Winstackers, then is it reasonable to remove all
 > >>? > > implementations to support Windows ?
 > >>? >
 > >>? > That's very good question IMO. And, from Neutron perspective very important according to the removal of netifaces dependency - it would be much easier to remove it by removing all "windows" module from Neutron repo rather than refactoring it.
 > >>
 > >> I agree. Thanks, Takashi for raising it.
 > >>
 > >> If we retire Winstackers then yes, it means all dependencies of any functionality (user-facing or internal)
 > >> need to be removed also. This is not a good situation for us as window support of OpenStack, if I am
 > >> not wrong, Cloudbase is the only company maintaining and supporting the window support since starting.
 > >> If there is any company having their customer based on windows then this is the right time to step up and help
 > >> in maintaining this project. Otherway (based on project wants and have the bandwidth) is to implement the
 > >> alternate way in projects for window support (the one you mentioned has window support ).
 > >>
 > > Please correct me if I'm wrong but what cloudbase has been maintaining is support for windows guest
 > > instead of windows host.
 > that is incorrect cloudbase provide the third party ci that test
 > deploying openstack compute nodes on windows.
 > that is the in/out of tree hyperV virt driver and the ovs on windows
 > supprot used with os-vif and neuton ml2/ovs plugsins on windows.
 > 
 > Thanks.
 > I was confused by some conversation logs in #openstack-tc and it was indeedmentioned cloudbase no longer maintains Winstackers (= Windows host support)earlier in this thread.
 > 
 > while we are happy to review fixes for hyper v /windows hows we now no
 > longer have any way to test these changes in ci ro locally as we
 > don't have a maintained way to deploy devstack on hyper v/windows hosts.
 > 
 > out side fo the cloud base init package which is optional there is no
 > depency on cloudbase to support windows guest.
 > that is unaffected. but windows host support is now effectivly
 > unmainated and untested.
 > 
 > I completely agree with this statement.

Yes. AFAIK, it was only Cloudbase who maintained code as well as 3rd party CI for Nova HyperV
driver. 

-gmann

 > 
 > > My previous question was about Windows host support (whether we can remove
 > > all implementations to run OpenStack services in windows hosts, instead of linux hosts) and guest support
 > > can be kept now.
 > >
 > >>
 > >> -gmann
 > >>
 > >>? >
 > >>? > >
 > >>? > >
 > >>? > >
 > >>? > > On Fri, Mar 31, 2023 at 6:29?AM Ghanshyam Mann gmann at ghanshyammann.com>
 > >>? > > wrote:
 > >>? > >
 > >>? > > > Thanks, Lucian, for the updates and email link.
 > >>? > > >
 > >>? > > > As the next step, we will discuss it in TC and take the next action.
 > >>? > > >
 > >>? > > > -gmann
 > >>? > > >
 > >>? > > >? ---- On Thu, 30 Mar 2023 00:11:38 -0700? Lucian Petrut? wrote ---
 > >>? > > >? > Hi,
 > >>? > > >? > Thanks for reaching out. As mentioned here [1], Cloudbase Solutions can
 > >>? > > > no longer lead the Winstackers project. Since there weren?t any other
 > >>? > > > interested parties, I think there?s no other option but to retire the
 > >>? > > > project.
 > >>? > > >? > [1]
 > >>? > > > https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html
 > >>? > > >? > Regards,Lucian Petrut
 > >>? > > >? >
 > >>? > > >? > On 22 Mar 2023, at 19:43, Ghanshyam Mann gmann at ghanshyammann.com>
 > >>? > > > wrote:
 > >>? > > >? > Hi Lukas,
 > >>? > > >? >
 > >>? > > >? > I am reaching out to you as you were PTL for OpenStack Winstackers
 > >>? > > > project in the last cycle.
 > >>? > > >? >
 > >>? > > >? > There is no PTL candidate for the next cycle (2023.2), and it is on the
 > >>? > > > leaderless project list. Please
 > >>? > > >? > check if you or anyone you know would like to lead this project.
 > >>? > > >? >
 > >>? > > >? > - https://etherpad.opendev.org/p/2023.2-leaderless
 > >>? > > >? >
 > >>? > > >? > Also, if anyone else would like to help leading this project, this is
 > >>? > > > time to let TC knows.
 > >>? > > >? >
 > >>? > > >? > -gmann
 > >>? > > >? >
 > >>? > > >? >
 > >>? > > >
 > >>? > > >
 > >>? > >
 > >>? >
 > >>? >
 > >>? > --
 > >>? > Slawek Kaplonski
 > >>? > Principal Software Engineer
 > >>? > Red Hat
 > >>
 > 
 > 


From nguyenhuukhoinw at gmail.com  Wed Apr 12 14:44:57 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Wed, 12 Apr 2023 21:44:57 +0700
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CAPgF-fr1k4pQs5j6DtV5OeeCgcgjmcW7gdMS75vtxnAEx8V=sw@mail.gmail.com>
References: <CAHsN3DO5jMQPtxz2yUdWa=jjgG3Y3Y6GDcJQmmtpQVNkSwh55Q@mail.gmail.com>
 <CAPgF-fr1k4pQs5j6DtV5OeeCgcgjmcW7gdMS75vtxnAEx8V=sw@mail.gmail.com>
Message-ID: <CABAODRdfX6aPXkCDwCxJBkwDNB7YaG4U_Z2o0=HLYeO0zWjE8A@mail.gmail.com>

Hi.
Create global.conf in /etc/kolla/config/

On Wed, Apr 12, 2023, 9:42 PM Satish Patel <satish.txt at gmail.com> wrote:

> Hi Matt,
>
> How do I set kombu_reconnect_delay=0.5 option?
>
> Something like the following in global.yml?
>
> kombu_reconnect_delay: 0.5
>
> On Wed, Apr 12, 2023 at 4:23?AM Matt Crees <mattc at stackhpc.com> wrote:
>
>> Hi all,
>>
>> It seems worth noting here that there is a fix ongoing in
>> oslo.messaging which will resolve the issues with HA failing when one
>> node is down. See here:
>> https://review.opendev.org/c/openstack/oslo.messaging/+/866617
>> In the meantime, we have also found that setting kombu_reconnect_delay
>> = 0.5 does resolve this issue.
>>
>> As for why om_enable_rabbitmq_high_availability is currently
>> defaulting to false, as Michal said enabling it in stable releases
>> will impact users. This is because it enables durable queues, and the
>> migration from transient to durable queues is not a seamless
>> procedure. It requires that the state of RabbitMQ is reset and that
>> the OpenStack services which use RabbitMQ are restarted to recreate
>> the queues.
>>
>> I think that there is some merit in changing this default value. But
>> if we did this, we should either add additional support to automate
>> the migration from transient to durable queues, or at the very least
>> provide some decent docs on the manual procedure.
>>
>> However, as classic queue mirroring is deprecated in RabbitMQ (to be
>> removed in RabbitMQ 4.0) we should maybe consider switching to quorum
>> queues soon. Then it may be beneficial to leave the classic queue
>> mirroring + durable queues setup as False by default. This is because
>> the migration between queue types (durable or quorum) can take several
>> hours on larger deployments. So it might be worth making sure the
>> default values only require one migration to quorum queues in the
>> future, rather than two (durable queues now and then quorum queues in
>> the future).
>>
>> We will need to make this switch eventually, but right now RabbitMQ
>> 4.0 does not even have a set release date, so it's not the most urgent
>> change.
>>
>> Cheers,
>> Matt
>>
>> >Hi Michal,
>> >
>> >Feel free to propose change of default in master branch, but I don?t
>> think we can change the default in stable branches without impacting users.
>> >
>> >Best regards,
>> >Michal
>> >
>> >> On 11 Apr 2023, at 15:18, Michal Arbet <michal.arbet at ultimum.io>
>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> Btw, why we have such option set to false ?
>> >> Michal Arbet
>> >> Openstack Engineer
>> >>
>> >> Ultimum Technologies a.s.
>> >> Na Po???? 1047/26, 11000 Praha 1
>> >> Czech Republic
>> >>
>> >> +420 604 228 897 <>
>> >> michal.arbet at ultimum.io <mailto:michal.arbet at ultimum.io>
>> >> https://ultimum.io <https://ultimum.io/>
>> >>
>> >> LinkedIn <https://www.linkedin.com/company/ultimum-technologies> |
>> Twitter <https://twitter.com/ultimumtech> | Facebook <
>> https://www.facebook.com/ultimumtechnologies/timeline>
>> >>
>> >>
>> >> ?t 11. 4. 2023 v 14:48 odes?latel Micha? Nasiadka <mnasiadka at gmail.com
>> <mailto:mnasiadka at gmail.com>> napsal:
>> >>> Hello,
>> >>>
>> >>> RabbitMQ HA has been backported into stable releases, and it?s
>> documented here:
>> >>>
>> https://docs.openstack.org/kolla-ansible/yoga/reference/message-queues/rabbitmq.html#high-availability
>> >>>
>> >>> Best regards,
>> >>> Michal
>> >>>
>> >>> W dniu wt., 11.04.2023 o 13:32 Nguy?n H?u Kh?i <
>> nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> napisa?(a):
>> >>>> Yes.
>> >>>> But cluster cannot work properly without it. :(
>> >>>>
>> >>>> On Tue, Apr 11, 2023, 6:18 PM Danny Webb <Danny.Webb at thehutgroup.com
>> <mailto:Danny.Webb at thehutgroup.com>> wrote:
>> >>>>> This commit explains why they largely removed HA queue durability:
>> >>>>>
>> >>>>>
>> https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90a9a912588af0a180
>> >>>>> From: Satish Patel <satish.txt at gmail.com <mailto:
>> satish.txt at gmail.com>>
>> >>>>> Sent: 09 April 2023 04:16
>> >>>>> To: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:
>> nguyenhuukhoinw at gmail.com>>
>> >>>>> Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org
>> <mailto:openstack-discuss at lists.openstack.org>>
>> >>>>> Subject: Re: [openstack][sharing][kolla ansible]Problems when 1 of
>> 3 controller was be down
>> >>>>>
>> >>>>>
>> >>>>> CAUTION: This email originates from outside THG
>> >>>>>
>> >>>>> Are you proposing a solution or just raising an issue?
>> >>>>>
>> >>>>> I did find it strange that kolla-ansible doesn't support HA queue
>> by default. That is a disaster because when one of the nodes goes down it
>> will make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have
>> to add HA policy to make queue HA otherwise you will endup in problem.
>> >>>>>
>> >>>>> On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <
>> nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> wrote:
>> >>>>> Hello everyone.
>> >>>>>
>> >>>>> I want to summary for who meets problems with Openstack when deploy
>> cluster with 3 controller using Kolla Ansible
>> >>>>>
>> >>>>> Scenario: 1 of 3 controller is down
>> >>>>>
>> >>>>> 1. Login horizon and use API such as nova, cinder will be very slow
>> >>>>>
>> >>>>> fix by:
>> >>>>>
>> >>>>> nano:
>> >>>>> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
>> >>>>> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
>> >>>>> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
>> >>>>> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
>> >>>>> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
>> >>>>>
>> >>>>> or which service need caches
>> >>>>>
>> >>>>> add as below
>> >>>>>
>> >>>>> [cache]
>> >>>>> backend = oslo_cache.memcache_pool
>> >>>>> enabled = True
>> >>>>> memcache_servers = {{ kolla_internal_vip_address }}:{{
>> memcached_port }}
>> >>>>> memcache_dead_retry = 0.25
>> >>>>> memcache_socket_timeout = 900
>> >>>>>
>> >>>>> https://review.opendev.org/c/openstack/kolla-ansible/+/849487
>> >>>>>
>> >>>>> but it is not the end
>> >>>>>
>> >>>>> 2. Cannot launch instance or mapping block device(stuck at this
>> step)
>> >>>>>
>> >>>>> nano
>> kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
>> >>>>>
>> >>>>> "policies":[
>> >>>>> {"vhost": "/", "name": "ha-all", "pattern":
>> "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition":
>> {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
>> >>>>> {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all",
>> "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"},
>> "priority":0}
>> >>>>> {% endif %}
>> >>>>> ]
>> >>>>>
>> >>>>> nano /etc/kollla/global.conf
>> >>>>>
>> >>>>> [oslo_messaging_rabbit]
>> >>>>> kombu_reconnect_delay=0.5
>> >>>>>
>> >>>>>
>> >>>>> https://bugs.launchpad.net/oslo.messaging/+bug/1993149
>> >>>>>
>> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
>> >>>>>
>> >>>>> I used Xena 13.4 and Yoga 14.8.1.
>> >>>>>
>> >>>>> Above bugs are critical, but I see that it was not fixed. I am just
>> an operator and I want to share what I encountered for new people who come
>> to Openstack
>> >>>>>
>> >>>>>
>> >>>>> Nguyen Huu Khoi
>> >>> --
>> >>> Micha? Nasiadka
>> >>> mnasiadka at gmail.com <mailto:mnasiadka at gmail.com>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/67a20dd9/attachment.htm>

From mattc at stackhpc.com  Wed Apr 12 14:54:19 2023
From: mattc at stackhpc.com (Matt Crees)
Date: Wed, 12 Apr 2023 15:54:19 +0100
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CABAODRdfX6aPXkCDwCxJBkwDNB7YaG4U_Z2o0=HLYeO0zWjE8A@mail.gmail.com>
References: <CAHsN3DO5jMQPtxz2yUdWa=jjgG3Y3Y6GDcJQmmtpQVNkSwh55Q@mail.gmail.com>
 <CAPgF-fr1k4pQs5j6DtV5OeeCgcgjmcW7gdMS75vtxnAEx8V=sw@mail.gmail.com>
 <CABAODRdfX6aPXkCDwCxJBkwDNB7YaG4U_Z2o0=HLYeO0zWjE8A@mail.gmail.com>
Message-ID: <CAHsN3DNRogsCtLJSm9VKd1YV0J+M4dwj+byWB8A2W4OZNm4W-g@mail.gmail.com>

Yes, and the option also needs to be under the oslo_messaging_rabbit heading:

[oslo_messaging_rabbit]
kombu_reconnect_delay=0.5


On Wed, 12 Apr 2023 at 15:45, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com> wrote:
>
> Hi.
> Create global.conf in /etc/kolla/config/
>
> On Wed, Apr 12, 2023, 9:42 PM Satish Patel <satish.txt at gmail.com> wrote:
>>
>> Hi Matt,
>>
>> How do I set kombu_reconnect_delay=0.5 option?
>>
>> Something like the following in global.yml?
>>
>> kombu_reconnect_delay: 0.5
>>
>> On Wed, Apr 12, 2023 at 4:23?AM Matt Crees <mattc at stackhpc.com> wrote:
>>>
>>> Hi all,
>>>
>>> It seems worth noting here that there is a fix ongoing in
>>> oslo.messaging which will resolve the issues with HA failing when one
>>> node is down. See here:
>>> https://review.opendev.org/c/openstack/oslo.messaging/+/866617
>>> In the meantime, we have also found that setting kombu_reconnect_delay
>>> = 0.5 does resolve this issue.
>>>
>>> As for why om_enable_rabbitmq_high_availability is currently
>>> defaulting to false, as Michal said enabling it in stable releases
>>> will impact users. This is because it enables durable queues, and the
>>> migration from transient to durable queues is not a seamless
>>> procedure. It requires that the state of RabbitMQ is reset and that
>>> the OpenStack services which use RabbitMQ are restarted to recreate
>>> the queues.
>>>
>>> I think that there is some merit in changing this default value. But
>>> if we did this, we should either add additional support to automate
>>> the migration from transient to durable queues, or at the very least
>>> provide some decent docs on the manual procedure.
>>>
>>> However, as classic queue mirroring is deprecated in RabbitMQ (to be
>>> removed in RabbitMQ 4.0) we should maybe consider switching to quorum
>>> queues soon. Then it may be beneficial to leave the classic queue
>>> mirroring + durable queues setup as False by default. This is because
>>> the migration between queue types (durable or quorum) can take several
>>> hours on larger deployments. So it might be worth making sure the
>>> default values only require one migration to quorum queues in the
>>> future, rather than two (durable queues now and then quorum queues in
>>> the future).
>>>
>>> We will need to make this switch eventually, but right now RabbitMQ
>>> 4.0 does not even have a set release date, so it's not the most urgent
>>> change.
>>>
>>> Cheers,
>>> Matt
>>>
>>> >Hi Michal,
>>> >
>>> >Feel free to propose change of default in master branch, but I don?t think we can change the default in stable branches without impacting users.
>>> >
>>> >Best regards,
>>> >Michal
>>> >
>>> >> On 11 Apr 2023, at 15:18, Michal Arbet <michal.arbet at ultimum.io> wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> Btw, why we have such option set to false ?
>>> >> Michal Arbet
>>> >> Openstack Engineer
>>> >>
>>> >> Ultimum Technologies a.s.
>>> >> Na Po???? 1047/26, 11000 Praha 1
>>> >> Czech Republic
>>> >>
>>> >> +420 604 228 897 <>
>>> >> michal.arbet at ultimum.io <mailto:michal.arbet at ultimum.io>
>>> >> https://ultimum.io <https://ultimum.io/>
>>> >>
>>> >> LinkedIn <https://www.linkedin.com/company/ultimum-technologies> | Twitter <https://twitter.com/ultimumtech> | Facebook <https://www.facebook.com/ultimumtechnologies/timeline>
>>> >>
>>> >>
>>> >> ?t 11. 4. 2023 v 14:48 odes?latel Micha? Nasiadka <mnasiadka at gmail.com <mailto:mnasiadka at gmail.com>> napsal:
>>> >>> Hello,
>>> >>>
>>> >>> RabbitMQ HA has been backported into stable releases, and it?s documented here:
>>> >>> https://docs.openstack.org/kolla-ansible/yoga/reference/message-queues/rabbitmq.html#high-availability
>>> >>>
>>> >>> Best regards,
>>> >>> Michal
>>> >>>
>>> >>> W dniu wt., 11.04.2023 o 13:32 Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> napisa?(a):
>>> >>>> Yes.
>>> >>>> But cluster cannot work properly without it. :(
>>> >>>>
>>> >>>> On Tue, Apr 11, 2023, 6:18 PM Danny Webb <Danny.Webb at thehutgroup.com <mailto:Danny.Webb at thehutgroup.com>> wrote:
>>> >>>>> This commit explains why they largely removed HA queue durability:
>>> >>>>>
>>> >>>>> https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90a9a912588af0a180
>>> >>>>> From: Satish Patel <satish.txt at gmail.com <mailto:satish.txt at gmail.com>>
>>> >>>>> Sent: 09 April 2023 04:16
>>> >>>>> To: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>>
>>> >>>>> Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org <mailto:openstack-discuss at lists.openstack.org>>
>>> >>>>> Subject: Re: [openstack][sharing][kolla ansible]Problems when 1 of 3 controller was be down
>>> >>>>>
>>> >>>>>
>>> >>>>> CAUTION: This email originates from outside THG
>>> >>>>>
>>> >>>>> Are you proposing a solution or just raising an issue?
>>> >>>>>
>>> >>>>> I did find it strange that kolla-ansible doesn't support HA queue by default. That is a disaster because when one of the nodes goes down it will make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have to add HA policy to make queue HA otherwise you will endup in problem.
>>> >>>>>
>>> >>>>> On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> wrote:
>>> >>>>> Hello everyone.
>>> >>>>>
>>> >>>>> I want to summary for who meets problems with Openstack when deploy cluster with 3 controller using Kolla Ansible
>>> >>>>>
>>> >>>>> Scenario: 1 of 3 controller is down
>>> >>>>>
>>> >>>>> 1. Login horizon and use API such as nova, cinder will be very slow
>>> >>>>>
>>> >>>>> fix by:
>>> >>>>>
>>> >>>>> nano:
>>> >>>>> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
>>> >>>>> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
>>> >>>>> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
>>> >>>>> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
>>> >>>>> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
>>> >>>>>
>>> >>>>> or which service need caches
>>> >>>>>
>>> >>>>> add as below
>>> >>>>>
>>> >>>>> [cache]
>>> >>>>> backend = oslo_cache.memcache_pool
>>> >>>>> enabled = True
>>> >>>>> memcache_servers = {{ kolla_internal_vip_address }}:{{ memcached_port }}
>>> >>>>> memcache_dead_retry = 0.25
>>> >>>>> memcache_socket_timeout = 900
>>> >>>>>
>>> >>>>> https://review.opendev.org/c/openstack/kolla-ansible/+/849487
>>> >>>>>
>>> >>>>> but it is not the end
>>> >>>>>
>>> >>>>> 2. Cannot launch instance or mapping block device(stuck at this step)
>>> >>>>>
>>> >>>>> nano kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
>>> >>>>>
>>> >>>>> "policies":[
>>> >>>>> {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
>>> >>>>> {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all", "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"}, "priority":0}
>>> >>>>> {% endif %}
>>> >>>>> ]
>>> >>>>>
>>> >>>>> nano /etc/kollla/global.conf
>>> >>>>>
>>> >>>>> [oslo_messaging_rabbit]
>>> >>>>> kombu_reconnect_delay=0.5
>>> >>>>>
>>> >>>>>
>>> >>>>> https://bugs.launchpad.net/oslo.messaging/+bug/1993149
>>> >>>>> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
>>> >>>>>
>>> >>>>> I used Xena 13.4 and Yoga 14.8.1.
>>> >>>>>
>>> >>>>> Above bugs are critical, but I see that it was not fixed. I am just an operator and I want to share what I encountered for new people who come to Openstack
>>> >>>>>
>>> >>>>>
>>> >>>>> Nguyen Huu Khoi
>>> >>> --
>>> >>> Micha? Nasiadka
>>> >>> mnasiadka at gmail.com <mailto:mnasiadka at gmail.com>
>>>


From satish.txt at gmail.com  Wed Apr 12 15:00:49 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 12 Apr 2023 11:00:49 -0400
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CABAODRdfX6aPXkCDwCxJBkwDNB7YaG4U_Z2o0=HLYeO0zWjE8A@mail.gmail.com>
References: <CAHsN3DO5jMQPtxz2yUdWa=jjgG3Y3Y6GDcJQmmtpQVNkSwh55Q@mail.gmail.com>
 <CAPgF-fr1k4pQs5j6DtV5OeeCgcgjmcW7gdMS75vtxnAEx8V=sw@mail.gmail.com>
 <CABAODRdfX6aPXkCDwCxJBkwDNB7YaG4U_Z2o0=HLYeO0zWjE8A@mail.gmail.com>
Message-ID: <CAPgF-frZ3w_aN+_djz4r92V3w=atP7-WwWKAETR_p7s+hTd3fg@mail.gmail.com>

Hi Nguy?n,

Oh!! make sense, In your post you did the following that is why i got
confused :)  Let me try it in /etc/kolla/config/global.conf file and run
deploy.

>>>>> nano /etc/kollla/global.conf
>>>>>
>>>>> [oslo_messaging_rabbit]
>>>>> kombu_reconnect_delay=0.5

On Wed, Apr 12, 2023 at 10:45?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Hi.
> Create global.conf in /etc/kolla/config/
>
> On Wed, Apr 12, 2023, 9:42 PM Satish Patel <satish.txt at gmail.com> wrote:
>
>> Hi Matt,
>>
>> How do I set kombu_reconnect_delay=0.5 option?
>>
>> Something like the following in global.yml?
>>
>> kombu_reconnect_delay: 0.5
>>
>> On Wed, Apr 12, 2023 at 4:23?AM Matt Crees <mattc at stackhpc.com> wrote:
>>
>>> Hi all,
>>>
>>> It seems worth noting here that there is a fix ongoing in
>>> oslo.messaging which will resolve the issues with HA failing when one
>>> node is down. See here:
>>> https://review.opendev.org/c/openstack/oslo.messaging/+/866617
>>> In the meantime, we have also found that setting kombu_reconnect_delay
>>> = 0.5 does resolve this issue.
>>>
>>> As for why om_enable_rabbitmq_high_availability is currently
>>> defaulting to false, as Michal said enabling it in stable releases
>>> will impact users. This is because it enables durable queues, and the
>>> migration from transient to durable queues is not a seamless
>>> procedure. It requires that the state of RabbitMQ is reset and that
>>> the OpenStack services which use RabbitMQ are restarted to recreate
>>> the queues.
>>>
>>> I think that there is some merit in changing this default value. But
>>> if we did this, we should either add additional support to automate
>>> the migration from transient to durable queues, or at the very least
>>> provide some decent docs on the manual procedure.
>>>
>>> However, as classic queue mirroring is deprecated in RabbitMQ (to be
>>> removed in RabbitMQ 4.0) we should maybe consider switching to quorum
>>> queues soon. Then it may be beneficial to leave the classic queue
>>> mirroring + durable queues setup as False by default. This is because
>>> the migration between queue types (durable or quorum) can take several
>>> hours on larger deployments. So it might be worth making sure the
>>> default values only require one migration to quorum queues in the
>>> future, rather than two (durable queues now and then quorum queues in
>>> the future).
>>>
>>> We will need to make this switch eventually, but right now RabbitMQ
>>> 4.0 does not even have a set release date, so it's not the most urgent
>>> change.
>>>
>>> Cheers,
>>> Matt
>>>
>>> >Hi Michal,
>>> >
>>> >Feel free to propose change of default in master branch, but I don?t
>>> think we can change the default in stable branches without impacting users.
>>> >
>>> >Best regards,
>>> >Michal
>>> >
>>> >> On 11 Apr 2023, at 15:18, Michal Arbet <michal.arbet at ultimum.io>
>>> wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> Btw, why we have such option set to false ?
>>> >> Michal Arbet
>>> >> Openstack Engineer
>>> >>
>>> >> Ultimum Technologies a.s.
>>> >> Na Po???? 1047/26, 11000 Praha 1
>>> >> Czech Republic
>>> >>
>>> >> +420 604 228 897 <>
>>> >> michal.arbet at ultimum.io <mailto:michal.arbet at ultimum.io>
>>> >> https://ultimum.io <https://ultimum.io/>
>>> >>
>>> >> LinkedIn <https://www.linkedin.com/company/ultimum-technologies> |
>>> Twitter <https://twitter.com/ultimumtech> | Facebook <
>>> https://www.facebook.com/ultimumtechnologies/timeline>
>>> >>
>>> >>
>>> >> ?t 11. 4. 2023 v 14:48 odes?latel Micha? Nasiadka <
>>> mnasiadka at gmail.com <mailto:mnasiadka at gmail.com>> napsal:
>>> >>> Hello,
>>> >>>
>>> >>> RabbitMQ HA has been backported into stable releases, and it?s
>>> documented here:
>>> >>>
>>> https://docs.openstack.org/kolla-ansible/yoga/reference/message-queues/rabbitmq.html#high-availability
>>> >>>
>>> >>> Best regards,
>>> >>> Michal
>>> >>>
>>> >>> W dniu wt., 11.04.2023 o 13:32 Nguy?n H?u Kh?i <
>>> nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>>
>>> napisa?(a):
>>> >>>> Yes.
>>> >>>> But cluster cannot work properly without it. :(
>>> >>>>
>>> >>>> On Tue, Apr 11, 2023, 6:18 PM Danny Webb <
>>> Danny.Webb at thehutgroup.com <mailto:Danny.Webb at thehutgroup.com>> wrote:
>>> >>>>> This commit explains why they largely removed HA queue durability:
>>> >>>>>
>>> >>>>>
>>> https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90a9a912588af0a180
>>> >>>>> From: Satish Patel <satish.txt at gmail.com <mailto:
>>> satish.txt at gmail.com>>
>>> >>>>> Sent: 09 April 2023 04:16
>>> >>>>> To: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:
>>> nguyenhuukhoinw at gmail.com>>
>>> >>>>> Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org
>>> <mailto:openstack-discuss at lists.openstack.org>>
>>> >>>>> Subject: Re: [openstack][sharing][kolla ansible]Problems when 1 of
>>> 3 controller was be down
>>> >>>>>
>>> >>>>>
>>> >>>>> CAUTION: This email originates from outside THG
>>> >>>>>
>>> >>>>> Are you proposing a solution or just raising an issue?
>>> >>>>>
>>> >>>>> I did find it strange that kolla-ansible doesn't support HA queue
>>> by default. That is a disaster because when one of the nodes goes down it
>>> will make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have
>>> to add HA policy to make queue HA otherwise you will endup in problem.
>>> >>>>>
>>> >>>>> On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <
>>> nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> wrote:
>>> >>>>> Hello everyone.
>>> >>>>>
>>> >>>>> I want to summary for who meets problems with Openstack when
>>> deploy cluster with 3 controller using Kolla Ansible
>>> >>>>>
>>> >>>>> Scenario: 1 of 3 controller is down
>>> >>>>>
>>> >>>>> 1. Login horizon and use API such as nova, cinder will be very slow
>>> >>>>>
>>> >>>>> fix by:
>>> >>>>>
>>> >>>>> nano:
>>> >>>>> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
>>> >>>>> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
>>> >>>>> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
>>> >>>>> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
>>> >>>>> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
>>> >>>>>
>>> >>>>> or which service need caches
>>> >>>>>
>>> >>>>> add as below
>>> >>>>>
>>> >>>>> [cache]
>>> >>>>> backend = oslo_cache.memcache_pool
>>> >>>>> enabled = True
>>> >>>>> memcache_servers = {{ kolla_internal_vip_address }}:{{
>>> memcached_port }}
>>> >>>>> memcache_dead_retry = 0.25
>>> >>>>> memcache_socket_timeout = 900
>>> >>>>>
>>> >>>>> https://review.opendev.org/c/openstack/kolla-ansible/+/849487
>>> >>>>>
>>> >>>>> but it is not the end
>>> >>>>>
>>> >>>>> 2. Cannot launch instance or mapping block device(stuck at this
>>> step)
>>> >>>>>
>>> >>>>> nano
>>> kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
>>> >>>>>
>>> >>>>> "policies":[
>>> >>>>> {"vhost": "/", "name": "ha-all", "pattern":
>>> "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition":
>>> {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
>>> >>>>> {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all",
>>> "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"},
>>> "priority":0}
>>> >>>>> {% endif %}
>>> >>>>> ]
>>> >>>>>
>>> >>>>> nano /etc/kollla/global.conf
>>> >>>>>
>>> >>>>> [oslo_messaging_rabbit]
>>> >>>>> kombu_reconnect_delay=0.5
>>> >>>>>
>>> >>>>>
>>> >>>>> https://bugs.launchpad.net/oslo.messaging/+bug/1993149
>>> >>>>>
>>> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
>>> >>>>>
>>> >>>>> I used Xena 13.4 and Yoga 14.8.1.
>>> >>>>>
>>> >>>>> Above bugs are critical, but I see that it was not fixed. I am
>>> just an operator and I want to share what I encountered for new people who
>>> come to Openstack
>>> >>>>>
>>> >>>>>
>>> >>>>> Nguyen Huu Khoi
>>> >>> --
>>> >>> Micha? Nasiadka
>>> >>> mnasiadka at gmail.com <mailto:mnasiadka at gmail.com>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/61dcf729/attachment.htm>

From satish.txt at gmail.com  Wed Apr 12 15:04:40 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 12 Apr 2023 11:04:40 -0400
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CAHsN3DNRogsCtLJSm9VKd1YV0J+M4dwj+byWB8A2W4OZNm4W-g@mail.gmail.com>
References: <CAHsN3DO5jMQPtxz2yUdWa=jjgG3Y3Y6GDcJQmmtpQVNkSwh55Q@mail.gmail.com>
 <CAPgF-fr1k4pQs5j6DtV5OeeCgcgjmcW7gdMS75vtxnAEx8V=sw@mail.gmail.com>
 <CABAODRdfX6aPXkCDwCxJBkwDNB7YaG4U_Z2o0=HLYeO0zWjE8A@mail.gmail.com>
 <CAHsN3DNRogsCtLJSm9VKd1YV0J+M4dwj+byWB8A2W4OZNm4W-g@mail.gmail.com>
Message-ID: <CAPgF-fr9KAkJOOK1Y9z=QwEv=tW8Q6xRi9PjJ7Hp2rTrJ8=Pgw@mail.gmail.com>

Matt,

For new deployment how do I enable the Quorum queue?

Just adding the following should be enough?

om_enable_rabbitmq_high_availability: True

On Wed, Apr 12, 2023 at 10:54?AM Matt Crees <mattc at stackhpc.com> wrote:

> Yes, and the option also needs to be under the oslo_messaging_rabbit
> heading:
>
> [oslo_messaging_rabbit]
> kombu_reconnect_delay=0.5
>
>
> On Wed, 12 Apr 2023 at 15:45, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> wrote:
> >
> > Hi.
> > Create global.conf in /etc/kolla/config/
> >
> > On Wed, Apr 12, 2023, 9:42 PM Satish Patel <satish.txt at gmail.com> wrote:
> >>
> >> Hi Matt,
> >>
> >> How do I set kombu_reconnect_delay=0.5 option?
> >>
> >> Something like the following in global.yml?
> >>
> >> kombu_reconnect_delay: 0.5
> >>
> >> On Wed, Apr 12, 2023 at 4:23?AM Matt Crees <mattc at stackhpc.com> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> It seems worth noting here that there is a fix ongoing in
> >>> oslo.messaging which will resolve the issues with HA failing when one
> >>> node is down. See here:
> >>> https://review.opendev.org/c/openstack/oslo.messaging/+/866617
> >>> In the meantime, we have also found that setting kombu_reconnect_delay
> >>> = 0.5 does resolve this issue.
> >>>
> >>> As for why om_enable_rabbitmq_high_availability is currently
> >>> defaulting to false, as Michal said enabling it in stable releases
> >>> will impact users. This is because it enables durable queues, and the
> >>> migration from transient to durable queues is not a seamless
> >>> procedure. It requires that the state of RabbitMQ is reset and that
> >>> the OpenStack services which use RabbitMQ are restarted to recreate
> >>> the queues.
> >>>
> >>> I think that there is some merit in changing this default value. But
> >>> if we did this, we should either add additional support to automate
> >>> the migration from transient to durable queues, or at the very least
> >>> provide some decent docs on the manual procedure.
> >>>
> >>> However, as classic queue mirroring is deprecated in RabbitMQ (to be
> >>> removed in RabbitMQ 4.0) we should maybe consider switching to quorum
> >>> queues soon. Then it may be beneficial to leave the classic queue
> >>> mirroring + durable queues setup as False by default. This is because
> >>> the migration between queue types (durable or quorum) can take several
> >>> hours on larger deployments. So it might be worth making sure the
> >>> default values only require one migration to quorum queues in the
> >>> future, rather than two (durable queues now and then quorum queues in
> >>> the future).
> >>>
> >>> We will need to make this switch eventually, but right now RabbitMQ
> >>> 4.0 does not even have a set release date, so it's not the most urgent
> >>> change.
> >>>
> >>> Cheers,
> >>> Matt
> >>>
> >>> >Hi Michal,
> >>> >
> >>> >Feel free to propose change of default in master branch, but I don?t
> think we can change the default in stable branches without impacting users.
> >>> >
> >>> >Best regards,
> >>> >Michal
> >>> >
> >>> >> On 11 Apr 2023, at 15:18, Michal Arbet <michal.arbet at ultimum.io>
> wrote:
> >>> >>
> >>> >> Hi,
> >>> >>
> >>> >> Btw, why we have such option set to false ?
> >>> >> Michal Arbet
> >>> >> Openstack Engineer
> >>> >>
> >>> >> Ultimum Technologies a.s.
> >>> >> Na Po???? 1047/26, 11000 Praha 1
> >>> >> Czech Republic
> >>> >>
> >>> >> +420 604 228 897 <>
> >>> >> michal.arbet at ultimum.io <mailto:michal.arbet at ultimum.io>
> >>> >> https://ultimum.io <https://ultimum.io/>
> >>> >>
> >>> >> LinkedIn <https://www.linkedin.com/company/ultimum-technologies> |
> Twitter <https://twitter.com/ultimumtech> | Facebook <
> https://www.facebook.com/ultimumtechnologies/timeline>
> >>> >>
> >>> >>
> >>> >> ?t 11. 4. 2023 v 14:48 odes?latel Micha? Nasiadka <
> mnasiadka at gmail.com <mailto:mnasiadka at gmail.com>> napsal:
> >>> >>> Hello,
> >>> >>>
> >>> >>> RabbitMQ HA has been backported into stable releases, and it?s
> documented here:
> >>> >>>
> https://docs.openstack.org/kolla-ansible/yoga/reference/message-queues/rabbitmq.html#high-availability
> >>> >>>
> >>> >>> Best regards,
> >>> >>> Michal
> >>> >>>
> >>> >>> W dniu wt., 11.04.2023 o 13:32 Nguy?n H?u Kh?i <
> nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> napisa?(a):
> >>> >>>> Yes.
> >>> >>>> But cluster cannot work properly without it. :(
> >>> >>>>
> >>> >>>> On Tue, Apr 11, 2023, 6:18 PM Danny Webb <
> Danny.Webb at thehutgroup.com <mailto:Danny.Webb at thehutgroup.com>> wrote:
> >>> >>>>> This commit explains why they largely removed HA queue
> durability:
> >>> >>>>>
> >>> >>>>>
> https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90a9a912588af0a180
> >>> >>>>> From: Satish Patel <satish.txt at gmail.com <mailto:
> satish.txt at gmail.com>>
> >>> >>>>> Sent: 09 April 2023 04:16
> >>> >>>>> To: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:
> nguyenhuukhoinw at gmail.com>>
> >>> >>>>> Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org
> <mailto:openstack-discuss at lists.openstack.org>>
> >>> >>>>> Subject: Re: [openstack][sharing][kolla ansible]Problems when 1
> of 3 controller was be down
> >>> >>>>>
> >>> >>>>>
> >>> >>>>> CAUTION: This email originates from outside THG
> >>> >>>>>
> >>> >>>>> Are you proposing a solution or just raising an issue?
> >>> >>>>>
> >>> >>>>> I did find it strange that kolla-ansible doesn't support HA
> queue by default. That is a disaster because when one of the nodes goes
> down it will make the whole rabbitMQ unacceptable. Whenever i deploy kolla
> i have to add HA policy to make queue HA otherwise you will endup in
> problem.
> >>> >>>>>
> >>> >>>>> On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <
> nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> wrote:
> >>> >>>>> Hello everyone.
> >>> >>>>>
> >>> >>>>> I want to summary for who meets problems with Openstack when
> deploy cluster with 3 controller using Kolla Ansible
> >>> >>>>>
> >>> >>>>> Scenario: 1 of 3 controller is down
> >>> >>>>>
> >>> >>>>> 1. Login horizon and use API such as nova, cinder will be very
> slow
> >>> >>>>>
> >>> >>>>> fix by:
> >>> >>>>>
> >>> >>>>> nano:
> >>> >>>>> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
> >>> >>>>> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
> >>> >>>>> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
> >>> >>>>> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
> >>> >>>>> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
> >>> >>>>>
> >>> >>>>> or which service need caches
> >>> >>>>>
> >>> >>>>> add as below
> >>> >>>>>
> >>> >>>>> [cache]
> >>> >>>>> backend = oslo_cache.memcache_pool
> >>> >>>>> enabled = True
> >>> >>>>> memcache_servers = {{ kolla_internal_vip_address }}:{{
> memcached_port }}
> >>> >>>>> memcache_dead_retry = 0.25
> >>> >>>>> memcache_socket_timeout = 900
> >>> >>>>>
> >>> >>>>> https://review.opendev.org/c/openstack/kolla-ansible/+/849487
> >>> >>>>>
> >>> >>>>> but it is not the end
> >>> >>>>>
> >>> >>>>> 2. Cannot launch instance or mapping block device(stuck at this
> step)
> >>> >>>>>
> >>> >>>>> nano
> kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
> >>> >>>>>
> >>> >>>>> "policies":[
> >>> >>>>> {"vhost": "/", "name": "ha-all", "pattern":
> "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition":
> {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
> >>> >>>>> {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all",
> "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"},
> "priority":0}
> >>> >>>>> {% endif %}
> >>> >>>>> ]
> >>> >>>>>
> >>> >>>>> nano /etc/kollla/global.conf
> >>> >>>>>
> >>> >>>>> [oslo_messaging_rabbit]
> >>> >>>>> kombu_reconnect_delay=0.5
> >>> >>>>>
> >>> >>>>>
> >>> >>>>> https://bugs.launchpad.net/oslo.messaging/+bug/1993149
> >>> >>>>>
> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
> >>> >>>>>
> >>> >>>>> I used Xena 13.4 and Yoga 14.8.1.
> >>> >>>>>
> >>> >>>>> Above bugs are critical, but I see that it was not fixed. I am
> just an operator and I want to share what I encountered for new people who
> come to Openstack
> >>> >>>>>
> >>> >>>>>
> >>> >>>>> Nguyen Huu Khoi
> >>> >>> --
> >>> >>> Micha? Nasiadka
> >>> >>> mnasiadka at gmail.com <mailto:mnasiadka at gmail.com>
> >>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/29620ebe/attachment-0001.htm>

From mattc at stackhpc.com  Wed Apr 12 15:10:05 2023
From: mattc at stackhpc.com (Matt Crees)
Date: Wed, 12 Apr 2023 16:10:05 +0100
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CAPgF-fr9KAkJOOK1Y9z=QwEv=tW8Q6xRi9PjJ7Hp2rTrJ8=Pgw@mail.gmail.com>
References: <CAHsN3DO5jMQPtxz2yUdWa=jjgG3Y3Y6GDcJQmmtpQVNkSwh55Q@mail.gmail.com>
 <CAPgF-fr1k4pQs5j6DtV5OeeCgcgjmcW7gdMS75vtxnAEx8V=sw@mail.gmail.com>
 <CABAODRdfX6aPXkCDwCxJBkwDNB7YaG4U_Z2o0=HLYeO0zWjE8A@mail.gmail.com>
 <CAHsN3DNRogsCtLJSm9VKd1YV0J+M4dwj+byWB8A2W4OZNm4W-g@mail.gmail.com>
 <CAPgF-fr9KAkJOOK1Y9z=QwEv=tW8Q6xRi9PjJ7Hp2rTrJ8=Pgw@mail.gmail.com>
Message-ID: <CAHsN3DMRObqwwz1VGq1Lr6FKihyo4hB+EExnK9vXHmceHhBcEw@mail.gmail.com>

Hi Satish,

Yes for a new deployment you will just need to set that variable to
true. However, that will enable the high availability of RabbitMQ
queues using a combination of classic queue mirroring and durable
queues.
Quorum queues are not yet supported via Kolla Ansible.

Cheers,
Matt

On Wed, 12 Apr 2023 at 16:04, Satish Patel <satish.txt at gmail.com> wrote:
>
> Matt,
>
> For new deployment how do I enable the Quorum queue?
>
> Just adding the following should be enough?
>
> om_enable_rabbitmq_high_availability: True
>
> On Wed, Apr 12, 2023 at 10:54?AM Matt Crees <mattc at stackhpc.com> wrote:
>>
>> Yes, and the option also needs to be under the oslo_messaging_rabbit heading:
>>
>> [oslo_messaging_rabbit]
>> kombu_reconnect_delay=0.5
>>
>>
>> On Wed, 12 Apr 2023 at 15:45, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com> wrote:
>> >
>> > Hi.
>> > Create global.conf in /etc/kolla/config/
>> >
>> > On Wed, Apr 12, 2023, 9:42 PM Satish Patel <satish.txt at gmail.com> wrote:
>> >>
>> >> Hi Matt,
>> >>
>> >> How do I set kombu_reconnect_delay=0.5 option?
>> >>
>> >> Something like the following in global.yml?
>> >>
>> >> kombu_reconnect_delay: 0.5
>> >>
>> >> On Wed, Apr 12, 2023 at 4:23?AM Matt Crees <mattc at stackhpc.com> wrote:
>> >>>
>> >>> Hi all,
>> >>>
>> >>> It seems worth noting here that there is a fix ongoing in
>> >>> oslo.messaging which will resolve the issues with HA failing when one
>> >>> node is down. See here:
>> >>> https://review.opendev.org/c/openstack/oslo.messaging/+/866617
>> >>> In the meantime, we have also found that setting kombu_reconnect_delay
>> >>> = 0.5 does resolve this issue.
>> >>>
>> >>> As for why om_enable_rabbitmq_high_availability is currently
>> >>> defaulting to false, as Michal said enabling it in stable releases
>> >>> will impact users. This is because it enables durable queues, and the
>> >>> migration from transient to durable queues is not a seamless
>> >>> procedure. It requires that the state of RabbitMQ is reset and that
>> >>> the OpenStack services which use RabbitMQ are restarted to recreate
>> >>> the queues.
>> >>>
>> >>> I think that there is some merit in changing this default value. But
>> >>> if we did this, we should either add additional support to automate
>> >>> the migration from transient to durable queues, or at the very least
>> >>> provide some decent docs on the manual procedure.
>> >>>
>> >>> However, as classic queue mirroring is deprecated in RabbitMQ (to be
>> >>> removed in RabbitMQ 4.0) we should maybe consider switching to quorum
>> >>> queues soon. Then it may be beneficial to leave the classic queue
>> >>> mirroring + durable queues setup as False by default. This is because
>> >>> the migration between queue types (durable or quorum) can take several
>> >>> hours on larger deployments. So it might be worth making sure the
>> >>> default values only require one migration to quorum queues in the
>> >>> future, rather than two (durable queues now and then quorum queues in
>> >>> the future).
>> >>>
>> >>> We will need to make this switch eventually, but right now RabbitMQ
>> >>> 4.0 does not even have a set release date, so it's not the most urgent
>> >>> change.
>> >>>
>> >>> Cheers,
>> >>> Matt
>> >>>
>> >>> >Hi Michal,
>> >>> >
>> >>> >Feel free to propose change of default in master branch, but I don?t think we can change the default in stable branches without impacting users.
>> >>> >
>> >>> >Best regards,
>> >>> >Michal
>> >>> >
>> >>> >> On 11 Apr 2023, at 15:18, Michal Arbet <michal.arbet at ultimum.io> wrote:
>> >>> >>
>> >>> >> Hi,
>> >>> >>
>> >>> >> Btw, why we have such option set to false ?
>> >>> >> Michal Arbet
>> >>> >> Openstack Engineer
>> >>> >>
>> >>> >> Ultimum Technologies a.s.
>> >>> >> Na Po???? 1047/26, 11000 Praha 1
>> >>> >> Czech Republic
>> >>> >>
>> >>> >> +420 604 228 897 <>
>> >>> >> michal.arbet at ultimum.io <mailto:michal.arbet at ultimum.io>
>> >>> >> https://ultimum.io <https://ultimum.io/>
>> >>> >>
>> >>> >> LinkedIn <https://www.linkedin.com/company/ultimum-technologies> | Twitter <https://twitter.com/ultimumtech> | Facebook <https://www.facebook.com/ultimumtechnologies/timeline>
>> >>> >>
>> >>> >>
>> >>> >> ?t 11. 4. 2023 v 14:48 odes?latel Micha? Nasiadka <mnasiadka at gmail.com <mailto:mnasiadka at gmail.com>> napsal:
>> >>> >>> Hello,
>> >>> >>>
>> >>> >>> RabbitMQ HA has been backported into stable releases, and it?s documented here:
>> >>> >>> https://docs.openstack.org/kolla-ansible/yoga/reference/message-queues/rabbitmq.html#high-availability
>> >>> >>>
>> >>> >>> Best regards,
>> >>> >>> Michal
>> >>> >>>
>> >>> >>> W dniu wt., 11.04.2023 o 13:32 Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> napisa?(a):
>> >>> >>>> Yes.
>> >>> >>>> But cluster cannot work properly without it. :(
>> >>> >>>>
>> >>> >>>> On Tue, Apr 11, 2023, 6:18 PM Danny Webb <Danny.Webb at thehutgroup.com <mailto:Danny.Webb at thehutgroup.com>> wrote:
>> >>> >>>>> This commit explains why they largely removed HA queue durability:
>> >>> >>>>>
>> >>> >>>>> https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90a9a912588af0a180
>> >>> >>>>> From: Satish Patel <satish.txt at gmail.com <mailto:satish.txt at gmail.com>>
>> >>> >>>>> Sent: 09 April 2023 04:16
>> >>> >>>>> To: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>>
>> >>> >>>>> Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org <mailto:openstack-discuss at lists.openstack.org>>
>> >>> >>>>> Subject: Re: [openstack][sharing][kolla ansible]Problems when 1 of 3 controller was be down
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> CAUTION: This email originates from outside THG
>> >>> >>>>>
>> >>> >>>>> Are you proposing a solution or just raising an issue?
>> >>> >>>>>
>> >>> >>>>> I did find it strange that kolla-ansible doesn't support HA queue by default. That is a disaster because when one of the nodes goes down it will make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have to add HA policy to make queue HA otherwise you will endup in problem.
>> >>> >>>>>
>> >>> >>>>> On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> wrote:
>> >>> >>>>> Hello everyone.
>> >>> >>>>>
>> >>> >>>>> I want to summary for who meets problems with Openstack when deploy cluster with 3 controller using Kolla Ansible
>> >>> >>>>>
>> >>> >>>>> Scenario: 1 of 3 controller is down
>> >>> >>>>>
>> >>> >>>>> 1. Login horizon and use API such as nova, cinder will be very slow
>> >>> >>>>>
>> >>> >>>>> fix by:
>> >>> >>>>>
>> >>> >>>>> nano:
>> >>> >>>>> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
>> >>> >>>>> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
>> >>> >>>>> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
>> >>> >>>>> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
>> >>> >>>>> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
>> >>> >>>>>
>> >>> >>>>> or which service need caches
>> >>> >>>>>
>> >>> >>>>> add as below
>> >>> >>>>>
>> >>> >>>>> [cache]
>> >>> >>>>> backend = oslo_cache.memcache_pool
>> >>> >>>>> enabled = True
>> >>> >>>>> memcache_servers = {{ kolla_internal_vip_address }}:{{ memcached_port }}
>> >>> >>>>> memcache_dead_retry = 0.25
>> >>> >>>>> memcache_socket_timeout = 900
>> >>> >>>>>
>> >>> >>>>> https://review.opendev.org/c/openstack/kolla-ansible/+/849487
>> >>> >>>>>
>> >>> >>>>> but it is not the end
>> >>> >>>>>
>> >>> >>>>> 2. Cannot launch instance or mapping block device(stuck at this step)
>> >>> >>>>>
>> >>> >>>>> nano kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
>> >>> >>>>>
>> >>> >>>>> "policies":[
>> >>> >>>>> {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
>> >>> >>>>> {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all", "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"}, "priority":0}
>> >>> >>>>> {% endif %}
>> >>> >>>>> ]
>> >>> >>>>>
>> >>> >>>>> nano /etc/kollla/global.conf
>> >>> >>>>>
>> >>> >>>>> [oslo_messaging_rabbit]
>> >>> >>>>> kombu_reconnect_delay=0.5
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> https://bugs.launchpad.net/oslo.messaging/+bug/1993149
>> >>> >>>>> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
>> >>> >>>>>
>> >>> >>>>> I used Xena 13.4 and Yoga 14.8.1.
>> >>> >>>>>
>> >>> >>>>> Above bugs are critical, but I see that it was not fixed. I am just an operator and I want to share what I encountered for new people who come to Openstack
>> >>> >>>>>
>> >>> >>>>>
>> >>> >>>>> Nguyen Huu Khoi
>> >>> >>> --
>> >>> >>> Micha? Nasiadka
>> >>> >>> mnasiadka at gmail.com <mailto:mnasiadka at gmail.com>
>> >>>


From satish.txt at gmail.com  Wed Apr 12 15:55:18 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 12 Apr 2023 11:55:18 -0400
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CAHsN3DMRObqwwz1VGq1Lr6FKihyo4hB+EExnK9vXHmceHhBcEw@mail.gmail.com>
References: <CAHsN3DO5jMQPtxz2yUdWa=jjgG3Y3Y6GDcJQmmtpQVNkSwh55Q@mail.gmail.com>
 <CAPgF-fr1k4pQs5j6DtV5OeeCgcgjmcW7gdMS75vtxnAEx8V=sw@mail.gmail.com>
 <CABAODRdfX6aPXkCDwCxJBkwDNB7YaG4U_Z2o0=HLYeO0zWjE8A@mail.gmail.com>
 <CAHsN3DNRogsCtLJSm9VKd1YV0J+M4dwj+byWB8A2W4OZNm4W-g@mail.gmail.com>
 <CAPgF-fr9KAkJOOK1Y9z=QwEv=tW8Q6xRi9PjJ7Hp2rTrJ8=Pgw@mail.gmail.com>
 <CAHsN3DMRObqwwz1VGq1Lr6FKihyo4hB+EExnK9vXHmceHhBcEw@mail.gmail.com>
Message-ID: <CAPgF-fpCxu80Yh8JzfjjNjYEti+_Sy=QWOjdkSOiYYuZ7HVmZA@mail.gmail.com>

Matt,

After enabling om_enable_rabbitmq_high_availability: True  and
kombu_reconnect_delay=0.5  all my api services started throwing the
following logs. Even i rebuild my RabbitMQ cluster again. What could be
wrong here?

2023-04-12 15:53:40.380 391 ERROR oslo_service.service
amqp.exceptions.PreconditionFailed: Exchange.declare: (406)
PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'neutron' in
vhost '/': received 'true' but current is 'false'
2023-04-12 15:53:40.380 391 ERROR oslo_service.service
2023-04-12 15:53:40.380 391 ERROR oslo_service.service During handling of
the above exception, another exception occurred:
2023-04-12 15:53:40.380 391 ERROR oslo_service.service
2023-04-12 15:53:40.380 391 ERROR oslo_service.service Traceback (most
recent call last):
2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File
"/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_service/service.py",
line 806, in run_service
2023-04-12 15:53:40.380 391 ERROR oslo_service.service     service.start()
2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File
"/var/lib/kolla/venv/lib/python3.10/site-packages/neutron/service.py", line
115, in start
2023-04-12 15:53:40.380 391 ERROR oslo_service.service     servers =
getattr(plugin, self.start_listeners_method)()
2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File
"/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_log/helpers.py",
line 67, in wrapper
2023-04-12 15:53:40.380 391 ERROR oslo_service.service     return
method(*args, **kwargs)
2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File
"/var/lib/kolla/venv/lib/python3.10/site-packages/neutron/plugins/ml2/plugin.py",
line 425, in start_rpc_listeners
2023-04-12 15:53:40.380 391 ERROR oslo_service.service     return
self.conn.consume_in_threads()
2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File
"/var/lib/kolla/venv/lib/python3.10/site-packages/neutron_lib/rpc.py", line
351, in consume_in_threads
2023-04-12 15:53:40.380 391 ERROR oslo_service.service     server.start()
2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File
"/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/server.py",
line 267, in wrapper
2023-04-12 15:53:40.380 391 ERROR oslo_service.service
states[state].run_once(lambda: fn(self, *args, **kwargs),
2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File
"/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/server.py",
line 188, in run_once
2023-04-12 15:53:40.380 391 ERROR oslo_service.service     post_fn = fn()
2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File
"/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/server.py",
line 267, in <lambda>
2023-04-12 15:53:40.380 391 ERROR oslo_service.service
states[state].run_once(lambda: fn(self, *args, **kwargs),
2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File
"/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/server.py",
line 413, in start
2023-04-12 15:53:40.380 391 ERROR oslo_service.service     self.listener =
self._create_listener()
2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File
"/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/rpc/server.py",
line 150, in _create_listener
2023-04-12 15:53:40.380 391 ERROR oslo_service.service     return
self.transport._listen(self._target, 1, None)
2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File
"/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/transport.py",
line 142, in _listen
2023-04-12 15:53:40.380 391 ERROR oslo_service.service     return
self._driver.listen(target, batch_size,
2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File
"/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/_drivers/amqpdriver.py",
line 702, in listen
2023-04-12 15:53:40.380 391 ERROR oslo_service.service
conn.declare_topic_consumer(exchange_name=self._get_exchange(target),
2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File
"/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/_drivers/impl_rabbit.py",
line 1295, in declare_topic_consumer
2023-04-12 15:53:40.380 391 ERROR oslo_service.service
self.declare_consumer(consumer)
2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File
"/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/_drivers/impl_rabbit.py",
line 1192, in declare_consumer
2023-04-12 15:53:40.380 391 ERROR oslo_service.service     return
self.ensure(_declare_consumer,
2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File
"/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/_drivers/impl_rabbit.py",
line 977, in ensure
2023-04-12 15:53:40.380 391 ERROR oslo_service.service     raise
exceptions.MessageDeliveryFailure(msg)
2023-04-12 15:53:40.380 391 ERROR oslo_service.service
oslo_messaging.exceptions.MessageDeliveryFailure: Unable to connect to AMQP
server on 10.30.50.3:5672 after inf tries: Exchange.declare: (406)
PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'neutron' in
vhost '/': received 'true' but current is 'false'
2023-04-12 15:53:40.380 391 ERROR oslo_service.service

On Wed, Apr 12, 2023 at 11:10?AM Matt Crees <mattc at stackhpc.com> wrote:

> Hi Satish,
>
> Yes for a new deployment you will just need to set that variable to
> true. However, that will enable the high availability of RabbitMQ
> queues using a combination of classic queue mirroring and durable
> queues.
> Quorum queues are not yet supported via Kolla Ansible.
>
> Cheers,
> Matt
>
> On Wed, 12 Apr 2023 at 16:04, Satish Patel <satish.txt at gmail.com> wrote:
> >
> > Matt,
> >
> > For new deployment how do I enable the Quorum queue?
> >
> > Just adding the following should be enough?
> >
> > om_enable_rabbitmq_high_availability: True
> >
> > On Wed, Apr 12, 2023 at 10:54?AM Matt Crees <mattc at stackhpc.com> wrote:
> >>
> >> Yes, and the option also needs to be under the oslo_messaging_rabbit
> heading:
> >>
> >> [oslo_messaging_rabbit]
> >> kombu_reconnect_delay=0.5
> >>
> >>
> >> On Wed, 12 Apr 2023 at 15:45, Nguy?n H?u Kh?i <
> nguyenhuukhoinw at gmail.com> wrote:
> >> >
> >> > Hi.
> >> > Create global.conf in /etc/kolla/config/
> >> >
> >> > On Wed, Apr 12, 2023, 9:42 PM Satish Patel <satish.txt at gmail.com>
> wrote:
> >> >>
> >> >> Hi Matt,
> >> >>
> >> >> How do I set kombu_reconnect_delay=0.5 option?
> >> >>
> >> >> Something like the following in global.yml?
> >> >>
> >> >> kombu_reconnect_delay: 0.5
> >> >>
> >> >> On Wed, Apr 12, 2023 at 4:23?AM Matt Crees <mattc at stackhpc.com>
> wrote:
> >> >>>
> >> >>> Hi all,
> >> >>>
> >> >>> It seems worth noting here that there is a fix ongoing in
> >> >>> oslo.messaging which will resolve the issues with HA failing when
> one
> >> >>> node is down. See here:
> >> >>> https://review.opendev.org/c/openstack/oslo.messaging/+/866617
> >> >>> In the meantime, we have also found that setting
> kombu_reconnect_delay
> >> >>> = 0.5 does resolve this issue.
> >> >>>
> >> >>> As for why om_enable_rabbitmq_high_availability is currently
> >> >>> defaulting to false, as Michal said enabling it in stable releases
> >> >>> will impact users. This is because it enables durable queues, and
> the
> >> >>> migration from transient to durable queues is not a seamless
> >> >>> procedure. It requires that the state of RabbitMQ is reset and that
> >> >>> the OpenStack services which use RabbitMQ are restarted to recreate
> >> >>> the queues.
> >> >>>
> >> >>> I think that there is some merit in changing this default value. But
> >> >>> if we did this, we should either add additional support to automate
> >> >>> the migration from transient to durable queues, or at the very least
> >> >>> provide some decent docs on the manual procedure.
> >> >>>
> >> >>> However, as classic queue mirroring is deprecated in RabbitMQ (to be
> >> >>> removed in RabbitMQ 4.0) we should maybe consider switching to
> quorum
> >> >>> queues soon. Then it may be beneficial to leave the classic queue
> >> >>> mirroring + durable queues setup as False by default. This is
> because
> >> >>> the migration between queue types (durable or quorum) can take
> several
> >> >>> hours on larger deployments. So it might be worth making sure the
> >> >>> default values only require one migration to quorum queues in the
> >> >>> future, rather than two (durable queues now and then quorum queues
> in
> >> >>> the future).
> >> >>>
> >> >>> We will need to make this switch eventually, but right now RabbitMQ
> >> >>> 4.0 does not even have a set release date, so it's not the most
> urgent
> >> >>> change.
> >> >>>
> >> >>> Cheers,
> >> >>> Matt
> >> >>>
> >> >>> >Hi Michal,
> >> >>> >
> >> >>> >Feel free to propose change of default in master branch, but I
> don?t think we can change the default in stable branches without impacting
> users.
> >> >>> >
> >> >>> >Best regards,
> >> >>> >Michal
> >> >>> >
> >> >>> >> On 11 Apr 2023, at 15:18, Michal Arbet <michal.arbet at ultimum.io>
> wrote:
> >> >>> >>
> >> >>> >> Hi,
> >> >>> >>
> >> >>> >> Btw, why we have such option set to false ?
> >> >>> >> Michal Arbet
> >> >>> >> Openstack Engineer
> >> >>> >>
> >> >>> >> Ultimum Technologies a.s.
> >> >>> >> Na Po???? 1047/26, 11000 Praha 1
> >> >>> >> Czech Republic
> >> >>> >>
> >> >>> >> +420 604 228 897 <>
> >> >>> >> michal.arbet at ultimum.io <mailto:michal.arbet at ultimum.io>
> >> >>> >> https://ultimum.io <https://ultimum.io/>
> >> >>> >>
> >> >>> >> LinkedIn <https://www.linkedin.com/company/ultimum-technologies>
> | Twitter <https://twitter.com/ultimumtech> | Facebook <
> https://www.facebook.com/ultimumtechnologies/timeline>
> >> >>> >>
> >> >>> >>
> >> >>> >> ?t 11. 4. 2023 v 14:48 odes?latel Micha? Nasiadka <
> mnasiadka at gmail.com <mailto:mnasiadka at gmail.com>> napsal:
> >> >>> >>> Hello,
> >> >>> >>>
> >> >>> >>> RabbitMQ HA has been backported into stable releases, and it?s
> documented here:
> >> >>> >>>
> https://docs.openstack.org/kolla-ansible/yoga/reference/message-queues/rabbitmq.html#high-availability
> >> >>> >>>
> >> >>> >>> Best regards,
> >> >>> >>> Michal
> >> >>> >>>
> >> >>> >>> W dniu wt., 11.04.2023 o 13:32 Nguy?n H?u Kh?i <
> nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> napisa?(a):
> >> >>> >>>> Yes.
> >> >>> >>>> But cluster cannot work properly without it. :(
> >> >>> >>>>
> >> >>> >>>> On Tue, Apr 11, 2023, 6:18 PM Danny Webb <
> Danny.Webb at thehutgroup.com <mailto:Danny.Webb at thehutgroup.com>> wrote:
> >> >>> >>>>> This commit explains why they largely removed HA queue
> durability:
> >> >>> >>>>>
> >> >>> >>>>>
> https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90a9a912588af0a180
> >> >>> >>>>> From: Satish Patel <satish.txt at gmail.com <mailto:
> satish.txt at gmail.com>>
> >> >>> >>>>> Sent: 09 April 2023 04:16
> >> >>> >>>>> To: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:
> nguyenhuukhoinw at gmail.com>>
> >> >>> >>>>> Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org
> <mailto:openstack-discuss at lists.openstack.org>>
> >> >>> >>>>> Subject: Re: [openstack][sharing][kolla ansible]Problems when
> 1 of 3 controller was be down
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>> CAUTION: This email originates from outside THG
> >> >>> >>>>>
> >> >>> >>>>> Are you proposing a solution or just raising an issue?
> >> >>> >>>>>
> >> >>> >>>>> I did find it strange that kolla-ansible doesn't support HA
> queue by default. That is a disaster because when one of the nodes goes
> down it will make the whole rabbitMQ unacceptable. Whenever i deploy kolla
> i have to add HA policy to make queue HA otherwise you will endup in
> problem.
> >> >>> >>>>>
> >> >>> >>>>> On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <
> nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> wrote:
> >> >>> >>>>> Hello everyone.
> >> >>> >>>>>
> >> >>> >>>>> I want to summary for who meets problems with Openstack when
> deploy cluster with 3 controller using Kolla Ansible
> >> >>> >>>>>
> >> >>> >>>>> Scenario: 1 of 3 controller is down
> >> >>> >>>>>
> >> >>> >>>>> 1. Login horizon and use API such as nova, cinder will be
> very slow
> >> >>> >>>>>
> >> >>> >>>>> fix by:
> >> >>> >>>>>
> >> >>> >>>>> nano:
> >> >>> >>>>> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
> >> >>> >>>>> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
> >> >>> >>>>>
> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
> >> >>> >>>>> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
> >> >>> >>>>> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
> >> >>> >>>>>
> >> >>> >>>>> or which service need caches
> >> >>> >>>>>
> >> >>> >>>>> add as below
> >> >>> >>>>>
> >> >>> >>>>> [cache]
> >> >>> >>>>> backend = oslo_cache.memcache_pool
> >> >>> >>>>> enabled = True
> >> >>> >>>>> memcache_servers = {{ kolla_internal_vip_address }}:{{
> memcached_port }}
> >> >>> >>>>> memcache_dead_retry = 0.25
> >> >>> >>>>> memcache_socket_timeout = 900
> >> >>> >>>>>
> >> >>> >>>>> https://review.opendev.org/c/openstack/kolla-ansible/+/849487
> >> >>> >>>>>
> >> >>> >>>>> but it is not the end
> >> >>> >>>>>
> >> >>> >>>>> 2. Cannot launch instance or mapping block device(stuck at
> this step)
> >> >>> >>>>>
> >> >>> >>>>> nano
> kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
> >> >>> >>>>>
> >> >>> >>>>> "policies":[
> >> >>> >>>>> {"vhost": "/", "name": "ha-all", "pattern":
> "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition":
> {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
> >> >>> >>>>> {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name":
> "ha-all", "pattern": ".*", "apply-to": "all", "definition":
> {"ha-mode":"all"}, "priority":0}
> >> >>> >>>>> {% endif %}
> >> >>> >>>>> ]
> >> >>> >>>>>
> >> >>> >>>>> nano /etc/kollla/global.conf
> >> >>> >>>>>
> >> >>> >>>>> [oslo_messaging_rabbit]
> >> >>> >>>>> kombu_reconnect_delay=0.5
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>> https://bugs.launchpad.net/oslo.messaging/+bug/1993149
> >> >>> >>>>>
> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
> >> >>> >>>>>
> >> >>> >>>>> I used Xena 13.4 and Yoga 14.8.1.
> >> >>> >>>>>
> >> >>> >>>>> Above bugs are critical, but I see that it was not fixed. I
> am just an operator and I want to share what I encountered for new people
> who come to Openstack
> >> >>> >>>>>
> >> >>> >>>>>
> >> >>> >>>>> Nguyen Huu Khoi
> >> >>> >>> --
> >> >>> >>> Micha? Nasiadka
> >> >>> >>> mnasiadka at gmail.com <mailto:mnasiadka at gmail.com>
> >> >>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/e1131f56/attachment-0001.htm>

From mattc at stackhpc.com  Wed Apr 12 16:24:58 2023
From: mattc at stackhpc.com (Matt Crees)
Date: Wed, 12 Apr 2023 17:24:58 +0100
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CAPgF-fpCxu80Yh8JzfjjNjYEti+_Sy=QWOjdkSOiYYuZ7HVmZA@mail.gmail.com>
References: <CAHsN3DO5jMQPtxz2yUdWa=jjgG3Y3Y6GDcJQmmtpQVNkSwh55Q@mail.gmail.com>
 <CAPgF-fr1k4pQs5j6DtV5OeeCgcgjmcW7gdMS75vtxnAEx8V=sw@mail.gmail.com>
 <CABAODRdfX6aPXkCDwCxJBkwDNB7YaG4U_Z2o0=HLYeO0zWjE8A@mail.gmail.com>
 <CAHsN3DNRogsCtLJSm9VKd1YV0J+M4dwj+byWB8A2W4OZNm4W-g@mail.gmail.com>
 <CAPgF-fr9KAkJOOK1Y9z=QwEv=tW8Q6xRi9PjJ7Hp2rTrJ8=Pgw@mail.gmail.com>
 <CAHsN3DMRObqwwz1VGq1Lr6FKihyo4hB+EExnK9vXHmceHhBcEw@mail.gmail.com>
 <CAPgF-fpCxu80Yh8JzfjjNjYEti+_Sy=QWOjdkSOiYYuZ7HVmZA@mail.gmail.com>
Message-ID: <CAHsN3DNNUZLh9MtQtvRMzRzON1JTE6px0a0Xgx+pr5=dVEpf-A@mail.gmail.com>

Hi Satish,

Apologies, I would have mentioned this before but I thought when you
mentioned a new deployment you meant starting a completely fresh
deploy. As you're now reconfiguring a running deployment, there are
some extra steps that need to be taken to migrate to durable queues.

1. You will need to stop the OpenStack services which use RabbitMQ.

2. Reset the state of RabbitMQ one each rabbit node with the following
commands. You must run each command on all RabbitMQ nodes before
moving on to the next command. This will remove all queues.

    rabbitmqctl stop_app
    rabbitmqctl force_reset
    rabbitmqctl start_app

3. Start the OpenStack services again, at which point they will
recreate the appropriate queues as durable.

On Wed, 12 Apr 2023 at 16:55, Satish Patel <satish.txt at gmail.com> wrote:
>
> Matt,
>
> After enabling om_enable_rabbitmq_high_availability: True  and kombu_reconnect_delay=0.5  all my api services started throwing the following logs. Even i rebuild my RabbitMQ cluster again. What could be wrong here?
>
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service amqp.exceptions.PreconditionFailed: Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'neutron' in vhost '/': received 'true' but current is 'false'
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service During handling of the above exception, another exception occurred:
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service Traceback (most recent call last):
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File "/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_service/service.py", line 806, in run_service
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service     service.start()
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File "/var/lib/kolla/venv/lib/python3.10/site-packages/neutron/service.py", line 115, in start
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service     servers = getattr(plugin, self.start_listeners_method)()
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File "/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_log/helpers.py", line 67, in wrapper
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service     return method(*args, **kwargs)
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File "/var/lib/kolla/venv/lib/python3.10/site-packages/neutron/plugins/ml2/plugin.py", line 425, in start_rpc_listeners
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service     return self.conn.consume_in_threads()
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File "/var/lib/kolla/venv/lib/python3.10/site-packages/neutron_lib/rpc.py", line 351, in consume_in_threads
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service     server.start()
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File "/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/server.py", line 267, in wrapper
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service     states[state].run_once(lambda: fn(self, *args, **kwargs),
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File "/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/server.py", line 188, in run_once
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service     post_fn = fn()
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File "/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/server.py", line 267, in <lambda>
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service     states[state].run_once(lambda: fn(self, *args, **kwargs),
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File "/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/server.py", line 413, in start
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service     self.listener = self._create_listener()
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File "/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/rpc/server.py", line 150, in _create_listener
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service     return self.transport._listen(self._target, 1, None)
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File "/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/transport.py", line 142, in _listen
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service     return self._driver.listen(target, batch_size,
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File "/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 702, in listen
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service     conn.declare_topic_consumer(exchange_name=self._get_exchange(target),
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File "/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/_drivers/impl_rabbit.py", line 1295, in declare_topic_consumer
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service     self.declare_consumer(consumer)
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File "/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/_drivers/impl_rabbit.py", line 1192, in declare_consumer
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service     return self.ensure(_declare_consumer,
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service   File "/var/lib/kolla/venv/lib/python3.10/site-packages/oslo_messaging/_drivers/impl_rabbit.py", line 977, in ensure
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service     raise exceptions.MessageDeliveryFailure(msg)
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service oslo_messaging.exceptions.MessageDeliveryFailure: Unable to connect to AMQP server on 10.30.50.3:5672 after inf tries: Exchange.declare: (406) PRECONDITION_FAILED - inequivalent arg 'durable' for exchange 'neutron' in vhost '/': received 'true' but current is 'false'
> 2023-04-12 15:53:40.380 391 ERROR oslo_service.service
>
> On Wed, Apr 12, 2023 at 11:10?AM Matt Crees <mattc at stackhpc.com> wrote:
>>
>> Hi Satish,
>>
>> Yes for a new deployment you will just need to set that variable to
>> true. However, that will enable the high availability of RabbitMQ
>> queues using a combination of classic queue mirroring and durable
>> queues.
>> Quorum queues are not yet supported via Kolla Ansible.
>>
>> Cheers,
>> Matt
>>
>> On Wed, 12 Apr 2023 at 16:04, Satish Patel <satish.txt at gmail.com> wrote:
>> >
>> > Matt,
>> >
>> > For new deployment how do I enable the Quorum queue?
>> >
>> > Just adding the following should be enough?
>> >
>> > om_enable_rabbitmq_high_availability: True
>> >
>> > On Wed, Apr 12, 2023 at 10:54?AM Matt Crees <mattc at stackhpc.com> wrote:
>> >>
>> >> Yes, and the option also needs to be under the oslo_messaging_rabbit heading:
>> >>
>> >> [oslo_messaging_rabbit]
>> >> kombu_reconnect_delay=0.5
>> >>
>> >>
>> >> On Wed, 12 Apr 2023 at 15:45, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com> wrote:
>> >> >
>> >> > Hi.
>> >> > Create global.conf in /etc/kolla/config/
>> >> >
>> >> > On Wed, Apr 12, 2023, 9:42 PM Satish Patel <satish.txt at gmail.com> wrote:
>> >> >>
>> >> >> Hi Matt,
>> >> >>
>> >> >> How do I set kombu_reconnect_delay=0.5 option?
>> >> >>
>> >> >> Something like the following in global.yml?
>> >> >>
>> >> >> kombu_reconnect_delay: 0.5
>> >> >>
>> >> >> On Wed, Apr 12, 2023 at 4:23?AM Matt Crees <mattc at stackhpc.com> wrote:
>> >> >>>
>> >> >>> Hi all,
>> >> >>>
>> >> >>> It seems worth noting here that there is a fix ongoing in
>> >> >>> oslo.messaging which will resolve the issues with HA failing when one
>> >> >>> node is down. See here:
>> >> >>> https://review.opendev.org/c/openstack/oslo.messaging/+/866617
>> >> >>> In the meantime, we have also found that setting kombu_reconnect_delay
>> >> >>> = 0.5 does resolve this issue.
>> >> >>>
>> >> >>> As for why om_enable_rabbitmq_high_availability is currently
>> >> >>> defaulting to false, as Michal said enabling it in stable releases
>> >> >>> will impact users. This is because it enables durable queues, and the
>> >> >>> migration from transient to durable queues is not a seamless
>> >> >>> procedure. It requires that the state of RabbitMQ is reset and that
>> >> >>> the OpenStack services which use RabbitMQ are restarted to recreate
>> >> >>> the queues.
>> >> >>>
>> >> >>> I think that there is some merit in changing this default value. But
>> >> >>> if we did this, we should either add additional support to automate
>> >> >>> the migration from transient to durable queues, or at the very least
>> >> >>> provide some decent docs on the manual procedure.
>> >> >>>
>> >> >>> However, as classic queue mirroring is deprecated in RabbitMQ (to be
>> >> >>> removed in RabbitMQ 4.0) we should maybe consider switching to quorum
>> >> >>> queues soon. Then it may be beneficial to leave the classic queue
>> >> >>> mirroring + durable queues setup as False by default. This is because
>> >> >>> the migration between queue types (durable or quorum) can take several
>> >> >>> hours on larger deployments. So it might be worth making sure the
>> >> >>> default values only require one migration to quorum queues in the
>> >> >>> future, rather than two (durable queues now and then quorum queues in
>> >> >>> the future).
>> >> >>>
>> >> >>> We will need to make this switch eventually, but right now RabbitMQ
>> >> >>> 4.0 does not even have a set release date, so it's not the most urgent
>> >> >>> change.
>> >> >>>
>> >> >>> Cheers,
>> >> >>> Matt
>> >> >>>
>> >> >>> >Hi Michal,
>> >> >>> >
>> >> >>> >Feel free to propose change of default in master branch, but I don?t think we can change the default in stable branches without impacting users.
>> >> >>> >
>> >> >>> >Best regards,
>> >> >>> >Michal
>> >> >>> >
>> >> >>> >> On 11 Apr 2023, at 15:18, Michal Arbet <michal.arbet at ultimum.io> wrote:
>> >> >>> >>
>> >> >>> >> Hi,
>> >> >>> >>
>> >> >>> >> Btw, why we have such option set to false ?
>> >> >>> >> Michal Arbet
>> >> >>> >> Openstack Engineer
>> >> >>> >>
>> >> >>> >> Ultimum Technologies a.s.
>> >> >>> >> Na Po???? 1047/26, 11000 Praha 1
>> >> >>> >> Czech Republic
>> >> >>> >>
>> >> >>> >> +420 604 228 897 <>
>> >> >>> >> michal.arbet at ultimum.io <mailto:michal.arbet at ultimum.io>
>> >> >>> >> https://ultimum.io <https://ultimum.io/>
>> >> >>> >>
>> >> >>> >> LinkedIn <https://www.linkedin.com/company/ultimum-technologies> | Twitter <https://twitter.com/ultimumtech> | Facebook <https://www.facebook.com/ultimumtechnologies/timeline>
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> ?t 11. 4. 2023 v 14:48 odes?latel Micha? Nasiadka <mnasiadka at gmail.com <mailto:mnasiadka at gmail.com>> napsal:
>> >> >>> >>> Hello,
>> >> >>> >>>
>> >> >>> >>> RabbitMQ HA has been backported into stable releases, and it?s documented here:
>> >> >>> >>> https://docs.openstack.org/kolla-ansible/yoga/reference/message-queues/rabbitmq.html#high-availability
>> >> >>> >>>
>> >> >>> >>> Best regards,
>> >> >>> >>> Michal
>> >> >>> >>>
>> >> >>> >>> W dniu wt., 11.04.2023 o 13:32 Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> napisa?(a):
>> >> >>> >>>> Yes.
>> >> >>> >>>> But cluster cannot work properly without it. :(
>> >> >>> >>>>
>> >> >>> >>>> On Tue, Apr 11, 2023, 6:18 PM Danny Webb <Danny.Webb at thehutgroup.com <mailto:Danny.Webb at thehutgroup.com>> wrote:
>> >> >>> >>>>> This commit explains why they largely removed HA queue durability:
>> >> >>> >>>>>
>> >> >>> >>>>> https://opendev.org/openstack/kolla-ansible/commit/2764844ee2ff9393a4eebd90a9a912588af0a180
>> >> >>> >>>>> From: Satish Patel <satish.txt at gmail.com <mailto:satish.txt at gmail.com>>
>> >> >>> >>>>> Sent: 09 April 2023 04:16
>> >> >>> >>>>> To: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>>
>> >> >>> >>>>> Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org <mailto:openstack-discuss at lists.openstack.org>>
>> >> >>> >>>>> Subject: Re: [openstack][sharing][kolla ansible]Problems when 1 of 3 controller was be down
>> >> >>> >>>>>
>> >> >>> >>>>>
>> >> >>> >>>>> CAUTION: This email originates from outside THG
>> >> >>> >>>>>
>> >> >>> >>>>> Are you proposing a solution or just raising an issue?
>> >> >>> >>>>>
>> >> >>> >>>>> I did find it strange that kolla-ansible doesn't support HA queue by default. That is a disaster because when one of the nodes goes down it will make the whole rabbitMQ unacceptable. Whenever i deploy kolla i have to add HA policy to make queue HA otherwise you will endup in problem.
>> >> >>> >>>>>
>> >> >>> >>>>> On Sat, Apr 8, 2023 at 6:40?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com <mailto:nguyenhuukhoinw at gmail.com>> wrote:
>> >> >>> >>>>> Hello everyone.
>> >> >>> >>>>>
>> >> >>> >>>>> I want to summary for who meets problems with Openstack when deploy cluster with 3 controller using Kolla Ansible
>> >> >>> >>>>>
>> >> >>> >>>>> Scenario: 1 of 3 controller is down
>> >> >>> >>>>>
>> >> >>> >>>>> 1. Login horizon and use API such as nova, cinder will be very slow
>> >> >>> >>>>>
>> >> >>> >>>>> fix by:
>> >> >>> >>>>>
>> >> >>> >>>>> nano:
>> >> >>> >>>>> kolla-ansible/ansible/roles/heat/templates/heat.conf.j2
>> >> >>> >>>>> kolla-ansible/ansible/roles/nova/templates/nova.conf.j2
>> >> >>> >>>>> kolla-ansible/ansible/roles/keystone/templates/keystone.conf.j2
>> >> >>> >>>>> kolla-ansible/ansible/roles/neutron/templates/neutron.conf.j2
>> >> >>> >>>>> kolla-ansible/ansible/roles/cinder/templates/cinder.conf.j2
>> >> >>> >>>>>
>> >> >>> >>>>> or which service need caches
>> >> >>> >>>>>
>> >> >>> >>>>> add as below
>> >> >>> >>>>>
>> >> >>> >>>>> [cache]
>> >> >>> >>>>> backend = oslo_cache.memcache_pool
>> >> >>> >>>>> enabled = True
>> >> >>> >>>>> memcache_servers = {{ kolla_internal_vip_address }}:{{ memcached_port }}
>> >> >>> >>>>> memcache_dead_retry = 0.25
>> >> >>> >>>>> memcache_socket_timeout = 900
>> >> >>> >>>>>
>> >> >>> >>>>> https://review.opendev.org/c/openstack/kolla-ansible/+/849487
>> >> >>> >>>>>
>> >> >>> >>>>> but it is not the end
>> >> >>> >>>>>
>> >> >>> >>>>> 2. Cannot launch instance or mapping block device(stuck at this step)
>> >> >>> >>>>>
>> >> >>> >>>>> nano kolla-ansible/ansible/roles/rabbitmq/templates/definitions.json.j2
>> >> >>> >>>>>
>> >> >>> >>>>> "policies":[
>> >> >>> >>>>> {"vhost": "/", "name": "ha-all", "pattern": "^(?!(amq\.)|(.*_fanout_)|(reply_)).*", "apply-to": "all", "definition": {"ha-mode":"all"}, "priority":0}{% if project_name == 'outward_rabbitmq' %},
>> >> >>> >>>>> {"vhost": "{{ murano_agent_rabbitmq_vhost }}", "name": "ha-all", "pattern": ".*", "apply-to": "all", "definition": {"ha-mode":"all"}, "priority":0}
>> >> >>> >>>>> {% endif %}
>> >> >>> >>>>> ]
>> >> >>> >>>>>
>> >> >>> >>>>> nano /etc/kollla/global.conf
>> >> >>> >>>>>
>> >> >>> >>>>> [oslo_messaging_rabbit]
>> >> >>> >>>>> kombu_reconnect_delay=0.5
>> >> >>> >>>>>
>> >> >>> >>>>>
>> >> >>> >>>>> https://bugs.launchpad.net/oslo.messaging/+bug/1993149
>> >> >>> >>>>> https://docs.openstack.org/large-scale/journey/configure/rabbitmq.html
>> >> >>> >>>>>
>> >> >>> >>>>> I used Xena 13.4 and Yoga 14.8.1.
>> >> >>> >>>>>
>> >> >>> >>>>> Above bugs are critical, but I see that it was not fixed. I am just an operator and I want to share what I encountered for new people who come to Openstack
>> >> >>> >>>>>
>> >> >>> >>>>>
>> >> >>> >>>>> Nguyen Huu Khoi
>> >> >>> >>> --
>> >> >>> >>> Micha? Nasiadka
>> >> >>> >>> mnasiadka at gmail.com <mailto:mnasiadka at gmail.com>
>> >> >>>


From radoslaw.piliszek at gmail.com  Wed Apr 12 16:35:03 2023
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Wed, 12 Apr 2023 18:35:03 +0200
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CAHsN3DNNUZLh9MtQtvRMzRzON1JTE6px0a0Xgx+pr5=dVEpf-A@mail.gmail.com>
References: <CAHsN3DO5jMQPtxz2yUdWa=jjgG3Y3Y6GDcJQmmtpQVNkSwh55Q@mail.gmail.com>
 <CAPgF-fr1k4pQs5j6DtV5OeeCgcgjmcW7gdMS75vtxnAEx8V=sw@mail.gmail.com>
 <CABAODRdfX6aPXkCDwCxJBkwDNB7YaG4U_Z2o0=HLYeO0zWjE8A@mail.gmail.com>
 <CAHsN3DNRogsCtLJSm9VKd1YV0J+M4dwj+byWB8A2W4OZNm4W-g@mail.gmail.com>
 <CAPgF-fr9KAkJOOK1Y9z=QwEv=tW8Q6xRi9PjJ7Hp2rTrJ8=Pgw@mail.gmail.com>
 <CAHsN3DMRObqwwz1VGq1Lr6FKihyo4hB+EExnK9vXHmceHhBcEw@mail.gmail.com>
 <CAPgF-fpCxu80Yh8JzfjjNjYEti+_Sy=QWOjdkSOiYYuZ7HVmZA@mail.gmail.com>
 <CAHsN3DNNUZLh9MtQtvRMzRzON1JTE6px0a0Xgx+pr5=dVEpf-A@mail.gmail.com>
Message-ID: <CAKZ_x79aM92AxLTq0bW1OAg=WmoiHzXhfJx1eug7oNq6EtxjEQ@mail.gmail.com>

Hi Matt,

> As you're now reconfiguring a running deployment, there are
> some extra steps that need to be taken to migrate to durable queues.
>
> 1. You will need to stop the OpenStack services which use RabbitMQ.
>
> 2. Reset the state of RabbitMQ one each rabbit node with the following
> commands. You must run each command on all RabbitMQ nodes before
> moving on to the next command. This will remove all queues.
>
>     rabbitmqctl stop_app
>     rabbitmqctl force_reset
>     rabbitmqctl start_app
>
> 3. Start the OpenStack services again, at which point they will
> recreate the appropriate queues as durable.

This sounds like a great new addition-to-be to the Kolla Ansible docs!
Could you please propose it as a change?

Kindest,
Radek


From wodel.youchi at gmail.com  Wed Apr 12 16:44:20 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Wed, 12 Apr 2023 17:44:20 +0100
Subject: [Kolla-ansible][Yoga] Cannot live migrate VMs
In-Reply-To: <20230412073021.Horde.F1lstMW1fv-TZnzECX76xx8@webmail.nde.ag>
References: <CAJV_UBDGYOJG8iuEbD3eELbvDHVyCmOv--w=oJ8h=iYF4vehXg@mail.gmail.com>
 <20230412073021.Horde.F1lstMW1fv-TZnzECX76xx8@webmail.nde.ag>
Message-ID: <CAJV_UBBRjbMXKLrufXcJd+Fmeh5rGebzKYmp48=9P-8azuHvfQ@mail.gmail.com>

Thanks for the help,

I had a configuration mistake, I configured cinder with multiple stores and
when adding them I made a mistake, the name of the rbd store is rbd-1, when
I created the cinder.conf I wrote rbd1, so cinder-volume was not seeing the
rbd store correctly, after correcting the typo and deploying again,
migration worked without issues.

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/3cafef0a/attachment.htm>

From wodel.youchi at gmail.com  Wed Apr 12 16:45:32 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Wed, 12 Apr 2023 17:45:32 +0100
Subject: [kolla-ansible][yoga] how to configure cinder to connect to iscsi
 target?
In-Reply-To: <CAJV_UBDrXxBMskVzQwPJtoCQAy5VU91e9KYcwXWchf2e8rM51w@mail.gmail.com>
References: <CAJV_UBB74c78b8r1iLMdk_sX9vrFFiE4VSyOqgt=4=x15qRnYA@mail.gmail.com>
 <CABAODRePq2e7Fddt2atTxSCTv401bNp5YS-_1hUSq3NgZe_hLA@mail.gmail.com>
 <CAJV_UBDrXxBMskVzQwPJtoCQAy5VU91e9KYcwXWchf2e8rM51w@mail.gmail.com>
Message-ID: <CAJV_UBD0_oabFHLugGa2B7LBhOG_XPQ-Fhm2c94My60WandT3w@mail.gmail.com>

Hi,

Any thoughts?

Regards.

Le mar. 11 avr. 2023 ? 13:15, wodel youchi <wodel.youchi at gmail.com> a
?crit :

> Hi,
>
> What do you mean by controller status?
>
> After some digging I found that, when using
> cinder.volume.drivers.lvm.LVMVolumeDriver, it seems that cinder searches
> for the VG, and the VG must exist.
> Seeing some examples like this [1], it's like the configuration is made to
> expose a local disk as an iscsi LUN.
>
> The VG was created on a local disk, then it was exposed as LUN. So just to
> be sure, is cinder.volume.drivers.lvm.LVMVolumeDriver with target_protocol
> = iscsi, intended to expose a local VG on compute nodes as iscsi LUNs?
>
> My other question is : Can I configure cinder with  Tagetcli as external
> iscsi storage?
>
>
> [1] :
> https://www.server-world.info/en/note?os=CentOS_Stream_8&p=openstack_yoga2&f=12
>
> Regards.
>
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> Virus-free.www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#m_999205176410728176_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Mon, Apr 10, 2023, 06:33 Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> wrote:
>
>> what is your controller status?
>> Nguyen Huu Khoi
>>
>>
>> On Sun, Apr 9, 2023 at 10:36?PM wodel youchi <wodel.youchi at gmail.com>
>> wrote:
>>
>>> Hi,
>>> I am trying to configure cinder to connect to an iscsi target. I am
>>> using targetcli as my target server.
>>>
>>> I have tested the connection from the node using iscsiadm and it works
>>> from the OS.
>>>
>>> Now I am trying to use the iscsid container to do the job.
>>>
>>> I added this to my globals.yml
>>> enable_iscsid: "yes"
>>> enable_cinder_backend_iscsi: "yes"
>>> enable_cinder_backend_lvm: "no"
>>>
>>> And I created the cinder.conf file like this
>>> [DEFAULT]
>>> enabled_backends = rbd1,nfs-1,*lvmtnas *
>>>
>>> # add follows to the end
>>> [lvmtnas]
>>> target_helper = lioadm
>>> target_protocol = iscsi
>>> target_ip_address = 20.1.0.32 (my target server)
>>> volume_backend_name = lvmtnas
>>> # volume group name created
>>> volume_group = *vg_volume01 *
>>> volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
>>> use_chap_auth = false
>>>
>>> I did create the vg_volume01 on the LUN prior to the test.
>>>
>>> I did a deploy, the container has been created, but nothing happened,
>>> it's like I am missing something.
>>>
>>> docker logs iscsid fome one the compute nodes
>>> + sudo -E kolla_set_configs
>>> INFO:__main__:Loading config file at
>>> /var/lib/kolla/config_files/config.json
>>> INFO:__main__:Validating config file
>>> INFO:__main__:Kolla config strategy set to: COPY_ALWAYS
>>> INFO:__main__:Copying service configuration files
>>> INFO:__main__:Writing out command to execute
>>> ++ cat /run_command
>>> + CMD='iscsid -d 8 -f'
>>> + ARGS=
>>> + sudo kolla_copy_cacerts
>>> + [[ ! -n '' ]]
>>> + . kolla_extend_start
>>> ++ [[ ! -f /etc/iscsi/initiatorname.iscsi ]]
>>> + echo 'Running command: '\''iscsid -d 8 -f'\'''
>>> + exec iscsid -d 8 -f
>>> Running command: 'iscsid -d 8 -f'
>>> iscsid: sysfs_init: sysfs_path='/sys'
>>> iscsid: in ctldev_open
>>> iscsid: created NETLINK_ISCSI socket...
>>> iscsid: InitiatorName=iqn.1994-05.com.redhat:2a318909ad8
>>> iscsid: InitiatorName=iqn.1994-05.com.redhat:2a318909ad8
>>> iscsid: InitiatorAlias=computehci01
>>> iscsid: Max file limits 1048576 1048576
>>> iscsid: current time 258465
>>> iscsid: nothing on pend_list, deactivating alarm
>>>
>>>
>>> Any idea?
>>>
>>> Regards.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/b51023fb/attachment-0001.htm>

From rosmaita.fossdev at gmail.com  Wed Apr 12 16:49:58 2023
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Wed, 12 Apr 2023 12:49:58 -0400
Subject: [all][stable][ptl] Propose to EOL Rocky series
In-Reply-To: <VI1P18901MB07518A29DA2DDC613DB0FF80FF889@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>
References: <E1pLm0Z-001aff-0j@lists.openstack.org>
 <VI1P18901MB0751BF4E42E67D9FABC8AB51FFDE9@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>
 <e600c96d-19f9-4a14-6abf-08bd01b79d79@debian.org>
 <VI1P18901MB07518A29DA2DDC613DB0FF80FF889@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>
Message-ID: <80674f31-dd98-849f-9bce-43e385a9ba6b@gmail.com>

On 3/28/23 2:34 AM, El?d Ill?s wrote:
> Hi,
> 
> this thread was bit of forgotten, sorry for that. A bit more than two
> weeks ago we had a discussion on #openstack-release about this [1].
> 
> So, to summerize, there are the issues:
> - stable/rocky's gate is mostly broken
> - more than one third of the repositories have transitioned their
>  ? stable/rocky branch to EOL (including multiple core component)
> - old, unmaintained CI jobs, testing environments, hinders refactoring
>  ? of Zuul jobs and other configurations
> 
> On the other hand, as Thomas mentioned, there is the need for some
> to be able to cooperate (as an example: recent security issue [2],
> mentioned in previous mail or in our IRC discussion) on a common place,
> namely in gerrit.

The Cinder project team discussed this at the 2023.2 Bobcat vPTG and 
decided that we will definitely EOL rocky AND stein.  Given that other 
core projects have already done this, they've outlived their usefulness, 
even if they were only to be used to discuss patches for those branches 
in gerrit.  If a cinder patch requires patches in other services that 
have EOL'd that branch, that other service's patches can't be discussed 
in gerrit.  (And if there's an alternative place to discuss, for 
example, a nova rocky patch, then that alternative place can be used to 
discuss cinder EOL patches, too.)

> This was originally the intention with Extended
> Maintenance. We just haven't thought about eternity :)

We are also concerned about the eternal nature of older branches.  There 
are some open source projects where the convention has been to never 
delete a branch, even though at a certain point, no changes will be 
accepted into such a branch.  OpenStack, however, is not such a project, 
and we *do* delete branches.  There's a feeling among the project team 
that while a branch exists, we are still responsible for it, and there's 
an expectation that (no matter what the EM docs say), the project team 
is keeping an eye on it.  So we support the current 
declare-EOL-and-delete-the-branch policy.

Additionally, if we leave a branch in EM but turn off all CI because the 
team has no intention of ever merging anything into that branch, using 
gerrit for discussion of patches is probably unworkable as you start to 
get a bunch of patches into merge conflict, and it looks like the whole 
situation will just become a mess.

> It seems that teams feel that if a branch is 'open' and in 'Extended
> Maintenance' then it still means it is 'fully supported', thus cannot
> let the gate failing AND don't want to merge patches without gate
> tests, that's one reason why teams rather EOL their branches.

We agree.  "Not fully supported but still maintained" is a weird state. 
The way OpenStack has signaled "no more" for a branch is to delete it, 
so we continue to support the eol-and-delete policy.

> We might need to think more about what is the best way forward.

We think that rocky and stein are done deals because some projects have 
already deleted them.  The next issue is train ... is it even 
responsible to have a branch that supports Python 2 be in extended 
maintenance?  We agree that this requires some more thought.

> [1] 
> https://meetings.opendev.org/irclogs/%23openstack-release/%23openstack-release.2023-03-08.log.html#t2023-03-08T13:54:34
> [2] https://security.openstack.org/ossa/OSSA-2023-002.html
> 
> El?d
> irc: elodilles
> 
> ------------------------------------------------------------------------
> *From:* Thomas Goirand <zigo at debian.org>
> *Sent:* Tuesday, February 14, 2023 7:31 PM
> *To:* El?d Ill?s <elod.illes at est.tech>
> *Cc:* openstack-discuss at lists.openstack.org 
> <openstack-discuss at lists.openstack.org>
> *Subject:* Re: [all][stable][ptl] Propose to EOL Rocky series
> On 2/10/23 18:26, El?d Ill?s wrote:
>> Hi,
>> 
>> thanks for all the feedbacks from teams so far!
>> 
>> @Zigo: Extended Maintenance process was created just for the same 
>> situation: to give space to interested parties to cooperate and keep 
>> things maintained even when stable releases are over their 'supported' 
>> lifetime. So it's good to see that there is interest in it! 
>> Unfortunately, with very old branches we've reached the state where 
>> gates can't be maintained and without a functional gate it's not safe to 
>> merge patches (yes, even security fixes) and they are just using 
>> resources (CI & maintainers' time). When gate is broken in such extent, 
>> then i think the community have to accept that it is not possible to 
>> merge patches confidently and needs to EOL that release.
> 
> That's where I don't agree. There are ways, outside of the OpenStack
> gate, to test things, in such ways that merging patches there can be a
> thing.
> 
>> Another aspect is that code cannot be cleaned up until those old 
>> branches are still present (CI jobs, project configurations, etc) which 
>> gives pain for developers.
> 
> Just disable gating completely then.
> 
>> So, however some vendors would appreciate probably to keep things open 
>> forever, for the community this is not beneficial and doable I think. 
> 
> I don't agree. We need a place to share patches between distros. The
> official Git feels like the natural place to do so, even without any
> type of gating.
> 
> BTW, my Nova patches for CVE-2022-47951 in Rocky, Stein & Train are
> currently wrong and need another approach. I was thinking about simply
> disabling .vmdk altogether (rather than having a complicated code to
> check for the VMDK subtype). I wonder what other distros did. Where do I
> disucss this?
> 
> Cheers,
> 
> Thomas Goirand (zigo)
> 



From nguyenhuukhoinw at gmail.com  Wed Apr 12 16:54:44 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Wed, 12 Apr 2023 23:54:44 +0700
Subject: [kolla-ansible][yoga] how to configure cinder to connect to iscsi
 target?
In-Reply-To: <CAJV_UBD0_oabFHLugGa2B7LBhOG_XPQ-Fhm2c94My60WandT3w@mail.gmail.com>
References: <CAJV_UBB74c78b8r1iLMdk_sX9vrFFiE4VSyOqgt=4=x15qRnYA@mail.gmail.com>
 <CABAODRePq2e7Fddt2atTxSCTv401bNp5YS-_1hUSq3NgZe_hLA@mail.gmail.com>
 <CAJV_UBDrXxBMskVzQwPJtoCQAy5VU91e9KYcwXWchf2e8rM51w@mail.gmail.com>
 <CAJV_UBD0_oabFHLugGa2B7LBhOG_XPQ-Fhm2c94My60WandT3w@mail.gmail.com>
Message-ID: <CABAODRfRxYqhyEDbgrsi-R=9_zcPK=AciQzKbY5sBcRGkCZJCA@mail.gmail.com>

Hello.
It depends on cinder driver.
https://docs.openstack.org/cinder/latest/drivers.html


On Wed, Apr 12, 2023, 11:45 PM wodel youchi <wodel.youchi at gmail.com> wrote:

> Hi,
>
> Any thoughts?
>
> Regards.
>
> Le mar. 11 avr. 2023 ? 13:15, wodel youchi <wodel.youchi at gmail.com> a
> ?crit :
>
>> Hi,
>>
>> What do you mean by controller status?
>>
>> After some digging I found that, when using
>> cinder.volume.drivers.lvm.LVMVolumeDriver, it seems that cinder searches
>> for the VG, and the VG must exist.
>> Seeing some examples like this [1], it's like the configuration is made
>> to expose a local disk as an iscsi LUN.
>>
>> The VG was created on a local disk, then it was exposed as LUN. So just
>> to be sure, is cinder.volume.drivers.lvm.LVMVolumeDriver with
>> target_protocol = iscsi, intended to expose a local VG on compute nodes as
>> iscsi LUNs?
>>
>> My other question is : Can I configure cinder with  Tagetcli as external
>> iscsi storage?
>>
>>
>> [1] :
>> https://www.server-world.info/en/note?os=CentOS_Stream_8&p=openstack_yoga2&f=12
>>
>> Regards.
>>
>>
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>> Virus-free.www.avast.com
>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
>> <#m_-8391729476659671118_m_1391200188812930768_m_999205176410728176_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> On Mon, Apr 10, 2023, 06:33 Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
>> wrote:
>>
>>> what is your controller status?
>>> Nguyen Huu Khoi
>>>
>>>
>>> On Sun, Apr 9, 2023 at 10:36?PM wodel youchi <wodel.youchi at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>> I am trying to configure cinder to connect to an iscsi target. I am
>>>> using targetcli as my target server.
>>>>
>>>> I have tested the connection from the node using iscsiadm and it works
>>>> from the OS.
>>>>
>>>> Now I am trying to use the iscsid container to do the job.
>>>>
>>>> I added this to my globals.yml
>>>> enable_iscsid: "yes"
>>>> enable_cinder_backend_iscsi: "yes"
>>>> enable_cinder_backend_lvm: "no"
>>>>
>>>> And I created the cinder.conf file like this
>>>> [DEFAULT]
>>>> enabled_backends = rbd1,nfs-1,*lvmtnas *
>>>>
>>>> # add follows to the end
>>>> [lvmtnas]
>>>> target_helper = lioadm
>>>> target_protocol = iscsi
>>>> target_ip_address = 20.1.0.32 (my target server)
>>>> volume_backend_name = lvmtnas
>>>> # volume group name created
>>>> volume_group = *vg_volume01 *
>>>> volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
>>>> use_chap_auth = false
>>>>
>>>> I did create the vg_volume01 on the LUN prior to the test.
>>>>
>>>> I did a deploy, the container has been created, but nothing happened,
>>>> it's like I am missing something.
>>>>
>>>> docker logs iscsid fome one the compute nodes
>>>> + sudo -E kolla_set_configs
>>>> INFO:__main__:Loading config file at
>>>> /var/lib/kolla/config_files/config.json
>>>> INFO:__main__:Validating config file
>>>> INFO:__main__:Kolla config strategy set to: COPY_ALWAYS
>>>> INFO:__main__:Copying service configuration files
>>>> INFO:__main__:Writing out command to execute
>>>> ++ cat /run_command
>>>> + CMD='iscsid -d 8 -f'
>>>> + ARGS=
>>>> + sudo kolla_copy_cacerts
>>>> + [[ ! -n '' ]]
>>>> + . kolla_extend_start
>>>> ++ [[ ! -f /etc/iscsi/initiatorname.iscsi ]]
>>>> + echo 'Running command: '\''iscsid -d 8 -f'\'''
>>>> + exec iscsid -d 8 -f
>>>> Running command: 'iscsid -d 8 -f'
>>>> iscsid: sysfs_init: sysfs_path='/sys'
>>>> iscsid: in ctldev_open
>>>> iscsid: created NETLINK_ISCSI socket...
>>>> iscsid: InitiatorName=iqn.1994-05.com.redhat:2a318909ad8
>>>> iscsid: InitiatorName=iqn.1994-05.com.redhat:2a318909ad8
>>>> iscsid: InitiatorAlias=computehci01
>>>> iscsid: Max file limits 1048576 1048576
>>>> iscsid: current time 258465
>>>> iscsid: nothing on pend_list, deactivating alarm
>>>>
>>>>
>>>> Any idea?
>>>>
>>>> Regards.
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/daccc625/attachment.htm>

From wodel.youchi at gmail.com  Wed Apr 12 17:39:13 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Wed, 12 Apr 2023 18:39:13 +0100
Subject: [kolla-ansible][yoga] Glance backend cinder Privsep daemon failed to
 start operation not permitted
Message-ID: <CAJV_UBC95fMQh00w7vxbyV55F=wXuLXjgVYG5fYy08en2VYtaA@mail.gmail.com>

Hi,

I am trying to configure glance to use cinder as a backend.

This is my glance-api.conf
[cinder]
cinder_store_auth_address = https://dashint.example.com:5000/v3
cinder_store_user_name = cinder
cinder_store_password = cinderpass
cinder_store_project_name = service
cinder_volume_type = nfstype
rootwrap_config = /etc/glance/rootwrap.conf



==> /var/log/kolla/glance/glance-api.log <==
> 2023-04-12 18:02:20.842 64 INFO oslo.privsep.daemon
> [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 - default default] Spawned new privsep
> daemon via rootwrap
> 2023-04-12 18:02:20.733 360 INFO oslo.privsep.daemon [-] privsep daemon
> starting
> 2023-04-12 18:02:20.735 360 INFO oslo.privsep.daemon [-] privsep process
> running with uid/gid: 0/0
>
> *2023-04-12 18:02:20.737 360 ERROR oslo.privsep.daemon [-] [Errno 1]
> Operation not permitted Traceback (most recent call last): *
>  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
> line 584, in helper_main
>    Daemon(channel, context).run()
>  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
> line 394, in run
>    self._drop_privs()
>  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
> line 430, in _drop_privs
>    capabilities.drop_all_caps_except(self.caps, self.caps, [])
>  File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/capabilities.py",
> line 156, in drop_all_caps_except
>    raise OSError(errno, os.strerror(errno))
> PermissionError: [Errno 1] Operation not permitted
> 2023-04-12 18:02:20.844 64 WARNING oslo_privsep.comm
> [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 - default
> default] Unexpected error: <class 'BrokenPipeError'>: BrokenPipeError:
> [Errno 32] Broken pipe
> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon
> [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 - default
> default] Error while sending initial PING to privsep: [Errno 32] Broken
> pipe: BrokenPipeError: [Errno 32] Broken pipe
> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon Traceback (most
> recent call last):
> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
> line 192, in exchange_ping
> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon     reply =
> self.send_recv((comm.Message.PING.value,))
> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/comm.py",
> line 186, in send_recv
> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon
>     self.writer.send((myid, msg))
> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/comm.py",
> line 60, in send
> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon
>     self.writesock.sendall(buf)
> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/greenio/base.py",
> line 407, in sendall
> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon     tail =
> self.send(data, flags)
> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/greenio/base.py",
> line 401, in send
> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon     return
> self._send_loop(self.fd.send, data, flags)
> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/greenio/base.py",
> line 388, in _send_loop
> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon     return
> send_method(data, *args)
> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon BrokenPipeError:
> [Errno 32] Broken pipe
> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon
> 2023-04-12 18:02:20.846 64 CRITICAL oslo.privsep.daemon
> [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 - defau
> lt default] Privsep daemon failed to start
> 2023-04-12 18:02:20.847 64 ERROR glance_store._drivers.cinder
> [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 -
> default default] Failed to write to volume
> 46316c12-6c24-40af-afde-1c16edd616b6.:
> oslo_privsep.daemon.FailedToDropPrivileges: Privsep daemon failed to start
> 2023-04-12 18:02:20.890 64 ERROR glance.api.v2.image_data
> [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 - def
> ault default] *Failed to upload image data due to internal error:
> oslo_privsep.daemon.FailedToDropPrivileges: Privsep daemon failed to start *
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
> [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 - default d
> efault] Caught error: Privsep daemon failed to start:
> oslo_privsep.daemon.FailedToDropPrivileges: Privsep daemon failed to start
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi Traceback (most recent
> call last):
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/wsgi.py",
> line 1332, in __call__
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     request,
> **action_args)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/wsgi.py",
> line 1370, in dispatch
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     return
> method(*args, **kwargs)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/utils.py",
> line 414, in wrapped
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     return func(self,
> req, *args, **kwargs)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/api/v2/image_data.py",
> line 303, in upload
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>     self._restore(image_repo, image)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 227, in __exit__
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>     self.force_reraise()
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 200, in force_reraise
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     raise self.value
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/api/v2/image_data.py",
> line 163, in upload
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>     image.set_data(data, size, backend=backend)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/notifier.py", line
> 497, in set_data
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>     _send_notification(notify_error, 'image.upload', msg)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 227, in __exit__
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>     self.force_reraise()
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 200, in force_reraise
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     raise self.value
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/notifier.py", line
> 444, in set_data
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>     set_active=set_active)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/quota/__init__.py",
> line 323, in set_data
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>     set_active=set_active)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/location.py", line
> 585, in set_data
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>     self._upload_to_store(data, verifier, backend, size)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/location.py", line
> 485, in _upload_to_store
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     verifier=verifier)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/multi_backend.py",
> line 399, in add_with_multihash
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     image_id, data,
> size, hashing_algo, store, context, verifier)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/multi_backend.py",
> line 481, in store_add_to_backe
> nd_with_multihash
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     image_id, data,
> size, hashing_algo, context=context, verifier=verifier)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/driver.py",
> line 279, in add_adapter
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     metadata_dict) =
> store_add_fun(*args, **kwargs)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/capabilities.py",
> line 176, in op_checker
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     return
> store_op_fun(store, *args, **kwargs)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py",
> line 985, in add
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     with
> self._open_cinder_volume(client, volume, 'wb') as f:
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/usr/lib64/python3.6/contextlib.py", line 81, in __enter__
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     return
> next(self.gen)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py",
> line 739, in _open_cinder_vol
> ume
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     root_helper,
> my_ip, use_multipath, enforce_multipath, host=host)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/utils.py", line
> 169, in trace_logging_wrapper
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     return f(*args,
> **kwargs)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/initiator/connector.py",
> line 240, in get_connector_pr
> operties
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     execute=execute))
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py",
> line 70, in get_connec
> tor_properties
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     initiator =
> iscsi.get_initiator()
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py",
> line 963, in get_initi
> ator
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>     root_helper=self._root_helper)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/executor.py",
> line 53, in _execute
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     result =
> self.__execute(*args, **kwargs)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/privileged/rootwrap.py",
> line 172, in execute
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     return
> execute_root(*cmd, **kwargs)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/priv_context.py",
> line 269, in _wrap
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     self.start()
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/priv_context.py",
> line 283, in start
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     channel =
> daemon.RootwrapClientChannel(context=self)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
> line 374, in __init__
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>     super(RootwrapClientChannel, self).__init__(sock, context)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
> line 187, in __init__
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>     self.exchange_ping()
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
> line 201, in exchange_ping
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     raise
> FailedToDropPrivileges(msg)
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi *oslo_privsep.daemon.FailedToDropPrivileges:
> Privsep daemon failed to start *
> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
> 2023-04-12 18:02:20.927 64 INFO eventlet.wsgi.server
> [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 - default
> default] 20.3.0.34,127.0.0.1 - - [12/Apr/2023 18:02:20] "PUT
> /v2/images/52ed7ed7-330e-4249-abb9-5ec99712846f/file HTTP/1.1" 500 430
> 2.727683
>

It seems like a lack of privileges, any ideas?

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/b6a2aefa/attachment-0001.htm>

From gmann at ghanshyammann.com  Wed Apr 12 17:49:26 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 12 Apr 2023 10:49:26 -0700
Subject: =?UTF-8?Q?Re:_=E7=AD=94=E5=A4=8D:_[ptl]_Need_PTL_vol?=
 =?UTF-8?Q?unteer_for_OpenStack_Sahara?=
In-Reply-To: <1876bee150d.ee4aa6ae296851.8453515049256805786@ghanshyammann.com>
References: <1870a9accaa.ca4d3931996653.2888367201531485088@ghanshyammann.com>
 <5133a1c69a4e4d579514eccaa03dd8cd@inspur.com>
 <7d2aa6aaffb844e3b28517cdba3b7c54@inspur.com>
 <1cceee9b4afa459d9c64c1c106304b85@inspur.com>
 <f477d35f70f04f448533e422dd5ca38b@inspur.com>
 <1876bee150d.ee4aa6ae296851.8453515049256805786@ghanshyammann.com>
Message-ID: <18776962f8e.b5be9467498529.2443601353157879154@ghanshyammann.com>

Hi Jerry,

We discussed it in the TC meeting[1], and below is the summary and next step:

* Sahara has been almost unmaintained in the last cycle, even though we had PTL volunteering to lead/maintain it.

* From the PTL role, we expect the project to keep its testing/gate green, merge the incoming review requests,
and do the releases on time. For example, if no maintainer is left in any project (which is the Sahara case), then its
PTL's responsibility is to get all those project's basic maintenance done (by onboarding new maintainers or by themself)
otherwise, inform TC about it so we can decide on the project status on time. 

* Next step:
Thanks for volunteering and helping to maintain the Sahara project. Please propose the governance patch to
PTL appointment, and TC will review it. Example: https://review.opendev.org/c/openstack/governance/+/878286

[1] https://meetings.opendev.org/meetings/tc/2023/tc.2023-04-11-17.59.log.html#l-83

-gmann

 ---- On Mon, 10 Apr 2023 09:09:37 -0700  Ghanshyam Mann  wrote --- 
 > Thanks Jerry, Brin for the updates and showing interest in Sahara project.
 > 
 > In PTG discussion, there were some concern on  Sahara maintenance even 
 > we had PTL volunteer to lead this project but not much things got merged and
 > gate was broken many times. But let me discuss it in TC meeting tomorrow and
 > update here.
 > 
 > -gmann
 > 
 >  ---- On Mon, 10 Apr 2023 00:22:08 -0700  Brin Zhang(???)  wrote --- 
 >  > Hi Gmann,
 >  > ????Jerry Zhou works the same company as qiujunting (Qiujunting has out of the office, so he cannot response us, I am so sorry), and he will be involved in Sahara.
 >  > ????Hope TC can add him in Sahara team, let him gradually complete the maintenance of the Sahara project.
 >  > ????Thanks.
 >  > 
 >  > brinzhang
 >  > 
 >  > -----????-----
 >  > ???: Jerry Zhou (???) zhouxinyong at inspur.com> 
 >  > ????: 2023?4?7? 11:10
 >  > ???: gmann at ghanshyammann.com; Juntingqiu Qiujunting (???) qiujunting at inspur.com>
 >  > ??: openstack-discuss at lists.openstack.org; Tom Guo(??2810) guotao.bj at inspur.com>; Brin Zhang(???) zhangbailin at inspur.com>; Weiting Kong (???) kongweiting at inspur.com>
 >  > ??: ??: [ptl] Need PTL volunteer for OpenStack Sahara
 >  > 
 >  > Hi Gmann,
 >  >   I can lead this project.
 >  > 
 >  > -----????-----
 >  > ???: Ghanshyam Mann gmann at ghanshyammann.com>
 >  > ????: 2023?3?23? 2:35
 >  > ???: Qiujunting qiujunting at inspur.com>; openstack-discuss openstack-discuss at lists.openstack.org>
 >  > ??: [ptl] Need PTL volunteer for OpenStack Sahara
 >  > 
 >  > Hi Qiu,
 >  > 
 >  > I am reaching out to you as you were PTL for OpenStack Sahara project in the last cycle.
 >  > 
 >  > There is no PTL candidate for the next cycle (2023.2), and it is on the leaderless project list. Please check if you or anyone you know would like to lead this project.
 >  > 
 >  > - https://etherpad.opendev.org/p/2023.2-leaderless
 >  > 
 >  > Also, if anyone else would like to help leading this project, this is time to let TC knows.
 >  > 
 >  > -gmann
 >  > 
 >  > 
 > 


From satish.txt at gmail.com  Wed Apr 12 17:53:31 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 12 Apr 2023 13:53:31 -0400
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CAKZ_x79aM92AxLTq0bW1OAg=WmoiHzXhfJx1eug7oNq6EtxjEQ@mail.gmail.com>
References: <CAHsN3DO5jMQPtxz2yUdWa=jjgG3Y3Y6GDcJQmmtpQVNkSwh55Q@mail.gmail.com>
 <CAPgF-fr1k4pQs5j6DtV5OeeCgcgjmcW7gdMS75vtxnAEx8V=sw@mail.gmail.com>
 <CABAODRdfX6aPXkCDwCxJBkwDNB7YaG4U_Z2o0=HLYeO0zWjE8A@mail.gmail.com>
 <CAHsN3DNRogsCtLJSm9VKd1YV0J+M4dwj+byWB8A2W4OZNm4W-g@mail.gmail.com>
 <CAPgF-fr9KAkJOOK1Y9z=QwEv=tW8Q6xRi9PjJ7Hp2rTrJ8=Pgw@mail.gmail.com>
 <CAHsN3DMRObqwwz1VGq1Lr6FKihyo4hB+EExnK9vXHmceHhBcEw@mail.gmail.com>
 <CAPgF-fpCxu80Yh8JzfjjNjYEti+_Sy=QWOjdkSOiYYuZ7HVmZA@mail.gmail.com>
 <CAHsN3DNNUZLh9MtQtvRMzRzON1JTE6px0a0Xgx+pr5=dVEpf-A@mail.gmail.com>
 <CAKZ_x79aM92AxLTq0bW1OAg=WmoiHzXhfJx1eug7oNq6EtxjEQ@mail.gmail.com>
Message-ID: <CAPgF-fosH2eS6CMDCnLoOHy6U+9aVQJXye7LAJqVPNjSRYeSoQ@mail.gmail.com>

This is great! Matt,

Documentation would be greatly appreciated. I have a counter question: does
Durable queue be good for large clouds with 1000 compute nodes or better to
not use durable queue. This is a private cloud and we don't care about
persistent data.

On Wed, Apr 12, 2023 at 12:37?PM Rados?aw Piliszek <
radoslaw.piliszek at gmail.com> wrote:

> Hi Matt,
>
> > As you're now reconfiguring a running deployment, there are
> > some extra steps that need to be taken to migrate to durable queues.
> >
> > 1. You will need to stop the OpenStack services which use RabbitMQ.
> >
> > 2. Reset the state of RabbitMQ one each rabbit node with the following
> > commands. You must run each command on all RabbitMQ nodes before
> > moving on to the next command. This will remove all queues.
> >
> >     rabbitmqctl stop_app
> >     rabbitmqctl force_reset
> >     rabbitmqctl start_app
> >
> > 3. Start the OpenStack services again, at which point they will
> > recreate the appropriate queues as durable.
>
> This sounds like a great new addition-to-be to the Kolla Ansible docs!
> Could you please propose it as a change?
>
> Kindest,
> Radek
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/6cef67d8/attachment.htm>

From abishop at redhat.com  Wed Apr 12 18:12:24 2023
From: abishop at redhat.com (Alan Bishop)
Date: Wed, 12 Apr 2023 11:12:24 -0700
Subject: [kolla-ansible][yoga] Glance backend cinder Privsep daemon failed
 to start operation not permitted
In-Reply-To: <CAJV_UBC95fMQh00w7vxbyV55F=wXuLXjgVYG5fYy08en2VYtaA@mail.gmail.com>
References: <CAJV_UBC95fMQh00w7vxbyV55F=wXuLXjgVYG5fYy08en2VYtaA@mail.gmail.com>
Message-ID: <CADO3vb4++zhHTu3Gfdsb3pYZFMdwGSytDuXhN0QZ-JCdVFqu7A@mail.gmail.com>

On Wed, Apr 12, 2023 at 10:41?AM wodel youchi <wodel.youchi at gmail.com>
wrote:

> Hi,
>
> I am trying to configure glance to use cinder as a backend.
>
> This is my glance-api.conf
> [cinder]
> cinder_store_auth_address = https://dashint.example.com:5000/v3
> cinder_store_user_name = cinder
> cinder_store_password = cinderpass
> cinder_store_project_name = service
> cinder_volume_type = nfstype
> rootwrap_config = /etc/glance/rootwrap.conf
>
>
>
> ==> /var/log/kolla/glance/glance-api.log <==
>> 2023-04-12 18:02:20.842 64 INFO oslo.privsep.daemon
>> [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default default] Spawned new privsep
>> daemon via rootwrap
>> 2023-04-12 18:02:20.733 360 INFO oslo.privsep.daemon [-] privsep daemon
>> starting
>> 2023-04-12 18:02:20.735 360 INFO oslo.privsep.daemon [-] privsep process
>> running with uid/gid: 0/0
>>
>> *2023-04-12 18:02:20.737 360 ERROR oslo.privsep.daemon [-] [Errno 1]
>> Operation not permitted Traceback (most recent call last): *
>>  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
>> line 584, in helper_main
>>    Daemon(channel, context).run()
>>  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
>> line 394, in run
>>    self._drop_privs()
>>  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
>> line 430, in _drop_privs
>>    capabilities.drop_all_caps_except(self.caps, self.caps, [])
>>  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/capabilities.py",
>> line 156, in drop_all_caps_except
>>    raise OSError(errno, os.strerror(errno))
>> PermissionError: [Errno 1] Operation not permitted
>> 2023-04-12 18:02:20.844 64 WARNING oslo_privsep.comm
>> [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default
>> default] Unexpected error: <class 'BrokenPipeError'>: BrokenPipeError:
>> [Errno 32] Broken pipe
>> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon
>> [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default
>> default] Error while sending initial PING to privsep: [Errno 32] Broken
>> pipe: BrokenPipeError: [Errno 32] Broken pipe
>> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon Traceback (most
>> recent call last):
>> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
>> line 192, in exchange_ping
>> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon     reply =
>> self.send_recv((comm.Message.PING.value,))
>> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/comm.py",
>> line 186, in send_recv
>> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon
>>     self.writer.send((myid, msg))
>> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/comm.py",
>> line 60, in send
>> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon
>>     self.writesock.sendall(buf)
>> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/greenio/base.py",
>> line 407, in sendall
>> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon     tail =
>> self.send(data, flags)
>> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/greenio/base.py",
>> line 401, in send
>> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon     return
>> self._send_loop(self.fd.send, data, flags)
>> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/greenio/base.py",
>> line 388, in _send_loop
>> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon     return
>> send_method(data, *args)
>> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon BrokenPipeError:
>> [Errno 32] Broken pipe
>> 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon
>> 2023-04-12 18:02:20.846 64 CRITICAL oslo.privsep.daemon
>> [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - defau
>> lt default] Privsep daemon failed to start
>> 2023-04-12 18:02:20.847 64 ERROR glance_store._drivers.cinder
>> [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 -
>> default default] Failed to write to volume
>> 46316c12-6c24-40af-afde-1c16edd616b6.:
>> oslo_privsep.daemon.FailedToDropPrivileges: Privsep daemon failed to start
>> 2023-04-12 18:02:20.890 64 ERROR glance.api.v2.image_data
>> [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - def
>> ault default] *Failed to upload image data due to internal error:
>> oslo_privsep.daemon.FailedToDropPrivileges: Privsep daemon failed to start *
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>> [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default d
>> efault] Caught error: Privsep daemon failed to start:
>> oslo_privsep.daemon.FailedToDropPrivileges: Privsep daemon failed to start
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi Traceback (most
>> recent call last):
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/wsgi.py",
>> line 1332, in __call__
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     request,
>> **action_args)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/wsgi.py",
>> line 1370, in dispatch
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     return
>> method(*args, **kwargs)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/utils.py",
>> line 414, in wrapped
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     return func(self,
>> req, *args, **kwargs)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/api/v2/image_data.py",
>> line 303, in upload
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>>     self._restore(image_repo, image)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>>     self.force_reraise()
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     raise self.value
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/api/v2/image_data.py",
>> line 163, in upload
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>>     image.set_data(data, size, backend=backend)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/notifier.py", line
>> 497, in set_data
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>>     _send_notification(notify_error, 'image.upload', msg)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>>     self.force_reraise()
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     raise self.value
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/notifier.py", line
>> 444, in set_data
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>>     set_active=set_active)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/quota/__init__.py",
>> line 323, in set_data
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>>     set_active=set_active)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/location.py", line
>> 585, in set_data
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>>     self._upload_to_store(data, verifier, backend, size)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/location.py", line
>> 485, in _upload_to_store
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>>     verifier=verifier)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/multi_backend.py",
>> line 399, in add_with_multihash
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     image_id, data,
>> size, hashing_algo, store, context, verifier)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/multi_backend.py",
>> line 481, in store_add_to_backe
>> nd_with_multihash
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     image_id, data,
>> size, hashing_algo, context=context, verifier=verifier)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/driver.py",
>> line 279, in add_adapter
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     metadata_dict) =
>> store_add_fun(*args, **kwargs)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/capabilities.py",
>> line 176, in op_checker
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     return
>> store_op_fun(store, *args, **kwargs)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py",
>> line 985, in add
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     with
>> self._open_cinder_volume(client, volume, 'wb') as f:
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/usr/lib64/python3.6/contextlib.py", line 81, in __enter__
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     return
>> next(self.gen)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py",
>> line 739, in _open_cinder_vol
>> ume
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     root_helper,
>> my_ip, use_multipath, enforce_multipath, host=host)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/utils.py", line
>> 169, in trace_logging_wrapper
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     return f(*args,
>> **kwargs)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/initiator/connector.py",
>> line 240, in get_connector_pr
>> operties
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     execute=execute))
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py",
>> line 70, in get_connec
>> tor_properties
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     initiator =
>> iscsi.get_initiator()
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py",
>> line 963, in get_initi
>> ator
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>>     root_helper=self._root_helper)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/executor.py",
>> line 53, in _execute
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     result =
>> self.__execute(*args, **kwargs)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/privileged/rootwrap.py",
>> line 172, in execute
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     return
>> execute_root(*cmd, **kwargs)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/priv_context.py",
>> line 269, in _wrap
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     self.start()
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/priv_context.py",
>> line 283, in start
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     channel =
>> daemon.RootwrapClientChannel(context=self)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
>> line 374, in __init__
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>>     super(RootwrapClientChannel, self).__init__(sock, context)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
>> line 187, in __init__
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>>     self.exchange_ping()
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
>> line 201, in exchange_ping
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     raise
>> FailedToDropPrivileges(msg)
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi *oslo_privsep.daemon.FailedToDropPrivileges:
>> Privsep daemon failed to start *
>> 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
>> 2023-04-12 18:02:20.927 64 INFO eventlet.wsgi.server
>> [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default
>> default] 20.3.0.34,127.0.0.1 - - [12/Apr/2023 18:02:20] "PUT
>> /v2/images/52ed7ed7-330e-4249-abb9-5ec99712846f/file HTTP/1.1" 500 430
>> 2.727683
>>
>
> It seems like a lack of privileges, any ideas?
>

Yes, the glance-api container itself must run with "privileged: true" when
glance is using cinder for a backend. For reference, you can see how
TripleO handles this:

https://github.com/openstack/tripleo-heat-templates/blob/2e6d826debd6099b3d85d0268430541b01560139/deployment/glance/glance-api-container-puppet.yaml#L790

Alan



>
> Regards.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/127c8e4d/attachment-0001.htm>

From satish.txt at gmail.com  Wed Apr 12 18:12:47 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 12 Apr 2023 14:12:47 -0400
Subject: [kolla-ansible][mariadb] socat: Connection reset by peer
In-Reply-To: <CA+eLJkaeY4Gb8Gk7wVZg4sbU-zcdJjpfYFd__-Y_6B7t_uGwrg@mail.gmail.com>
References: <CAPgF-fp7eZa+Hn6CEUvt7fw=S4PQsKmNuuy8+evp8oEBoQWuBA@mail.gmail.com>
 <CA+eLJkaeY4Gb8Gk7wVZg4sbU-zcdJjpfYFd__-Y_6B7t_uGwrg@mail.gmail.com>
Message-ID: <CAPgF-fqsRrZxPf5_YjzpZKY1KCKz-pSMgoKO8D9Q4=0M=2=uDg@mail.gmail.com>

I have checked the mysql limit and it's very high and usage is way below
the limit using them. It's a very small deployment in the lab.

Following is the docker container running that check

(mariadb-clustercheck)[root at kolla-infra-1-2 /]# ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.0   2632   924 ?        Ss   Apr04   0:00
dumb-init --single-child -- kolla_start
root           7  0.0  0.0  10280  4760 ?        S    Apr04   8:19 socat -d
-lf/var/log/kolla/mariadb/mariadb-clustercheck.log
tcp-l:4569,fork,reuseaddr,bind=10.30.50.2 EXEC:clustercheck
root     2070140  0.0  0.0   7624  4240 pts/0    Ss   18:08   0:00 bash
root     2070999  0.0  0.0  10060  1596 pts/0    R+   18:09   0:00 ps aux

When i run manually i got successful reply

(mariadb-clustercheck)[root at kolla-infra-1-2 /]# clustercheck
HTTP/1.1 200 OK
Content-Type: text/plain
Connection: close
Content-Length: 32

Galera cluster node is synced.

Everything looks ok so far. Not sure if I should ignore that error message
or consider it bad.


On Tue, Apr 11, 2023 at 11:07?PM Alvaro Soto <alsotoes at gmail.com> wrote:

> Hey,
> I don't have too much kolla hands-on experience, but it'll be nice if you
> can post SOCAT configurations, specific to the MySQL health check.
> Also, the number 8192 is the default maximum connection value; could you
> check if you are hitting that limit?
>
> Cheers!
>
> On Tue, Apr 11, 2023 at 8:49?PM Satish Patel <satish.txt at gmail.com> wrote:
>
>> Folks,
>>
>> I am getting the following errors in logs constantly and continually. I
>> have 3 node galera clusters. Everything looks good except this error making
>> me nervous. I have deployed Zed release of kolla openstack.
>>
>> ==> /var/log/kolla/mariadb/mariadb-clustercheck.log <==
>> 2023/04/12 02:42:16 socat[1574755] W read(7, 0x5653c4a4c000, 8192):
>> Connection reset by peer
>> 2023/04/12 02:42:16 socat[1574761] W read(7, 0x5653c4a4c000, 8192):
>> Connection reset by peer
>> 2023/04/12 02:42:16 socat[1574755] W read(6, 0x5653c4a4c000, 8192):
>> Connection reset by peer
>> 2023/04/12 02:42:16 socat[1574761] W read(6, 0x5653c4a4c000, 8192):
>> Connection reset by peer
>> 2023/04/12 02:42:18 socat[1574767] W read(7, 0x5653c4a4c000, 8192):
>> Connection reset by peer
>> 2023/04/12 02:42:18 socat[1574767] W read(6, 0x5653c4a4c000, 8192):
>> Connection reset by peer
>>
>
>
> --
>
> Alvaro Soto
>
> *Note: My work hours may not be your work hours. Please do not feel the
> need to respond during a time that is not convenient for you.*
> ----------------------------------------------------------
> Great people talk about ideas,
> ordinary people talk about things,
> small people talk... about other people.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/83652397/attachment.htm>

From smooney at redhat.com  Wed Apr 12 19:13:03 2023
From: smooney at redhat.com (Sean Mooney)
Date: Wed, 12 Apr 2023 20:13:03 +0100
Subject: [kolla-ansible][yoga] Glance backend cinder Privsep daemon
 failed to start operation not permitted
In-Reply-To: <CADO3vb4++zhHTu3Gfdsb3pYZFMdwGSytDuXhN0QZ-JCdVFqu7A@mail.gmail.com>
References: <CAJV_UBC95fMQh00w7vxbyV55F=wXuLXjgVYG5fYy08en2VYtaA@mail.gmail.com>
 <CADO3vb4++zhHTu3Gfdsb3pYZFMdwGSytDuXhN0QZ-JCdVFqu7A@mail.gmail.com>
Message-ID: <323313cf9ef907a0bbbdce18e7ae71654385e1f2.camel@redhat.com>

On Wed, 2023-04-12 at 11:12 -0700, Alan Bishop wrote:
> On Wed, Apr 12, 2023 at 10:41?AM wodel youchi <wodel.youchi at gmail.com>
> wrote:
> 
> > Hi,
> > 
> > I am trying to configure glance to use cinder as a backend.
> > 
> > This is my glance-api.conf
> > [cinder]
> > cinder_store_auth_address = https://dashint.example.com:5000/v3
> > cinder_store_user_name = cinder
> > cinder_store_password = cinderpass
> > cinder_store_project_name = service
> > cinder_volume_type = nfstype
> > rootwrap_config = /etc/glance/rootwrap.conf
> > 
> > 
> > 
> > ==> /var/log/kolla/glance/glance-api.log <==
> > > 2023-04-12 18:02:20.842 64 INFO oslo.privsep.daemon
> > > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
> > > b0f76b5c6dcb457fa716762bbf954837 - default default] Spawned new privsep
> > > daemon via rootwrap
> > > 2023-04-12 18:02:20.733 360 INFO oslo.privsep.daemon [-] privsep daemon
> > > starting
> > > 2023-04-12 18:02:20.735 360 INFO oslo.privsep.daemon [-] privsep process
> > > running with uid/gid: 0/0
> > > 
> > > *2023-04-12 18:02:20.737 360 ERROR oslo.privsep.daemon [-] [Errno 1]
> > > Operation not permitted Traceback (most recent call last): *
> > >  File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
> > > line 584, in helper_main
> > >    Daemon(channel, context).run()
> > >  File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
> > > line 394, in run
> > >    self._drop_privs()
> > >  File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
> > > line 430, in _drop_privs
> > >    capabilities.drop_all_caps_except(self.caps, self.caps, [])
> > >  File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/capabilities.py",
> > > line 156, in drop_all_caps_except
> > >    raise OSError(errno, os.strerror(errno))
> > > PermissionError: [Errno 1] Operation not permitted
> > > 2023-04-12 18:02:20.844 64 WARNING oslo_privsep.comm
> > > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
> > > b0f76b5c6dcb457fa716762bbf954837 - default
> > > default] Unexpected error: <class 'BrokenPipeError'>: BrokenPipeError:
> > > [Errno 32] Broken pipe
> > > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon
> > > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
> > > b0f76b5c6dcb457fa716762bbf954837 - default
> > > default] Error while sending initial PING to privsep: [Errno 32] Broken
> > > pipe: BrokenPipeError: [Errno 32] Broken pipe
> > > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon Traceback (most
> > > recent call last):
> > > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
> > > line 192, in exchange_ping
> > > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon     reply =
> > > self.send_recv((comm.Message.PING.value,))
> > > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/comm.py",
> > > line 186, in send_recv
> > > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon
> > >     self.writer.send((myid, msg))
> > > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/comm.py",
> > > line 60, in send
> > > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon
> > >     self.writesock.sendall(buf)
> > > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/greenio/base.py",
> > > line 407, in sendall
> > > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon     tail =
> > > self.send(data, flags)
> > > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/greenio/base.py",
> > > line 401, in send
> > > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon     return
> > > self._send_loop(self.fd.send, data, flags)
> > > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/eventlet/greenio/base.py",
> > > line 388, in _send_loop
> > > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon     return
> > > send_method(data, *args)
> > > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon BrokenPipeError:
> > > [Errno 32] Broken pipe
> > > 2023-04-12 18:02:20.844 64 ERROR oslo.privsep.daemon
> > > 2023-04-12 18:02:20.846 64 CRITICAL oslo.privsep.daemon
> > > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
> > > b0f76b5c6dcb457fa716762bbf954837 - defau
> > > lt default] Privsep daemon failed to start
> > > 2023-04-12 18:02:20.847 64 ERROR glance_store._drivers.cinder
> > > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
> > > b0f76b5c6dcb457fa716762bbf954837 -
> > > default default] Failed to write to volume
> > > 46316c12-6c24-40af-afde-1c16edd616b6.:
> > > oslo_privsep.daemon.FailedToDropPrivileges: Privsep daemon failed to start
> > > 2023-04-12 18:02:20.890 64 ERROR glance.api.v2.image_data
> > > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
> > > b0f76b5c6dcb457fa716762bbf954837 - def
> > > ault default] *Failed to upload image data due to internal error:
> > > oslo_privsep.daemon.FailedToDropPrivileges: Privsep daemon failed to start *
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
> > > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
> > > b0f76b5c6dcb457fa716762bbf954837 - default d
> > > efault] Caught error: Privsep daemon failed to start:
> > > oslo_privsep.daemon.FailedToDropPrivileges: Privsep daemon failed to start
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi Traceback (most
> > > recent call last):
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/wsgi.py",
> > > line 1332, in __call__
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     request,
> > > **action_args)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/wsgi.py",
> > > line 1370, in dispatch
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     return
> > > method(*args, **kwargs)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/utils.py",
> > > line 414, in wrapped
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     return func(self,
> > > req, *args, **kwargs)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/api/v2/image_data.py",
> > > line 303, in upload
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
> > >     self._restore(image_repo, image)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> > > line 227, in __exit__
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
> > >     self.force_reraise()
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> > > line 200, in force_reraise
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     raise self.value
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/api/v2/image_data.py",
> > > line 163, in upload
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
> > >     image.set_data(data, size, backend=backend)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/notifier.py", line
> > > 497, in set_data
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
> > >     _send_notification(notify_error, 'image.upload', msg)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> > > line 227, in __exit__
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
> > >     self.force_reraise()
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> > > line 200, in force_reraise
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     raise self.value
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/notifier.py", line
> > > 444, in set_data
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
> > >     set_active=set_active)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/quota/__init__.py",
> > > line 323, in set_data
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
> > >     set_active=set_active)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/location.py", line
> > > 585, in set_data
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
> > >     self._upload_to_store(data, verifier, backend, size)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/location.py", line
> > > 485, in _upload_to_store
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
> > >     verifier=verifier)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/multi_backend.py",
> > > line 399, in add_with_multihash
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     image_id, data,
> > > size, hashing_algo, store, context, verifier)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/multi_backend.py",
> > > line 481, in store_add_to_backe
> > > nd_with_multihash
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     image_id, data,
> > > size, hashing_algo, context=context, verifier=verifier)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/driver.py",
> > > line 279, in add_adapter
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     metadata_dict) =
> > > store_add_fun(*args, **kwargs)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/capabilities.py",
> > > line 176, in op_checker
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     return
> > > store_op_fun(store, *args, **kwargs)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py",
> > > line 985, in add
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     with
> > > self._open_cinder_volume(client, volume, 'wb') as f:
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/usr/lib64/python3.6/contextlib.py", line 81, in __enter__
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     return
> > > next(self.gen)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py",
> > > line 739, in _open_cinder_vol
> > > ume
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     root_helper,
> > > my_ip, use_multipath, enforce_multipath, host=host)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/utils.py", line
> > > 169, in trace_logging_wrapper
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     return f(*args,
> > > **kwargs)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/initiator/connector.py",
> > > line 240, in get_connector_pr
> > > operties
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     execute=execute))
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py",
> > > line 70, in get_connec
> > > tor_properties
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     initiator =
> > > iscsi.get_initiator()
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/initiator/connectors/iscsi.py",
> > > line 963, in get_initi
> > > ator
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
> > >     root_helper=self._root_helper)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/executor.py",
> > > line 53, in _execute
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     result =
> > > self.__execute(*args, **kwargs)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/os_brick/privileged/rootwrap.py",
> > > line 172, in execute
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     return
> > > execute_root(*cmd, **kwargs)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/priv_context.py",
> > > line 269, in _wrap
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     self.start()
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/priv_context.py",
> > > line 283, in start
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     channel =
> > > daemon.RootwrapClientChannel(context=self)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
> > > line 374, in __init__
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
> > >     super(RootwrapClientChannel, self).__init__(sock, context)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
> > > line 187, in __init__
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
> > >     self.exchange_ping()
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi   File
> > > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_privsep/daemon.py",
> > > line 201, in exchange_ping
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi     raise
> > > FailedToDropPrivileges(msg)
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi *oslo_privsep.daemon.FailedToDropPrivileges:
> > > Privsep daemon failed to start *
> > > 2023-04-12 18:02:20.908 64 ERROR glance.common.wsgi
> > > 2023-04-12 18:02:20.927 64 INFO eventlet.wsgi.server
> > > [req-62883866-1b53-4032-bdc4-d9a294a837c4 0439953e7cfe4a13a1b4bb118b5dc3c4
> > > b0f76b5c6dcb457fa716762bbf954837 - default
> > > default] 20.3.0.34,127.0.0.1 - - [12/Apr/2023 18:02:20] "PUT
> > > /v2/images/52ed7ed7-330e-4249-abb9-5ec99712846f/file HTTP/1.1" 500 430
> > > 2.727683
> > > 
> > 
> > It seems like a lack of privileges, any ideas?
> > 
> 
> Yes, the glance-api container itself must run with "privileged: true" when
> glance is using cinder for a backend. For reference, you can see how
> TripleO handles this:
> 
> https://github.com/openstack/tripleo-heat-templates/blob/2e6d826debd6099b3d85d0268430541b01560139/deployment/glance/glance-api-container-puppet.yaml#L790

that should work in yoga i have my home cloud using glance-api with cinder back storage

sean at cloud:~/repos/kolla-ansible$ cat /etc/kolla/config/glance/glance-api.conf 
[DEFAULT]
enabled_import_methods = ['glance-direct','web-download','copy-image']
enabled_backends = local:cinder
cinder_catalog_info = volumev3:cinderv3:internalURL
show_multiple_locations = True
show_image_direct_url = True

[glance_store]
default_backend = local
default_store = cinder
stores = cinder

[keystone_authtoken]
interface = internal

[local]
cinder_volume_type = local_storage
description = LVM based cinder store
cinder_catalog_info = volumev3:cinderv3:internalURL
cinder_store_auth_address = {{ keystone_internal_url }}
cinder_store_project_name = service
cinder_store_user_name = {{ glance_keystone_user }}
cinder_store_password =  {{ glance_keystone_password }}


my glance options in gobal.yamlare

########################
# Glance - Image Options
########################
# Configure image backend.
#glance_backend_ceph: "no"
glance_backend_file: "no"
#glance_backend_swift: "no"
#glance_backend_vmware: "no"
#enable_glance_image_cache: "no"
glance_enable_property_protection: "no"
glance_enable_interoperable_image_import: "yes"
# Configure glance upgrade option.
# Due to this feature being experimental in glance,
# the default value is "no".
#glance_enable_rolling_upgrade: "no"


and cinder lvm

# Cinder - Block Storage Options
################################
# Enable / disable Cinder backends
#cinder_backend_ceph: "no"
#cinder_backend_vmwarevc_vmdk: "no"
#cinder_backend_vmware_vstorage_object: "no"
cinder_volume_group: "cinder-volumes"
# Valid options are [ '', redis, etcd ]
cinder_coordination_backend: ""

on the cidner side i have
sean at cloud:~/repos/kolla-ansible$ cat /etc/kolla/config/cinder.conf 
[DEFAULT]
allowed_direct_url_schemes = cinder
[lvm-1]
image_upload_use_cinder_backend = True
image_upload_use_internal_tenant = True

otherwise i requried no other change in kolla-ansible stable/yoga

commit bf1e29c87b52cd4a75f484c1f16c265fdb09b5fa (HEAD -> stable/yoga, origin/stable/yoga)
Merge: 4ee8667f1 f4e6dcc3b
Author: Zuul <zuul at review.opendev.org>
Date:   Tue Sep 20 10:00:54 2022 +0000

    Merge "Fix prometheus-msteams image name" into stable/yoga



perhaps the nfs type has extra requiement btu lvm should work.


> 
> Alan
> 
> 
> 
> > 
> > Regards.
> > 
> > 



From jamesleong123098 at gmail.com  Wed Apr 12 22:04:05 2023
From: jamesleong123098 at gmail.com (James Leong)
Date: Wed, 12 Apr 2023 17:04:05 -0500
Subject: [zun][zun_api][blazar][config][yoga][kolla-ansible] Adding more
 configuration to config file
Message-ID: <CA+_ZFmEQDi=FfOcFJOMWnvCBG7-x2QJ-fKSmWMitBfpKPaXXGg@mail.gmail.com>

Hi all,

I am playing around with Zun. I have used kolla-ansible as a deployment
tool for deploying the yoga version of OpenStack. I am trying to add an
option to the configuration file. However, those added options are not
recognized by OpenStack when being called. For instance, Zun.conf, I am
adding a new database (blazar) information to it so I can access blazar
information in the zun service. Would that be possible to allow the zun_api
container to access the blazar database?

Thanks for your help,
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/27256700/attachment.htm>

From kkloppenborg at rwts.com.au  Wed Apr 12 23:24:17 2023
From: kkloppenborg at rwts.com.au (Karl Kloppenborg)
Date: Wed, 12 Apr 2023 23:24:17 +0000
Subject: Updating OS-TRAITS in placement stable/yoga and stable/zed
Message-ID: <PS2PR01MB2197DD6CBACFEE5758A13066F49B9@PS2PR01MB2197.apcprd01.prod.exchangelabs.com>

Hello Placement and OS-Traits teams.
Karl from Openstack-Helm.

After debugging a number of issues in Cyborg, it has become necessary to update the pinned OS-TRAITs version in stable/yoga and stable/zed.
I have submitted the following two reviews for updating the pinned versions to 2.10.0

https://review.opendev.org/c/openstack/placement/+/880249
https://review.opendev.org/c/openstack/placement/+/880249

By merging these changes, it will allow us to continue to use vGPU capabilities in cyborg in the stable/yoga and stable/zed onwards branches.


Kind Regards,
--
Karl Kloppenborg, (BCompSc, CNCF-[KCNA, CKA, CKAD], LFCE, CompTIA Linux+ XK0-004)
Managing Director, Invention Labs.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/eb4bbb33/attachment.htm>

From tony at bakeyournoodle.com  Thu Apr 13 00:00:49 2023
From: tony at bakeyournoodle.com (Tony Breeds)
Date: Wed, 12 Apr 2023 19:00:49 -0500
Subject: Updating OS-TRAITS in placement stable/yoga and stable/zed
In-Reply-To: <PS2PR01MB2197DD6CBACFEE5758A13066F49B9@PS2PR01MB2197.apcprd01.prod.exchangelabs.com>
References: <PS2PR01MB2197DD6CBACFEE5758A13066F49B9@PS2PR01MB2197.apcprd01.prod.exchangelabs.com>
Message-ID: <CAFT5D2SA_2=xo7Kc-q-x4ZdV4G4eP=LRnbu+Az-gUGHpA9fiQg@mail.gmail.com>

On Wed, 12 Apr 2023 at 18:27, Karl Kloppenborg <kkloppenborg at rwts.com.au>
wrote:

> Hello Placement and OS-Traits teams.
>
> Karl from Openstack-Helm.
>
>
>
> After debugging a number of issues in Cyborg, it has become necessary to
> update the pinned OS-TRAITs version in stable/yoga and stable/zed.
>
> I have submitted the following two reviews for updating the pinned
> versions to 2.10.0
>
>
>
> https://review.opendev.org/c/openstack/placement/+/880249
>
> https://review.opendev.org/c/openstack/placement/+/880249
>

This won't do what you want.  The version that will be installed is
controlled by constraints in the openstack/requirements repo

https://opendev.org/openstack/requirements/src/branch/stable/yoga/upper-constraints.txt#L388
and
https://opendev.org/openstack/requirements/src/branch/stable/zed/upper-constraints.txt#L361

We don't typically allow this kind of bump on stable branches as it often
indicates a feature backport which we avoid in order to keep the release
and gate stable.

So we could *potentially* do what you need but the community as a whole
will need to understand the rationale for why.  Upping the version on a
stable branch will also have vendor impacts for supported versions of
os-traints.

By merging these changes, it will allow us to continue to use vGPU
> capabilities in cyborg in the stable/yoga and stable/zed onwards branches.
>

Continue to use?  Please help us understand this.

Tony.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230412/f2f7bc60/attachment.htm>

From nguyenhuukhoinw at gmail.com  Thu Apr 13 02:02:19 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Thu, 13 Apr 2023 09:02:19 +0700
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CAPgF-fosH2eS6CMDCnLoOHy6U+9aVQJXye7LAJqVPNjSRYeSoQ@mail.gmail.com>
References: <CAHsN3DO5jMQPtxz2yUdWa=jjgG3Y3Y6GDcJQmmtpQVNkSwh55Q@mail.gmail.com>
 <CAPgF-fr1k4pQs5j6DtV5OeeCgcgjmcW7gdMS75vtxnAEx8V=sw@mail.gmail.com>
 <CABAODRdfX6aPXkCDwCxJBkwDNB7YaG4U_Z2o0=HLYeO0zWjE8A@mail.gmail.com>
 <CAHsN3DNRogsCtLJSm9VKd1YV0J+M4dwj+byWB8A2W4OZNm4W-g@mail.gmail.com>
 <CAPgF-fr9KAkJOOK1Y9z=QwEv=tW8Q6xRi9PjJ7Hp2rTrJ8=Pgw@mail.gmail.com>
 <CAHsN3DMRObqwwz1VGq1Lr6FKihyo4hB+EExnK9vXHmceHhBcEw@mail.gmail.com>
 <CAPgF-fpCxu80Yh8JzfjjNjYEti+_Sy=QWOjdkSOiYYuZ7HVmZA@mail.gmail.com>
 <CAHsN3DNNUZLh9MtQtvRMzRzON1JTE6px0a0Xgx+pr5=dVEpf-A@mail.gmail.com>
 <CAKZ_x79aM92AxLTq0bW1OAg=WmoiHzXhfJx1eug7oNq6EtxjEQ@mail.gmail.com>
 <CAPgF-fosH2eS6CMDCnLoOHy6U+9aVQJXye7LAJqVPNjSRYeSoQ@mail.gmail.com>
Message-ID: <CABAODReZ011H=Gv0V9FEnmyRNFoWtmOK6LXOFhFN-J39dMVS4Q@mail.gmail.com>

Hello guys.

I do many tests on xena and yoga. then i am sure that without ha-queue and
kombu_reconnect_delay=0.5(it can < 1)
you cannot launch instances when 1 of 3 controllers is down.
Somebody can verify what I say, I hope we will have a common solution for
this problem because those who use openstack for the first time will
continue to ask questions like that.

Nguyen Huu Khoi


On Thu, Apr 13, 2023 at 12:59?AM Satish Patel <satish.txt at gmail.com> wrote:

> This is great! Matt,
>
> Documentation would be greatly appreciated. I have a counter question:
> does Durable queue be good for large clouds with 1000 compute nodes or
> better to not use durable queue. This is a private cloud and we don't care
> about persistent data.
>
> On Wed, Apr 12, 2023 at 12:37?PM Rados?aw Piliszek <
> radoslaw.piliszek at gmail.com> wrote:
>
>> Hi Matt,
>>
>> > As you're now reconfiguring a running deployment, there are
>> > some extra steps that need to be taken to migrate to durable queues.
>> >
>> > 1. You will need to stop the OpenStack services which use RabbitMQ.
>> >
>> > 2. Reset the state of RabbitMQ one each rabbit node with the following
>> > commands. You must run each command on all RabbitMQ nodes before
>> > moving on to the next command. This will remove all queues.
>> >
>> >     rabbitmqctl stop_app
>> >     rabbitmqctl force_reset
>> >     rabbitmqctl start_app
>> >
>> > 3. Start the OpenStack services again, at which point they will
>> > recreate the appropriate queues as durable.
>>
>> This sounds like a great new addition-to-be to the Kolla Ansible docs!
>> Could you please propose it as a change?
>>
>> Kindest,
>> Radek
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230413/74f228be/attachment-0001.htm>

From nguyenhuukhoinw at gmail.com  Thu Apr 13 02:04:12 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Thu, 13 Apr 2023 09:04:12 +0700
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CABAODReZ011H=Gv0V9FEnmyRNFoWtmOK6LXOFhFN-J39dMVS4Q@mail.gmail.com>
References: <CAHsN3DO5jMQPtxz2yUdWa=jjgG3Y3Y6GDcJQmmtpQVNkSwh55Q@mail.gmail.com>
 <CAPgF-fr1k4pQs5j6DtV5OeeCgcgjmcW7gdMS75vtxnAEx8V=sw@mail.gmail.com>
 <CABAODRdfX6aPXkCDwCxJBkwDNB7YaG4U_Z2o0=HLYeO0zWjE8A@mail.gmail.com>
 <CAHsN3DNRogsCtLJSm9VKd1YV0J+M4dwj+byWB8A2W4OZNm4W-g@mail.gmail.com>
 <CAPgF-fr9KAkJOOK1Y9z=QwEv=tW8Q6xRi9PjJ7Hp2rTrJ8=Pgw@mail.gmail.com>
 <CAHsN3DMRObqwwz1VGq1Lr6FKihyo4hB+EExnK9vXHmceHhBcEw@mail.gmail.com>
 <CAPgF-fpCxu80Yh8JzfjjNjYEti+_Sy=QWOjdkSOiYYuZ7HVmZA@mail.gmail.com>
 <CAHsN3DNNUZLh9MtQtvRMzRzON1JTE6px0a0Xgx+pr5=dVEpf-A@mail.gmail.com>
 <CAKZ_x79aM92AxLTq0bW1OAg=WmoiHzXhfJx1eug7oNq6EtxjEQ@mail.gmail.com>
 <CAPgF-fosH2eS6CMDCnLoOHy6U+9aVQJXye7LAJqVPNjSRYeSoQ@mail.gmail.com>
 <CABAODReZ011H=Gv0V9FEnmyRNFoWtmOK6LXOFhFN-J39dMVS4Q@mail.gmail.com>
Message-ID: <CABAODRfixPQGnENxpWT4nvPkmGU27X1Amzs=oyHvZ_VHxPLqVw@mail.gmail.com>

update:
I use SAN as Cinder backend.
Nguyen Huu Khoi


On Thu, Apr 13, 2023 at 9:02?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Hello guys.
>
> I do many tests on xena and yoga. then i am sure that without ha-queue and
> kombu_reconnect_delay=0.5(it can < 1)
> you cannot launch instances when 1 of 3 controllers is down.
> Somebody can verify what I say, I hope we will have a common solution for
> this problem because those who use openstack for the first time will
> continue to ask questions like that.
>
> Nguyen Huu Khoi
>
>
> On Thu, Apr 13, 2023 at 12:59?AM Satish Patel <satish.txt at gmail.com>
> wrote:
>
>> This is great! Matt,
>>
>> Documentation would be greatly appreciated. I have a counter question:
>> does Durable queue be good for large clouds with 1000 compute nodes or
>> better to not use durable queue. This is a private cloud and we don't care
>> about persistent data.
>>
>> On Wed, Apr 12, 2023 at 12:37?PM Rados?aw Piliszek <
>> radoslaw.piliszek at gmail.com> wrote:
>>
>>> Hi Matt,
>>>
>>> > As you're now reconfiguring a running deployment, there are
>>> > some extra steps that need to be taken to migrate to durable queues.
>>> >
>>> > 1. You will need to stop the OpenStack services which use RabbitMQ.
>>> >
>>> > 2. Reset the state of RabbitMQ one each rabbit node with the following
>>> > commands. You must run each command on all RabbitMQ nodes before
>>> > moving on to the next command. This will remove all queues.
>>> >
>>> >     rabbitmqctl stop_app
>>> >     rabbitmqctl force_reset
>>> >     rabbitmqctl start_app
>>> >
>>> > 3. Start the OpenStack services again, at which point they will
>>> > recreate the appropriate queues as durable.
>>>
>>> This sounds like a great new addition-to-be to the Kolla Ansible docs!
>>> Could you please propose it as a change?
>>>
>>> Kindest,
>>> Radek
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230413/a9768048/attachment.htm>

From nguyenhuukhoinw at gmail.com  Thu Apr 13 06:44:43 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Thu, 13 Apr 2023 13:44:43 +0700
Subject: Does cinder-backup support multi-backend?
In-Reply-To: <0966efa7-8b53-8b84-255d-cefaeddd0384@inovex.de>
References: <CAJV_UBAwDcy7Adob712AVYa0uK0txsoJbi3U83Fjy2G6UFhyiQ@mail.gmail.com>
 <CABAODRfY9v6muyZw34yxk25npgFUc4LfTe594Ng8VUUXA334DQ@mail.gmail.com>
 <CABAODRd=ps4S8pPcHgSkpdyKzbwtkS6_YXzUZpx1dU71NXNDRg@mail.gmail.com>
 <CABAODRedjYcb0NDeemMHCfSMSiken=iaDQqpkQQVq57dE+XiaA@mail.gmail.com>
 <CABAODReU3fBhPi0co77y=2qXM+u1u8mVpH4XxRiXVoX12_hsnw@mail.gmail.com>
 <CAARK8KTgRYDGG=ZsckZD_3-_yXR8NpHAzZa-4sT_m-iPto2KrQ@mail.gmail.com>
 <0966efa7-8b53-8b84-255d-cefaeddd0384@inovex.de>
Message-ID: <CABAODReW4Ky8JpjySp2BXZ4aryR3Uu+ZBWGZv7T5gErt7KfgnQ@mail.gmail.com>

Hello.
I feel that people don't use cinder-backup because it is slow and not show
more stats such as how many percent to complete a backup job,
Nguyen Huu Khoi


On Wed, Apr 12, 2023 at 2:06?PM Christian Rohmann <
christian.rohmann at inovex.de> wrote:

> Wondel, Kh?i,
>
>
> On 06/04/2023 09:39, Rajat Dhasmana wrote:
> > Currently configuring multiple cinder backup backends is not supported.
> > This was brought up in our last cinder meeting on 06 April, 2023[1].
> > A spec was proposed to implement this[2] but there aren't any patches
> > to implement this.
> > Christian Rohmann (crohmann on IRC) has shown interest in this topic,
> > so probably you can contact him about the details and can collaborate
> > on the effort.
> >
> > [1]
> >
> https://meetings.opendev.org/irclogs/%23openstack-meeting-alt/%23openstack-meeting-alt.2023-04-05.log.html#t2023-04-05T14:50:24
> > [2] https://review.opendev.org/c/openstack/cinder-specs/+/712301
>
>
> I am just as interested as you to have this feature.
> First to allow transitioning from one backup backend to another, but
> also to offer multiple "types" of backups.
> One could i.e. be "onsite" the other "offsite".
>
> I gladly rework the spec and propose it for Bobcat. But I do not have
> the capacity to implement this.
> Yes, cinder itself and the already present support for different volume
> types could serve as some kind of blueprint, but having more than one
> type of backup storage likely is a little more complicated to implement
> and transition to as it first appears.
>
> So what are your thoughts on the matter then?
>
>
> Regards
>
> Christian
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230413/735c59f2/attachment.htm>

From mattc at stackhpc.com  Thu Apr 13 08:07:19 2023
From: mattc at stackhpc.com (Matt Crees)
Date: Thu, 13 Apr 2023 09:07:19 +0100
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CABAODRfixPQGnENxpWT4nvPkmGU27X1Amzs=oyHvZ_VHxPLqVw@mail.gmail.com>
References: <CAHsN3DO5jMQPtxz2yUdWa=jjgG3Y3Y6GDcJQmmtpQVNkSwh55Q@mail.gmail.com>
 <CAPgF-fr1k4pQs5j6DtV5OeeCgcgjmcW7gdMS75vtxnAEx8V=sw@mail.gmail.com>
 <CABAODRdfX6aPXkCDwCxJBkwDNB7YaG4U_Z2o0=HLYeO0zWjE8A@mail.gmail.com>
 <CAHsN3DNRogsCtLJSm9VKd1YV0J+M4dwj+byWB8A2W4OZNm4W-g@mail.gmail.com>
 <CAPgF-fr9KAkJOOK1Y9z=QwEv=tW8Q6xRi9PjJ7Hp2rTrJ8=Pgw@mail.gmail.com>
 <CAHsN3DMRObqwwz1VGq1Lr6FKihyo4hB+EExnK9vXHmceHhBcEw@mail.gmail.com>
 <CAPgF-fpCxu80Yh8JzfjjNjYEti+_Sy=QWOjdkSOiYYuZ7HVmZA@mail.gmail.com>
 <CAHsN3DNNUZLh9MtQtvRMzRzON1JTE6px0a0Xgx+pr5=dVEpf-A@mail.gmail.com>
 <CAKZ_x79aM92AxLTq0bW1OAg=WmoiHzXhfJx1eug7oNq6EtxjEQ@mail.gmail.com>
 <CAPgF-fosH2eS6CMDCnLoOHy6U+9aVQJXye7LAJqVPNjSRYeSoQ@mail.gmail.com>
 <CABAODReZ011H=Gv0V9FEnmyRNFoWtmOK6LXOFhFN-J39dMVS4Q@mail.gmail.com>
 <CABAODRfixPQGnENxpWT4nvPkmGU27X1Amzs=oyHvZ_VHxPLqVw@mail.gmail.com>
Message-ID: <CAHsN3DMv0JZr=bovHJtUiRuy-a5wFo9GG48L4Y9eH3Rr+6GXkw@mail.gmail.com>

Hi all, I'll reply in turn here:

Radek, I agree it definitely will be a good addition to the KA docs.
I've got it on my radar, will aim to get a patch proposed this week.

Satish, I haven't personally been able to test durable queues on a
system that large. According to the RabbitMQ docs
(https://www.rabbitmq.com/queues.html#durability), "Throughput and
latency of a queue is not affected by whether a queue is durable or
not in most cases." However, I have anecdotally heard that it can
affect some performance in particularly large systems.

Please note that if you are using the classic mirrored queues, you
must also have them durable. Transient (i.e. non-durable) mirrored
queues are not a supported feature and do cause bugs. (For example the
"old incarnation" errors seen here:
https://bugs.launchpad.net/kolla-ansible/+bug/1954925)

Nguyen, I can confirm that we've seen the same behaviour. This is
caused by a backported change in oslo.messaging (I believe you linked
the relevant bug report previously). There is a fix in progress to fix
this (https://review.opendev.org/c/openstack/oslo.messaging/+/866617),
and in the meantime setting kombu_reconnect_delay < 1.0 does resolve
it.

Cheers,
Matt

On Thu, 13 Apr 2023 at 03:04, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com> wrote:
>
> update:
> I use SAN as Cinder backend.
> Nguyen Huu Khoi
>
>
> On Thu, Apr 13, 2023 at 9:02?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com> wrote:
>>
>> Hello guys.
>>
>> I do many tests on xena and yoga. then i am sure that without ha-queue and kombu_reconnect_delay=0.5(it can < 1)
>> you cannot launch instances when 1 of 3 controllers is down.
>> Somebody can verify what I say, I hope we will have a common solution for this problem because those who use openstack for the first time will continue to ask questions like that.
>>
>> Nguyen Huu Khoi
>>
>>
>> On Thu, Apr 13, 2023 at 12:59?AM Satish Patel <satish.txt at gmail.com> wrote:
>>>
>>> This is great! Matt,
>>>
>>> Documentation would be greatly appreciated. I have a counter question: does Durable queue be good for large clouds with 1000 compute nodes or better to not use durable queue. This is a private cloud and we don't care about persistent data.
>>>
>>> On Wed, Apr 12, 2023 at 12:37?PM Rados?aw Piliszek <radoslaw.piliszek at gmail.com> wrote:
>>>>
>>>> Hi Matt,
>>>>
>>>> > As you're now reconfiguring a running deployment, there are
>>>> > some extra steps that need to be taken to migrate to durable queues.
>>>> >
>>>> > 1. You will need to stop the OpenStack services which use RabbitMQ.
>>>> >
>>>> > 2. Reset the state of RabbitMQ one each rabbit node with the following
>>>> > commands. You must run each command on all RabbitMQ nodes before
>>>> > moving on to the next command. This will remove all queues.
>>>> >
>>>> >     rabbitmqctl stop_app
>>>> >     rabbitmqctl force_reset
>>>> >     rabbitmqctl start_app
>>>> >
>>>> > 3. Start the OpenStack services again, at which point they will
>>>> > recreate the appropriate queues as durable.
>>>>
>>>> This sounds like a great new addition-to-be to the Kolla Ansible docs!
>>>> Could you please propose it as a change?
>>>>
>>>> Kindest,
>>>> Radek
>>>>


From eyalb1 at gmail.com  Thu Apr 13 08:12:02 2023
From: eyalb1 at gmail.com (Eyal B)
Date: Thu, 13 Apr 2023 10:12:02 +0200
Subject: [ptl] Need PTL volunteer for OpenStack Vitrage
In-Reply-To: <1870a6b95c5.105ea64ba994248.8904640311035076666@ghanshyammann.com>
References: <1870a6b95c5.105ea64ba994248.8904640311035076666@ghanshyammann.com>
Message-ID: <CAL4TGfZGsazLwdkwETXt-+GxnDhUg1MJUkJrKfTzDW846HeQtA@mail.gmail.com>

Hi,
Unfortunately I won't be able to continue as vitrage PTL, I don't have the
time any more. I have been doing it on my free time for several years now
but I cannot continue.

BR
 Eyal

On Wed, 22 Mar 2023, 18:43 Ghanshyam Mann, <gmann at ghanshyammann.com> wrote:

> Hi Eyal,
>
> I am reaching out to you as you were PTL for OpenStack Vitrage project in
> the last cycle.
>
> There is no PTL candidate for the next cycle (2023.2), and it is on the
> leaderless project list. Please
> check if you or anyone you know would like to lead this project.
>
> - https://etherpad.opendev.org/p/2023.2-leaderless
>
> Also, if anyone else would like to help leading this project, this is time
> to let TC knows.
>
> -gmann
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230413/081c7247/attachment-0001.htm>

From christian.rohmann at inovex.de  Thu Apr 13 10:32:59 2023
From: christian.rohmann at inovex.de (Christian Rohmann)
Date: Thu, 13 Apr 2023 12:32:59 +0200
Subject: Does cinder-backup support multi-backend?
In-Reply-To: <CABAODReW4Ky8JpjySp2BXZ4aryR3Uu+ZBWGZv7T5gErt7KfgnQ@mail.gmail.com>
References: <CAJV_UBAwDcy7Adob712AVYa0uK0txsoJbi3U83Fjy2G6UFhyiQ@mail.gmail.com>
 <CABAODRfY9v6muyZw34yxk25npgFUc4LfTe594Ng8VUUXA334DQ@mail.gmail.com>
 <CABAODRd=ps4S8pPcHgSkpdyKzbwtkS6_YXzUZpx1dU71NXNDRg@mail.gmail.com>
 <CABAODRedjYcb0NDeemMHCfSMSiken=iaDQqpkQQVq57dE+XiaA@mail.gmail.com>
 <CABAODReU3fBhPi0co77y=2qXM+u1u8mVpH4XxRiXVoX12_hsnw@mail.gmail.com>
 <CAARK8KTgRYDGG=ZsckZD_3-_yXR8NpHAzZa-4sT_m-iPto2KrQ@mail.gmail.com>
 <0966efa7-8b53-8b84-255d-cefaeddd0384@inovex.de>
 <CABAODReW4Ky8JpjySp2BXZ4aryR3Uu+ZBWGZv7T5gErt7KfgnQ@mail.gmail.com>
Message-ID: <cf61ed61-ce22-ff89-a438-39e1a15cbc06@inovex.de>

Hello again,
(added Petr and Gorka to CC, as we discussed some of the issues with 
cinder-backup and object storage at cinder meetings)


On 13/04/2023 08:44, Nguy?n H?u Kh?i wrote:
> I feel that people don't use cinder-backup because it is slow and not 
> show more stats such as how many percent to complete a backup job,

I also suspected that cinder-backup is not extremely common and mostly 
the RBD driver is used.
That's why I asked on the ML 
(https://lists.openstack.org/pipermail/openstack-discuss/2022-September/030263.html) 
about others experience with object storage.
E.g. OVH just introduced volume backups 
(https://docs.ovh.com/us/en/public-cloud/volume-backup/) and they say 
that those end up in object storage.


I just dropped a larger comment summing into an existing bug about 
backups timing out 
(https://bugs.launchpad.net/cinder/+bug/1918119/comments/2)
as this is exactly what we observed with chunked driver backups as well.


Regards

Christian







From wodel.youchi at gmail.com  Thu Apr 13 10:41:41 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Thu, 13 Apr 2023 11:41:41 +0100
Subject: [kolla-ansible][yoga] Glance backend cinder Privsep daemon failed
 to start operation not permitted
In-Reply-To: <323313cf9ef907a0bbbdce18e7ae71654385e1f2.camel@redhat.com>
References: <CAJV_UBC95fMQh00w7vxbyV55F=wXuLXjgVYG5fYy08en2VYtaA@mail.gmail.com>
 <CADO3vb4++zhHTu3Gfdsb3pYZFMdwGSytDuXhN0QZ-JCdVFqu7A@mail.gmail.com>
 <323313cf9ef907a0bbbdce18e7ae71654385e1f2.camel@redhat.com>
Message-ID: <CAJV_UBDUQ0x_Y24Q5S8QbvJrLnZ8Moy2q=LsvojjSMRooSrXrg@mail.gmail.com>

Thanks for the help,

I modified my glance-api.conf like this but no luck, I got the same problem
: Privsep daemon failed to start

> [cinder]
> cinder_store_auth_address = https://dashint.example.com:5000/v3
> cinder_store_project_name = service
> cinder_volume_type = nfstype
> rootwrap_config = /etc/glance/rootwrap.conf
>
> *cinder_store_user_name = glancecinder_store_password = glance-password*
> cinder_catalog_info = volumev3:cinderv3:internalURL
>

> *###cinder_store_user_name = cinder###cinder_store_password =
> cinder-password  *
>


I thought once cinder has the capability to read & write into the backend,
glance will just use it to upload the images!!

Another thing, about the credentials, which ones should I use? Glance's or
cinder's I thought it should be cinder's !! but in your example @Sean you
used {{ glance_keystone_user }} and  {{ glance_keystone_password }}

Lastly I searched how to launch a privileged container in kolla but I
didn't find anything.

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230413/d7e8d2c2/attachment.htm>

From rafaelweingartner at gmail.com  Thu Apr 13 11:06:34 2023
From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=)
Date: Thu, 13 Apr 2023 08:06:34 -0300
Subject: [Cloudkitty][ptg] CloudKitty 2023.2 Bobcat PTG outcome
Message-ID: <CAG97racwu7aEnUmy6CDeXjv6PHjB1s4Xg_F9uJ3Dv1RpVP7sUA@mail.gmail.com>

Hello,
Thanks to everyone who attended the CloudKitty PTG sessions, we covered a
lot during the meeting. The Etherpad is available at [1].


[1] https://etherpad.opendev.org/p/march2023-ptg-cloudkitty

-- 
Rafael Weing?rtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230413/57156ddc/attachment.htm>

From smooney at redhat.com  Thu Apr 13 11:31:48 2023
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 13 Apr 2023 12:31:48 +0100
Subject: Updating OS-TRAITS in placement stable/yoga and stable/zed
In-Reply-To: <CAFT5D2SA_2=xo7Kc-q-x4ZdV4G4eP=LRnbu+Az-gUGHpA9fiQg@mail.gmail.com>
References: <PS2PR01MB2197DD6CBACFEE5758A13066F49B9@PS2PR01MB2197.apcprd01.prod.exchangelabs.com>
 <CAFT5D2SA_2=xo7Kc-q-x4ZdV4G4eP=LRnbu+Az-gUGHpA9fiQg@mail.gmail.com>
Message-ID: <a40c2c36ce427212e0589077f45ea27915afed54.camel@redhat.com>

On Wed, 2023-04-12 at 19:00 -0500, Tony Breeds wrote:
> On Wed, 12 Apr 2023 at 18:27, Karl Kloppenborg <kkloppenborg at rwts.com.au>
> wrote:
> 
> > Hello Placement and OS-Traits teams.
> > 
> > Karl from Openstack-Helm.
> > 
> > 
> > 
> > After debugging a number of issues in Cyborg, it has become necessary to
> > update the pinned OS-TRAITs version in stable/yoga and stable/zed.
> > 
> > I have submitted the following two reviews for updating the pinned
> > versions to 2.10.0
> > 
> > 
> > 
> > https://review.opendev.org/c/openstack/placement/+/880249
> > 
> > https://review.opendev.org/c/openstack/placement/+/880249
> > 
> 
> This won't do what you want.  The version that will be installed is
> controlled by constraints in the openstack/requirements repo
> 
> https://opendev.org/openstack/requirements/src/branch/stable/yoga/upper-constraints.txt#L388
> and
> https://opendev.org/openstack/requirements/src/branch/stable/zed/upper-constraints.txt#L361
> 
> We don't typically allow this kind of bump on stable branches as it often
> indicates a feature backport which we avoid in order to keep the release
> and gate stable.
ya this is not somethign we can or should change upstream

> 
> So we could *potentially* do what you need but the community as a whole
> will need to understand the rationale for why.
> 
my understanidng is they are tryign to use a features from antelop cyborg with a yoga placement.

the reall fix would be just update placemtn to at least zed in there deployemnt.
>   Upping the version on a
> stable branch will also have vendor impacts for supported versions of
> os-traints.
> 
> By merging these changes, it will allow us to continue to use vGPU
> > capabilities in cyborg in the stable/yoga and stable/zed onwards branches.
> > 
> 
> Continue to use?  Please help us understand this.
they have a downstream backport of a feature that merged in febuary but was written 3 years ago
specificaly they somehow have https://github.com/openstack/cyborg/commit/79e1928554b6a03dd481ebefd3f550adeb457aed
in there yoga/zed verions which uses the?"OWNER_CYBORG" trait
https://github.com/openstack/cyborg/blob/master/cyborg/accelerator/drivers/gpu/nvidia/sysinfo.py#L52

which does not exsit until zed released in os-traits 2.8.0 https://github.com/openstack/os-traits/commit/f64d50e4dd2f21558fb73dd4b59cd1d4b121b707
placement in zed depens on 2.8.0 https://github.com/openstack/placement/commit/c4e89253a52839a514bd87fdebc4785fe0e64146

the fact tehy need os-traits 2.10.0 probaly means they have other backports.

standard trait shoudl not really be backproted.
when we consider feature backports downstream we do not backport feature that require new traits to funciton.
we treat it like an api change (microversion). strictly speaking it spossibel to do but all that they really need
to do is update the installed version of os-triats they use.

the other thing to not is that we dont curretnly use the owner traits for anythign.

the nova part of https://specs.openstack.org/openstack/nova-specs/specs/zed/approved/owner-nova-trait-usage.html was not implemented
so the nova managed resouce are not tagged it OWNER_NOVA so you cant have boot nova managed gpus and nova manged vgpus shareing hte same resouce class
yet. at least not out of the box.

they 3 paths forward really are as follows.
1.) work with your downstream vendor distibution to have them remove the usage of the ownwer trait on ther yoga backport and any other standard traits
that dont exist there. i.e. traits = ["OWNER_CYBORG"] -> traits = [] here
https://github.com/openstack/cyborg/blob/master/cyborg/accelerator/drivers/gpu/nvidia/sysinfo.py#L52

2.) work with your downstrem vendor distribuion  to update the os-traits lib they ship. the newer versions will work with older placement.
it will just break the unit test that count the number of standard traits in the db. that is trivial to fix to the new count.

3.) upgrade your placement version in your deployment to a zed/antelope container, newer placement will work with older everything else.

if you are using the upstream version fo cyborg with the upstream version of placment/os-traits there shoudl be no incompatiblity.



> 
> Tony.



From smooney at redhat.com  Thu Apr 13 11:50:20 2023
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 13 Apr 2023 12:50:20 +0100
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CAHsN3DMv0JZr=bovHJtUiRuy-a5wFo9GG48L4Y9eH3Rr+6GXkw@mail.gmail.com>
References: <CAHsN3DO5jMQPtxz2yUdWa=jjgG3Y3Y6GDcJQmmtpQVNkSwh55Q@mail.gmail.com>
 <CAPgF-fr1k4pQs5j6DtV5OeeCgcgjmcW7gdMS75vtxnAEx8V=sw@mail.gmail.com>
 <CABAODRdfX6aPXkCDwCxJBkwDNB7YaG4U_Z2o0=HLYeO0zWjE8A@mail.gmail.com>
 <CAHsN3DNRogsCtLJSm9VKd1YV0J+M4dwj+byWB8A2W4OZNm4W-g@mail.gmail.com>
 <CAPgF-fr9KAkJOOK1Y9z=QwEv=tW8Q6xRi9PjJ7Hp2rTrJ8=Pgw@mail.gmail.com>
 <CAHsN3DMRObqwwz1VGq1Lr6FKihyo4hB+EExnK9vXHmceHhBcEw@mail.gmail.com>
 <CAPgF-fpCxu80Yh8JzfjjNjYEti+_Sy=QWOjdkSOiYYuZ7HVmZA@mail.gmail.com>
 <CAHsN3DNNUZLh9MtQtvRMzRzON1JTE6px0a0Xgx+pr5=dVEpf-A@mail.gmail.com>
 <CAKZ_x79aM92AxLTq0bW1OAg=WmoiHzXhfJx1eug7oNq6EtxjEQ@mail.gmail.com>
 <CAPgF-fosH2eS6CMDCnLoOHy6U+9aVQJXye7LAJqVPNjSRYeSoQ@mail.gmail.com>
 <CABAODReZ011H=Gv0V9FEnmyRNFoWtmOK6LXOFhFN-J39dMVS4Q@mail.gmail.com>
 <CABAODRfixPQGnENxpWT4nvPkmGU27X1Amzs=oyHvZ_VHxPLqVw@mail.gmail.com>
 <CAHsN3DMv0JZr=bovHJtUiRuy-a5wFo9GG48L4Y9eH3Rr+6GXkw@mail.gmail.com>
Message-ID: <5906e729a3a7adf9dea1fcd47aade4e9a0688e7d.camel@redhat.com>

On Thu, 2023-04-13 at 09:07 +0100, Matt Crees wrote:
> Hi all, I'll reply in turn here:
> 
> Radek, I agree it definitely will be a good addition to the KA docs.
> I've got it on my radar, will aim to get a patch proposed this week.
> 
> Satish, I haven't personally been able to test durable queues on a
> system that large. According to the RabbitMQ docs
> (https://www.rabbitmq.com/queues.html#durability), "Throughput and
> latency of a queue is not affected by whether a queue is durable or
> not in most cases." However, I have anecdotally heard that it can
> affect some performance in particularly large systems.

the perfomacne of durable queue is dominated by the disk io
put rabbit on a pcie nvme ssd and it will have littel effect
use spinnign rust (a HDD even in raid 10) and the iops/throput of the
storage sued to make the qure durible (that just mean write all messages to disk)
will be the bottlenck for scaleablity
combine that with HA and that is worse as it has to be writen to multipel servers.
i belive that teh mirror implemantion will wait for all copies to be persisted
but i have not really looked into it. it was raised as a pain point with rabbit by
operator in the past in terms fo scaling.

> 
> Please note that if you are using the classic mirrored queues, you
> must also have them durable. Transient (i.e. non-durable) mirrored
> queues are not a supported feature and do cause bugs. (For example the
> "old incarnation" errors seen here:
> https://bugs.launchpad.net/kolla-ansible/+bug/1954925)
> 
> Nguyen, I can confirm that we've seen the same behaviour. This is
> caused by a backported change in oslo.messaging (I believe you linked
> the relevant bug report previously). There is a fix in progress to fix
> this (https://review.opendev.org/c/openstack/oslo.messaging/+/866617),
> and in the meantime setting kombu_reconnect_delay < 1.0 does resolve
> it.
> 
> Cheers,
> Matt
> 
> On Thu, 13 Apr 2023 at 03:04, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com> wrote:
> > 
> > update:
> > I use SAN as Cinder backend.
> > Nguyen Huu Khoi
> > 
> > 
> > On Thu, Apr 13, 2023 at 9:02?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com> wrote:
> > > 
> > > Hello guys.
> > > 
> > > I do many tests on xena and yoga. then i am sure that without ha-queue and kombu_reconnect_delay=0.5(it can < 1)
> > > you cannot launch instances when 1 of 3 controllers is down.
> > > Somebody can verify what I say, I hope we will have a common solution for this problem because those who use openstack for the first time will continue to ask questions like that.
> > > 
> > > Nguyen Huu Khoi
> > > 
> > > 
> > > On Thu, Apr 13, 2023 at 12:59?AM Satish Patel <satish.txt at gmail.com> wrote:
> > > > 
> > > > This is great! Matt,
> > > > 
> > > > Documentation would be greatly appreciated. I have a counter question: does Durable queue be good for large clouds with 1000 compute nodes or better to not use durable queue. This is a private cloud and we don't care about persistent data.
> > > > 
> > > > On Wed, Apr 12, 2023 at 12:37?PM Rados?aw Piliszek <radoslaw.piliszek at gmail.com> wrote:
> > > > > 
> > > > > Hi Matt,
> > > > > 
> > > > > > As you're now reconfiguring a running deployment, there are
> > > > > > some extra steps that need to be taken to migrate to durable queues.
> > > > > > 
> > > > > > 1. You will need to stop the OpenStack services which use RabbitMQ.
> > > > > > 
> > > > > > 2. Reset the state of RabbitMQ one each rabbit node with the following
> > > > > > commands. You must run each command on all RabbitMQ nodes before
> > > > > > moving on to the next command. This will remove all queues.
> > > > > > 
> > > > > >     rabbitmqctl stop_app
> > > > > >     rabbitmqctl force_reset
> > > > > >     rabbitmqctl start_app
> > > > > > 
> > > > > > 3. Start the OpenStack services again, at which point they will
> > > > > > recreate the appropriate queues as durable.
> > > > > 
> > > > > This sounds like a great new addition-to-be to the Kolla Ansible docs!
> > > > > Could you please propose it as a change?
> > > > > 
> > > > > Kindest,
> > > > > Radek
> > > > > 
> 



From smooney at redhat.com  Thu Apr 13 12:00:05 2023
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 13 Apr 2023 13:00:05 +0100
Subject: [kolla-ansible][yoga] Glance backend cinder Privsep daemon
 failed to start operation not permitted
In-Reply-To: <CAJV_UBDUQ0x_Y24Q5S8QbvJrLnZ8Moy2q=LsvojjSMRooSrXrg@mail.gmail.com>
References: <CAJV_UBC95fMQh00w7vxbyV55F=wXuLXjgVYG5fYy08en2VYtaA@mail.gmail.com>
 <CADO3vb4++zhHTu3Gfdsb3pYZFMdwGSytDuXhN0QZ-JCdVFqu7A@mail.gmail.com>
 <323313cf9ef907a0bbbdce18e7ae71654385e1f2.camel@redhat.com>
 <CAJV_UBDUQ0x_Y24Q5S8QbvJrLnZ8Moy2q=LsvojjSMRooSrXrg@mail.gmail.com>
Message-ID: <e0bd7f4fdb6a4e1e949531730f9f19a0304781d6.camel@redhat.com>

On Thu, 2023-04-13 at 11:41 +0100, wodel youchi wrote:
> Thanks for the help,
> 
> I modified my glance-api.conf like this but no luck, I got the same problem
> : Privsep daemon failed to start
> 
> > [cinder]
> > cinder_store_auth_address = https://dashint.example.com:5000/v3
> > cinder_store_project_name = service
> > cinder_volume_type = nfstype
> > rootwrap_config = /etc/glance/rootwrap.conf
> > 
> > *cinder_store_user_name = glancecinder_store_password = glance-password*
> > cinder_catalog_info = volumev3:cinderv3:internalURL
> > 
> 
> > *###cinder_store_user_name = cinder###cinder_store_password =
> > cinder-password  *
> > 
> 
> 
> I thought once cinder has the capability to read & write into the backend,
> glance will just use it to upload the images!!
> 
> Another thing, about the credentials, which ones should I use? Glance's or
> cinder's I thought it should be cinder's !! but in your example @Sean you
> used {{ glance_keystone_user }} and  {{ glance_keystone_password }}

either would work but normally i woudl consider it bad partice for a service to have the username/password for a differnt users account
so glance should alwasy use its user to talk to other services when its not using the keystone user token passed in to the api.

> 
> Lastly I searched how to launch a privileged container in kolla but I
> didn't find anything.

i see the issue
https://github.com/openstack/kolla-ansible/blob/stable/yoga/ansible/roles/glance/defaults/main.yml#L10
glace api is only privlaged if you use iscsi for the cinder backend.
privileged: "{{ enable_cinder | bool and enable_cinder_backend_iscsi | bool }}"
you are using nfs.

you can workaround this in your global.yaml by adding this i think

glance_services:
  glance-api:
   privileged: true

alternitivly you can do it via the inventory file by seting that as a host/group var.
> 
> Regards.



From nguyenhuukhoinw at gmail.com  Thu Apr 13 14:00:16 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Thu, 13 Apr 2023 21:00:16 +0700
Subject: [glance][cinder]create volume from image too slow
Message-ID: <CABAODRd4v9XqRWE7ojxUC6UFynNe29wbB+G-WOYLFmP1besN8A@mail.gmail.com>

Hello guys.
I am using nfs for glance and SAN for cinder but when i create 1 gb volume
with 100mb image(Converted 112.00 MB image at 25.4 MB/s) then it will fast.
however, if I create 100gb volume with 100mb image(Converted 112.00 MB
image at 8.24 MB/s) then it will very slow.

Pls give me some advices. ty

Nguyen Huu Khoi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230413/84ed5140/attachment.htm>

From wodel.youchi at gmail.com  Thu Apr 13 14:23:37 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Thu, 13 Apr 2023 15:23:37 +0100
Subject: [kolla-ansible][yoga] Glance backend cinder Privsep daemon failed
 to start operation not permitted
In-Reply-To: <e0bd7f4fdb6a4e1e949531730f9f19a0304781d6.camel@redhat.com>
References: <CAJV_UBC95fMQh00w7vxbyV55F=wXuLXjgVYG5fYy08en2VYtaA@mail.gmail.com>
 <CADO3vb4++zhHTu3Gfdsb3pYZFMdwGSytDuXhN0QZ-JCdVFqu7A@mail.gmail.com>
 <323313cf9ef907a0bbbdce18e7ae71654385e1f2.camel@redhat.com>
 <CAJV_UBDUQ0x_Y24Q5S8QbvJrLnZ8Moy2q=LsvojjSMRooSrXrg@mail.gmail.com>
 <e0bd7f4fdb6a4e1e949531730f9f19a0304781d6.camel@redhat.com>
Message-ID: <CAJV_UBCkuvnXem=A8czKSE3zJBp5LtQ9wXQPr-y5LE4X8k3V8A@mail.gmail.com>

Hi,

Adding those lines to globals.yml did produce errors, complaining about the
enabled line missing

> glance_services:
>   glance-api:
>     privileged: true
>

Then I tried this

> glance_services:
>   glance-api:
>     enabled: true
>     privileged: true
>

Gave these errors
fatal: [192.168.2.23]: FAILED! => {"msg": "The conditional check
'item.value.host_in_groups | bool' failed. The error was: error while
evaluating conditional (item.value.host_in_groups | bool): 'dict object'
has no attribute 'host_in_groups'\n\nThe error appears to be in
'/home/deployer/kollavenv/yogavenv/share/kolla-ansible/ansible/roles/glance/tasks/config.yml':
line 2, column 3, but may\nbe elsewhere in the file depending on the exact
syntax problem.\n\nThe offending line appears to be:\n\n---\n- name:
Ensuring config directories exist\n  ^ here\n"}
fatal: [192.168.2.27]: FAILED! => {"msg": "The conditional check
'item.value.host_in_groups | bool' failed. The error was: error while
evaluating conditional (item.value.host_in_groups | bool): 'dict object'
has no attribute 'host_in_groups'\n\nThe error appears to be in
'/home/deployer/kollavenv/yogavenv/share/kolla-ansible/ansible/roles/glance/tasks/config.yml':
line 2, column 3, but may\nbe elsewhere in the file depending on the exact
syntax problem.\n\nThe offending line appears to be:\n\n---\n- name:
Ensuring config directories exist\n  ^ here\n"}
fatal: [192.168.2.31]: FAILED! => {"msg": "The conditional check
'item.value.host_in_groups | bool' failed. The error was: error while
evaluating conditional (item.value.host_in_groups | bool): 'dict object'
has no attribute 'host_in_groups'\n\nThe error appears to be in
'/home/deployer/kollavenv/yogavenv/share/kolla-ansible/ansible/roles/glance/tasks/config.yml':
line 2, column 3, but may\nbe elsewhere in the file depending on the exact
syntax problem.\n\nThe offending line appears to be:\n\n---\n- name:
Ensuring config directories exist\n  ^ here\n"}


it seems, this configuration is discarding main.yml from
https://github.com/openstack/kolla-ansible/blob/stable/yoga/ansible/roles/glance/defaults/main.yml#L10
not just replacing the needed variables.

Regards.

Le jeu. 13 avr. 2023 ? 13:00, Sean Mooney <smooney at redhat.com> a ?crit :

> On Thu, 2023-04-13 at 11:41 +0100, wodel youchi wrote:
> > Thanks for the help,
> >
> > I modified my glance-api.conf like this but no luck, I got the same
> problem
> > : Privsep daemon failed to start
> >
> > > [cinder]
> > > cinder_store_auth_address = https://dashint.example.com:5000/v3
> > > cinder_store_project_name = service
> > > cinder_volume_type = nfstype
> > > rootwrap_config = /etc/glance/rootwrap.conf
> > >
> > > *cinder_store_user_name = glancecinder_store_password =
> glance-password*
> > > cinder_catalog_info = volumev3:cinderv3:internalURL
> > >
> >
> > > *###cinder_store_user_name = cinder###cinder_store_password =
> > > cinder-password  *
> > >
> >
> >
> > I thought once cinder has the capability to read & write into the
> backend,
> > glance will just use it to upload the images!!
> >
> > Another thing, about the credentials, which ones should I use? Glance's
> or
> > cinder's I thought it should be cinder's !! but in your example @Sean you
> > used {{ glance_keystone_user }} and  {{ glance_keystone_password }}
>
> either would work but normally i woudl consider it bad partice for a
> service to have the username/password for a differnt users account
> so glance should alwasy use its user to talk to other services when its
> not using the keystone user token passed in to the api.
>
> >
> > Lastly I searched how to launch a privileged container in kolla but I
> > didn't find anything.
>
> i see the issue
>
> https://github.com/openstack/kolla-ansible/blob/stable/yoga/ansible/roles/glance/defaults/main.yml#L10
> glace api is only privlaged if you use iscsi for the cinder backend.
> privileged: "{{ enable_cinder | bool and enable_cinder_backend_iscsi |
> bool }}"
> you are using nfs.
>
> you can workaround this in your global.yaml by adding this i think
>
> glance_services:
>   glance-api:
>    privileged: true
>
> alternitivly you can do it via the inventory file by seting that as a
> host/group var.
> >
> > Regards.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230413/c1768644/attachment.htm>

From james.page at canonical.com  Thu Apr 13 14:54:12 2023
From: james.page at canonical.com (James Page)
Date: Thu, 13 Apr 2023 15:54:12 +0100
Subject: [ptl][tc][winstackers] Final call for Winstackers PTL and maintainers
Message-ID: <CAG1bqQoS8aF9-P93zFsQTPpKMO5d+s3m6oxtHsNHrgQUgam09g@mail.gmail.com>

Hi All

As announced by Lucian last November (see [0]) Cloudbase Solutions are no
longer in a position to maintain support for running OpenStack on Windows
and have also ceased operation of their 3rd party CI for the windows
support across a number of OpenStack projects.

This situation has resulted in the Winstackers project becoming PTL-less
for the 2023.2 cycle with no volunteers responding to the TC's call to fill
this role and take this feature in OpenStack forward (see [1]).

This is the final call for any maintainers to step forward if this feature
is important to them in OpenStack.

The last user survey in 2022 indicated that 2% of respondents were running
on Hyper-V so this might be important enough to warrant a commitment from
someone operating OpenStack on Windows to maintain these features going
forward.

Here is a reminder from Lucian's original email on the full list of
projects which are impacted in some way:

* nova hyper-v driver - in-tree plus out-of-tree compute-hyperv driver
* os-win - common Windows library for Openstack
* neutron hyperv ml2 plugin and agent
* ovs on Windows and neutron ovs agent support
* cinder drivers - SMB and Windows iSCSI
* os-brick Windows connectors - iSCSI, FC, SMB, RBD
* ceilometer Windows poller
* manila Windows driver
* glance Windows support
* freerdp gateway

The lack of 3rd party CI for testing all of this really needs to be
addressed as well.

If no maintainers are forthcoming between now and the next PTG in June the
TC will need to officially retire the project and start the process of
removing support for Windows across the various projects that support this
operating system in some way - either directly or through the use of os-win.

For clarity this call refers to the use of the Hyper-V virtualisation
driver and associated Windows server components to provide WIndows based
OpenStack Hypervisors and does not relate to the ability to run Windows
images as guests on OpenStack.

Regards

James

[0]
https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html
[1]
https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032888.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230413/13016e72/attachment-0001.htm>

From arnaud.morin at gmail.com  Thu Apr 13 15:41:52 2023
From: arnaud.morin at gmail.com (Arnaud Morin)
Date: Thu, 13 Apr 2023 15:41:52 +0000
Subject: [oslo.messaging][nova][neutron] quorum queues
Message-ID: <ZDgiwMOAFK0URW5x@sync2>

Hey team,

I am currently looking into using quorum queues (see patch [1]
introduced in oslo_messaging) for openstack services (nova, neutron
mostly).

After switching the value to true and bootstraping a new cluster, all
queues are quorum except the fanout and reply queues.

I understand that transient queues are managed differently in openstack,
but why is it so?

I am asking this because when using rabbit in cluster mode, the quorum
queues are replicated accross the cluster.
But because the fanout and reply queues are not replicated, if one of
the cluster is shutting down during an instance boot, the boot may endup
in error (the reply queue may be on the faulty node).

Is there any reason to not enable quorum on transient queues?


[1] https://github.com/openstack/oslo.messaging/commit/7e8acbf87070354cd2438f3ab0821d035c2e7d92


From ces.eduardo98 at gmail.com  Thu Apr 13 16:01:00 2023
From: ces.eduardo98 at gmail.com (Carlos Silva)
Date: Thu, 13 Apr 2023 13:01:00 -0300
Subject: [manila] Cancelling next week's weekly meeting
Message-ID: <CAE51gQKHE2zVqhTxBRfuBmQgU9m-GSR_hwEeE+LMF_6ArzOeRA@mail.gmail.com>

Hello everyone!

As we will have a significant drop in attendance in next week's IRC weekly
meeting (Apr 20th), we will be cancelling it.

The next IRC weekly meeting will be on Apr 27th.

Thanks,
carloss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230413/8bd53b0d/attachment.htm>

From bartelme at gmail.com  Thu Apr 13 16:12:50 2023
From: bartelme at gmail.com (John Bartelme)
Date: Thu, 13 Apr 2023 12:12:50 -0400
Subject: [heat] Performance scaling with number of resources
Message-ID: <CADC88CcyJ4nc7s4SVDyCPVAYR_B4admzaQSmuPiVymy6uieZFA@mail.gmail.com>

Hello,

I'm wondering about heat performance when I scale to a larger number of
resources.  A single resource deploys quite quickly but when I deploy the
below template it takes 2 minutes for this stack to deploy.  This occurs on
Antelope via DevStack on Ubuntu 22.04 as well as a full production
cluster(yoga) deployed with OpenStack-Ansible on RHEL 8.  Not only does
this template take 2 minutes to deploy it also takes 2 minutes to update
without any changes.  Is there anything in the stack configuration or heat
configuration I can do to speed up the process of updating the stack when
very little changes?  Or this something inherit in the design of heat?

---
heat_template_version: 2021-04-16

description: test

resources:
  test-resources:
    type: OS::Heat::ResourceGroup
    properties:
      count: 100
      resource_def:
        type: OS::Heat::None
---

A little more detail:

Obviously I have no need to deploy this template but it is a much more
simplified case of what I really want to deploy.  I'm deploying resource
groups that contain hundreds of custom resources(containing
network/compute/storage etc.) that are conditionally enabled or disabled
based on a JSON property array(in general only about 20 or so resources are
deployed but depending on needs any one of the resources might be needed in
the near future).  The JSON properties array is complex enough that I
really want to have it all defined so that changing a boolean value is all
that is needed to turn on and off resources without having to fully write
new complex heat templates.  Additionally the nature of the workflow is
that I want to add future resources to the existing stack.  I don't change
the number of the resources to the resource group, i.e. count=20 instead of
100 because when I conditionally add another resource it causes all the
existing resources to be renumbered.  Ideally I could rapidly modify one
value to the json array and then update the stack and have it quickly
modified.

Thanks, john


From gmann at ghanshyammann.com  Thu Apr 13 17:02:54 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 13 Apr 2023 10:02:54 -0700
Subject: [qa][patrole] Retiring Patrole project
Message-ID: <1877b91ef1a.115629994587286.2036976784973587597@ghanshyammann.com>

Hello Everyone,

You might know that Patrole project[1] which was created to test the RBAC but had some design
challenges, and we never got much attention to this project to align it with the new SRBAC or efficient
way to test the RBAC.

Since the last couple of years (After AT&T's focus was changed from OpenStack), we hardly had any maintainer
in this project. In this cycle, the QA team decided to retire this project. There is always an option to bring it back
in OpenStack if anyone is interested in maintaining it.

I have pushed the changes required for retirement, including governance change. If anyone
using or interested in this project, feel free to reply here or in governance change[2].

[1] https://wiki.openstack.org/wiki/QA#Patrole_.28RETIRED.29
[2] https://review.opendev.org/c/openstack/governance/+/880014

-gmann


From gmann at ghanshyammann.com  Thu Apr 13 17:09:54 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 13 Apr 2023 10:09:54 -0700
Subject: [ptl] Need PTL volunteer for OpenStack Vitrage
In-Reply-To: <CAL4TGfZGsazLwdkwETXt-+GxnDhUg1MJUkJrKfTzDW846HeQtA@mail.gmail.com>
References: <1870a6b95c5.105ea64ba994248.8904640311035076666@ghanshyammann.com>
 <CAL4TGfZGsazLwdkwETXt-+GxnDhUg1MJUkJrKfTzDW846HeQtA@mail.gmail.com>
Message-ID: <1877b98576a.f5f7e32e587608.323404367955418499@ghanshyammann.com>

Thanks Eyal for maintaining it for so long even in your free time. We really
appreciate your effort in this project and understand your priority.

Let me start calling out for other maintainers if any otherwise last option is to
propose retirement.


-gmann
 ---- On Thu, 13 Apr 2023 01:12:02 -0700  Eyal B  wrote --- 
 > Hi,Unfortunately I won't be able to continue as vitrage PTL, I don't have the time any more. I have been doing it on my free time for several years now but I cannot continue.
 > BR?Eyal?
 > On Wed, 22 Mar 2023, 18:43 Ghanshyam Mann, gmann at ghanshyammann.com> wrote:
 > Hi Eyal,
 > 
 > I am reaching out to you as you were PTL for OpenStack Vitrage project in the last cycle.
 > 
 > There is no PTL candidate for the next cycle (2023.2), and it is on the leaderless project list. Please
 > check if you or anyone you know would like to lead this project.
 > 
 > - https://etherpad.opendev.org/p/2023.2-leaderless
 > 
 > Also, if anyone else would like to help leading this project, this is time to let TC knows.
 > 
 > -gmann
 > 


From gmann at ghanshyammann.com  Thu Apr 13 17:24:31 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 13 Apr 2023 10:24:31 -0700
Subject: [all][tc][vitrage] Final call for Vitrage project maintainers
Message-ID: <1877ba5bc71.12a20ec8f588247.2493892904205072376@ghanshyammann.com>

Hello Everyone,

You might have noticed that the Vitrage project is leaderless in this cycle[1]. Eyal, who was the
previous PTL and the only maintainer of this project for more than two years[2], will not be
able to continue in this project[3]. We thank and appreciate all previous maintainers' work on this
project.

This is the final call for maintainers. If anyone is using or interested in this project, this is the right
time to step up and let us know in this email or IRC(OFTC) #openstack-tc channel. If there is no
response by the end of April 2023, we will discuss the retirement of this project.


[1] https://etherpad.opendev.org/p/2023.2-leaderless
[2] https://www.stackalytics.io/?module=vitrage-group&release=wallaby
[3] https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033333.html

-gmann


From gmann at ghanshyammann.com  Thu Apr 13 17:30:03 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 13 Apr 2023 10:30:03 -0700
Subject: [ptl][tc][winstackers] Final call for Winstackers PTL and
 maintainers
In-Reply-To: <CAG1bqQoS8aF9-P93zFsQTPpKMO5d+s3m6oxtHsNHrgQUgam09g@mail.gmail.com>
References: <CAG1bqQoS8aF9-P93zFsQTPpKMO5d+s3m6oxtHsNHrgQUgam09g@mail.gmail.com>
Message-ID: <1877baacbb5.f141cc1b588495.6218423714416684683@ghanshyammann.com>

Thanks, James for describing the Winstacjers project (Window support in OpenStack) situation. 

I am forwarding it to openstack-announce ML also for a wider audience.

Ref:  https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033342.html

-gmann

 ---- On Thu, 13 Apr 2023 07:54:12 -0700  James Page  wrote --- 
 > Hi All
 > 
 > As announced by Lucian last November (see [0]) Cloudbase Solutions are no longer in a position to maintain support for running OpenStack on Windows and have also ceased operation of their 3rd party CI for the windows support across a number of OpenStack projects.
 > This situation has resulted in the Winstackers project becoming PTL-less for the 2023.2 cycle with no volunteers responding to the TC's call to fill this role and take this feature in OpenStack forward (see [1]).
 > This is the final call for any maintainers to step forward if this feature is important to them in OpenStack.
 > The last user survey in 2022 indicated that 2% of respondents were running on Hyper-V so this might be important enough to warrant a commitment from someone operating OpenStack on Windows to maintain these features going forward.
 > Here is a reminder from Lucian's original email on the full list of projects which are impacted in some way:?* nova hyper-v driver - in-tree plus out-of-tree compute-hyperv driver* os-win - common Windows library for Openstack* neutron hyperv ml2 plugin and agent* ovs on Windows and neutron ovs agent support* cinder drivers - SMB and Windows iSCSI* os-brick Windows connectors - iSCSI, FC, SMB, RBD* ceilometer Windows poller* manila Windows driver* glance Windows support* freerdp gateway
 > The lack of 3rd party CI for testing all of this really needs to be addressed as well.
 > If no maintainers are forthcoming between now and the next PTG in June the TC will need to officially retire the project and start the process of removing support for Windows across the various projects that support this operating system in some way - either directly or through the use of os-win.
 > For clarity this call refers to the use of the Hyper-V virtualisation driver and associated Windows server components to provide WIndows based OpenStack Hypervisors and does not relate to the ability to run Windows images as guests on OpenStack.
 > Regards
 > James
 > [0]?https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html[1]?https://lists.openstack.org/pipermail/openstack-discuss/2023-March/032888.html


From fungi at yuggoth.org  Thu Apr 13 19:08:46 2023
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Thu, 13 Apr 2023 19:08:46 +0000
Subject: [ptl] Need PTL volunteer for OpenStack Winstackers
In-Reply-To: <CALOCmunYewLhbN4Yu53fqRuuSGptKEtnd=5UxPNRxZDS_V+0Vg@mail.gmail.com>
References: <1870a6b7a1d.114e70a2d994244.3514791188773000084@ghanshyammann.com>
 <1873468752c.bf93124c180931.3029567703559224707@ghanshyammann.com>
 <CAL_crJQn0h0w4zyCV_HLZrYQ4YwsKwVzcbtGAxzdN8REx06g+w@mail.gmail.com>
 <2832840.mvXUDI8C0e@p1>
 <187715c5f64.10fd9250b398749.6791795632701673310@ghanshyammann.com>
 <CAL_crJSDDiwhcG_eLUefJ_UEaM7avtGEA-KzS4e3oi+cnie9Xw@mail.gmail.com>
 <CAHmFs2VaHmZF+yUgfWhxXyDZh2951h1d9TJjPOxYwKVUsG=HRQ@mail.gmail.com>
 <CALOCmunYewLhbN4Yu53fqRuuSGptKEtnd=5UxPNRxZDS_V+0Vg@mail.gmail.com>
Message-ID: <20230413190846.qmfz7aty43v5wckb@yuggoth.org>

On 2023-04-12 09:46:32 +0200 (+0200), Sylvain Bauza wrote:
[...]
> by a next release, we will deprecate Hyper-V virt driver
[...]

With 2023.1 being a SLURP release, does this mean deprecated through
at least 2024.1 (the next SLURP release) and then potentially
dropped as soon as 2024.2 (the following non-SLURP release)?
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230413/a07fc678/attachment-0001.sig>

From gmann at ghanshyammann.com  Thu Apr 13 20:20:48 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 13 Apr 2023 13:20:48 -0700
Subject: [ptl] Need PTL volunteer for OpenStack Winstackers
In-Reply-To: <20230413190846.qmfz7aty43v5wckb@yuggoth.org>
References: <1870a6b7a1d.114e70a2d994244.3514791188773000084@ghanshyammann.com>
 <1873468752c.bf93124c180931.3029567703559224707@ghanshyammann.com>
 <CAL_crJQn0h0w4zyCV_HLZrYQ4YwsKwVzcbtGAxzdN8REx06g+w@mail.gmail.com>
 <2832840.mvXUDI8C0e@p1>
 <187715c5f64.10fd9250b398749.6791795632701673310@ghanshyammann.com>
 <CAL_crJSDDiwhcG_eLUefJ_UEaM7avtGEA-KzS4e3oi+cnie9Xw@mail.gmail.com>
 <CAHmFs2VaHmZF+yUgfWhxXyDZh2951h1d9TJjPOxYwKVUsG=HRQ@mail.gmail.com>
 <CALOCmunYewLhbN4Yu53fqRuuSGptKEtnd=5UxPNRxZDS_V+0Vg@mail.gmail.com>
 <20230413190846.qmfz7aty43v5wckb@yuggoth.org>
Message-ID: <1877c471f98.c5a80efa593828.3754392512680385541@ghanshyammann.com>

 ---- On Thu, 13 Apr 2023 12:08:46 -0700  Jeremy Stanley  wrote --- 
 > On 2023-04-12 09:46:32 +0200 (+0200), Sylvain Bauza wrote:
 > [...]
 > > by a next release, we will deprecate Hyper-V virt driver
 > [...]
 > 
 > With 2023.1 being a SLURP release, does this mean deprecated through
 > at least 2024.1 (the next SLURP release) and then potentially
 > dropped as soon as 2024.2 (the following non-SLURP release)?

The situation is little different here, and it is difficult to guarantee that we can follow normal
deprecation phase here.

Nova hyperV driver has hard dependencies on os-win, and if that goes away, then as long
as hyperV is working with an older version of os-win, it is good to keep HyperV as deprecated.
But once it starts failing and we cannot fix/backport fixes in os-win(if we end up retiring it), then
HyperV driver also needs to be removed. Another challenge is how we keep it testing. HyperV CI
is also going away with Cloudbase, so we do not have any tests running for this driver to know
whether it is working.

IMO, the next possible way can be:
1. merge the 'not tested and experimental' message in Nova [1]
2. backport this message to 2023.1 antelope (Initially, I was not in favour of backport but seeing the
situation, I now agree with Sean's idea of backport it to Antelope)
3. if we retire os-win in the 2023.2 release and no alternate implementation for the HyperV
driver, we remove HyperV driver support in the next release, 2024.1 (considering the 'not tested
and experimental' warning backported to the 2023.1 previous SLURP release).

-gmann

 > -- 
 > Jeremy Stanley
 > 


From sbauza at redhat.com  Thu Apr 13 21:10:15 2023
From: sbauza at redhat.com (Sylvain Bauza)
Date: Thu, 13 Apr 2023 23:10:15 +0200
Subject: [ptl] Need PTL volunteer for OpenStack Winstackers
In-Reply-To: <20230413190846.qmfz7aty43v5wckb@yuggoth.org>
References: <1870a6b7a1d.114e70a2d994244.3514791188773000084@ghanshyammann.com>
 <1873468752c.bf93124c180931.3029567703559224707@ghanshyammann.com>
 <CAL_crJQn0h0w4zyCV_HLZrYQ4YwsKwVzcbtGAxzdN8REx06g+w@mail.gmail.com>
 <2832840.mvXUDI8C0e@p1>
 <187715c5f64.10fd9250b398749.6791795632701673310@ghanshyammann.com>
 <CAL_crJSDDiwhcG_eLUefJ_UEaM7avtGEA-KzS4e3oi+cnie9Xw@mail.gmail.com>
 <CAHmFs2VaHmZF+yUgfWhxXyDZh2951h1d9TJjPOxYwKVUsG=HRQ@mail.gmail.com>
 <CALOCmunYewLhbN4Yu53fqRuuSGptKEtnd=5UxPNRxZDS_V+0Vg@mail.gmail.com>
 <20230413190846.qmfz7aty43v5wckb@yuggoth.org>
Message-ID: <CALOCmu=TsD7AxKpXyPQ+jVKUPjixOSKRupvP-41v8D-ExYK6nA@mail.gmail.com>

Le jeu. 13 avr. 2023 ? 21:15, Jeremy Stanley <fungi at yuggoth.org> a ?crit :

> On 2023-04-12 09:46:32 +0200 (+0200), Sylvain Bauza wrote:
> [...]
> > by a next release, we will deprecate Hyper-V virt driver
> [...]
>
> With 2023.1 being a SLURP release, does this mean deprecated through
> at least 2024.1 (the next SLURP release) and then potentially
> dropped as soon as 2024.2 (the following non-SLURP release)?
>

For the moment, we don't have yet agreed on a specific plan, but we'll
discuss this during the next Nova meeting on Tuesday 1600UTC.
-Sylvain


> --
> Jeremy Stanley
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230413/afba326d/attachment.htm>

From satish.txt at gmail.com  Thu Apr 13 22:04:56 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Thu, 13 Apr 2023 18:04:56 -0400
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <5906e729a3a7adf9dea1fcd47aade4e9a0688e7d.camel@redhat.com>
References: <5906e729a3a7adf9dea1fcd47aade4e9a0688e7d.camel@redhat.com>
Message-ID: <A6BEA46C-87FA-42C5-8384-8D86ED790B5C@gmail.com>

Thank Sean/Matt,

This is interesting that I have only option to use classic mirror with durable :( because without mirror cluster acting up when one of node is down. 

How people are scaling rabbitMQ for large scale? 

Sent from my iPhone

> On Apr 13, 2023, at 7:50 AM, Sean Mooney <smooney at redhat.com> wrote:
> 
> ?On Thu, 2023-04-13 at 09:07 +0100, Matt Crees wrote:
>> Hi all, I'll reply in turn here:
>> 
>> Radek, I agree it definitely will be a good addition to the KA docs.
>> I've got it on my radar, will aim to get a patch proposed this week.
>> 
>> Satish, I haven't personally been able to test durable queues on a
>> system that large. According to the RabbitMQ docs
>> (https://www.rabbitmq.com/queues.html#durability), "Throughput and
>> latency of a queue is not affected by whether a queue is durable or
>> not in most cases." However, I have anecdotally heard that it can
>> affect some performance in particularly large systems.
> 
> the perfomacne of durable queue is dominated by the disk io
> put rabbit on a pcie nvme ssd and it will have littel effect
> use spinnign rust (a HDD even in raid 10) and the iops/throput of the
> storage sued to make the qure durible (that just mean write all messages to disk)
> will be the bottlenck for scaleablity
> combine that with HA and that is worse as it has to be writen to multipel servers.
> i belive that teh mirror implemantion will wait for all copies to be persisted
> but i have not really looked into it. it was raised as a pain point with rabbit by
> operator in the past in terms fo scaling.
> 
>> 
>> Please note that if you are using the classic mirrored queues, you
>> must also have them durable. Transient (i.e. non-durable) mirrored
>> queues are not a supported feature and do cause bugs. (For example the
>> "old incarnation" errors seen here:
>> https://bugs.launchpad.net/kolla-ansible/+bug/1954925)
>> 
>> Nguyen, I can confirm that we've seen the same behaviour. This is
>> caused by a backported change in oslo.messaging (I believe you linked
>> the relevant bug report previously). There is a fix in progress to fix
>> this (https://review.opendev.org/c/openstack/oslo.messaging/+/866617),
>> and in the meantime setting kombu_reconnect_delay < 1.0 does resolve
>> it.
>> 
>> Cheers,
>> Matt
>> 
>>> On Thu, 13 Apr 2023 at 03:04, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com> wrote:
>>> 
>>> update:
>>> I use SAN as Cinder backend.
>>> Nguyen Huu Khoi
>>> 
>>> 
>>> On Thu, Apr 13, 2023 at 9:02?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com> wrote:
>>>> 
>>>> Hello guys.
>>>> 
>>>> I do many tests on xena and yoga. then i am sure that without ha-queue and kombu_reconnect_delay=0.5(it can < 1)
>>>> you cannot launch instances when 1 of 3 controllers is down.
>>>> Somebody can verify what I say, I hope we will have a common solution for this problem because those who use openstack for the first time will continue to ask questions like that.
>>>> 
>>>> Nguyen Huu Khoi
>>>> 
>>>> 
>>>> On Thu, Apr 13, 2023 at 12:59?AM Satish Patel <satish.txt at gmail.com> wrote:
>>>>> 
>>>>> This is great! Matt,
>>>>> 
>>>>> Documentation would be greatly appreciated. I have a counter question: does Durable queue be good for large clouds with 1000 compute nodes or better to not use durable queue. This is a private cloud and we don't care about persistent data.
>>>>> 
>>>>> On Wed, Apr 12, 2023 at 12:37?PM Rados?aw Piliszek <radoslaw.piliszek at gmail.com> wrote:
>>>>>> 
>>>>>> Hi Matt,
>>>>>> 
>>>>>>> As you're now reconfiguring a running deployment, there are
>>>>>>> some extra steps that need to be taken to migrate to durable queues.
>>>>>>> 
>>>>>>> 1. You will need to stop the OpenStack services which use RabbitMQ.
>>>>>>> 
>>>>>>> 2. Reset the state of RabbitMQ one each rabbit node with the following
>>>>>>> commands. You must run each command on all RabbitMQ nodes before
>>>>>>> moving on to the next command. This will remove all queues.
>>>>>>> 
>>>>>>>    rabbitmqctl stop_app
>>>>>>>    rabbitmqctl force_reset
>>>>>>>    rabbitmqctl start_app
>>>>>>> 
>>>>>>> 3. Start the OpenStack services again, at which point they will
>>>>>>> recreate the appropriate queues as durable.
>>>>>> 
>>>>>> This sounds like a great new addition-to-be to the Kolla Ansible docs!
>>>>>> Could you please propose it as a change?
>>>>>> 
>>>>>> Kindest,
>>>>>> Radek
>>>>>> 
>> 
> 


From hongbin034 at gmail.com  Fri Apr 14 00:19:09 2023
From: hongbin034 at gmail.com (Hongbin Lu)
Date: Fri, 14 Apr 2023 08:19:09 +0800
Subject: [zun][zun_api][blazar][config][yoga][kolla-ansible] Adding more
 configuration to config file
In-Reply-To: <CA+_ZFmEQDi=FfOcFJOMWnvCBG7-x2QJ-fKSmWMitBfpKPaXXGg@mail.gmail.com>
References: <CA+_ZFmEQDi=FfOcFJOMWnvCBG7-x2QJ-fKSmWMitBfpKPaXXGg@mail.gmail.com>
Message-ID: <CAFNUc+TMYbaA=1qzxL_TfB56k4ZoEwtBDvRU_gCz1L_yHgcNzg@mail.gmail.com>

Hi James,

I am from Zun team, and not quite familiar with Blazar. I am not sure what
is "blazar database". Could you elaborate? What is the use case?

Best regards,
Hongbin

On Thu, Apr 13, 2023 at 6:07?AM James Leong <jamesleong123098 at gmail.com>
wrote:

> Hi all,
>
> I am playing around with Zun. I have used kolla-ansible as a deployment
> tool for deploying the yoga version of OpenStack. I am trying to add an
> option to the configuration file. However, those added options are not
> recognized by OpenStack when being called. For instance, Zun.conf, I am
> adding a new database (blazar) information to it so I can access blazar
> information in the zun service. Would that be possible to allow the zun_api
> container to access the blazar database?
>
> Thanks for your help,
> James
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230414/409efa0d/attachment.htm>

From wodel.youchi at gmail.com  Fri Apr 14 08:53:30 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Fri, 14 Apr 2023 09:53:30 +0100
Subject: [kolla-ansible][yoga] is there a way to deploy or reconfigure a
 container to run in privileged mode?
Message-ID: <CAJV_UBBA=hSG24W3rakCO8ctzdxcShTjgqSjtsR9GH9B48u6WQ@mail.gmail.com>

Hi,

Is there a way to deploy or reconfigure a container to run in privileged
mode?

I need to make glance-api run in privileged mode.

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230414/f084f916/attachment.htm>

From Danny.Webb at thehutgroup.com  Fri Apr 14 09:10:34 2023
From: Danny.Webb at thehutgroup.com (Danny Webb)
Date: Fri, 14 Apr 2023 09:10:34 +0000
Subject: [kolla-ansible][yoga] is there a way to deploy or reconfigure a
 container to run in privileged mode?
In-Reply-To: <CAJV_UBBA=hSG24W3rakCO8ctzdxcShTjgqSjtsR9GH9B48u6WQ@mail.gmail.com>
References: <CAJV_UBBA=hSG24W3rakCO8ctzdxcShTjgqSjtsR9GH9B48u6WQ@mail.gmail.com>
Message-ID: <LO2P265MB5773C9F41D21F43B96A42EA69A999@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>

https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/glance/defaults/main.yml#L10

In theory you can do your own version of this value that you override in globals.yml.
________________________________
From: wodel youchi <wodel.youchi at gmail.com>
Sent: 14 April 2023 09:53
To: OpenStack Discuss <openstack-discuss at lists.openstack.org>
Subject: [kolla-ansible][yoga] is there a way to deploy or reconfigure a container to run in privileged mode?


CAUTION: This email originates from outside THG

________________________________
Hi,

Is there a way to deploy or reconfigure a container to run in privileged mode?

I need to make glance-api run in privileged mode.

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230414/7559b75e/attachment-0001.htm>

From danish52.jmi at gmail.com  Fri Apr 14 09:19:37 2023
From: danish52.jmi at gmail.com (Danish Khan)
Date: Fri, 14 Apr 2023 14:49:37 +0530
Subject: [Controller/Infra node removal] [openstack-ansible] Need to remove
 infra/controller node from environment.
Message-ID: <CABWYFkwnZCEFT4QMkq_eNa49MXj+e8REJDqYUaR3G+ZcXZ+14Q@mail.gmail.com>

Hello Team,

Is it possible to remove an infra host from environment? If yes, can
you please share the exact steps that need to be followed.

I am trying to remove it manually by destroying all lxc containers
from infra host which needs to be removed and then running setup
openstack playbook. but it is not working properly.

Can someone please share the exact steps needed to be followed to
remove infra host from the environment.

Openstack version: Wallaby or Yoga.

Regards,
Danish


From noonedeadpunk at gmail.com  Fri Apr 14 09:40:22 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Fri, 14 Apr 2023 11:40:22 +0200
Subject: [Controller/Infra node removal] [openstack-ansible] Need to
 remove infra/controller node from environment.
In-Reply-To: <CABWYFkwnZCEFT4QMkq_eNa49MXj+e8REJDqYUaR3G+ZcXZ+14Q@mail.gmail.com>
References: <CABWYFkwnZCEFT4QMkq_eNa49MXj+e8REJDqYUaR3G+ZcXZ+14Q@mail.gmail.com>
Message-ID: <CAPd_6AseqTajinv-U6xyjphCKtNEpyWSOMF6k0kx2gxDXpQjXw@mail.gmail.com>

Hi, Danish,

I don't think we have anything established in our documentation at the
moment, as it's not very common to scale down an environment.

I would probably do it this way:
* Remove host from openstack_user_config.yml
* Remove all related containers and host inteslf from inventory, you
can leverage scripts/inventory-manage.py for that (with -r flag).
* Run haproxy-setup playbook to remove backends on this host from balancing
* Stop/mask keepalived on host that you're removing
* Run setup-openstack to reconfigure services regarding backends that
will be used for rabbitmq and memcached
* Run setup-infrastructure.yml playbook to reconfigure rabbit/galera
clusters and repo containers regarding members that should participate
* Stop containers (systemctl stop lxc) on host you're removing

You can indeed do lxc-containers-destroy as the first step as well
with limiting execution to the host you want to remove, but I'm not
sure how graceful this might be for galera/rabbit and services that
are currently connected to it. Eventually it should be fine, as the
setup is designed to survive controller failure, but it's always
better to avoid services use backends that are gonna be removed.

??, 14 ???. 2023??. ? 11:25, Danish Khan <danish52.jmi at gmail.com>:

>
> Hello Team,
>
> Is it possible to remove an infra host from environment? If yes, can
> you please share the exact steps that need to be followed.
>
> I am trying to remove it manually by destroying all lxc containers
> from infra host which needs to be removed and then running setup
> openstack playbook. but it is not working properly.
>
> Can someone please share the exact steps needed to be followed to
> remove infra host from the environment.
>
> Openstack version: Wallaby or Yoga.
>
> Regards,
> Danish
>


From ralonsoh at redhat.com  Fri Apr 14 10:50:56 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Fri, 14 Apr 2023 12:50:56 +0200
Subject: [neutron] Drivers meeting agenda
Message-ID: <CAECr9X5YJ5ecxkqwVet2=GFqSXaOB_HZctYtK6bCzefvdVnkdg@mail.gmail.com>

Hello Neutrinos:

Remember we have the Neutron drivers meeting today at 14UTC. The agenda is
here: https://wiki.openstack.org/wiki/Meetings/NeutronDrivers

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230414/e81752ad/attachment.htm>

From smooney at redhat.com  Fri Apr 14 11:46:09 2023
From: smooney at redhat.com (Sean Mooney)
Date: Fri, 14 Apr 2023 12:46:09 +0100
Subject: [kolla-ansible][yoga] Glance backend cinder Privsep daemon
 failed to start operation not permitted
In-Reply-To: <CAJV_UBCkuvnXem=A8czKSE3zJBp5LtQ9wXQPr-y5LE4X8k3V8A@mail.gmail.com>
References: <CAJV_UBC95fMQh00w7vxbyV55F=wXuLXjgVYG5fYy08en2VYtaA@mail.gmail.com>
 <CADO3vb4++zhHTu3Gfdsb3pYZFMdwGSytDuXhN0QZ-JCdVFqu7A@mail.gmail.com>
 <323313cf9ef907a0bbbdce18e7ae71654385e1f2.camel@redhat.com>
 <CAJV_UBDUQ0x_Y24Q5S8QbvJrLnZ8Moy2q=LsvojjSMRooSrXrg@mail.gmail.com>
 <e0bd7f4fdb6a4e1e949531730f9f19a0304781d6.camel@redhat.com>
 <CAJV_UBCkuvnXem=A8czKSE3zJBp5LtQ9wXQPr-y5LE4X8k3V8A@mail.gmail.com>
Message-ID: <b2c015f0bda7b9ae16ecbb3dff71e69665db0878.camel@redhat.com>

given it appears to be replacing it directly instead of merging then you need to add the following to global.yaml instead

glance_services:
  glance-api:
    container_name: glance_api
    group: glance-api
    host_in_groups: "{{ inventory_hostname in glance_api_hosts }}"
    enabled: true
    image: "{{ glance_api_image_full }}"
    environment: "{{ glance_api_container_proxy }}"
    privileged: true
    volumes: "{{ glance_api_default_volumes + glance_api_extra_volumes }}"
    dimensions: "{{ glance_api_dimensions }}"
    healthcheck: "{{ glance_api_healthcheck }}"
    haproxy:
      glance_api:
        enabled: "{{ enable_glance | bool and not glance_enable_tls_backend | bool }}"
        mode: "http"
        external: false
        port: "{{ glance_api_port }}"
        frontend_http_extra:
          - "timeout client {{ haproxy_glance_api_client_timeout }}"
        backend_http_extra:
          - "timeout server {{ haproxy_glance_api_server_timeout }}"
        custom_member_list: "{{ haproxy_members.split(';') }}"
      glance_api_external:
        enabled: "{{ enable_glance | bool and not glance_enable_tls_backend | bool }}"
        mode: "http"
        external: true
        port: "{{ glance_api_port }}"
        frontend_http_extra:
          - "timeout client {{ haproxy_glance_api_client_timeout }}"
        backend_http_extra:
          - "timeout server {{ haproxy_glance_api_server_timeout }}"
        custom_member_list: "{{ haproxy_members.split(';') }}"



basically copy the default with all teh templates and just update privileged to true

On Thu, 2023-04-13 at 15:23 +0100, wodel youchi wrote:
> Hi,
> 
> Adding those lines to globals.yml did produce errors, complaining about the
> enabled line missing
> 
> > glance_services:
> >   glance-api:
> >     privileged: true
> > 
> 
> Then I tried this
> 
> > glance_services:
> >   glance-api:
> >     enabled: true
> >     privileged: true
> > 
> 
> Gave these errors
> fatal: [192.168.2.23]: FAILED! => {"msg": "The conditional check
> 'item.value.host_in_groups | bool' failed. The error was: error while
> evaluating conditional (item.value.host_in_groups | bool): 'dict object'
> has no attribute 'host_in_groups'\n\nThe error appears to be in
> '/home/deployer/kollavenv/yogavenv/share/kolla-ansible/ansible/roles/glance/tasks/config.yml':
> line 2, column 3, but may\nbe elsewhere in the file depending on the exact
> syntax problem.\n\nThe offending line appears to be:\n\n---\n- name:
> Ensuring config directories exist\n  ^ here\n"}
> fatal: [192.168.2.27]: FAILED! => {"msg": "The conditional check
> 'item.value.host_in_groups | bool' failed. The error was: error while
> evaluating conditional (item.value.host_in_groups | bool): 'dict object'
> has no attribute 'host_in_groups'\n\nThe error appears to be in
> '/home/deployer/kollavenv/yogavenv/share/kolla-ansible/ansible/roles/glance/tasks/config.yml':
> line 2, column 3, but may\nbe elsewhere in the file depending on the exact
> syntax problem.\n\nThe offending line appears to be:\n\n---\n- name:
> Ensuring config directories exist\n  ^ here\n"}
> fatal: [192.168.2.31]: FAILED! => {"msg": "The conditional check
> 'item.value.host_in_groups | bool' failed. The error was: error while
> evaluating conditional (item.value.host_in_groups | bool): 'dict object'
> has no attribute 'host_in_groups'\n\nThe error appears to be in
> '/home/deployer/kollavenv/yogavenv/share/kolla-ansible/ansible/roles/glance/tasks/config.yml':
> line 2, column 3, but may\nbe elsewhere in the file depending on the exact
> syntax problem.\n\nThe offending line appears to be:\n\n---\n- name:
> Ensuring config directories exist\n  ^ here\n"}
> 
> 
> it seems, this configuration is discarding main.yml from
> https://github.com/openstack/kolla-ansible/blob/stable/yoga/ansible/roles/glance/defaults/main.yml#L10
> not just replacing the needed variables.
> 
> Regards.
> 
> Le jeu. 13 avr. 2023 ? 13:00, Sean Mooney <smooney at redhat.com> a ?crit :
> 
> > On Thu, 2023-04-13 at 11:41 +0100, wodel youchi wrote:
> > > Thanks for the help,
> > > 
> > > I modified my glance-api.conf like this but no luck, I got the same
> > problem
> > > : Privsep daemon failed to start
> > > 
> > > > [cinder]
> > > > cinder_store_auth_address = https://dashint.example.com:5000/v3
> > > > cinder_store_project_name = service
> > > > cinder_volume_type = nfstype
> > > > rootwrap_config = /etc/glance/rootwrap.conf
> > > > 
> > > > *cinder_store_user_name = glancecinder_store_password =
> > glance-password*
> > > > cinder_catalog_info = volumev3:cinderv3:internalURL
> > > > 
> > > 
> > > > *###cinder_store_user_name = cinder###cinder_store_password =
> > > > cinder-password  *
> > > > 
> > > 
> > > 
> > > I thought once cinder has the capability to read & write into the
> > backend,
> > > glance will just use it to upload the images!!
> > > 
> > > Another thing, about the credentials, which ones should I use? Glance's
> > or
> > > cinder's I thought it should be cinder's !! but in your example @Sean you
> > > used {{ glance_keystone_user }} and  {{ glance_keystone_password }}
> > 
> > either would work but normally i woudl consider it bad partice for a
> > service to have the username/password for a differnt users account
> > so glance should alwasy use its user to talk to other services when its
> > not using the keystone user token passed in to the api.
> > 
> > > 
> > > Lastly I searched how to launch a privileged container in kolla but I
> > > didn't find anything.
> > 
> > i see the issue
> > 
> > https://github.com/openstack/kolla-ansible/blob/stable/yoga/ansible/roles/glance/defaults/main.yml#L10
> > glace api is only privlaged if you use iscsi for the cinder backend.
> > privileged: "{{ enable_cinder | bool and enable_cinder_backend_iscsi |
> > bool }}"
> > you are using nfs.
> > 
> > you can workaround this in your global.yaml by adding this i think
> > 
> > glance_services:
> >   glance-api:
> >    privileged: true
> > 
> > alternitivly you can do it via the inventory file by seting that as a
> > host/group var.
> > > 
> > > Regards.
> > 
> > 



From smooney at redhat.com  Fri Apr 14 11:48:15 2023
From: smooney at redhat.com (Sean Mooney)
Date: Fri, 14 Apr 2023 12:48:15 +0100
Subject: [kolla-ansible][yoga] Glance backend cinder Privsep daemon
 failed to start operation not permitted
In-Reply-To: <b2c015f0bda7b9ae16ecbb3dff71e69665db0878.camel@redhat.com>
References: <CAJV_UBC95fMQh00w7vxbyV55F=wXuLXjgVYG5fYy08en2VYtaA@mail.gmail.com>
 <CADO3vb4++zhHTu3Gfdsb3pYZFMdwGSytDuXhN0QZ-JCdVFqu7A@mail.gmail.com>
 <323313cf9ef907a0bbbdce18e7ae71654385e1f2.camel@redhat.com>
 <CAJV_UBDUQ0x_Y24Q5S8QbvJrLnZ8Moy2q=LsvojjSMRooSrXrg@mail.gmail.com>
 <e0bd7f4fdb6a4e1e949531730f9f19a0304781d6.camel@redhat.com>
 <CAJV_UBCkuvnXem=A8czKSE3zJBp5LtQ9wXQPr-y5LE4X8k3V8A@mail.gmail.com>
 <b2c015f0bda7b9ae16ecbb3dff71e69665db0878.camel@redhat.com>
Message-ID: <b7e2ae4d7740ca4175a941ce30a0b354b6de99b7.camel@redhat.com>

On Fri, 2023-04-14 at 12:46 +0100, Sean Mooney wrote:
> given it appears to be replacing it directly instead of merging then you need to add the following to global.yaml instead
> 
slight correction you will also need to include the glance-tls-proxy section
https://github.com/openstack/kolla-ansible/blob/stable/yoga/ansible/roles/glance/defaults/main.yml#L2-L66
since that is also under glance_services so copy all the highlighted section


> glance_services:
>   glance-api:
>     container_name: glance_api
>     group: glance-api
>     host_in_groups: "{{ inventory_hostname in glance_api_hosts }}"
>     enabled: true
>     image: "{{ glance_api_image_full }}"
>     environment: "{{ glance_api_container_proxy }}"
>     privileged: true
>     volumes: "{{ glance_api_default_volumes + glance_api_extra_volumes }}"
>     dimensions: "{{ glance_api_dimensions }}"
>     healthcheck: "{{ glance_api_healthcheck }}"
>     haproxy:
>       glance_api:
>         enabled: "{{ enable_glance | bool and not glance_enable_tls_backend | bool }}"
>         mode: "http"
>         external: false
>         port: "{{ glance_api_port }}"
>         frontend_http_extra:
>           - "timeout client {{ haproxy_glance_api_client_timeout }}"
>         backend_http_extra:
>           - "timeout server {{ haproxy_glance_api_server_timeout }}"
>         custom_member_list: "{{ haproxy_members.split(';') }}"
>       glance_api_external:
>         enabled: "{{ enable_glance | bool and not glance_enable_tls_backend | bool }}"
>         mode: "http"
>         external: true
>         port: "{{ glance_api_port }}"
>         frontend_http_extra:
>           - "timeout client {{ haproxy_glance_api_client_timeout }}"
>         backend_http_extra:
>           - "timeout server {{ haproxy_glance_api_server_timeout }}"
>         custom_member_list: "{{ haproxy_members.split(';') }}"
> 
> 
> 
> basically copy the default with all teh templates and just update privileged to true
> 
> On Thu, 2023-04-13 at 15:23 +0100, wodel youchi wrote:
> > Hi,
> > 
> > Adding those lines to globals.yml did produce errors, complaining about the
> > enabled line missing
> > 
> > > glance_services:
> > >   glance-api:
> > >     privileged: true
> > > 
> > 
> > Then I tried this
> > 
> > > glance_services:
> > >   glance-api:
> > >     enabled: true
> > >     privileged: true
> > > 
> > 
> > Gave these errors
> > fatal: [192.168.2.23]: FAILED! => {"msg": "The conditional check
> > 'item.value.host_in_groups | bool' failed. The error was: error while
> > evaluating conditional (item.value.host_in_groups | bool): 'dict object'
> > has no attribute 'host_in_groups'\n\nThe error appears to be in
> > '/home/deployer/kollavenv/yogavenv/share/kolla-ansible/ansible/roles/glance/tasks/config.yml':
> > line 2, column 3, but may\nbe elsewhere in the file depending on the exact
> > syntax problem.\n\nThe offending line appears to be:\n\n---\n- name:
> > Ensuring config directories exist\n  ^ here\n"}
> > fatal: [192.168.2.27]: FAILED! => {"msg": "The conditional check
> > 'item.value.host_in_groups | bool' failed. The error was: error while
> > evaluating conditional (item.value.host_in_groups | bool): 'dict object'
> > has no attribute 'host_in_groups'\n\nThe error appears to be in
> > '/home/deployer/kollavenv/yogavenv/share/kolla-ansible/ansible/roles/glance/tasks/config.yml':
> > line 2, column 3, but may\nbe elsewhere in the file depending on the exact
> > syntax problem.\n\nThe offending line appears to be:\n\n---\n- name:
> > Ensuring config directories exist\n  ^ here\n"}
> > fatal: [192.168.2.31]: FAILED! => {"msg": "The conditional check
> > 'item.value.host_in_groups | bool' failed. The error was: error while
> > evaluating conditional (item.value.host_in_groups | bool): 'dict object'
> > has no attribute 'host_in_groups'\n\nThe error appears to be in
> > '/home/deployer/kollavenv/yogavenv/share/kolla-ansible/ansible/roles/glance/tasks/config.yml':
> > line 2, column 3, but may\nbe elsewhere in the file depending on the exact
> > syntax problem.\n\nThe offending line appears to be:\n\n---\n- name:
> > Ensuring config directories exist\n  ^ here\n"}
> > 
> > 
> > it seems, this configuration is discarding main.yml from
> > https://github.com/openstack/kolla-ansible/blob/stable/yoga/ansible/roles/glance/defaults/main.yml#L10
> > not just replacing the needed variables.
> > 
> > Regards.
> > 
> > Le jeu. 13 avr. 2023 ? 13:00, Sean Mooney <smooney at redhat.com> a ?crit :
> > 
> > > On Thu, 2023-04-13 at 11:41 +0100, wodel youchi wrote:
> > > > Thanks for the help,
> > > > 
> > > > I modified my glance-api.conf like this but no luck, I got the same
> > > problem
> > > > : Privsep daemon failed to start
> > > > 
> > > > > [cinder]
> > > > > cinder_store_auth_address = https://dashint.example.com:5000/v3
> > > > > cinder_store_project_name = service
> > > > > cinder_volume_type = nfstype
> > > > > rootwrap_config = /etc/glance/rootwrap.conf
> > > > > 
> > > > > *cinder_store_user_name = glancecinder_store_password =
> > > glance-password*
> > > > > cinder_catalog_info = volumev3:cinderv3:internalURL
> > > > > 
> > > > 
> > > > > *###cinder_store_user_name = cinder###cinder_store_password =
> > > > > cinder-password  *
> > > > > 
> > > > 
> > > > 
> > > > I thought once cinder has the capability to read & write into the
> > > backend,
> > > > glance will just use it to upload the images!!
> > > > 
> > > > Another thing, about the credentials, which ones should I use? Glance's
> > > or
> > > > cinder's I thought it should be cinder's !! but in your example @Sean you
> > > > used {{ glance_keystone_user }} and  {{ glance_keystone_password }}
> > > 
> > > either would work but normally i woudl consider it bad partice for a
> > > service to have the username/password for a differnt users account
> > > so glance should alwasy use its user to talk to other services when its
> > > not using the keystone user token passed in to the api.
> > > 
> > > > 
> > > > Lastly I searched how to launch a privileged container in kolla but I
> > > > didn't find anything.
> > > 
> > > i see the issue
> > > 
> > > https://github.com/openstack/kolla-ansible/blob/stable/yoga/ansible/roles/glance/defaults/main.yml#L10
> > > glace api is only privlaged if you use iscsi for the cinder backend.
> > > privileged: "{{ enable_cinder | bool and enable_cinder_backend_iscsi |
> > > bool }}"
> > > you are using nfs.
> > > 
> > > you can workaround this in your global.yaml by adding this i think
> > > 
> > > glance_services:
> > >   glance-api:
> > >    privileged: true
> > > 
> > > alternitivly you can do it via the inventory file by seting that as a
> > > host/group var.
> > > > 
> > > > Regards.
> > > 
> > > 
> 



From nguyenhuukhoinw at gmail.com  Fri Apr 14 14:41:54 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Fri, 14 Apr 2023 21:41:54 +0700
Subject: [glance][cinder]create volume from image too slow
In-Reply-To: <CABAODRd4v9XqRWE7ojxUC6UFynNe29wbB+G-WOYLFmP1besN8A@mail.gmail.com>
References: <CABAODRd4v9XqRWE7ojxUC6UFynNe29wbB+G-WOYLFmP1besN8A@mail.gmail.com>
Message-ID: <CABAODRfftihE226RkA4bqqqP_oAtEW6Y_74N6mxmP22qJQfPrg@mail.gmail.com>

I update:

because openstack xena and yoga using kolla-ansible(cinder docker image
base 20.04) have a problem with qemu-img version 4.2.1 (Debian
1:4.2-3ubuntu6.25). it will cause the copy image to volume very slow,
to fix this we need upgrade to qemu-img version 6.2.0 (Debian
1:6.2+dfsg-2ubuntu6.7). I use kolla build to do this.

preference: https://bugzilla.redhat.com/show_bug.cgi?id=1847192

Nguyen Huu Khoi


On Thu, Apr 13, 2023 at 9:00?PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Hello guys.
> I am using nfs for glance and SAN for cinder but when i create 1 gb volume
> with 100mb image(Converted 112.00 MB image at 25.4 MB/s) then it will fast.
> however, if I create 100gb volume with 100mb image(Converted 112.00 MB
> image at 8.24 MB/s) then it will very slow.
>
> Pls give me some advices. ty
>
> Nguyen Huu Khoi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230414/4239a132/attachment.htm>

From knikolla at bu.edu  Fri Apr 14 16:45:10 2023
From: knikolla at bu.edu (Nikolla, Kristi)
Date: Fri, 14 Apr 2023 16:45:10 +0000
Subject: [tc][all] What's happening in the Technical Committee - 2023 April 14
Message-ID: <74B79382-3911-49DB-B462-88E858DFE1D1@bu.edu>

Hi all,

Here?s another edition of ?What?s happening on the Technical Committee.?

Meeting
=======
The Technical Committee met on April 11 on the #openstack-tc channel on OFTC IRC. The next weekly meeting will happen on April 18th. For more information visit https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

Happenings
==========

Final call for Winstackers (and Windows Support)
------------------------------------------------
Cloudbase Solutions are no longer in a position to maintain support for running OpenStack on Windows and have also ceased operation of their 3rd party CI for the windows support across a number of OpenStack projects.

This is the final call for any maintainers to step forward for maintaining Winstackers if this feature is important to them in OpenStack[0][1]. If there is no response by June 2023, we will discuss the retirement of this project.

[0]. https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033342.html
[1]. https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033273.html

Final call for Vitrage maintainers
----------------------------------
This is the final call for maintainers. If anyone is using or interested in this project, this is the right time to step up. If there is no response by the end of April 2023, we will discuss the retirement of this project.[0]

[0]. https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033348.html

Patrole retirement
------------------
As notified on the mailing list yesterday[0] and by a patch proposed to the governance repo[1], the Patrole project is being retired.
The project is inactive, and there was no interest from prospective maintainers.

[0]. https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033346.html
[1]. https://review.opendev.org/c/openstack/governance/+/880014

Gate status
-----------
Every week we have a look at the overall status of the "gate". In the last meeting the status was reported and not super healthy[0].

* The U-C bump broke Glance's functional test and there is a desire to put Glance's functional tests behind the U-C gate so that future breakages are caught before they happen.
* It was also reported that we were seeing some guest kernel crashes on volume tests. These may be related to nested virtualization.

[0]. https://meetings.opendev.org/meetings/tc/2023/tc.2023-04-11-17.59.log.html#l-33


Changes
=======
* Merged
  * Add ovn-bgp-agent to Neutron governed projects (project-update) | https://review.opendev.org/c/openstack/governance/+/879455
  * Add xstatic-angular-fileupload as Horizon team deliverables (project-update) | https://review.opendev.org/c/openstack/governance/+/873845
  * Retire puppet-tacker - Step 3: Retire Repository (project-update) | https://review.opendev.org/c/openstack/governance/+/875295
* New Open
  * Appoint Jerry Zhou as Sahara PTL (formal-vote) | https://review.opendev.org/c/openstack/governance/+/879847
  * Retire patrole (project-update) | https://review.opendev.org/c/openstack/governance/+/880014
  * Correct the old deprecated policies removal timeline for SLURP release (formal-vote) | https://review.opendev.org/c/openstack/governance/+/880238
  * Add missing governance-sigs repo in technical-committee-repos.yaml (project-update) | https://review.opendev.org/c/openstack/governance/+/880237
  * Retire puppet-rally - Step 3: Retire Repository (project-update) | https://review.opendev.org/c/openstack/governance/+/880018
* All Open
  * https://review.opendev.org/q/project:openstack/governance+status:open

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 an email with the tag [tc] on the openstack-discuss mailing list.
2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 16:00 UTC
3. IRC: Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel on OFTC.

From fadhel.bedda at gmail.com  Fri Apr 14 17:28:40 2023
From: fadhel.bedda at gmail.com (BEDDA Fadhel)
Date: Fri, 14 Apr 2023 19:28:40 +0200
Subject: Installation
Message-ID: <CAE1GhS7fwyS4s2znpW+AsRHV4rW+_jgB_VeRww_P1Gu3mFqxtA@mail.gmail.com>

Bonjour,
Ou je peux trouver pour tester openstack sur Ubuntu 22.04
Cordialement
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230414/b665d17b/attachment.htm>

From noonedeadpunk at gmail.com  Fri Apr 14 18:11:45 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Fri, 14 Apr 2023 20:11:45 +0200
Subject: Installation
In-Reply-To: <CAE1GhS7fwyS4s2znpW+AsRHV4rW+_jgB_VeRww_P1Gu3mFqxtA@mail.gmail.com>
References: <CAE1GhS7fwyS4s2znpW+AsRHV4rW+_jgB_VeRww_P1Gu3mFqxtA@mail.gmail.com>
Message-ID: <CAPd_6AsdXheNxZR=rGUtWuBepPs-jQ_=tkedXz7xa3DzgfyDbA@mail.gmail.com>

Hi,

I would suggest looking at All-In-One installations that are provided by
deployment toolings, like:
1. OpenStack-Ansible:
https://docs.openstack.org/openstack-ansible/latest/user/aio/quickstart.html
2. Kolla-ansible:
https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html

Using that methods you will be able to get basic concepts and deploy an
OpenStack sandbox. Later on same projects/concepts can be extrapolated for
real production deployments.

You also can always spawn a devstack that is heavily used by OpenStack
developers to test code and spawn deployment environments:
https://docs.openstack.org/devstack/latest/guides/single-machine.html

??, 14 ???. 2023 ?., 19:38 BEDDA Fadhel <fadhel.bedda at gmail.com>:

> Bonjour,
> Ou je peux trouver pour tester openstack sur Ubuntu 22.04
> Cordialement
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230414/1468ca68/attachment-0001.htm>

From nfleishman at student.ccaeagles.org  Fri Apr 14 19:53:27 2023
From: nfleishman at student.ccaeagles.org (Trey Fleishman)
Date: Fri, 14 Apr 2023 15:53:27 -0400
Subject: Installation
In-Reply-To: <CAPd_6AsdXheNxZR=rGUtWuBepPs-jQ_=tkedXz7xa3DzgfyDbA@mail.gmail.com>
References: <CAE1GhS7fwyS4s2znpW+AsRHV4rW+_jgB_VeRww_P1Gu3mFqxtA@mail.gmail.com>
 <CAPd_6AsdXheNxZR=rGUtWuBepPs-jQ_=tkedXz7xa3DzgfyDbA@mail.gmail.com>
Message-ID: <CAF_4gkes7eUF0-V15uv8RzCn+dh6=oWACYcaaNKwUkQazVS=mg@mail.gmail.com>

You can use devstack, it's a deployment system found here
https://docs.openstack.org/devstack/latest/


On Fri, Apr 14, 2023 at 2:13?PM Dmitriy Rabotyagov <noonedeadpunk at gmail.com>
wrote:

> Hi,
>
> I would suggest looking at All-In-One installations that are provided by
> deployment toolings, like:
> 1. OpenStack-Ansible:
> https://docs.openstack.org/openstack-ansible/latest/user/aio/quickstart.html
> 2. Kolla-ansible:
> https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html
>
> Using that methods you will be able to get basic concepts and deploy an
> OpenStack sandbox. Later on same projects/concepts can be extrapolated for
> real production deployments.
>
> You also can always spawn a devstack that is heavily used by OpenStack
> developers to test code and spawn deployment environments:
> https://docs.openstack.org/devstack/latest/guides/single-machine.html
>
> ??, 14 ???. 2023 ?., 19:38 BEDDA Fadhel <fadhel.bedda at gmail.com>:
>
>> Bonjour,
>> Ou je peux trouver pour tester openstack sur Ubuntu 22.04
>> Cordialement
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230414/680b8684/attachment.htm>

From jlibosva at redhat.com  Fri Apr 14 21:01:30 2023
From: jlibosva at redhat.com (Jakub Libosvar)
Date: Fri, 14 Apr 2023 17:01:30 -0400
Subject: [Neutron] Future of TripleO OVN migration in-tree code
Message-ID: <1FBD2524-4B12-4EF9-BF86-4876FF830899@redhat.com>

Hello Neutrinos and others,

as this has been brought up several times through some conversation channels with no consensus, I wanted to start a discussion and possibly find a consensus about the code for migrating an OpenStack from OVS mechanism driver to OVN [1].

The code leverages TripleO to install and to configure OVN services, however the TripleO project is no longer maintained after Zed release [2].
This brings up the question what to do with the migration tooling that relies on TripleO. Shall we remove the code completely or is there anybody who would be interested in maintaining that code and implement support for other installers?

Thanks

Kuba

[1] https://opendev.org/openstack/neutron/src/branch/master/tools/ovn_migration/tripleo_environment
[2] https://review.opendev.org/c/openstack/governance/+/878799



From noonedeadpunk at gmail.com  Sat Apr 15 03:10:25 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Sat, 15 Apr 2023 05:10:25 +0200
Subject: [Neutron] Future of TripleO OVN migration in-tree code
In-Reply-To: <1FBD2524-4B12-4EF9-BF86-4876FF830899@redhat.com>
References: <1FBD2524-4B12-4EF9-BF86-4876FF830899@redhat.com>
Message-ID: <CAPd_6Avs7_vjMFOt1qNKd64knD2FbLb9_FxXXE9ni42p1suyXw@mail.gmail.com>

Hi, Jakub,

I'm interested to keep OVN migration alive. At the same time I'm not
interested in maintaining TripleO bits.

I can check the code deeper during the next week and see what I can do and
return back to you.

Ideally I think the code should be tool-agnostic, but at worst case
scenario I will be able to work on adding OpenStack-Ansible support for the
migration.

??, 14 ???. 2023 ?., 23:05 Jakub Libosvar <jlibosva at redhat.com>:

> Hello Neutrinos and others,
>
> as this has been brought up several times through some conversation
> channels with no consensus, I wanted to start a discussion and possibly
> find a consensus about the code for migrating an OpenStack from OVS
> mechanism driver to OVN [1].
>
> The code leverages TripleO to install and to configure OVN services,
> however the TripleO project is no longer maintained after Zed release [2].
> This brings up the question what to do with the migration tooling that
> relies on TripleO. Shall we remove the code completely or is there anybody
> who would be interested in maintaining that code and implement support for
> other installers?
>
> Thanks
>
> Kuba
>
> [1]
> https://opendev.org/openstack/neutron/src/branch/master/tools/ovn_migration/tripleo_environment
> [2] https://review.opendev.org/c/openstack/governance/+/878799
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230415/774eef48/attachment.htm>

From wodel.youchi at gmail.com  Sun Apr 16 05:25:01 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Sun, 16 Apr 2023 06:25:01 +0100
Subject: [kolla-ansible][yoga] Glance backend cinder Privsep daemon failed
 to start operation not permitted
In-Reply-To: <b7e2ae4d7740ca4175a941ce30a0b354b6de99b7.camel@redhat.com>
References: <CAJV_UBC95fMQh00w7vxbyV55F=wXuLXjgVYG5fYy08en2VYtaA@mail.gmail.com>
 <CADO3vb4++zhHTu3Gfdsb3pYZFMdwGSytDuXhN0QZ-JCdVFqu7A@mail.gmail.com>
 <323313cf9ef907a0bbbdce18e7ae71654385e1f2.camel@redhat.com>
 <CAJV_UBDUQ0x_Y24Q5S8QbvJrLnZ8Moy2q=LsvojjSMRooSrXrg@mail.gmail.com>
 <e0bd7f4fdb6a4e1e949531730f9f19a0304781d6.camel@redhat.com>
 <CAJV_UBCkuvnXem=A8czKSE3zJBp5LtQ9wXQPr-y5LE4X8k3V8A@mail.gmail.com>
 <b2c015f0bda7b9ae16ecbb3dff71e69665db0878.camel@redhat.com>
 <b7e2ae4d7740ca4175a941ce30a0b354b6de99b7.camel@redhat.com>
Message-ID: <CAJV_UBBHK9L=eS0QhYKx9Jm3xAHvWX6F9F8dH9uFTBn-pVKhdA@mail.gmail.com>

Hi;

I have managed to start the glance-api container in privileged mode, but I
still have issues to get glance to use my cinder backend backed by nfs.

When I push an image, now I am getting :

Stderr: '/var/lib/kolla/venv/bin/glance-rootwrap: Unauthorized command:
mount -t nfs 20.1.0.32:/kolla_nfs
/var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624
f97bf3623b13014f22186b7 (no filter matched)\n'

Any ideas on that?


PS : How did I managed to start the glance-api as privileged container
1 - I edited this file and added this variable
vim kollavenv/yogavenv/share/kolla-ansible/ansible/group_vars/all.yml
glance_privileged_container: "no"


2 - I edited this file
vim
kollavenv/yogavenv/share/kolla-ansible/ansible/roles/glance/defaults/main.yml
---
glance_services:
 glance-api:
   container_name: glance_api
   group: glance-api
   host_in_groups: "{{ inventory_hostname in glance_api_hosts }}"
   enabled: true
   image: "{{ glance_api_image_full }}"
   environment: "{{ glance_api_container_proxy }}"
   *privileged: "{{ enable_cinder | bool and enable_cinder_backend_iscsi |
bool or glance_privileged_container | bool }}"* <-------


3 - I added this configuration to my globals.yml
vim /etc/yogakolla/globals.yml
glance_privileged_container: "yes"

4 - Then I redeployed the glance service
kolla-ansible --configdir /etc/yogakolla -i multinode-yoga deploy --tags
glance -v

5 - Verifying
[root at controllerb ~]# docker inspect glance_api | grep -i pri
           "IpcMode": "private",
           *"Pri**vileged": true,*
               "Propagation": "rprivate"
               "Propagation": "rprivate"
               "PS1=$(tput bold)($(printenv KOLLA_SERVICE_NAME))$(tput
sgr0)[$(id -un)@$(hostname -s) $(pwd)]$ ",




Regards.

Le ven. 14 avr. 2023 ? 12:48, Sean Mooney <smooney at redhat.com> a ?crit :

> On Fri, 2023-04-14 at 12:46 +0100, Sean Mooney wrote:
> > given it appears to be replacing it directly instead of merging then you
> need to add the following to global.yaml instead
> >
> slight correction you will also need to include the glance-tls-proxy
> section
>
> https://github.com/openstack/kolla-ansible/blob/stable/yoga/ansible/roles/glance/defaults/main.yml#L2-L66
> since that is also under glance_services so copy all the highlighted
> section
>
>
> > glance_services:
> >   glance-api:
> >     container_name: glance_api
> >     group: glance-api
> >     host_in_groups: "{{ inventory_hostname in glance_api_hosts }}"
> >     enabled: true
> >     image: "{{ glance_api_image_full }}"
> >     environment: "{{ glance_api_container_proxy }}"
> >     privileged: true
> >     volumes: "{{ glance_api_default_volumes + glance_api_extra_volumes
> }}"
> >     dimensions: "{{ glance_api_dimensions }}"
> >     healthcheck: "{{ glance_api_healthcheck }}"
> >     haproxy:
> >       glance_api:
> >         enabled: "{{ enable_glance | bool and not
> glance_enable_tls_backend | bool }}"
> >         mode: "http"
> >         external: false
> >         port: "{{ glance_api_port }}"
> >         frontend_http_extra:
> >           - "timeout client {{ haproxy_glance_api_client_timeout }}"
> >         backend_http_extra:
> >           - "timeout server {{ haproxy_glance_api_server_timeout }}"
> >         custom_member_list: "{{ haproxy_members.split(';') }}"
> >       glance_api_external:
> >         enabled: "{{ enable_glance | bool and not
> glance_enable_tls_backend | bool }}"
> >         mode: "http"
> >         external: true
> >         port: "{{ glance_api_port }}"
> >         frontend_http_extra:
> >           - "timeout client {{ haproxy_glance_api_client_timeout }}"
> >         backend_http_extra:
> >           - "timeout server {{ haproxy_glance_api_server_timeout }}"
> >         custom_member_list: "{{ haproxy_members.split(';') }}"
> >
> >
> >
> > basically copy the default with all teh templates and just update
> privileged to true
> >
> > On Thu, 2023-04-13 at 15:23 +0100, wodel youchi wrote:
> > > Hi,
> > >
> > > Adding those lines to globals.yml did produce errors, complaining
> about the
> > > enabled line missing
> > >
> > > > glance_services:
> > > >   glance-api:
> > > >     privileged: true
> > > >
> > >
> > > Then I tried this
> > >
> > > > glance_services:
> > > >   glance-api:
> > > >     enabled: true
> > > >     privileged: true
> > > >
> > >
> > > Gave these errors
> > > fatal: [192.168.2.23]: FAILED! => {"msg": "The conditional check
> > > 'item.value.host_in_groups | bool' failed. The error was: error while
> > > evaluating conditional (item.value.host_in_groups | bool): 'dict
> object'
> > > has no attribute 'host_in_groups'\n\nThe error appears to be in
> > >
> '/home/deployer/kollavenv/yogavenv/share/kolla-ansible/ansible/roles/glance/tasks/config.yml':
> > > line 2, column 3, but may\nbe elsewhere in the file depending on the
> exact
> > > syntax problem.\n\nThe offending line appears to be:\n\n---\n- name:
> > > Ensuring config directories exist\n  ^ here\n"}
> > > fatal: [192.168.2.27]: FAILED! => {"msg": "The conditional check
> > > 'item.value.host_in_groups | bool' failed. The error was: error while
> > > evaluating conditional (item.value.host_in_groups | bool): 'dict
> object'
> > > has no attribute 'host_in_groups'\n\nThe error appears to be in
> > >
> '/home/deployer/kollavenv/yogavenv/share/kolla-ansible/ansible/roles/glance/tasks/config.yml':
> > > line 2, column 3, but may\nbe elsewhere in the file depending on the
> exact
> > > syntax problem.\n\nThe offending line appears to be:\n\n---\n- name:
> > > Ensuring config directories exist\n  ^ here\n"}
> > > fatal: [192.168.2.31]: FAILED! => {"msg": "The conditional check
> > > 'item.value.host_in_groups | bool' failed. The error was: error while
> > > evaluating conditional (item.value.host_in_groups | bool): 'dict
> object'
> > > has no attribute 'host_in_groups'\n\nThe error appears to be in
> > >
> '/home/deployer/kollavenv/yogavenv/share/kolla-ansible/ansible/roles/glance/tasks/config.yml':
> > > line 2, column 3, but may\nbe elsewhere in the file depending on the
> exact
> > > syntax problem.\n\nThe offending line appears to be:\n\n---\n- name:
> > > Ensuring config directories exist\n  ^ here\n"}
> > >
> > >
> > > it seems, this configuration is discarding main.yml from
> > >
> https://github.com/openstack/kolla-ansible/blob/stable/yoga/ansible/roles/glance/defaults/main.yml#L10
> > > not just replacing the needed variables.
> > >
> > > Regards.
> > >
> > > Le jeu. 13 avr. 2023 ? 13:00, Sean Mooney <smooney at redhat.com> a
> ?crit :
> > >
> > > > On Thu, 2023-04-13 at 11:41 +0100, wodel youchi wrote:
> > > > > Thanks for the help,
> > > > >
> > > > > I modified my glance-api.conf like this but no luck, I got the same
> > > > problem
> > > > > : Privsep daemon failed to start
> > > > >
> > > > > > [cinder]
> > > > > > cinder_store_auth_address = https://dashint.example.com:5000/v3
> > > > > > cinder_store_project_name = service
> > > > > > cinder_volume_type = nfstype
> > > > > > rootwrap_config = /etc/glance/rootwrap.conf
> > > > > >
> > > > > > *cinder_store_user_name = glancecinder_store_password =
> > > > glance-password*
> > > > > > cinder_catalog_info = volumev3:cinderv3:internalURL
> > > > > >
> > > > >
> > > > > > *###cinder_store_user_name = cinder###cinder_store_password =
> > > > > > cinder-password  *
> > > > > >
> > > > >
> > > > >
> > > > > I thought once cinder has the capability to read & write into the
> > > > backend,
> > > > > glance will just use it to upload the images!!
> > > > >
> > > > > Another thing, about the credentials, which ones should I use?
> Glance's
> > > > or
> > > > > cinder's I thought it should be cinder's !! but in your example
> @Sean you
> > > > > used {{ glance_keystone_user }} and  {{ glance_keystone_password }}
> > > >
> > > > either would work but normally i woudl consider it bad partice for a
> > > > service to have the username/password for a differnt users account
> > > > so glance should alwasy use its user to talk to other services when
> its
> > > > not using the keystone user token passed in to the api.
> > > >
> > > > >
> > > > > Lastly I searched how to launch a privileged container in kolla
> but I
> > > > > didn't find anything.
> > > >
> > > > i see the issue
> > > >
> > > >
> https://github.com/openstack/kolla-ansible/blob/stable/yoga/ansible/roles/glance/defaults/main.yml#L10
> > > > glace api is only privlaged if you use iscsi for the cinder backend.
> > > > privileged: "{{ enable_cinder | bool and enable_cinder_backend_iscsi
> |
> > > > bool }}"
> > > > you are using nfs.
> > > >
> > > > you can workaround this in your global.yaml by adding this i think
> > > >
> > > > glance_services:
> > > >   glance-api:
> > > >    privileged: true
> > > >
> > > > alternitivly you can do it via the inventory file by seting that as a
> > > > host/group var.
> > > > >
> > > > > Regards.
> > > >
> > > >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230416/63fa5dd7/attachment-0001.htm>

From knikolla at bu.edu  Mon Apr 17 01:30:49 2023
From: knikolla at bu.edu (Nikolla, Kristi)
Date: Mon, 17 Apr 2023 01:30:49 +0000
Subject: [tc] Technical Committee next weekly meeting on 2023 April 18 at 1800
 UTC
Message-ID: <F98C53D5-A9E4-485B-83C3-09F0EDE60887@bu.edu>

Hi all,

This is a reminder that the next weekly Technical Committee meeting is to be held on Tuesday (April 18) at 1800 UTC on #openstack-tc on OFTC IRC

Items can be proposed by editing the wiki page at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

Unless there are last minute additions (for which I will send a follow-up email) the agenda will be:

    ? Roll call
    ? Follow up on past action items
        ? gmann respond to Sahara PTL volunteer to propose a patch to governance, and explain the outcome of today's discussion
        ? jamespage to write email about Winstackers removal
    ? Gate health check
    ? 2023.2 cycle Leaderless projects
        ? https://etherpad.opendev.org/p/2023.2-leaderless
    ? Broken docs due to inconsistent release naming
    ? Recurring tasks check
        ? Bare 'recheck' state
            ? https://etherpad.opendev.org/p/recheck-weekly-summary
    ? Open Reviews
        ? https://review.opendev.org/q/projects:openstack/governance+is:open


Thank you,
Kristi Nikolla

From gregory.orange at pawsey.org.au  Mon Apr 17 05:56:28 2023
From: gregory.orange at pawsey.org.au (Gregory Orange)
Date: Mon, 17 Apr 2023 13:56:28 +0800
Subject: [neutron] [kolla-ansible] alembic mismatch, schema differences
In-Reply-To: <20230411091638.Horde.18FVI49lop_QXhPAphY0Z47@webmail.nde.ag>
References: <20230411091638.Horde.18FVI49lop_QXhPAphY0Z47@webmail.nde.ag>
Message-ID: <20cb3478-a6ef-8c89-cbd2-2669f0a81e42@pawsey.org.au>

On 11/4/23 17:16, Eugen Block wrote:
> I don't really have more input than what I reported in the mentioned 
> thread. I'm also not familiar with kolla-ansible, unfortunately. But I 
> would check for files with the non-existing revision number on the 
> control node(s)? Something like this depending on your distro could 
> reveal something:
> 
> # find 
> /usr/lib/python3/dist-packages/neutron/db/migration/alembic_migrations/versions/ -name *6135a7bd4425*

Two matches in the same layer of the same Docker volume:
/usr/lib/python3/dist-packages/neutron/db/migration/alembic_migrations/versions/wallaby/expand/__pycache__/6135a7bd4425_add_rbac_support_for_address_group.cpython-38.pyc
/usr/lib/python3/dist-packages/neutron/db/migration/alembic_migrations/versions/wallaby/expand/6135a7bd4425_add_rbac_support_for_address_group.py

I have no time to look further right now though.

> If there are files that don't belong there remove them and retry the 
> neutron-db-manage commands with the correct revisions in the table. But 
> if you're using containers I'd be curious how those files would get 
> there... Does a release change in the globals.yaml also redeploy control 
> containers? But on the other hand, you seem to have deployed only a 
> compute node with wallaby? I hope someone with kolla-ansible experience 
> can chime in here.

It only deployed wallaby containers to the compute node, but a neutron 
container on that node then appears to have run `neutron-db-manage 
upgrade` and changed the database schema.

> Sorry if I can't be more helpful...

No problem, thank you for the attempt. We managed to revert the changes 
- I'll post separately.


From gregory.orange at pawsey.org.au  Mon Apr 17 05:59:41 2023
From: gregory.orange at pawsey.org.au (Gregory Orange)
Date: Mon, 17 Apr 2023 13:59:41 +0800
Subject: [neutron] [kolla-ansible] alembic mismatch, schema differences
In-Reply-To: <d7cae712-bf0c-9144-38cb-ad8fe61f6d54@pawsey.org.au>
References: <d7cae712-bf0c-9144-38cb-ad8fe61f6d54@pawsey.org.au>
Message-ID: <532a6f17-2cda-112e-1744-4c377b8d843c@pawsey.org.au>

Solution: Manually revert the database schema changes.

We found that `neutron-db-manage downgrade` has been unsupported for 
quite some time, so that avenue was closed to us. So, we restored 
backups of before and after to some temporary mariadb servers, to look 
at and compare the data. In the end this is how we reverted it (mysql < 
revert_wallaby_schema.sql):

use neutron

alter table address_scopes alter column shared drop default;
alter table meteringlabelrules drop column source_ip_prefix;
alter table meteringlabelrules drop column destination_ip_prefix;
alter table ml2_vlan_allocations drop constraint 
check_ml2_vlan_allocations0vlan_id;
alter table networkdhcpagentbindings drop index 
uniq_network_dhcp_agent_binding0network_id0binding_index0;
alter table networkdhcpagentbindings drop column binding_index;
alter table networks modify mtu int(11) null default null;
alter table portforwardings drop constraint portforwardings_ibfk_3;
alter table portforwardings drop index 
uniq_portforwardings0standard_attr_id;
alter table portforwardings drop column standard_attr_id;
alter table portuplinkstatuspropagation alter column 
propagate_uplink_status set default 0;
alter table quotas drop index uniq_quotas0project_id0resource;
alter table securitygroups drop constraint CONSTRAINT_1;
alter table securitygroups drop column stateful;
alter table securitygrouprules drop constraint securitygrouprules_ibfk_4;
alter table securitygrouprules drop column remote_address_group_id;
alter table subnetpools alter column shared drop default;
alter table subnets drop constraint CONSTRAINT_1;
alter table subnets drop column in_use;

update alembic_version set version_num='c613d0b82681' where 
version_num='6135a7bd4425';

drop table address_associations;
drop table addressgrouprbacs;
drop table address_groups;
drop table addressscoperbacs;
drop table dvr_fip_gateway_port_network;
drop table network_subnet_lock;
drop table ovn_hash_ring;
drop table ovn_revision_numbers;
drop table portdeviceprofiles;
drop table portnumaaffinitypolicies;
drop table subnet_dns_publish_fixed_ips;
drop table subnetpoolrbacs;


And everything is fine again.

Greg.


From wodel.youchi at gmail.com  Mon Apr 17 08:22:35 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Mon, 17 Apr 2023 09:22:35 +0100
Subject: [kolla-ansible][yoga] Does glance support cinder-nfs as backend?
Message-ID: <CAJV_UBDXyggV--mpzePiNvjSFEtYNUwSsJm0zsTfRoGGQfwxrw@mail.gmail.com>

Hi,

The openstak documentation says that glance supports cinder as backend, but
it does not exclude any backend used by cinder itself.

I'm having trouble configuring glance to use a cinder backend which is
backed by an nfs share.

Is this configuration supported?

First, the rootwrap was missing, after adding it, I faced the lack of
privileges, which was corrected by starting the glance-api container in
privileged mode and finally I am facing a non existing filter error.

Glance is trying to mount the nfs share to use it!!! Which I don't
understand , why mount a share that is already mounted by cinder which
glance is supposed to use as an intermediary!!!?

When I push an image I get this error:

Stderr: '/var/lib/kolla/venv/bin/glance-rootwrap: Unauthorized command:
mount -t nfs 20.1.0.32:/kolla_nfs
/var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624
f97bf3623b13014f22186b7 (no filter matched)\n'


Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230417/6f1ae60a/attachment.htm>

From doug at stackhpc.com  Mon Apr 17 10:03:09 2023
From: doug at stackhpc.com (Doug Szumski)
Date: Mon, 17 Apr 2023 11:03:09 +0100
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <A6BEA46C-87FA-42C5-8384-8D86ED790B5C@gmail.com>
References: <5906e729a3a7adf9dea1fcd47aade4e9a0688e7d.camel@redhat.com>
 <A6BEA46C-87FA-42C5-8384-8D86ED790B5C@gmail.com>
Message-ID: <4ffc9821-4edc-de97-a0ed-d87355bc4241@stackhpc.com>

On 13/04/2023 23:04, Satish Patel wrote:
> Thank Sean/Matt,
>
> This is interesting that I have only option to use classic mirror with durable :( because without mirror cluster acting up when one of node is down.

If you have planned maintenance and non-mirrored transient queues, you 
can first try draining the node to be removed, before removing it from 
the cluster. In my testing at least, this appears to be much more 
successful than relying on the RabbitMQ clients to do the failover and 
recreate queues.? See [1], or for RMQ <3.8 you can cobble something 
together with ha-mode nodes [2].

[1] https://www.rabbitmq.com/upgrade.html#maintenance-mode

[2] https://www.rabbitmq.com/ha.html#mirroring-arguments

This obviously doesn't solve the case of when a controller fails 
unexpectedly.

I also think it's worth making the distinction between a highly 
available messaging infrastructure, and queue mirroring. In many cases, 
if a RMQ node hosting a non-mirrored, transient queue goes down, it 
should be possible for a service to just recreate the queue on another 
node and retry. This often seems to fail, which leads to queue mirroring 
getting turned on.

>
> How people are scaling rabbitMQ for large scale?
>
> Sent from my iPhone
>
>> On Apr 13, 2023, at 7:50 AM, Sean Mooney <smooney at redhat.com> wrote:
>>
>> ?On Thu, 2023-04-13 at 09:07 +0100, Matt Crees wrote:
>>> Hi all, I'll reply in turn here:
>>>
>>> Radek, I agree it definitely will be a good addition to the KA docs.
>>> I've got it on my radar, will aim to get a patch proposed this week.
>>>
>>> Satish, I haven't personally been able to test durable queues on a
>>> system that large. According to the RabbitMQ docs
>>> (https://www.rabbitmq.com/queues.html#durability), "Throughput and
>>> latency of a queue is not affected by whether a queue is durable or
>>> not in most cases." However, I have anecdotally heard that it can
>>> affect some performance in particularly large systems.
>> the perfomacne of durable queue is dominated by the disk io
>> put rabbit on a pcie nvme ssd and it will have littel effect
>> use spinnign rust (a HDD even in raid 10) and the iops/throput of the
>> storage sued to make the qure durible (that just mean write all messages to disk)
>> will be the bottlenck for scaleablity
>> combine that with HA and that is worse as it has to be writen to multipel servers.
>> i belive that teh mirror implemantion will wait for all copies to be persisted
>> but i have not really looked into it. it was raised as a pain point with rabbit by
>> operator in the past in terms fo scaling.
>>
>>> Please note that if you are using the classic mirrored queues, you
>>> must also have them durable. Transient (i.e. non-durable) mirrored
>>> queues are not a supported feature and do cause bugs. (For example the
>>> "old incarnation" errors seen here:
>>> https://bugs.launchpad.net/kolla-ansible/+bug/1954925)
>>>
>>> Nguyen, I can confirm that we've seen the same behaviour. This is
>>> caused by a backported change in oslo.messaging (I believe you linked
>>> the relevant bug report previously). There is a fix in progress to fix
>>> this (https://review.opendev.org/c/openstack/oslo.messaging/+/866617),
>>> and in the meantime setting kombu_reconnect_delay < 1.0 does resolve
>>> it.
>>>
>>> Cheers,
>>> Matt
>>>
>>>> On Thu, 13 Apr 2023 at 03:04, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com> wrote:
>>>>
>>>> update:
>>>> I use SAN as Cinder backend.
>>>> Nguyen Huu Khoi
>>>>
>>>>
>>>> On Thu, Apr 13, 2023 at 9:02?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com> wrote:
>>>>> Hello guys.
>>>>>
>>>>> I do many tests on xena and yoga. then i am sure that without ha-queue and kombu_reconnect_delay=0.5(it can < 1)
>>>>> you cannot launch instances when 1 of 3 controllers is down.
>>>>> Somebody can verify what I say, I hope we will have a common solution for this problem because those who use openstack for the first time will continue to ask questions like that.
>>>>>
>>>>> Nguyen Huu Khoi
>>>>>
>>>>>
>>>>> On Thu, Apr 13, 2023 at 12:59?AM Satish Patel <satish.txt at gmail.com> wrote:
>>>>>> This is great! Matt,
>>>>>>
>>>>>> Documentation would be greatly appreciated. I have a counter question: does Durable queue be good for large clouds with 1000 compute nodes or better to not use durable queue. This is a private cloud and we don't care about persistent data.
>>>>>>
>>>>>> On Wed, Apr 12, 2023 at 12:37?PM Rados?aw Piliszek <radoslaw.piliszek at gmail.com> wrote:
>>>>>>> Hi Matt,
>>>>>>>
>>>>>>>> As you're now reconfiguring a running deployment, there are
>>>>>>>> some extra steps that need to be taken to migrate to durable queues.
>>>>>>>>
>>>>>>>> 1. You will need to stop the OpenStack services which use RabbitMQ.
>>>>>>>>
>>>>>>>> 2. Reset the state of RabbitMQ one each rabbit node with the following
>>>>>>>> commands. You must run each command on all RabbitMQ nodes before
>>>>>>>> moving on to the next command. This will remove all queues.
>>>>>>>>
>>>>>>>>     rabbitmqctl stop_app
>>>>>>>>     rabbitmqctl force_reset
>>>>>>>>     rabbitmqctl start_app
>>>>>>>>
>>>>>>>> 3. Start the OpenStack services again, at which point they will
>>>>>>>> recreate the appropriate queues as durable.
>>>>>>> This sounds like a great new addition-to-be to the Kolla Ansible docs!
>>>>>>> Could you please propose it as a change?
>>>>>>>
>>>>>>> Kindest,
>>>>>>> Radek
>>>>>>>


From thierry at openstack.org  Mon Apr 17 11:14:19 2023
From: thierry at openstack.org (Thierry Carrez)
Date: Mon, 17 Apr 2023 13:14:19 +0200
Subject: [largescale-sig] Next meeting: April 19, 15utc
Message-ID: <25b05623-92e2-f01e-70c3-5aac26a4f256@openstack.org>

Hi everyone,

The Large Scale SIG will be meeting this Wednesday in 
#openstack-operators on OFTC IRC, at 15UTC, our EU+US-friendly time.

You can doublecheck how that UTC time translates locally at:
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230322T14

Feel free to add topics to the agenda:
https://etherpad.opendev.org/p/large-scale-sig-meeting

Regards,

-- 
Thierry Carrez


From thierry at openstack.org  Mon Apr 17 11:15:26 2023
From: thierry at openstack.org (Thierry Carrez)
Date: Mon, 17 Apr 2023 13:15:26 +0200
Subject: [largescale-sig] Next meeting: April 19, 15utc
In-Reply-To: <25b05623-92e2-f01e-70c3-5aac26a4f256@openstack.org>
References: <25b05623-92e2-f01e-70c3-5aac26a4f256@openstack.org>
Message-ID: <90db3bfb-b6b4-c0ef-6b9f-8593c7dcc324@openstack.org>

Thierry Carrez wrote:
> You can doublecheck how that UTC time translates locally at:
> https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230322T14

Wrong URL, try out this one instead:
https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230419T15

Sorry about that.

-- 
Thierry]



From michal.arbet at ultimum.io  Mon Apr 17 12:43:34 2023
From: michal.arbet at ultimum.io (Michal Arbet)
Date: Mon, 17 Apr 2023 14:43:34 +0200
Subject: [neutron] [kolla-ansible] alembic mismatch, schema differences
In-Reply-To: <532a6f17-2cda-112e-1744-4c377b8d843c@pawsey.org.au>
References: <d7cae712-bf0c-9144-38cb-ad8fe61f6d54@pawsey.org.au>
 <532a6f17-2cda-112e-1744-4c377b8d843c@pawsey.org.au>
Message-ID: <CAKz7_JTm=j7ykFLpB_vfSvnB5K6RfOsgzWjP9ysz_Bf+4nGEWQ@mail.gmail.com>

Hi,

I don't think pyc is problem, is it same file but byte compiled.


   1. .py: This is normally the input source code that you've written.
   2. .pyc: This is the compiled bytecode. If you import a module, python
   will build a *.pyc file that contains the bytecode to make importing it
   again later easier (and faster).


Two matches in the same layer of the same Docker volume:
/usr/lib/python3/dist-packages/neutron/db/migration/alembic_migrations/versions/wallaby/expand/__pycache__/6135a7bd4425_add_rbac_support_for_address_group.cpython-38.pyc
/usr/lib/python3/dist-packages/neutron/db/migration/alembic_migrations/versions/wallaby/expand/6135a7bd4425_add_rbac_support_for_address_group.py

Michal Arbet
Openstack Engineer

Ultimum Technologies a.s.
Na Po???? 1047/26, 11000 Praha 1
Czech Republic

+420 604 228 897
michal.arbet at ultimum.io
*https://ultimum.io <https://ultimum.io/>*

LinkedIn <https://www.linkedin.com/company/ultimum-technologies> | Twitter
<https://twitter.com/ultimumtech> | Facebook
<https://www.facebook.com/ultimumtechnologies/timeline>


po 17. 4. 2023 v 8:04 odes?latel Gregory Orange <
gregory.orange at pawsey.org.au> napsal:

> Solution: Manually revert the database schema changes.
>
> We found that `neutron-db-manage downgrade` has been unsupported for
> quite some time, so that avenue was closed to us. So, we restored
> backups of before and after to some temporary mariadb servers, to look
> at and compare the data. In the end this is how we reverted it (mysql <
> revert_wallaby_schema.sql):
>
> use neutron
>
> alter table address_scopes alter column shared drop default;
> alter table meteringlabelrules drop column source_ip_prefix;
> alter table meteringlabelrules drop column destination_ip_prefix;
> alter table ml2_vlan_allocations drop constraint
> check_ml2_vlan_allocations0vlan_id;
> alter table networkdhcpagentbindings drop index
> uniq_network_dhcp_agent_binding0network_id0binding_index0;
> alter table networkdhcpagentbindings drop column binding_index;
> alter table networks modify mtu int(11) null default null;
> alter table portforwardings drop constraint portforwardings_ibfk_3;
> alter table portforwardings drop index
> uniq_portforwardings0standard_attr_id;
> alter table portforwardings drop column standard_attr_id;
> alter table portuplinkstatuspropagation alter column
> propagate_uplink_status set default 0;
> alter table quotas drop index uniq_quotas0project_id0resource;
> alter table securitygroups drop constraint CONSTRAINT_1;
> alter table securitygroups drop column stateful;
> alter table securitygrouprules drop constraint securitygrouprules_ibfk_4;
> alter table securitygrouprules drop column remote_address_group_id;
> alter table subnetpools alter column shared drop default;
> alter table subnets drop constraint CONSTRAINT_1;
> alter table subnets drop column in_use;
>
> update alembic_version set version_num='c613d0b82681' where
> version_num='6135a7bd4425';
>
> drop table address_associations;
> drop table addressgrouprbacs;
> drop table address_groups;
> drop table addressscoperbacs;
> drop table dvr_fip_gateway_port_network;
> drop table network_subnet_lock;
> drop table ovn_hash_ring;
> drop table ovn_revision_numbers;
> drop table portdeviceprofiles;
> drop table portnumaaffinitypolicies;
> drop table subnet_dns_publish_fixed_ips;
> drop table subnetpoolrbacs;
>
>
> And everything is fine again.
>
> Greg.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230417/200c7fd7/attachment.htm>

From mobilebackup95 at gmail.com  Mon Apr 17 14:08:25 2023
From: mobilebackup95 at gmail.com (Modyngs)
Date: Mon, 17 Apr 2023 17:38:25 +0330
Subject: [kolla] Reducing ceilometer, gnocchi, aodh time interval
Message-ID: <CAOV3zY8BVTsPrZm2cXMT9ssQg9_qsAyRgGhcrZuBpLpyZy+SaA@mail.gmail.com>

Dear lists, Hi
I have recently noticed of this link to customize configurations to be
overridden [Thanks to michal nasiadka]:
https://docs.openstack.org/kolla-ansible/latest/admin/advanced-configuration.html#openstack-service-configuration-in-kolla

but i have some doubts in regards!
The docs says /etc/kolla/ config/<< service name >>/<< config file >>
(Ex.  /etc/kolla/config/nova/nova-scheduler.conf)



let's say i want to change interval to 30sec (* 'interval: 30'*) in
*'/etc/kolla/ceilometer-central/polling.yaml'* file:
as i understood, i need to create a file in
*'/etc/kolla/config/ceilometer-central/polling.yaml'* and copy all the
contents of * '/etc/kolla/ceilometer-central/polling.yaml'* into it ( *or
just the change?*)  and then change just the  *interval from 300 to 30 .*

Am I doing Right? ( because there was no [DEFAULT] section available in the
polling.yaml file ....)


After doing the same for all the desired files, then i need to do prechecks
and deploy?

kolla-ansible -i /etc/kolla/all-in-one prechecks

kolla-ansible -i /etc/kolla/all-in-one deploy


Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230417/d77febb6/attachment.htm>

From wodel.youchi at gmail.com  Mon Apr 17 14:42:02 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Mon, 17 Apr 2023 15:42:02 +0100
Subject: [kolla-ansible][yoga] Does glance support cinder-nfs as backend?
In-Reply-To: <CAJV_UBDXyggV--mpzePiNvjSFEtYNUwSsJm0zsTfRoGGQfwxrw@mail.gmail.com>
References: <CAJV_UBDXyggV--mpzePiNvjSFEtYNUwSsJm0zsTfRoGGQfwxrw@mail.gmail.com>
Message-ID: <CAJV_UBA=LjYYgG=P-OKo_mQFvbD4zDDEZx3KD5Oeymive=WWjA@mail.gmail.com>

Any ideas?

Le lun. 17 avr. 2023 ? 09:22, wodel youchi <wodel.youchi at gmail.com> a
?crit :

> Hi,
>
> The openstak documentation says that glance supports cinder as backend,
> but it does not exclude any backend used by cinder itself.
>
> I'm having trouble configuring glance to use a cinder backend which is
> backed by an nfs share.
>
> Is this configuration supported?
>
> First, the rootwrap was missing, after adding it, I faced the lack of
> privileges, which was corrected by starting the glance-api container in
> privileged mode and finally I am facing a non existing filter error.
>
> Glance is trying to mount the nfs share to use it!!! Which I don't
> understand , why mount a share that is already mounted by cinder which
> glance is supposed to use as an intermediary!!!?
>
> When I push an image I get this error:
>
> Stderr: '/var/lib/kolla/venv/bin/glance-rootwrap: Unauthorized command:
> mount -t nfs 20.1.0.32:/kolla_nfs
> /var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624
> f97bf3623b13014f22186b7 (no filter matched)\n'
>
>
> Regards.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230417/936bbf25/attachment-0001.htm>

From mnasiadka at gmail.com  Mon Apr 17 15:13:55 2023
From: mnasiadka at gmail.com (=?utf-8?Q?Micha=C5=82_Nasiadka?=)
Date: Mon, 17 Apr 2023 17:13:55 +0200
Subject: [kolla] [openeuler] CI jobs status
Message-ID: <71E23583-527B-4502-A624-A118E7CCA3E3@gmail.com>

Hello Koalas,

OpenEuler jobs in master (to be Antelope) are failing for a long time.
If no one is interested in maintaining OpenEuler support in Kolla-Ansible - I will propose dropping it?s support on Wednesday Kolla meeting.

Best regards,
Michal

From pierre at stackhpc.com  Tue Apr 11 09:45:19 2023
From: pierre at stackhpc.com (Pierre Riteau)
Date: Tue, 11 Apr 2023 11:45:19 +0200
Subject: [Kolla-ansible][Yoga] Cannot live migrate VMs
In-Reply-To: <CAJV_UBDGYOJG8iuEbD3eELbvDHVyCmOv--w=oJ8h=iYF4vehXg@mail.gmail.com>
References: <CAJV_UBDGYOJG8iuEbD3eELbvDHVyCmOv--w=oJ8h=iYF4vehXg@mail.gmail.com>
Message-ID: <CA+ny2syZyMnhX3WVW9UxGzaxSPDf_S=pShRA9JA6hoELzhkHxw@mail.gmail.com>

You should check the status of your Cinder services.

On Sun, 9 Apr 2023 at 19:43, wodel youchi <wodel.youchi at gmail.com> wrote:

> Hi,
>
> I cannot live-migrate any VM I have.
> All my compute nodes are enabled. I have a few VMs, I am in the testing
> phase.
> I tried to live-migrate toward an empty node, then toward a node which
> already had a VM in it. It is the same problem.
>
> In the log files I have :
>
> Source node :
> Source
>
>> ==> /var/log/kolla/nova/nova-compute.log <==
>> 2023-04-09 11:32:49.419 7 INFO nova.compute.resource_tracker
>> [req-4e91d562-d7ad-4585-a827-3db6277fd81e - - - - -] [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Updating resource usage from
>> migration f60eb077-8e1c-404a-aca5-64e5609ca02c
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [-] [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Pre live migration failed at
>> computehci02: oslo_messaging.rpc.client.RemoteError: Remote error:
>> ClientException Gateway Time-out (HTTP 504)
>> ['Traceback (most recent call last):\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py",
>> line 165, in _process_incoming\n    res =
>> self.dispatcher.dispatch(message)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>> line 309, in dispatch\n    return self._do_dispatch(endpoint, method, ctxt,
>> args)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>> line 229, in _do_dispatch\n    result = func(ctxt, **new_args)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>> line 72, in wrapped\n    context, exc, binary)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise\n    raise self.value\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>> line 63, in wrapped\n    return f(self, context, *args, **kw)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py",
>> line 1439, in decorated_function\n    return function(self, context, *args,
>> **kwargs)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 213, in decorated_function\n    kwargs[\'instance\'], e,
>> sys.exc_info())\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise\n    raise self.value\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 201, in decorated_function\n    return function(self, context, *args,
>> **kwargs)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 8367, in pre_live_migration\n    bdm.save()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise\n    raise self.value\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 8304, in pre_live_migration\n    connector=connector,
>> mountpoint=bdm.device_name)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 395, in wrapper\n    res = method(self, ctx, *args, **kwargs)\n', '
>>  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 433, in wrapper\n    res = method(self, ctx, volume_id, *args,
>> **kwargs)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 813, in attachment_create\n    instance_uuid=instance_id)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise\n    raise self.value\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 801, in attachment_create\n    volume_id, _connector, instance_id)\n',
>> '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py",
>> line 421, in substitution\n    return method.func(obj, *args, **kwargs)\n',
>> '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py",
>> line 39, in create\n    retval = self._create(\'/attachments\', body,
>> \'attachment\')\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py",
>> line 306, in _create\n    resp, body = self.api.client.post(url,
>> body=body)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> line 227, in post\n    return self._cs_request(url, \'POST\', **kwargs)\n',
>> '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> line 215, in _cs_request\n    return self.request(url, method,
>> **kwargs)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> line 201, in request\n    raise exceptions.from_response(resp, body)\n',
>> 'cinderclient.exceptions.ClientException: Gateway Time-out (HTTP 504)\n'].
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Traceback (most recent call last):
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 8501, in _do_pre_live_migration_from_source
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     block_migration, disk, dest,
>> migrate_data)
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/rpcapi.py",
>> line 948, in pre_live_migration
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     **msg_args)
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/client.py",
>> line 192, in call
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     retry=self.retry,
>> transport_options=self.transport_options)
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/transport.py",
>> line 128, in _send
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
>> transport_options=transport_options)
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>> line 691, in send
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
>> transport_options=transport_options)
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>> line 681, in _send
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     raise result
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
>> oslo_messaging.rpc.client.RemoteError: Remote error: ClientException
>> Gateway Time-out (HTTP 504)
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] ['Traceback (most recent call
>> last):\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py",
>> line 165, in _process_incoming\n    res =
>> self.dispatcher.dispatch(message)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>> line 309, in dispatch\n    return self._do_dispatch(endpoint, method, ctxt,
>> args)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>> line 229, in _do_dispatch\n    result = func(ctxt, **new_args)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>> line 72, in wrapped\n    context, exc, binary)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise\n    raise self.value\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>> line 63, in wrapped\n    return f(self, context, *args, **kw)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py",
>> line 1439, in decorated_function\n    return function(self, context, *args,
>> **kwargs)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 213, in decorated_function\n    kwargs[\'instance\'], e,
>> sys.exc_info())\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise\n    raise self.value\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 201, in decorated_function\n    return function(self, context, *args,
>> **kwargs)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 8367, in pre_live_migration\n    bdm.save()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise\n    raise self.value\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 8304, in pre_live_migration\n    connector=connector,
>> mountpoint=bdm.device_name)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 395, in wrapper\n    res = method(self, ctx, *args, **kwargs)\n', '
>>  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 433, in wrapper\n    res = method(self, ctx, volume_id, *args,
>> **kwargs)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 813, in attachment_create\n    instance_uuid=instance_id)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise\n    raise self.value\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 801, in attachment_create\n    volume_id, _connector, instance_id)\n',
>> '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py",
>> line 421, in substitution\n    return method.func(obj, *args, **kwargs)\n',
>> '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py",
>> line 39, in create\n    retval = self._create(\'/attachments\', body,
>> \'attachment\')\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py",
>> line 306, in _create\n    resp, body = self.api.client.post(url,
>> body=body)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> line 227, in post\n    return self._cs_request(url, \'POST\', **kwargs)\n',
>> '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> line 215, in _cs_request\n    return self.request(url, method,
>> **kwargs)\n', '  File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> line 201, in request\n    raise exceptions.from_response(resp, body)\n',
>> 'cinderclient.exceptions.ClientException: Gateway Time-out (HTTP 504)\n'].
>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
>> 2023-04-09 11:33:30.157 7 INFO nova.compute.manager [-] [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Swapping old allocation on
>> dict_keys(['2857ae62-3519-4b13-b700-858c827dd78d']) held by migration
>> f60eb077-8e1c-404a-aca5-64e5609ca02c for instance
>
>
>
> In the destination node :
>
>> nova-compute.log
>>
>>
>>
>>
>> *2023-04-09 11:32:30.052 7 WARNING os_brick.initiator.connectors.nvmeof
>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default default] Process execution error
>> in _get_host_uuid: Unexpected error while running command.Command: blkid
>> overlay -s UUID -o valueExit code: 2Stdout: ''Stderr: '':
>> oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while
>> running command.*
>>
>> 2023-04-09 11:33:05.354 7 INFO nova.compute.resource_tracker
>> [req-9d480442-87f7-4d4e-a866-c46d645ac7f2 - - - - -] [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Updating resource usage from
>> migration f60eb077-8e1c-404a-aca5-64e5609ca02c
>> 2023-04-09 11:33:05.392 7 WARNING nova.compute.resource_tracker
>> [req-9d480442-87f7-4d4e-a866-c46d645ac7f2 - - - - -] Instance
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7 has been moved to another host
>> computehci01(computehci01). There are allocations remaining against the
>> source host that might need to be removed: {'resources': {'VCPU': 1,
>> 'MEMORY_MB': 2048}}.
>> 2023-04-09 11:33:30.086 7 ERROR nova.volume.cinder
>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Create attachment failed for volume
>> 3d7bd0af-5e4c-48fc-a027-f6c9dd6280bb. Error: Gateway Time-out (HTTP 504)
>> Code: 504: cinderclient.exceptions.ClientException: Gateway Time-out (HTTP
>> 504)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default default] Exception during
>> message handling: cinderclient.exceptions.ClientException: Gateway Time-out
>> (HTTP 504)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server Traceback (most
>> recent call last):
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py",
>> line 165, in _process_incoming
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     res =
>> self.dispatcher.dispatch(message)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>> line 309, in dispatch
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> self._do_dispatch(endpoint, method, ctxt, args)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>> line 229, in _do_dispatch
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     result =
>> func(ctxt, **new_args)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>> line 72, in wrapped
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     context,
>> exc, binary)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> self.force_reraise()
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>> self.value
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>> line 63, in wrapped
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> f(self, context, *args, **kw)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py",
>> line 1439, in decorated_function
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> function(self, context, *args, **kwargs)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 213, in decorated_function
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> kwargs['instance'], e, sys.exc_info())
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> self.force_reraise()
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>> self.value
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 201, in decorated_function
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> function(self, context, *args, **kwargs)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 8367, in pre_live_migration
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     bdm.save()
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> self.force_reraise()
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>> self.value
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> line 8304, in pre_live_migration
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> connector=connector, mountpoint=bdm.device_name)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 395, in wrapper
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     res =
>> method(self, ctx, *args, **kwargs)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 433, in wrapper
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     res =
>> method(self, ctx, volume_id, *args, **kwargs)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 813, in attachment_create
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> instance_uuid=instance_id)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 227, in __exit__
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> self.force_reraise()
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> line 200, in force_reraise
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>> self.value
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> line 801, in attachment_create
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     volume_id,
>> _connector, instance_id)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py",
>> line 421, in substitution
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> method.func(obj, *args, **kwargs)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py",
>> line 39, in create
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     retval =
>> self._create('/attachments', body, 'attachment')
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py",
>> line 306, in _create
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     resp, body
>> = self.api.client.post(url, body=body)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> line 227, in post
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> self._cs_request(url, 'POST', **kwargs)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> line 215, in _cs_request
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> self.request(url, method, **kwargs)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> line 201, in request
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>> exceptions.from_response(resp, body)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> cinderclient.exceptions.ClientException: Gateway Time-out (HTTP 504)
>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> 2023-04-09 11:33:30.238 7 INFO nova.virt.block_device
>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Attempting to driver detach volume
>> 3d7bd0af-5e4c-48fc-a027-f6c9dd6280bb from mountpoint /dev/vda
>> 2023-04-09 11:33:30.239 7 WARNING nova.virt.block_device
>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Detaching volume from unknown instance
>> 2023-04-09 11:33:30.240 7 WARNING nova.virt.libvirt.driver
>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] During detach_volume, instance
>> disappeared.: nova.exception.InstanceNotFound: Instance
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7 could not be found.
>> 2023-04-09 11:33:30.678 7 INFO nova.virt.libvirt.driver [-] [instance:
>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Instance destroyed successfully.
>> 2023-04-09 11:33:30.682 7 INFO os_vif
>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>> b0f76b5c6dcb457fa716762bbf954837 - default default] Successfully unplugged
>> vif
>> VIFBridge(active=True,address=fa:16:3e:9b:92:46,bridge_name='qbr46651303-65',has_traffic_filtering=True,id=46651303-65e1-4809-95cc-7c2d97acf16b,network=Network(532470c1-dd2f-4505-8557-ba24e9d4062b),plugin='ovs',port_profile=VIFPortProfileOpenVSwitch,preserve_on_delete=False,vif_name='tap46651303-65')
>>
>
> All I can see is
>
>
>
>
> *b0f76b5c6dcb457fa716762bbf954837 - default default] Process execution
> error in _get_host_uuid: Unexpected error while running command.Command:
> blkid overlay -s UUID -o valueExit code: 2Stdout: ''Stderr: '':
> oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while
> running command.*
>
> Searching the web I didn't find anything useful about this error, and I
> don't know if it's the origin of the problem.
>
> My default storage is ceph rbd, I have an HCI deployment, and all my VMs
> are for now created on Ceph only. But I have configured two other cinder
> backends, NFS and LVM, but they are node used for now.
>
> Thanks in advance.
>
> Regards.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/8dd018f0/attachment-0001.htm>

From wodel.youchi at gmail.com  Tue Apr 11 11:57:47 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Tue, 11 Apr 2023 12:57:47 +0100
Subject: [Kolla-ansible][Yoga] Cannot live migrate VMs
In-Reply-To: <CA+ny2syZyMnhX3WVW9UxGzaxSPDf_S=pShRA9JA6hoELzhkHxw@mail.gmail.com>
References: <CAJV_UBDGYOJG8iuEbD3eELbvDHVyCmOv--w=oJ8h=iYF4vehXg@mail.gmail.com>
 <CA+ny2syZyMnhX3WVW9UxGzaxSPDf_S=pShRA9JA6hoELzhkHxw@mail.gmail.com>
Message-ID: <CAJV_UBDH4tJ11pkOagYpWNVCrZHruTmA6A-k9P=DLrqchPvNPg@mail.gmail.com>

Hi,

Indeed, there was a mistake in the cinder.conf file.
Thanks.

Regards.

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Le mar. 11 avr. 2023 ? 10:45, Pierre Riteau <pierre at stackhpc.com> a ?crit :

> You should check the status of your Cinder services.
>
> On Sun, 9 Apr 2023 at 19:43, wodel youchi <wodel.youchi at gmail.com> wrote:
>
>> Hi,
>>
>> I cannot live-migrate any VM I have.
>> All my compute nodes are enabled. I have a few VMs, I am in the testing
>> phase.
>> I tried to live-migrate toward an empty node, then toward a node which
>> already had a VM in it. It is the same problem.
>>
>> In the log files I have :
>>
>> Source node :
>> Source
>>
>>> ==> /var/log/kolla/nova/nova-compute.log <==
>>> 2023-04-09 11:32:49.419 7 INFO nova.compute.resource_tracker
>>> [req-4e91d562-d7ad-4585-a827-3db6277fd81e - - - - -] [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Updating resource usage from
>>> migration f60eb077-8e1c-404a-aca5-64e5609ca02c
>>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [-] [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Pre live migration failed at
>>> computehci02: oslo_messaging.rpc.client.RemoteError: Remote error:
>>> ClientException Gateway Time-out (HTTP 504)
>>> ['Traceback (most recent call last):\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py",
>>> line 165, in _process_incoming\n    res =
>>> self.dispatcher.dispatch(message)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>>> line 309, in dispatch\n    return self._do_dispatch(endpoint, method, ctxt,
>>> args)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>>> line 229, in _do_dispatch\n    result = func(ctxt, **new_args)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>>> line 72, in wrapped\n    context, exc, binary)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 200, in force_reraise\n    raise self.value\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>>> line 63, in wrapped\n    return f(self, context, *args, **kw)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py",
>>> line 1439, in decorated_function\n    return function(self, context, *args,
>>> **kwargs)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>>> line 213, in decorated_function\n    kwargs[\'instance\'], e,
>>> sys.exc_info())\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 200, in force_reraise\n    raise self.value\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>>> line 201, in decorated_function\n    return function(self, context, *args,
>>> **kwargs)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>>> line 8367, in pre_live_migration\n    bdm.save()\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 200, in force_reraise\n    raise self.value\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>>> line 8304, in pre_live_migration\n    connector=connector,
>>> mountpoint=bdm.device_name)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>>> line 395, in wrapper\n    res = method(self, ctx, *args, **kwargs)\n', '
>>>  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>>> line 433, in wrapper\n    res = method(self, ctx, volume_id, *args,
>>> **kwargs)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>>> line 813, in attachment_create\n    instance_uuid=instance_id)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 200, in force_reraise\n    raise self.value\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>>> line 801, in attachment_create\n    volume_id, _connector, instance_id)\n',
>>> '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py",
>>> line 421, in substitution\n    return method.func(obj, *args, **kwargs)\n',
>>> '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py",
>>> line 39, in create\n    retval = self._create(\'/attachments\', body,
>>> \'attachment\')\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py",
>>> line 306, in _create\n    resp, body = self.api.client.post(url,
>>> body=body)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>>> line 227, in post\n    return self._cs_request(url, \'POST\', **kwargs)\n',
>>> '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>>> line 215, in _cs_request\n    return self.request(url, method,
>>> **kwargs)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>>> line 201, in request\n    raise exceptions.from_response(resp, body)\n',
>>> 'cinderclient.exceptions.ClientException: Gateway Time-out (HTTP 504)\n'].
>>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Traceback (most recent call last):
>>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>>> line 8501, in _do_pre_live_migration_from_source
>>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     block_migration, disk, dest,
>>> migrate_data)
>>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/rpcapi.py",
>>> line 948, in pre_live_migration
>>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     **msg_args)
>>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/client.py",
>>> line 192, in call
>>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     retry=self.retry,
>>> transport_options=self.transport_options)
>>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/transport.py",
>>> line 128, in _send
>>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
>>> transport_options=transport_options)
>>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>>> line 691, in send
>>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
>>> transport_options=transport_options)
>>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>>> line 681, in _send
>>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     raise result
>>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
>>> oslo_messaging.rpc.client.RemoteError: Remote error: ClientException
>>> Gateway Time-out (HTTP 504)
>>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] ['Traceback (most recent call
>>> last):\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py",
>>> line 165, in _process_incoming\n    res =
>>> self.dispatcher.dispatch(message)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>>> line 309, in dispatch\n    return self._do_dispatch(endpoint, method, ctxt,
>>> args)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>>> line 229, in _do_dispatch\n    result = func(ctxt, **new_args)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>>> line 72, in wrapped\n    context, exc, binary)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 200, in force_reraise\n    raise self.value\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>>> line 63, in wrapped\n    return f(self, context, *args, **kw)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py",
>>> line 1439, in decorated_function\n    return function(self, context, *args,
>>> **kwargs)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>>> line 213, in decorated_function\n    kwargs[\'instance\'], e,
>>> sys.exc_info())\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 200, in force_reraise\n    raise self.value\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>>> line 201, in decorated_function\n    return function(self, context, *args,
>>> **kwargs)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>>> line 8367, in pre_live_migration\n    bdm.save()\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 200, in force_reraise\n    raise self.value\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>>> line 8304, in pre_live_migration\n    connector=connector,
>>> mountpoint=bdm.device_name)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>>> line 395, in wrapper\n    res = method(self, ctx, *args, **kwargs)\n', '
>>>  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>>> line 433, in wrapper\n    res = method(self, ctx, volume_id, *args,
>>> **kwargs)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>>> line 813, in attachment_create\n    instance_uuid=instance_id)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 200, in force_reraise\n    raise self.value\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>>> line 801, in attachment_create\n    volume_id, _connector, instance_id)\n',
>>> '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py",
>>> line 421, in substitution\n    return method.func(obj, *args, **kwargs)\n',
>>> '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py",
>>> line 39, in create\n    retval = self._create(\'/attachments\', body,
>>> \'attachment\')\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py",
>>> line 306, in _create\n    resp, body = self.api.client.post(url,
>>> body=body)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>>> line 227, in post\n    return self._cs_request(url, \'POST\', **kwargs)\n',
>>> '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>>> line 215, in _cs_request\n    return self.request(url, method,
>>> **kwargs)\n', '  File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>>> line 201, in request\n    raise exceptions.from_response(resp, body)\n',
>>> 'cinderclient.exceptions.ClientException: Gateway Time-out (HTTP 504)\n'].
>>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
>>> 2023-04-09 11:33:30.157 7 INFO nova.compute.manager [-] [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Swapping old allocation on
>>> dict_keys(['2857ae62-3519-4b13-b700-858c827dd78d']) held by migration
>>> f60eb077-8e1c-404a-aca5-64e5609ca02c for instance
>>
>>
>>
>> In the destination node :
>>
>>> nova-compute.log
>>>
>>>
>>>
>>>
>>> *2023-04-09 11:32:30.052 7 WARNING os_brick.initiator.connectors.nvmeof
>>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>>> b0f76b5c6dcb457fa716762bbf954837 - default default] Process execution error
>>> in _get_host_uuid: Unexpected error while running command.Command: blkid
>>> overlay -s UUID -o valueExit code: 2Stdout: ''Stderr: '':
>>> oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while
>>> running command.*
>>>
>>> 2023-04-09 11:33:05.354 7 INFO nova.compute.resource_tracker
>>> [req-9d480442-87f7-4d4e-a866-c46d645ac7f2 - - - - -] [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Updating resource usage from
>>> migration f60eb077-8e1c-404a-aca5-64e5609ca02c
>>> 2023-04-09 11:33:05.392 7 WARNING nova.compute.resource_tracker
>>> [req-9d480442-87f7-4d4e-a866-c46d645ac7f2 - - - - -] Instance
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7 has been moved to another host
>>> computehci01(computehci01). There are allocations remaining against the
>>> source host that might need to be removed: {'resources': {'VCPU': 1,
>>> 'MEMORY_MB': 2048}}.
>>> 2023-04-09 11:33:30.086 7 ERROR nova.volume.cinder
>>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Create attachment failed for volume
>>> 3d7bd0af-5e4c-48fc-a027-f6c9dd6280bb. Error: Gateway Time-out (HTTP 504)
>>> Code: 504: cinderclient.exceptions.ClientException: Gateway Time-out (HTTP
>>> 504)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>>> b0f76b5c6dcb457fa716762bbf954837 - default default] Exception during
>>> message handling: cinderclient.exceptions.ClientException: Gateway Time-out
>>> (HTTP 504)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server Traceback
>>> (most recent call last):
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py",
>>> line 165, in _process_incoming
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     res =
>>> self.dispatcher.dispatch(message)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>>> line 309, in dispatch
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>>> self._do_dispatch(endpoint, method, ctxt, args)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>>> line 229, in _do_dispatch
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     result =
>>> func(ctxt, **new_args)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>>> line 72, in wrapped
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     context,
>>> exc, binary)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 227, in __exit__
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>>> self.force_reraise()
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 200, in force_reraise
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>>> self.value
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>>> line 63, in wrapped
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>>> f(self, context, *args, **kw)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py",
>>> line 1439, in decorated_function
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>>> function(self, context, *args, **kwargs)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>>> line 213, in decorated_function
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>>> kwargs['instance'], e, sys.exc_info())
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 227, in __exit__
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>>> self.force_reraise()
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 200, in force_reraise
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>>> self.value
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>>> line 201, in decorated_function
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>>> function(self, context, *args, **kwargs)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>>> line 8367, in pre_live_migration
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     bdm.save()
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 227, in __exit__
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>>> self.force_reraise()
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 200, in force_reraise
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>>> self.value
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>>> line 8304, in pre_live_migration
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>>> connector=connector, mountpoint=bdm.device_name)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>>> line 395, in wrapper
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     res =
>>> method(self, ctx, *args, **kwargs)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>>> line 433, in wrapper
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     res =
>>> method(self, ctx, volume_id, *args, **kwargs)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>>> line 813, in attachment_create
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>>> instance_uuid=instance_id)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 227, in __exit__
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>>> self.force_reraise()
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>>> line 200, in force_reraise
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>>> self.value
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>>> line 801, in attachment_create
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     volume_id,
>>> _connector, instance_id)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py",
>>> line 421, in substitution
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>>> method.func(obj, *args, **kwargs)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py",
>>> line 39, in create
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     retval =
>>> self._create('/attachments', body, 'attachment')
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py",
>>> line 306, in _create
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     resp, body
>>> = self.api.client.post(url, body=body)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>>> line 227, in post
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>>> self._cs_request(url, 'POST', **kwargs)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>>> line 215, in _cs_request
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>>> self.request(url, method, **kwargs)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>>> line 201, in request
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>>> exceptions.from_response(resp, body)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>>> cinderclient.exceptions.ClientException: Gateway Time-out (HTTP 504)
>>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>>> 2023-04-09 11:33:30.238 7 INFO nova.virt.block_device
>>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Attempting to driver detach volume
>>> 3d7bd0af-5e4c-48fc-a027-f6c9dd6280bb from mountpoint /dev/vda
>>> 2023-04-09 11:33:30.239 7 WARNING nova.virt.block_device
>>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Detaching volume from unknown instance
>>> 2023-04-09 11:33:30.240 7 WARNING nova.virt.libvirt.driver
>>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] During detach_volume, instance
>>> disappeared.: nova.exception.InstanceNotFound: Instance
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7 could not be found.
>>> 2023-04-09 11:33:30.678 7 INFO nova.virt.libvirt.driver [-] [instance:
>>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Instance destroyed successfully.
>>> 2023-04-09 11:33:30.682 7 INFO os_vif
>>> [req-69822759-d982-4d01-b448-232796077002 0439953e7cfe4a13a1b4bb118b5dc3c4
>>> b0f76b5c6dcb457fa716762bbf954837 - default default] Successfully unplugged
>>> vif
>>> VIFBridge(active=True,address=fa:16:3e:9b:92:46,bridge_name='qbr46651303-65',has_traffic_filtering=True,id=46651303-65e1-4809-95cc-7c2d97acf16b,network=Network(532470c1-dd2f-4505-8557-ba24e9d4062b),plugin='ovs',port_profile=VIFPortProfileOpenVSwitch,preserve_on_delete=False,vif_name='tap46651303-65')
>>>
>>
>> All I can see is
>>
>>
>>
>>
>> *b0f76b5c6dcb457fa716762bbf954837 - default default] Process execution
>> error in _get_host_uuid: Unexpected error while running command.Command:
>> blkid overlay -s UUID -o valueExit code: 2Stdout: ''Stderr: '':
>> oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while
>> running command.*
>>
>> Searching the web I didn't find anything useful about this error, and I
>> don't know if it's the origin of the problem.
>>
>> My default storage is ceph rbd, I have an HCI deployment, and all my VMs
>> are for now created on Ceph only. But I have configured two other cinder
>> backends, NFS and LVM, but they are node used for now.
>>
>> Thanks in advance.
>>
>> Regards.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/e775a16b/attachment-0001.htm>

From wodel.youchi at gmail.com  Mon Apr 17 15:43:07 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Mon, 17 Apr 2023 16:43:07 +0100
Subject: [kolla-ansible][yoga] Glance backend cinder Privsep daemon failed
 to start operation not permitted
In-Reply-To: <CAJV_UBBHK9L=eS0QhYKx9Jm3xAHvWX6F9F8dH9uFTBn-pVKhdA@mail.gmail.com>
References: <CAJV_UBC95fMQh00w7vxbyV55F=wXuLXjgVYG5fYy08en2VYtaA@mail.gmail.com>
 <CADO3vb4++zhHTu3Gfdsb3pYZFMdwGSytDuXhN0QZ-JCdVFqu7A@mail.gmail.com>
 <323313cf9ef907a0bbbdce18e7ae71654385e1f2.camel@redhat.com>
 <CAJV_UBDUQ0x_Y24Q5S8QbvJrLnZ8Moy2q=LsvojjSMRooSrXrg@mail.gmail.com>
 <e0bd7f4fdb6a4e1e949531730f9f19a0304781d6.camel@redhat.com>
 <CAJV_UBCkuvnXem=A8czKSE3zJBp5LtQ9wXQPr-y5LE4X8k3V8A@mail.gmail.com>
 <b2c015f0bda7b9ae16ecbb3dff71e69665db0878.camel@redhat.com>
 <b7e2ae4d7740ca4175a941ce30a0b354b6de99b7.camel@redhat.com>
 <CAJV_UBBHK9L=eS0QhYKx9Jm3xAHvWX6F9F8dH9uFTBn-pVKhdA@mail.gmail.com>
Message-ID: <CAJV_UBB7m-3Cv1soi_mZDuWzK3_DmdHhzwr2sH0yt3+eOgJ6yA@mail.gmail.com>

Hi,

I managed to get another step forward, but I hit another wall.
Glance-api was trying to mount the NFS share on the controller node, not on
the compute, so I installed nfs-utils on it, now I have this error :

2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder
> [req-35f49fc4-15bc-4d3b-b93e-e039c1d0f3fa 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 - default default] Exception while
> accessing to cinder volume 3d4712ef-7cb5-4a0b-bc1e-cfbebd8fa902.:
> FileExistsError: [Errno 17] File exists:
> '/var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624f97bf3623b13014f22186b7'
> 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder Traceback
> (most recent call last):
> 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py",
> line 788, in _open_cinder_volume
> 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder     device =
> connect_volume_nfs()
> 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_concurrency/lockutils.py",
> line 391, in inner
> 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder     return
> f(*args, **kwargs)
> 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py",
> line 786, in connect_volume_nfs
> 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder
> root_helper, options)
> 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/common/fs_mount.py",
> line 359, in mount
> 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder
> rootwrap_helper, options)
> 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/common/fs_mount.py",
> line 247, in mount
> 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder
> os.makedirs(mountpoint)
> 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder   File
> "/usr/lib64/python3.6/os.py", line 220, in makedirs
> 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder
> mkdir(name, mode)
> 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder
> FileExistsError: [Errno 17] File exists:
> '/var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624f97bf3623b13014f22186b7'
> 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder
> 2023-04-17 16:33:08.906 62 ERROR glance_store._drivers.cinder
> [req-35f49fc4-15bc-4d3b-b93e-e039c1d0f3fa 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 - default default] Failed to write to
> volume 3d4712ef-7cb5-4a0b-bc1e-cfbebd8fa902.: FileExistsError: [Errno 17]
> File exists:
> '/var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624f97bf3623b13014f22186b7'
> 2023-04-17 16:33:08.939 62 ERROR glance.api.v2.image_data
> [req-35f49fc4-15bc-4d3b-b93e-e039c1d0f3fa 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 - default default] Failed to upload image
> data due to internal error: FileExistsError: [Errno 17] File exists:
> '/var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624f97bf3623b13014f22186b7'
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> [req-35f49fc4-15bc-4d3b-b93e-e039c1d0f3fa 0439953e7cfe4a13a1b4bb118b5dc3c4
> b0f76b5c6dcb457fa716762bbf954837 - default default] Caught error: [Errno
> 17] File exists:
> '/var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624f97bf3623b13014f22186b7':
> FileExistsError: [Errno 17] File exists:
> '/var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624f97bf3623b13014f22186b7'
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi Traceback (most recent
> call last):
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/wsgi.py",
> line 1332, in __call__
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     request,
> **action_args)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/wsgi.py",
> line 1370, in dispatch
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     return
> method(*args, **kwargs)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/utils.py",
> line 414, in wrapped
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     return func(self,
> req, *args, **kwargs)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/api/v2/image_data.py",
> line 303, in upload
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> self._restore(image_repo, image)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 227, in __exit__
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> self.force_reraise()
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 200, in force_reraise
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     raise self.value
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/api/v2/image_data.py",
> line 163, in upload
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> image.set_data(data, size, backend=backend)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/notifier.py", line
> 497, in set_data
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> _send_notification(notify_error, 'image.upload', msg)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 227, in __exit__
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> self.force_reraise()
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> line 200, in force_reraise
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     raise self.value
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/notifier.py", line
> 444, in set_data
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> set_active=set_active)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/quota/__init__.py",
> line 323, in set_data
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> set_active=set_active)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/location.py", line
> 585, in set_data
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> self._upload_to_store(data, verifier, backend, size)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/location.py", line
> 485, in _upload_to_store
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     verifier=verifier)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/multi_backend.py",
> line 399, in add_with_multihash
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     image_id, data,
> size, hashing_algo, store, context, verifier)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/multi_backend.py",
> line 481, in store_add_to_backend_with_multihash
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     image_id, data,
> size, hashing_algo, context=context, verifier=verifier)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/driver.py",
> line 279, in add_adapter
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     metadata_dict) =
> store_add_fun(*args, **kwargs)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/capabilities.py",
> line 176, in op_checker
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     return
> store_op_fun(store, *args, **kwargs)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py",
> line 1028, in add
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     raise
> errors.get(e.errno, e)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py",
> line 985, in add
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     with
> self._open_cinder_volume(client, volume, 'wb') as f:
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/usr/lib64/python3.6/contextlib.py", line 81, in __enter__
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     return
> next(self.gen)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py",
> line 788, in _open_cinder_volume
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     device =
> connect_volume_nfs()
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_concurrency/lockutils.py",
> line 391, in inner
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     return f(*args,
> **kwargs)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py",
> line 786, in connect_volume_nfs
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     root_helper,
> options)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/common/fs_mount.py",
> line 359, in mount
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     rootwrap_helper,
> options)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/common/fs_mount.py",
> line 247, in mount
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> os.makedirs(mountpoint)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> "/usr/lib64/python3.6/os.py", line 220, in makedirs
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     mkdir(name, mode)
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi FileExistsError:
> [Errno 17] File exists:
> '/var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624f97bf3623b13014f22186b7'
> 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
>


Regards.

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230417/dd99b325/attachment.htm>

From smooney at redhat.com  Mon Apr 17 16:38:21 2023
From: smooney at redhat.com (Sean Mooney)
Date: Mon, 17 Apr 2023 17:38:21 +0100
Subject: [kolla-ansible][yoga] Glance backend cinder Privsep daemon
 failed to start operation not permitted
In-Reply-To: <CAJV_UBB7m-3Cv1soi_mZDuWzK3_DmdHhzwr2sH0yt3+eOgJ6yA@mail.gmail.com>
References: <CAJV_UBC95fMQh00w7vxbyV55F=wXuLXjgVYG5fYy08en2VYtaA@mail.gmail.com>
 <CADO3vb4++zhHTu3Gfdsb3pYZFMdwGSytDuXhN0QZ-JCdVFqu7A@mail.gmail.com>
 <323313cf9ef907a0bbbdce18e7ae71654385e1f2.camel@redhat.com>
 <CAJV_UBDUQ0x_Y24Q5S8QbvJrLnZ8Moy2q=LsvojjSMRooSrXrg@mail.gmail.com>
 <e0bd7f4fdb6a4e1e949531730f9f19a0304781d6.camel@redhat.com>
 <CAJV_UBCkuvnXem=A8czKSE3zJBp5LtQ9wXQPr-y5LE4X8k3V8A@mail.gmail.com>
 <b2c015f0bda7b9ae16ecbb3dff71e69665db0878.camel@redhat.com>
 <b7e2ae4d7740ca4175a941ce30a0b354b6de99b7.camel@redhat.com>
 <CAJV_UBBHK9L=eS0QhYKx9Jm3xAHvWX6F9F8dH9uFTBn-pVKhdA@mail.gmail.com>
 <CAJV_UBB7m-3Cv1soi_mZDuWzK3_DmdHhzwr2sH0yt3+eOgJ6yA@mail.gmail.com>
Message-ID: <d0388a61b86d6f01daff73b0f423d4aea56ce093.camel@redhat.com>

On Mon, 2023-04-17 at 16:43 +0100, wodel youchi wrote:
> Hi,
> 
> I managed to get another step forward, but I hit another wall.
> Glance-api was trying to mount the NFS share on the controller node
> 
corret galnce-api si not runnign on a compute at least not by default.
and galnce cannot assume that its runnign on the same hosta s cinder so it cannot assume
any mounting done by cinder can be reused.

> , not on
> the compute, so I installed nfs-utils on it, now I have this error :
> 
> 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder
> > [req-35f49fc4-15bc-4d3b-b93e-e039c1d0f3fa 0439953e7cfe4a13a1b4bb118b5dc3c4
> > b0f76b5c6dcb457fa716762bbf954837 - default default] Exception while
> > accessing to cinder volume 3d4712ef-7cb5-4a0b-bc1e-cfbebd8fa902.:
> > FileExistsError: [Errno 17] File exists:
> > '/var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624f97bf3623b13014f22186b7'
> > 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder Traceback
> > (most recent call last):
> > 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py",
> > line 788, in _open_cinder_volume
> > 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder     device =
> > connect_volume_nfs()
> > 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_concurrency/lockutils.py",
> > line 391, in inner
> > 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder     return
> > f(*args, **kwargs)
> > 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py",
> > line 786, in connect_volume_nfs
> > 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder
> > root_helper, options)
> > 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/common/fs_mount.py",
> > line 359, in mount
> > 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder
> > rootwrap_helper, options)
> > 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/common/fs_mount.py",
> > line 247, in mount
> > 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder
> > os.makedirs(mountpoint)
> > 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder   File
> > "/usr/lib64/python3.6/os.py", line 220, in makedirs
> > 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder
> > mkdir(name, mode)
> > 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder
> > FileExistsError: [Errno 17] File exists:
> > '/var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624f97bf3623b13014f22186b7'
> > 2023-04-17 16:33:08.814 62 ERROR glance_store._drivers.cinder
> > 2023-04-17 16:33:08.906 62 ERROR glance_store._drivers.cinder
> > [req-35f49fc4-15bc-4d3b-b93e-e039c1d0f3fa 0439953e7cfe4a13a1b4bb118b5dc3c4
> > b0f76b5c6dcb457fa716762bbf954837 - default default] Failed to write to
> > volume 3d4712ef-7cb5-4a0b-bc1e-cfbebd8fa902.: FileExistsError: [Errno 17]
> > File exists:
> > '/var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624f97bf3623b13014f22186b7'
> > 2023-04-17 16:33:08.939 62 ERROR glance.api.v2.image_data
> > [req-35f49fc4-15bc-4d3b-b93e-e039c1d0f3fa 0439953e7cfe4a13a1b4bb118b5dc3c4
> > b0f76b5c6dcb457fa716762bbf954837 - default default] Failed to upload image
> > data due to internal error: FileExistsError: [Errno 17] File exists:
> > '/var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624f97bf3623b13014f22186b7'
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> > [req-35f49fc4-15bc-4d3b-b93e-e039c1d0f3fa 0439953e7cfe4a13a1b4bb118b5dc3c4
> > b0f76b5c6dcb457fa716762bbf954837 - default default] Caught error: [Errno
> > 17] File exists:
> > '/var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624f97bf3623b13014f22186b7':
> > FileExistsError: [Errno 17] File exists:
> > '/var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624f97bf3623b13014f22186b7'
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi Traceback (most recent
> > call last):
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/wsgi.py",
> > line 1332, in __call__
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     request,
> > **action_args)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/wsgi.py",
> > line 1370, in dispatch
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     return
> > method(*args, **kwargs)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/common/utils.py",
> > line 414, in wrapped
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     return func(self,
> > req, *args, **kwargs)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/api/v2/image_data.py",
> > line 303, in upload
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> > self._restore(image_repo, image)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> > line 227, in __exit__
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> > self.force_reraise()
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> > line 200, in force_reraise
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     raise self.value
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/api/v2/image_data.py",
> > line 163, in upload
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> > image.set_data(data, size, backend=backend)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/notifier.py", line
> > 497, in set_data
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> > _send_notification(notify_error, 'image.upload', msg)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> > line 227, in __exit__
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> > self.force_reraise()
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> > line 200, in force_reraise
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     raise self.value
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/notifier.py", line
> > 444, in set_data
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> > set_active=set_active)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/quota/__init__.py",
> > line 323, in set_data
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> > set_active=set_active)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/location.py", line
> > 585, in set_data
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> > self._upload_to_store(data, verifier, backend, size)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance/location.py", line
> > 485, in _upload_to_store
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     verifier=verifier)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/multi_backend.py",
> > line 399, in add_with_multihash
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     image_id, data,
> > size, hashing_algo, store, context, verifier)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/multi_backend.py",
> > line 481, in store_add_to_backend_with_multihash
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     image_id, data,
> > size, hashing_algo, context=context, verifier=verifier)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/driver.py",
> > line 279, in add_adapter
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     metadata_dict) =
> > store_add_fun(*args, **kwargs)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/capabilities.py",
> > line 176, in op_checker
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     return
> > store_op_fun(store, *args, **kwargs)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py",
> > line 1028, in add
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     raise
> > errors.get(e.errno, e)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py",
> > line 985, in add
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     with
> > self._open_cinder_volume(client, volume, 'wb') as f:
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/usr/lib64/python3.6/contextlib.py", line 81, in __enter__
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     return
> > next(self.gen)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py",
> > line 788, in _open_cinder_volume
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     device =
> > connect_volume_nfs()
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_concurrency/lockutils.py",
> > line 391, in inner
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     return f(*args,
> > **kwargs)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/_drivers/cinder.py",
> > line 786, in connect_volume_nfs
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     root_helper,
> > options)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/common/fs_mount.py",
> > line 359, in mount
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     rootwrap_helper,
> > options)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/var/lib/kolla/venv/lib/python3.6/site-packages/glance_store/common/fs_mount.py",
> > line 247, in mount
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> > os.makedirs(mountpoint)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi   File
> > "/usr/lib64/python3.6/os.py", line 220, in makedirs
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi     mkdir(name, mode)
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi FileExistsError:
> > [Errno 17] File exists:
> > '/var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624f97bf3623b13014f22186b7'
> > 2023-04-17 16:33:08.957 62 ERROR glance.common.wsgi
> > 
> 
> 
> Regards.
> 
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> Virus-free.www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>



From jlibosva at redhat.com  Mon Apr 17 18:04:21 2023
From: jlibosva at redhat.com (Jakub Libosvar)
Date: Mon, 17 Apr 2023 14:04:21 -0400
Subject: [Neutron] Future of TripleO OVN migration in-tree code
In-Reply-To: <CAPd_6Avs7_vjMFOt1qNKd64knD2FbLb9_FxXXE9ni42p1suyXw@mail.gmail.com>
References: <1FBD2524-4B12-4EF9-BF86-4876FF830899@redhat.com>
 <CAPd_6Avs7_vjMFOt1qNKd64knD2FbLb9_FxXXE9ni42p1suyXw@mail.gmail.com>
Message-ID: <523FD8DE-B09B-4E24-BE68-CC44519D7898@redhat.com>

Hi Dmitriy,

those are great news! I agree with it being installer agnostic, I even think this was discussed at some earlier PTGs. The problem with the migration tool is that it does have no CI so the patches are manually tested, best effort. That said, would be awesome to have CI with openstack-ansible :)

Let me know if you need any help understanding the concept, we can schedule some call if you want to go over the code base too if you?d be insterested.

Best regards
Kuba



> On Apr 14, 2023, at 11:10 PM, Dmitriy Rabotyagov <noonedeadpunk at gmail.com> wrote:
> 
> Hi, Jakub,
> 
> I'm interested to keep OVN migration alive. At the same time I'm not interested in maintaining TripleO bits.
> 
> I can check the code deeper during the next week and see what I can do and return back to you.
> 
> Ideally I think the code should be tool-agnostic, but at worst case scenario I will be able to work on adding OpenStack-Ansible support for the migration.
> 
> ??, 14 ???. 2023 ?., 23:05 Jakub Libosvar <jlibosva at redhat.com>:
> Hello Neutrinos and others,
> 
> as this has been brought up several times through some conversation channels with no consensus, I wanted to start a discussion and possibly find a consensus about the code for migrating an OpenStack from OVS mechanism driver to OVN [1].
> 
> The code leverages TripleO to install and to configure OVN services, however the TripleO project is no longer maintained after Zed release [2].
> This brings up the question what to do with the migration tooling that relies on TripleO. Shall we remove the code completely or is there anybody who would be interested in maintaining that code and implement support for other installers?
> 
> Thanks
> 
> Kuba
> 
> [1] https://opendev.org/openstack/neutron/src/branch/master/tools/ovn_migration/tripleo_environment
> [2] https://review.opendev.org/c/openstack/governance/+/878799
> 
> 



From elod.illes at est.tech  Mon Apr 17 18:40:12 2023
From: elod.illes at est.tech (=?utf-8?B?RWzDtWQgSWxsw6lz?=)
Date: Mon, 17 Apr 2023 18:40:12 +0000
Subject: [all][stable][ptl] Propose to EOL Rocky series
In-Reply-To: <80674f31-dd98-849f-9bce-43e385a9ba6b@gmail.com>
References: <E1pLm0Z-001aff-0j@lists.openstack.org>
 <VI1P18901MB0751BF4E42E67D9FABC8AB51FFDE9@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>
 <e600c96d-19f9-4a14-6abf-08bd01b79d79@debian.org>
 <VI1P18901MB07518A29DA2DDC613DB0FF80FF889@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>
 <80674f31-dd98-849f-9bce-43e385a9ba6b@gmail.com>
Message-ID: <VI1P18901MB07514F4F0C5EA32EA9FDFC58FF9C9@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>

Hi,

Thanks, Brian, for sharing Cinder team's view on this topic! I was thinking what to do now, and, because I agree that Rocky (and Stein, too) is probably a done business already, I'm planning to propose the rocky-eol patches for projects that are still open, and teams can signal their decision on those patches (such as: +1 to EOL their stable/rocky branch, or -1 to keep it open).

Thanks again for the responses,

El?d
________________________________
From: Brian Rosmaita <rosmaita.fossdev at gmail.com>
Sent: Wednesday, April 12, 2023 6:49 PM
To: openstack-discuss at lists.openstack.org <openstack-discuss at lists.openstack.org>
Subject: Re: [all][stable][ptl] Propose to EOL Rocky series

On 3/28/23 2:34 AM, El?d Ill?s wrote:
> Hi,
>
> this thread was bit of forgotten, sorry for that. A bit more than two
> weeks ago we had a discussion on #openstack-release about this [1].
>
> So, to summerize, there are the issues:
> - stable/rocky's gate is mostly broken
> - more than one third of the repositories have transitioned their
>    stable/rocky branch to EOL (including multiple core component)
> - old, unmaintained CI jobs, testing environments, hinders refactoring
>    of Zuul jobs and other configurations
>
> On the other hand, as Thomas mentioned, there is the need for some
> to be able to cooperate (as an example: recent security issue [2],
> mentioned in previous mail or in our IRC discussion) on a common place,
> namely in gerrit.

The Cinder project team discussed this at the 2023.2 Bobcat vPTG and
decided that we will definitely EOL rocky AND stein.  Given that other
core projects have already done this, they've outlived their usefulness,
even if they were only to be used to discuss patches for those branches
in gerrit.  If a cinder patch requires patches in other services that
have EOL'd that branch, that other service's patches can't be discussed
in gerrit.  (And if there's an alternative place to discuss, for
example, a nova rocky patch, then that alternative place can be used to
discuss cinder EOL patches, too.)

> This was originally the intention with Extended
> Maintenance. We just haven't thought about eternity :)

We are also concerned about the eternal nature of older branches.  There
are some open source projects where the convention has been to never
delete a branch, even though at a certain point, no changes will be
accepted into such a branch.  OpenStack, however, is not such a project,
and we *do* delete branches.  There's a feeling among the project team
that while a branch exists, we are still responsible for it, and there's
an expectation that (no matter what the EM docs say), the project team
is keeping an eye on it.  So we support the current
declare-EOL-and-delete-the-branch policy.

Additionally, if we leave a branch in EM but turn off all CI because the
team has no intention of ever merging anything into that branch, using
gerrit for discussion of patches is probably unworkable as you start to
get a bunch of patches into merge conflict, and it looks like the whole
situation will just become a mess.

> It seems that teams feel that if a branch is 'open' and in 'Extended
> Maintenance' then it still means it is 'fully supported', thus cannot
> let the gate failing AND don't want to merge patches without gate
> tests, that's one reason why teams rather EOL their branches.

We agree.  "Not fully supported but still maintained" is a weird state.
The way OpenStack has signaled "no more" for a branch is to delete it,
so we continue to support the eol-and-delete policy.

> We might need to think more about what is the best way forward.

We think that rocky and stein are done deals because some projects have
already deleted them.  The next issue is train ... is it even
responsible to have a branch that supports Python 2 be in extended
maintenance?  We agree that this requires some more thought.

> [1]
> https://meetings.opendev.org/irclogs/%23openstack-release/%23openstack-release.2023-03-08.log.html#t2023-03-08T13:54:34
> [2] https://security.openstack.org/ossa/OSSA-2023-002.html
>
> El?d
> irc: elodilles
>
> ------------------------------------------------------------------------
> *From:* Thomas Goirand <zigo at debian.org>
> *Sent:* Tuesday, February 14, 2023 7:31 PM
> *To:* El?d Ill?s <elod.illes at est.tech>
> *Cc:* openstack-discuss at lists.openstack.org
> <openstack-discuss at lists.openstack.org>
> *Subject:* Re: [all][stable][ptl] Propose to EOL Rocky series
> On 2/10/23 18:26, El?d Ill?s wrote:
>> Hi,
>>
>> thanks for all the feedbacks from teams so far!
>>
>> @Zigo: Extended Maintenance process was created just for the same
>> situation: to give space to interested parties to cooperate and keep
>> things maintained even when stable releases are over their 'supported'
>> lifetime. So it's good to see that there is interest in it!
>> Unfortunately, with very old branches we've reached the state where
>> gates can't be maintained and without a functional gate it's not safe to
>> merge patches (yes, even security fixes) and they are just using
>> resources (CI & maintainers' time). When gate is broken in such extent,
>> then i think the community have to accept that it is not possible to
>> merge patches confidently and needs to EOL that release.
>
> That's where I don't agree. There are ways, outside of the OpenStack
> gate, to test things, in such ways that merging patches there can be a
> thing.
>
>> Another aspect is that code cannot be cleaned up until those old
>> branches are still present (CI jobs, project configurations, etc) which
>> gives pain for developers.
>
> Just disable gating completely then.
>
>> So, however some vendors would appreciate probably to keep things open
>> forever, for the community this is not beneficial and doable I think.
>
> I don't agree. We need a place to share patches between distros. The
> official Git feels like the natural place to do so, even without any
> type of gating.
>
> BTW, my Nova patches for CVE-2022-47951 in Rocky, Stein & Train are
> currently wrong and need another approach. I was thinking about simply
> disabling .vmdk altogether (rather than having a complicated code to
> check for the VMDK subtype). I wonder what other distros did. Where do I
> disucss this?
>
> Cheers,
>
> Thomas Goirand (zigo)
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230417/113c4f66/attachment-0001.htm>

From maksim.malchuk at gmail.com  Mon Apr 17 20:52:50 2023
From: maksim.malchuk at gmail.com (Maksim Malchuk)
Date: Mon, 17 Apr 2023 23:52:50 +0300
Subject: [kolla] [openeuler] CI jobs status
In-Reply-To: <71E23583-527B-4502-A624-A118E7CCA3E3@gmail.com>
References: <71E23583-527B-4502-A624-A118E7CCA3E3@gmail.com>
Message-ID: <CAE_fguAsdM-CC4J5OEOska7DK4vsZH+reMbBsgTzCDW+gdUT7g@mail.gmail.com>

Hi Micha?,

We moved from Centos to Rocky so hard, I think supporting another one
RedHat "compatible system" would be not easy.

On Mon, Apr 17, 2023 at 6:21?PM Micha? Nasiadka <mnasiadka at gmail.com> wrote:

> Hello Koalas,
>
> OpenEuler jobs in master (to be Antelope) are failing for a long time.
> If no one is interested in maintaining OpenEuler support in Kolla-Ansible
> - I will propose dropping it?s support on Wednesday Kolla meeting.
>
> Best regards,
> Michal
>


-- 
Regards,
Maksim Malchuk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230417/04b07283/attachment.htm>

From pierre at stackhpc.com  Tue Apr 18 07:57:18 2023
From: pierre at stackhpc.com (Pierre Riteau)
Date: Tue, 18 Apr 2023 09:57:18 +0200
Subject: [zun][zun_api][blazar][config][yoga][kolla-ansible] Adding more
 configuration to config file
In-Reply-To: <CA+_ZFmEQDi=FfOcFJOMWnvCBG7-x2QJ-fKSmWMitBfpKPaXXGg@mail.gmail.com>
References: <CA+_ZFmEQDi=FfOcFJOMWnvCBG7-x2QJ-fKSmWMitBfpKPaXXGg@mail.gmail.com>
Message-ID: <CA+ny2sxafk0Y8E+X7Zzq1qQDijDt0rvt58L+Jg8V5HSpLRERvw@mail.gmail.com>

Hi James,

As far as I know, there is no integration between Zun and Blazar. So, if
you want Zun to be able to read information from the Blazar database, you
would need to modify Zun's code to do so.

May I ask what you are trying to do? OpenStack services don't read each
other's databases, but instead interact via HTTP APIs.

Best wishes,
Pierre Riteau (priteau)

On Thu, 13 Apr 2023 at 00:08, James Leong <jamesleong123098 at gmail.com>
wrote:

> Hi all,
>
> I am playing around with Zun. I have used kolla-ansible as a deployment
> tool for deploying the yoga version of OpenStack. I am trying to add an
> option to the configuration file. However, those added options are not
> recognized by OpenStack when being called. For instance, Zun.conf, I am
> adding a new database (blazar) information to it so I can access blazar
> information in the zun service. Would that be possible to allow the zun_api
> container to access the blazar database?
>
> Thanks for your help,
> James
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230418/0acb88ec/attachment.htm>

From pierre at stackhpc.com  Tue Apr 18 08:01:42 2023
From: pierre at stackhpc.com (Pierre Riteau)
Date: Tue, 18 Apr 2023 10:01:42 +0200
Subject: [Horizon]: allow user to access calendar on horizon
In-Reply-To: <CA+_ZFmHVNN3QtNkM3ipDCDhbP71wCXekc3vE2p=Bjc5nDg0KNg@mail.gmail.com>
References: <CA+_ZFmHVNN3QtNkM3ipDCDhbP71wCXekc3vE2p=Bjc5nDg0KNg@mail.gmail.com>
Message-ID: <CA+ny2syMZBuFntWC-Ew-pc-1hf-JOb5D0Mv9R894P7J51iZ3YA@mail.gmail.com>

Hi James,

This is documented in the blazar-dashboard docs at
https://docs.openstack.org/blazar-dashboard/latest/calendar.html:

In order to be able to view the calendar, a user needs permission for
blazar:oshosts:get and blazar:oshosts:get_allocations.


You need to customise the Blazar policy.yaml file to allow these calls for
any member. It would look like this:

/etc/kolla/config/blazar/policy.yaml:

# Policies required to access the host reservation calendar
"blazar:oshosts:get": ""
"blazar:oshosts:get_allocations": ""

Best wishes,
Pierre Riteau (priteau)

PS: You should have used [blazar] as a tag, I only found your message by
accident.

On Mon, 13 Mar 2023 at 04:40, James Leong <jamesleong123098 at gmail.com>
wrote:

> Hi all,
> I am using kolla-ansible for OpenStack deployment in the yoga version. Is
> it possible to allow the user (member role) to view the calendar graph
> under the reservation tab (lease)? Currently, only the admin will be able
> to view the calendar graph with all the reserved leases. However, a user
> with other roles cannot load the calendar information. On the dashboard, I
> saw it displayed " Unable to load reservations." When I look into the log
> file, I get the below error message.
>
> "blazarclient.exception.BlazarClientException: ERROR: Policy doesn't allow
> blazar:oshosts:get to be performed."
>
> Is there a way to allow the policy?
>
> Thanks for your help.
> James
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230418/cfb7b2e0/attachment.htm>

From pierre at stackhpc.com  Tue Apr 18 08:04:46 2023
From: pierre at stackhpc.com (Pierre Riteau)
Date: Tue, 18 Apr 2023 10:04:46 +0200
Subject: [kolla][kolla-ansible] Kolla-Ansible mirror update and kolla
 images
In-Reply-To: <CABAODRfu_PCJhgwbk5K5_voX08=KF=SHgJKPpA_eW8e12Spbjw@mail.gmail.com>
References: <CABAODRfu_PCJhgwbk5K5_voX08=KF=SHgJKPpA_eW8e12Spbjw@mail.gmail.com>
Message-ID: <CA+ny2sxeJvjyGa6-8J4ak1Bf7QuEeqkj+MOMdbr-hs_RPALtLQ@mail.gmail.com>

It is generally recommended to use the stable branch, for example
stable/xena in your case, to get the most recent images.
You can build your own or pull them from quay.io.

On Wed, 5 Apr 2023 at 01:42, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Hello.
>
> I have a question.
>
> I use kolla-ansible 13.0.0 and kolla 13.0.0 images then I upgrade
> kolla-ansible to 13.8.0. I will use kolla 13.8.0 to build new images?
>
> Thank you. Regards
>
> Nguyen Huu Khoi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230418/40be881a/attachment.htm>

From nguyenhuukhoinw at gmail.com  Tue Apr 18 08:28:03 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Tue, 18 Apr 2023 15:28:03 +0700
Subject: [kolla][kolla-ansible] Kolla-Ansible mirror update and kolla
 images
In-Reply-To: <CA+ny2sxeJvjyGa6-8J4ak1Bf7QuEeqkj+MOMdbr-hs_RPALtLQ@mail.gmail.com>
References: <CABAODRfu_PCJhgwbk5K5_voX08=KF=SHgJKPpA_eW8e12Spbjw@mail.gmail.com>
 <CA+ny2sxeJvjyGa6-8J4ak1Bf7QuEeqkj+MOMdbr-hs_RPALtLQ@mail.gmail.com>
Message-ID: <CABAODRcuPDX7d1=Zu1K7Qdy201ys-kxidYYCynRRdF0qY13s3Q@mail.gmail.com>

Thank you for your answer. :)
Nguyen Huu Khoi


On Tue, Apr 18, 2023 at 3:05?PM Pierre Riteau <pierre at stackhpc.com> wrote:

> It is generally recommended to use the stable branch, for example
> stable/xena in your case, to get the most recent images.
> You can build your own or pull them from quay.io.
>
> On Wed, 5 Apr 2023 at 01:42, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> wrote:
>
>> Hello.
>>
>> I have a question.
>>
>> I use kolla-ansible 13.0.0 and kolla 13.0.0 images then I upgrade
>> kolla-ansible to 13.8.0. I will use kolla 13.8.0 to build new images?
>>
>> Thank you. Regards
>>
>> Nguyen Huu Khoi
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230418/67469ffc/attachment-0001.htm>

From Danny.Webb at thehutgroup.com  Tue Apr 18 09:37:22 2023
From: Danny.Webb at thehutgroup.com (Danny Webb)
Date: Tue, 18 Apr 2023 09:37:22 +0000
Subject: [kolla][kolla-ansible] Kolla-Ansible mirror update and kolla
 images
In-Reply-To: <CABAODRcuPDX7d1=Zu1K7Qdy201ys-kxidYYCynRRdF0qY13s3Q@mail.gmail.com>
References: <CABAODRfu_PCJhgwbk5K5_voX08=KF=SHgJKPpA_eW8e12Spbjw@mail.gmail.com>
 <CA+ny2sxeJvjyGa6-8J4ak1Bf7QuEeqkj+MOMdbr-hs_RPALtLQ@mail.gmail.com>
 <CABAODRcuPDX7d1=Zu1K7Qdy201ys-kxidYYCynRRdF0qY13s3Q@mail.gmail.com>
Message-ID: <LO2P265MB5773FB77A44378CE19F79B1C9A9D9@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>

Just a little operator anecdote,  we build all our our images using the kolla image builder instead of pulling from public repos.  It gives us a better option for versioning our containers so we get homogeneous deployments.  When we used the upstream repos we couldn't guarantee that our images would be the same between say the original deployment and the deployment of some new computes a month or so later.
________________________________
From: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
Sent: 18 April 2023 09:28
To: Pierre Riteau <pierre at stackhpc.com>
Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org>
Subject: Re: [kolla][kolla-ansible] Kolla-Ansible mirror update and kolla images


CAUTION: This email originates from outside THG

________________________________
Thank you for your answer. :)
Nguyen Huu Khoi


On Tue, Apr 18, 2023 at 3:05?PM Pierre Riteau <pierre at stackhpc.com<mailto:pierre at stackhpc.com>> wrote:
It is generally recommended to use the stable branch, for example stable/xena in your case, to get the most recent images.
You can build your own or pull them from quay.io<http://quay.io>.

On Wed, 5 Apr 2023 at 01:42, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com<mailto:nguyenhuukhoinw at gmail.com>> wrote:
Hello.

I have a question.

I use kolla-ansible 13.0.0 and kolla 13.0.0 images then I upgrade kolla-ansible to 13.8.0. I will use kolla 13.8.0 to build new images?

Thank you. Regards

Nguyen Huu Khoi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230418/169d7ae3/attachment.htm>

From ralonsoh at redhat.com  Tue Apr 18 09:39:06 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Tue, 18 Apr 2023 11:39:06 +0200
Subject: [neutron] Bug deputy April 10-16th
Message-ID: <CAECr9X4yHacRpkv=t=MbUbnXwGRn3+1H9dip3SqqqDYXxLdSSQ@mail.gmail.com>

Hello Neutrinos:

This is the bug list from the last week:

High:
* https://bugs.launchpad.net/neutron/+bug/2015847: Functional job db
missconfiguration. Assigned to Rodolfo.
* https://bugs.launchpad.net/neutron/+bug/2016142: [sqlalchemy-20] Error in
"get_ports_on_host_by_subnet" execution. Fixed.
* https://bugs.launchpad.net/neutron/+bug/2016266: [Secure RBAC] Get
availability zone API should be available for READER role. Assigned to
Slawek. Patch proposed:
https://review.opendev.org/c/openstack/neutron/+/880461

Medium:
* https://bugs.launchpad.net/neutron/+bug/2016198: [L3][HA] race condition
between first two router creations when tenant has no HA network. Related
to https://bugs.launchpad.net/neutron/+bug/2016197. Not assigned.

Low:
* https://bugs.launchpad.net/neutron/+bug/2015844: Remove netifaces
dependency from neutron. To be discussed during the Neutron meeting.
* https://bugs.launchpad.net/neutron/+bug/1988039: ovs idl not monitor
tables after reconnect. Patch proposed:
https://review.opendev.org/c/openstack/neutron/+/857010
* https://bugs.launchpad.net/neutron/+bug/2016413: api-ref: missing
documentation for subnet-onboard. Not assigned.

Whislist:
* https://bugs.launchpad.net/neutron/+bug/2016158: [OVN] How to deal with
SB "Chassis"/"Chassis_Private" duplicated registers. Assigned to Rodolfo.
* https://bugs.launchpad.net/neutron/+bug/2016197: [Open Discussion]
neutron can create port from network which has no subnet. Not assigned
(maybe it won?t be necessary).

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230418/92d716cf/attachment.htm>

From pierre at stackhpc.com  Tue Apr 18 09:40:22 2023
From: pierre at stackhpc.com (Pierre Riteau)
Date: Tue, 18 Apr 2023 11:40:22 +0200
Subject: [kolla][kolla-ansible] Kolla-Ansible mirror update and kolla
 images
In-Reply-To: <LO2P265MB5773FB77A44378CE19F79B1C9A9D9@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
References: <CABAODRfu_PCJhgwbk5K5_voX08=KF=SHgJKPpA_eW8e12Spbjw@mail.gmail.com>
 <CA+ny2sxeJvjyGa6-8J4ak1Bf7QuEeqkj+MOMdbr-hs_RPALtLQ@mail.gmail.com>
 <CABAODRcuPDX7d1=Zu1K7Qdy201ys-kxidYYCynRRdF0qY13s3Q@mail.gmail.com>
 <LO2P265MB5773FB77A44378CE19F79B1C9A9D9@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <CA+ny2sw233Skink92k1jSTN3rJ17rd+SjFTf6m2HNsfn2TzSGQ@mail.gmail.com>

Indeed, I wouldn't advise pulling upstream container images directly to
your compute hosts. You should mirror the container images into a local
registry. This will ensure you get a homogeneous deployment.

On Tue, 18 Apr 2023 at 11:37, Danny Webb <Danny.Webb at thehutgroup.com> wrote:

> Just a little operator anecdote,  we build all our our images using the
> kolla image builder instead of pulling from public repos.  It gives us a
> better option for versioning our containers so we get homogeneous
> deployments.  When we used the upstream repos we couldn't guarantee that
> our images would be the same between say the original deployment and the
> deployment of some new computes a month or so later.
> ------------------------------
> *From:* Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> *Sent:* 18 April 2023 09:28
> *To:* Pierre Riteau <pierre at stackhpc.com>
> *Cc:* OpenStack Discuss <openstack-discuss at lists.openstack.org>
> *Subject:* Re: [kolla][kolla-ansible] Kolla-Ansible mirror update and
> kolla images
>
>
> * CAUTION: This email originates from outside THG *
> ------------------------------
> Thank you for your answer. :)
> Nguyen Huu Khoi
>
>
> On Tue, Apr 18, 2023 at 3:05?PM Pierre Riteau <pierre at stackhpc.com> wrote:
>
> It is generally recommended to use the stable branch, for example
> stable/xena in your case, to get the most recent images.
> You can build your own or pull them from quay.io.
>
> On Wed, 5 Apr 2023 at 01:42, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> wrote:
>
> Hello.
>
> I have a question.
>
> I use kolla-ansible 13.0.0 and kolla 13.0.0 images then I upgrade
> kolla-ansible to 13.8.0. I will use kolla 13.8.0 to build new images?
>
> Thank you. Regards
>
> Nguyen Huu Khoi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230418/e9841357/attachment-0001.htm>

From eblock at nde.ag  Tue Apr 18 11:37:12 2023
From: eblock at nde.ag (Eugen Block)
Date: Tue, 18 Apr 2023 11:37:12 +0000
Subject: [neutron] [kolla-ansible] alembic mismatch, schema differences
In-Reply-To: <532a6f17-2cda-112e-1744-4c377b8d843c@pawsey.org.au>
References: <d7cae712-bf0c-9144-38cb-ad8fe61f6d54@pawsey.org.au>
 <532a6f17-2cda-112e-1744-4c377b8d843c@pawsey.org.au>
Message-ID: <20230418113712.Horde.8KfiDAn_9ZqPTQsOnQwwFHu@webmail.nde.ag>

Hi, I'm glad you worked that out. But one thing I'm wondering since  
I'm not familiar with kolla (as I'm stating repeatedly), why does the  
compute node have the capabilities to manipulate the neutron database?  
Is that by design? We have our own deployment mechanism on baremetal  
and there's no "connection =..." string available on compute nodes.  
Maybe I misunderstood something, but I find it strange that such a  
thing could happen that easily.

Thanks,
Eugen

Zitat von Gregory Orange <gregory.orange at pawsey.org.au>:

> Solution: Manually revert the database schema changes.
>
> We found that `neutron-db-manage downgrade` has been unsupported for  
> quite some time, so that avenue was closed to us. So, we restored  
> backups of before and after to some temporary mariadb servers, to  
> look at and compare the data. In the end this is how we reverted it  
> (mysql < revert_wallaby_schema.sql):
>
> use neutron
>
> alter table address_scopes alter column shared drop default;
> alter table meteringlabelrules drop column source_ip_prefix;
> alter table meteringlabelrules drop column destination_ip_prefix;
> alter table ml2_vlan_allocations drop constraint  
> check_ml2_vlan_allocations0vlan_id;
> alter table networkdhcpagentbindings drop index  
> uniq_network_dhcp_agent_binding0network_id0binding_index0;
> alter table networkdhcpagentbindings drop column binding_index;
> alter table networks modify mtu int(11) null default null;
> alter table portforwardings drop constraint portforwardings_ibfk_3;
> alter table portforwardings drop index uniq_portforwardings0standard_attr_id;
> alter table portforwardings drop column standard_attr_id;
> alter table portuplinkstatuspropagation alter column  
> propagate_uplink_status set default 0;
> alter table quotas drop index uniq_quotas0project_id0resource;
> alter table securitygroups drop constraint CONSTRAINT_1;
> alter table securitygroups drop column stateful;
> alter table securitygrouprules drop constraint securitygrouprules_ibfk_4;
> alter table securitygrouprules drop column remote_address_group_id;
> alter table subnetpools alter column shared drop default;
> alter table subnets drop constraint CONSTRAINT_1;
> alter table subnets drop column in_use;
>
> update alembic_version set version_num='c613d0b82681' where  
> version_num='6135a7bd4425';
>
> drop table address_associations;
> drop table addressgrouprbacs;
> drop table address_groups;
> drop table addressscoperbacs;
> drop table dvr_fip_gateway_port_network;
> drop table network_subnet_lock;
> drop table ovn_hash_ring;
> drop table ovn_revision_numbers;
> drop table portdeviceprofiles;
> drop table portnumaaffinitypolicies;
> drop table subnet_dns_publish_fixed_ips;
> drop table subnetpoolrbacs;
>
>
> And everything is fine again.
>
> Greg.





From jake.yip at ardc.edu.au  Tue Apr 18 11:53:48 2023
From: jake.yip at ardc.edu.au (Jake Yip)
Date: Tue, 18 Apr 2023 21:53:48 +1000
Subject: [heat][magnum][tacker] Future of SoftwareDeployment support
In-Reply-To: <CAL_crJTB_D+Y+LVRs2qNindh8e1Pk=aK2EEx7SP09eSFZDRB5g@mail.gmail.com>
References: <CAL_crJTB_D+Y+LVRs2qNindh8e1Pk=aK2EEx7SP09eSFZDRB5g@mail.gmail.com>
Message-ID: <6396cae4-9afd-b823-525f-90690d8c29d7@ardc.edu.au>

HI Takashi,

Sorry I missed replying.

On 30/3/2023 1:46 pm, Takashi Kajinami wrote:

> 
> 1. Magnum
> It seems SoftwareDeployment is used by k8s_fedora_atomic_v1 driver but 
> I'm not too sure whether
> this driver is still supported, because Fedora Atomic was EOLed a while 
> ago, right ?
> 

No It's still in the main k8s_fedora_coreos_v1 driver. It basically is 
how everything is set up, so we still depend on this greatly for now.

We are also working on a ClusterAPI driver who will bypass heat 
altogether. We hope to get it working within two cycles, then we can 
remove k8s_fedora_coreos_v1 together, possibly within another two cycles.

Thanks!

Regards
Jake


From yasufum.o at gmail.com  Tue Apr 18 12:42:50 2023
From: yasufum.o at gmail.com (Yasufumi Ogawa)
Date: Tue, 18 Apr 2023 14:42:50 +0200
Subject: [heat][magnum][tacker] Future of SoftwareDeployment support
In-Reply-To: <CAL_crJTB_D+Y+LVRs2qNindh8e1Pk=aK2EEx7SP09eSFZDRB5g@mail.gmail.com>
References: <CAL_crJTB_D+Y+LVRs2qNindh8e1Pk=aK2EEx7SP09eSFZDRB5g@mail.gmail.com>
Message-ID: <1842d77c-c6e4-c28e-fd6a-55d1dbc634cf@gmail.com>

Hi,

Sorry for the late reply. For tacker, it can be dropped because it only 
used in some few tests and the features itself of the tests have been 
deprecated. On the other hand, I'm not sure for heat-translator but it 
can be also dropped considering takcer's parspective scarcely depends on 
the feature. Anyway, I would like to have a discussion in tacker's IRC 
meeting before making the decision.

Thanks,
Yasufumi

On 2023/03/30 11:46, Takashi Kajinami wrote:
> Hello,
> 
> 
> We discussed this briefly in the past thread where we discussed maintenance
> of os-*-agent repos,
> and also talked about this topic during Heat PTG, but I'd like to formalize
> the discussion to get
> a clear agreement.
> 
> Heat has been supporting SoftwareDeployment resources to configure software
> in instances using
> some agents such as os-collect-config[1].
>   [1]
> https://docs.openstack.org/heat/latest/template_guide/software_deployment.html#software-deployment-resources
> 
> This feature was initially developed to be used by TripleO (IIUC), but
> TripleO is retired now and
> we are losing the first motivation to maintain the feature.
> #  Even TripleO replaced most of its usage of softwaredeployment by
> config-download lately.
> 
> Because the heat project team has drunk dramatically recently, we'd like to
> put more focus on core
> features. For that aim we are now wondering if we can deprecate and remove
> this feature, and would
> like to hear from anyone who has any concerns about this.
> 
> Quickly looking through the repos, it seems currently Magnum and Tacker are
> using SoftwareDeployment,
> and it'd be nice especially if we can understand their current requirements.
> 
> 1. Magnum
> It seems SoftwareDeployment is used by k8s_fedora_atomic_v1 driver but I'm
> not too sure whether
> this driver is still supported, because Fedora Atomic was EOLed a while
> ago, right ?
> 
> 2. Tacker
> SoftwareDeployment can be found in only test code in the tacker repo. We
> have some references kept
> in heat-translator which look related to TOSCA templates.
> 
> Thank you,
> Takashi Kajinami
> 


From skaplons at redhat.com  Tue Apr 18 12:56:26 2023
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Tue, 18 Apr 2023 14:56:26 +0200
Subject: [neutron] [kolla-ansible] alembic mismatch, schema differences
In-Reply-To: <20230418113712.Horde.8KfiDAn_9ZqPTQsOnQwwFHu@webmail.nde.ag>
References: <d7cae712-bf0c-9144-38cb-ad8fe61f6d54@pawsey.org.au>
 <532a6f17-2cda-112e-1744-4c377b8d843c@pawsey.org.au>
 <20230418113712.Horde.8KfiDAn_9ZqPTQsOnQwwFHu@webmail.nde.ag>
Message-ID: <1892258.J3ZZrq5oHq@p1>

Hi,

Dnia wtorek, 18 kwietnia 2023 13:37:12 CEST Eugen Block pisze:
> Hi, I'm glad you worked that out. But one thing I'm wondering since  
> I'm not familiar with kolla (as I'm stating repeatedly), why does the  
> compute node have the capabilities to manipulate the neutron database?  
> Is that by design? 

It shouldn't. Only neutron-server should have access to the DB.

> We have our own deployment mechanism on baremetal  
> and there's no "connection =..." string available on compute nodes.  
> Maybe I misunderstood something, but I find it strange that such a  
> thing could happen that easily.
> 
> Thanks,
> Eugen
> 
> Zitat von Gregory Orange <gregory.orange at pawsey.org.au>:
> 
> > Solution: Manually revert the database schema changes.
> >
> > We found that `neutron-db-manage downgrade` has been unsupported for  
> > quite some time, so that avenue was closed to us. So, we restored  
> > backups of before and after to some temporary mariadb servers, to  
> > look at and compare the data. In the end this is how we reverted it  
> > (mysql < revert_wallaby_schema.sql):
> >
> > use neutron
> >
> > alter table address_scopes alter column shared drop default;
> > alter table meteringlabelrules drop column source_ip_prefix;
> > alter table meteringlabelrules drop column destination_ip_prefix;
> > alter table ml2_vlan_allocations drop constraint  
> > check_ml2_vlan_allocations0vlan_id;
> > alter table networkdhcpagentbindings drop index  
> > uniq_network_dhcp_agent_binding0network_id0binding_index0;
> > alter table networkdhcpagentbindings drop column binding_index;
> > alter table networks modify mtu int(11) null default null;
> > alter table portforwardings drop constraint portforwardings_ibfk_3;
> > alter table portforwardings drop index uniq_portforwardings0standard_attr_id;
> > alter table portforwardings drop column standard_attr_id;
> > alter table portuplinkstatuspropagation alter column  
> > propagate_uplink_status set default 0;
> > alter table quotas drop index uniq_quotas0project_id0resource;
> > alter table securitygroups drop constraint CONSTRAINT_1;
> > alter table securitygroups drop column stateful;
> > alter table securitygrouprules drop constraint securitygrouprules_ibfk_4;
> > alter table securitygrouprules drop column remote_address_group_id;
> > alter table subnetpools alter column shared drop default;
> > alter table subnets drop constraint CONSTRAINT_1;
> > alter table subnets drop column in_use;
> >
> > update alembic_version set version_num='c613d0b82681' where  
> > version_num='6135a7bd4425';
> >
> > drop table address_associations;
> > drop table addressgrouprbacs;
> > drop table address_groups;
> > drop table addressscoperbacs;
> > drop table dvr_fip_gateway_port_network;
> > drop table network_subnet_lock;
> > drop table ovn_hash_ring;
> > drop table ovn_revision_numbers;
> > drop table portdeviceprofiles;
> > drop table portnumaaffinitypolicies;
> > drop table subnet_dns_publish_fixed_ips;
> > drop table subnetpoolrbacs;
> >
> >
> > And everything is fine again.
> >
> > Greg.
> 
> 
> 
> 
> 


-- 
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: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230418/e88a2f00/attachment.sig>

From michal.arbet at ultimum.io  Tue Apr 18 13:16:08 2023
From: michal.arbet at ultimum.io (Michal Arbet)
Date: Tue, 18 Apr 2023 15:16:08 +0200
Subject: [heat][magnum][tacker] Future of SoftwareDeployment support
In-Reply-To: <6396cae4-9afd-b823-525f-90690d8c29d7@ardc.edu.au>
References: <CAL_crJTB_D+Y+LVRs2qNindh8e1Pk=aK2EEx7SP09eSFZDRB5g@mail.gmail.com>
 <6396cae4-9afd-b823-525f-90690d8c29d7@ardc.edu.au>
Message-ID: <f72fa847-a6d1-c0a2-29d5-3cbb1df738ac@ultimum.io>

Hi,

Two cycles ? I thought that most of work was implemented by vexxhost ? 
https://github.com/vexxhost/magnum-cluster-api
Do you have reviews somewhere if you are working on ClusterAPI ?


Thanks

On 4/18/23 13:53, Jake Yip wrote:
> HI Takashi,
>
> Sorry I missed replying.
>
> On 30/3/2023 1:46 pm, Takashi Kajinami wrote:
>
>>
>> 1. Magnum
>> It seems SoftwareDeployment is used by k8s_fedora_atomic_v1 driver 
>> but I'm not too sure whether
>> this driver is still supported, because Fedora Atomic was EOLed a 
>> while ago, right ?
>>
>
> No It's still in the main k8s_fedora_coreos_v1 driver. It basically is 
> how everything is set up, so we still depend on this greatly for now.
>
> We are also working on a ClusterAPI driver who will bypass heat 
> altogether. We hope to get it working within two cycles, then we can 
> remove k8s_fedora_coreos_v1 together, possibly within another two cycles.
>
> Thanks!
>
> Regards
> Jake
>
-- 
Michal Arbet
Openstack Engineer

Ultimum Technologies a.s.
Na Po???? 1047/26, 11000 Praha 1
Czech Republic

+420 604 228 897
michal.arbet at ultimum.io
_https://ultimum.io_

LinkedIn <https://www.linkedin.com/company/ultimum-technologies>?| 
Twitter <https://twitter.com/ultimumtech>?| Facebook 
<https://www.facebook.com/ultimumtechnologies/timeline>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230418/8b1b9131/attachment.htm>

From jamesleong123098 at gmail.com  Tue Apr 18 13:38:32 2023
From: jamesleong123098 at gmail.com (James Leong)
Date: Tue, 18 Apr 2023 08:38:32 -0500
Subject: [Horizon]: allow user to access calendar on horizon
In-Reply-To: <CA+ny2syMZBuFntWC-Ew-pc-1hf-JOb5D0Mv9R894P7J51iZ3YA@mail.gmail.com>
References: <CA+_ZFmHVNN3QtNkM3ipDCDhbP71wCXekc3vE2p=Bjc5nDg0KNg@mail.gmail.com>
 <CA+ny2syMZBuFntWC-Ew-pc-1hf-JOb5D0Mv9R894P7J51iZ3YA@mail.gmail.com>
Message-ID: <CA+_ZFmHQK_MVUU5-eQEWvBSx+PO3DDE+g5rZD6oboxxi0kckTw@mail.gmail.com>

Thanks for your help. It works on my side after changing the policy.

Best
James

On Tue, 18 Apr 2023, 3:02 am Pierre Riteau, <pierre at stackhpc.com> wrote:

> Hi James,
>
> This is documented in the blazar-dashboard docs at
> https://docs.openstack.org/blazar-dashboard/latest/calendar.html:
>
> In order to be able to view the calendar, a user needs permission for
> blazar:oshosts:get and blazar:oshosts:get_allocations.
>
>
> You need to customise the Blazar policy.yaml file to allow these calls for
> any member. It would look like this:
>
> /etc/kolla/config/blazar/policy.yaml:
>
> # Policies required to access the host reservation calendar
> "blazar:oshosts:get": ""
> "blazar:oshosts:get_allocations": ""
>
> Best wishes,
> Pierre Riteau (priteau)
>
> PS: You should have used [blazar] as a tag, I only found your message by
> accident.
>
> On Mon, 13 Mar 2023 at 04:40, James Leong <jamesleong123098 at gmail.com>
> wrote:
>
>> Hi all,
>> I am using kolla-ansible for OpenStack deployment in the yoga version. Is
>> it possible to allow the user (member role) to view the calendar graph
>> under the reservation tab (lease)? Currently, only the admin will be able
>> to view the calendar graph with all the reserved leases. However, a user
>> with other roles cannot load the calendar information. On the dashboard, I
>> saw it displayed " Unable to load reservations." When I look into the log
>> file, I get the below error message.
>>
>> "blazarclient.exception.BlazarClientException: ERROR: Policy doesn't
>> allow blazar:oshosts:get to be performed."
>>
>> Is there a way to allow the policy?
>>
>> Thanks for your help.
>> James
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230418/ea5ea872/attachment-0001.htm>

From amy at demarco.com  Tue Apr 18 13:53:01 2023
From: amy at demarco.com (Amy Marrich)
Date: Tue, 18 Apr 2023 08:53:01 -0500
Subject: RDO Antelope Released
Message-ID: <CAFs83QoChvQ4qGbdDyBQuLUs6k5424KfqfoAjRj2NiRQAKQAcw@mail.gmail.com>

The RDO community is pleased to announce the general availability of the
RDO build for OpenStack 2023.1 Antelope for RPM-based distributions, CentOS
Stream and Red Hat Enterprise Linux. RDO is suitable for building private,
public, and hybrid clouds. Antelope is the 27th release from the OpenStack
project, which is the work of more than 1,000 contributors from around the
world.

The release is already available for CentOS Stream 9 on the CentOS mirror
network in:

http://mirror.stream.centos.org/SIGs/9-stream/cloud/x86_64/openstack-antelope/

The RDO community project curates, packages, builds, tests and maintains a
complete OpenStack component set for RHEL and CentOS Stream and is a member
of the CentOS Cloud Infrastructure SIG. The Cloud Infrastructure SIG
focuses on delivering a great user experience for CentOS users looking to
build and maintain their own on-premise, public or hybrid clouds.

All work on RDO and on the downstream release, Red Hat OpenStack Platform,
is 100% open source, with all code changes going upstream first.

The highlights of the broader upstream OpenStack project may be read via
https://releases.openstack.org/antelope/highlights.html but here are some
highlights:

   - The continuation of SRBAC and FIPS to make OpenStack a more secure
   platform across various services, along with additional support in images.
   - Additional drivers and features for Block Storage to support more
   technologies from vendors such as Dell, Hitachi and NetApp, among others.
   - DNS Zones that can now be shared with other tenants (projects)
   allowing them to create and manage recordsets within the Zone.
   - Networking port forwarding was added to the dashboard for Floating IPs.
   - Additional networking features to support OVN.
   - Compute now allows PCI devices to be scheduled via the Placement API
   and power consumption can be managed for dedicated CPUs.
   - Load balancing now allows users to enable cpu-pinning.
   - Community testing of compatibility between non-adjacent upstream
   versions.

OpenStack Antelope is the first release marked as Skip Level Upgrade
Release Process or SLURP. According to this model (
https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adjustment.html)
this means that upgrades will be supported between these (SLURP) releases,
in addition to between adjacent major releases.

*TripleO removal in the RDO Antelope release:* During the Antelope cycle,
The TripleO team communicated the decision of abandoning the development of
the project and deprecating the master branches. According to that upstream
decision, TripleO packages have been removed from the RDO distribution and
will not be included in the Antelope release.

*Contributors* During the Zed cycle, we saw the following new RDO
contributors:

   - Adrian Fusco Arnejo
   - Bhagyashri Shewale
   - Eduardo Olivares
   - Elvira Garcia Ruiz
   - Enrique Vallesp?
   - Jason Paroly
   - Juan Badia Payno
   - Karthik Sundaravel
   - Roberto Alfieri
   - Tom Weininger

Welcome to all of you and Thank You So Much for participating! But we
wouldn?t want to overlook anyone.

A super massive Thank You to all *52* contributors who participated in
producing this release. This list includes commits to rdo-packages,
rdo-infra, and rdo-website repositories:

   - Adrian Fusco Arnejo
   - Alan Pevec
   - Alfredo Moralejo Alonso
   - Amol Kahat
   - Amy Marrich
   - Ananya Banerjee
   - Artom Lifshitz
   - Arx Cruz
   - Bhagyashri Shewale
   - C?dric Jeanneret
   - Chandan Kumar
   - Daniel Pawlik
   - Dariusz Smigiel
   - Dmitry Tantsur
   - Douglas Viroel
   - Eduardo Olivares
   - Elvira Garcia Ruiz
   - Emma Foley
   - Eric Harney
   - Enrique Vallesp?
   - Fabien Boucher
   - Harald Jensas
   - Jakob Meng
   - Jason Paroly
   - Jesse Pretorius
   - Ji?? Podiv?n
   - Joel Capitao
   - Juan Badia Payno
   - Julia Kreger
   - Karolina Kula
   - Karthik Sundaravel
   - Leif Madsen
   - Luigi Toscano
   - Luis Tomas Bolivar
   - Marios Andreou
   - Martin Kopec
   - Matthias Runge
   - Matthieu Huin
   - Nicolas Hicher
   - Pooja Jadhav
   - Rabi Mishra
   - Riccardo Pittau
   - Roberto Alfieri
   - Ronelle Landy
   - Sandeep Yadav
   - Sean Mooney
   - Slawomir Kaplonski
   - Steve Baker
   - Takashi Kajinami
   - Tobias Urdin
   - Tom Weininger
   - Yatin Karel

*The Next Release Cycle*

At the end of one release, focus shifts immediately to the next release i.e
Bobcat.

*Get Started*

To spin up a proof of concept cloud, quickly, and on limited hardware, try
an All-In-One Packstack installation. You can run RDO on a single node to
get a feel for how it works.

Finally, for those that don?t have any hardware or physical resources,
there?s the OpenStack Global Passport Program. This is a collaborative
effort between OpenStack public cloud providers to let you experience the
freedom, performance and interoperability of open source infrastructure.
You can quickly and easily gain access to OpenStack infrastructure via
trial programs from participating OpenStack public cloud providers around
the world.

*Get Help*

The RDO Project has our users at lists.rdoproject.org for RDO-specific users
and operators. For more developer-oriented content we recommend joining the
dev at lists.rdoproject.org mailing list. Remember to post a brief
introduction about yourself and your RDO story. The mailing lists archives
are all available at https://mail.rdoproject.org. You can also find
extensive documentation on RDOproject.org.

The #rdo channel on OFTC IRC is also an excellent place to find and give
help.

We also welcome comments and requests on the CentOS devel mailing list and
the CentOS IRC channels (#centos, #centos-cloud, and #centos-devel in
Libera.Chat network), however we have a more focused audience within the
RDO venues.

*Get Involved*

To get involved in the OpenStack RPM packaging effort, check out the RDO
contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO
packaging documentation. Join us in #rdo on the OFTC IRC network and follow
us on Twitter @RDOCommunity. You can also find us on Facebook and YouTube.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230418/4fe19ad5/attachment.htm>

From ishii.vanou at fujitsu.com  Tue Apr 18 12:42:46 2023
From: ishii.vanou at fujitsu.com (Vanou Ishii (Fujitsu))
Date: Tue, 18 Apr 2023 12:42:46 +0000
Subject: [security-sig] Ask base recommendation for handling vulnerability
 which affects both OpenStack code and vendor code
Message-ID: <OSZPR01MB9599850FA8E075D2A1D3647AE89D9@OSZPR01MB9599.jpnprd01.prod.outlook.com>

Hi OpenStack community,

I?m working on OpenStack project under my employee company.
In OpenStack, few of projects (e.g. Cinder and Ironic) uses vendor supplied library in it.
This means vendor-neutral base code of project is hosted under OpenStack project repository
but vendor hardware specific logic is delegated to vendor library which is called by base code
and is maintained by each hardware vendor under their repository.

In the past, I faced situation to handle vulnerability in which cause of vulnerability is in
vendor library but, to handle vulnerability, both OpenStack code and vendor library code
should be modified.
To handle this, I consulted community member and asked them to coordinate to fix vulnerability
in private way (i.e. review patch and prepare commit in not public but private as usual security
handling manner). However member are not willing to working on together because cause of
vulnerability is in vendor provided library.
I felt it?s better for community to, at least, be open to working on such vulnerability because that policy
may benefit community. So I think it?s better to include policy in VMT document[1] like
?Community is encouraged to make effort to be open to handling vulnerability in which both
OpenStack community code and vendor provided code should be modified?.

How do you think about this?

Regards,
Vanou Ishii

[1] https://security.openstack.org/vmt-process.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230418/ca1b8ab2/attachment-0001.htm>

From fungi at yuggoth.org  Tue Apr 18 14:45:37 2023
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 18 Apr 2023 14:45:37 +0000
Subject: [security-sig] Ask base recommendation for handling
 vulnerability which affects both OpenStack code and vendor code
In-Reply-To: <OSZPR01MB9599850FA8E075D2A1D3647AE89D9@OSZPR01MB9599.jpnprd01.prod.outlook.com>
References: <OSZPR01MB9599850FA8E075D2A1D3647AE89D9@OSZPR01MB9599.jpnprd01.prod.outlook.com>
Message-ID: <20230418144537.mbm4rf33nqwm2d6r@yuggoth.org>

[I'm Cc'ing you since you don't appear to be subscribed to
openstack-discuss, but please reply to the list rather than to me
directly.]

On 2023-04-18 12:42:46 +0000 (+0000), Vanou Ishii (Fujitsu) wrote:
[...]
> In the past, I faced situation to handle vulnerability in which
> cause of vulnerability is in vendor library but, to handle
> vulnerability, both OpenStack code and vendor library code should
> be modified. To handle this, I consulted community member and
> asked them to coordinate to fix vulnerability in private way (i.e.
> review patch and prepare commit in not public but private as usual
> security handling manner). However member are not willing to
> working on together because cause of vulnerability is in vendor
> provided library. I felt it?s better for community to, at least,
> be open to working on such vulnerability because that policy may
> benefit community. So I think it?s better to include policy in VMT
> document[1] like ?Community is encouraged to make effort to be
> open to handling vulnerability in which both OpenStack community
> code and vendor provided code should be modified?.
> 
> How do you think about this?
[...]

I think it depends a great deal on the specifics of the bug and the
proposed solution. OpenStack has backport policies which attempt to
avoid introducing regressions or disruptive behavior changes in
stable branches, so there are limits as to what can be changed
through the backporting process. For fixing in the version of
OpenStack services under development (currently 2023.2 "bobcat"),
there is more leniency but it's still up to the core reviewers of
that project as to what sorts of solutions they're willing to
incorporate into their software in order to cater to changes in
externally-developed device drivers.

It sounds like you have a security vulnerability in a device driver,
and fixing it will also require some changes to an OpenStack
service, is that correct? If so, follow the recommended reporting
process[*] ideally opening a bug in Launchpad or creating a story in
StoryBoard depending on where that project's defect tracking is
managed. If the affected repository is not officially overseen[**]
by the OpenStack Vulnerability Management Team, you can still
explicitly subscribe them (~openstack-vuln-mgmt in Launchpad or
openstack-security in StoryBoard) and we'll try to assist with
coordination on a best effort basis.

[*] https://security.openstack.org/#how-to-report-security-issues-to-openstack
[**] https://security.openstack.org/repos-overseen.html
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230418/7861003f/attachment.sig>

From eblock at nde.ag  Tue Apr 18 18:15:20 2023
From: eblock at nde.ag (Eugen Block)
Date: Tue, 18 Apr 2023 18:15:20 +0000
Subject: [neutron] [kolla-ansible] alembic mismatch, schema differences
In-Reply-To: <1892258.J3ZZrq5oHq@p1>
References: <d7cae712-bf0c-9144-38cb-ad8fe61f6d54@pawsey.org.au>
 <532a6f17-2cda-112e-1744-4c377b8d843c@pawsey.org.au>
 <20230418113712.Horde.8KfiDAn_9ZqPTQsOnQwwFHu@webmail.nde.ag>
 <1892258.J3ZZrq5oHq@p1>
Message-ID: <20230418181520.Horde.fRysM0Vk_XEwKegcXXv9rmY@webmail.nde.ag>

Yeah, thanks for the confirmation, I agree.

Zitat von Slawek Kaplonski <skaplons at redhat.com>:

> Hi,
>
> Dnia wtorek, 18 kwietnia 2023 13:37:12 CEST Eugen Block pisze:
>> Hi, I'm glad you worked that out. But one thing I'm wondering since
>> I'm not familiar with kolla (as I'm stating repeatedly), why does the
>> compute node have the capabilities to manipulate the neutron database?
>> Is that by design?
>
> It shouldn't. Only neutron-server should have access to the DB.
>
>> We have our own deployment mechanism on baremetal
>> and there's no "connection =..." string available on compute nodes.
>> Maybe I misunderstood something, but I find it strange that such a
>> thing could happen that easily.
>>
>> Thanks,
>> Eugen
>>
>> Zitat von Gregory Orange <gregory.orange at pawsey.org.au>:
>>
>> > Solution: Manually revert the database schema changes.
>> >
>> > We found that `neutron-db-manage downgrade` has been unsupported for
>> > quite some time, so that avenue was closed to us. So, we restored
>> > backups of before and after to some temporary mariadb servers, to
>> > look at and compare the data. In the end this is how we reverted it
>> > (mysql < revert_wallaby_schema.sql):
>> >
>> > use neutron
>> >
>> > alter table address_scopes alter column shared drop default;
>> > alter table meteringlabelrules drop column source_ip_prefix;
>> > alter table meteringlabelrules drop column destination_ip_prefix;
>> > alter table ml2_vlan_allocations drop constraint
>> > check_ml2_vlan_allocations0vlan_id;
>> > alter table networkdhcpagentbindings drop index
>> > uniq_network_dhcp_agent_binding0network_id0binding_index0;
>> > alter table networkdhcpagentbindings drop column binding_index;
>> > alter table networks modify mtu int(11) null default null;
>> > alter table portforwardings drop constraint portforwardings_ibfk_3;
>> > alter table portforwardings drop index  
>> uniq_portforwardings0standard_attr_id;
>> > alter table portforwardings drop column standard_attr_id;
>> > alter table portuplinkstatuspropagation alter column
>> > propagate_uplink_status set default 0;
>> > alter table quotas drop index uniq_quotas0project_id0resource;
>> > alter table securitygroups drop constraint CONSTRAINT_1;
>> > alter table securitygroups drop column stateful;
>> > alter table securitygrouprules drop constraint securitygrouprules_ibfk_4;
>> > alter table securitygrouprules drop column remote_address_group_id;
>> > alter table subnetpools alter column shared drop default;
>> > alter table subnets drop constraint CONSTRAINT_1;
>> > alter table subnets drop column in_use;
>> >
>> > update alembic_version set version_num='c613d0b82681' where
>> > version_num='6135a7bd4425';
>> >
>> > drop table address_associations;
>> > drop table addressgrouprbacs;
>> > drop table address_groups;
>> > drop table addressscoperbacs;
>> > drop table dvr_fip_gateway_port_network;
>> > drop table network_subnet_lock;
>> > drop table ovn_hash_ring;
>> > drop table ovn_revision_numbers;
>> > drop table portdeviceprofiles;
>> > drop table portnumaaffinitypolicies;
>> > drop table subnet_dns_publish_fixed_ips;
>> > drop table subnetpoolrbacs;
>> >
>> >
>> > And everything is fine again.
>> >
>> > Greg.
>>
>>
>>
>>
>>
>
>
> --
> Slawek Kaplonski
> Principal Software Engineer
> Red Hat





From noonedeadpunk at gmail.com  Tue Apr 18 19:00:07 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Tue, 18 Apr 2023 21:00:07 +0200
Subject: [openstack-ansible] Proposing Neil Hanlon for core reviewer
Message-ID: <CAPd_6AuUW5bN=rfdOJ1yK98b_BYsSvADHBt=iSQZYBiZnUT_CQ@mail.gmail.com>

Hi everyone,

I'm pleased to propose Neil Hanlon as OpenStack-Ansible Core Reviewer.
Neil has helped us a lot lately with maintenance of RHEL-like distros
-
both CentOS Stream and Rocky Linux, and basically has brought in
support for the last one.

Neil is present at meetings and always is responsive in IRC. At the
same time they were providing useful reviews lately [1]

If there are no objections, I will add Neil to the team on 25th of
April 2023. Until then, please feel free to provide your
feedback/opinions on the matter.

[1] https://www.stackalytics.io/report/contribution?module=openstackansible-group&project_type=openstack&days=120


From amy at demarco.com  Tue Apr 18 19:34:41 2023
From: amy at demarco.com (Amy Marrich)
Date: Tue, 18 Apr 2023 14:34:41 -0500
Subject: [openstack-ansible] Proposing Neil Hanlon for core reviewer
In-Reply-To: <CAPd_6AuUW5bN=rfdOJ1yK98b_BYsSvADHBt=iSQZYBiZnUT_CQ@mail.gmail.com>
References: <CAPd_6AuUW5bN=rfdOJ1yK98b_BYsSvADHBt=iSQZYBiZnUT_CQ@mail.gmail.com>
Message-ID: <CAFs83QoSLhNRP4W1Q0amUP3ERto5PJV5eTvfJRpf9XeVKD0dDg@mail.gmail.com>

+2 from me

On Tue, Apr 18, 2023 at 2:05?PM Dmitriy Rabotyagov
<noonedeadpunk at gmail.com> wrote:
>
> Hi everyone,
>
> I'm pleased to propose Neil Hanlon as OpenStack-Ansible Core Reviewer.
> Neil has helped us a lot lately with maintenance of RHEL-like distros
> -
> both CentOS Stream and Rocky Linux, and basically has brought in
> support for the last one.
>
> Neil is present at meetings and always is responsive in IRC. At the
> same time they were providing useful reviews lately [1]
>
> If there are no objections, I will add Neil to the team on 25th of
> April 2023. Until then, please feel free to provide your
> feedback/opinions on the matter.
>
> [1] https://www.stackalytics.io/report/contribution?module=openstackansible-group&project_type=openstack&days=120
>


From damian at dabrowski.cloud  Tue Apr 18 20:33:15 2023
From: damian at dabrowski.cloud (Damian Dabrowski)
Date: Tue, 18 Apr 2023 22:33:15 +0200
Subject: [openstack-ansible] Proposing Neil Hanlon for core reviewer
In-Reply-To: <CAFs83QoSLhNRP4W1Q0amUP3ERto5PJV5eTvfJRpf9XeVKD0dDg@mail.gmail.com>
References: <CAPd_6AuUW5bN=rfdOJ1yK98b_BYsSvADHBt=iSQZYBiZnUT_CQ@mail.gmail.com>
 <CAFs83QoSLhNRP4W1Q0amUP3ERto5PJV5eTvfJRpf9XeVKD0dDg@mail.gmail.com>
Message-ID: <CA+gc-7wGrzWY=fZ_tAKyiSxoy1VOci9N5s5SGt41Dou6TReL3g@mail.gmail.com>

+2

On Tue, Apr 18, 2023 at 9:34?PM Amy Marrich <amy at demarco.com> wrote:

> +2 from me
>
> On Tue, Apr 18, 2023 at 2:05?PM Dmitriy Rabotyagov
> <noonedeadpunk at gmail.com> wrote:
> >
> > Hi everyone,
> >
> > I'm pleased to propose Neil Hanlon as OpenStack-Ansible Core Reviewer.
> > Neil has helped us a lot lately with maintenance of RHEL-like distros
> > -
> > both CentOS Stream and Rocky Linux, and basically has brought in
> > support for the last one.
> >
> > Neil is present at meetings and always is responsive in IRC. At the
> > same time they were providing useful reviews lately [1]
> >
> > If there are no objections, I will add Neil to the team on 25th of
> > April 2023. Until then, please feel free to provide your
> > feedback/opinions on the matter.
> >
> > [1]
> https://www.stackalytics.io/report/contribution?module=openstackansible-group&project_type=openstack&days=120
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230418/ab09a126/attachment.htm>

From satish.txt at gmail.com  Wed Apr 19 01:07:56 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Tue, 18 Apr 2023 21:07:56 -0400
Subject: [openstack-ansible] Proposing Neil Hanlon for core reviewer
In-Reply-To: <CA+gc-7wGrzWY=fZ_tAKyiSxoy1VOci9N5s5SGt41Dou6TReL3g@mail.gmail.com>
References: <CAPd_6AuUW5bN=rfdOJ1yK98b_BYsSvADHBt=iSQZYBiZnUT_CQ@mail.gmail.com>
 <CAFs83QoSLhNRP4W1Q0amUP3ERto5PJV5eTvfJRpf9XeVKD0dDg@mail.gmail.com>
 <CA+gc-7wGrzWY=fZ_tAKyiSxoy1VOci9N5s5SGt41Dou6TReL3g@mail.gmail.com>
Message-ID: <CAPgF-fpwag_p4k4PYkPoqqqH8wes07um2sVSsxz7gjSHWoEZQQ@mail.gmail.com>

+2

On Tue, Apr 18, 2023 at 4:35?PM Damian Dabrowski <damian at dabrowski.cloud>
wrote:

> +2
>
> On Tue, Apr 18, 2023 at 9:34?PM Amy Marrich <amy at demarco.com> wrote:
>
>> +2 from me
>>
>> On Tue, Apr 18, 2023 at 2:05?PM Dmitriy Rabotyagov
>> <noonedeadpunk at gmail.com> wrote:
>> >
>> > Hi everyone,
>> >
>> > I'm pleased to propose Neil Hanlon as OpenStack-Ansible Core Reviewer.
>> > Neil has helped us a lot lately with maintenance of RHEL-like distros
>> > -
>> > both CentOS Stream and Rocky Linux, and basically has brought in
>> > support for the last one.
>> >
>> > Neil is present at meetings and always is responsive in IRC. At the
>> > same time they were providing useful reviews lately [1]
>> >
>> > If there are no objections, I will add Neil to the team on 25th of
>> > April 2023. Until then, please feel free to provide your
>> > feedback/opinions on the matter.
>> >
>> > [1]
>> https://www.stackalytics.io/report/contribution?module=openstackansible-group&project_type=openstack&days=120
>> >
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230418/0c904df6/attachment-0001.htm>

From satish.txt at gmail.com  Wed Apr 19 01:41:30 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Tue, 18 Apr 2023 21:41:30 -0400
Subject: [kolla-ansible] bootstrap-server docker version question
In-Reply-To: <cd945940-7169-9cfd-a03e-d7a6089d4a30@pawsey.org.au>
References: <CAPgF-frS7FQnQ=QsdWf1qpWJ2mai2NOUPa2GijLvmmp8ovYY2Q@mail.gmail.com>
 <CAE_fguDnG386zvfu6gcwUkKhZg11+UEECOdE-ZWAnYbsr5Y+ug@mail.gmail.com>
 <CAPgF-fovY_b2CtuP=6KJyH3qhn4iffZRS8M0skQj2dRnAL5rOg@mail.gmail.com>
 <cd945940-7169-9cfd-a03e-d7a6089d4a30@pawsey.org.au>
Message-ID: <CAPgF-fqJ=Zu-r3ABYNpUetPEzMPg0kOLCckus-bBeiVEb1mY5g@mail.gmail.com>

Thanks, I'll check it out.

On Tue, Apr 4, 2023 at 11:09?AM Gregory Orange <gregory.orange at pawsey.org.au>
wrote:

> On 4/4/23 22:37, Satish Patel wrote:
> > How do i tell bootstrap-server to don't use docker-ce and just use
> > docker.io <http://docker.io>? are there any setting to tell?
>
> A quick grep (well, ack) through /usr/local/share/kolla-ansible showed
> me this:
>
> ansible/roles/baremetal/defaults/main.yml
> 10:docker_apt_package: "docker-ce"
> 19:docker_yum_package: "docker-ce"
>
> So I would say try changing that variable in your globals.yml and see if
> that does the trick.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230418/90980d44/attachment.htm>

From 1031576740 at qq.com  Wed Apr 19 02:56:20 2023
From: 1031576740 at qq.com (=?utf-8?B?QmVpcWkgWmhhbmc=?=)
Date: Wed, 19 Apr 2023 10:56:20 +0800
Subject: Survey Invitation on Code Snippets in Code Reviews
Message-ID: <tencent_FEE872E15F92084EDD370EF3BE3B56DAE208@qq.com>

Dear OpenStack Contributors,


In the code review process, reviewers and developers engage in asynchronous online discussions to exchange information with each other, aiming at promoting the acceptence of proposed code changes. During the discussions, code snippets might be served as a way to meet the information needs of reviewers or developers (e.g., reviewers may make a suggestion by providing code snippet). However, little is known about the practices of providing code snippets in code reviews (e.g., what is the intention behind providing code snippet). To this end, we plan to conduct this survey to gain knowledge and experience from the perspective of developers in industry. We would greatly appreciate your help with our research by filling out the questionnaire below:


Our questionnaire contains 4 close-ended questions and 2 open-ended questions, which may take about 3-5 minutes. The link of the questionnaire (hosted at Google Forms): https://forms.gle/nrLaZXQUq4QMS3bu6


Thank you very much for your participation!
 
Best regards,
Beiqi Zhang (on Behalf of the Team)
Wuhan University, China
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230419/8a0943c9/attachment.htm>

From thuvh87 at gmail.com  Wed Apr 19 04:35:30 2023
From: thuvh87 at gmail.com (Hoai-Thu Vuong)
Date: Wed, 19 Apr 2023 11:35:30 +0700
Subject: [kolla-ansible] bootstrap-server docker version question
In-Reply-To: <CAPgF-fqJ=Zu-r3ABYNpUetPEzMPg0kOLCckus-bBeiVEb1mY5g@mail.gmail.com>
References: <CAPgF-frS7FQnQ=QsdWf1qpWJ2mai2NOUPa2GijLvmmp8ovYY2Q@mail.gmail.com>
 <CAE_fguDnG386zvfu6gcwUkKhZg11+UEECOdE-ZWAnYbsr5Y+ug@mail.gmail.com>
 <CAPgF-fovY_b2CtuP=6KJyH3qhn4iffZRS8M0skQj2dRnAL5rOg@mail.gmail.com>
 <cd945940-7169-9cfd-a03e-d7a6089d4a30@pawsey.org.au>
 <CAPgF-fqJ=Zu-r3ABYNpUetPEzMPg0kOLCckus-bBeiVEb1mY5g@mail.gmail.com>
Message-ID: <CABBkmgqkPDTddREs1H=q+v6EJvNA4zHfXJkKsz7A8e4WLRja7g@mail.gmail.com>

I think you can pin version of docker

https://opendev.org/openstack/ansible-collection-kolla/src/commit/0e3dbd7b266ecc634e34b91815b822dacba0887c/roles/docker/defaults/main.yml#L13

On Wed, Apr 19, 2023 at 8:49?AM Satish Patel <satish.txt at gmail.com> wrote:

> Thanks, I'll check it out.
>
> On Tue, Apr 4, 2023 at 11:09?AM Gregory Orange <
> gregory.orange at pawsey.org.au> wrote:
>
>> On 4/4/23 22:37, Satish Patel wrote:
>> > How do i tell bootstrap-server to don't use docker-ce and just use
>> > docker.io <http://docker.io>? are there any setting to tell?
>>
>> A quick grep (well, ack) through /usr/local/share/kolla-ansible showed
>> me this:
>>
>> ansible/roles/baremetal/defaults/main.yml
>> 10:docker_apt_package: "docker-ce"
>> 19:docker_yum_package: "docker-ce"
>>
>> So I would say try changing that variable in your globals.yml and see if
>> that does the trick.
>>
>

-- 
Thu.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230419/597ddbbe/attachment.htm>

From pdeore at redhat.com  Wed Apr 19 10:54:34 2023
From: pdeore at redhat.com (Pranali Deore)
Date: Wed, 19 Apr 2023 16:24:34 +0530
Subject: [Glance] Bobcat PTG summary
In-Reply-To: <CADkbuWgP2GbyNg5rCativbFYhuHRzd_Y4T_NgigQ=ApAMneh=w@mail.gmail.com>
References: <CALOt+SS5hstT+hRb7T3hSovCFFnB_P9WKsYF+_DwMC+56_9LEA@mail.gmail.com>
 <40D3DB03-3D45-4C08-9B80-CE7F2D47F2F7@gmail.com>
 <CADkbuWgP2GbyNg5rCativbFYhuHRzd_Y4T_NgigQ=ApAMneh=w@mail.gmail.com>
Message-ID: <CADkbuWidTbvRsfMO8MDEwj06YQWtX+hNGVm6i6ksSfEKaZvsVg@mail.gmail.com>

On Mon, Apr 10, 2023 at 6:52?PM Pranali Deore <pdeore at redhat.com> wrote:

>
>
> On Wed, Apr 5, 2023 at 12:57?PM Artem Goncharov <artem.goncharov at gmail.com>
> wrote:
>
>> Hi,
>>
>> Feedback from SDK/OSC team on one item that got my attention
>>
>>
>> # Bridge gap between Glance client and OSC
>> Last cycle we have prepared the list of missing commands [2] and started
>> submitting patches to implement the same. Our biggest hurdle at the moment
>> is lack of reviews from the osc team (which has only one/two cores). Glance
>> PTL is going to communicate with TC/existing core(s) of OSC whether they
>> can add any glance core to the team so that we can prioritize our work and
>> get reviews immediately. This cycle we are planning to complete this work.
>>
>>
>> At the moment SDK/CLI core group is having 27 members, which should be
>> already a sign. We have an agreement with all teams and add certain members
>> into the core group to be able to review changes for their corresponding
>> services (with a limitation that they are NOT by default setting W+1).
>> You have noticed pretty correct - at the moment there is not so much
>> activity on our side due to lack of reviewers. But that is not blocking any
>> change once there is a +2 review from the service representatives. That
>> means that if Glance team opens change and another Glance team member
>> leaves +2 those changes are having absolutely different priority and we
>> normally approving them fast (unless there is something preventing that).
>> What we want to prevent is that every team is pulling project into their
>> direction breaking certain rules or conventions.
>>
>> Please provide me the list of members you would like to get SDK/CLI core
>> rights and I would gladly add them (one more time - no workflow+1)
>>
>> Artem
>>
>>
> Hi Artem,
>
> We have the discussion in the team and Abhishek & Cyril are ready to join
> the SDK/CLI core group to speed up the reviews on glance related changes.
> Please provide the SDK/CLI core rights to @Abhishek Kekane
> <akekane at redhat.com> & @Cyril Roelandt <cyril at redhat.com>.
>
>
Hi Artem,

Any updates on adding the glance team members to SDK/CLI core group?
Kindly please let us know once you add them.


Thanks,
Pranali


> Thanks,
> Pranali Deore
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230419/341466ca/attachment-0001.htm>

From senrique at redhat.com  Wed Apr 19 11:54:50 2023
From: senrique at redhat.com (Sofia Enriquez)
Date: Wed, 19 Apr 2023 12:54:50 +0100
Subject: [cinder] Bug Report | Bugs from 2023-04-12 to 2023-04-19
Message-ID: <CANtmtpF-MKgoQcAOdKV5LXopA5EEiPxVdk-YZiSjBmT3AoLQsA@mail.gmail.com>

Hello Argonauts,

I've recently updated a personal script
<https://github.com/enriquetaso/launchpad-bug-reporter> I've been using to
fetch bugs from Launchpad. I wanted to share it with you all in case anyone
has ideas on how to make it better or wants to contribute to the project.
Your suggestions and input would be super valuable!

*Medium*

   - Dell Compellent:- DSM is unable to fetch WWNs from mapping personality
   objects which are stored with lowercase letters in SC.
   <https://bugs.launchpad.net/cinder/+bug/2016840>
      - *Status*: The bug report says *In Progress *but I couldn't find any
      patch on Gerrit.
   -  NVMe-oF connector doesn't create the hostid
   <https://bugs.launchpad.net/os-brick/+bug/2016029>
      - Status: Fix proposed to branch: master
      <https://review.opendev.org/c/openstack/os-brick/+/880222>.


   - [rbac] list, show and show_default volume type command response does
   not contain "os-volume-type-access:is_public" property when using reader
   user <https://bugs.launchpad.net/cinder/+bug/2016402>
   - *Status*: The reporter updated the bug report with references to the
      Tempest test.


*Incomplete*

   - Cleanup of backups fails for non-existing volume
   <https://bugs.launchpad.net/cinder/+bug/2016138>.
      - *Status*: Waiting on reporter update.


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: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230419/273b07cc/attachment.htm>

From satish.txt at gmail.com  Wed Apr 19 12:40:39 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Wed, 19 Apr 2023 08:40:39 -0400
Subject: [kolla-ansible] bootstrap-server docker version question
In-Reply-To: <CABBkmgqkPDTddREs1H=q+v6EJvNA4zHfXJkKsz7A8e4WLRja7g@mail.gmail.com>
References: <CAPgF-frS7FQnQ=QsdWf1qpWJ2mai2NOUPa2GijLvmmp8ovYY2Q@mail.gmail.com>
 <CAE_fguDnG386zvfu6gcwUkKhZg11+UEECOdE-ZWAnYbsr5Y+ug@mail.gmail.com>
 <CAPgF-fovY_b2CtuP=6KJyH3qhn4iffZRS8M0skQj2dRnAL5rOg@mail.gmail.com>
 <cd945940-7169-9cfd-a03e-d7a6089d4a30@pawsey.org.au>
 <CAPgF-fqJ=Zu-r3ABYNpUetPEzMPg0kOLCckus-bBeiVEb1mY5g@mail.gmail.com>
 <CABBkmgqkPDTddREs1H=q+v6EJvNA4zHfXJkKsz7A8e4WLRja7g@mail.gmail.com>
Message-ID: <CAPgF-foGMYVahUSPUPOvwx7KQ2dSH9PmEdMikKCWEa-g79qB2A@mail.gmail.com>

Thanks, I'll check it out.

One more question related bootstrap, I have local docker registry and I do
create daemon.json file on each nodes when I add compute nodes. Can
bootstrap has option to add registry configuration during preparing new
nodes?

$ cat /etc/docker/daemon.json

{

    "bridge": "none",

    "insecure-registries": [

        "docker-reg.example.com:4000"

    ],

    "ip-forward": false,

    "iptables": false,

    "log-opts": {

        "max-file": "5",

        "max-size": "50m"

    }

}

On Wed, Apr 19, 2023 at 12:35 AM Hoai-Thu Vuong <thuvh87 at gmail.com> wrote:

> I think you can pin version of docker
>
>
> https://opendev.org/openstack/ansible-collection-kolla/src/commit/0e3dbd7b266ecc634e34b91815b822dacba0887c/roles/docker/defaults/main.yml#L13
>
> On Wed, Apr 19, 2023 at 8:49?AM Satish Patel <satish.txt at gmail.com> wrote:
>
>> Thanks, I'll check it out.
>>
>> On Tue, Apr 4, 2023 at 11:09?AM Gregory Orange <
>> gregory.orange at pawsey.org.au> wrote:
>>
>>> On 4/4/23 22:37, Satish Patel wrote:
>>> > How do i tell bootstrap-server to don't use docker-ce and just use
>>> > docker.io <http://docker.io>? are there any setting to tell?
>>>
>>> A quick grep (well, ack) through /usr/local/share/kolla-ansible showed
>>> me this:
>>>
>>> ansible/roles/baremetal/defaults/main.yml
>>> 10:docker_apt_package: "docker-ce"
>>> 19:docker_yum_package: "docker-ce"
>>>
>>> So I would say try changing that variable in your globals.yml and see if
>>> that does the trick.
>>>
>>
>
> --
> Thu.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230419/73d64f61/attachment.htm>

From kieske at osism.tech  Wed Apr 19 12:54:35 2023
From: kieske at osism.tech (Sven Kieske)
Date: Wed, 19 Apr 2023 14:54:35 +0200
Subject: [kolla-ansible][glance][yoga] Does glance support cinder-nfs as
 backend?
In-Reply-To: <CAJV_UBA=LjYYgG=P-OKo_mQFvbD4zDDEZx3KD5Oeymive=WWjA@mail.gmail.com>
References: <CAJV_UBDXyggV--mpzePiNvjSFEtYNUwSsJm0zsTfRoGGQfwxrw@mail.gmail.com>
 <CAJV_UBA=LjYYgG=P-OKo_mQFvbD4zDDEZx3KD5Oeymive=WWjA@mail.gmail.com>
Message-ID: <e6620d1432398798a782acf835b6b68e346bb0a9.camel@osism.tech>

I added glance to the topic, because this is really more a question
about glance than about kolla-ansible.

HTH

-- 
Sven Kieske
Senior Cloud Engineer

Mail: kieske at osism.tech
Web: https://osism.tech

OSISM GmbH
Teckstra?e 62 / 70190 Stuttgart / Deutschland

Gesch?ftsf?hrer: Christian Berendt
Unternehmenssitz: Stuttgart
Amtsgericht: Stuttgart, HRB 756139


Am Montag, dem 17.04.2023 um 15:42 +0100 schrieb wodel youchi:
> Any ideas?
> 
> Le lun. 17 avr. 2023 ? 09:22, wodel youchi <wodel.youchi at gmail.com> a
> ?crit :
> 
> > Hi,
> > 
> > The openstak documentation says that glance supports cinder as
> > backend,
> > but it does not exclude any backend used by cinder itself.
> > 
> > I'm having trouble configuring glance to use a cinder backend which
> > is
> > backed by an nfs share.
> > 
> > Is this configuration supported?
> > 
> > First, the rootwrap was missing, after adding it, I faced the lack
> > of
> > privileges, which was corrected by starting the glance-api
> > container in
> > privileged mode and finally I am facing a non existing filter
> > error.
> > 
> > Glance is trying to mount the nfs share to use it!!! Which I don't
> > understand , why mount a share that is already mounted by cinder
> > which
> > glance is supposed to use as an intermediary!!!?
> > 
> > When I push an image I get this error:
> > 
> > Stderr: '/var/lib/kolla/venv/bin/glance-rootwrap: Unauthorized
> > command:
> > mount -t nfs 20.1.0.32:/kolla_nfs
> > /var/lib/glance/mnt/nfs/f6f6b4ee42b4f3522a75f422887010ad2c47f8624
> > f97bf3623b13014f22186b7 (no filter matched)\n'
> > 
> > 
> > Regards.
> > 


From acozyurt at gmail.com  Wed Apr 19 13:01:14 2023
From: acozyurt at gmail.com (=?UTF-8?Q?Can_=C3=96zyurt?=)
Date: Wed, 19 Apr 2023 16:01:14 +0300
Subject: [kolla-ansible] bootstrap-server docker version question
In-Reply-To: <CAPgF-foGMYVahUSPUPOvwx7KQ2dSH9PmEdMikKCWEa-g79qB2A@mail.gmail.com>
References: <CAPgF-frS7FQnQ=QsdWf1qpWJ2mai2NOUPa2GijLvmmp8ovYY2Q@mail.gmail.com>
 <CAE_fguDnG386zvfu6gcwUkKhZg11+UEECOdE-ZWAnYbsr5Y+ug@mail.gmail.com>
 <CAPgF-fovY_b2CtuP=6KJyH3qhn4iffZRS8M0skQj2dRnAL5rOg@mail.gmail.com>
 <cd945940-7169-9cfd-a03e-d7a6089d4a30@pawsey.org.au>
 <CAPgF-fqJ=Zu-r3ABYNpUetPEzMPg0kOLCckus-bBeiVEb1mY5g@mail.gmail.com>
 <CABBkmgqkPDTddREs1H=q+v6EJvNA4zHfXJkKsz7A8e4WLRja7g@mail.gmail.com>
 <CAPgF-foGMYVahUSPUPOvwx7KQ2dSH9PmEdMikKCWEa-g79qB2A@mail.gmail.com>
Message-ID: <CAMf4N73K9CC3rU2mKXFmzMExbmVZPWQzpRGs23H7Yz9fY9XpPw@mail.gmail.com>

Yes, there is ##Docker Options## section in globals.yml. You can find
the sample configs there as commented out.

On Wed, 19 Apr 2023 at 15:42, Satish Patel <satish.txt at gmail.com> wrote:
>
> Thanks, I'll check it out.
>
> One more question related bootstrap, I have local docker registry and I do create daemon.json file on each nodes when I add compute nodes. Can bootstrap has option to add registry configuration during preparing new nodes?
>
> $ cat /etc/docker/daemon.json
>
> {
>
>     "bridge": "none",
>
>     "insecure-registries": [
>
>         "docker-reg.example.com:4000"
>
>     ],
>
>     "ip-forward": false,
>
>     "iptables": false,
>
>     "log-opts": {
>
>         "max-file": "5",
>
>         "max-size": "50m"
>
>     }
>
> }
>
>
> On Wed, Apr 19, 2023 at 12:35 AM Hoai-Thu Vuong <thuvh87 at gmail.com> wrote:
>>
>> I think you can pin version of docker
>>
>> https://opendev.org/openstack/ansible-collection-kolla/src/commit/0e3dbd7b266ecc634e34b91815b822dacba0887c/roles/docker/defaults/main.yml#L13
>>
>> On Wed, Apr 19, 2023 at 8:49?AM Satish Patel <satish.txt at gmail.com> wrote:
>>>
>>> Thanks, I'll check it out.
>>>
>>> On Tue, Apr 4, 2023 at 11:09?AM Gregory Orange <gregory.orange at pawsey.org.au> wrote:
>>>>
>>>> On 4/4/23 22:37, Satish Patel wrote:
>>>> > How do i tell bootstrap-server to don't use docker-ce and just use
>>>> > docker.io <http://docker.io>? are there any setting to tell?
>>>>
>>>> A quick grep (well, ack) through /usr/local/share/kolla-ansible showed
>>>> me this:
>>>>
>>>> ansible/roles/baremetal/defaults/main.yml
>>>> 10:docker_apt_package: "docker-ce"
>>>> 19:docker_yum_package: "docker-ce"
>>>>
>>>> So I would say try changing that variable in your globals.yml and see if
>>>> that does the trick.
>>
>>
>>
>> --
>> Thu.


From thuvh87 at gmail.com  Wed Apr 19 13:15:39 2023
From: thuvh87 at gmail.com (Hoai-Thu Vuong)
Date: Wed, 19 Apr 2023 20:15:39 +0700
Subject: [kolla-ansible] bootstrap-server docker version question
In-Reply-To: <CAPgF-foGMYVahUSPUPOvwx7KQ2dSH9PmEdMikKCWEa-g79qB2A@mail.gmail.com>
References: <CAPgF-frS7FQnQ=QsdWf1qpWJ2mai2NOUPa2GijLvmmp8ovYY2Q@mail.gmail.com>
 <CAE_fguDnG386zvfu6gcwUkKhZg11+UEECOdE-ZWAnYbsr5Y+ug@mail.gmail.com>
 <CAPgF-fovY_b2CtuP=6KJyH3qhn4iffZRS8M0skQj2dRnAL5rOg@mail.gmail.com>
 <cd945940-7169-9cfd-a03e-d7a6089d4a30@pawsey.org.au>
 <CAPgF-fqJ=Zu-r3ABYNpUetPEzMPg0kOLCckus-bBeiVEb1mY5g@mail.gmail.com>
 <CABBkmgqkPDTddREs1H=q+v6EJvNA4zHfXJkKsz7A8e4WLRja7g@mail.gmail.com>
 <CAPgF-foGMYVahUSPUPOvwx7KQ2dSH9PmEdMikKCWEa-g79qB2A@mail.gmail.com>
Message-ID: <CABBkmgpva4ad7OP1xSC26-HVdvnMkXSriUo3T2nccLfrnEVF0A@mail.gmail.com>

I think you can edit this variable: docker_registry (noted that docker
config is created for you, check in tasks directory with this variable).
https://opendev.org/openstack/ansible-collection-kolla/src/commit/0e3dbd7b266ecc634e34b91815b822dacba0887c/roles/docker/defaults/main.yml#L52

On Wed, Apr 19, 2023, 19:40 Satish Patel <satish.txt at gmail.com> wrote:

> Thanks, I'll check it out.
>
> One more question related bootstrap, I have local docker registry and I do
> create daemon.json file on each nodes when I add compute nodes. Can
> bootstrap has option to add registry configuration during preparing new
> nodes?
>
> $ cat /etc/docker/daemon.json
>
> {
>
>     "bridge": "none",
>
>     "insecure-registries": [
>
>         "docker-reg.example.com:4000"
>
>     ],
>
>     "ip-forward": false,
>
>     "iptables": false,
>
>     "log-opts": {
>
>         "max-file": "5",
>
>         "max-size": "50m"
>
>     }
>
> }
>
> On Wed, Apr 19, 2023 at 12:35 AM Hoai-Thu Vuong <thuvh87 at gmail.com> wrote:
>
>> I think you can pin version of docker
>>
>>
>> https://opendev.org/openstack/ansible-collection-kolla/src/commit/0e3dbd7b266ecc634e34b91815b822dacba0887c/roles/docker/defaults/main.yml#L13
>>
>> On Wed, Apr 19, 2023 at 8:49?AM Satish Patel <satish.txt at gmail.com>
>> wrote:
>>
>>> Thanks, I'll check it out.
>>>
>>> On Tue, Apr 4, 2023 at 11:09?AM Gregory Orange <
>>> gregory.orange at pawsey.org.au> wrote:
>>>
>>>> On 4/4/23 22:37, Satish Patel wrote:
>>>> > How do i tell bootstrap-server to don't use docker-ce and just use
>>>> > docker.io <http://docker.io>? are there any setting to tell?
>>>>
>>>> A quick grep (well, ack) through /usr/local/share/kolla-ansible showed
>>>> me this:
>>>>
>>>> ansible/roles/baremetal/defaults/main.yml
>>>> 10:docker_apt_package: "docker-ce"
>>>> 19:docker_yum_package: "docker-ce"
>>>>
>>>> So I would say try changing that variable in your globals.yml and see
>>>> if
>>>> that does the trick.
>>>>
>>>
>>
>> --
>> Thu.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230419/2be31833/attachment-0001.htm>

From kristin at openinfra.dev  Wed Apr 19 14:10:47 2023
From: kristin at openinfra.dev (Kristin Barrientos)
Date: Wed, 19 Apr 2023 09:10:47 -0500
Subject: openstack-discuss Digest, Vol 54, Issue 85
In-Reply-To: <mailman.3.1681732802.2746191.openstack-discuss@lists.openstack.org>
References: <mailman.3.1681732802.2746191.openstack-discuss@lists.openstack.org>
Message-ID: <C781581C-050D-4444-B218-B20FADA5C2A0@openinfra.dev>

Hi everyone,

There seems to have been an error regarding the time for the next Large Scale SIG meeting. It was supposed to be 14 UTC, not 15 UTC. Is there anyone that is able to join the meeting now?

So sorry about that.

Please join now if you can! 
 
Thanks, 

Kristin Barrientos
Marketing Coordinator 
OpenInfra Foundation




> On Apr 17, 2023, at 7:00 AM, openstack-discuss-request at lists.openstack.org wrote:
> 
> Send openstack-discuss mailing list submissions to
> 	openstack-discuss at lists.openstack.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
> 
> or, via email, send a message with subject or body 'help' to
> 	openstack-discuss-request at lists.openstack.org
> 
> You can reach the person managing the list at
> 	openstack-discuss-owner at lists.openstack.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openstack-discuss digest..."
> 
> 
> Today's Topics:
> 
>   1. [largescale-sig] Next meeting: April 19, 15utc (Thierry Carrez)
>   2. Re: [largescale-sig] Next meeting: April 19, 15utc
>      (Thierry Carrez)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 17 Apr 2023 13:14:19 +0200
> From: Thierry Carrez <thierry at openstack.org>
> To: "openstack-discuss at lists.openstack.org"
> 	<openstack-discuss at lists.openstack.org>
> Subject: [largescale-sig] Next meeting: April 19, 15utc
> Message-ID: <25b05623-92e2-f01e-70c3-5aac26a4f256 at openstack.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> Hi everyone,
> 
> The Large Scale SIG will be meeting this Wednesday in 
> #openstack-operators on OFTC IRC, at 15UTC, our EU+US-friendly time.
> 
> You can doublecheck how that UTC time translates locally at:
> https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230322T14
> 
> Feel free to add topics to the agenda:
> https://etherpad.opendev.org/p/large-scale-sig-meeting
> 
> Regards,
> 
> -- 
> Thierry Carrez
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 17 Apr 2023 13:15:26 +0200
> From: Thierry Carrez <thierry at openstack.org>
> To: "openstack-discuss at lists.openstack.org"
> 	<openstack-discuss at lists.openstack.org>
> Subject: Re: [largescale-sig] Next meeting: April 19, 15utc
> Message-ID: <90db3bfb-b6b4-c0ef-6b9f-8593c7dcc324 at openstack.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> Thierry Carrez wrote:
>> You can doublecheck how that UTC time translates locally at:
>> https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230322T14
> 
> Wrong URL, try out this one instead:
> https://www.timeanddate.com/worldclock/fixedtime.html?iso=20230419T15
> 
> Sorry about that.
> 
> -- 
> Thierry]
> 
> 
> 
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> openstack-discuss mailing list
> openstack-discuss at lists.openstack.org
> 
> 
> ------------------------------
> 
> End of openstack-discuss Digest, Vol 54, Issue 85
> *************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230419/08402e5d/attachment.htm>

From hanguangyu2 at gmail.com  Wed Apr 19 14:26:06 2023
From: hanguangyu2 at gmail.com (=?UTF-8?B?6Z+p5YWJ5a6H?=)
Date: Wed, 19 Apr 2023 14:26:06 +0000
Subject: [neutron] questions about bond and port ip
Message-ID: <CAOirdiVvAOPyWB8SNvf+oWmH8HmCD6vG64oo20-qQBzTAux+Kw@mail.gmail.com>

Hello,

I have a victoria cluster. I am a bit perplexed about OpenStack
networking and was wondering if you could enlighten me on the topic.

1. bond
When configuring bond interfaces (bond0/1/2/3) in an OpenStack
instance, can I follow the same steps as I would on a physical
machine? Are there any particular considerations to keep in mind?
Also, when it comes to switch configuration, do I configure virtual
machine switches directly or are there specific OpenStack interfaces
to use?

2.
`openstack port create --network net1 --no-fixed-ip port_net1`
I was able to obtain a port with an ip_allocation value of "none"
using the above command. I noticed that the ip_allocation value can be
set to "none", "deferred", or "immediate". Is there a CLI interface to
modify the ip_allocation value of a port, for example, changing "none"
to "deferred"? Alternatively, what is the recommended method to make
this change?

3.
Is it possible for users to set IP addresses within an instance
system? For example, if I create an instance without an IP address, is
there a mechanism that allows me to set an IP address within the
instance system, or can I only modify the port bindings or switch
ports externally to change the IP address of an instance?

Thank you for your attention to this matter.
Best regards,
Han Guangyu


From ralonsoh at redhat.com  Wed Apr 19 16:09:41 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Wed, 19 Apr 2023 18:09:41 +0200
Subject: [neutron] questions about bond and port ip
In-Reply-To: <CAOirdiVvAOPyWB8SNvf+oWmH8HmCD6vG64oo20-qQBzTAux+Kw@mail.gmail.com>
References: <CAOirdiVvAOPyWB8SNvf+oWmH8HmCD6vG64oo20-qQBzTAux+Kw@mail.gmail.com>
Message-ID: <CAECr9X43LbHi9t2f4Mv6eukABfYbxWCzTWfsz98BVi4=d9Ym8Q@mail.gmail.com>

Hello Han:

If you are trying to create a bond, you'll need to perform that operation
inside the VM. The problem, at least for ML2/OVS and ML2/OVN, is that the
traffic egressing from this interface won't match the MAC address
configured. This traffic will be dropped because of the ARP spoofing rules
unless you disable "port_security_enabled". I'm not sure (I've never
tested) if LACP mode will work in these backends. In any case, what is the
user case? Isn't it better to make this bond in the host interfaces? [1]

The IP allocation of a port is something that cannot be manually set. This
value will depend on the DHCP configuration:

   - If the network has a subnet, the Neutron server will try to assign an
   IP. If you don't have routed provider network, the value will be "immediate"
   - For routed provider networks (that I don't think is your case), the
   value will be "deferred" and will depend on the host the port is bound.
   - If you choose --no-fixed-ip when creating the port, the value will be
   "none".


The functionality you are looking for was implemented in Nova in [2], *but
this is available in Yoga, not in Victoria*. This feature allows you to
create an IP-less port and use it to spawn a VM.

Regards.

[1]
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/advanced_overcloud_customization/assembly_network-interface-bonding
[2]https://review.opendev.org/c/openstack/nova/+/669411


On Wed, Apr 19, 2023 at 4:27?PM ??? <hanguangyu2 at gmail.com> wrote:

> Hello,
>
> I have a victoria cluster. I am a bit perplexed about OpenStack
> networking and was wondering if you could enlighten me on the topic.
>
> 1. bond
> When configuring bond interfaces (bond0/1/2/3) in an OpenStack
> instance, can I follow the same steps as I would on a physical
> machine? Are there any particular considerations to keep in mind?
> Also, when it comes to switch configuration, do I configure virtual
> machine switches directly or are there specific OpenStack interfaces
> to use?
>
> 2.
> `openstack port create --network net1 --no-fixed-ip port_net1`
> I was able to obtain a port with an ip_allocation value of "none"
> using the above command. I noticed that the ip_allocation value can be
> set to "none", "deferred", or "immediate". Is there a CLI interface to
> modify the ip_allocation value of a port, for example, changing "none"
> to "deferred"? Alternatively, what is the recommended method to make
> this change?
>
> 3.
> Is it possible for users to set IP addresses within an instance
> system? For example, if I create an instance without an IP address, is
> there a mechanism that allows me to set an IP address within the
> instance system, or can I only modify the port bindings or switch
> ports externally to change the IP address of an instance?
>
> Thank you for your attention to this matter.
> Best regards,
> Han Guangyu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230419/2d2873c7/attachment.htm>

From eblock at nde.ag  Wed Apr 19 16:58:21 2023
From: eblock at nde.ag (Eugen Block)
Date: Wed, 19 Apr 2023 16:58:21 +0000
Subject: [neutron] questions about bond and port ip
In-Reply-To: <CAECr9X43LbHi9t2f4Mv6eukABfYbxWCzTWfsz98BVi4=d9Ym8Q@mail.gmail.com>
References: <CAOirdiVvAOPyWB8SNvf+oWmH8HmCD6vG64oo20-qQBzTAux+Kw@mail.gmail.com>
 <CAECr9X43LbHi9t2f4Mv6eukABfYbxWCzTWfsz98BVi4=d9Ym8Q@mail.gmail.com>
Message-ID: <20230419165821.Horde.Ky80NH2_UWHtVLLlkNlkSnR@webmail.nde.ag>

Hi,

you should look into trunks [1]. They work quite well and cover my  
use-case. But as already mentioned you need to switch off port  
security for the trunk.

Regards,
Eugen

[1] https://docs.openstack.org/neutron/pike/admin/config-trunking.html

Zitat von Rodolfo Alonso Hernandez <ralonsoh at redhat.com>:

> Hello Han:
>
> If you are trying to create a bond, you'll need to perform that operation
> inside the VM. The problem, at least for ML2/OVS and ML2/OVN, is that the
> traffic egressing from this interface won't match the MAC address
> configured. This traffic will be dropped because of the ARP spoofing rules
> unless you disable "port_security_enabled". I'm not sure (I've never
> tested) if LACP mode will work in these backends. In any case, what is the
> user case? Isn't it better to make this bond in the host interfaces? [1]
>
> The IP allocation of a port is something that cannot be manually set. This
> value will depend on the DHCP configuration:
>
>    - If the network has a subnet, the Neutron server will try to assign an
>    IP. If you don't have routed provider network, the value will be  
> "immediate"
>    - For routed provider networks (that I don't think is your case), the
>    value will be "deferred" and will depend on the host the port is bound.
>    - If you choose --no-fixed-ip when creating the port, the value will be
>    "none".
>
>
> The functionality you are looking for was implemented in Nova in [2], *but
> this is available in Yoga, not in Victoria*. This feature allows you to
> create an IP-less port and use it to spawn a VM.
>
> Regards.
>
> [1]
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/advanced_overcloud_customization/assembly_network-interface-bonding
> [2]https://review.opendev.org/c/openstack/nova/+/669411
>
>
> On Wed, Apr 19, 2023 at 4:27?PM ??? <hanguangyu2 at gmail.com> wrote:
>
>> Hello,
>>
>> I have a victoria cluster. I am a bit perplexed about OpenStack
>> networking and was wondering if you could enlighten me on the topic.
>>
>> 1. bond
>> When configuring bond interfaces (bond0/1/2/3) in an OpenStack
>> instance, can I follow the same steps as I would on a physical
>> machine? Are there any particular considerations to keep in mind?
>> Also, when it comes to switch configuration, do I configure virtual
>> machine switches directly or are there specific OpenStack interfaces
>> to use?
>>
>> 2.
>> `openstack port create --network net1 --no-fixed-ip port_net1`
>> I was able to obtain a port with an ip_allocation value of "none"
>> using the above command. I noticed that the ip_allocation value can be
>> set to "none", "deferred", or "immediate". Is there a CLI interface to
>> modify the ip_allocation value of a port, for example, changing "none"
>> to "deferred"? Alternatively, what is the recommended method to make
>> this change?
>>
>> 3.
>> Is it possible for users to set IP addresses within an instance
>> system? For example, if I create an instance without an IP address, is
>> there a mechanism that allows me to set an IP address within the
>> instance system, or can I only modify the port bindings or switch
>> ports externally to change the IP address of an instance?
>>
>> Thank you for your attention to this matter.
>> Best regards,
>> Han Guangyu
>>
>>





From ishii.vanou at fujitsu.com  Wed Apr 19 14:18:32 2023
From: ishii.vanou at fujitsu.com (Vanou Ishii (Fujitsu))
Date: Wed, 19 Apr 2023 14:18:32 +0000
Subject: [security-sig] Ask base recommendation for handling vulnerability
 which affects both OpenStack code and vendor code
In-Reply-To: <20230418144537.mbm4rf33nqwm2d6r@yuggoth.org>
References: <OSZPR01MB9599850FA8E075D2A1D3647AE89D9@OSZPR01MB9599.jpnprd01.prod.outlook.com>
 <20230418144537.mbm4rf33nqwm2d6r@yuggoth.org>
Message-ID: <OSZPR01MB95994765F42FC4E2328024D1E8629@OSZPR01MB9599.jpnprd01.prod.outlook.com>

Hi Jeremy,

Thanks for reply. I have already fixed that vulnerability and fix patch was merged into OpenStack project. In that case, patch review was held in public even that patch was related to vulnerability fix.
What I would like to say is following:

"I think it's good idea to add policy to OpenStack security document[1]. That policy is OpenStack community is encouraged to be open to handle vulnerability which needs fix both in OpenStack code and vendor library code if that vendor library takes good role in that OpenStack project."

Above idea comes because when I consulted OpenStack project member about vulnerability fix whose root cause is in vendor library but both OpenStack code and vendor library, member was not open to collaborate working on vulnerability.
Is such addition to OpenStack security document reasonable? I ask this because there was discussion, in my colleague team, about there is no explicit description to openness to working on such situation in OpenStack doc.

Regards,
Vanou

[1] https://security.openstack.org

-----Original Message-----
From: Jeremy Stanley <fungi at yuggoth.org> 
Sent: Tuesday, April 18, 2023 11:46 PM
To: openstack-discuss at lists.openstack.org
Cc: Ishii, Vanou/?? ?? <ishii.vanou at fujitsu.com>
Subject: Re: [security-sig] Ask base recommendation for handling vulnerability which affects both OpenStack code and vendor code

[I'm Cc'ing you since you don't appear to be subscribed to openstack-discuss, but please reply to the list rather than to me directly.]

On 2023-04-18 12:42:46 +0000 (+0000), Vanou Ishii (Fujitsu) wrote:
[...]
> In the past, I faced situation to handle vulnerability in which cause 
> of vulnerability is in vendor library but, to handle vulnerability, 
> both OpenStack code and vendor library code should be modified. To 
> handle this, I consulted community member and asked them to coordinate 
> to fix vulnerability in private way (i.e.
> review patch and prepare commit in not public but private as usual 
> security handling manner). However member are not willing to working 
> on together because cause of vulnerability is in vendor provided 
> library. I felt it?s better for community to, at least, be open to 
> working on such vulnerability because that policy may benefit 
> community. So I think it?s better to include policy in VMT document[1] 
> like ?Community is encouraged to make effort to be open to handling 
> vulnerability in which both OpenStack community code and vendor 
> provided code should be modified?.
> 
> How do you think about this?
[...]

I think it depends a great deal on the specifics of the bug and the proposed solution. OpenStack has backport policies which attempt to avoid introducing regressions or disruptive behavior changes in stable branches, so there are limits as to what can be changed through the backporting process. For fixing in the version of OpenStack services under development (currently 2023.2 "bobcat"), there is more leniency but it's still up to the core reviewers of that project as to what sorts of solutions they're willing to incorporate into their software in order to cater to changes in externally-developed device drivers.

It sounds like you have a security vulnerability in a device driver, and fixing it will also require some changes to an OpenStack service, is that correct? If so, follow the recommended reporting process[*] ideally opening a bug in Launchpad or creating a story in StoryBoard depending on where that project's defect tracking is managed. If the affected repository is not officially overseen[**] by the OpenStack Vulnerability Management Team, you can still explicitly subscribe them (~openstack-vuln-mgmt in Launchpad or openstack-security in StoryBoard) and we'll try to assist with coordination on a best effort basis.

[*] https://security.openstack.org/#how-to-report-security-issues-to-openstack
[**] https://security.openstack.org/repos-overseen.html
--
Jeremy Stanley


From fungi at yuggoth.org  Wed Apr 19 18:18:45 2023
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 19 Apr 2023 18:18:45 +0000
Subject: [security-sig] Ask base recommendation for handling
 vulnerability which affects both OpenStack code and vendor code
In-Reply-To: <OSZPR01MB95994765F42FC4E2328024D1E8629@OSZPR01MB9599.jpnprd01.prod.outlook.com>
References: <OSZPR01MB9599850FA8E075D2A1D3647AE89D9@OSZPR01MB9599.jpnprd01.prod.outlook.com>
 <20230418144537.mbm4rf33nqwm2d6r@yuggoth.org>
 <OSZPR01MB95994765F42FC4E2328024D1E8629@OSZPR01MB9599.jpnprd01.prod.outlook.com>
Message-ID: <20230419181844.xgj5j2ii3gtfjvjp@yuggoth.org>

On 2023-04-19 14:18:32 +0000 (+0000), Vanou Ishii (Fujitsu) wrote:
[...]
> I have already fixed that vulnerability and fix patch was merged
> into OpenStack project. In that case, patch review was held in
> public even that patch was related to vulnerability fix.

Note that it's preferable for most vulnerability fixes to be
developed in public, since private embargoes are extremely
inconvenient and taxing on our community. Only the most severe of
vulnerabilities need secrecy and rigorous coordinated disclosure.

I like to refer folks to this article on "the hidden costs of
embargoes" which does a great job of explaining the delicate balance
we try to strike in deciding which process to follow for each bug:
https://access.redhat.com/blogs/766093/posts/1976653

> What I would like to say is following:
> 
> "I think it's good idea to add policy to OpenStack security
> document[1]. That policy is OpenStack community is encouraged to
> be open to handle vulnerability which needs fix both in OpenStack
> code and vendor library code if that vendor library takes good
> role in that OpenStack project."
> 
> Above idea comes because when I consulted OpenStack project member
> about vulnerability fix whose root cause is in vendor library but
> both OpenStack code and vendor library, member was not open to
> collaborate working on vulnerability.
> 
> Is such addition to OpenStack security document reasonable? I ask
> this because there was discussion, in my colleague team, about
> there is no explicit description to openness to working on such
> situation in OpenStack doc.
[...]

As a community we expect our projects to be open to collaboration
with everyone; it's one of our founding principles:

https://governance.openstack.org/tc/reference/principles.html#contribution-is-our-currency

Security vulnerabilities are just bugs, and our projects are
expected to be open to collaborating with members of the community
on bug fixes. However, individual contributors decide their
priorities and get to choose what they spend their time working on.
Just because one contributor wasn't interested in collaborating on a
specific bug fix doesn't mean others won't assist. Reaching out to
project leadership when you have concerns over prioritization is the
most effective way to make progress.

This doesn't really seem to me to have anything to do with security
vulnerabilities, and so I don't think that adding collaboration
recommendations to our vulnerability reporting guidelines or to our
vulnerability coordination process document would make sense. These
principles apply everywhere, not just to security fixes.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230419/47e3670a/attachment.sig>

From juliaashleykreger at gmail.com  Wed Apr 19 19:26:57 2023
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Wed, 19 Apr 2023 12:26:57 -0700
Subject: [security-sig] Ask base recommendation for handling vulnerability
 which affects both OpenStack code and vendor code
In-Reply-To: <OSZPR01MB95994765F42FC4E2328024D1E8629@OSZPR01MB9599.jpnprd01.prod.outlook.com>
References: <OSZPR01MB9599850FA8E075D2A1D3647AE89D9@OSZPR01MB9599.jpnprd01.prod.outlook.com>
 <20230418144537.mbm4rf33nqwm2d6r@yuggoth.org>
 <OSZPR01MB95994765F42FC4E2328024D1E8629@OSZPR01MB9599.jpnprd01.prod.outlook.com>
Message-ID: <CAF7gwdgfW3fbKcj2pZ35RERFxhxNUke8CBwAD4YvXyyToBvsoA@mail.gmail.com>

On Wed, Apr 19, 2023 at 10:14?AM Vanou Ishii (Fujitsu) <
ishii.vanou at fujitsu.com> wrote:

> Hi Jeremy,
>
> Thanks for reply. I have already fixed that vulnerability and fix patch
> was merged into OpenStack project. In that case, patch review was held in
> public even that patch was related to vulnerability fix.
> What I would like to say is following:
>
> "I think it's good idea to add policy to OpenStack security document[1].
> That policy is OpenStack community is encouraged to be open to handle
> vulnerability which needs fix both in OpenStack code and vendor library
> code if that vendor library takes good role in that OpenStack project."
>
> Above idea comes because when I consulted OpenStack project member about
> vulnerability fix whose root cause is in vendor library but both OpenStack
> code and vendor library, member was not open to collaborate working on
> vulnerability.
> Is such addition to OpenStack security document reasonable? I ask this
> because there was discussion, in my colleague team, about there is no
> explicit description to openness to working on such situation in OpenStack
> doc.
>
>
I believe there is a difference of impression as well, which can impact
perception of openness. An explicit statement or policy document
requirement won't fix the impression or perception which may result.

There can be agreement to fix an issue, but disagreement on the process or
the constraints. For example, in OpenStack, we have specific policies to
handle the behavior of backports in terms of breaking changes. It means for
such fixes, we have a very narrow path we can walk, and the more consensus
and community buy-in we generate in that process makes everyone's job
easier. Yet, the original proposed fix may not meet the policy requirements
and usage constraints, and that push back can leave an impression of
refusal to collaborate, which is not the intent. The key is in a dialog.

Dialog is often required and it requires mutual compromise and respect for
boundaries. Depending on a project's context, it may be that what is being
asked of them is bordering on a feature because an end user may still need
to make a choice and the prior insecure path may still need to be
supported. This all can leave differing impressions, which is definitely
difficult to navigate and only compounded with competing demands on
contributor's time.

-Julia

Regards,
> Vanou
>
> [1] https://security.openstack.org
>
> -----Original Message-----
> From: Jeremy Stanley <fungi at yuggoth.org>
> Sent: Tuesday, April 18, 2023 11:46 PM
> To: openstack-discuss at lists.openstack.org
> Cc: Ishii, Vanou/?? ?? <ishii.vanou at fujitsu.com>
> Subject: Re: [security-sig] Ask base recommendation for handling
> vulnerability which affects both OpenStack code and vendor code
>
> [I'm Cc'ing you since you don't appear to be subscribed to
> openstack-discuss, but please reply to the list rather than to me directly.]
>
> On 2023-04-18 12:42:46 +0000 (+0000), Vanou Ishii (Fujitsu) wrote:
> [...]
> > In the past, I faced situation to handle vulnerability in which cause
> > of vulnerability is in vendor library but, to handle vulnerability,
> > both OpenStack code and vendor library code should be modified. To
> > handle this, I consulted community member and asked them to coordinate
> > to fix vulnerability in private way (i.e.
> > review patch and prepare commit in not public but private as usual
> > security handling manner). However member are not willing to working
> > on together because cause of vulnerability is in vendor provided
> > library. I felt it?s better for community to, at least, be open to
> > working on such vulnerability because that policy may benefit
> > community. So I think it?s better to include policy in VMT document[1]
> > like ?Community is encouraged to make effort to be open to handling
> > vulnerability in which both OpenStack community code and vendor
> > provided code should be modified?.
> >
> > How do you think about this?
> [...]
>
> I think it depends a great deal on the specifics of the bug and the
> proposed solution. OpenStack has backport policies which attempt to avoid
> introducing regressions or disruptive behavior changes in stable branches,
> so there are limits as to what can be changed through the backporting
> process. For fixing in the version of OpenStack services under development
> (currently 2023.2 "bobcat"), there is more leniency but it's still up to
> the core reviewers of that project as to what sorts of solutions they're
> willing to incorporate into their software in order to cater to changes in
> externally-developed device drivers.
>
> It sounds like you have a security vulnerability in a device driver, and
> fixing it will also require some changes to an OpenStack service, is that
> correct? If so, follow the recommended reporting process[*] ideally opening
> a bug in Launchpad or creating a story in StoryBoard depending on where
> that project's defect tracking is managed. If the affected repository is
> not officially overseen[**] by the OpenStack Vulnerability Management Team,
> you can still explicitly subscribe them (~openstack-vuln-mgmt in Launchpad
> or openstack-security in StoryBoard) and we'll try to assist with
> coordination on a best effort basis.
>
> [*]
> https://security.openstack.org/#how-to-report-security-issues-to-openstack
> [**] https://security.openstack.org/repos-overseen.html
> --
> Jeremy Stanley
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230419/05db0225/attachment-0001.htm>

From ralonsoh at redhat.com  Thu Apr 20 09:12:54 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Thu, 20 Apr 2023 11:12:54 +0200
Subject: [neutron] Neutron drivers meeting
Message-ID: <CAECr9X60V18yQUjfu8NrebK4KumMSEKM5PaakrzFLUGB3YgQXg@mail.gmail.com>

Hello Neutrinos:

Please remember tomorrow we have the drivers meeting at 14UTC. The agenda
is here [1]. We have, so far, a couple of topics to discuss.

See you tomorrow.

[1]https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230420/13e0e20d/attachment.htm>

From artem.goncharov at gmail.com  Thu Apr 20 10:02:43 2023
From: artem.goncharov at gmail.com (Artem Goncharov)
Date: Thu, 20 Apr 2023 12:02:43 +0200
Subject: [Glance] Bobcat PTG summary
In-Reply-To: <CADkbuWidTbvRsfMO8MDEwj06YQWtX+hNGVm6i6ksSfEKaZvsVg@mail.gmail.com>
References: <CALOt+SS5hstT+hRb7T3hSovCFFnB_P9WKsYF+_DwMC+56_9LEA@mail.gmail.com>
 <40D3DB03-3D45-4C08-9B80-CE7F2D47F2F7@gmail.com>
 <CADkbuWgP2GbyNg5rCativbFYhuHRzd_Y4T_NgigQ=ApAMneh=w@mail.gmail.com>
 <CADkbuWidTbvRsfMO8MDEwj06YQWtX+hNGVm6i6ksSfEKaZvsVg@mail.gmail.com>
Message-ID: <29A0D9C9-62CA-469D-8E08-FA13D1E7075C@gmail.com>

Hi,

I have not forgotten and I am on it. However I see that there are too many people in the core group right now from most of which I have not ever a single review. This is becoming a bit too dangerous and I have requested arranging a new group (openstacksdk-service-core and openstackclient-service-core) with only +2 privileges to prevent workflow misuse [1].

Once this is done I will immediately add mentioned members into the group.

In the meanwhile I also wanted to hint that there are currently changes for the glance in openstackclient open (well, only 1 open left) and the people mentioned by you are so far not doing code reviews.

Regards,
Artem

[1] https://review.opendev.org/c/openstack/project-config/+/880933

> On 19. Apr 2023, at 12:54, Pranali Deore <pdeore at redhat.com> wrote:
> 
> 
> 
> On Mon, Apr 10, 2023 at 6:52?PM Pranali Deore <pdeore at redhat.com <mailto:pdeore at redhat.com>> wrote:
>> 
>> 
>> On Wed, Apr 5, 2023 at 12:57?PM Artem Goncharov <artem.goncharov at gmail.com <mailto:artem.goncharov at gmail.com>> wrote:
>>> Hi,
>>> 
>>> Feedback from SDK/OSC team on one item that got my attention
>>> 
>>>> 
>>>> # Bridge gap between Glance client and OSC
>>>> Last cycle we have prepared the list of missing commands [2] and started submitting patches to implement the same. Our biggest hurdle at the moment is lack of reviews from the osc team (which has only one/two cores). Glance PTL is going to communicate with TC/existing core(s) of OSC whether they can add any glance core to the team so that we can prioritize our work and get reviews immediately. This cycle we are planning to complete this work. 
>>>> 
>>> 
>>> At the moment SDK/CLI core group is having 27 members, which should be already a sign. We have an agreement with all teams and add certain members into the core group to be able to review changes for their corresponding services (with a limitation that they are NOT by default setting W+1).
>>> You have noticed pretty correct - at the moment there is not so much activity on our side due to lack of reviewers. But that is not blocking any change once there is a +2 review from the service representatives. That means that if Glance team opens change and another Glance team member leaves +2 those changes are having absolutely different priority and we normally approving them fast (unless there is something preventing that). What we want to prevent is that every team is pulling project into their direction breaking certain rules or conventions.
>>> 
>>> Please provide me the list of members you would like to get SDK/CLI core rights and I would gladly add them (one more time - no workflow+1)
>>> 
>>> Artem
>>> 
>> 
>> Hi Artem,
>> 
>> We have the discussion in the team and Abhishek & Cyril are ready to join the SDK/CLI core group to speed up the reviews on glance related changes.
>> Please provide the SDK/CLI core rights to @Abhishek Kekane <mailto:akekane at redhat.com> & @Cyril Roelandt <mailto:cyril at redhat.com>.
>> 
> 
> Hi Artem,
> 
> Any updates on adding the glance team members to SDK/CLI core group?
> Kindly please let us know once you add them. 
> 
> 
> Thanks,
> Pranali
> 
>> 
>> Thanks,
>> Pranali Deore 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230420/1014e62e/attachment.htm>

From 1148203170 at qq.com  Thu Apr 20 10:13:02 2023
From: 1148203170 at qq.com (=?gb18030?B?3/Xf9d/1?=)
Date: Thu, 20 Apr 2023 18:13:02 +0800
Subject: [nova]qemu-guest-agent Used in openstack 
Message-ID: <tencent_3BA769BFD2F23E133E81736CA43A5EB0D305@qq.com>

Hi,


We discovered the use of qemu-guest-agent in openstack,Set hw_qemu_guest_agent=yes to the metadata parameter on the image.
https://docs.openstack.org/mitaka/config-reference/compute/hypervisor-kvm.html


Meanwhile, the application of qemu-guest-agent in cloud scenarios is investigated. It is found that Qemu-guest-Agent can be used for guest os performance monitoring, snapshot backup, and guest OS-level failover.
But these things can be done in openstack with prometheus and&nbsp; instance backup,There may be some differences between them.


Sorry, I am not familiar with how hw_qemu_guest_agent is used in openstack, and I do not know the operations that can be performed on guest os in openstack by configuring hw_qemu_guest_agent.
Only through qemu official know some of the effects.I want to clarify the use of hw_qemu_guest_agent. Other components of openstack, such as the prometheus service, can be used instead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230420/00e6aa8c/attachment.htm>

From akekane at redhat.com  Thu Apr 20 10:44:21 2023
From: akekane at redhat.com (Abhishek Kekane)
Date: Thu, 20 Apr 2023 16:14:21 +0530
Subject: [Glance] Bobcat PTG summary
In-Reply-To: <29A0D9C9-62CA-469D-8E08-FA13D1E7075C@gmail.com>
References: <CALOt+SS5hstT+hRb7T3hSovCFFnB_P9WKsYF+_DwMC+56_9LEA@mail.gmail.com>
 <40D3DB03-3D45-4C08-9B80-CE7F2D47F2F7@gmail.com>
 <CADkbuWgP2GbyNg5rCativbFYhuHRzd_Y4T_NgigQ=ApAMneh=w@mail.gmail.com>
 <CADkbuWidTbvRsfMO8MDEwj06YQWtX+hNGVm6i6ksSfEKaZvsVg@mail.gmail.com>
 <29A0D9C9-62CA-469D-8E08-FA13D1E7075C@gmail.com>
Message-ID: <CALOt+SSOMin3-c-ddypUM+44MPTwgprtjq-A_p_HuUuwW9a0Rg@mail.gmail.com>

On Thu, Apr 20, 2023 at 3:33?PM Artem Goncharov <artem.goncharov at gmail.com>
wrote:

> Hi,
>
> I have not forgotten and I am on it. However I see that there are too many
> people in the core group right now from most of which I have not ever a
> single review. This is becoming a bit too dangerous and I have requested
> arranging a new group (openstacksdk-service-core and
> openstackclient-service-core) with only +2 privileges to prevent workflow
> misuse [1].
>
> Once this is done I will immediately add mentioned members into the group.
>
> In the meanwhile I also wanted to hint that there are currently changes
> for the glance in openstackclient open (well, only 1 open left) and the
> people mentioned by you are so far not doing code reviews.
>
Hi Artem,

Thanks for pointing it out, the one open is WIP i guess, sorry we didn't
notice it earlier. This PTG we decided to dedicate particular
resources on  reviewing
the glance specific patches. So once new patches are up then you will
definitely find reviews from our side on priority basis.

@Pranali, please make sure when a patch is submitted the owner adds us as a
reviewer to the patches so that we will get immediate notification about
the same.

Thank you,

Abhishek

>
> Regards,
> Artem
>
> [1] https://review.opendev.org/c/openstack/project-config/+/880933
>
> On 19. Apr 2023, at 12:54, Pranali Deore <pdeore at redhat.com> wrote:
>
>
>
> On Mon, Apr 10, 2023 at 6:52?PM Pranali Deore <pdeore at redhat.com> wrote:
>
>>
>>
>> On Wed, Apr 5, 2023 at 12:57?PM Artem Goncharov <
>> artem.goncharov at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> Feedback from SDK/OSC team on one item that got my attention
>>>
>>>
>>> # Bridge gap between Glance client and OSC
>>> Last cycle we have prepared the list of missing commands [2] and started
>>> submitting patches to implement the same. Our biggest hurdle at the moment
>>> is lack of reviews from the osc team (which has only one/two cores). Glance
>>> PTL is going to communicate with TC/existing core(s) of OSC whether they
>>> can add any glance core to the team so that we can prioritize our work and
>>> get reviews immediately. This cycle we are planning to complete this work.
>>>
>>>
>>>
>>> At the moment SDK/CLI core group is having 27 members, which should be
>>> already a sign. We have an agreement with all teams and add certain members
>>> into the core group to be able to review changes for their corresponding
>>> services (with a limitation that they are NOT by default setting W+1).
>>> You have noticed pretty correct - at the moment there is not so much
>>> activity on our side due to lack of reviewers. But that is not blocking any
>>> change once there is a +2 review from the service representatives. That
>>> means that if Glance team opens change and another Glance team member
>>> leaves +2 those changes are having absolutely different priority and we
>>> normally approving them fast (unless there is something preventing that).
>>> What we want to prevent is that every team is pulling project into their
>>> direction breaking certain rules or conventions.
>>>
>>> Please provide me the list of members you would like to get SDK/CLI core
>>> rights and I would gladly add them (one more time - no workflow+1)
>>>
>>> Artem
>>>
>>>
>> Hi Artem,
>>
>> We have the discussion in the team and Abhishek & Cyril are ready to join
>> the SDK/CLI core group to speed up the reviews on glance related changes.
>> Please provide the SDK/CLI core rights to @Abhishek Kekane
>> <akekane at redhat.com> & @Cyril Roelandt <cyril at redhat.com>.
>>
>>
> Hi Artem,
>
> Any updates on adding the glance team members to SDK/CLI core group?
> Kindly please let us know once you add them.
>
>
> Thanks,
> Pranali
>
>
>> Thanks,
>> Pranali Deore
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230420/a5c5bc2a/attachment-0001.htm>

From smooney at redhat.com  Thu Apr 20 11:00:48 2023
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 20 Apr 2023 12:00:48 +0100
Subject: [nova]qemu-guest-agent Used in openstack
In-Reply-To: <tencent_3BA769BFD2F23E133E81736CA43A5EB0D305@qq.com>
References: <tencent_3BA769BFD2F23E133E81736CA43A5EB0D305@qq.com>
Message-ID: <773963adcc9d68e00c04ecf85dab3c438345be0a.camel@redhat.com>

The hw_qemu_guest_agent image property is used to enable the qemu channel (basically a unix socket) use to enabel comunciation
between a "qemu guest agent" there is a default qemu one but other cloud vendor have created there own. i know ovh has one they
maintain for there cloud. the upstream qemu guest agent is not used for monitoring. i belive it can be used to monitor the guest if
you write a custom one but that is not somethign that is directly supported by upstream openstack.

nova only uses it for one thing.
we supprot the generic qemu geusts agent ablity to freeze the guest file system and unfreeze it to take
snapshots without any inflight data writes.

prometheus is not really integrated with openstack at least not in a way that is maintained/supported by
the openstack comunity as an officall project as far as i am aware.
i do not belive there is any interaction between prometheus and the qemu guest agent although there is a libvirt exporter
for prometious so perhaps it has support for interafcting with the qemu agent in some way.

form a nova point of view we just enable the qemu guest agent to fucntion if you have installed it in your guest but we
dont really try to use it to monitor or manage the guest in general beyond the orginal uscase for consitent snapshots.
hopefully that helps.


On Thu, 2023-04-20 at 18:13 +0800, ??? wrote:
> Hi,
> 
> 
> We discovered the use of qemu-guest-agent in openstack,Set hw_qemu_guest_agent=yes to the metadata parameter on the image.
> https://docs.openstack.org/mitaka/config-reference/compute/hypervisor-kvm.html
> 
> 
> Meanwhile, the application of qemu-guest-agent in cloud scenarios is investigated. It is found that Qemu-guest-Agent can be used for guest os performance monitoring, snapshot backup, and guest OS-level failover.
> But these things can be done in openstack with prometheus and&nbsp; instance backup,There may be some differences between them.
> 
> 
> Sorry, I am not familiar with how hw_qemu_guest_agent is used in openstack, and I do not know the operations that can be performed on guest os in openstack by configuring hw_qemu_guest_agent.
> Only through qemu official know some of the effects.I want to clarify the use of hw_qemu_guest_agent. Other components of openstack, such as the prometheus service, can be used instead.



From rdhasman at redhat.com  Thu Apr 20 11:15:24 2023
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Thu, 20 Apr 2023 16:45:24 +0530
Subject: [Glance] Bobcat PTG summary
In-Reply-To: <CALOt+SSOMin3-c-ddypUM+44MPTwgprtjq-A_p_HuUuwW9a0Rg@mail.gmail.com>
References: <CALOt+SS5hstT+hRb7T3hSovCFFnB_P9WKsYF+_DwMC+56_9LEA@mail.gmail.com>
 <40D3DB03-3D45-4C08-9B80-CE7F2D47F2F7@gmail.com>
 <CADkbuWgP2GbyNg5rCativbFYhuHRzd_Y4T_NgigQ=ApAMneh=w@mail.gmail.com>
 <CADkbuWidTbvRsfMO8MDEwj06YQWtX+hNGVm6i6ksSfEKaZvsVg@mail.gmail.com>
 <29A0D9C9-62CA-469D-8E08-FA13D1E7075C@gmail.com>
 <CALOt+SSOMin3-c-ddypUM+44MPTwgprtjq-A_p_HuUuwW9a0Rg@mail.gmail.com>
Message-ID: <CAARK8KQ8a=dHO==QGu837ZE+EjWj79XEwhSN7BpSZU7gTWzFUw@mail.gmail.com>

Hi,

I was discussing this with Stephen last cycle. The general idea we
discussed to review project specific patches was:
1 core from project team to verify the functionality of the patch is as
intended
1 core from SDK team to verify the code follows all the conventions of
SDK/OSC project

This will ensure we are following proper convention (like how a specific
command should be written) and the change
we are adding works as expected (calling the right API, accepting/passing
the right parameters etc)

On a similar note, Cinder team would also like to nominate its team
member(s) for the core position in OSC/SDK.
Last cycle, most (if not all) of my changes were reviewed by Stephen and I
don't want to put more burden on
him for the SDK work I'm planning. :)
Let me know about the feasibility of that request and I can initiate a
discussion in the Cinder upstream meeting for the
interested candidate(s).

Thanks
Rajat Dhasmana

On Thu, Apr 20, 2023 at 4:21?PM Abhishek Kekane <akekane at redhat.com> wrote:

>
>
> On Thu, Apr 20, 2023 at 3:33?PM Artem Goncharov <artem.goncharov at gmail.com>
> wrote:
>
>> Hi,
>>
>> I have not forgotten and I am on it. However I see that there are too
>> many people in the core group right now from most of which I have not ever
>> a single review. This is becoming a bit too dangerous and I have requested
>> arranging a new group (openstacksdk-service-core and
>> openstackclient-service-core) with only +2 privileges to prevent workflow
>> misuse [1].
>>
>> Once this is done I will immediately add mentioned members into the group.
>>
>> In the meanwhile I also wanted to hint that there are currently changes
>> for the glance in openstackclient open (well, only 1 open left) and the
>> people mentioned by you are so far not doing code reviews.
>>
> Hi Artem,
>
> Thanks for pointing it out, the one open is WIP i guess, sorry we didn't
> notice it earlier. This PTG we decided to dedicate particular resources on
>  reviewing the glance specific patches. So once new patches are up then
> you will definitely find reviews from our side on priority basis.
>
> @Pranali, please make sure when a patch is submitted the owner adds us as
> a reviewer to the patches so that we will get immediate notification about
> the same.
>
> Thank you,
>
> Abhishek
>
>>
>> Regards,
>> Artem
>>
>> [1] https://review.opendev.org/c/openstack/project-config/+/880933
>>
>> On 19. Apr 2023, at 12:54, Pranali Deore <pdeore at redhat.com> wrote:
>>
>>
>>
>> On Mon, Apr 10, 2023 at 6:52?PM Pranali Deore <pdeore at redhat.com> wrote:
>>
>>>
>>>
>>> On Wed, Apr 5, 2023 at 12:57?PM Artem Goncharov <
>>> artem.goncharov at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Feedback from SDK/OSC team on one item that got my attention
>>>>
>>>>
>>>> # Bridge gap between Glance client and OSC
>>>> Last cycle we have prepared the list of missing commands [2] and
>>>> started submitting patches to implement the same. Our biggest hurdle at the
>>>> moment is lack of reviews from the osc team (which has only one/two cores).
>>>> Glance PTL is going to communicate with TC/existing core(s) of OSC whether
>>>> they can add any glance core to the team so that we can prioritize our work
>>>> and get reviews immediately. This cycle we are planning to complete this
>>>> work.
>>>>
>>>>
>>>> At the moment SDK/CLI core group is having 27 members, which should be
>>>> already a sign. We have an agreement with all teams and add certain members
>>>> into the core group to be able to review changes for their corresponding
>>>> services (with a limitation that they are NOT by default setting W+1).
>>>> You have noticed pretty correct - at the moment there is not so much
>>>> activity on our side due to lack of reviewers. But that is not blocking any
>>>> change once there is a +2 review from the service representatives. That
>>>> means that if Glance team opens change and another Glance team member
>>>> leaves +2 those changes are having absolutely different priority and we
>>>> normally approving them fast (unless there is something preventing that).
>>>> What we want to prevent is that every team is pulling project into their
>>>> direction breaking certain rules or conventions.
>>>>
>>>> Please provide me the list of members you would like to get SDK/CLI
>>>> core rights and I would gladly add them (one more time - no workflow+1)
>>>>
>>>> Artem
>>>>
>>>>
>>> Hi Artem,
>>>
>>> We have the discussion in the team and Abhishek & Cyril are ready to
>>> join the SDK/CLI core group to speed up the reviews on glance related
>>> changes.
>>> Please provide the SDK/CLI core rights to @Abhishek Kekane
>>> <akekane at redhat.com> & @Cyril Roelandt <cyril at redhat.com>.
>>>
>>>
>> Hi Artem,
>>
>> Any updates on adding the glance team members to SDK/CLI core group?
>> Kindly please let us know once you add them.
>>
>>
>> Thanks,
>> Pranali
>>
>>
>>> Thanks,
>>> Pranali Deore
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230420/92401847/attachment.htm>

From stephenfin at redhat.com  Thu Apr 20 11:54:25 2023
From: stephenfin at redhat.com (Stephen Finucane)
Date: Thu, 20 Apr 2023 12:54:25 +0100
Subject: [Glance] Bobcat PTG summary
In-Reply-To: <CAARK8KQ8a=dHO==QGu837ZE+EjWj79XEwhSN7BpSZU7gTWzFUw@mail.gmail.com>
References: <CALOt+SS5hstT+hRb7T3hSovCFFnB_P9WKsYF+_DwMC+56_9LEA@mail.gmail.com>
 <40D3DB03-3D45-4C08-9B80-CE7F2D47F2F7@gmail.com>
 <CADkbuWgP2GbyNg5rCativbFYhuHRzd_Y4T_NgigQ=ApAMneh=w@mail.gmail.com>
 <CADkbuWidTbvRsfMO8MDEwj06YQWtX+hNGVm6i6ksSfEKaZvsVg@mail.gmail.com>
 <29A0D9C9-62CA-469D-8E08-FA13D1E7075C@gmail.com>
 <CALOt+SSOMin3-c-ddypUM+44MPTwgprtjq-A_p_HuUuwW9a0Rg@mail.gmail.com>
 <CAARK8KQ8a=dHO==QGu837ZE+EjWj79XEwhSN7BpSZU7gTWzFUw@mail.gmail.com>
Message-ID: <471e3bd76432d335951a13c4230a14d327ee8de7.camel@redhat.com>

On Thu, 2023-04-20 at 16:45 +0530, Rajat Dhasmana wrote:
> Hi,
> 
> I was discussing this with Stephen last cycle. The general idea we discussed
> to review project specific patches was:
> 1 core from project team to verify the functionality of the patch is as
> intended
> 1 core from SDK team to verify the code follows all the conventions of SDK/OSC
> project

Just to add, I personally expect this to be a temporary state of affairs. Once
folks have a "feel" for how things are expected to work in SDK and OSC, project
teams should be able to manage their own destiny. As I've said before, I have
enough jobs and I don't want to add "gatekeeping" to that list :)

> This will ensure we are following proper convention (like how a specific
> command should be written) and the change
> we are adding works as expected (calling the right API, accepting/passing the
> right parameters etc)
> 
> On a similar note, Cinder team would also like to nominate its team member(s)
> for the core position in OSC/SDK.
> Last cycle, most (if not all) of my changes were reviewed by Stephen and I
> don't want to put more burden on
> him for the SDK work I'm planning. :)
> Let me know about the feasibility of that request and I can initiate a
> discussion in the Cinder upstream meeting for the
> interested candidate(s).

Artem will know more but it sounds like these we'll be adding the core teams for
all services to openstacksdk-service-core and openstackclient-service-core, so
this will happen then.

Stephen

> 
> Thanks
> Rajat Dhasmana
> 
> On Thu, Apr 20, 2023 at 4:21?PM Abhishek Kekane <akekane at redhat.com> wrote:
> > 
> > 
> > On Thu, Apr 20, 2023 at 3:33?PM Artem Goncharov <artem.goncharov at gmail.com>
> > wrote:
> > > Hi,
> > > 
> > > I have not forgotten and I am on it. However I see that there are too many
> > > people in the core group right now from most of which I have not ever a
> > > single review. This is becoming a bit too dangerous and I have requested
> > > arranging a new group (openstacksdk-service-core and openstackclient-
> > > service-core) with only +2 privileges to prevent workflow misuse [1].
> > > 
> > > Once this is done I will immediately add mentioned members into the group.
> > > 
> > > In the meanwhile I also wanted to hint that there are currently changes
> > > for the glance in openstackclient open (well, only 1 open left) and the
> > > people mentioned by you are so far not doing code reviews.
> > > 
> > 
> > Hi Artem,
> > 
> > Thanks for pointing it out, the one open is WIP i guess, sorry we didn't
> > notice it earlier. This PTG we decided to dedicate particular resources on
> > ?reviewing the glance specific patches. So once new patches are up then you
> > will definitely find reviews from our side on priority basis.
> > 
> > @Pranali, please make sure when a patch is submitted the owner adds us as a
> > reviewer to the patches so that we will get immediate notification about the
> > same.
> > 
> > Thank you,
> > 
> > Abhishek
> > > 
> > > Regards,
> > > Artem
> > > 
> > > [1]?https://review.opendev.org/c/openstack/project-config/+/880933
> > > 
> > > > On 19. Apr 2023, at 12:54, Pranali Deore <pdeore at redhat.com> wrote:
> > > > 
> > > > 
> > > > 
> > > > On Mon, Apr 10, 2023 at 6:52?PM Pranali Deore <pdeore at redhat.com> wrote:
> > > > > 
> > > > > 
> > > > > On Wed, Apr 5, 2023 at 12:57?PM Artem Goncharov
> > > > > <artem.goncharov at gmail.com> wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > Feedback from SDK/OSC team on one item that got my attention
> > > > > > 
> > > > > > > 
> > > > > > > # Bridge gap between Glance client and OSC
> > > > > > > Last cycle we have prepared the list of missing commands [2] and
> > > > > > > started submitting patches to implement the same. Our biggest
> > > > > > > hurdle at the moment is lack of reviews from the osc team (which
> > > > > > > has only one/two cores). Glance PTL is going to communicate with
> > > > > > > TC/existing core(s) of OSC whether they can add any glance core to
> > > > > > > the team so that we can prioritize our work and get reviews
> > > > > > > immediately. This cycle we are planning to complete this work.?
> > > > > > > 
> > > > > > 
> > > > > > At the moment SDK/CLI core group is having 27 members, which should
> > > > > > be already a sign. We have an agreement with all teams and add
> > > > > > certain members into the core group to be able to review changes for
> > > > > > their corresponding services (with a limitation that they are NOT by
> > > > > > default setting W+1).
> > > > > > You have noticed pretty correct - at the moment there is not so much
> > > > > > activity on our side due to lack of reviewers. But that is not
> > > > > > blocking any change once there is a +2 review from the service
> > > > > > representatives. That means that if Glance team opens change and
> > > > > > another Glance team member leaves +2 those changes are having
> > > > > > absolutely different priority and we normally approving them fast
> > > > > > (unless there is something preventing that). What we want to prevent
> > > > > > is that every team is pulling project into their direction breaking
> > > > > > certain rules or conventions.
> > > > > > 
> > > > > > Please provide me the list of members you would like to get SDK/CLI
> > > > > > core rights and I would gladly add them (one more time - no
> > > > > > workflow+1)
> > > > > > 
> > > > > > Artem
> > > > > > 
> > > > > > 
> > > > > 
> > > > > 
> > > > > Hi Artem,
> > > > > 
> > > > > We have the discussion in the team and Abhishek & Cyril are ready to
> > > > > join the SDK/CLI core group to speed up the reviews on glance related
> > > > > changes.
> > > > > Please provide the SDK/CLI core rights to?@Abhishek Kekane?&?@Cyril
> > > > > Roelandt.
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > Hi Artem,
> > > > 
> > > > Any updates on adding the glance team members to SDK/CLI core group?
> > > > Kindly please let us know once you add them.?
> > > > 
> > > > 
> > > > Thanks,
> > > > Pranali
> > > > 
> > > > > 
> > > > > Thanks,
> > > > > Pranali Deore?
> > > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230420/e653f28b/attachment-0001.htm>

From artem.goncharov at gmail.com  Thu Apr 20 12:56:39 2023
From: artem.goncharov at gmail.com (Artem Goncharov)
Date: Thu, 20 Apr 2023 14:56:39 +0200
Subject: [Glance] Bobcat PTG summary
In-Reply-To: <471e3bd76432d335951a13c4230a14d327ee8de7.camel@redhat.com>
References: <CALOt+SS5hstT+hRb7T3hSovCFFnB_P9WKsYF+_DwMC+56_9LEA@mail.gmail.com>
 <40D3DB03-3D45-4C08-9B80-CE7F2D47F2F7@gmail.com>
 <CADkbuWgP2GbyNg5rCativbFYhuHRzd_Y4T_NgigQ=ApAMneh=w@mail.gmail.com>
 <CADkbuWidTbvRsfMO8MDEwj06YQWtX+hNGVm6i6ksSfEKaZvsVg@mail.gmail.com>
 <29A0D9C9-62CA-469D-8E08-FA13D1E7075C@gmail.com>
 <CALOt+SSOMin3-c-ddypUM+44MPTwgprtjq-A_p_HuUuwW9a0Rg@mail.gmail.com>
 <CAARK8KQ8a=dHO==QGu837ZE+EjWj79XEwhSN7BpSZU7gTWzFUw@mail.gmail.com>
 <471e3bd76432d335951a13c4230a14d327ee8de7.camel@redhat.com>
Message-ID: <E58C1842-0BB0-4B02-AA27-A1A7AE48B2D2@gmail.com>

Hi,

Done. Mentioned members are added into the openstacksdk-service-core and python-openstackclient-service-core groups. With that they should be having code-review +2 rights

Regards,
Artem

> On 20. Apr 2023, at 13:54, Stephen Finucane <stephenfin at redhat.com> wrote:
> 
> On Thu, 2023-04-20 at 16:45 +0530, Rajat Dhasmana wrote:
>> Hi,
>> 
>> I was discussing this with Stephen last cycle. The general idea we discussed to review project specific patches was:
>> 1 core from project team to verify the functionality of the patch is as intended
>> 1 core from SDK team to verify the code follows all the conventions of SDK/OSC project
> 
> Just to add, I personally expect this to be a temporary state of affairs. Once folks have a "feel" for how things are expected to work in SDK and OSC, project teams should be able to manage their own destiny. As I've said before, I have enough jobs and I don't want to add "gatekeeping" to that list :)
> 
>> This will ensure we are following proper convention (like how a specific command should be written) and the change
>> we are adding works as expected (calling the right API, accepting/passing the right parameters etc)
>> 
>> On a similar note, Cinder team would also like to nominate its team member(s) for the core position in OSC/SDK.
>> Last cycle, most (if not all) of my changes were reviewed by Stephen and I don't want to put more burden on
>> him for the SDK work I'm planning. :)
>> Let me know about the feasibility of that request and I can initiate a discussion in the Cinder upstream meeting for the
>> interested candidate(s).
> 
> Artem will know more but it sounds like these we'll be adding the core teams for all services to openstacksdk-service-core and openstackclient-service-core, so this will happen then.
> 
> Stephen
> 
>> 
>> Thanks
>> Rajat Dhasmana
>> 
>> On Thu, Apr 20, 2023 at 4:21?PM Abhishek Kekane <akekane at redhat.com <mailto:akekane at redhat.com>> wrote:
>>> 
>>> 
>>> On Thu, Apr 20, 2023 at 3:33?PM Artem Goncharov <artem.goncharov at gmail.com <mailto:artem.goncharov at gmail.com>> wrote:
>>>> Hi,
>>>> 
>>>> I have not forgotten and I am on it. However I see that there are too many people in the core group right now from most of which I have not ever a single review. This is becoming a bit too dangerous and I have requested arranging a new group (openstacksdk-service-core and openstackclient-service-core) with only +2 privileges to prevent workflow misuse [1].
>>>> 
>>>> Once this is done I will immediately add mentioned members into the group.
>>>> 
>>>> In the meanwhile I also wanted to hint that there are currently changes for the glance in openstackclient open (well, only 1 open left) and the people mentioned by you are so far not doing code reviews.
>>>> 
>>> Hi Artem,
>>> 
>>> Thanks for pointing it out, the one open is WIP i guess, sorry we didn't notice it earlier. This PTG we decided to dedicate particular resources on  reviewing the glance specific patches. So once new patches are up then you will definitely find reviews from our side on priority basis.
>>> 
>>> @Pranali, please make sure when a patch is submitted the owner adds us as a reviewer to the patches so that we will get immediate notification about the same.
>>> 
>>> Thank you,
>>> 
>>> Abhishek
>>>> 
>>>> Regards,
>>>> Artem
>>>> 
>>>> [1] https://review.opendev.org/c/openstack/project-config/+/880933
>>>> 
>>>>> On 19. Apr 2023, at 12:54, Pranali Deore <pdeore at redhat.com <mailto:pdeore at redhat.com>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On Mon, Apr 10, 2023 at 6:52?PM Pranali Deore <pdeore at redhat.com <mailto:pdeore at redhat.com>> wrote:
>>>>>> 
>>>>>> 
>>>>>> On Wed, Apr 5, 2023 at 12:57?PM Artem Goncharov <artem.goncharov at gmail.com <mailto:artem.goncharov at gmail.com>> wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>> Feedback from SDK/OSC team on one item that got my attention
>>>>>>> 
>>>>>>>> 
>>>>>>>> # Bridge gap between Glance client and OSC
>>>>>>>> Last cycle we have prepared the list of missing commands [2] and started submitting patches to implement the same. Our biggest hurdle at the moment is lack of reviews from the osc team (which has only one/two cores). Glance PTL is going to communicate with TC/existing core(s) of OSC whether they can add any glance core to the team so that we can prioritize our work and get reviews immediately. This cycle we are planning to complete this work. 
>>>>>>>> 
>>>>>>> 
>>>>>>> At the moment SDK/CLI core group is having 27 members, which should be already a sign. We have an agreement with all teams and add certain members into the core group to be able to review changes for their corresponding services (with a limitation that they are NOT by default setting W+1).
>>>>>>> You have noticed pretty correct - at the moment there is not so much activity on our side due to lack of reviewers. But that is not blocking any change once there is a +2 review from the service representatives. That means that if Glance team opens change and another Glance team member leaves +2 those changes are having absolutely different priority and we normally approving them fast (unless there is something preventing that). What we want to prevent is that every team is pulling project into their direction breaking certain rules or conventions.
>>>>>>> 
>>>>>>> Please provide me the list of members you would like to get SDK/CLI core rights and I would gladly add them (one more time - no workflow+1)
>>>>>>> 
>>>>>>> Artem
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> Hi Artem,
>>>>>> 
>>>>>> We have the discussion in the team and Abhishek & Cyril are ready to join the SDK/CLI core group to speed up the reviews on glance related changes.
>>>>>> Please provide the SDK/CLI core rights to @Abhishek Kekane <mailto:akekane at redhat.com> & @Cyril Roelandt <mailto:cyril at redhat.com>.
>>>>>> 
>>>>>> 
>>>>> 
>>>>> Hi Artem,
>>>>> 
>>>>> Any updates on adding the glance team members to SDK/CLI core group?
>>>>> Kindly please let us know once you add them. 
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> Pranali
>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> Pranali Deore 
>>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230420/d953c577/attachment.htm>

From renliang at uniontech.com  Thu Apr 20 07:55:52 2023
From: renliang at uniontech.com (=?utf-8?B?5Lu75Lqu?=)
Date: Thu, 20 Apr 2023 15:55:52 +0800
Subject: [nova]qemu-guest-agent Used in openstack
Message-ID: <tencent_0E2EFE4458CEF6703E135F5E@qq.com>

Hi,


We discovered the use of qemu-guest-agent in openstack,Set hw_qemu_guest_agent=yes to the metadata parameter on the image.
https://docs.openstack.org/mitaka/config-reference/compute/hypervisor-kvm.html


Meanwhile, the application of qemu-guest-agent in cloud scenarios is investigated. It is found that Qemu-guest-Agent can be used for guest os performance monitoring, snapshot backup, and guest OS-level failover.
But these things can be done in openstack with prometheus and cinder-backup,There may be some differences between them,


Sorry, I am not familiar with how hw_qemu_guest_agent is used in openstack, and I do not know the operations that can be performed on guest os in openstack by configuring hw_qemu_guest_agent.
Only through qemu official know some of the effects.I want to clarify the use of hw_qemu_guest_agent. Other components of openstack, such as the prometheus service, can be used instead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230420/c49ee7b4/attachment.htm>

From pierre at stackhpc.com  Thu Apr 20 13:55:48 2023
From: pierre at stackhpc.com (Pierre Riteau)
Date: Thu, 20 Apr 2023 15:55:48 +0200
Subject: [blazar] Meeting cancelled today
Message-ID: <CA+ny2szymoNzNw+2YbAxbtedYf428AkCNKDX8yOH+pa5AWd63Q@mail.gmail.com>

Hello,

I won't be able to run the Blazar IRC meeting today. Let's skip this one.

Thanks,
Pierre Riteau (priteau)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230420/1a9a422d/attachment-0001.htm>

From rdhasman at redhat.com  Thu Apr 20 14:04:25 2023
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Thu, 20 Apr 2023 19:34:25 +0530
Subject: [cinder] festival of feature reviews 21 April 2023
Message-ID: <CAARK8KQ8ThYyS2DRUvEvu2P2rbU3FyfSemz-qNzOMCRHBXpz5w@mail.gmail.com>

Hello Argonauts,

We will be having our monthly festival of reviews tomorrow
i.e. 21st April (Friday) from 1400-1600 UTC.
Our priorities for M-1 are DB changes for compatibility with
sqlalchemy 2.0 and cinder-specs.
Following are some additional details:

Date: 21st April, 2023
Time: 1400-1600 UTC
Meeting link:  will be shared before meeting
etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews

See you there!

Thanks
Rajat Dhasmana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230420/13db49a5/attachment.htm>

From akekane at redhat.com  Thu Apr 20 14:53:59 2023
From: akekane at redhat.com (Abhishek Kekane)
Date: Thu, 20 Apr 2023 20:23:59 +0530
Subject: [Glance] Bobcat PTG summary
In-Reply-To: <E58C1842-0BB0-4B02-AA27-A1A7AE48B2D2@gmail.com>
References: <CALOt+SS5hstT+hRb7T3hSovCFFnB_P9WKsYF+_DwMC+56_9LEA@mail.gmail.com>
 <40D3DB03-3D45-4C08-9B80-CE7F2D47F2F7@gmail.com>
 <CADkbuWgP2GbyNg5rCativbFYhuHRzd_Y4T_NgigQ=ApAMneh=w@mail.gmail.com>
 <CADkbuWidTbvRsfMO8MDEwj06YQWtX+hNGVm6i6ksSfEKaZvsVg@mail.gmail.com>
 <29A0D9C9-62CA-469D-8E08-FA13D1E7075C@gmail.com>
 <CALOt+SSOMin3-c-ddypUM+44MPTwgprtjq-A_p_HuUuwW9a0Rg@mail.gmail.com>
 <CAARK8KQ8a=dHO==QGu837ZE+EjWj79XEwhSN7BpSZU7gTWzFUw@mail.gmail.com>
 <471e3bd76432d335951a13c4230a14d327ee8de7.camel@redhat.com>
 <E58C1842-0BB0-4B02-AA27-A1A7AE48B2D2@gmail.com>
Message-ID: <CALOt+STBcdJSdGKRPXaAgpoXU=HWE-peQRWatDvPKrTePb-MXg@mail.gmail.com>

Awesome, thank you for your help!

Thanks & Best Regards,

Abhishek Kekane


On Thu, Apr 20, 2023 at 6:26?PM Artem Goncharov <artem.goncharov at gmail.com>
wrote:

> Hi,
>
> Done. Mentioned members are added into the openstacksdk-service-core and
> python-openstackclient-service-core groups. With that they should be having
> code-review +2 rights
>
> Regards,
> Artem
>
> On 20. Apr 2023, at 13:54, Stephen Finucane <stephenfin at redhat.com> wrote:
>
> On Thu, 2023-04-20 at 16:45 +0530, Rajat Dhasmana wrote:
>
> Hi,
>
> I was discussing this with Stephen last cycle. The general idea we
> discussed to review project specific patches was:
> 1 core from project team to verify the functionality of the patch is as
> intended
> 1 core from SDK team to verify the code follows all the conventions of
> SDK/OSC project
>
>
> Just to add, I personally expect this to be a temporary state of affairs.
> Once folks have a "feel" for how things are expected to work in SDK and
> OSC, project teams should be able to manage their own destiny. As I've said
> before, I have enough jobs and I don't want to add "gatekeeping" to that
> list :)
>
> This will ensure we are following proper convention (like how a specific
> command should be written) and the change
> we are adding works as expected (calling the right API, accepting/passing
> the right parameters etc)
>
> On a similar note, Cinder team would also like to nominate its team
> member(s) for the core position in OSC/SDK.
> Last cycle, most (if not all) of my changes were reviewed by Stephen and I
> don't want to put more burden on
> him for the SDK work I'm planning. :)
> Let me know about the feasibility of that request and I can initiate a
> discussion in the Cinder upstream meeting for the
> interested candidate(s).
>
>
> Artem will know more but it sounds like these we'll be adding the core
> teams for all services to openstacksdk-service-core and
> openstackclient-service-core, so this will happen then.
>
> Stephen
>
>
> Thanks
> Rajat Dhasmana
>
> On Thu, Apr 20, 2023 at 4:21?PM Abhishek Kekane <akekane at redhat.com>
> wrote:
>
>
>
> On Thu, Apr 20, 2023 at 3:33?PM Artem Goncharov <artem.goncharov at gmail.com>
> wrote:
>
> Hi,
>
> I have not forgotten and I am on it. However I see that there are too many
> people in the core group right now from most of which I have not ever a
> single review. This is becoming a bit too dangerous and I have requested
> arranging a new group (openstacksdk-service-core and
> openstackclient-service-core) with only +2 privileges to prevent workflow
> misuse [1].
>
> Once this is done I will immediately add mentioned members into the group.
>
> In the meanwhile I also wanted to hint that there are currently changes
> for the glance in openstackclient open (well, only 1 open left) and the
> people mentioned by you are so far not doing code reviews.
>
> Hi Artem,
>
> Thanks for pointing it out, the one open is WIP i guess, sorry we didn't
> notice it earlier. This PTG we decided to dedicate particular resources on
>  reviewing the glance specific patches. So once new patches are up then
> you will definitely find reviews from our side on priority basis.
>
> @Pranali, please make sure when a patch is submitted the owner adds us as
> a reviewer to the patches so that we will get immediate notification about
> the same.
>
> Thank you,
>
> Abhishek
>
>
> Regards,
> Artem
>
> [1] https://review.opendev.org/c/openstack/project-config/+/880933
>
> On 19. Apr 2023, at 12:54, Pranali Deore <pdeore at redhat.com> wrote:
>
>
>
> On Mon, Apr 10, 2023 at 6:52?PM Pranali Deore <pdeore at redhat.com> wrote:
>
>
>
> On Wed, Apr 5, 2023 at 12:57?PM Artem Goncharov <artem.goncharov at gmail.com>
> wrote:
>
> Hi,
>
> Feedback from SDK/OSC team on one item that got my attention
>
>
> # Bridge gap between Glance client and OSC
> Last cycle we have prepared the list of missing commands [2] and started
> submitting patches to implement the same. Our biggest hurdle at the moment
> is lack of reviews from the osc team (which has only one/two cores). Glance
> PTL is going to communicate with TC/existing core(s) of OSC whether they
> can add any glance core to the team so that we can prioritize our work and
> get reviews immediately. This cycle we are planning to complete this work.
>
>
>
> At the moment SDK/CLI core group is having 27 members, which should be
> already a sign. We have an agreement with all teams and add certain members
> into the core group to be able to review changes for their corresponding
> services (with a limitation that they are NOT by default setting W+1).
> You have noticed pretty correct - at the moment there is not so much
> activity on our side due to lack of reviewers. But that is not blocking any
> change once there is a +2 review from the service representatives. That
> means that if Glance team opens change and another Glance team member
> leaves +2 those changes are having absolutely different priority and we
> normally approving them fast (unless there is something preventing that).
> What we want to prevent is that every team is pulling project into their
> direction breaking certain rules or conventions.
>
> Please provide me the list of members you would like to get SDK/CLI core
> rights and I would gladly add them (one more time - no workflow+1)
>
> Artem
>
>
>
> Hi Artem,
>
> We have the discussion in the team and Abhishek & Cyril are ready to join
> the SDK/CLI core group to speed up the reviews on glance related changes.
> Please provide the SDK/CLI core rights to @Abhishek Kekane
> <akekane at redhat.com> & @Cyril Roelandt <cyril at redhat.com>.
>
>
>
> Hi Artem,
>
> Any updates on adding the glance team members to SDK/CLI core group?
> Kindly please let us know once you add them.
>
>
> Thanks,
> Pranali
>
>
> Thanks,
> Pranali Deore
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230420/1e8275c8/attachment.htm>

From gmann at ghanshyammann.com  Thu Apr 20 22:42:35 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 20 Apr 2023 15:42:35 -0700
Subject: [qa][all] New hacking 6.0.0 is available
Message-ID: <187a0d57281.f2aae5d4229696.732622903205452208@ghanshyammann.com>

Hello Everyone,

Hacking 6.0.0 is available to use now which includes flake8 5.0 changes. 

There are no other changes than bumping flake8 version to 5.0.1, you can
refer to the changes done in flake8 5.0.0 (or 5.0.1) directly in flake8 release notes
- https://flake8.pycqa.org/en/latest/release-notes/5.0.0.html 

Note: hacking is pinned in test-requirements.txt (for almost all the repo), do not forget
to bump the version there while moving your code to new hacking.

-gmann


From 1148203170 at qq.com  Fri Apr 21 01:58:05 2023
From: 1148203170 at qq.com (=?gb18030?B?3/Xf9d/1?=)
Date: Fri, 21 Apr 2023 09:58:05 +0800
Subject: [nova]qemu-guest-agent Used in openstack
In-Reply-To: <773963adcc9d68e00c04ecf85dab3c438345be0a.camel@redhat.com>
References: <tencent_3BA769BFD2F23E133E81736CA43A5EB0D305@qq.com>
 <773963adcc9d68e00c04ecf85dab3c438345be0a.camel@redhat.com>
Message-ID: <tencent_0AEB76FA36155592DD83C07773728E9CC50A@qq.com>

Thank you for your reply


I see that hw_qemu_guest_agent can freeze and unfreeze the guest os file system when creating snapshots, but I do not know the meaning of freezing and unfreezing the file system. In other words, if the qemu guest agent is not specified, the guest os cannot be frozen or unfrozen. What are the differences between freezing and thawing operations? How applicable it is in the cloud scenario.





------------------&nbsp;????&nbsp;------------------
???:                                                                                                                        "Sean Mooney"                                                                                    <smooney at redhat.com&gt;;
????:&nbsp;2023?4?20?(???) ??7:00
???:&nbsp;"???"<1148203170 at qq.com&gt;;"openstack-discuss"<openstack-discuss at lists.openstack.org&gt;;

??:&nbsp;Re: [nova]qemu-guest-agent Used in openstack



The hw_qemu_guest_agent image property is used to enable the qemu channel (basically a unix socket) use to enabel comunciation
between a "qemu guest agent" there is a default qemu one but other cloud vendor have created there own. i know ovh has one they
maintain for there cloud. the upstream qemu guest agent is not used for monitoring. i belive it can be used to monitor the guest if
you write a custom one but that is not somethign that is directly supported by upstream openstack.

nova only uses it for one thing.
we supprot the generic qemu geusts agent ablity to freeze the guest file system and unfreeze it to take
snapshots without any inflight data writes.

prometheus is not really integrated with openstack at least not in a way that is maintained/supported by
the openstack comunity as an officall project as far as i am aware.
i do not belive there is any interaction between prometheus and the qemu guest agent although there is a libvirt exporter
for prometious so perhaps it has support for interafcting with the qemu agent in some way.

form a nova point of view we just enable the qemu guest agent to fucntion if you have installed it in your guest but we
dont really try to use it to monitor or manage the guest in general beyond the orginal uscase for consitent snapshots.
hopefully that helps.


On Thu, 2023-04-20 at 18:13 +0800, ??? wrote:
&gt; Hi,
&gt; 
&gt; 
&gt; We discovered the use of qemu-guest-agent in openstack,Set hw_qemu_guest_agent=yes to the metadata parameter on the image.
&gt; https://docs.openstack.org/mitaka/config-reference/compute/hypervisor-kvm.html
&gt; 
&gt; 
&gt; Meanwhile, the application of qemu-guest-agent in cloud scenarios is investigated. It is found that Qemu-guest-Agent can be used for guest os performance monitoring, snapshot backup, and guest OS-level failover.
&gt; But these things can be done in openstack with prometheus and&amp;nbsp; instance backup,There may be some differences between them.
&gt; 
&gt; 
&gt; Sorry, I am not familiar with how hw_qemu_guest_agent is used in openstack, and I do not know the operations that can be performed on guest os in openstack by configuring hw_qemu_guest_agent.
&gt; Only through qemu official know some of the effects.I want to clarify the use of hw_qemu_guest_agent. Other components of openstack, such as the prometheus service, can be used instead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230421/63ced8a4/attachment.htm>

From wangxiyuan1007 at gmail.com  Fri Apr 21 05:47:04 2023
From: wangxiyuan1007 at gmail.com (Xiyuan Wang)
Date: Fri, 21 Apr 2023 13:47:04 +0800
Subject: [kolla] [openeuler] CI jobs status
In-Reply-To: <CAE_fguAsdM-CC4J5OEOska7DK4vsZH+reMbBsgTzCDW+gdUT7g@mail.gmail.com>
References: <71E23583-527B-4502-A624-A118E7CCA3E3@gmail.com>
 <CAE_fguAsdM-CC4J5OEOska7DK4vsZH+reMbBsgTzCDW+gdUT7g@mail.gmail.com>
Message-ID: <CAGLsBR-v8L5wEx69Jmth5y+9EQ56r1x40s_3=DU8o+z9ZzRz7w@mail.gmail.com>

Hi  Micha?
    Sorry for reply late. I'm now working on fixing the openEuler CI issue.
I'll make it OK ASAP. Actually, I noticed the failure some days ago and
Here is some background I'd like to share.
    1. The openEuler repo mirror doesn't work. So the job may TIMEOUT due
to slow network speed. I've fixed the mirror problem in
diskimage-builder[1]. It needs some days to be released and addressed into
zuul before. That's why I didn't fix the kolla CI error at once.
    2. There is another TIMEOUT issue in the openEuler Kolla-ansible job.
The case is that MariaDB setup step is hanging. I'm working on debugging it
these days.
    3. The job raises another error these two day. I'll fix it ASAP.

I'm sure I'll keep maintaining the openEuler Job, please give me few more
days, I'll make it back to OK.

Thanks. Regards

[1]: https://review.opendev.org/c/openstack/diskimage-builder/+/878185
https://review.opendev.org/c/openstack/diskimage-builder/+/878807


Maksim Malchuk <maksim.malchuk at gmail.com> ?2023?4?18??? 04:54???

> Hi Micha?,
>
> We moved from Centos to Rocky so hard, I think supporting another one
> RedHat "compatible system" would be not easy.
>
> On Mon, Apr 17, 2023 at 6:21?PM Micha? Nasiadka <mnasiadka at gmail.com>
> wrote:
>
>> Hello Koalas,
>>
>> OpenEuler jobs in master (to be Antelope) are failing for a long time.
>> If no one is interested in maintaining OpenEuler support in Kolla-Ansible
>> - I will propose dropping it?s support on Wednesday Kolla meeting.
>>
>> Best regards,
>> Michal
>>
>
>
> --
> Regards,
> Maksim Malchuk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230421/ca3cd9aa/attachment.htm>

From weixu at iastate.edu  Fri Apr 21 04:52:39 2023
From: weixu at iastate.edu (Xu, Wei [E CPE])
Date: Fri, 21 Apr 2023 04:52:39 +0000
Subject: OpenStack Swift quota
Message-ID: <SA1PR04MB854472CC6D76D00245BFF81FA9609@SA1PR04MB8544.namprd04.prod.outlook.com>

Hello OpenStack community,

Right now, because we tend to limit each user's individual storage capacity, we're trying to implement account and container-level quotas on our OpenStack Swift cluster (Yoga version). Every time we tried to execute a command like "swift post -m quota-bytes: 500" using the Swift CLI client to implement account quotas, it returned a 403 error saying "403 Forbidden  [first 60 chars of response] <html><h1>Forbidden</h1><p>Access was denied to this resourc", even if we are using an account already with the reseller/ResellerAdmin role, and both quotas added to the [pipeline:main] on our proxy server. Could you help us identify what could be behind this issue and how to resolve it?

Also, it seems like default OpenStack Swift only supports account-level and container-level quota implementation. Is it possible to implement not only user-level but also project-level and domain-level quotas?

I'm looking forward to hearing back from you. Thank you very much!

Yours sincerely,

Wei Xu, M.S.
Research Assistant
Department of ECpE,
Iowa State University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230421/fe6d3b43/attachment-0001.htm>

From emanuele.scaglia at nposervices.com  Fri Apr 21 09:20:33 2023
From: emanuele.scaglia at nposervices.com (SCAGLIA Emanuele (NPO))
Date: Fri, 21 Apr 2023 09:20:33 +0000
Subject: [Networking-vSphere]
Message-ID: <PR1PR01MB497008B207DF5D8BA1A2382E88609@PR1PR01MB4970.eurprd01.prod.exchangelabs.com>

Hello,
I'd like to know if there is in your opinion any chance that the OVSvApp solution works with Openstack zed release.
Regarding how to use it, I found this page:
https://github.com/nephoscale-div/OVSvAPP

Is it still valid?
Thank you in advance,
Emanuele Scaglia

Emanuele Scaglia
Senior System Engineer
NPO TORINO s.r.l.
[cid:image001.png at 01D97443.46C8DCE0]<https://www.nposervices.com/>
[cid:image002.png at 01D97443.46C8DCE0]
emanuele.scaglia at nposervices.com<mailto:emanuele.scaglia at nposervices.com>
[cid:image003.png at 01D97443.46C8DCE0]
+39 3666180721<tel:3425965928>
[cid:image004.png at 01D97443.46C8DCE0]
Via Vincenzo Lancia 27, 10141 TORINO<https://www.google.com/maps/place/Via+Vincenzo+Lancia,+27,+10141+Torino+TO/@45.0612057,7.6413237,17z/data=!3m1!4b1!4m6!3m5!1s0x47886cdd3eab2711:0xadcede36ced85268!8m2!3d45.0612057!4d7.6413237!16s%2Fg%2F11bw3zvhgq>
[cid:image005.png at 01D97443.46C8DCE0]
nposervices.com<https://www.nposervices.com/>
[cid:image006.png at 01D97443.46C8DCE0]<https://www.facebook.com/>
[cid:image007.png at 01D97443.46C8DCE0]<https://www.twitter.com/>
[cid:image008.png at 01D97443.46C8DCE0]<https://www.linkedin.com/>
[cid:image009.png at 01D97443.46C8DCE0]<https://www.instagram.com/>
[cid:image010.png at 01D97443.46C8DCE0]<https://www.youtube.com/>
Sede legale: L.go Dora P. Colletta, 81, 10153- Torino
Tel. +39 011 19701225
Fax. +39 011 19781413
P. IVA: 10041060012

The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.


AVVERTENZE AI SENSI DEL D.LGS. 196/2003 . Il contenuto di questo messaggio (ed eventuali allegati) e' strettamente confidenziale. L'utilizzo del contenuto del messaggio e' riservato esclusivamente al destinatario. La modifica, distribuzione, copia del messaggio da parte di altri e' severamente proibita. Se non siete i destinatari Vi invitiamo ad informare il mittente ed eliminare tutte le copie del suddetto messaggio. The contents of this message (and all attachments) are strictly confidential. The message is intended exclusively to the addressee. The modification, distribution, or replication of the message from others is strictly forbidden. If you are not the intended addressee, please notify the sender and eliminate all the copies of the message,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230421/3e798415/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3878 bytes
Desc: image001.png
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230421/3e798415/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 980 bytes
Desc: image002.png
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230421/3e798415/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 838 bytes
Desc: image003.png
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230421/3e798415/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 1247 bytes
Desc: image004.png
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230421/3e798415/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 1199 bytes
Desc: image005.png
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230421/3e798415/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 915 bytes
Desc: image006.png
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230421/3e798415/attachment-0015.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 1241 bytes
Desc: image007.png
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230421/3e798415/attachment-0016.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.png
Type: image/png
Size: 1017 bytes
Desc: image008.png
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230421/3e798415/attachment-0017.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image009.png
Type: image/png
Size: 1335 bytes
Desc: image009.png
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230421/3e798415/attachment-0018.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image010.png
Type: image/png
Size: 1023 bytes
Desc: image010.png
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230421/3e798415/attachment-0019.png>

From knikolla at bu.edu  Sat Apr 22 13:37:25 2023
From: knikolla at bu.edu (Nikolla, Kristi)
Date: Sat, 22 Apr 2023 13:37:25 +0000
Subject: [tc][all] Technical Committee Weekly Summary - April 22, 2023
Message-ID: <2F7EE27D-8D12-4215-8F5F-EE44CBDF5F32@bu.edu>

Hi all,

Here?s another edition of ?What?s happening on the Technical Committee.?

Meeting
=======
The Technical Committee met on April 18, 2023 on the #openstack-tc channel on OFTC IRC. The meeting was chaired by Jay Faulkner. Thanks Jay!

The next meeting will be held on April 25, 2023 at 18:00UTC. For more information visit https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

Happenings
==========

Leaderless projects
-------------------
There's only 3 projects now remaining without a leader[0]. Monasca[1], Vitrage[2] and Winstackers[3]. We're actively looking for people with the time and desire to maintain these projects. A retirement of Winstackers would cause Windows (and Hyper-V) host support to be removed.

Meanwhile, TripleO has switched to a distributed project leadership model, and is initiating the process of deprecation.[4]

[0]. https://etherpad.opendev.org/p/2023.2-leaderless
[1]. https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033112.html
[2]. https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033348.html
[3]. https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033342.html
[4]. https://review.opendev.org/c/openstack/governance/+/877132


Issues with docs since 2023.1 release
-------------------------------------
2023.1 is the first release that uses numeric versioning, rather than the old naming scheme. This confuses our docs build process, which produces incorrect results.

For one example the Administrator Guides list for Zed lists all the projects correctly[0], but the one for 2023.1 is empty[1].

Please use the Etherpad [2] to report issues, and the same Etherpad for tracking work. We're looking for help in getting this resolved quickly.


[0]. https://docs.openstack.org/zed/admin/index.html
[1]. https://docs.openstack.org/2023.1.antelope/admin/index.html
[2]. https://etherpad.opendev.org/p/docs-issues-2023

Weekly Gate Health Report
-------------------------
The gate continues to experience failures regarding volume detach tests[0]. There's also some issues with Ironic grenade jobs. Helping out with CI is an amazing way to get involved in the community, reach out to the TC (see below how) to know more!

[0]. https://meetings.opendev.org/meetings/tc/2023/tc.2023-04-18-18.00.log.html#l-50


Changes
=======
Merged
Appoint Tim Burke as Swift PTL (formal-vote) | https://review.opendev.org/c/openstack/governance/+/878286
TripleO: switch to distributed project leadership (formal-vote) | https://review.opendev.org/c/openstack/governance/+/878799
Appoint Andriy Kurilin as Rally PTL (formal-vote) | https://review.opendev.org/c/openstack/governance/+/878065
Add missing governance-sigs repo in technical-committee-repos.yaml (project-update) | https://review.opendev.org/c/openstack/governance/+/880237
Consider release version as string in projects data (code-change) | https://review.opendev.org/c/openstack/governance/+/877143
New Open
Update to hacking v6 (code-change) | https://review.opendev.org/c/openstack/governance/+/881266
Switch to 2023.2 testing runtime py version (code-change) | https://review.opendev.org/c/openstack/governance/+/881137
Abandoned
Switch project and OpenStack versions in releases (formal-vote) | https://review.opendev.org/c/openstack/governance/+/875942
All Open
https://review.opendev.org/q/project:openstack/governance+status:open

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 an email with the tag [tc] on the openstack-discuss mailing list.
2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 16:00 UTC
3. IRC: Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel on OFTC.

From satish.txt at gmail.com  Mon Apr 24 01:31:38 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Sun, 23 Apr 2023 21:31:38 -0400
Subject: [OpenvSwitch][Neutron] native flow based firewall Vs LinuxBridge
 Iptables firewall
Message-ID: <CAPgF-fqVtNznnbXZPBBzNLbtc-T-a+3KWoktt18xR5suHcktFg@mail.gmail.com>

Folks,

As we know, openvswitch uses a linuxbridge based firewall to implement
security-groups on openstack. It works great but it has so many packet
hops. It also makes troubleshooting a little complicated.

OpenvSwitch does support native firewall features in flows, Does it mature
enough to implement in production and replace it with LinuxBridge based
IPtables firewall?

~S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230423/347a1d2d/attachment.htm>

From nguyenhuukhoinw at gmail.com  Mon Apr 24 06:17:13 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Mon, 24 Apr 2023 13:17:13 +0700
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <4ffc9821-4edc-de97-a0ed-d87355bc4241@stackhpc.com>
References: <5906e729a3a7adf9dea1fcd47aade4e9a0688e7d.camel@redhat.com>
 <A6BEA46C-87FA-42C5-8384-8D86ED790B5C@gmail.com>
 <4ffc9821-4edc-de97-a0ed-d87355bc4241@stackhpc.com>
Message-ID: <CABAODRfSvRyFSLSvSF_O+HwxDfECBz=PaiYDkx25FSzJQ1VLFA@mail.gmail.com>

Hi everyone,
I update that. With failover controller, we dont need use mirror queue if
we use ceph as backend. In my case, I use SAN as cinder backend and NFS as
glance backend so I need mirror queue. It is quite weird.
Nguyen Huu Khoi


On Mon, Apr 17, 2023 at 5:03?PM Doug Szumski <doug at stackhpc.com> wrote:

> On 13/04/2023 23:04, Satish Patel wrote:
> > Thank Sean/Matt,
> >
> > This is interesting that I have only option to use classic mirror with
> durable :( because without mirror cluster acting up when one of node is
> down.
>
> If you have planned maintenance and non-mirrored transient queues, you
> can first try draining the node to be removed, before removing it from
> the cluster. In my testing at least, this appears to be much more
> successful than relying on the RabbitMQ clients to do the failover and
> recreate queues.  See [1], or for RMQ <3.8 you can cobble something
> together with ha-mode nodes [2].
>
> [1] https://www.rabbitmq.com/upgrade.html#maintenance-mode
>
> [2] https://www.rabbitmq.com/ha.html#mirroring-arguments
>
> This obviously doesn't solve the case of when a controller fails
> unexpectedly.
>
> I also think it's worth making the distinction between a highly
> available messaging infrastructure, and queue mirroring. In many cases,
> if a RMQ node hosting a non-mirrored, transient queue goes down, it
> should be possible for a service to just recreate the queue on another
> node and retry. This often seems to fail, which leads to queue mirroring
> getting turned on.
>
> >
> > How people are scaling rabbitMQ for large scale?
> >
> > Sent from my iPhone
> >
> >> On Apr 13, 2023, at 7:50 AM, Sean Mooney <smooney at redhat.com> wrote:
> >>
> >> ?On Thu, 2023-04-13 at 09:07 +0100, Matt Crees wrote:
> >>> Hi all, I'll reply in turn here:
> >>>
> >>> Radek, I agree it definitely will be a good addition to the KA docs.
> >>> I've got it on my radar, will aim to get a patch proposed this week.
> >>>
> >>> Satish, I haven't personally been able to test durable queues on a
> >>> system that large. According to the RabbitMQ docs
> >>> (https://www.rabbitmq.com/queues.html#durability), "Throughput and
> >>> latency of a queue is not affected by whether a queue is durable or
> >>> not in most cases." However, I have anecdotally heard that it can
> >>> affect some performance in particularly large systems.
> >> the perfomacne of durable queue is dominated by the disk io
> >> put rabbit on a pcie nvme ssd and it will have littel effect
> >> use spinnign rust (a HDD even in raid 10) and the iops/throput of the
> >> storage sued to make the qure durible (that just mean write all
> messages to disk)
> >> will be the bottlenck for scaleablity
> >> combine that with HA and that is worse as it has to be writen to
> multipel servers.
> >> i belive that teh mirror implemantion will wait for all copies to be
> persisted
> >> but i have not really looked into it. it was raised as a pain point
> with rabbit by
> >> operator in the past in terms fo scaling.
> >>
> >>> Please note that if you are using the classic mirrored queues, you
> >>> must also have them durable. Transient (i.e. non-durable) mirrored
> >>> queues are not a supported feature and do cause bugs. (For example the
> >>> "old incarnation" errors seen here:
> >>> https://bugs.launchpad.net/kolla-ansible/+bug/1954925)
> >>>
> >>> Nguyen, I can confirm that we've seen the same behaviour. This is
> >>> caused by a backported change in oslo.messaging (I believe you linked
> >>> the relevant bug report previously). There is a fix in progress to fix
> >>> this (https://review.opendev.org/c/openstack/oslo.messaging/+/866617),
> >>> and in the meantime setting kombu_reconnect_delay < 1.0 does resolve
> >>> it.
> >>>
> >>> Cheers,
> >>> Matt
> >>>
> >>>> On Thu, 13 Apr 2023 at 03:04, Nguy?n H?u Kh?i <
> nguyenhuukhoinw at gmail.com> wrote:
> >>>>
> >>>> update:
> >>>> I use SAN as Cinder backend.
> >>>> Nguyen Huu Khoi
> >>>>
> >>>>
> >>>> On Thu, Apr 13, 2023 at 9:02?AM Nguy?n H?u Kh?i <
> nguyenhuukhoinw at gmail.com> wrote:
> >>>>> Hello guys.
> >>>>>
> >>>>> I do many tests on xena and yoga. then i am sure that without
> ha-queue and kombu_reconnect_delay=0.5(it can < 1)
> >>>>> you cannot launch instances when 1 of 3 controllers is down.
> >>>>> Somebody can verify what I say, I hope we will have a common
> solution for this problem because those who use openstack for the first
> time will continue to ask questions like that.
> >>>>>
> >>>>> Nguyen Huu Khoi
> >>>>>
> >>>>>
> >>>>> On Thu, Apr 13, 2023 at 12:59?AM Satish Patel <satish.txt at gmail.com>
> wrote:
> >>>>>> This is great! Matt,
> >>>>>>
> >>>>>> Documentation would be greatly appreciated. I have a counter
> question: does Durable queue be good for large clouds with 1000 compute
> nodes or better to not use durable queue. This is a private cloud and we
> don't care about persistent data.
> >>>>>>
> >>>>>> On Wed, Apr 12, 2023 at 12:37?PM Rados?aw Piliszek <
> radoslaw.piliszek at gmail.com> wrote:
> >>>>>>> Hi Matt,
> >>>>>>>
> >>>>>>>> As you're now reconfiguring a running deployment, there are
> >>>>>>>> some extra steps that need to be taken to migrate to durable
> queues.
> >>>>>>>>
> >>>>>>>> 1. You will need to stop the OpenStack services which use
> RabbitMQ.
> >>>>>>>>
> >>>>>>>> 2. Reset the state of RabbitMQ one each rabbit node with the
> following
> >>>>>>>> commands. You must run each command on all RabbitMQ nodes before
> >>>>>>>> moving on to the next command. This will remove all queues.
> >>>>>>>>
> >>>>>>>>     rabbitmqctl stop_app
> >>>>>>>>     rabbitmqctl force_reset
> >>>>>>>>     rabbitmqctl start_app
> >>>>>>>>
> >>>>>>>> 3. Start the OpenStack services again, at which point they will
> >>>>>>>> recreate the appropriate queues as durable.
> >>>>>>> This sounds like a great new addition-to-be to the Kolla Ansible
> docs!
> >>>>>>> Could you please propose it as a change?
> >>>>>>>
> >>>>>>> Kindest,
> >>>>>>> Radek
> >>>>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/2f07cbdb/attachment.htm>

From katonalala at gmail.com  Mon Apr 24 06:27:35 2023
From: katonalala at gmail.com (Lajos Katona)
Date: Mon, 24 Apr 2023 08:27:35 +0200
Subject: [Networking-vSphere]
In-Reply-To: <PR1PR01MB497008B207DF5D8BA1A2382E88609@PR1PR01MB4970.eurprd01.prod.exchangelabs.com>
References: <PR1PR01MB497008B207DF5D8BA1A2382E88609@PR1PR01MB4970.eurprd01.prod.exchangelabs.com>
Message-ID: <CALg0jKnmkw9XHZmG7V=tAK6HT18+YOKs75CaL_Zwt4T0H9g9xg@mail.gmail.com>

Hi,
Nobody worked on vS[here integration recently in Openstack, the last effort
is networking-vsphere, but that is long without maintainers (ocata is the
last branch) as I see:
https://opendev.org/x/networking-vsphere

Best wishes
Lajos (lajoskatona)

SCAGLIA Emanuele (NPO) <emanuele.scaglia at nposervices.com> ezt ?rta
(id?pont: 2023. ?pr. 21., P, 18:29):

> Hello,
>
> I?d like to know if there is in your opinion any chance that the OVSvApp
> solution works with Openstack zed release.
>
> Regarding how to use it, I found this page:
> https://github.com/nephoscale-div/OVSvAPP
>
>
>
> Is it still valid?
>
> Thank you in advance,
>
> Emanuele Scaglia
>
>
>
> *Emanuele Scaglia*
>
> Senior System Engineer
>
> NPO TORINO s.r.l.
>
> <https://www.nposervices.com/>
>
> emanuele.scaglia at nposervices.com
>
> +39 3666180721 <3425965928>
>
> Via Vincenzo Lancia 27, 10141 TORINO
> <https://www.google.com/maps/place/Via+Vincenzo+Lancia,+27,+10141+Torino+TO/@45.0612057,7.6413237,17z/data=!3m1!4b1!4m6!3m5!1s0x47886cdd3eab2711:0xadcede36ced85268!8m2!3d45.0612057!4d7.6413237!16s%2Fg%2F11bw3zvhgq>
>
> *nposervices.com <https://www.nposervices.com/>*
>
> <https://www.facebook.com/>
>
> <https://www.twitter.com/>
>
> <https://www.linkedin.com/>
>
> <https://www.instagram.com/>
>
> <https://www.youtube.com/>
>
> Sede legale: L.go Dora P. Colletta, 81, 10153- Torino
> Tel. +39 011 19701225
> Fax. +39 011 19781413
>
> P. IVA: 10041060012
>
> The content of this email is confidential and intended for the recipient
> specified in message only. It is strictly forbidden to share any part of
> this message with any third party, without a written consent of the sender.
> If you received this message by mistake, please reply to this message and
> follow with its deletion, so that we can ensure such a mistake does not
> occur in the future.
>
>
>
>
> AVVERTENZE AI SENSI DEL D.LGS. 196/2003 . Il contenuto di questo messaggio
> (ed eventuali allegati) e' strettamente confidenziale. L'utilizzo del
> contenuto del messaggio e' riservato esclusivamente al destinatario. La
> modifica, distribuzione, copia del messaggio da parte di altri e'
> severamente proibita. Se non siete i destinatari Vi invitiamo ad informare
> il mittente ed eliminare tutte le copie del suddetto messaggio. The
> contents of this message (and all attachments) are strictly confidential.
> The message is intended exclusively to the addressee. The modification,
> distribution, or replication of the message from others is strictly
> forbidden. If you are not the intended addressee, please notify the sender
> and eliminate all the copies of the message,
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/1c7d0f44/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3878 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/1c7d0f44/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 980 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/1c7d0f44/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 838 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/1c7d0f44/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 1247 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/1c7d0f44/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 1199 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/1c7d0f44/attachment-0014.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 915 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/1c7d0f44/attachment-0015.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image007.png
Type: image/png
Size: 1241 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/1c7d0f44/attachment-0016.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image008.png
Type: image/png
Size: 1017 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/1c7d0f44/attachment-0017.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image009.png
Type: image/png
Size: 1335 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/1c7d0f44/attachment-0018.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image010.png
Type: image/png
Size: 1023 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/1c7d0f44/attachment-0019.png>

From katonalala at gmail.com  Mon Apr 24 06:49:31 2023
From: katonalala at gmail.com (Lajos Katona)
Date: Mon, 24 Apr 2023 08:49:31 +0200
Subject: [OpenvSwitch][Neutron] native flow based firewall Vs LinuxBridge
 Iptables firewall
In-Reply-To: <CAPgF-fqVtNznnbXZPBBzNLbtc-T-a+3KWoktt18xR5suHcktFg@mail.gmail.com>
References: <CAPgF-fqVtNznnbXZPBBzNLbtc-T-a+3KWoktt18xR5suHcktFg@mail.gmail.com>
Message-ID: <CALg0jKmCR65F6ARDs3zeWTCc45PExVWVSrKdWheX_=PNg36ODw@mail.gmail.com>

H,
The OVS flow based Neutron firewall driver is long supported by the
community and used by many operators in production, please check the
documentation:
https://docs.openstack.org/neutron/latest/admin/config-ovsfwdriver.html

For some details how it works please check the related internals doc:
https://docs.openstack.org/neutron/latest/contributor/internals/openvswitch_firewall.html

Best wished
Lajos (lajoskatona)

Satish Patel <satish.txt at gmail.com> ezt ?rta (id?pont: 2023. ?pr. 24., H,
3:40):

> Folks,
>
> As we know, openvswitch uses a linuxbridge based firewall to implement
> security-groups on openstack. It works great but it has so many packet
> hops. It also makes troubleshooting a little complicated.
>
> OpenvSwitch does support native firewall features in flows, Does it mature
> enough to implement in production and replace it with LinuxBridge based
> IPtables firewall?
>
> ~S
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/4adc4d33/attachment.htm>

From zigo at debian.org  Mon Apr 24 08:47:25 2023
From: zigo at debian.org (Thomas Goirand)
Date: Mon, 24 Apr 2023 10:47:25 +0200
Subject: OpenStack Swift quota
In-Reply-To: <SA1PR04MB854472CC6D76D00245BFF81FA9609@SA1PR04MB8544.namprd04.prod.outlook.com>
References: <SA1PR04MB854472CC6D76D00245BFF81FA9609@SA1PR04MB8544.namprd04.prod.outlook.com>
Message-ID: <19abee38-30f0-d45d-75c5-8823aa630c32@debian.org>

On 4/21/23 06:52, Xu, Wei [E CPE] wrote:
> Also, it seems like default OpenStack Swift only supports account-level 
> and container-level quota implementation. Is it possible to implement 
> not only user-level but also project-level and domain-level quotas?

Hi,

When Swift says "account level", it really is about an OpenStack 
project, not about an OpenStack user.

Cheers,

Thomas Goirand (zigo)



From lucasagomes at gmail.com  Mon Apr 24 08:53:44 2023
From: lucasagomes at gmail.com (Lucas Alvares Gomes)
Date: Mon, 24 Apr 2023 09:53:44 +0100
Subject: [neutron] Bug Deputy Report April 17 - 23
Message-ID: <CAB1EZBpNdZsdWgaUZ-MSTJ9eM=oeL58khrTnLAfq8ugAzXCXRw@mail.gmail.com>

Hi,

This is the Neutron bug report from April 17th to 24th.

*High:*

* https://bugs.launchpad.net/neutron/+bug/2016704 -  Listing ports creates
inefficient database query
- Assigned to: Ihtisham ul Haq

* https://bugs.launchpad.net/neutron/+bug/2017145 - [OVN] - Logging
configuration doesn't change after neutron restart
- Assigned to: Elvira Garc?a Ruiz

* https://bugs.launchpad.net/neutron/+bug/2017216 - [ovn-octavia-provider]
batch member update generates out of sync with Octavia DB
- Assigned to: Fernando Royo

*Medium:*

* https://bugs.launchpad.net/neutron/+bug/2016414 - Message when creating
new neutron bugs has outdated links
- Unassigned

* https://bugs.launchpad.net/neutron/+bug/2016862 - [ovn-octavia-provider]
Admin_state_up ignored on create a new member
- Assigned to: Fernando Royo

* https://bugs.launchpad.net/neutron/+bug/2017037 - Improve keepalived test
pid termination
- Assigned to: Miro Tomaska

* https://bugs.launchpad.net/neutron/+bug/2017127 - [ovn-octavia-provider]
Fix member update according to the Octavia API definition
- Assigned to: Fernando Royo

*Low:*

* https://bugs.launchpad.net/neutron/+bug/2016413 - api-ref: missing
documentation for subnet-onboard
- Unassigned

*Wishlist:*

* https://bugs.launchpad.net/neutron/+bug/2016504 -  [rfe]Support specify
fixed_ip_address for DHCP or Metadata port
- Unassigned

* https://bugs.launchpad.net/neutron/+bug/2016960 -  neutron fwaas support
l2 firewall for ovn driver
- Unassigned

*Needs further triage:*

* https://bugs.launchpad.net/neutron/+bug/2017023 -  Tempest: remove test
duplication for Compute legacy networking API and Neutron API calls
- Unassigned

* https://bugs.launchpad.net/neutron/+bug/2017131 - neutron-loki job fails
tests with ORM session: SQL execution without transaction in progress
- Unassigned

Cheers,
Lucas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/e2cae712/attachment.htm>

From kozhukalov at gmail.com  Mon Apr 24 10:40:43 2023
From: kozhukalov at gmail.com (Vladimir Kozhukalov)
Date: Mon, 24 Apr 2023 13:40:43 +0300
Subject: [openstack-helm] Manila chart merged
Message-ID: <CANxTg763p_vtGSpdhUqXSO_fUddzz3tOESJdW+CLamFSWxtBnA@mail.gmail.com>

Hi, everyone

I would like to announce that last week we eventually merged the PR that
adds the Manila chart.

Thanks everyone for their contribution.

-- 
Best regards,
Kozhukalov Vladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/93aa5b57/attachment.htm>

From ralonsoh at redhat.com  Mon Apr 24 12:54:29 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Mon, 24 Apr 2023 14:54:29 +0200
Subject: [neutron] Broken CI "neutron-tempest-plugin-*" jobs
Message-ID: <CAECr9X60eTvydCyUmHg+3o4cZAJZzVdAXd86RMn8+J6Pqvsi8w@mail.gmail.com>

Hello all:

Please hold your rechecks for the "neutron-tempest-plugin-*" jobs. We need
to bump the python version from 3.8 to 3.9. However, due to an issue in
Ubuntu Jammy [1], we are still working with Ubuntu Focal nodes. The problem
in Focal is that uWSGI provided in this version doesn't support python3.9.

We are pushing new patches for Nova and neutron-tempest-plugin to test
possible solutions. If we can't solve this issue, we'll skip these jobs
temporarily.

I'll send an update as soon as possible.

Regards.

[1]https://bugs.launchpad.net/neutron/+bug/1999249
[2]https://review.opendev.org/c/openstack/nova/+/868419
[3]https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/879036
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/d4e35920/attachment.htm>

From saditya at vt.edu  Sun Apr 23 20:39:14 2023
From: saditya at vt.edu (Aditya Sathish)
Date: Sun, 23 Apr 2023 16:39:14 -0400
Subject: Query about RBAC for subnets
Message-ID: <CA+OUCKtim4q8mD+PGdOvBsZDGDCNh7z8nphsnc=s9ULSGjB1Ng@mail.gmail.com>

Hello,

We currently have an external network that is being interfaced from the
physical interface of the compute server to an L3 switch with different
subnets to different services. These services (and, by extension, the
subnets) must be accessed and controlled by the operator to allow a project
only a subset of these services. RBAC can only set rules for the network as
a whole. Can this network be made external but only share a few subnets
with each project?

If not the RBAC way, is there another alternative to achieve the same?

Regards,
Aditya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230423/3d111884/attachment.htm>

From ralonsoh at redhat.com  Mon Apr 24 13:38:08 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Mon, 24 Apr 2023 15:38:08 +0200
Subject: Query about RBAC for subnets
In-Reply-To: <CA+OUCKtim4q8mD+PGdOvBsZDGDCNh7z8nphsnc=s9ULSGjB1Ng@mail.gmail.com>
References: <CA+OUCKtim4q8mD+PGdOvBsZDGDCNh7z8nphsnc=s9ULSGjB1Ng@mail.gmail.com>
Message-ID: <CAECr9X7CG3hHt5HmQR-7ybumJG7CirjYiTxzUsd6wdhFu0S43A@mail.gmail.com>

Hello Aditya:

This is not possible in Neutron. If you want to segregate the traffic, what
I recommend is to create a network per service and each network with the
corresponding subnet. Each external network will be the GW of a router. Any
VM that needs to have access to any service (external network) can create
an internal network and connect it to the corresponding router.

Regards.

On Mon, Apr 24, 2023 at 3:17?PM Aditya Sathish <saditya at vt.edu> wrote:

> Hello,
>
> We currently have an external network that is being interfaced from the
> physical interface of the compute server to an L3 switch with different
> subnets to different services. These services (and, by extension, the
> subnets) must be accessed and controlled by the operator to allow a project
> only a subset of these services. RBAC can only set rules for the network as
> a whole. Can this network be made external but only share a few subnets
> with each project?
>
> If not the RBAC way, is there another alternative to achieve the same?
>
> Regards,
> Aditya
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/b0635a04/attachment.htm>

From gthiemonge at redhat.com  Mon Apr 24 14:15:46 2023
From: gthiemonge at redhat.com (Gregory Thiemonge)
Date: Mon, 24 Apr 2023 16:15:46 +0200
Subject: [neutron] Broken CI "neutron-tempest-plugin-*" jobs
In-Reply-To: <CAECr9X60eTvydCyUmHg+3o4cZAJZzVdAXd86RMn8+J6Pqvsi8w@mail.gmail.com>
References: <CAECr9X60eTvydCyUmHg+3o4cZAJZzVdAXd86RMn8+J6Pqvsi8w@mail.gmail.com>
Message-ID: <CAKsmYT3kEYmu-qQV-cbG=qLGiAko0TROWajCGHwo+0NhJWtLdg@mail.gmail.com>

FYI We are facing the same issue in Octavia, our octavia-tempest-plugin
jobs are still running on focal and they are now failing because of python
3.8.
We cannot update the job to use Jammy because nested virt support is not
really reliable (many crashes on the vexxhost nodes [0] it is the same
issue as the neutron bug [1]), and nested virt is required by Octavia (our
LB is based on a VM). I'm trying to identify the "broken" nodes so we
could report them.

[0] https://bugs.launchpad.net/octavia/+bug/2015244
[1] https://bugs.launchpad.net/neutron/+bug/1999249


On Mon, Apr 24, 2023 at 3:01?PM Rodolfo Alonso Hernandez <
ralonsoh at redhat.com> wrote:

> Hello all:
>
> Please hold your rechecks for the "neutron-tempest-plugin-*" jobs. We need
> to bump the python version from 3.8 to 3.9. However, due to an issue in
> Ubuntu Jammy [1], we are still working with Ubuntu Focal nodes. The problem
> in Focal is that uWSGI provided in this version doesn't support python3.9.
>
> We are pushing new patches for Nova and neutron-tempest-plugin to test
> possible solutions. If we can't solve this issue, we'll skip these jobs
> temporarily.
>
> I'll send an update as soon as possible.
>
> Regards.
>
> [1]https://bugs.launchpad.net/neutron/+bug/1999249
> [2]https://review.opendev.org/c/openstack/nova/+/868419
> [3]https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/879036
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/5f2d0156/attachment.htm>

From sbauza at redhat.com  Mon Apr 24 15:33:04 2023
From: sbauza at redhat.com (Sylvain Bauza)
Date: Mon, 24 Apr 2023 17:33:04 +0200
Subject: [nova][ci] Hold your rechecks
Message-ID: <CALOCmumo-Mo5CY3sg4riEmpeJ+n=s6OHnqPgsVZR2_vKW0U0Wg@mail.gmail.com>

Due to tooz changing their python support to no longer support py3.8 by the
4.0 version, the Nova functional jobs are now blocked until we either block
tooz>=4 in upper-constraints or we completely remove py3.8 support for the
CI jobs we run.

A proposal already exists :
https://review.opendev.org/c/openstack/nova/+/881339

Anyway, hold your rechecks.

-Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/0d2be841/attachment-0001.htm>

From sbauza at redhat.com  Mon Apr 24 16:47:05 2023
From: sbauza at redhat.com (Sylvain Bauza)
Date: Mon, 24 Apr 2023 18:47:05 +0200
Subject: [nova][ci] Hold your rechecks
In-Reply-To: <CALOCmumo-Mo5CY3sg4riEmpeJ+n=s6OHnqPgsVZR2_vKW0U0Wg@mail.gmail.com>
References: <CALOCmumo-Mo5CY3sg4riEmpeJ+n=s6OHnqPgsVZR2_vKW0U0Wg@mail.gmail.com>
Message-ID: <CALOCmukPG__pWW23DGzPx3s6mjEUMXFfFqtUddZNB4OH4tX5CQ@mail.gmail.com>

Le lun. 24 avr. 2023 ? 17:33, Sylvain Bauza <sbauza at redhat.com> a ?crit :

> Due to tooz changing their python support to no longer support py3.8 by
> the 4.0 version, the Nova functional jobs are now blocked until we either
> block tooz>=4 in upper-constraints or we completely remove py3.8 support
> for the CI jobs we run.
>
>
FWIW, a patch to cap tooz to 3.2 is proposed
https://review.opendev.org/c/openstack/requirements/+/881329 which should
help unblocking the gate.

-Sylvain

A proposal already exists :
> https://review.opendev.org/c/openstack/nova/+/881339
>
> Anyway, hold your rechecks.
>
> -Sylvain
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/13ee099f/attachment.htm>

From ralonsoh at redhat.com  Mon Apr 24 17:04:48 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Mon, 24 Apr 2023 19:04:48 +0200
Subject: [neutron] Broken CI "neutron-tempest-plugin-*" jobs
In-Reply-To: <CAKsmYT3kEYmu-qQV-cbG=qLGiAko0TROWajCGHwo+0NhJWtLdg@mail.gmail.com>
References: <CAECr9X60eTvydCyUmHg+3o4cZAJZzVdAXd86RMn8+J6Pqvsi8w@mail.gmail.com>
 <CAKsmYT3kEYmu-qQV-cbG=qLGiAko0TROWajCGHwo+0NhJWtLdg@mail.gmail.com>
Message-ID: <CAECr9X4gCT13FzOi0y-ReTpw8kVq6FD0h70485vTNQBPTGCziw@mail.gmail.com>

Although this is a temporary fix, as you may have read in the Nova thread,
a patch that will limit tooz to 3.2.0 [1] has been proposed. In any case,
we should continue working to support neutron-tempest-plugin in Ubuntu
Jammy nodes.

[1]https://review.opendev.org/c/openstack/requirements/+/881329

On Mon, Apr 24, 2023 at 4:16?PM Gregory Thiemonge <gthiemonge at redhat.com>
wrote:

> FYI We are facing the same issue in Octavia, our octavia-tempest-plugin
> jobs are still running on focal and they are now failing because of python
> 3.8.
> We cannot update the job to use Jammy because nested virt support is not
> really reliable (many crashes on the vexxhost nodes [0] it is the same
> issue as the neutron bug [1]), and nested virt is required by Octavia (our
> LB is based on a VM). I'm trying to identify the "broken" nodes so we
> could report them.
>
> [0] https://bugs.launchpad.net/octavia/+bug/2015244
> [1] https://bugs.launchpad.net/neutron/+bug/1999249
>
>
> On Mon, Apr 24, 2023 at 3:01?PM Rodolfo Alonso Hernandez <
> ralonsoh at redhat.com> wrote:
>
>> Hello all:
>>
>> Please hold your rechecks for the "neutron-tempest-plugin-*" jobs. We
>> need to bump the python version from 3.8 to 3.9. However, due to an issue
>> in Ubuntu Jammy [1], we are still working with Ubuntu Focal nodes. The
>> problem in Focal is that uWSGI provided in this version doesn't support
>> python3.9.
>>
>> We are pushing new patches for Nova and neutron-tempest-plugin to test
>> possible solutions. If we can't solve this issue, we'll skip these jobs
>> temporarily.
>>
>> I'll send an update as soon as possible.
>>
>> Regards.
>>
>> [1]https://bugs.launchpad.net/neutron/+bug/1999249
>> [2]https://review.opendev.org/c/openstack/nova/+/868419
>> [3]https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/879036
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/c9ac5447/attachment.htm>

From satish.txt at gmail.com  Mon Apr 24 17:32:44 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Mon, 24 Apr 2023 13:32:44 -0400
Subject: [OpenvSwitch][Neutron] native flow based firewall Vs LinuxBridge
 Iptables firewall
In-Reply-To: <CALg0jKmCR65F6ARDs3zeWTCc45PExVWVSrKdWheX_=PNg36ODw@mail.gmail.com>
References: <CAPgF-fqVtNznnbXZPBBzNLbtc-T-a+3KWoktt18xR5suHcktFg@mail.gmail.com>
 <CALg0jKmCR65F6ARDs3zeWTCc45PExVWVSrKdWheX_=PNg36ODw@mail.gmail.com>
Message-ID: <CAPgF-fo-yEeWEiYYECdfiPednc8Mbti3zXkZGOYjUbJ8Vq1DFA@mail.gmail.com>

Thanks, I'll check it out.

This is great! so no harm to turn it on :)

On Mon, Apr 24, 2023 at 2:49?AM Lajos Katona <katonalala at gmail.com> wrote:

> H,
> The OVS flow based Neutron firewall driver is long supported by the
> community and used by many operators in production, please check the
> documentation:
> https://docs.openstack.org/neutron/latest/admin/config-ovsfwdriver.html
>
> For some details how it works please check the related internals doc:
>
> https://docs.openstack.org/neutron/latest/contributor/internals/openvswitch_firewall.html
>
> Best wished
> Lajos (lajoskatona)
>
> Satish Patel <satish.txt at gmail.com> ezt ?rta (id?pont: 2023. ?pr. 24., H,
> 3:40):
>
>> Folks,
>>
>> As we know, openvswitch uses a linuxbridge based firewall to implement
>> security-groups on openstack. It works great but it has so many packet
>> hops. It also makes troubleshooting a little complicated.
>>
>> OpenvSwitch does support native firewall features in flows, Does it
>> mature enough to implement in production and replace it with LinuxBridge
>> based IPtables firewall?
>>
>> ~S
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/f78bc2f0/attachment.htm>

From satish.txt at gmail.com  Mon Apr 24 17:34:53 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Mon, 24 Apr 2023 13:34:53 -0400
Subject: [openstack][sharing][kolla ansible]Problems when 1 of 3
 controller was be down
In-Reply-To: <CABAODRfSvRyFSLSvSF_O+HwxDfECBz=PaiYDkx25FSzJQ1VLFA@mail.gmail.com>
References: <5906e729a3a7adf9dea1fcd47aade4e9a0688e7d.camel@redhat.com>
 <A6BEA46C-87FA-42C5-8384-8D86ED790B5C@gmail.com>
 <4ffc9821-4edc-de97-a0ed-d87355bc4241@stackhpc.com>
 <CABAODRfSvRyFSLSvSF_O+HwxDfECBz=PaiYDkx25FSzJQ1VLFA@mail.gmail.com>
Message-ID: <CAPgF-frf7816FKooH4bi+B2j_AbposK1XeLmqY3S3HY4DrAiPA@mail.gmail.com>

Oh wait! What is the relation of Rabbit mirror queue with Ceph/NFS or any
shared storage backend?

On Mon, Apr 24, 2023 at 2:17?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Hi everyone,
> I update that. With failover controller, we dont need use mirror queue if
> we use ceph as backend. In my case, I use SAN as cinder backend and NFS as
> glance backend so I need mirror queue. It is quite weird.
> Nguyen Huu Khoi
>
>
> On Mon, Apr 17, 2023 at 5:03?PM Doug Szumski <doug at stackhpc.com> wrote:
>
>> On 13/04/2023 23:04, Satish Patel wrote:
>> > Thank Sean/Matt,
>> >
>> > This is interesting that I have only option to use classic mirror with
>> durable :( because without mirror cluster acting up when one of node is
>> down.
>>
>> If you have planned maintenance and non-mirrored transient queues, you
>> can first try draining the node to be removed, before removing it from
>> the cluster. In my testing at least, this appears to be much more
>> successful than relying on the RabbitMQ clients to do the failover and
>> recreate queues.  See [1], or for RMQ <3.8 you can cobble something
>> together with ha-mode nodes [2].
>>
>> [1] https://www.rabbitmq.com/upgrade.html#maintenance-mode
>>
>> [2] https://www.rabbitmq.com/ha.html#mirroring-arguments
>>
>> This obviously doesn't solve the case of when a controller fails
>> unexpectedly.
>>
>> I also think it's worth making the distinction between a highly
>> available messaging infrastructure, and queue mirroring. In many cases,
>> if a RMQ node hosting a non-mirrored, transient queue goes down, it
>> should be possible for a service to just recreate the queue on another
>> node and retry. This often seems to fail, which leads to queue mirroring
>> getting turned on.
>>
>> >
>> > How people are scaling rabbitMQ for large scale?
>> >
>> > Sent from my iPhone
>> >
>> >> On Apr 13, 2023, at 7:50 AM, Sean Mooney <smooney at redhat.com> wrote:
>> >>
>> >> ?On Thu, 2023-04-13 at 09:07 +0100, Matt Crees wrote:
>> >>> Hi all, I'll reply in turn here:
>> >>>
>> >>> Radek, I agree it definitely will be a good addition to the KA docs.
>> >>> I've got it on my radar, will aim to get a patch proposed this week.
>> >>>
>> >>> Satish, I haven't personally been able to test durable queues on a
>> >>> system that large. According to the RabbitMQ docs
>> >>> (https://www.rabbitmq.com/queues.html#durability), "Throughput and
>> >>> latency of a queue is not affected by whether a queue is durable or
>> >>> not in most cases." However, I have anecdotally heard that it can
>> >>> affect some performance in particularly large systems.
>> >> the perfomacne of durable queue is dominated by the disk io
>> >> put rabbit on a pcie nvme ssd and it will have littel effect
>> >> use spinnign rust (a HDD even in raid 10) and the iops/throput of the
>> >> storage sued to make the qure durible (that just mean write all
>> messages to disk)
>> >> will be the bottlenck for scaleablity
>> >> combine that with HA and that is worse as it has to be writen to
>> multipel servers.
>> >> i belive that teh mirror implemantion will wait for all copies to be
>> persisted
>> >> but i have not really looked into it. it was raised as a pain point
>> with rabbit by
>> >> operator in the past in terms fo scaling.
>> >>
>> >>> Please note that if you are using the classic mirrored queues, you
>> >>> must also have them durable. Transient (i.e. non-durable) mirrored
>> >>> queues are not a supported feature and do cause bugs. (For example the
>> >>> "old incarnation" errors seen here:
>> >>> https://bugs.launchpad.net/kolla-ansible/+bug/1954925)
>> >>>
>> >>> Nguyen, I can confirm that we've seen the same behaviour. This is
>> >>> caused by a backported change in oslo.messaging (I believe you linked
>> >>> the relevant bug report previously). There is a fix in progress to fix
>> >>> this (https://review.opendev.org/c/openstack/oslo.messaging/+/866617
>> ),
>> >>> and in the meantime setting kombu_reconnect_delay < 1.0 does resolve
>> >>> it.
>> >>>
>> >>> Cheers,
>> >>> Matt
>> >>>
>> >>>> On Thu, 13 Apr 2023 at 03:04, Nguy?n H?u Kh?i <
>> nguyenhuukhoinw at gmail.com> wrote:
>> >>>>
>> >>>> update:
>> >>>> I use SAN as Cinder backend.
>> >>>> Nguyen Huu Khoi
>> >>>>
>> >>>>
>> >>>> On Thu, Apr 13, 2023 at 9:02?AM Nguy?n H?u Kh?i <
>> nguyenhuukhoinw at gmail.com> wrote:
>> >>>>> Hello guys.
>> >>>>>
>> >>>>> I do many tests on xena and yoga. then i am sure that without
>> ha-queue and kombu_reconnect_delay=0.5(it can < 1)
>> >>>>> you cannot launch instances when 1 of 3 controllers is down.
>> >>>>> Somebody can verify what I say, I hope we will have a common
>> solution for this problem because those who use openstack for the first
>> time will continue to ask questions like that.
>> >>>>>
>> >>>>> Nguyen Huu Khoi
>> >>>>>
>> >>>>>
>> >>>>> On Thu, Apr 13, 2023 at 12:59?AM Satish Patel <satish.txt at gmail.com>
>> wrote:
>> >>>>>> This is great! Matt,
>> >>>>>>
>> >>>>>> Documentation would be greatly appreciated. I have a counter
>> question: does Durable queue be good for large clouds with 1000 compute
>> nodes or better to not use durable queue. This is a private cloud and we
>> don't care about persistent data.
>> >>>>>>
>> >>>>>> On Wed, Apr 12, 2023 at 12:37?PM Rados?aw Piliszek <
>> radoslaw.piliszek at gmail.com> wrote:
>> >>>>>>> Hi Matt,
>> >>>>>>>
>> >>>>>>>> As you're now reconfiguring a running deployment, there are
>> >>>>>>>> some extra steps that need to be taken to migrate to durable
>> queues.
>> >>>>>>>>
>> >>>>>>>> 1. You will need to stop the OpenStack services which use
>> RabbitMQ.
>> >>>>>>>>
>> >>>>>>>> 2. Reset the state of RabbitMQ one each rabbit node with the
>> following
>> >>>>>>>> commands. You must run each command on all RabbitMQ nodes before
>> >>>>>>>> moving on to the next command. This will remove all queues.
>> >>>>>>>>
>> >>>>>>>>     rabbitmqctl stop_app
>> >>>>>>>>     rabbitmqctl force_reset
>> >>>>>>>>     rabbitmqctl start_app
>> >>>>>>>>
>> >>>>>>>> 3. Start the OpenStack services again, at which point they will
>> >>>>>>>> recreate the appropriate queues as durable.
>> >>>>>>> This sounds like a great new addition-to-be to the Kolla Ansible
>> docs!
>> >>>>>>> Could you please propose it as a change?
>> >>>>>>>
>> >>>>>>> Kindest,
>> >>>>>>> Radek
>> >>>>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/a86635b1/attachment-0001.htm>

From Jeanpierre.Roquesalane at dell.com  Mon Apr 24 14:28:45 2023
From: Jeanpierre.Roquesalane at dell.com (Roquesalane, Jean-Pierre)
Date: Mon, 24 Apr 2023 14:28:45 +0000
Subject: [cinder] - Test cases or procedure for active/active support
 validation
Message-ID: <DM6PR19MB344934DBBB7E3F81986AA1E0EB679@DM6PR19MB3449.namprd19.prod.outlook.com>

Hi community!

Here at Dell, we're in the process of certifying our Dell PowerMax storage platform against cinder volume Active/active configuration. I was wondering how vendors who already support this functionality have managed to handle this and if they can share their testing scenario.

Thank you.

JP

Jean-Pierre Roquesalane
SW System Sr Principal Engineer - OpenStack Champion
Dell Technologies | Security and Ecosystem Software
Mobile +33 6 21 86 79 04<tel:1-613-314-8106>
Email : jeanpierre.roquesalane at dell.com<mailto:jeanpierre.roquesalane at dell.com>
[cid:image001.png at 01D976C9.D5B91180]



Internal Use - Confidential

Dell S.A, Si?ge Social 1 rond point Benjamin Franklin 34000 Montpellier. Capital 1,782,769 Euros, 351 528 229 RCS Montpellier -APE 4651Z -TVA Intracommunautaire FR 20 351 528 229, SIRET 351 528 229 00088 Vat Number : FR 20351528229 (France) / IT00001709997 (Italy) / ESN0012622G (Spain)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/5b9261ee/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 88008 bytes
Desc: image001.png
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/5b9261ee/attachment-0001.png>

From david at octapus.io  Mon Apr 24 15:03:01 2023
From: david at octapus.io (=?UTF-8?Q?David_Francisco_Le=C3=B3n_Vera?=)
Date: Mon, 24 Apr 2023 09:03:01 -0600
Subject: VM doesn't boot after qemu-img convert from VMDK to RAW/QCOW2 Edit
Message-ID: <CAF6XWq7+GZXQ+brHRiUPOgu_QrBJs+Tq27Q46Qxv=jgVXAn1Yw@mail.gmail.com>

Hi!

Can someone help me? I have an issue migrating VMWare VMs to OpenStack with
KVM-QEMU ... the VMDK file converted to qcow2 format doesn't boot,
especially with Windows Server 2016 and 2019. I tried a lot of ways, but I
still finish with an unbootable disk in Nova.

I explained with more details my problem here:
https://bugs.launchpad.net/nova/+bug/2017358

-- 


Before printing, think about your responsibility and commitment to the 
ENVIRONMENT.


The information contained in this email and in any attached 
file is sent only for the use of the person or entity to which it is 
addressed and / or authorized third parties. This release may contain 
confidential and / or legally privileged information. If you are not the 
recipient or have received this email in error, we request that you notify 
the sender of this message and destroy this email, its attachments, and any 
copies or backups thereof immediately. If you are not the indicated 
recipient, you are notified that the total or partial distribution, 
printing or reproduction of this message is strictly prohibited, it could 
be considered illegal and sent to the corresponding authorities.

Emails 
are not necessarily a secure means of transmission, so the sender will not 
be responsible at any time for the changes in your transfer, for attacks in 
the medium, so no responsibility is assumed in case of mutations in their 
transfer and it will always be necessary for the recipient to check them 
before opening them. Octapus is not responsible for the correct and 
complete transmission of the information contained in this communication, 
nor for any delay in receiving it.



If you want to know about our privacy 
notice, go to:? 
<https://on-cloud.com/avisos-de-privacidad/>https://octapus.io/aviso-de-privacidad/ 
<https://octapus.io/aviso-de-privacidad/>







Antes de imprimir piense 
en su responsabilidad y compromiso con el MEDIO AMBIENTE.
La informaci?n 
contenida en este correo electr?nico y en cualquier archivo adjunto es 
enviada ?nicamente para el uso de la persona o entidad a quien est? 
dirigida y/o terceros autorizados. Este comunicado puede contener 
informaci?n confidencial y/o legalmente privilegiada. Si usted no es el 
destinatario o ha recibido este correo por error, le solicitamos notificar 
al emisor de este mensaje y destruir este correo, sus archivos adjuntos y 
cualquier copia o respaldo del mismo inmediatamente. Si usted no es el 
destinatario indicado, queda notificado que la distribuci?n, impresi?n o 
reproducci?n, total o parcial del presente mensaje est? estrictamente 
prohibida, podr?a ser considerado ilegal y remitido a las autoridades 
correspondientes.
Los correos electr?nicos no son necesariamente un medio 
de transmisi?n seguro, por lo que el remitente no ser? responsable en 
ning?n momento por los cambios que se sufra en su transferencia, por 
ataques en el medio, por lo que tampoco se asume ninguna responsabilidad en 
caso de mutaciones en su transferencia y ser? siempre necesario para el 
destinatario revisarlos antes de abrirlos.? Octapus no es responsable por 
la correcta y completa transmisi?n de la informaci?n contenida en esta 
comunicaci?n, y tampoco por cualquier retraso en su recepci?n.
Si usted 
desea conocer sobre nuestro aviso de privacidad, ingresa a:?? 
<https://on-cloud.com/avisos-de-privacidad/>https://octapus.io/aviso-de-privacidad/ 
<https://octapus.io/aviso-de-privacidad/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/31f89ab3/attachment.htm>

From weixu at iastate.edu  Mon Apr 24 18:34:48 2023
From: weixu at iastate.edu (Xu, Wei [E CPE])
Date: Mon, 24 Apr 2023 18:34:48 +0000
Subject: OpenStack Swift quota
In-Reply-To: <19abee38-30f0-d45d-75c5-8823aa630c32@debian.org>
References: <SA1PR04MB854472CC6D76D00245BFF81FA9609@SA1PR04MB8544.namprd04.prod.outlook.com>
 <19abee38-30f0-d45d-75c5-8823aa630c32@debian.org>
Message-ID: <SA1PR04MB85448F20BE1BBF164ECC9774A9679@SA1PR04MB8544.namprd04.prod.outlook.com>

Hello Thomas,

Thank you very much for the clarification! Right now, this is exactly what we have been trying to do.

I mentioned the authentication issue (Getting 403 forbidden error when attempting to implement account quota even already with Reseller/ResellerAdmin role) in the previous email. Do you have any clues about it? Are there any possible solutions?

I'm looking forward to hearing from you!

Yours sincerely,

Wei Xu, M.S.
Research Assistant
Department of ECpE,
Iowa State University
________________________________
From: Thomas Goirand <zigo at debian.org>
Sent: Monday, April 24, 2023 3:47 AM
To: Xu, Wei [E CPE] <weixu at iastate.edu>; openstack-discuss at lists.openstack.org <openstack-discuss at lists.openstack.org>
Cc: Babu, Sarath [E CPE] <sarath4 at IASTATE.EDU>
Subject: Re: OpenStack Swift quota

On 4/21/23 06:52, Xu, Wei [E CPE] wrote:
> Also, it seems like default OpenStack Swift only supports account-level
> and container-level quota implementation. Is it possible to implement
> not only user-level but also project-level and domain-level quotas?

Hi,

When Swift says "account level", it really is about an OpenStack
project, not about an OpenStack user.

Cheers,

Thomas Goirand (zigo)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230424/9ed465eb/attachment.htm>

From knikolla at bu.edu  Mon Apr 24 21:25:11 2023
From: knikolla at bu.edu (Nikolla, Kristi)
Date: Mon, 24 Apr 2023 21:25:11 +0000
Subject: [tc] Next Technical Committee weekly meeting to be held on April 25, 
 2023
Message-ID: <D5CB88D0-B594-4CC1-804A-B878DEF1DD25@bu.edu>

Hi all,

This is a reminder that the next weekly Technical Committee meeting is to be held on Tuesday (April 25) at 1800 UTC on #openstack-tc on OFTC IRC

Items can be proposed by editing the wiki page at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

Unless there are last minute additions (for which I will send a follow-up email) the agenda will be:

* Roll call
* Follow up on past action items
* Gate health check
* 2023.2 cycle Leaderless projects
	** https://etherpad.opendev.org/p/2023.2-leaderless
* Broken docs due to inconsistent release naming
* Following new release naming convention by packagers (UCA/RDO)
* Schedule of removing support for Python versions by libraries - how it should align with coordinated releases (tooz case)
* Recurring tasks check
	** Bare 'recheck' state
		*** https://etherpad.opendev.org/p/recheck-weekly-summary
* Open Reviews
	** https://review.opendev.org/q/projects:openstack/governance+is:open

Thank you,
Kristi Nikolla

From jonathan.rosser at rd.bbc.co.uk  Tue Apr 25 07:13:56 2023
From: jonathan.rosser at rd.bbc.co.uk (Jonathan Rosser)
Date: Tue, 25 Apr 2023 08:13:56 +0100
Subject: [openstack-ansible] Proposing Neil Hanlon for core reviewer
In-Reply-To: <CAPd_6AuUW5bN=rfdOJ1yK98b_BYsSvADHBt=iSQZYBiZnUT_CQ@mail.gmail.com>
References: <CAPd_6AuUW5bN=rfdOJ1yK98b_BYsSvADHBt=iSQZYBiZnUT_CQ@mail.gmail.com>
Message-ID: <f0b5954c-846a-f302-72bb-08a4d0e469de@rd.bbc.co.uk>

This would be great. +2 from me.

Jon.

On 18/04/2023 20:00, Dmitriy Rabotyagov wrote:
> Hi everyone,
>
> I'm pleased to propose Neil Hanlon as OpenStack-Ansible Core Reviewer.
> Neil has helped us a lot lately with maintenance of RHEL-like distros
> -
> both CentOS Stream and Rocky Linux, and basically has brought in
> support for the last one.
>
> Neil is present at meetings and always is responsive in IRC. At the
> same time they were providing useful reviews lately [1]
>
> If there are no objections, I will add Neil to the team on 25th of
> April 2023. Until then, please feel free to provide your
> feedback/opinions on the matter.
>
> [1] https://www.stackalytics.io/report/contribution?module=openstackansible-group&project_type=openstack&days=120
>
>


From ralonsoh at redhat.com  Tue Apr 25 08:00:57 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Tue, 25 Apr 2023 10:00:57 +0200
Subject: [neutron] Broken CI "neutron-tempest-plugin-*" jobs
In-Reply-To: <CAECr9X4gCT13FzOi0y-ReTpw8kVq6FD0h70485vTNQBPTGCziw@mail.gmail.com>
References: <CAECr9X60eTvydCyUmHg+3o4cZAJZzVdAXd86RMn8+J6Pqvsi8w@mail.gmail.com>
 <CAKsmYT3kEYmu-qQV-cbG=qLGiAko0TROWajCGHwo+0NhJWtLdg@mail.gmail.com>
 <CAECr9X4gCT13FzOi0y-ReTpw8kVq6FD0h70485vTNQBPTGCziw@mail.gmail.com>
Message-ID: <CAECr9X7C7OcxozC5ommR0BhcEiKdERkNQONq1tF=JWeUzqS2wQ@mail.gmail.com>

Hello all:

After capping the tooz version to 3.2.0 [1], we have reverted the patch
that set the Neutron minimum version to 3.9 [2]. But we are committed,
during this release, to move to Ubuntu Jammy and push again the minimum
version of python to 3.9. Once we solve the problems we have with nested
virt nodes in this Ubuntu version [3], we'll be able to move forward.

Last but not least, the Neutron CI is working again.

Regards.

[1]
https://review.opendev.org/c/openstack/requirements/+/881329/1/upper-constraints.txt
[2]https://review.opendev.org/c/openstack/neutron/+/881430
[3]https://bugs.launchpad.net/neutron/+bug/1999249

On Mon, Apr 24, 2023 at 7:04?PM Rodolfo Alonso Hernandez <
ralonsoh at redhat.com> wrote:

> Although this is a temporary fix, as you may have read in the Nova thread,
> a patch that will limit tooz to 3.2.0 [1] has been proposed. In any case,
> we should continue working to support neutron-tempest-plugin in Ubuntu
> Jammy nodes.
>
> [1]https://review.opendev.org/c/openstack/requirements/+/881329
>
> On Mon, Apr 24, 2023 at 4:16?PM Gregory Thiemonge <gthiemonge at redhat.com>
> wrote:
>
>> FYI We are facing the same issue in Octavia, our octavia-tempest-plugin
>> jobs are still running on focal and they are now failing because of python
>> 3.8.
>> We cannot update the job to use Jammy because nested virt support is not
>> really reliable (many crashes on the vexxhost nodes [0] it is the same
>> issue as the neutron bug [1]), and nested virt is required by Octavia (our
>> LB is based on a VM). I'm trying to identify the "broken" nodes so we
>> could report them.
>>
>> [0] https://bugs.launchpad.net/octavia/+bug/2015244
>> [1] https://bugs.launchpad.net/neutron/+bug/1999249
>>
>>
>> On Mon, Apr 24, 2023 at 3:01?PM Rodolfo Alonso Hernandez <
>> ralonsoh at redhat.com> wrote:
>>
>>> Hello all:
>>>
>>> Please hold your rechecks for the "neutron-tempest-plugin-*" jobs. We
>>> need to bump the python version from 3.8 to 3.9. However, due to an issue
>>> in Ubuntu Jammy [1], we are still working with Ubuntu Focal nodes. The
>>> problem in Focal is that uWSGI provided in this version doesn't support
>>> python3.9.
>>>
>>> We are pushing new patches for Nova and neutron-tempest-plugin to test
>>> possible solutions. If we can't solve this issue, we'll skip these jobs
>>> temporarily.
>>>
>>> I'll send an update as soon as possible.
>>>
>>> Regards.
>>>
>>> [1]https://bugs.launchpad.net/neutron/+bug/1999249
>>> [2]https://review.opendev.org/c/openstack/nova/+/868419
>>> [3]
>>> https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/879036
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230425/7cea9d49/attachment.htm>

From ralonsoh at redhat.com  Tue Apr 25 09:09:36 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Tue, 25 Apr 2023 11:09:36 +0200
Subject: [neutron] Deprecated support for Windows OS
Message-ID: <CAECr9X5JiocYUoZbLnU3XoPyGGhrFkSwg+7q57CRjNer8XnSZQ@mail.gmail.com>

Hello Neutrinos:

During this release, Neutron is dropping the support for Windows OS [1] and
will be removed in 2024.2. This decision [2] was taken after the
announcement of the current Winstacker mantainers to step down from this
project.

Regards.

[1]https://review.opendev.org/c/openstack/neutron/+/880980
[2]
https://meetings.opendev.org/meetings/networking/2023/networking.2023-04-18-14.01.log.html#l-66
[3]
https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230425/b0460fc1/attachment.htm>

From zigo at debian.org  Tue Apr 25 14:49:52 2023
From: zigo at debian.org (Thomas Goirand)
Date: Tue, 25 Apr 2023 16:49:52 +0200
Subject: OpenStack Swift quota
In-Reply-To: <SA1PR04MB85448F20BE1BBF164ECC9774A9679@SA1PR04MB8544.namprd04.prod.outlook.com>
References: <SA1PR04MB854472CC6D76D00245BFF81FA9609@SA1PR04MB8544.namprd04.prod.outlook.com>
 <19abee38-30f0-d45d-75c5-8823aa630c32@debian.org>
 <SA1PR04MB85448F20BE1BBF164ECC9774A9679@SA1PR04MB8544.namprd04.prod.outlook.com>
Message-ID: <cccee798-6f57-4b72-4e88-1cf57416277f@debian.org>

On 4/24/23 20:34, Xu, Wei [E CPE] wrote:
> Hello Thomas,
> 
> Thank you very much for the clarification! Right now, this is exactly 
> what we have been trying to do.
> 
> I mentioned the authentication issue (Getting 403 forbidden error when 
> attempting to implement account quota even already with 
> Reseller/ResellerAdmin role) in the previous email. Do you have any 
> clues about it? Are there any possible solutions?
> 
> I'm looking forward to hearing from you!
> 
> Yours sincerely,

Hi,

As admin, use:

swift --os-storage-url  https://<proxy-url>/v1/AUTH_<PROJECT-ID> \
	post -m quota-bytes:<value>

I hope this helps,

Thomas Goirand (zigo)



From tobias.rydberg at cleura.com  Tue Apr 25 15:22:14 2023
From: tobias.rydberg at cleura.com (Tobias Rydberg)
Date: Tue, 25 Apr 2023 17:22:14 +0200
Subject: [publiccloud-sig] Bi-weekly meeting reminder
Message-ID: <933a3548-8f8f-ba34-6ef1-9062a0b8b8f2@cleura.com>

Hi everyone,

Tomorrow it's time again for our bi-weekly meeting, 0800 UTC in 
#openstack-operators. Etherpad can be found here [0].

Hope to chat with you tomorrow!

[0] https://etherpad.opendev.org/p/publiccloud-sig-meeting

BR,
Tobias Rydberg

-- 
*Tobias Rydberg*
Solution Architect

Email: tobias.rydberg at cleura.com

cleura.com <https://cleura.com/> ? The European cloud!

Read our press release ? City Network becomes Cleura 
<https://cleura.com/press-releases/city-network-becomes-cleura/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230425/6a6459af/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3626 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230425/6a6459af/attachment.bin>

From sbauza at redhat.com  Tue Apr 25 15:45:22 2023
From: sbauza at redhat.com (Sylvain Bauza)
Date: Tue, 25 Apr 2023 17:45:22 +0200
Subject: [nova][ci] Hold your rechecks
In-Reply-To: <CALOCmukPG__pWW23DGzPx3s6mjEUMXFfFqtUddZNB4OH4tX5CQ@mail.gmail.com>
References: <CALOCmumo-Mo5CY3sg4riEmpeJ+n=s6OHnqPgsVZR2_vKW0U0Wg@mail.gmail.com>
 <CALOCmukPG__pWW23DGzPx3s6mjEUMXFfFqtUddZNB4OH4tX5CQ@mail.gmail.com>
Message-ID: <CALOCmukRzDWOQE+05ZyzrpRyUS0bsfZBOi8GdgpQDvDMNbNOCA@mail.gmail.com>

Le lun. 24 avr. 2023 ? 18:47, Sylvain Bauza <sbauza at redhat.com> a ?crit :

>
>
> Le lun. 24 avr. 2023 ? 17:33, Sylvain Bauza <sbauza at redhat.com> a ?crit :
>
>> Due to tooz changing their python support to no longer support py3.8 by
>> the 4.0 version, the Nova functional jobs are now blocked until we either
>> block tooz>=4 in upper-constraints or we completely remove py3.8 support
>> for the CI jobs we run.
>>
>>
> FWIW, a patch to cap tooz to 3.2 is proposed
> https://review.opendev.org/c/openstack/requirements/+/881329 which should
> help unblocking the gate.
>
>
Unfortunately, our gate is still blocked because now, some other libraries
changed their python requirements too [1]
While we try to revert some of those constraints, we will try to no longer
run our Focal jobs in the CI by
https://review.opendev.org/c/openstack/nova/+/881409 or by
https://review.opendev.org/c/openstack/nova/+/881339

Eventually, we also need to wait for
https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/881479 and
https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/865315 to be
merged.

-Sylvain

[1] https://review.opendev.org/c/openstack/requirements/+/879915

-Sylvain
>
> A proposal already exists :
>> https://review.opendev.org/c/openstack/nova/+/881339
>>
>> Anyway, hold your rechecks.
>>
>> -Sylvain
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230425/827d7e6e/attachment.htm>

From gmann at ghanshyammann.com  Tue Apr 25 19:19:37 2023
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Tue, 25 Apr 2023 12:19:37 -0700
Subject: [all][tc][release] Hold the Python3.8 dropping
Message-ID: <187b9db6cd1.d4ef9f41524517.2257044958377593573@ghanshyammann.com>

Hello Everyone,

As you know the gate is breaking due to  Python3.8 drop[1][2], which we discussed in the TC channel
and meeting[3]. TC is preparing the guidelines on not dropping  Python3.8 in 2023.2 pti.

Meanwhile, governance guidelines are prepared, this email is a heads-up to hold the
dropping of Python3.8 from your project/repo. Do not bump the min py version in
setup.cfg (do not bump version in python_requires ).

@Release team,
It will be helpful if you can check/hold the release of any project/lib dropping the  Python3.8.

[1] https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033450.html
[2] https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033454.html
[3] https://meetings.opendev.org/meetings/tc/2023/tc.2023-04-25-18.00.log.html#l-191

-gmann


From weixu at iastate.edu  Tue Apr 25 20:39:02 2023
From: weixu at iastate.edu (Xu, Wei [E CPE])
Date: Tue, 25 Apr 2023 20:39:02 +0000
Subject: OpenStack Swift quota
In-Reply-To: <cccee798-6f57-4b72-4e88-1cf57416277f@debian.org>
References: <SA1PR04MB854472CC6D76D00245BFF81FA9609@SA1PR04MB8544.namprd04.prod.outlook.com>
 <19abee38-30f0-d45d-75c5-8823aa630c32@debian.org>
 <SA1PR04MB85448F20BE1BBF164ECC9774A9679@SA1PR04MB8544.namprd04.prod.outlook.com>
 <cccee798-6f57-4b72-4e88-1cf57416277f@debian.org>
Message-ID: <SA1PR04MB8544F697E51FEBA8EEC20FF7A9649@SA1PR04MB8544.namprd04.prod.outlook.com>

Hello Thomas,

We have just tried the command you provided, however it is showing the exact same error we had before. Is it likely to be some configuration error? Or there're some other roles that this admin user must obtain?

[cid:9f3afe5e-0b85-4bae-830e-4378c7483b6b]

[cid:7a469a71-b579-446a-bde3-587a69ea3a83]

We'll be looking forward to hearing from you. Thanks again!

Yours sincerely,

Wei Xu, M.S.
Research Assistant
Department of ECpE,
Iowa State University
________________________________
From: Thomas Goirand <zigo at debian.org>
Sent: Tuesday, April 25, 2023 9:49 AM
To: Xu, Wei [E CPE] <weixu at iastate.edu>; openstack-discuss at lists.openstack.org <openstack-discuss at lists.openstack.org>
Cc: Babu, Sarath [E CPE] <sarath4 at IASTATE.EDU>
Subject: Re: OpenStack Swift quota

On 4/24/23 20:34, Xu, Wei [E CPE] wrote:
> Hello Thomas,
>
> Thank you very much for the clarification! Right now, this is exactly
> what we have been trying to do.
>
> I mentioned the authentication issue (Getting 403 forbidden error when
> attempting to implement account quota even already with
> Reseller/ResellerAdmin role) in the previous email. Do you have any
> clues about it? Are there any possible solutions?
>
> I'm looking forward to hearing from you!
>
> Yours sincerely,

Hi,

As admin, use:

swift --os-storage-url  https://<proxy-url>/v1/AUTH_<PROJECT-ID> \
        post -m quota-bytes:<value>

I hope this helps,

Thomas Goirand (zigo)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230425/2ed1d45a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2023-04-25 15-28-32.png
Type: image/png
Size: 38032 bytes
Desc: Screenshot from 2023-04-25 15-28-32.png
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230425/2ed1d45a/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2023-04-25 15-37-11.png
Type: image/png
Size: 91904 bytes
Desc: Screenshot from 2023-04-25 15-37-11.png
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230425/2ed1d45a/attachment-0003.png>

From nguyenhuukhoinw at gmail.com  Wed Apr 26 01:08:09 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Wed, 26 Apr 2023 08:08:09 +0700
Subject: [kolla-ansible][swift][ceph]
Message-ID: <CABAODRc1SLeGT4oxH0srAp8nL06_iNrcTLQioGg1w948SBUSGg@mail.gmail.com>

Hello guys.
I am working to make openstack swift save data on ceph. I am using kolla
ansible and see it need enable swift first but I don't want to make swift
ring on my controller. I just want use external ceph.
Pls you give me some advices
Thank you
Nguyen Huu Khoi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/a36c4ff6/attachment.htm>

From zigo at debian.org  Wed Apr 26 06:38:05 2023
From: zigo at debian.org (Thomas Goirand)
Date: Wed, 26 Apr 2023 08:38:05 +0200
Subject: OpenStack Swift quota
In-Reply-To: <SA1PR04MB8544F697E51FEBA8EEC20FF7A9649@SA1PR04MB8544.namprd04.prod.outlook.com>
References: <SA1PR04MB854472CC6D76D00245BFF81FA9609@SA1PR04MB8544.namprd04.prod.outlook.com>
 <19abee38-30f0-d45d-75c5-8823aa630c32@debian.org>
 <SA1PR04MB85448F20BE1BBF164ECC9774A9679@SA1PR04MB8544.namprd04.prod.outlook.com>
 <cccee798-6f57-4b72-4e88-1cf57416277f@debian.org>
 <SA1PR04MB8544F697E51FEBA8EEC20FF7A9649@SA1PR04MB8544.namprd04.prod.outlook.com>
Message-ID: <fb5d37ba-1344-16e8-f2bf-f469afd696b6@debian.org>

On 4/25/23 22:39, Xu, Wei [E CPE] wrote:
> Hello Thomas,
> 
> We have just tried the command you provided, however it is showing the 
> exact same error we had before. Is it likely to be some configuration 
> error? Or there're some other roles that this admin user must obtain?

It's likely that the error message is right by saying "forbidden", ie, 
you don't have enough right (so, the 2nd possibility...).

Cheers,

Thomas Goirand (zigo)



From josephine.seifert at secustack.com  Wed Apr 26 07:26:54 2023
From: josephine.seifert at secustack.com (Josephine Seifert)
Date: Wed, 26 Apr 2023 09:26:54 +0200
Subject: [Image Encryption] No meeting on May 1st
Message-ID: <eed7cae9-13cd-3c12-2e17-a619347893e9@secustack.com>

Hi,

due to a national holiday there will be no meeting on May the 1st.

regards,
Jospehine (Luzi)



From Danny.Webb at thehutgroup.com  Wed Apr 26 08:50:24 2023
From: Danny.Webb at thehutgroup.com (Danny Webb)
Date: Wed, 26 Apr 2023 08:50:24 +0000
Subject: [kolla-ansible][swift][ceph]
In-Reply-To: <CABAODRc1SLeGT4oxH0srAp8nL06_iNrcTLQioGg1w948SBUSGg@mail.gmail.com>
References: <CABAODRc1SLeGT4oxH0srAp8nL06_iNrcTLQioGg1w948SBUSGg@mail.gmail.com>
Message-ID: <LO2P265MB5773F165E355BDCA0C7F811A9A659@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>

So if I remember correctly from when we did this a long while back, you don't really do much on the openstack deployment side.   Ceph comes with a swift compliant interface so the only thing required was in the ceph.conf to enable keystone as an authentication mechanism.
________________________________
From: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
Sent: 26 April 2023 02:08
To: OpenStack Discuss <openstack-discuss at lists.openstack.org>
Subject: [kolla-ansible][swift][ceph]


CAUTION: This email originates from outside THG

________________________________
Hello guys.
I am working to make openstack swift save data on ceph. I am using kolla ansible and see it need enable swift first but I don't want to make swift ring on my controller. I just want use external ceph.
Pls you give me some advices
Thank you
Nguyen Huu Khoi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/e8227a45/attachment.htm>

From Danny.Webb at thehutgroup.com  Wed Apr 26 08:51:07 2023
From: Danny.Webb at thehutgroup.com (Danny Webb)
Date: Wed, 26 Apr 2023 08:51:07 +0000
Subject: [kolla-ansible][swift][ceph]
In-Reply-To: <LO2P265MB5773F165E355BDCA0C7F811A9A659@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
References: <CABAODRc1SLeGT4oxH0srAp8nL06_iNrcTLQioGg1w948SBUSGg@mail.gmail.com>
 <LO2P265MB5773F165E355BDCA0C7F811A9A659@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <LO2P265MB577320D0FABCCE59432F22D09A659@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>

https://docs.ceph.com/en/latest/radosgw/keystone/
________________________________
From: Danny Webb <Danny.Webb at thehutgroup.com>
Sent: 26 April 2023 09:50
To: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>; OpenStack Discuss <openstack-discuss at lists.openstack.org>
Subject: Re: [kolla-ansible][swift][ceph]

So if I remember correctly from when we did this a long while back, you don't really do much on the openstack deployment side.   Ceph comes with a swift compliant interface so the only thing required was in the ceph.conf to enable keystone as an authentication mechanism.
________________________________
From: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
Sent: 26 April 2023 02:08
To: OpenStack Discuss <openstack-discuss at lists.openstack.org>
Subject: [kolla-ansible][swift][ceph]


CAUTION: This email originates from outside THG

________________________________
Hello guys.
I am working to make openstack swift save data on ceph. I am using kolla ansible and see it need enable swift first but I don't want to make swift ring on my controller. I just want use external ceph.
Pls you give me some advices
Thank you
Nguyen Huu Khoi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/48593f1e/attachment-0001.htm>

From jake.yip at ardc.edu.au  Wed Apr 26 10:07:58 2023
From: jake.yip at ardc.edu.au (Jake Yip)
Date: Wed, 26 Apr 2023 20:07:58 +1000
Subject: [heat][magnum][tacker] Future of SoftwareDeployment support
In-Reply-To: <f72fa847-a6d1-c0a2-29d5-3cbb1df738ac@ultimum.io>
References: <CAL_crJTB_D+Y+LVRs2qNindh8e1Pk=aK2EEx7SP09eSFZDRB5g@mail.gmail.com>
 <6396cae4-9afd-b823-525f-90690d8c29d7@ardc.edu.au>
 <f72fa847-a6d1-c0a2-29d5-3cbb1df738ac@ultimum.io>
Message-ID: <eb0d30ca-0fc6-e974-9417-68500f5c03bd@ardc.edu.au>

Hi,

Yes, there are a couple of WIP reviews in magnum by John.

Regards,
Jake

On 18/4/2023 11:16 pm, Michal Arbet wrote:
> Hi,
> 
> Two cycles ? I thought that most of work was implemented by vexxhost ? 
> https://github.com/vexxhost/magnum-cluster-api
> Do you have reviews somewhere if you are working on ClusterAPI ?
> 
> 
> Thanks
> 
> On 4/18/23 13:53, Jake Yip wrote:
>> HI Takashi,
>>
>> Sorry I missed replying.
>>
>> On 30/3/2023 1:46 pm, Takashi Kajinami wrote:
>>
>>>
>>> 1. Magnum
>>> It seems SoftwareDeployment is used by k8s_fedora_atomic_v1 driver 
>>> but I'm not too sure whether
>>> this driver is still supported, because Fedora Atomic was EOLed a 
>>> while ago, right ?
>>>
>>
>> No It's still in the main k8s_fedora_coreos_v1 driver. It basically is 
>> how everything is set up, so we still depend on this greatly for now.
>>
>> We are also working on a ClusterAPI driver who will bypass heat 
>> altogether. We hope to get it working within two cycles, then we can 
>> remove k8s_fedora_coreos_v1 together, possibly within another two cycles.
>>
>> Thanks!
>>
>> Regards
>> Jake
>>
> -- 
> Michal Arbet
> Openstack Engineer
> 
> Ultimum Technologies a.s.
> Na Po???? 1047/26, 11000 Praha 1
> Czech Republic
> 
> +420 604 228 897
> michal.arbet at ultimum.io
> _https://ultimum.io_
> 
> LinkedIn <https://www.linkedin.com/company/ultimum-technologies>?| 
> Twitter <https://twitter.com/ultimumtech>?| Facebook 
> <https://www.facebook.com/ultimumtechnologies/timeline>
> 


From senrique at redhat.com  Wed Apr 26 10:35:57 2023
From: senrique at redhat.com (Sofia Enriquez)
Date: Wed, 26 Apr 2023 11:35:57 +0100
Subject: Cinder Bug Report 2023-04-26
Message-ID: <CANtmtpGbCUAa2BvymSOSvVWOyZN93JwtA5SXtyjj5XMQDi-Lgg@mail.gmail.com>

Hello Argonauts,

Cinder Bug Meeting Etherpad
<https://etherpad.opendev.org/p/cinder-bug-squad-meeting>

*High*

   -  Users with a Reader role can create/delete/update a snapshot
   <https://bugs.launchpad.net/cinder/+bug/2017108>.
      - *Status:* Unassigned. These issues were found while adding snapshot
      tests for srbac
      <https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/872986>
      .

*Incomplete*

   - wrong hostname passed to os_brick
   <https://bugs.launchpad.net/cinder/+bug/2017575>
      - *Status:* Waiting on reports updates.

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: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/483e2f49/attachment.htm>

From nguyenhuukhoinw at gmail.com  Wed Apr 26 10:43:05 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Wed, 26 Apr 2023 17:43:05 +0700
Subject: [kolla-ansible][swift][ceph]
In-Reply-To: <LO2P265MB577320D0FABCCE59432F22D09A659@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
References: <CABAODRc1SLeGT4oxH0srAp8nL06_iNrcTLQioGg1w948SBUSGg@mail.gmail.com>
 <LO2P265MB5773F165E355BDCA0C7F811A9A659@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <LO2P265MB577320D0FABCCE59432F22D09A659@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <CABAODReCqi8+mCrvFwz9U_zfZJ3_-cWKokOEQpW0z4a4oojF0A@mail.gmail.com>

Hello. Thank you for your email,
But the problem is that I use cephadm so it is not like a traditional way
to configure, I am trying to test.
Nguyen Huu Khoi


On Wed, Apr 26, 2023 at 3:51?PM Danny Webb <Danny.Webb at thehutgroup.com>
wrote:

> https://docs.ceph.com/en/latest/radosgw/keystone/
> ------------------------------
> *From:* Danny Webb <Danny.Webb at thehutgroup.com>
> *Sent:* 26 April 2023 09:50
> *To:* Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>; OpenStack Discuss <
> openstack-discuss at lists.openstack.org>
> *Subject:* Re: [kolla-ansible][swift][ceph]
>
> So if I remember correctly from when we did this a long while back, you
> don't really do much on the openstack deployment side.   Ceph comes with a
> swift compliant interface so the only thing required was in the ceph.conf
> to enable keystone as an authentication mechanism.
> ------------------------------
> *From:* Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> *Sent:* 26 April 2023 02:08
> *To:* OpenStack Discuss <openstack-discuss at lists.openstack.org>
> *Subject:* [kolla-ansible][swift][ceph]
>
>
> * CAUTION: This email originates from outside THG *
> ------------------------------
> Hello guys.
> I am working to make openstack swift save data on ceph. I am using kolla
> ansible and see it need enable swift first but I don't want to make swift
> ring on my controller. I just want use external ceph.
> Pls you give me some advices
> Thank you
> Nguyen Huu Khoi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/4f690703/attachment.htm>

From wodel.youchi at gmail.com  Wed Apr 26 11:07:36 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Wed, 26 Apr 2023 12:07:36 +0100
Subject: [Cinder][LVM backend] LVM vg backed by a shared LUN
Message-ID: <CAJV_UBC+H8CZHrDo04=v0AYLtXavVQOhavVKm4Sn31haPGoPJA@mail.gmail.com>

Hi,

The examples I could find on the internet using LVM as backend for Cinder,
they expose a local disk using lvm via Cinder.

I did this configuration and I am wondering if it's correct, especially
from a "simultaneous access" point of view.

I have an iSCSI target backed by targetcli that exposes a LUN to my compute
nodes. I did configure the iscsi connexion manually on each one of them and
they all see the LUN, then on one of them I created the cinder-volumes VG
(the other nodes can see the modifications), then I configured Cinder with
lvm backend using this VG and it worked. I created some volumes on it
without issues using my account. But what about when there are multiple
tenants that try to create multiple volumes on it, is this configuration
safe?

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/226615ee/attachment.htm>

From wodel.youchi at gmail.com  Wed Apr 26 11:11:53 2023
From: wodel.youchi at gmail.com (wodel youchi)
Date: Wed, 26 Apr 2023 12:11:53 +0100
Subject: [Glance] backend file backed by NFS share
Message-ID: <CAJV_UBBwxK8x5Kn9V28jGABvEAVa93OeS9ZEFRi1EE_v9m6mGg@mail.gmail.com>

Hi,

I have 3 controllers nodes on my deployment, each controller has a
Glance-api container on it.

Can I create an NFS share, then mount it manually, or via fstab or autofs
then use file as backend for Glance pointing to the nfs mount point on the
3 controllers safely, regarding simultaneous access?

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/0395d8f9/attachment-0001.htm>

From fadhel.bedda at gmail.com  Wed Apr 26 11:54:51 2023
From: fadhel.bedda at gmail.com (BEDDA Fadhel)
Date: Wed, 26 Apr 2023 13:54:51 +0200
Subject: openstack-discuss Digest, Vol 54, Issue 117
In-Reply-To: <mailman.13907.1682499073.934892.openstack-discuss@lists.openstack.org>
References: <mailman.13907.1682499073.934892.openstack-discuss@lists.openstack.org>
Message-ID: <CAE1GhS5Ja5uBLD7R6g=eVqRYUFHLEK+oObXAzH=zbAYKJUg1tQ@mail.gmail.com>

Good morning,
I am still looking for a complete and clear procedure to set up an
openstack yoga solution on a vmware worksation virtual machine: ubuntu
22.04 or centos.
THANKS

Le mer. 26 avr. 2023 ? 10:54, <openstack-discuss-request at lists.openstack.org>
a ?crit :

> Send openstack-discuss mailing list submissions to
>         openstack-discuss at lists.openstack.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
>
> or, via email, send a message with subject or body 'help' to
>         openstack-discuss-request at lists.openstack.org
>
> You can reach the person managing the list at
>         openstack-discuss-owner at lists.openstack.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openstack-discuss digest..."
>
>
> Today's Topics:
>
>    1. [kolla-ansible][swift][ceph] (Nguy?n H?u Kh?i)
>    2. Re: OpenStack Swift quota (Thomas Goirand)
>    3. [Image Encryption] No meeting on May 1st (Josephine Seifert)
>    4. Re: [kolla-ansible][swift][ceph] (Danny Webb)
>    5. Re: [kolla-ansible][swift][ceph] (Danny Webb)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 26 Apr 2023 08:08:09 +0700
> From: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> To: OpenStack Discuss <openstack-discuss at lists.openstack.org>
> Subject: [kolla-ansible][swift][ceph]
> Message-ID:
>         <
> CABAODRc1SLeGT4oxH0srAp8nL06_iNrcTLQioGg1w948SBUSGg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello guys.
> I am working to make openstack swift save data on ceph. I am using kolla
> ansible and see it need enable swift first but I don't want to make swift
> ring on my controller. I just want use external ceph.
> Pls you give me some advices
> Thank you
> Nguyen Huu Khoi
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/a36c4ff6/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 26 Apr 2023 08:38:05 +0200
> From: Thomas Goirand <zigo at debian.org>
> To: "Xu, Wei [E CPE]" <weixu at iastate.edu>,
>         "openstack-discuss at lists.openstack.org"
>         <openstack-discuss at lists.openstack.org>
> Cc: "Babu, Sarath [E CPE]" <sarath4 at IASTATE.EDU>
> Subject: Re: OpenStack Swift quota
> Message-ID: <fb5d37ba-1344-16e8-f2bf-f469afd696b6 at debian.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 4/25/23 22:39, Xu, Wei [E CPE] wrote:
> > Hello Thomas,
> >
> > We have just tried the command you provided, however it is showing the
> > exact same error we had before. Is it likely to be some configuration
> > error? Or there're some other roles that this admin user must obtain?
>
> It's likely that the error message is right by saying "forbidden", ie,
> you don't have enough right (so, the 2nd possibility...).
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 26 Apr 2023 09:26:54 +0200
> From: Josephine Seifert <josephine.seifert at secustack.com>
> To: openstack-discuss at lists.openstack.org
> Subject: [Image Encryption] No meeting on May 1st
> Message-ID: <eed7cae9-13cd-3c12-2e17-a619347893e9 at secustack.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Hi,
>
> due to a national holiday there will be no meeting on May the 1st.
>
> regards,
> Jospehine (Luzi)
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 26 Apr 2023 08:50:24 +0000
> From: Danny Webb <Danny.Webb at thehutgroup.com>
> To: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>, OpenStack Discuss
>         <openstack-discuss at lists.openstack.org>
> Subject: Re: [kolla-ansible][swift][ceph]
> Message-ID:
>         <
> LO2P265MB5773F165E355BDCA0C7F811A9A659 at LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> So if I remember correctly from when we did this a long while back, you
> don't really do much on the openstack deployment side.   Ceph comes with a
> swift compliant interface so the only thing required was in the ceph.conf
> to enable keystone as an authentication mechanism.
> ________________________________
> From: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> Sent: 26 April 2023 02:08
> To: OpenStack Discuss <openstack-discuss at lists.openstack.org>
> Subject: [kolla-ansible][swift][ceph]
>
>
> CAUTION: This email originates from outside THG
>
> ________________________________
> Hello guys.
> I am working to make openstack swift save data on ceph. I am using kolla
> ansible and see it need enable swift first but I don't want to make swift
> ring on my controller. I just want use external ceph.
> Pls you give me some advices
> Thank you
> Nguyen Huu Khoi
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/e8227a45/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 5
> Date: Wed, 26 Apr 2023 08:51:07 +0000
> From: Danny Webb <Danny.Webb at thehutgroup.com>
> To: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>, OpenStack Discuss
>         <openstack-discuss at lists.openstack.org>
> Subject: Re: [kolla-ansible][swift][ceph]
> Message-ID:
>         <
> LO2P265MB577320D0FABCCE59432F22D09A659 at LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM
> >
>
> Content-Type: text/plain; charset="utf-8"
>
> https://docs.ceph.com/en/latest/radosgw/keystone/
> ________________________________
> From: Danny Webb <Danny.Webb at thehutgroup.com>
> Sent: 26 April 2023 09:50
> To: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>; OpenStack Discuss <
> openstack-discuss at lists.openstack.org>
> Subject: Re: [kolla-ansible][swift][ceph]
>
> So if I remember correctly from when we did this a long while back, you
> don't really do much on the openstack deployment side.   Ceph comes with a
> swift compliant interface so the only thing required was in the ceph.conf
> to enable keystone as an authentication mechanism.
> ________________________________
> From: Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> Sent: 26 April 2023 02:08
> To: OpenStack Discuss <openstack-discuss at lists.openstack.org>
> Subject: [kolla-ansible][swift][ceph]
>
>
> CAUTION: This email originates from outside THG
>
> ________________________________
> Hello guys.
> I am working to make openstack swift save data on ceph. I am using kolla
> ansible and see it need enable swift first but I don't want to make swift
> ring on my controller. I just want use external ceph.
> Pls you give me some advices
> Thank you
> Nguyen Huu Khoi
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/48593f1e/attachment.htm
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> openstack-discuss mailing list
> openstack-discuss at lists.openstack.org
>
>
> ------------------------------
>
> End of openstack-discuss Digest, Vol 54, Issue 117
> **************************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/41250899/attachment.htm>

From rafaelweingartner at gmail.com  Wed Apr 26 12:45:51 2023
From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=)
Date: Wed, 26 Apr 2023 09:45:51 -0300
Subject: [horizon][nova][masakari] Instances created with "Any AZ" problem
In-Reply-To: <CABAODReEPT0iJRM3oU+S6RD4NjwNXyfmcU6O8=qzq7WQoudbEg@mail.gmail.com>
References: <CABAODRfg-m=3_c9ynAW6ZT5sqL=2Q5zwSGB=fX+q+NtBg86=Ew@mail.gmail.com>
 <CAG97rac6PFLNq7AMZe8hLgqF9tYqTbxx0Uj84aF-ux=XAW+vRQ@mail.gmail.com>
 <CALOCmump0kJ-2BMri-wP=8frgKAofqEj9BmDfkZgetK1uXfOGA@mail.gmail.com>
 <173abaa4b89efc8594b08c1c256bc873f3192828.camel@redhat.com>
 <CALOCmumceqTz-BDX2OOdvLi1gbQGsDJpnsh5RT2z+nAjQtvMQA@mail.gmail.com>
 <c0ad091d2030ed7416c2117ad9e9debff60941e6.camel@redhat.com>
 <CALOCmumSkbPcwfo9LhpCd=A6tFveeVFm=EtojKX6v1E3pa_9Ug@mail.gmail.com>
 <CABAODRe_vYVnTiG+QnkJdawiaXeRCiLp8o5c4tZLa3AsGggVLw@mail.gmail.com>
 <CABAODRcUSTxfJodFijJJA4FqeW+=uxP__xbRFV9MjaJ26wwFBA@mail.gmail.com>
 <CALOCmum1PwzFYEG-Go1KMjHk5L4RGNEFRabgw0vJ5QaFG9yUMg@mail.gmail.com>
 <CABAODRfQS_5mtL08XAYnxiOVBU3tB-dDCALWW77mhf+DivD4MA@mail.gmail.com>
 <CABAODReEPT0iJRM3oU+S6RD4NjwNXyfmcU6O8=qzq7WQoudbEg@mail.gmail.com>
Message-ID: <CAG97radCs2p_egsDey-G_v1JuZ+YYHenSY-y+uABqcoqDu=haQ@mail.gmail.com>

Adding the response to this thread, as I replied in the wrong one. Sorry
for the confusion.

Hello Sylvain Bauza and Sean Mooney,

The patch pointed out in [1] is doing exactly what you said that we should
not do. I mean, changing the AZ in the request spec of the virtual machine
(VM) that the user created. The patch we propose in [2] is intended to
avoid exactly that.

As pointed out by Florian, the configuration "cross_az_attach" is a
constraint of the cloud environment, and as such it should be considered
when selecting hosts to execute VMs migrations. Therefore, for those
situations, and only for those (cross_az_attach=False), we send the current
AZ of the VM to placement, to enable it (placement) to filter out hosts
that are not from the current AZ of the VM.

Looking at the patch suggested by you in [1], and later testing it, we can
confirm that the problem is still there in main/upstream. This happens
because the patch in [1] is only addressing the cases when the VM is
created based on volumes, and then it sets the AZ of the volumes in the
request spec of the VM. That is why everything works for the setups where
cross_az_attach=False. However, if we create a VM based on an image, and
then it (Nova) creates a new volume in Cinder, the AZ is not set in the
request spec (but it is used to execute the first call to placement to
select the hosts); thus, the issues described in [2] can still happen.

Anyways, the proposal presented in [2] is simpler and works nicely. We can
discuss it further in the patchset then, if you guys think it is worth it.

[1]
https://review.opendev.org/c/openstack/nova/+/469675/12/nova/compute/api.py#1173
[2] https://review.opendev.org/c/openstack/nova/+/864760

On Wed, Mar 29, 2023 at 10:26?AM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> "If they *don't* provide this parameter, then depending on the
> default_schedule_zone config option, either the instance will eventually
> use a specific AZ (and then it's like if the enduser was asking for this
> AZ), or none of AZ is requested and then the instance can be created and
> moved between any hosts within *all* AZs."
>
> I ask aftet that, although without az when launch instances but they still
> have az. But i still mv to diffent host in diffent az when mirgrating or
> spawn which masakari. i am not clear, I tested.
>
>
> On Wed, Mar 29, 2023, 7:38 PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> wrote:
>
>> Yes. Thanks, but the things I would like to know: after instances are
>> created, how do we know if it was launched with specified AZ or without it?
>> I mean the way to distinguish between specified instances and non specified
>> instances?
>>
>> Nguyen Huu Khoi
>>
>>
>> On Wed, Mar 29, 2023 at 5:05?PM Sylvain Bauza <sbauza at redhat.com> wrote:
>>
>>>
>>>
>>> Le mer. 29 mars 2023 ? 08:06, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
>>> a ?crit :
>>>
>>>> Hello.
>>>> I have one question.
>>>> Follow this
>>>>
>>>> https://docs.openstack.org/nova/latest/admin/availability-zones.html
>>>>
>>>> If the server was not created in a specific zone then it is free to be
>>>> moved to other zones. but when I use
>>>>
>>>> openstack server show [server id]
>>>>
>>>> I still see the "OS-EXT-AZ:availability_zone" value belonging to my
>>>> instance.
>>>>
>>>>
>>> Correct, this is normal. If the operators creates some AZs, then the
>>> enduser should see where the instance in which AZ.
>>>
>>>
>>>> Could you tell the difference which causes "if the server was not
>>>> created in a specific zone then it is free to be moved to other zones."
>>>>
>>>>
>>> To be clear, an operator can create Availability Zones. Those AZs can
>>> then be seen by an enduser using the os-availability-zones API [1]. Then,
>>> either the enduser wants to use a specific AZ for their next instance
>>> creation (and if so, he/she adds --availability-zone parameter to their
>>> instance creation client) or they don't want and then they don't provide
>>> this parameter.
>>>
>>> If they provide this parameter, then the server will be created only in
>>> one host in the specific AZ and then when moving the instance later, it
>>> will continue to move to any host within the same AZ.
>>> If they *don't* provide this parameter, then depending on the
>>> default_schedule_zone config option, either the instance will eventually
>>> use a specific AZ (and then it's like if the enduser was asking for this
>>> AZ), or none of AZ is requested and then the instance can be created and
>>> moved between any hosts within *all* AZs.
>>>
>>> That being said, as I said earlier, the enduser can still verify the AZ
>>> from where the instance is by the server show parameter you told.
>>>
>>> We also have a documentation explaining about Availability Zones, maybe
>>> this would help you more to understand about AZs :
>>> https://docs.openstack.org/nova/latest/admin/availability-zones.html
>>>
>>>
>>> [1]
>>> https://docs.openstack.org/api-ref/compute/#availability-zones-os-availability-zone
>>> (tbc, the enduser won't see the hosts, but they can see the list of
>>> existing AZs)
>>>
>>>
>>>
>>>> Nguyen Huu Khoi
>>>>
>>>>
>>>> On Mon, Mar 27, 2023 at 8:37?PM Nguy?n H?u Kh?i <
>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>
>>>>> Hello guys.
>>>>>
>>>>> I just suggest to openstack nova works better. My story because
>>>>>
>>>>>
>>>>>    1.
>>>>>
>>>>>    The server was created in a specific zone with the POST /servers request
>>>>>    containing the availability_zone parameter.
>>>>>
>>>>> It will be nice when we attach randow zone when we create instances
>>>>> then It will only move to the same zone when migrating or masakari ha.
>>>>>
>>>>> Currently we can force it to zone by default zone shedule in nova.conf.
>>>>>
>>>>> Sorry because I am new to Openstack and I am just an operator. I try
>>>>> to verify some real cases.
>>>>>
>>>>>
>>>>>
>>>>> Nguyen Huu Khoi
>>>>>
>>>>>
>>>>> On Mon, Mar 27, 2023 at 7:43?PM Sylvain Bauza <sbauza at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> Le lun. 27 mars 2023 ? 14:28, Sean Mooney <smooney at redhat.com> a
>>>>>> ?crit :
>>>>>>
>>>>>>> On Mon, 2023-03-27 at 14:06 +0200, Sylvain Bauza wrote:
>>>>>>> > Le lun. 27 mars 2023 ? 13:51, Sean Mooney <smooney at redhat.com> a
>>>>>>> ?crit :
>>>>>>> >
>>>>>>> > > On Mon, 2023-03-27 at 10:19 +0200, Sylvain Bauza wrote:
>>>>>>> > > > Le dim. 26 mars 2023 ? 14:30, Rafael Weing?rtner <
>>>>>>> > > > rafaelweingartner at gmail.com> a ?crit :
>>>>>>> > > >
>>>>>>> > > > > Hello Nguy?n H?u Kh?i,
>>>>>>> > > > > You might want to take a look at:
>>>>>>> > > > > https://review.opendev.org/c/openstack/nova/+/864760. We
>>>>>>> created a
>>>>>>> > > patch
>>>>>>> > > > > to avoid migrating VMs to any AZ, once the VM has been
>>>>>>> bootstrapped in
>>>>>>> > > an
>>>>>>> > > > > AZ that has cross zone attache equals to false.
>>>>>>> > > > >
>>>>>>> > > > >
>>>>>>> > > > Well, I'll provide some comments in the change, but I'm afraid
>>>>>>> we can't
>>>>>>> > > > just modify the request spec like you would want.
>>>>>>> > > >
>>>>>>> > > > Anyway, if you want to discuss about it in the vPTG, just add
>>>>>>> it in the
>>>>>>> > > > etherpad and add your IRC nick so we could try to find a time
>>>>>>> where we
>>>>>>> > > > could be discussing it :
>>>>>>> https://etherpad.opendev.org/p/nova-bobcat-ptg
>>>>>>> > > > Also, this kind of behaviour modification is more a new
>>>>>>> feature than a
>>>>>>> > > > bugfix, so fwiw you should create a launchpad blueprint so we
>>>>>>> could
>>>>>>> > > better
>>>>>>> > > > see it.
>>>>>>> > >
>>>>>>> > > i tought i left review feedback on that too that the approch was
>>>>>>> not
>>>>>>> > > correct.
>>>>>>> > > i guess i did not in the end.
>>>>>>> > >
>>>>>>> > > modifying the request spec as sylvain menthioned is not correct.
>>>>>>> > > i disucssed this topic on irc a few weeks back with mohomad for
>>>>>>> vxhost.
>>>>>>> > > what can be done is as follows.
>>>>>>> > >
>>>>>>> > > we can add a current_az field  to the Destination object
>>>>>>> > >
>>>>>>> > >
>>>>>>> https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L1092-L1122
>>>>>>> > > The conductor can read the instance.AZ and populate it in that
>>>>>>> new field.
>>>>>>> > > We can then add a new weigher to prefer hosts that are in the
>>>>>>> same az.
>>>>>>> > >
>>>>>>> > >
>>>>>>> >
>>>>>>> > I tend to disagree this approach as people would think that the
>>>>>>> > Destination.az field would be related to the current AZ for an
>>>>>>> instance,
>>>>>>> > while we only look at the original AZ.
>>>>>>> > That being said, we could have a weigher that would look at
>>>>>>> whether the
>>>>>>> > host is in the same AZ than the instance.host.
>>>>>>> you miss understood what i wrote
>>>>>>>
>>>>>>> i suggested addint Destination.current_az to store teh curernt AZ of
>>>>>>> the instance before scheduling.
>>>>>>>
>>>>>>> so my proposal is if RequestSpec.AZ is not set and
>>>>>>> Destination.current_az is set then the new
>>>>>>> weigher would prefer hosts that are in the same az as
>>>>>>> Destination.current_az
>>>>>>>
>>>>>>> we coudl also call Destination.current_az Destination.prefered_az
>>>>>>>
>>>>>>>
>>>>>> I meant, I think we don't need to provide a new field, we can already
>>>>>> know about what host an existing instance uses if we want (using [1])
>>>>>> Anyway, let's stop to discuss about it here, we should rather review
>>>>>> that for a Launchpad blueprint or more a spec.
>>>>>>
>>>>>> -Sylvain
>>>>>>
>>>>>> [1]
>>>>>> https://github.com/openstack/nova/blob/b9a49ffb04cb5ae2d8c439361a3552296df02988/nova/scheduler/host_manager.py#L369-L370
>>>>>>
>>>>>>> >
>>>>>>> >
>>>>>>> > This will provide soft AZ affinity for the vm and preserve the
>>>>>>> fact that if
>>>>>>> > > a vm is created without sepcifying
>>>>>>> > > An AZ the expectaiton at the api level woudl be that it can
>>>>>>> migrate to any
>>>>>>> > > AZ.
>>>>>>> > >
>>>>>>> > > To provide hard AZ affintiy we could also add prefileter that
>>>>>>> would use
>>>>>>> > > the same data but instead include it in the
>>>>>>> > > placement query so that only the current AZ is considered. This
>>>>>>> would have
>>>>>>> > > to be disabled by default.
>>>>>>> > >
>>>>>>> > >
>>>>>>> > Sure, we could create a new prefilter so we could then deprecate
>>>>>>> the
>>>>>>> > AZFilter if we want.
>>>>>>> we already have an AZ prefilter and the AZFilter is deprecate for
>>>>>>> removal
>>>>>>> i ment to delete it in zed but did not have time to do it in zed of
>>>>>>> Antielope
>>>>>>> i deprecated the AZ| filter in
>>>>>>> https://github.com/openstack/nova/commit/7c7a2a142d74a7deeda2a79baf21b689fe32cd08
>>>>>>> xena when i enabeld the az prefilter by default.
>>>>>>>
>>>>>>>
>>>>>> Ah whoops, indeed I forgot the fact we already have the prefilter, so
>>>>>> the hard support for AZ is already existing.
>>>>>>
>>>>>>
>>>>>>> i will try an delete teh AZ filter before m1 if others dont.
>>>>>>>
>>>>>>
>>>>>> OK.
>>>>>>
>>>>>>
>>>>>>> >
>>>>>>> >
>>>>>>> > > That woudl allow operators to choose the desired behavior.
>>>>>>> > > curret behavior (disable weigher and dont enabel prefilter)
>>>>>>> > > new default, prefer current AZ (weigher enabeld prefilter
>>>>>>> disabled)
>>>>>>> > > hard affintiy(prefilter enabled.)
>>>>>>> > >
>>>>>>> > > there are other ways to approch this but updating the request
>>>>>>> spec is not
>>>>>>> > > one of them.
>>>>>>> > > we have to maintain the fact the enduser did not request an AZ.
>>>>>>> > >
>>>>>>> > >
>>>>>>> > Anyway, if folks want to discuss about AZs, this week is the good
>>>>>>> time :-)
>>>>>>> >
>>>>>>> >
>>>>>>> > > >
>>>>>>> > > > -Sylvain
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > >
>>>>>>> > > > > On Sun, Mar 26, 2023 at 8:20?AM Nguy?n H?u Kh?i <
>>>>>>> > > nguyenhuukhoinw at gmail.com>
>>>>>>> > > > > wrote:
>>>>>>> > > > >
>>>>>>> > > > > > Hello guys.
>>>>>>> > > > > > I playing with Nova AZ and Masakari
>>>>>>> > > > > >
>>>>>>> > > > > >
>>>>>>> https://docs.openstack.org/nova/latest/admin/availability-zones.html
>>>>>>> > > > > >
>>>>>>> > > > > > Masakari will move server by nova scheduler.
>>>>>>> > > > > >
>>>>>>> > > > > > Openstack Docs describe that:
>>>>>>> > > > > >
>>>>>>> > > > > > If the server was not created in a specific zone then it
>>>>>>> is free to
>>>>>>> > > be
>>>>>>> > > > > > moved to other zones, i.e. the AvailabilityZoneFilter
>>>>>>> > > > > > <
>>>>>>> > >
>>>>>>> https://docs.openstack.org/nova/latest/admin/scheduling.html#availabilityzonefilter
>>>>>>> >
>>>>>>> > > is
>>>>>>> > > > > > a no-op.
>>>>>>> > > > > >
>>>>>>> > > > > > I see that everyone usually creates instances with "Any
>>>>>>> Availability
>>>>>>> > > > > > Zone" on Horzion and also we don't specify AZ when creating
>>>>>>> > > instances by
>>>>>>> > > > > > cli.
>>>>>>> > > > > >
>>>>>>> > > > > > By this way, when we use Masakari or we miragrated
>>>>>>> instances( or
>>>>>>> > > > > > evacuate) so our instance will be moved to other zones.
>>>>>>> > > > > >
>>>>>>> > > > > > Can we attach AZ to server create requests API based on Any
>>>>>>> > > > > > Availability Zone to limit instances moved to other zones?
>>>>>>> > > > > >
>>>>>>> > > > > > Thank you. Regards
>>>>>>> > > > > >
>>>>>>> > > > > > Nguyen Huu Khoi
>>>>>>> > > > > >
>>>>>>> > > > >
>>>>>>> > > > >
>>>>>>> > > > > --
>>>>>>> > > > > Rafael Weing?rtner
>>>>>>> > > > >
>>>>>>> > >
>>>>>>> > >
>>>>>>>
>>>>>>>

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

From fungi at yuggoth.org  Wed Apr 26 13:34:25 2023
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 26 Apr 2023 13:34:25 +0000
Subject: [kolla-ansible][swift][ceph]
In-Reply-To: <LO2P265MB5773F165E355BDCA0C7F811A9A659@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
References: <CABAODRc1SLeGT4oxH0srAp8nL06_iNrcTLQioGg1w948SBUSGg@mail.gmail.com>
 <LO2P265MB5773F165E355BDCA0C7F811A9A659@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <20230426133424.7bsky4dnudvxmvlx@yuggoth.org>

On 2023-04-26 08:50:24 +0000 (+0000), Danny Webb wrote:
> So if I remember correctly from when we did this a long while
> back, you don't really do much on the openstack deployment side.
> Ceph comes with a swift compliant interface so the only thing
> required was in the ceph.conf to enable keystone as an
> authentication mechanism.
[...]

That's not really the same thing as backing actual Swift services
with data stored in Ceph, that's replacing the user-facing Swift API
with Ceph's attempt to recreate some of the same functionality. For
a lot of people that's "good enough" but note that there are a lot
of things which won't be quite the same (like lack of proper
multi-tenant namespacing for containers, performance limitations
with large container counts, et cetera) but also there's a number of
Swift features that Ceph simply doesn't have.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/8a790629/attachment.sig>

From eblock at nde.ag  Wed Apr 26 13:47:11 2023
From: eblock at nde.ag (Eugen Block)
Date: Wed, 26 Apr 2023 13:47:11 +0000
Subject: [kolla-ansible][swift][ceph]
In-Reply-To: <CABAODReCqi8+mCrvFwz9U_zfZJ3_-cWKokOEQpW0z4a4oojF0A@mail.gmail.com>
References: <CABAODRc1SLeGT4oxH0srAp8nL06_iNrcTLQioGg1w948SBUSGg@mail.gmail.com>
 <LO2P265MB5773F165E355BDCA0C7F811A9A659@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <LO2P265MB577320D0FABCCE59432F22D09A659@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <CABAODReCqi8+mCrvFwz9U_zfZJ3_-cWKokOEQpW0z4a4oojF0A@mail.gmail.com>
Message-ID: <20230426134711.Horde.p7SlAs9sxHVYKvE0d9Laspa@webmail.nde.ag>

Hi,

not so long ago I wrote down what was necessary in my lab environment  
to configure a cephadm based cluster with keystone authentication for  
S3 (swift) clients. In Openstack you need swift endpoints which point  
to the rados gateway(s) in your external ceph cluster. So you don't  
really set up swift but only create the endpoints for your clients. I  
can't comment what exactly needs to be done with kolla but you should  
get the general idea, I hope.

Regards,
Eugen

[1]  
https://serverfault.com/questions/1118004/cephadm-openstack-keystone-integration

Zitat von Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>:

> Hello. Thank you for your email,
> But the problem is that I use cephadm so it is not like a traditional way
> to configure, I am trying to test.
> Nguyen Huu Khoi
>
>
> On Wed, Apr 26, 2023 at 3:51?PM Danny Webb <Danny.Webb at thehutgroup.com>
> wrote:
>
>> https://docs.ceph.com/en/latest/radosgw/keystone/
>> ------------------------------
>> *From:* Danny Webb <Danny.Webb at thehutgroup.com>
>> *Sent:* 26 April 2023 09:50
>> *To:* Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>; OpenStack Discuss <
>> openstack-discuss at lists.openstack.org>
>> *Subject:* Re: [kolla-ansible][swift][ceph]
>>
>> So if I remember correctly from when we did this a long while back, you
>> don't really do much on the openstack deployment side.   Ceph comes with a
>> swift compliant interface so the only thing required was in the ceph.conf
>> to enable keystone as an authentication mechanism.
>> ------------------------------
>> *From:* Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
>> *Sent:* 26 April 2023 02:08
>> *To:* OpenStack Discuss <openstack-discuss at lists.openstack.org>
>> *Subject:* [kolla-ansible][swift][ceph]
>>
>>
>> * CAUTION: This email originates from outside THG *
>> ------------------------------
>> Hello guys.
>> I am working to make openstack swift save data on ceph. I am using kolla
>> ansible and see it need enable swift first but I don't want to make swift
>> ring on my controller. I just want use external ceph.
>> Pls you give me some advices
>> Thank you
>> Nguyen Huu Khoi
>>





From fadhel.bedda at gmail.com  Wed Apr 26 11:36:37 2023
From: fadhel.bedda at gmail.com (BEDDA Fadhel)
Date: Wed, 26 Apr 2023 13:36:37 +0200
Subject: openstack-discuss Digest, Vol 54, Issue 88
In-Reply-To: <mailman.12577.1681745265.934892.openstack-discuss@lists.openstack.org>
References: <mailman.12577.1681745265.934892.openstack-discuss@lists.openstack.org>
Message-ID: <CAE1GhS6dRz0-kAd8yzpDi1cDfn7rszuZOXV8z-Yar_poHQZRhQ@mail.gmail.com>

Good morning,
I am still looking for a complete and clear procedure to set up an
openstack solution on a vmware worksation virtual machine: ubuntu or
centos.
THANKS


Le lun. 17 avr. 2023 ? 17:30, <openstack-discuss-request at lists.openstack.org>
a ?crit :

> Send openstack-discuss mailing list submissions to
>         openstack-discuss at lists.openstack.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
>
> or, via email, send a message with subject or body 'help' to
>         openstack-discuss-request at lists.openstack.org
>
> You can reach the person managing the list at
>         openstack-discuss-owner at lists.openstack.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openstack-discuss digest..."
>
>
> Today's Topics:
>
>    1. Re: [Kolla-ansible][Yoga] Cannot live migrate VMs (wodel youchi)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 11 Apr 2023 12:57:47 +0100
> From: wodel youchi <wodel.youchi at gmail.com>
> To: Pierre Riteau <pierre at stackhpc.com>
> Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org>
> Subject: Re: [Kolla-ansible][Yoga] Cannot live migrate VMs
> Message-ID:
>         <CAJV_UBDH4tJ11pkOagYpWNVCrZHruTmA6A-k9P=
> DLrqchPvNPg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> Indeed, there was a mistake in the cinder.conf file.
> Thanks.
>
> Regards.
>
> <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> Virus-free.www.avast.com
> <
> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Le mar. 11 avr. 2023 ? 10:45, Pierre Riteau <pierre at stackhpc.com> a ?crit
> :
>
> > You should check the status of your Cinder services.
> >
> > On Sun, 9 Apr 2023 at 19:43, wodel youchi <wodel.youchi at gmail.com>
> wrote:
> >
> >> Hi,
> >>
> >> I cannot live-migrate any VM I have.
> >> All my compute nodes are enabled. I have a few VMs, I am in the testing
> >> phase.
> >> I tried to live-migrate toward an empty node, then toward a node which
> >> already had a VM in it. It is the same problem.
> >>
> >> In the log files I have :
> >>
> >> Source node :
> >> Source
> >>
> >>> ==> /var/log/kolla/nova/nova-compute.log <==
> >>> 2023-04-09 11:32:49.419 7 INFO nova.compute.resource_tracker
> >>> [req-4e91d562-d7ad-4585-a827-3db6277fd81e - - - - -] [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Updating resource usage from
> >>> migration f60eb077-8e1c-404a-aca5-64e5609ca02c
> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [-] [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Pre live migration failed at
> >>> computehci02: oslo_messaging.rpc.client.RemoteError: Remote error:
> >>> ClientException Gateway Time-out (HTTP 504)
> >>> ['Traceback (most recent call last):\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py",
> >>> line 165, in _process_incoming\n    res =
> >>> self.dispatcher.dispatch(message)\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
> >>> line 309, in dispatch\n    return self._do_dispatch(endpoint, method,
> ctxt,
> >>> args)\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
> >>> line 229, in _do_dispatch\n    result = func(ctxt, **new_args)\n', '
> File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
> >>> line 72, in wrapped\n    context, exc, binary)\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 227, in __exit__\n    self.force_reraise()\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 200, in force_reraise\n    raise self.value\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
> >>> line 63, in wrapped\n    return f(self, context, *args, **kw)\n', '
> File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py",
> >>> line 1439, in decorated_function\n    return function(self, context,
> *args,
> >>> **kwargs)\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> >>> line 213, in decorated_function\n    kwargs[\'instance\'], e,
> >>> sys.exc_info())\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 227, in __exit__\n    self.force_reraise()\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 200, in force_reraise\n    raise self.value\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> >>> line 201, in decorated_function\n    return function(self, context,
> *args,
> >>> **kwargs)\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> >>> line 8367, in pre_live_migration\n    bdm.save()\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 227, in __exit__\n    self.force_reraise()\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 200, in force_reraise\n    raise self.value\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> >>> line 8304, in pre_live_migration\n    connector=connector,
> >>> mountpoint=bdm.device_name)\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> >>> line 395, in wrapper\n    res = method(self, ctx, *args, **kwargs)\n',
> '
> >>>  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> >>> line 433, in wrapper\n    res = method(self, ctx, volume_id, *args,
> >>> **kwargs)\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> >>> line 813, in attachment_create\n    instance_uuid=instance_id)\n', '
> File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 227, in __exit__\n    self.force_reraise()\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 200, in force_reraise\n    raise self.value\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> >>> line 801, in attachment_create\n    volume_id, _connector,
> instance_id)\n',
> >>> '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py",
> >>> line 421, in substitution\n    return method.func(obj, *args,
> **kwargs)\n',
> >>> '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py",
> >>> line 39, in create\n    retval = self._create(\'/attachments\', body,
> >>> \'attachment\')\n', '  File
> >>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py",
> >>> line 306, in _create\n    resp, body = self.api.client.post(url,
> >>> body=body)\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
> >>> line 227, in post\n    return self._cs_request(url, \'POST\',
> **kwargs)\n',
> >>> '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
> >>> line 215, in _cs_request\n    return self.request(url, method,
> >>> **kwargs)\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
> >>> line 201, in request\n    raise exceptions.from_response(resp,
> body)\n',
> >>> 'cinderclient.exceptions.ClientException: Gateway Time-out (HTTP
> 504)\n'].
> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Traceback (most recent call
> last):
> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> >>> line 8501, in _do_pre_live_migration_from_source
> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     block_migration, disk, dest,
> >>> migrate_data)
> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/rpcapi.py",
> >>> line 948, in pre_live_migration
> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     **msg_args)
> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/client.py",
> >>> line 192, in call
> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     retry=self.retry,
> >>> transport_options=self.transport_options)
> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/transport.py",
> >>> line 128, in _send
> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
> >>> transport_options=transport_options)
> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py",
> >>> line 691, in send
> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
> >>> transport_options=transport_options)
> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py",
> >>> line 681, in _send
> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     raise result
> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
> >>> oslo_messaging.rpc.client.RemoteError: Remote error: ClientException
> >>> Gateway Time-out (HTTP 504)
> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] ['Traceback (most recent call
> >>> last):\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py",
> >>> line 165, in _process_incoming\n    res =
> >>> self.dispatcher.dispatch(message)\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
> >>> line 309, in dispatch\n    return self._do_dispatch(endpoint, method,
> ctxt,
> >>> args)\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
> >>> line 229, in _do_dispatch\n    result = func(ctxt, **new_args)\n', '
> File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
> >>> line 72, in wrapped\n    context, exc, binary)\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 227, in __exit__\n    self.force_reraise()\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 200, in force_reraise\n    raise self.value\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
> >>> line 63, in wrapped\n    return f(self, context, *args, **kw)\n', '
> File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py",
> >>> line 1439, in decorated_function\n    return function(self, context,
> *args,
> >>> **kwargs)\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> >>> line 213, in decorated_function\n    kwargs[\'instance\'], e,
> >>> sys.exc_info())\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 227, in __exit__\n    self.force_reraise()\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 200, in force_reraise\n    raise self.value\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> >>> line 201, in decorated_function\n    return function(self, context,
> *args,
> >>> **kwargs)\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> >>> line 8367, in pre_live_migration\n    bdm.save()\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 227, in __exit__\n    self.force_reraise()\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 200, in force_reraise\n    raise self.value\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> >>> line 8304, in pre_live_migration\n    connector=connector,
> >>> mountpoint=bdm.device_name)\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> >>> line 395, in wrapper\n    res = method(self, ctx, *args, **kwargs)\n',
> '
> >>>  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> >>> line 433, in wrapper\n    res = method(self, ctx, volume_id, *args,
> >>> **kwargs)\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> >>> line 813, in attachment_create\n    instance_uuid=instance_id)\n', '
> File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 227, in __exit__\n    self.force_reraise()\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 200, in force_reraise\n    raise self.value\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> >>> line 801, in attachment_create\n    volume_id, _connector,
> instance_id)\n',
> >>> '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py",
> >>> line 421, in substitution\n    return method.func(obj, *args,
> **kwargs)\n',
> >>> '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py",
> >>> line 39, in create\n    retval = self._create(\'/attachments\', body,
> >>> \'attachment\')\n', '  File
> >>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py",
> >>> line 306, in _create\n    resp, body = self.api.client.post(url,
> >>> body=body)\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
> >>> line 227, in post\n    return self._cs_request(url, \'POST\',
> **kwargs)\n',
> >>> '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
> >>> line 215, in _cs_request\n    return self.request(url, method,
> >>> **kwargs)\n', '  File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
> >>> line 201, in request\n    raise exceptions.from_response(resp,
> body)\n',
> >>> 'cinderclient.exceptions.ClientException: Gateway Time-out (HTTP
> 504)\n'].
> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
> >>> 2023-04-09 11:33:30.157 7 INFO nova.compute.manager [-] [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Swapping old allocation on
> >>> dict_keys(['2857ae62-3519-4b13-b700-858c827dd78d']) held by migration
> >>> f60eb077-8e1c-404a-aca5-64e5609ca02c for instance
> >>
> >>
> >>
> >> In the destination node :
> >>
> >>> nova-compute.log
> >>>
> >>>
> >>>
> >>>
> >>> *2023-04-09 11:32:30.052 7 WARNING os_brick.initiator.connectors.nvmeof
> >>> [req-69822759-d982-4d01-b448-232796077002
> 0439953e7cfe4a13a1b4bb118b5dc3c4
> >>> b0f76b5c6dcb457fa716762bbf954837 - default default] Process execution
> error
> >>> in _get_host_uuid: Unexpected error while running command.Command:
> blkid
> >>> overlay -s UUID -o valueExit code: 2Stdout: ''Stderr: '':
> >>> oslo_concurrency.processutils.ProcessExecutionError: Unexpected error
> while
> >>> running command.*
> >>>
> >>> 2023-04-09 11:33:05.354 7 INFO nova.compute.resource_tracker
> >>> [req-9d480442-87f7-4d4e-a866-c46d645ac7f2 - - - - -] [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Updating resource usage from
> >>> migration f60eb077-8e1c-404a-aca5-64e5609ca02c
> >>> 2023-04-09 11:33:05.392 7 WARNING nova.compute.resource_tracker
> >>> [req-9d480442-87f7-4d4e-a866-c46d645ac7f2 - - - - -] Instance
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7 has been moved to another host
> >>> computehci01(computehci01). There are allocations remaining against the
> >>> source host that might need to be removed: {'resources': {'VCPU': 1,
> >>> 'MEMORY_MB': 2048}}.
> >>> 2023-04-09 11:33:30.086 7 ERROR nova.volume.cinder
> >>> [req-69822759-d982-4d01-b448-232796077002
> 0439953e7cfe4a13a1b4bb118b5dc3c4
> >>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Create attachment failed for
> volume
> >>> 3d7bd0af-5e4c-48fc-a027-f6c9dd6280bb. Error: Gateway Time-out (HTTP
> 504)
> >>> Code: 504: cinderclient.exceptions.ClientException: Gateway Time-out
> (HTTP
> >>> 504)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> >>> [req-69822759-d982-4d01-b448-232796077002
> 0439953e7cfe4a13a1b4bb118b5dc3c4
> >>> b0f76b5c6dcb457fa716762bbf954837 - default default] Exception during
> >>> message handling: cinderclient.exceptions.ClientException: Gateway
> Time-out
> >>> (HTTP 504)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server Traceback
> >>> (most recent call last):
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py",
> >>> line 165, in _process_incoming
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     res =
> >>> self.dispatcher.dispatch(message)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
> >>> line 309, in dispatch
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
> >>> self._do_dispatch(endpoint, method, ctxt, args)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
> >>> line 229, in _do_dispatch
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     result =
> >>> func(ctxt, **new_args)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
> >>> line 72, in wrapped
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     context,
> >>> exc, binary)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 227, in __exit__
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> >>> self.force_reraise()
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 200, in force_reraise
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
> >>> self.value
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
> >>> line 63, in wrapped
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
> >>> f(self, context, *args, **kw)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py",
> >>> line 1439, in decorated_function
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
> >>> function(self, context, *args, **kwargs)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> >>> line 213, in decorated_function
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> >>> kwargs['instance'], e, sys.exc_info())
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 227, in __exit__
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> >>> self.force_reraise()
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 200, in force_reraise
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
> >>> self.value
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> >>> line 201, in decorated_function
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
> >>> function(self, context, *args, **kwargs)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> >>> line 8367, in pre_live_migration
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>  bdm.save()
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 227, in __exit__
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> >>> self.force_reraise()
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 200, in force_reraise
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
> >>> self.value
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
> >>> line 8304, in pre_live_migration
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> >>> connector=connector, mountpoint=bdm.device_name)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> >>> line 395, in wrapper
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     res =
> >>> method(self, ctx, *args, **kwargs)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> >>> line 433, in wrapper
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     res =
> >>> method(self, ctx, volume_id, *args, **kwargs)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> >>> line 813, in attachment_create
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> >>> instance_uuid=instance_id)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 227, in __exit__
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> >>> self.force_reraise()
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
> >>> line 200, in force_reraise
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
> >>> self.value
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
> >>> line 801, in attachment_create
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>  volume_id,
> >>> _connector, instance_id)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py",
> >>> line 421, in substitution
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
> >>> method.func(obj, *args, **kwargs)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py",
> >>> line 39, in create
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     retval =
> >>> self._create('/attachments', body, 'attachment')
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py",
> >>> line 306, in _create
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     resp,
> body
> >>> = self.api.client.post(url, body=body)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
> >>> line 227, in post
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
> >>> self._cs_request(url, 'POST', **kwargs)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
> >>> line 215, in _cs_request
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
> >>> self.request(url, method, **kwargs)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
> >>>
> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
> >>> line 201, in request
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
> >>> exceptions.from_response(resp, body)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> >>> cinderclient.exceptions.ClientException: Gateway Time-out (HTTP 504)
> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
> >>> 2023-04-09 11:33:30.238 7 INFO nova.virt.block_device
> >>> [req-69822759-d982-4d01-b448-232796077002
> 0439953e7cfe4a13a1b4bb118b5dc3c4
> >>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Attempting to driver detach
> volume
> >>> 3d7bd0af-5e4c-48fc-a027-f6c9dd6280bb from mountpoint /dev/vda
> >>> 2023-04-09 11:33:30.239 7 WARNING nova.virt.block_device
> >>> [req-69822759-d982-4d01-b448-232796077002
> 0439953e7cfe4a13a1b4bb118b5dc3c4
> >>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Detaching volume from unknown
> instance
> >>> 2023-04-09 11:33:30.240 7 WARNING nova.virt.libvirt.driver
> >>> [req-69822759-d982-4d01-b448-232796077002
> 0439953e7cfe4a13a1b4bb118b5dc3c4
> >>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] During detach_volume, instance
> >>> disappeared.: nova.exception.InstanceNotFound: Instance
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7 could not be found.
> >>> 2023-04-09 11:33:30.678 7 INFO nova.virt.libvirt.driver [-] [instance:
> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Instance destroyed successfully.
> >>> 2023-04-09 11:33:30.682 7 INFO os_vif
> >>> [req-69822759-d982-4d01-b448-232796077002
> 0439953e7cfe4a13a1b4bb118b5dc3c4
> >>> b0f76b5c6dcb457fa716762bbf954837 - default default] Successfully
> unplugged
> >>> vif
> >>>
> VIFBridge(active=True,address=fa:16:3e:9b:92:46,bridge_name='qbr46651303-65',has_traffic_filtering=True,id=46651303-65e1-4809-95cc-7c2d97acf16b,network=Network(532470c1-dd2f-4505-8557-ba24e9d4062b),plugin='ovs',port_profile=VIFPortProfileOpenVSwitch,preserve_on_delete=False,vif_name='tap46651303-65')
> >>>
> >>
> >> All I can see is
> >>
> >>
> >>
> >>
> >> *b0f76b5c6dcb457fa716762bbf954837 - default default] Process execution
> >> error in _get_host_uuid: Unexpected error while running command.Command:
> >> blkid overlay -s UUID -o valueExit code: 2Stdout: ''Stderr: '':
> >> oslo_concurrency.processutils.ProcessExecutionError: Unexpected error
> while
> >> running command.*
> >>
> >> Searching the web I didn't find anything useful about this error, and I
> >> don't know if it's the origin of the problem.
> >>
> >> My default storage is ceph rbd, I have an HCI deployment, and all my VMs
> >> are for now created on Ceph only. But I have configured two other cinder
> >> backends, NFS and LVM, but they are node used for now.
> >>
> >> Thanks in advance.
> >>
> >> Regards.
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/e775a16b/attachment.htm
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> openstack-discuss mailing list
> openstack-discuss at lists.openstack.org
>
>
> ------------------------------
>
> End of openstack-discuss Digest, Vol 54, Issue 88
> *************************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/4c2b8255/attachment-0001.htm>

From adivya1.singh at gmail.com  Wed Apr 26 14:24:56 2023
From: adivya1.singh at gmail.com (Adivya Singh)
Date: Wed, 26 Apr 2023 19:54:56 +0530
Subject: (OpenStack-Glance) issue while configuring glance
Message-ID: <CA+ykd63ZXMKnrraFcWMqcdEubgQYGqAOXa88tN-bGEAbFDzsfw@mail.gmail.com>

Hi Team,

I am getting OpenStack Glance issue while configuring, it is a remote NFS
which i am mounting in a glance container in /var/lib/glance/images

 2023-04-26 14:13:46.973 3260 ERROR glance.api.v2.image_data
[req-3b87572c-a508-441b-9a1d-2a0392859f52 4d849540700f412396b24bc913700323
2390988a15a04252825dbb6a6e071321 - default default] Error in store
configuration. Adding images to the store is disabled.:
glance_store.exceptions.StoreAddDisabled: Configuration for store failed.
Adding images to this store is disabled.

Regards
Adivya Singh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/fa6561f7/attachment.htm>

From nguyenhuukhoinw at gmail.com  Wed Apr 26 14:47:30 2023
From: nguyenhuukhoinw at gmail.com (=?UTF-8?B?Tmd1eeG7hW4gSOG7r3UgS2jDtGk=?=)
Date: Wed, 26 Apr 2023 21:47:30 +0700
Subject: [kolla-ansible][swift][ceph]
In-Reply-To: <20230426134711.Horde.p7SlAs9sxHVYKvE0d9Laspa@webmail.nde.ag>
References: <CABAODRc1SLeGT4oxH0srAp8nL06_iNrcTLQioGg1w948SBUSGg@mail.gmail.com>
 <LO2P265MB5773F165E355BDCA0C7F811A9A659@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <LO2P265MB577320D0FABCCE59432F22D09A659@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <CABAODReCqi8+mCrvFwz9U_zfZJ3_-cWKokOEQpW0z4a4oojF0A@mail.gmail.com>
 <20230426134711.Horde.p7SlAs9sxHVYKvE0d9Laspa@webmail.nde.ag>
Message-ID: <CABAODRfz1891VpZbSP2NzcW6pOmXvTdeph9WfMfRojwzC40wSg@mail.gmail.com>

Hello.
I was able to make swift run with ceph by restart osd daemon. .

Thank you @Danny Webb <Danny.Webb at thehutgroup.com> and @Eugen Block
<eblock at nde.ag>. I follow your advices and do it.
Summary:
recreate swift endpoint which need point ceph gw
create openstack user and account for ceph gw. project is service
and set parameters like
https://docs.ceph.com/en/latest/radosgw/keystone/

with new cephadm we need use "ceph config set" and restart osd daemon.


@Jeremy Stanley <fungi at yuggoth.org> I think too. Is there any idea use ceph
instead of swift completely? I feel not much people use swift.

Nguyen Huu Khoi


On Wed, Apr 26, 2023 at 8:56?PM Eugen Block <eblock at nde.ag> wrote:

> Hi,
>
> not so long ago I wrote down what was necessary in my lab environment
> to configure a cephadm based cluster with keystone authentication for
> S3 (swift) clients. In Openstack you need swift endpoints which point
> to the rados gateway(s) in your external ceph cluster. So you don't
> really set up swift but only create the endpoints for your clients. I
> can't comment what exactly needs to be done with kolla but you should
> get the general idea, I hope.
>
> Regards,
> Eugen
>
> [1]
>
> https://serverfault.com/questions/1118004/cephadm-openstack-keystone-integration
>
> Zitat von Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>:
>
> > Hello. Thank you for your email,
> > But the problem is that I use cephadm so it is not like a traditional way
> > to configure, I am trying to test.
> > Nguyen Huu Khoi
> >
> >
> > On Wed, Apr 26, 2023 at 3:51?PM Danny Webb <Danny.Webb at thehutgroup.com>
> > wrote:
> >
> >> https://docs.ceph.com/en/latest/radosgw/keystone/
> >> ------------------------------
> >> *From:* Danny Webb <Danny.Webb at thehutgroup.com>
> >> *Sent:* 26 April 2023 09:50
> >> *To:* Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>; OpenStack Discuss <
> >> openstack-discuss at lists.openstack.org>
> >> *Subject:* Re: [kolla-ansible][swift][ceph]
> >>
> >> So if I remember correctly from when we did this a long while back, you
> >> don't really do much on the openstack deployment side.   Ceph comes
> with a
> >> swift compliant interface so the only thing required was in the
> ceph.conf
> >> to enable keystone as an authentication mechanism.
> >> ------------------------------
> >> *From:* Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
> >> *Sent:* 26 April 2023 02:08
> >> *To:* OpenStack Discuss <openstack-discuss at lists.openstack.org>
> >> *Subject:* [kolla-ansible][swift][ceph]
> >>
> >>
> >> * CAUTION: This email originates from outside THG *
> >> ------------------------------
> >> Hello guys.
> >> I am working to make openstack swift save data on ceph. I am using kolla
> >> ansible and see it need enable swift first but I don't want to make
> swift
> >> ring on my controller. I just want use external ceph.
> >> Pls you give me some advices
> >> Thank you
> >> Nguyen Huu Khoi
> >>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/eee49cb1/attachment.htm>

From fungi at yuggoth.org  Wed Apr 26 15:01:09 2023
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 26 Apr 2023 15:01:09 +0000
Subject: [kolla-ansible][swift][ceph]
In-Reply-To: <CABAODRfz1891VpZbSP2NzcW6pOmXvTdeph9WfMfRojwzC40wSg@mail.gmail.com>
References: <CABAODRc1SLeGT4oxH0srAp8nL06_iNrcTLQioGg1w948SBUSGg@mail.gmail.com>
 <LO2P265MB5773F165E355BDCA0C7F811A9A659@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <LO2P265MB577320D0FABCCE59432F22D09A659@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <CABAODReCqi8+mCrvFwz9U_zfZJ3_-cWKokOEQpW0z4a4oojF0A@mail.gmail.com>
 <20230426134711.Horde.p7SlAs9sxHVYKvE0d9Laspa@webmail.nde.ag>
 <CABAODRfz1891VpZbSP2NzcW6pOmXvTdeph9WfMfRojwzC40wSg@mail.gmail.com>
Message-ID: <20230426150108.6546gdtbi5f7j2vn@yuggoth.org>

On 2023-04-26 21:47:30 +0700 (+0700), Nguy?n H?u Kh?i wrote:
[...]
> Is there any idea use ceph instead of swift completely? I feel not
> much people use swift.
[...]

Lots of people do use Swift, both with and without the rest of
OpenStack (even stand-alone it can be a great high-performance
object store independent of other services). Lots of other people
use Ceph's RadosGW API to mimic popular parts of the Swift API
because they're already using Ceph for related things in their
environment and don't want the added complexity of running both Ceph
and Swift. It's up to you to decide which best fits your and your
users' needs.

Just be aware that if you don't run actual Swift in your
environment, it doesn't qualify for use of the OpenStack Powered
Platform or OpenStack Powered Object Storage trademarks[*], if that
matters to you at all. RadosGW and Ceph are not OpenStack services,
even though they're often used in combination with OpenStack
services. "Proper" (from the Interop WG's perspective) full
deployments of the OpenStack platform are expected to provide the
actual Swift API to end users, not a substitute like Ceph's RadosGW.

[*] https://www.openstack.org/brand/interop/
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/de28d8e8/attachment.sig>

From noonedeadpunk at gmail.com  Wed Apr 26 15:07:01 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Wed, 26 Apr 2023 17:07:01 +0200
Subject: (OpenStack-Glance) issue while configuring glance
In-Reply-To: <CA+ykd63ZXMKnrraFcWMqcdEubgQYGqAOXa88tN-bGEAbFDzsfw@mail.gmail.com>
References: <CA+ykd63ZXMKnrraFcWMqcdEubgQYGqAOXa88tN-bGEAbFDzsfw@mail.gmail.com>
Message-ID: <CAPd_6AtNq=7i+K2Dcwq2bsd_qiuxpVaqOmUbv5+Y42VNC7QXcA@mail.gmail.com>

Hi Adivya,

I assume there might be several things there.

First of all, is the NFS mount configured in a way that will allow
glance in different control nodes to access the same image?
Then, when you're restarting glance, do you see any error in the logs?
As I would assume that Glance should error out/disable filestore on
it's startup with providing a reason for that.

Also what do you have in `enabled_backends` under [DEFAULT] section of
glance-api.conf and for default_backend under [glance_store] section?

??, 26 ???. 2023??. ? 16:27, Adivya Singh <adivya1.singh at gmail.com>:
>
> Hi Team,
>
> I am getting OpenStack Glance issue while configuring, it is a remote NFS which i am mounting in a glance container in /var/lib/glance/images
>
>  2023-04-26 14:13:46.973 3260 ERROR glance.api.v2.image_data [req-3b87572c-a508-441b-9a1d-2a0392859f52 4d849540700f412396b24bc913700323 2390988a15a04252825dbb6a6e071321 - default default] Error in store configuration. Adding images to the store is disabled.: glance_store.exceptions.StoreAddDisabled: Configuration for store failed. Adding images to this store is disabled.
>
> Regards
> Adivya Singh


From sbauza at redhat.com  Wed Apr 26 15:22:54 2023
From: sbauza at redhat.com (Sylvain Bauza)
Date: Wed, 26 Apr 2023 17:22:54 +0200
Subject: [horizon][nova][masakari] Instances created with "Any AZ" problem
In-Reply-To: <CAG97radCs2p_egsDey-G_v1JuZ+YYHenSY-y+uABqcoqDu=haQ@mail.gmail.com>
References: <CABAODRfg-m=3_c9ynAW6ZT5sqL=2Q5zwSGB=fX+q+NtBg86=Ew@mail.gmail.com>
 <CAG97rac6PFLNq7AMZe8hLgqF9tYqTbxx0Uj84aF-ux=XAW+vRQ@mail.gmail.com>
 <CALOCmump0kJ-2BMri-wP=8frgKAofqEj9BmDfkZgetK1uXfOGA@mail.gmail.com>
 <173abaa4b89efc8594b08c1c256bc873f3192828.camel@redhat.com>
 <CALOCmumceqTz-BDX2OOdvLi1gbQGsDJpnsh5RT2z+nAjQtvMQA@mail.gmail.com>
 <c0ad091d2030ed7416c2117ad9e9debff60941e6.camel@redhat.com>
 <CALOCmumSkbPcwfo9LhpCd=A6tFveeVFm=EtojKX6v1E3pa_9Ug@mail.gmail.com>
 <CABAODRe_vYVnTiG+QnkJdawiaXeRCiLp8o5c4tZLa3AsGggVLw@mail.gmail.com>
 <CABAODRcUSTxfJodFijJJA4FqeW+=uxP__xbRFV9MjaJ26wwFBA@mail.gmail.com>
 <CALOCmum1PwzFYEG-Go1KMjHk5L4RGNEFRabgw0vJ5QaFG9yUMg@mail.gmail.com>
 <CABAODRfQS_5mtL08XAYnxiOVBU3tB-dDCALWW77mhf+DivD4MA@mail.gmail.com>
 <CABAODReEPT0iJRM3oU+S6RD4NjwNXyfmcU6O8=qzq7WQoudbEg@mail.gmail.com>
 <CAG97radCs2p_egsDey-G_v1JuZ+YYHenSY-y+uABqcoqDu=haQ@mail.gmail.com>
Message-ID: <CALOCmukAk7pjM-fTcv_ztHuuzaLfh3CvLAN=uhJkOiRayzvZXg@mail.gmail.com>

Le mer. 26 avr. 2023 ? 14:46, Rafael Weing?rtner <
rafaelweingartner at gmail.com> a ?crit :

> Adding the response to this thread, as I replied in the wrong one. Sorry
> for the confusion.
>
> Hello Sylvain Bauza and Sean Mooney,
>
> The patch pointed out in [1] is doing exactly what you said that we should
> not do. I mean, changing the AZ in the request spec of the virtual machine
> (VM) that the user created. The patch we propose in [2] is intended to
> avoid exactly that.
>
> As pointed out by Florian, the configuration "cross_az_attach" is a
> constraint of the cloud environment, and as such it should be considered
> when selecting hosts to execute VMs migrations. Therefore, for those
> situations, and only for those (cross_az_attach=False), we send the current
> AZ of the VM to placement, to enable it (placement) to filter out hosts
> that are not from the current AZ of the VM.
>
> Looking at the patch suggested by you in [1], and later testing it, we can
> confirm that the problem is still there in main/upstream. This happens
> because the patch in [1] is only addressing the cases when the VM is
> created based on volumes, and then it sets the AZ of the volumes in the
> request spec of the VM. That is why everything works for the setups where
> cross_az_attach=False. However, if we create a VM based on an image, and
> then it (Nova) creates a new volume in Cinder, the AZ is not set in the
> request spec (but it is used to execute the first call to placement to
> select the hosts); thus, the issues described in [2] can still happen.
>
> Anyways, the proposal presented in [2] is simpler and works nicely. We can
> discuss it further in the patchset then, if you guys think it is worth it.
>
>
As I replied in the gerrit change
https://review.opendev.org/c/openstack/nova/+/864760/comments/4a302ce3_9805e7c6
then you should create a Launchpad bug report but fwiw, you should also
modify the implementation as it would rather do the same for image metadata
that what we do for volumes with [1]

-Sylvain

[1]
> https://review.opendev.org/c/openstack/nova/+/469675/12/nova/compute/api.py#1173
> [2] https://review.opendev.org/c/openstack/nova/+/864760
>
> On Wed, Mar 29, 2023 at 10:26?AM Nguy?n H?u Kh?i <
> nguyenhuukhoinw at gmail.com> wrote:
>
>> "If they *don't* provide this parameter, then depending on the
>> default_schedule_zone config option, either the instance will eventually
>> use a specific AZ (and then it's like if the enduser was asking for this
>> AZ), or none of AZ is requested and then the instance can be created and
>> moved between any hosts within *all* AZs."
>>
>> I ask aftet that, although without az when launch instances but they
>> still have az. But i still mv to diffent host in diffent az when mirgrating
>> or spawn which masakari. i am not clear, I tested.
>>
>>
>> On Wed, Mar 29, 2023, 7:38 PM Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
>> wrote:
>>
>>> Yes. Thanks, but the things I would like to know: after instances are
>>> created, how do we know if it was launched with specified AZ or without it?
>>> I mean the way to distinguish between specified instances and non specified
>>> instances?
>>>
>>> Nguyen Huu Khoi
>>>
>>>
>>> On Wed, Mar 29, 2023 at 5:05?PM Sylvain Bauza <sbauza at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> Le mer. 29 mars 2023 ? 08:06, Nguy?n H?u Kh?i <
>>>> nguyenhuukhoinw at gmail.com> a ?crit :
>>>>
>>>>> Hello.
>>>>> I have one question.
>>>>> Follow this
>>>>>
>>>>> https://docs.openstack.org/nova/latest/admin/availability-zones.html
>>>>>
>>>>> If the server was not created in a specific zone then it is free to be
>>>>> moved to other zones. but when I use
>>>>>
>>>>> openstack server show [server id]
>>>>>
>>>>> I still see the "OS-EXT-AZ:availability_zone" value belonging to my
>>>>> instance.
>>>>>
>>>>>
>>>> Correct, this is normal. If the operators creates some AZs, then the
>>>> enduser should see where the instance in which AZ.
>>>>
>>>>
>>>>> Could you tell the difference which causes "if the server was not
>>>>> created in a specific zone then it is free to be moved to other zones.
>>>>> "
>>>>>
>>>>>
>>>> To be clear, an operator can create Availability Zones. Those AZs can
>>>> then be seen by an enduser using the os-availability-zones API [1]. Then,
>>>> either the enduser wants to use a specific AZ for their next instance
>>>> creation (and if so, he/she adds --availability-zone parameter to their
>>>> instance creation client) or they don't want and then they don't provide
>>>> this parameter.
>>>>
>>>> If they provide this parameter, then the server will be created only in
>>>> one host in the specific AZ and then when moving the instance later, it
>>>> will continue to move to any host within the same AZ.
>>>> If they *don't* provide this parameter, then depending on the
>>>> default_schedule_zone config option, either the instance will eventually
>>>> use a specific AZ (and then it's like if the enduser was asking for this
>>>> AZ), or none of AZ is requested and then the instance can be created and
>>>> moved between any hosts within *all* AZs.
>>>>
>>>> That being said, as I said earlier, the enduser can still verify the AZ
>>>> from where the instance is by the server show parameter you told.
>>>>
>>>> We also have a documentation explaining about Availability Zones, maybe
>>>> this would help you more to understand about AZs :
>>>> https://docs.openstack.org/nova/latest/admin/availability-zones.html
>>>>
>>>>
>>>> [1]
>>>> https://docs.openstack.org/api-ref/compute/#availability-zones-os-availability-zone
>>>> (tbc, the enduser won't see the hosts, but they can see the list of
>>>> existing AZs)
>>>>
>>>>
>>>>
>>>>> Nguyen Huu Khoi
>>>>>
>>>>>
>>>>> On Mon, Mar 27, 2023 at 8:37?PM Nguy?n H?u Kh?i <
>>>>> nguyenhuukhoinw at gmail.com> wrote:
>>>>>
>>>>>> Hello guys.
>>>>>>
>>>>>> I just suggest to openstack nova works better. My story because
>>>>>>
>>>>>>
>>>>>>    1.
>>>>>>
>>>>>>    The server was created in a specific zone with the POST /servers request
>>>>>>    containing the availability_zone parameter.
>>>>>>
>>>>>> It will be nice when we attach randow zone when we create instances
>>>>>> then It will only move to the same zone when migrating or masakari ha.
>>>>>>
>>>>>> Currently we can force it to zone by default zone shedule in
>>>>>> nova.conf.
>>>>>>
>>>>>> Sorry because I am new to Openstack and I am just an operator. I try
>>>>>> to verify some real cases.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Nguyen Huu Khoi
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 27, 2023 at 7:43?PM Sylvain Bauza <sbauza at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le lun. 27 mars 2023 ? 14:28, Sean Mooney <smooney at redhat.com> a
>>>>>>> ?crit :
>>>>>>>
>>>>>>>> On Mon, 2023-03-27 at 14:06 +0200, Sylvain Bauza wrote:
>>>>>>>> > Le lun. 27 mars 2023 ? 13:51, Sean Mooney <smooney at redhat.com> a
>>>>>>>> ?crit :
>>>>>>>> >
>>>>>>>> > > On Mon, 2023-03-27 at 10:19 +0200, Sylvain Bauza wrote:
>>>>>>>> > > > Le dim. 26 mars 2023 ? 14:30, Rafael Weing?rtner <
>>>>>>>> > > > rafaelweingartner at gmail.com> a ?crit :
>>>>>>>> > > >
>>>>>>>> > > > > Hello Nguy?n H?u Kh?i,
>>>>>>>> > > > > You might want to take a look at:
>>>>>>>> > > > > https://review.opendev.org/c/openstack/nova/+/864760. We
>>>>>>>> created a
>>>>>>>> > > patch
>>>>>>>> > > > > to avoid migrating VMs to any AZ, once the VM has been
>>>>>>>> bootstrapped in
>>>>>>>> > > an
>>>>>>>> > > > > AZ that has cross zone attache equals to false.
>>>>>>>> > > > >
>>>>>>>> > > > >
>>>>>>>> > > > Well, I'll provide some comments in the change, but I'm
>>>>>>>> afraid we can't
>>>>>>>> > > > just modify the request spec like you would want.
>>>>>>>> > > >
>>>>>>>> > > > Anyway, if you want to discuss about it in the vPTG, just add
>>>>>>>> it in the
>>>>>>>> > > > etherpad and add your IRC nick so we could try to find a time
>>>>>>>> where we
>>>>>>>> > > > could be discussing it :
>>>>>>>> https://etherpad.opendev.org/p/nova-bobcat-ptg
>>>>>>>> > > > Also, this kind of behaviour modification is more a new
>>>>>>>> feature than a
>>>>>>>> > > > bugfix, so fwiw you should create a launchpad blueprint so we
>>>>>>>> could
>>>>>>>> > > better
>>>>>>>> > > > see it.
>>>>>>>> > >
>>>>>>>> > > i tought i left review feedback on that too that the approch
>>>>>>>> was not
>>>>>>>> > > correct.
>>>>>>>> > > i guess i did not in the end.
>>>>>>>> > >
>>>>>>>> > > modifying the request spec as sylvain menthioned is not correct.
>>>>>>>> > > i disucssed this topic on irc a few weeks back with mohomad for
>>>>>>>> vxhost.
>>>>>>>> > > what can be done is as follows.
>>>>>>>> > >
>>>>>>>> > > we can add a current_az field  to the Destination object
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L1092-L1122
>>>>>>>> > > The conductor can read the instance.AZ and populate it in that
>>>>>>>> new field.
>>>>>>>> > > We can then add a new weigher to prefer hosts that are in the
>>>>>>>> same az.
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> >
>>>>>>>> > I tend to disagree this approach as people would think that the
>>>>>>>> > Destination.az field would be related to the current AZ for an
>>>>>>>> instance,
>>>>>>>> > while we only look at the original AZ.
>>>>>>>> > That being said, we could have a weigher that would look at
>>>>>>>> whether the
>>>>>>>> > host is in the same AZ than the instance.host.
>>>>>>>> you miss understood what i wrote
>>>>>>>>
>>>>>>>> i suggested addint Destination.current_az to store teh curernt AZ
>>>>>>>> of the instance before scheduling.
>>>>>>>>
>>>>>>>> so my proposal is if RequestSpec.AZ is not set and
>>>>>>>> Destination.current_az is set then the new
>>>>>>>> weigher would prefer hosts that are in the same az as
>>>>>>>> Destination.current_az
>>>>>>>>
>>>>>>>> we coudl also call Destination.current_az Destination.prefered_az
>>>>>>>>
>>>>>>>>
>>>>>>> I meant, I think we don't need to provide a new field, we can
>>>>>>> already know about what host an existing instance uses if we want (using
>>>>>>> [1])
>>>>>>> Anyway, let's stop to discuss about it here, we should rather review
>>>>>>> that for a Launchpad blueprint or more a spec.
>>>>>>>
>>>>>>> -Sylvain
>>>>>>>
>>>>>>> [1]
>>>>>>> https://github.com/openstack/nova/blob/b9a49ffb04cb5ae2d8c439361a3552296df02988/nova/scheduler/host_manager.py#L369-L370
>>>>>>>
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > This will provide soft AZ affinity for the vm and preserve the
>>>>>>>> fact that if
>>>>>>>> > > a vm is created without sepcifying
>>>>>>>> > > An AZ the expectaiton at the api level woudl be that it can
>>>>>>>> migrate to any
>>>>>>>> > > AZ.
>>>>>>>> > >
>>>>>>>> > > To provide hard AZ affintiy we could also add prefileter that
>>>>>>>> would use
>>>>>>>> > > the same data but instead include it in the
>>>>>>>> > > placement query so that only the current AZ is considered. This
>>>>>>>> would have
>>>>>>>> > > to be disabled by default.
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> > Sure, we could create a new prefilter so we could then deprecate
>>>>>>>> the
>>>>>>>> > AZFilter if we want.
>>>>>>>> we already have an AZ prefilter and the AZFilter is deprecate for
>>>>>>>> removal
>>>>>>>> i ment to delete it in zed but did not have time to do it in zed of
>>>>>>>> Antielope
>>>>>>>> i deprecated the AZ| filter in
>>>>>>>> https://github.com/openstack/nova/commit/7c7a2a142d74a7deeda2a79baf21b689fe32cd08
>>>>>>>> xena when i enabeld the az prefilter by default.
>>>>>>>>
>>>>>>>>
>>>>>>> Ah whoops, indeed I forgot the fact we already have the prefilter,
>>>>>>> so the hard support for AZ is already existing.
>>>>>>>
>>>>>>>
>>>>>>>> i will try an delete teh AZ filter before m1 if others dont.
>>>>>>>>
>>>>>>>
>>>>>>> OK.
>>>>>>>
>>>>>>>
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > > That woudl allow operators to choose the desired behavior.
>>>>>>>> > > curret behavior (disable weigher and dont enabel prefilter)
>>>>>>>> > > new default, prefer current AZ (weigher enabeld prefilter
>>>>>>>> disabled)
>>>>>>>> > > hard affintiy(prefilter enabled.)
>>>>>>>> > >
>>>>>>>> > > there are other ways to approch this but updating the request
>>>>>>>> spec is not
>>>>>>>> > > one of them.
>>>>>>>> > > we have to maintain the fact the enduser did not request an AZ.
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>> > Anyway, if folks want to discuss about AZs, this week is the good
>>>>>>>> time :-)
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > > >
>>>>>>>> > > > -Sylvain
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > > > On Sun, Mar 26, 2023 at 8:20?AM Nguy?n H?u Kh?i <
>>>>>>>> > > nguyenhuukhoinw at gmail.com>
>>>>>>>> > > > > wrote:
>>>>>>>> > > > >
>>>>>>>> > > > > > Hello guys.
>>>>>>>> > > > > > I playing with Nova AZ and Masakari
>>>>>>>> > > > > >
>>>>>>>> > > > > >
>>>>>>>> https://docs.openstack.org/nova/latest/admin/availability-zones.html
>>>>>>>> > > > > >
>>>>>>>> > > > > > Masakari will move server by nova scheduler.
>>>>>>>> > > > > >
>>>>>>>> > > > > > Openstack Docs describe that:
>>>>>>>> > > > > >
>>>>>>>> > > > > > If the server was not created in a specific zone then it
>>>>>>>> is free to
>>>>>>>> > > be
>>>>>>>> > > > > > moved to other zones, i.e. the AvailabilityZoneFilter
>>>>>>>> > > > > > <
>>>>>>>> > >
>>>>>>>> https://docs.openstack.org/nova/latest/admin/scheduling.html#availabilityzonefilter
>>>>>>>> >
>>>>>>>> > > is
>>>>>>>> > > > > > a no-op.
>>>>>>>> > > > > >
>>>>>>>> > > > > > I see that everyone usually creates instances with "Any
>>>>>>>> Availability
>>>>>>>> > > > > > Zone" on Horzion and also we don't specify AZ when
>>>>>>>> creating
>>>>>>>> > > instances by
>>>>>>>> > > > > > cli.
>>>>>>>> > > > > >
>>>>>>>> > > > > > By this way, when we use Masakari or we miragrated
>>>>>>>> instances( or
>>>>>>>> > > > > > evacuate) so our instance will be moved to other zones.
>>>>>>>> > > > > >
>>>>>>>> > > > > > Can we attach AZ to server create requests API based on
>>>>>>>> Any
>>>>>>>> > > > > > Availability Zone to limit instances moved to other zones?
>>>>>>>> > > > > >
>>>>>>>> > > > > > Thank you. Regards
>>>>>>>> > > > > >
>>>>>>>> > > > > > Nguyen Huu Khoi
>>>>>>>> > > > > >
>>>>>>>> > > > >
>>>>>>>> > > > >
>>>>>>>> > > > > --
>>>>>>>> > > > > Rafael Weing?rtner
>>>>>>>> > > > >
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>>
>>>>>>>>
>
> --
> Rafael Weing?rtner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/13191122/attachment-0001.htm>

From rosmaita.fossdev at gmail.com  Wed Apr 26 16:16:41 2023
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Wed, 26 Apr 2023 12:16:41 -0400
Subject: [release][cinder] please delete cinderlib stable/ussuri branch
Message-ID: <0faa7bfc-f70c-5c04-3b24-0aa3d603da80@gmail.com>

Hello Release Team,

Some changes were bot-proposed recently to the cinderlib stable/ussuri 
branch, which was weird because that branch was tagged EOL by change
I75092342fe684892f8a73eab9ad5da4515cb1da5.  The change merged on 
2022-08-31, and the ussuri-eol tag exists in the code repository, but 
apparently the branch was never deleted.  Could you please delete the 
branch?

thanks!


From alsotoes at gmail.com  Wed Apr 26 18:21:37 2023
From: alsotoes at gmail.com (Alvaro Soto)
Date: Wed, 26 Apr 2023 12:21:37 -0600
Subject: VM doesn't boot after qemu-img convert from VMDK to RAW/QCOW2 Edit
In-Reply-To: <CAF6XWq7+GZXQ+brHRiUPOgu_QrBJs+Tq27Q46Qxv=jgVXAn1Yw@mail.gmail.com>
References: <CAF6XWq7+GZXQ+brHRiUPOgu_QrBJs+Tq27Q46Qxv=jgVXAn1Yw@mail.gmail.com>
Message-ID: <CA+eLJkYWVC0OqV5h3j6yV--vhFQKwNATW1A5M2aW-L_DVHA3UA@mail.gmail.com>

Hey David,
I agree with the issue being outside Nova.
Now, Windows doesn't support significant hardware changes very well.
I'm just wondering if you prepared the image after testing: removed VMware
drivers and installed virtio drivers.

Cheers!

On Mon, Apr 24, 2023 at 2:23?PM David Francisco Le?n Vera <david at octapus.io>
wrote:

> Hi!
>
> Can someone help me? I have an issue migrating VMWare VMs to OpenStack
> with KVM-QEMU ... the VMDK file converted to qcow2 format doesn't boot,
> especially with Windows Server 2016 and 2019. I tried a lot of ways, but I
> still finish with an unbootable disk in Nova.
>
> I explained with more details my problem here:
> https://bugs.launchpad.net/nova/+bug/2017358
>
>
> *Before printing, think about your responsibility and commitment to the
> ENVIRONMENT.*
>
> The information contained in this email and in any attached file is sent
> only for the use of the person or entity to which it is addressed and / or
> authorized third parties. This release may contain confidential and / or
> legally privileged information. If you are not the recipient or have
> received this email in error, we request that you notify the sender of this
> message and destroy this email, its attachments, and any copies or backups
> thereof immediately. If you are not the indicated recipient, you are
> notified that the total or partial distribution, printing or reproduction
> of this message is strictly prohibited, it could be considered illegal and
> sent to the corresponding authorities.
>
> Emails are not necessarily a secure means of transmission, so the sender
> will not be responsible at any time for the changes in your transfer, for
> attacks in the medium, so no responsibility is assumed in case of mutations
> in their transfer and it will always be necessary for the recipient to
> check them before opening them. Octapus is not responsible for the correct
> and complete transmission of the information contained in this
> communication, nor for any delay in receiving it.
>
> If you want to know about our privacy notice, go to:
> <https://on-cloud.com/avisos-de-privacidad/>
> https://octapus.io/aviso-de-privacidad/
>
>
>
> *Antes de imprimir piense en su responsabilidad y compromiso con el MEDIO
> AMBIENTE.*
> La informaci?n contenida en este correo electr?nico y en cualquier archivo
> adjunto es enviada ?nicamente para el uso de la persona o entidad a quien
> est? dirigida y/o terceros autorizados. Este comunicado puede contener
> informaci?n confidencial y/o legalmente privilegiada. Si usted no es el
> destinatario o ha recibido este correo por error, le solicitamos notificar
> al emisor de este mensaje y destruir este correo, sus archivos adjuntos y
> cualquier copia o respaldo del mismo inmediatamente. Si usted no es el
> destinatario indicado, queda notificado que la distribuci?n, impresi?n o
> reproducci?n, total o parcial del presente mensaje est? estrictamente
> prohibida, podr?a ser considerado ilegal y remitido a las autoridades
> correspondientes.
> Los correos electr?nicos no son necesariamente un medio de transmisi?n
> seguro, por lo que el remitente no ser? responsable en ning?n momento por
> los cambios que se sufra en su transferencia, por ataques en el medio, por
> lo que tampoco se asume ninguna responsabilidad en caso de mutaciones en su
> transferencia y ser? siempre necesario para el destinatario revisarlos
> antes de abrirlos.  Octapus no es responsable por la correcta y completa
> transmisi?n de la informaci?n contenida en esta comunicaci?n, y tampoco por
> cualquier retraso en su recepci?n.
> Si usted desea conocer sobre nuestro aviso de privacidad, ingresa a:
> <https://on-cloud.com/avisos-de-privacidad/>
> https://octapus.io/aviso-de-privacidad/
>


-- 

Alvaro Soto

*Note: My work hours may not be your work hours. Please do not feel the
need to respond during a time that is not convenient for you.*
----------------------------------------------------------
Great people talk about ideas,
ordinary people talk about things,
small people talk... about other people.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/d7f5ea9f/attachment.htm>

From weixu at iastate.edu  Wed Apr 26 19:51:08 2023
From: weixu at iastate.edu (Xu, Wei [E CPE])
Date: Wed, 26 Apr 2023 19:51:08 +0000
Subject: OpenStack Swift quota
In-Reply-To: <fb5d37ba-1344-16e8-f2bf-f469afd696b6@debian.org>
References: <SA1PR04MB854472CC6D76D00245BFF81FA9609@SA1PR04MB8544.namprd04.prod.outlook.com>
 <19abee38-30f0-d45d-75c5-8823aa630c32@debian.org>
 <SA1PR04MB85448F20BE1BBF164ECC9774A9679@SA1PR04MB8544.namprd04.prod.outlook.com>
 <cccee798-6f57-4b72-4e88-1cf57416277f@debian.org>
 <SA1PR04MB8544F697E51FEBA8EEC20FF7A9649@SA1PR04MB8544.namprd04.prod.outlook.com>
 <fb5d37ba-1344-16e8-f2bf-f469afd696b6@debian.org>
Message-ID: <SA1PR04MB8544BD41D47B42A20538E936A9659@SA1PR04MB8544.namprd04.prod.outlook.com>

Hello Thomas,

According to what we read from the OpenStack Swift quota documentation, only users with ResellerAdmin role can change the project quota settings. Right now for our Admin user we have already obtained the ResellerAdmin role (See the screenshot below), and yet we are still receiving the same 403 forbidden error. I believe the command itself is not having any errors and the Swift log did not record all these 403 errors. I doubt could it be somewhere in the Keystone that is buggy?

[cid:f7b30b2d-dfa0-4bc7-a813-74413b09ef55]

Yours sincerely,

Wei
________________________________
From: Thomas Goirand <zigo at debian.org>
Sent: Wednesday, April 26, 2023 1:38 AM
To: Xu, Wei [E CPE] <weixu at iastate.edu>; openstack-discuss at lists.openstack.org <openstack-discuss at lists.openstack.org>
Cc: Babu, Sarath [E CPE] <sarath4 at IASTATE.EDU>
Subject: Re: OpenStack Swift quota

On 4/25/23 22:39, Xu, Wei [E CPE] wrote:
> Hello Thomas,
>
> We have just tried the command you provided, however it is showing the
> exact same error we had before. Is it likely to be some configuration
> error? Or there're some other roles that this admin user must obtain?

It's likely that the error message is right by saying "forbidden", ie,
you don't have enough right (so, the 2nd possibility...).

Cheers,

Thomas Goirand (zigo)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/3b83d3eb/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 94420 bytes
Desc: image.png
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/3b83d3eb/attachment-0001.png>

From zigo at debian.org  Wed Apr 26 19:59:18 2023
From: zigo at debian.org (Thomas Goirand)
Date: Wed, 26 Apr 2023 21:59:18 +0200
Subject: OpenStack Swift quota
In-Reply-To: <SA1PR04MB8544BD41D47B42A20538E936A9659@SA1PR04MB8544.namprd04.prod.outlook.com>
References: <SA1PR04MB854472CC6D76D00245BFF81FA9609@SA1PR04MB8544.namprd04.prod.outlook.com>
 <19abee38-30f0-d45d-75c5-8823aa630c32@debian.org>
 <SA1PR04MB85448F20BE1BBF164ECC9774A9679@SA1PR04MB8544.namprd04.prod.outlook.com>
 <cccee798-6f57-4b72-4e88-1cf57416277f@debian.org>
 <SA1PR04MB8544F697E51FEBA8EEC20FF7A9649@SA1PR04MB8544.namprd04.prod.outlook.com>
 <fb5d37ba-1344-16e8-f2bf-f469afd696b6@debian.org>
 <SA1PR04MB8544BD41D47B42A20538E936A9659@SA1PR04MB8544.namprd04.prod.outlook.com>
Message-ID: <6885c522-2c2a-a902-2746-a45b458d3895@debian.org>

On 4/26/23 21:51, Xu, Wei [E CPE] wrote:
> Hello Thomas,
> 
> According to what we read from the OpenStack Swift quota documentation, 
> only users with ResellerAdmin role can change the project quota 
> settings. Right now for our Admin user we have already obtained the 
> ResellerAdmin role (See the screenshot below), and yet we are still 
> receiving the same 403 forbidden error. I believe the command itself is 
> not having any errors and the Swift log did not record all these 403 
> errors. I doubt could it be somewhere in the Keystone that is buggy?

Hi,

Please avoid HTML and screenshots when sending to mailing lists.

Have you checked that you have the quota middleware activated (and at 
the correct position) in your swift proxy pipeline?

Cheers,

Thomas Goirand (zigo)



From weixu at iastate.edu  Wed Apr 26 20:28:29 2023
From: weixu at iastate.edu (Xu, Wei [E CPE])
Date: Wed, 26 Apr 2023 20:28:29 +0000
Subject: OpenStack Swift quota
In-Reply-To: <6885c522-2c2a-a902-2746-a45b458d3895@debian.org>
References: <SA1PR04MB854472CC6D76D00245BFF81FA9609@SA1PR04MB8544.namprd04.prod.outlook.com>
 <19abee38-30f0-d45d-75c5-8823aa630c32@debian.org>
 <SA1PR04MB85448F20BE1BBF164ECC9774A9679@SA1PR04MB8544.namprd04.prod.outlook.com>
 <cccee798-6f57-4b72-4e88-1cf57416277f@debian.org>
 <SA1PR04MB8544F697E51FEBA8EEC20FF7A9649@SA1PR04MB8544.namprd04.prod.outlook.com>
 <fb5d37ba-1344-16e8-f2bf-f469afd696b6@debian.org>
 <SA1PR04MB8544BD41D47B42A20538E936A9659@SA1PR04MB8544.namprd04.prod.outlook.com>
 <6885c522-2c2a-a902-2746-a45b458d3895@debian.org>
Message-ID: <SA1PR04MB854482D599670872A6B438BAA9659@SA1PR04MB8544.namprd04.prod.outlook.com>

Hello Thomas,

We have just figured out what caused the authentication issue. Before doing any quota-related operations we need to manually assign the ResellerAdmin role to our user. By default, even if it's an admin user it does not have the ResellerAdmin role assigned.

Right now we have successfully executed both "swift post -m quota-bytes:5000" and "swift --os-storage-url  https://<proxy-url>/v1/AUTH_<PROJECT-ID> post -m quota-bytes:5000". But after this step we can still upload files that are much larger than 5000 bytes to containers. Are there any other prerequisites that we miss? In order to let the project level quota work, what else do we need to implement?

I'm looking forward to hearing from you! Thanks again!

Wei Xu, M.S.
Research Assistant
Department of ECpE,
Iowa State University
________________________________
From: Thomas Goirand <zigo at debian.org>
Sent: Wednesday, April 26, 2023 2:59 PM
To: Xu, Wei [E CPE] <weixu at iastate.edu>; openstack-discuss at lists.openstack.org <openstack-discuss at lists.openstack.org>
Cc: Babu, Sarath [E CPE] <sarath4 at IASTATE.EDU>
Subject: Re: OpenStack Swift quota

On 4/26/23 21:51, Xu, Wei [E CPE] wrote:
> Hello Thomas,
>
> According to what we read from the OpenStack Swift quota documentation,
> only users with ResellerAdmin role can change the project quota
> settings. Right now for our Admin user we have already obtained the
> ResellerAdmin role (See the screenshot below), and yet we are still
> receiving the same 403 forbidden error. I believe the command itself is
> not having any errors and the Swift log did not record all these 403
> errors. I doubt could it be somewhere in the Keystone that is buggy?

Hi,

Please avoid HTML and screenshots when sending to mailing lists.

Have you checked that you have the quota middleware activated (and at
the correct position) in your swift proxy pipeline?

Cheers,

Thomas Goirand (zigo)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230426/c5c88ccc/attachment.htm>

From navidsakhawat at gmail.com  Thu Apr 27 06:29:36 2023
From: navidsakhawat at gmail.com (Navid Bin Sakhawat)
Date: Thu, 27 Apr 2023 12:29:36 +0600
Subject: VM doesn't boot after qemu-img convert from VMDK to RAW/QCOW2 Edit
In-Reply-To: <CAF6XWq7+GZXQ+brHRiUPOgu_QrBJs+Tq27Q46Qxv=jgVXAn1Yw@mail.gmail.com>
References: <CAF6XWq7+GZXQ+brHRiUPOgu_QrBJs+Tq27Q46Qxv=jgVXAn1Yw@mail.gmail.com>
Message-ID: <CALAnsfKj05m5XK1bF+dsav0W-5kK8WOD=9pa6jj5z8dJhs0ctg@mail.gmail.com>

You can follow the below link

https://opensource-docs.brilliant.com.bd/converting-between-image-formats-raw-vmdk-to-qcow2/

On Tue, Apr 25, 2023, 2:28 AM David Francisco Le?n Vera <david at octapus.io>
wrote:

> Hi!
>
> Can someone help me? I have an issue migrating VMWare VMs to OpenStack
> with KVM-QEMU ... the VMDK file converted to qcow2 format doesn't boot,
> especially with Windows Server 2016 and 2019. I tried a lot of ways, but I
> still finish with an unbootable disk in Nova.
>
> I explained with more details my problem here:
> https://bugs.launchpad.net/nova/+bug/2017358
>
>
> *Before printing, think about your responsibility and commitment to the
> ENVIRONMENT.*
>
> The information contained in this email and in any attached file is sent
> only for the use of the person or entity to which it is addressed and / or
> authorized third parties. This release may contain confidential and / or
> legally privileged information. If you are not the recipient or have
> received this email in error, we request that you notify the sender of this
> message and destroy this email, its attachments, and any copies or backups
> thereof immediately. If you are not the indicated recipient, you are
> notified that the total or partial distribution, printing or reproduction
> of this message is strictly prohibited, it could be considered illegal and
> sent to the corresponding authorities.
>
> Emails are not necessarily a secure means of transmission, so the sender
> will not be responsible at any time for the changes in your transfer, for
> attacks in the medium, so no responsibility is assumed in case of mutations
> in their transfer and it will always be necessary for the recipient to
> check them before opening them. Octapus is not responsible for the correct
> and complete transmission of the information contained in this
> communication, nor for any delay in receiving it.
>
> If you want to know about our privacy notice, go to:
> <https://on-cloud.com/avisos-de-privacidad/>
> https://octapus.io/aviso-de-privacidad/
>
>
>
> *Antes de imprimir piense en su responsabilidad y compromiso con el MEDIO
> AMBIENTE.*
> La informaci?n contenida en este correo electr?nico y en cualquier archivo
> adjunto es enviada ?nicamente para el uso de la persona o entidad a quien
> est? dirigida y/o terceros autorizados. Este comunicado puede contener
> informaci?n confidencial y/o legalmente privilegiada. Si usted no es el
> destinatario o ha recibido este correo por error, le solicitamos notificar
> al emisor de este mensaje y destruir este correo, sus archivos adjuntos y
> cualquier copia o respaldo del mismo inmediatamente. Si usted no es el
> destinatario indicado, queda notificado que la distribuci?n, impresi?n o
> reproducci?n, total o parcial del presente mensaje est? estrictamente
> prohibida, podr?a ser considerado ilegal y remitido a las autoridades
> correspondientes.
> Los correos electr?nicos no son necesariamente un medio de transmisi?n
> seguro, por lo que el remitente no ser? responsable en ning?n momento por
> los cambios que se sufra en su transferencia, por ataques en el medio, por
> lo que tampoco se asume ninguna responsabilidad en caso de mutaciones en su
> transferencia y ser? siempre necesario para el destinatario revisarlos
> antes de abrirlos.  Octapus no es responsable por la correcta y completa
> transmisi?n de la informaci?n contenida en esta comunicaci?n, y tampoco por
> cualquier retraso en su recepci?n.
> Si usted desea conocer sobre nuestro aviso de privacidad, ingresa a:
> <https://on-cloud.com/avisos-de-privacidad/>
> https://octapus.io/aviso-de-privacidad/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230427/304f4446/attachment-0001.htm>

From bsanjeewa at kln.ac.lk  Thu Apr 27 06:56:17 2023
From: bsanjeewa at kln.ac.lk (Buddhika S. Godakuru - University of Kelaniya)
Date: Thu, 27 Apr 2023 12:26:17 +0530
Subject: [kolla-ansible][swift][ceph]
In-Reply-To: <CABAODRfz1891VpZbSP2NzcW6pOmXvTdeph9WfMfRojwzC40wSg@mail.gmail.com>
References: <CABAODRc1SLeGT4oxH0srAp8nL06_iNrcTLQioGg1w948SBUSGg@mail.gmail.com>
 <LO2P265MB5773F165E355BDCA0C7F811A9A659@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <LO2P265MB577320D0FABCCE59432F22D09A659@LO2P265MB5773.GBRP265.PROD.OUTLOOK.COM>
 <CABAODReCqi8+mCrvFwz9U_zfZJ3_-cWKokOEQpW0z4a4oojF0A@mail.gmail.com>
 <20230426134711.Horde.p7SlAs9sxHVYKvE0d9Laspa@webmail.nde.ag>
 <CABAODRfz1891VpZbSP2NzcW6pOmXvTdeph9WfMfRojwzC40wSg@mail.gmail.com>
Message-ID: <CACHrkDAGzFGX3UyJVtxixKOjNxk05h20Q9_3VerEOCoKhoZjdw@mail.gmail.com>

Dear All,
I was able to use ceph RadosGW without swift using kolla-ansible External
Ceph guide [1]. Please give it a go.

Thanks


[1]
https://docs.openstack.org/kolla-ansible/latest/reference/storage/external-ceph-guide.html#radosgw

On Wed, 26 Apr 2023 at 20:22, Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
wrote:

> Hello.
> I was able to make swift run with ceph by restart osd daemon. .
>
> Thank you @Danny Webb <Danny.Webb at thehutgroup.com> and @Eugen Block
> <eblock at nde.ag>. I follow your advices and do it.
> Summary:
> recreate swift endpoint which need point ceph gw
> create openstack user and account for ceph gw. project is service
> and set parameters like
> https://docs.ceph.com/en/latest/radosgw/keystone/
>
> with new cephadm we need use "ceph config set" and restart osd daemon.
>
>
> @Jeremy Stanley <fungi at yuggoth.org> I think too. Is there any idea use
> ceph instead of swift completely? I feel not much people use swift.
>
> Nguyen Huu Khoi
>
>
> On Wed, Apr 26, 2023 at 8:56?PM Eugen Block <eblock at nde.ag> wrote:
>
>> Hi,
>>
>> not so long ago I wrote down what was necessary in my lab environment
>> to configure a cephadm based cluster with keystone authentication for
>> S3 (swift) clients. In Openstack you need swift endpoints which point
>> to the rados gateway(s) in your external ceph cluster. So you don't
>> really set up swift but only create the endpoints for your clients. I
>> can't comment what exactly needs to be done with kolla but you should
>> get the general idea, I hope.
>>
>> Regards,
>> Eugen
>>
>> [1]
>>
>> https://serverfault.com/questions/1118004/cephadm-openstack-keystone-integration
>>
>> Zitat von Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>:
>>
>> > Hello. Thank you for your email,
>> > But the problem is that I use cephadm so it is not like a traditional
>> way
>> > to configure, I am trying to test.
>> > Nguyen Huu Khoi
>> >
>> >
>> > On Wed, Apr 26, 2023 at 3:51?PM Danny Webb <Danny.Webb at thehutgroup.com>
>> > wrote:
>> >
>> >> https://docs.ceph.com/en/latest/radosgw/keystone/
>> >> ------------------------------
>> >> *From:* Danny Webb <Danny.Webb at thehutgroup.com>
>> >> *Sent:* 26 April 2023 09:50
>> >> *To:* Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>; OpenStack Discuss <
>> >> openstack-discuss at lists.openstack.org>
>> >> *Subject:* Re: [kolla-ansible][swift][ceph]
>> >>
>> >> So if I remember correctly from when we did this a long while back, you
>> >> don't really do much on the openstack deployment side.   Ceph comes
>> with a
>> >> swift compliant interface so the only thing required was in the
>> ceph.conf
>> >> to enable keystone as an authentication mechanism.
>> >> ------------------------------
>> >> *From:* Nguy?n H?u Kh?i <nguyenhuukhoinw at gmail.com>
>> >> *Sent:* 26 April 2023 02:08
>> >> *To:* OpenStack Discuss <openstack-discuss at lists.openstack.org>
>> >> *Subject:* [kolla-ansible][swift][ceph]
>> >>
>> >>
>> >> * CAUTION: This email originates from outside THG *
>> >> ------------------------------
>> >> Hello guys.
>> >> I am working to make openstack swift save data on ceph. I am using
>> kolla
>> >> ansible and see it need enable swift first but I don't want to make
>> swift
>> >> ring on my controller. I just want use external ceph.
>> >> Pls you give me some advices
>> >> Thank you
>> >> Nguyen Huu Khoi
>> >>
>>
>>
>>
>>
>>

-- 

??????? ????? ????????
Buddhika Sanjeewa Godakuru

Systems Analyst/Programmer
Deputy Webmaster / University of Kelaniya

Information and Communication Technology Centre (ICTC)
University of Kelaniya, Sri Lanka,
Kelaniya,
Sri Lanka.

Mobile : (+94) 071 5696981
Office : (+94) 011 2903420 / 2903424

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++?
University 
of Kelaniya Sri Lanka, accepts no liability for the 
content of this email, 
or for the consequences of any actions taken on 
the basis of the 
information provided, unless that information is 
subsequently confirmed in 
writing. If you are not the intended 
recipient, this email and/or any 
information it contains should not be 
copied, disclosed, retained or used 
by you or any other party and the 
email and all its contents should be 
promptly deleted fully from our 
system and the sender informed.





E-mail transmission cannot be guaranteed to be secure or error-free 
as 
information could be intercepted, corrupted, lost, destroyed, arrive 
late 
or incomplete.





+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230427/7815ea70/attachment.htm>

From gregory.orange at pawsey.org.au  Thu Apr 27 07:35:18 2023
From: gregory.orange at pawsey.org.au (Gregory Orange)
Date: Thu, 27 Apr 2023 15:35:18 +0800
Subject: [neutron] [kolla-ansible] alembic mismatch, schema differences
In-Reply-To: <1892258.J3ZZrq5oHq@p1>
References: <d7cae712-bf0c-9144-38cb-ad8fe61f6d54@pawsey.org.au>
 <532a6f17-2cda-112e-1744-4c377b8d843c@pawsey.org.au>
 <20230418113712.Horde.8KfiDAn_9ZqPTQsOnQwwFHu@webmail.nde.ag>
 <1892258.J3ZZrq5oHq@p1>
Message-ID: <477317c2-a271-4c86-d4d8-4ce2cd3bf2aa@pawsey.org.au>

On 18/4/23 20:56, Slawek Kaplonski wrote:
> Dnia wtorek, 18 kwietnia 2023 13:37:12 CEST Eugen Block pisze:
>> Hi, I'm glad you worked that out. But one thing I'm wondering since
>> I'm not familiar with kolla (as I'm stating repeatedly), why does the
>> compute node have the capabilities to manipulate the neutron database?
>> Is that by design?
> It shouldn't. Only neutron-server should have access to the DB.

A question for kolla devs then I guess. Thank you for identifying this 
concern.


>> We have our own deployment mechanism on baremetal
>> and there's no "connection =..." string available on compute nodes.
>> Maybe I misunderstood something, but I find it strange that such a
>> thing could happen that easily.

The following files have the setting on our compute nodes. We haven't 
customised this setting, so its presence wasn't caused by us per se.

# ack -l "^connection =" /etc/kolla
/etc/kolla/neutron-openvswitch-agent/neutron.conf
/etc/kolla/neutron-metadata-agent/neutron.conf
/etc/kolla/neutron-l3-agent/neutron.conf


From elod.illes at est.tech  Thu Apr 27 09:30:54 2023
From: elod.illes at est.tech (=?utf-8?B?RWzDtWQgSWxsw6lz?=)
Date: Thu, 27 Apr 2023 09:30:54 +0000
Subject: [release][cinder] please delete cinderlib stable/ussuri branch
In-Reply-To: <0faa7bfc-f70c-5c04-3b24-0aa3d603da80@gmail.com>
References: <0faa7bfc-f70c-5c04-3b24-0aa3d603da80@gmail.com>
Message-ID: <VI1P18901MB07515515D29455DAB32DEF9AFF6A9@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>

Thanks Brian for signaling this. Actually to me this seems to be a bit more complicated as the branch was deleted i think, but somehow it was recreated (probably with some openstack/releases automation) one week ago. The generated two patches [1][2] suggest that, at least... So it's weird, and I don't see yet what happened.
We need to figure out what happend to prevent it happening again in the future.

I'll run the script today and delete the re-created stable/ussuri branch.

Thanks,

El?d

[1] https://review.opendev.org/c/openstack/cinderlib/+/877783
[2] https://review.opendev.org/c/openstack/cinderlib/+/877784
________________________________
From: Brian Rosmaita <rosmaita.fossdev at gmail.com>
Sent: Wednesday, April 26, 2023 6:16 PM
To: openstack-discuss at lists.openstack.org <openstack-discuss at lists.openstack.org>
Subject: [release][cinder] please delete cinderlib stable/ussuri branch

Hello Release Team,

Some changes were bot-proposed recently to the cinderlib stable/ussuri
branch, which was weird because that branch was tagged EOL by change
I75092342fe684892f8a73eab9ad5da4515cb1da5.  The change merged on
2022-08-31, and the ussuri-eol tag exists in the code repository, but
apparently the branch was never deleted.  Could you please delete the
branch?

thanks!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230427/7fe1a393/attachment-0001.htm>

From stefanbryzga at gmail.com  Thu Apr 27 08:12:38 2023
From: stefanbryzga at gmail.com (Stefan Bryzga)
Date: Thu, 27 Apr 2023 10:12:38 +0200
Subject: [kolla-ansible][watcher]Time zone issue in container
Message-ID: <CAJc0DSZZn7Dst0A66+Tt+HOVxhKEpbU3jbB=YNWqURKgY3pFpQ@mail.gmail.com>

Hi all,

Recently I created fresh deployment based on kolla-ansible yoga and debian
11. Everything works correctly except Watcher services. Containers are in
constant restart loop.
On Debian host OS time-related files are as follows:

lrwxrwxrwx  1 root root      33 Mar 21 07:53 localtime ->
/usr/share/zoneinfo/Europe/Warsaw
-rw-r--r--  1 root root      14 Mar 21 07:53 timezone
x at control01:/etc$ cat timezone
Europe/Warsaw

However every container have:

lrwxrwxrwx 1 root root      27 Apr 11 02:00 localtime ->
/usr/share/zoneinfo/Etc/UTC
-rw-r--r-- 1 root root      14 Mar 21 07:53 timezone
(nova-api)[root at control01 etc]# cat timezone
Europe/Warsaw

In watcher logs I found error:
2023-04-27 10:08:12.607 7 ERROR python-watcher
tzlocal.utils.ZoneInfoNotFoundError: 'Multiple conflicting time zone
configurations found:\n/etc/timezone: Europe/Warsaw\n/etc/localtime is a
symlink to: UTC\nFix the configuration, or set the time zone in a TZ
environment variable.\n'
2023-04-27 10:08:12.607 7 ERROR python-watcher
Which I believe is caused by wrong symlink for /etc/localtime in
containers.

Did anyone experience similar issue and know how to resolve it.

Best regards,
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230427/3886c9b0/attachment.htm>

From satish.txt at gmail.com  Thu Apr 27 14:47:11 2023
From: satish.txt at gmail.com (Satish Patel)
Date: Thu, 27 Apr 2023 10:47:11 -0400
Subject: [kolla-ansible] all-in-one deployment on single NIC
Message-ID: <CAPgF-frD5QxCjYGod8c2iB_prMgw8gPxV4Z7TbL7aL28MqOsMA@mail.gmail.com>

Folks,

I am trying to create a lab with a single server which has a single NIC
card and as you know kolla-ansible needs two nic for all-in-one (api and
neutron nic).

I want to test VLAN base provider for VMs so can I configure single nic on
trunk port and create two VLAN interfaces foo.10 and foo.20 bridge and
assign foo.10 to api and foo.20 for neutron. Does that make sense and will
help the test lab?

I was also reading somewhere that you need to create a veth interface two
split single nic for kolla.

Did anyone test kolla with single nic with two bridges to create dual nic
simulation?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230427/afd57e18/attachment.htm>

From pierre at stackhpc.com  Thu Apr 27 16:30:38 2023
From: pierre at stackhpc.com (Pierre Riteau)
Date: Thu, 27 Apr 2023 18:30:38 +0200
Subject: [kolla-ansible][watcher]Time zone issue in container
In-Reply-To: <CAJc0DSZZn7Dst0A66+Tt+HOVxhKEpbU3jbB=YNWqURKgY3pFpQ@mail.gmail.com>
References: <CAJc0DSZZn7Dst0A66+Tt+HOVxhKEpbU3jbB=YNWqURKgY3pFpQ@mail.gmail.com>
Message-ID: <CA+ny2swxpx3vY6fEDU10eTqj_8-cf-mDpMjD8c4BJ-5Pv8s06g@mail.gmail.com>

Hi Stefan,

Kolla Ansible is configured to bind mount both files when running Debian:

watcher_api_default_volumes:
  - "{{ node_config_directory }}/watcher-api/:{{ container_config_directory
}}/:ro"
  - "/etc/localtime:/etc/localtime:ro"
  - "{{ '/etc/timezone:/etc/timezone:ro' if ansible_facts.os_family ==
'Debian' else '' }}"
  - "{{ kolla_dev_repos_directory ~
'/watcher/watcher:/var/lib/kolla/venv/lib/python' ~ distro_python_version ~
'/site-packages/watcher' if watcher_dev_mode | bool else '' }}"
  - "kolla_logs:/var/log/kolla/"

Can you share the HostConfig/Binds part of `docker inspect watcher_api`.
For example this is the configuration for placement_api on a non-Debian
host:

        "HostConfig": {
            "Binds": [
                "/etc/kolla/placement-api/:/var/lib/kolla/config_files/:ro",
                "/etc/localtime:/etc/localtime:ro",
                "kolla_logs:/var/log/kolla/:rw"
            ],

On Thu, 27 Apr 2023 at 15:16, Stefan Bryzga <stefanbryzga at gmail.com> wrote:

> Hi all,
>
> Recently I created fresh deployment based on kolla-ansible yoga and debian
> 11. Everything works correctly except Watcher services. Containers are in
> constant restart loop.
> On Debian host OS time-related files are as follows:
>
> lrwxrwxrwx  1 root root      33 Mar 21 07:53 localtime ->
> /usr/share/zoneinfo/Europe/Warsaw
> -rw-r--r--  1 root root      14 Mar 21 07:53 timezone
> x at control01:/etc$ cat timezone
> Europe/Warsaw
>
> However every container have:
>
> lrwxrwxrwx 1 root root      27 Apr 11 02:00 localtime ->
> /usr/share/zoneinfo/Etc/UTC
> -rw-r--r-- 1 root root      14 Mar 21 07:53 timezone
> (nova-api)[root at control01 etc]# cat timezone
> Europe/Warsaw
>
> In watcher logs I found error:
> 2023-04-27 10:08:12.607 7 ERROR python-watcher
> tzlocal.utils.ZoneInfoNotFoundError: 'Multiple conflicting time zone
> configurations found:\n/etc/timezone: Europe/Warsaw\n/etc/localtime is a
> symlink to: UTC\nFix the configuration, or set the time zone in a TZ
> environment variable.\n'
> 2023-04-27 10:08:12.607 7 ERROR python-watcher
> Which I believe is caused by wrong symlink for /etc/localtime in
> containers.
>
> Did anyone experience similar issue and know how to resolve it.
>
> Best regards,
> Stefan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230427/706cc985/attachment.htm>

From stefanbryzga at gmail.com  Thu Apr 27 16:53:15 2023
From: stefanbryzga at gmail.com (Stefan Bryzga)
Date: Thu, 27 Apr 2023 18:53:15 +0200
Subject: [kolla-ansible][watcher]Time zone issue in container
In-Reply-To: <CA+ny2swxpx3vY6fEDU10eTqj_8-cf-mDpMjD8c4BJ-5Pv8s06g@mail.gmail.com>
References: <CAJc0DSZZn7Dst0A66+Tt+HOVxhKEpbU3jbB=YNWqURKgY3pFpQ@mail.gmail.com>
 <CA+ny2swxpx3vY6fEDU10eTqj_8-cf-mDpMjD8c4BJ-5Pv8s06g@mail.gmail.com>
Message-ID: <CAJc0DSbrv_ttiQqr16OoZvBhYR0wn0f0yZ2Oz9ho9_b21sbYUg@mail.gmail.com>

Thank you for looking into this,

Here is mentioned info:

docker inspect for watcher_api container (binds for localtime and timezone
are identical for all containers):

        "HostConfig": {
            "Binds": [
                "/etc/kolla/watcher-api/:/var/lib/kolla/config_files/:ro",
                "/etc/localtime:/etc/localtime:ro",
                "/etc/timezone:/etc/timezone:ro",
                "kolla_logs:/var/log/kolla/:rw"
            ],

If this could help:
Time zone on debian host was setup during OS installation
Base OS is synced to NTP server with systemd-timesyncd

Best regards,
Stefan

czw., 27 kwi 2023 o 18:31 Pierre Riteau <pierre at stackhpc.com> napisa?(a):

> Hi Stefan,
>
> Kolla Ansible is configured to bind mount both files when running Debian:
>
> watcher_api_default_volumes:
>   - "{{ node_config_directory }}/watcher-api/:{{
> container_config_directory }}/:ro"
>   - "/etc/localtime:/etc/localtime:ro"
>   - "{{ '/etc/timezone:/etc/timezone:ro' if ansible_facts.os_family ==
> 'Debian' else '' }}"
>   - "{{ kolla_dev_repos_directory ~
> '/watcher/watcher:/var/lib/kolla/venv/lib/python' ~ distro_python_version ~
> '/site-packages/watcher' if watcher_dev_mode | bool else '' }}"
>   - "kolla_logs:/var/log/kolla/"
>
> Can you share the HostConfig/Binds part of `docker inspect watcher_api`.
> For example this is the configuration for placement_api on a non-Debian
> host:
>
>         "HostConfig": {
>             "Binds": [
>
> "/etc/kolla/placement-api/:/var/lib/kolla/config_files/:ro",
>                 "/etc/localtime:/etc/localtime:ro",
>                 "kolla_logs:/var/log/kolla/:rw"
>             ],
>
> On Thu, 27 Apr 2023 at 15:16, Stefan Bryzga <stefanbryzga at gmail.com>
> wrote:
>
>> Hi all,
>>
>> Recently I created fresh deployment based on kolla-ansible yoga and
>> debian 11. Everything works correctly except Watcher services. Containers
>> are in constant restart loop.
>> On Debian host OS time-related files are as follows:
>>
>> lrwxrwxrwx  1 root root      33 Mar 21 07:53 localtime ->
>> /usr/share/zoneinfo/Europe/Warsaw
>> -rw-r--r--  1 root root      14 Mar 21 07:53 timezone
>> x at control01:/etc$ cat timezone
>> Europe/Warsaw
>>
>> However every container have:
>>
>> lrwxrwxrwx 1 root root      27 Apr 11 02:00 localtime ->
>> /usr/share/zoneinfo/Etc/UTC
>> -rw-r--r-- 1 root root      14 Mar 21 07:53 timezone
>> (nova-api)[root at control01 etc]# cat timezone
>> Europe/Warsaw
>>
>> In watcher logs I found error:
>> 2023-04-27 10:08:12.607 7 ERROR python-watcher
>> tzlocal.utils.ZoneInfoNotFoundError: 'Multiple conflicting time zone
>> configurations found:\n/etc/timezone: Europe/Warsaw\n/etc/localtime is a
>> symlink to: UTC\nFix the configuration, or set the time zone in a TZ
>> environment variable.\n'
>> 2023-04-27 10:08:12.607 7 ERROR python-watcher
>> Which I believe is caused by wrong symlink for /etc/localtime in
>> containers.
>>
>> Did anyone experience similar issue and know how to resolve it.
>>
>> Best regards,
>> Stefan
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230427/c6c28475/attachment-0001.htm>

From elod.illes at est.tech  Thu Apr 27 19:48:59 2023
From: elod.illes at est.tech (=?utf-8?B?RWzDtWQgSWxsw6lz?=)
Date: Thu, 27 Apr 2023 19:48:59 +0000
Subject: [release][cinder] please delete cinderlib stable/ussuri branch
In-Reply-To: <VI1P18901MB07515515D29455DAB32DEF9AFF6A9@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>
References: <0faa7bfc-f70c-5c04-3b24-0aa3d603da80@gmail.com>
 <VI1P18901MB07515515D29455DAB32DEF9AFF6A9@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>
Message-ID: <VI1P18901MB075105FA109A2E7D6DDDE3C3FF6A9@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>

Hi Brian,

cindelib's stable/ussuri is deleted now.
(the cause was indeed a post-release job that ran after a missing reno link fixing patch [1] and it re-created the stable/ussuri branch at the original branching point. I've proposed a fix [2] to avoid this in the future)

Thanks again for pinging us with this issue!

El?d

[1] https://review.opendev.org/c/openstack/releases/+/876962
[2] https://review.opendev.org/c/openstack/project-config/+/881731

________________________________
From: El?d Ill?s <elod.illes at est.tech>
Sent: Thursday, April 27, 2023 11:30 AM
To: Brian Rosmaita <rosmaita.fossdev at gmail.com>; openstack-discuss at lists.openstack.org <openstack-discuss at lists.openstack.org>
Subject: Re: [release][cinder] please delete cinderlib stable/ussuri branch

Thanks Brian for signaling this. Actually to me this seems to be a bit more complicated as the branch was deleted i think, but somehow it was recreated (probably with some openstack/releases automation) one week ago. The generated two patches [1][2] suggest that, at least... So it's weird, and I don't see yet what happened.
We need to figure out what happend to prevent it happening again in the future.

I'll run the script today and delete the re-created stable/ussuri branch.

Thanks,

El?d

[1] https://review.opendev.org/c/openstack/cinderlib/+/877783
[2] https://review.opendev.org/c/openstack/cinderlib/+/877784
________________________________
From: Brian Rosmaita <rosmaita.fossdev at gmail.com>
Sent: Wednesday, April 26, 2023 6:16 PM
To: openstack-discuss at lists.openstack.org <openstack-discuss at lists.openstack.org>
Subject: [release][cinder] please delete cinderlib stable/ussuri branch

Hello Release Team,

Some changes were bot-proposed recently to the cinderlib stable/ussuri
branch, which was weird because that branch was tagged EOL by change
I75092342fe684892f8a73eab9ad5da4515cb1da5.  The change merged on
2022-08-31, and the ussuri-eol tag exists in the code repository, but
apparently the branch was never deleted.  Could you please delete the
branch?

thanks!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230427/e056dc5c/attachment.htm>

From zaitcev at redhat.com  Thu Apr 27 21:49:45 2023
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Thu, 27 Apr 2023 16:49:45 -0500
Subject: OpenStack Swift quota
In-Reply-To: <SA1PR04MB854472CC6D76D00245BFF81FA9609@SA1PR04MB8544.namprd04.prod.outlook.com>
References: <SA1PR04MB854472CC6D76D00245BFF81FA9609@SA1PR04MB8544.namprd04.prod.outlook.com>
Message-ID: <20230425004055.69dad46c@lebethron.zaitcev.lan>

On Fri, 21 Apr 2023 04:52:39 +0000
"Xu, Wei [E CPE]" <weixu at iastate.edu> wrote:

> Also, it seems like default OpenStack Swift only supports account-level and container-level quota implementation. Is it possible to implement not only user-level but also project-level and domain-level quotas?

I'm pretty sure what Swift considers user-level quotes are actually
project-level ones in OpenStack terms. Remember that "tenant_id" is
used to identify accounts (and form their URL bases). This "tenant"
is the old name for "projects".

-- P



From rosmaita.fossdev at gmail.com  Fri Apr 28 01:19:54 2023
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Thu, 27 Apr 2023 21:19:54 -0400
Subject: [release][cinder] please delete cinderlib stable/ussuri branch
In-Reply-To: <VI1P18901MB075105FA109A2E7D6DDDE3C3FF6A9@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>
References: <0faa7bfc-f70c-5c04-3b24-0aa3d603da80@gmail.com>
 <VI1P18901MB07515515D29455DAB32DEF9AFF6A9@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>
 <VI1P18901MB075105FA109A2E7D6DDDE3C3FF6A9@VI1P18901MB0751.EURP189.PROD.OUTLOOK.COM>
Message-ID: <9d1e14f8-0452-a039-1c35-5c55b81f02f5@gmail.com>

On 4/27/23 3:48 PM, El?d Ill?s wrote:
> Hi Brian,
> 
> cindelib's stable/ussuri is deleted now.
> (the cause was indeed a post-release job that ran after a missing reno 
> link fixing patch [1] and it re-created the stable/ussuri branch at the 
> original branching point. I've proposed a fix [2] to avoid this in the 
> future)
> 
> Thanks again for pinging us with this issue!

Thanks for resolving this so quickly!

> 
> El?d
> 
> [1] https://review.opendev.org/c/openstack/releases/+/876962 
> <https://review.opendev.org/c/openstack/releases/+/876962>
> [2] https://review.opendev.org/c/openstack/project-config/+/881731 
> <https://review.opendev.org/c/openstack/project-config/+/881731>
> 
> ------------------------------------------------------------------------
> *From:* El?d Ill?s <elod.illes at est.tech>
> *Sent:* Thursday, April 27, 2023 11:30 AM
> *To:* Brian Rosmaita <rosmaita.fossdev at gmail.com>; 
> openstack-discuss at lists.openstack.org 
> <openstack-discuss at lists.openstack.org>
> *Subject:* Re: [release][cinder] please delete cinderlib stable/ussuri 
> branch
> Thanks Brian for signaling this. Actually to me this seems to be a bit 
> more complicated as the branch was deleted i think, but somehow it was 
> recreated (probably with some openstack/releases automation) one week 
> ago. The generated two patches [1][2] suggest that, at least... So it's 
> weird, and I don't see yet what happened.
> We need to figure out what happend to prevent it happening again in the 
> future.
> 
> I'll run the script today and delete the re-created stable/ussuri branch.
> 
> Thanks,
> 
> El?d
> 
> [1] https://review.opendev.org/c/openstack/cinderlib/+/877783 
> <https://review.opendev.org/c/openstack/cinderlib/+/877783>
> [2] https://review.opendev.org/c/openstack/cinderlib/+/877784 
> <https://review.opendev.org/c/openstack/cinderlib/+/877784>
> ------------------------------------------------------------------------
> *From:* Brian Rosmaita <rosmaita.fossdev at gmail.com>
> *Sent:* Wednesday, April 26, 2023 6:16 PM
> *To:* openstack-discuss at lists.openstack.org 
> <openstack-discuss at lists.openstack.org>
> *Subject:* [release][cinder] please delete cinderlib stable/ussuri branch
> Hello Release Team,
> 
> Some changes were bot-proposed recently to the cinderlib stable/ussuri
> branch, which was weird because that branch was tagged EOL by change
> I75092342fe684892f8a73eab9ad5da4515cb1da5.? The change merged on
> 2022-08-31, and the ussuri-eol tag exists in the code repository, but
> apparently the branch was never deleted.? Could you please delete the
> branch?
> 
> thanks!
> 



From ralonsoh at redhat.com  Fri Apr 28 08:14:18 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Fri, 28 Apr 2023 10:14:18 +0200
Subject: [neutron] Neutron drivers meeting cancelled
Message-ID: <CAECr9X7NXjFfYHzQF0PSWJQXaNAE9hk+hTrTOAJ=y6ULJYjp9A@mail.gmail.com>

Hello Neutrinos:

Due to the lack of agenda, today's drivers meeting is cancelled.

Have a nice weekend!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230428/887bf2fd/attachment.htm>

From jake.yip at ardc.edu.au  Fri Apr 28 08:24:16 2023
From: jake.yip at ardc.edu.au (Jake Yip)
Date: Fri, 28 Apr 2023 18:24:16 +1000
Subject: [magnum] Propose deprecation of Docker Swarm, CoreOS,
 fedora-ironic
In-Reply-To: <6cde45a5-a4f5-823b-2edc-bc7fe7fdab8c@ardc.edu.au>
References: <6cde45a5-a4f5-823b-2edc-bc7fe7fdab8c@ardc.edu.au>
Message-ID: <119b0efc-faeb-365f-4f4f-2fa87eff0e24@ardc.edu.au>

On 22/2/2023 9:41 pm, Jake Yip wrote:
> Hi,
> 
> Due to limited resources, Magnum team has decided to put most effort 
> into supporting the most popular use case - Kubernetes on Fedora CoreOS.
> 
> In light of that, we are seeking maintainers for the less well 
> maintained drivers / COE - Docker Swarm, CoreOS and fedora-ironic 
> drivers. The reasons are as follows:
> 

Hi all,

We have not received any volunteers for these drivers.

This is a final attempt on the list; if there is no response in a week, 
we will continue with our deprecation and subsequent removal of these 
drivers.

Regards,
Jake


From mnasiadka at gmail.com  Fri Apr 28 09:53:10 2023
From: mnasiadka at gmail.com (=?utf-8?Q?Micha=C5=82_Nasiadka?=)
Date: Fri, 28 Apr 2023 11:53:10 +0200
Subject: [kolla] Cancelling weekly meeting 3rd May
Message-ID: <891B8873-E81F-4F52-8B54-AC2EBE21EBE3@gmail.com>

Hello Koalas,

Since 3rd of May is public holiday in Poland and other cores are on vacation - cancelling weekly meeting.

Let?s meet again on 10th May.

Best regards,

Michal

From rafaelweingartner at gmail.com  Fri Apr 28 11:56:34 2023
From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=)
Date: Fri, 28 Apr 2023 08:56:34 -0300
Subject: [CloudKitty] Cancelling weekly meeting 1st May
Message-ID: <CAG97raeShTshuMs13Ntsi9a8+LiZr5jWy_Xt3te+NwiK__o_iA@mail.gmail.com>

Hello guys,

May 1st is a public holiday for most of the core reviewers. Therefore, we
will be canceling that meeting.
If you need any assistance until the next meeting, you can reach me via
e-mail.

Best regards,

-- 
Rafael Weing?rtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230428/3d21b97f/attachment.htm>

From james.slagle at gmail.com  Fri Apr 28 12:42:58 2023
From: james.slagle at gmail.com (James Slagle)
Date: Fri, 28 Apr 2023 08:42:58 -0400
Subject: [tripleo] Nominate dbengt for tripleo-core !
In-Reply-To: <CAHV77z9D59GTy8_Or=iJc-2wit53W-3d3PGEA4zPPpMuhSKYWA@mail.gmail.com>
References: <CAEggtay7MKKCUuDzvhhUitv=EgBRZMPjcdQ7cEDpjp0y04+SEg@mail.gmail.com>
 <CAHV77z9D59GTy8_Or=iJc-2wit53W-3d3PGEA4zPPpMuhSKYWA@mail.gmail.com>
Message-ID: <CAHV77z81HT==uiLC674x6H2WMKeauLJzwuqUvG-hvpOc82vQyQ@mail.gmail.com>

Thank you to everyone who participated in voting, and to Daniel for
your contributions! I've added Daniel to tripleo-core.

On Wed, Apr 5, 2023 at 8:16?AM James Slagle <james.slagle at gmail.com> wrote:
>
> On Mon, Apr 3, 2023 at 1:17?PM Lukas Bezdicka <lbezdick at redhat.com> wrote:
> > I'd like to nominate Daniel Bengtsson as tripleo-core. He works in upgrades and he'll have to maintain train, wallaby and zed for quite a while. He is a long term contributor to tripleo and oslo.
>
> +1 from me. However, I'd like to clarify that Daniel does not intend
> to maintain Zed. It was shared on the thread about the future of
> TripleO[1], that the project team does not intend to maintain Zed.
> There were no volunteers who indicated they were willing to do so on
> that thread. I don't believe it to be the case that this tripleo-core
> nomination is proposing that Daniel maintain Zed. If that is accurate,
> then +1, otherwise I think we need some more clarification about the
> intent.
>
> [1] https://lists.openstack.org/pipermail/openstack-discuss/2023-March/thread.html
>
>
>
>
> --
> -- James Slagle
> --



-- 
-- James Slagle
--


From ralonsoh at redhat.com  Fri Apr 28 12:45:59 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Fri, 28 Apr 2023 14:45:59 +0200
Subject: [neutron] Neutron CI not working
Message-ID: <CAECr9X5PPEEWai7__90wAJ5xAVqFEO+qVUfmtF+riNKCFjHBRw@mail.gmail.com>

Hello Neutrinos:

There are some problems in a set of nodes that we are using for tempest
tests. This is also affecting other projects like Octavia. Please follow
[1] for more information. Yatin has collected information of the error and
the affected nodes.

Actions:
* Temporarily disable these nodes from the pool [2]. That will allow us
(Neutron) to continue the CI testing.
* Send a support ticket to the node provider. Once we have more
information, we'll provide it.

Before [2] is merged, please hold your rechecks for the tempest jobs in
Neutron.

Regards.

[1]https://bugs.launchpad.net/neutron/+bug/2017992
[2]https://review.opendev.org/c/openstack/project-config/+/881810
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230428/f472be9f/attachment.htm>

From auniyal at redhat.com  Fri Apr 28 08:10:10 2023
From: auniyal at redhat.com (Amit Uniyal)
Date: Fri, 28 Apr 2023 13:40:10 +0530
Subject: openstack-discuss Digest, Vol 54, Issue 88
In-Reply-To: <CAE1GhS6dRz0-kAd8yzpDi1cDfn7rszuZOXV8z-Yar_poHQZRhQ@mail.gmail.com>
References: <mailman.12577.1681745265.934892.openstack-discuss@lists.openstack.org>
 <CAE1GhS6dRz0-kAd8yzpDi1cDfn7rszuZOXV8z-Yar_poHQZRhQ@mail.gmail.com>
Message-ID: <CAMZr3i717yey48VCPk7Rx=c5eeRPjfCLm7mxqJEer2ZUizKu=w@mail.gmail.com>

Hello,
I understand you want to deploy an OpenStack setup in standalone VMware
workstation software, the VM(s) you would like to use is either Ubuntu or
CentOS.

And if I understood correctly. These are a few tools which mostly work.

Automated:

Devstack: testing and development environment.

SingleNode: https://docs.openstack.org/devstack/latest/
MultiNode:
https://docs.openstack.org/devstack/latest/guides/multinode-lab.html

Kolla ansible:
https://docs.openstack.org/project-deploy-guide/kolla-ansible/latest/

Others.

TripleO:
https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/

ubuntu charms: https://docs.openstack.org/charm-guide/latest/

https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/

Fuel: Mirantis used to have Fuel, but I am not sure if it's ACTIVE now.


Manual: https://docs.openstack.org/install-guide/overview.html


Other good OpenStack Platforms:
- RHOSP from RedHat
- HOS from HPE


Regards

On Wed, Apr 26, 2023 at 7:34?PM BEDDA Fadhel <fadhel.bedda at gmail.com> wrote:

> Good morning,
> I am still looking for a complete and clear procedure to set up an openstack solution on a vmware worksation virtual machine: ubuntu or centos.
> THANKS
>
>
> Le lun. 17 avr. 2023 ? 17:30, <
> openstack-discuss-request at lists.openstack.org> a ?crit :
>
>> Send openstack-discuss mailing list submissions to
>>         openstack-discuss at lists.openstack.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>
>> https://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss
>>
>> or, via email, send a message with subject or body 'help' to
>>         openstack-discuss-request at lists.openstack.org
>>
>> You can reach the person managing the list at
>>         openstack-discuss-owner at lists.openstack.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of openstack-discuss digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: [Kolla-ansible][Yoga] Cannot live migrate VMs (wodel youchi)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 11 Apr 2023 12:57:47 +0100
>> From: wodel youchi <wodel.youchi at gmail.com>
>> To: Pierre Riteau <pierre at stackhpc.com>
>> Cc: OpenStack Discuss <openstack-discuss at lists.openstack.org>
>> Subject: Re: [Kolla-ansible][Yoga] Cannot live migrate VMs
>> Message-ID:
>>         <CAJV_UBDH4tJ11pkOagYpWNVCrZHruTmA6A-k9P=
>> DLrqchPvNPg at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi,
>>
>> Indeed, there was a mistake in the cinder.conf file.
>> Thanks.
>>
>> Regards.
>>
>> <
>> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
>> >
>> Virus-free.www.avast.com
>> <
>> https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail
>> >
>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>
>> Le mar. 11 avr. 2023 ? 10:45, Pierre Riteau <pierre at stackhpc.com> a
>> ?crit :
>>
>> > You should check the status of your Cinder services.
>> >
>> > On Sun, 9 Apr 2023 at 19:43, wodel youchi <wodel.youchi at gmail.com>
>> wrote:
>> >
>> >> Hi,
>> >>
>> >> I cannot live-migrate any VM I have.
>> >> All my compute nodes are enabled. I have a few VMs, I am in the testing
>> >> phase.
>> >> I tried to live-migrate toward an empty node, then toward a node which
>> >> already had a VM in it. It is the same problem.
>> >>
>> >> In the log files I have :
>> >>
>> >> Source node :
>> >> Source
>> >>
>> >>> ==> /var/log/kolla/nova/nova-compute.log <==
>> >>> 2023-04-09 11:32:49.419 7 INFO nova.compute.resource_tracker
>> >>> [req-4e91d562-d7ad-4585-a827-3db6277fd81e - - - - -] [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Updating resource usage from
>> >>> migration f60eb077-8e1c-404a-aca5-64e5609ca02c
>> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [-] [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Pre live migration failed at
>> >>> computehci02: oslo_messaging.rpc.client.RemoteError: Remote error:
>> >>> ClientException Gateway Time-out (HTTP 504)
>> >>> ['Traceback (most recent call last):\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py",
>> >>> line 165, in _process_incoming\n    res =
>> >>> self.dispatcher.dispatch(message)\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>> >>> line 309, in dispatch\n    return self._do_dispatch(endpoint, method,
>> ctxt,
>> >>> args)\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>> >>> line 229, in _do_dispatch\n    result = func(ctxt, **new_args)\n', '
>> File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>> >>> line 72, in wrapped\n    context, exc, binary)\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 200, in force_reraise\n    raise self.value\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>> >>> line 63, in wrapped\n    return f(self, context, *args, **kw)\n', '
>> File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py",
>> >>> line 1439, in decorated_function\n    return function(self, context,
>> *args,
>> >>> **kwargs)\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> >>> line 213, in decorated_function\n    kwargs[\'instance\'], e,
>> >>> sys.exc_info())\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 200, in force_reraise\n    raise self.value\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> >>> line 201, in decorated_function\n    return function(self, context,
>> *args,
>> >>> **kwargs)\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> >>> line 8367, in pre_live_migration\n    bdm.save()\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 200, in force_reraise\n    raise self.value\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> >>> line 8304, in pre_live_migration\n    connector=connector,
>> >>> mountpoint=bdm.device_name)\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> >>> line 395, in wrapper\n    res = method(self, ctx, *args,
>> **kwargs)\n', '
>> >>>  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> >>> line 433, in wrapper\n    res = method(self, ctx, volume_id, *args,
>> >>> **kwargs)\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> >>> line 813, in attachment_create\n    instance_uuid=instance_id)\n', '
>> File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 200, in force_reraise\n    raise self.value\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> >>> line 801, in attachment_create\n    volume_id, _connector,
>> instance_id)\n',
>> >>> '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py",
>> >>> line 421, in substitution\n    return method.func(obj, *args,
>> **kwargs)\n',
>> >>> '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py",
>> >>> line 39, in create\n    retval = self._create(\'/attachments\', body,
>> >>> \'attachment\')\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py",
>> >>> line 306, in _create\n    resp, body = self.api.client.post(url,
>> >>> body=body)\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> >>> line 227, in post\n    return self._cs_request(url, \'POST\',
>> **kwargs)\n',
>> >>> '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> >>> line 215, in _cs_request\n    return self.request(url, method,
>> >>> **kwargs)\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> >>> line 201, in request\n    raise exceptions.from_response(resp,
>> body)\n',
>> >>> 'cinderclient.exceptions.ClientException: Gateway Time-out (HTTP
>> 504)\n'].
>> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Traceback (most recent call
>> last):
>> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> >>> line 8501, in _do_pre_live_migration_from_source
>> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     block_migration, disk, dest,
>> >>> migrate_data)
>> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/rpcapi.py",
>> >>> line 948, in pre_live_migration
>> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     **msg_args)
>> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/client.py",
>> >>> line 192, in call
>> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     retry=self.retry,
>> >>> transport_options=self.transport_options)
>> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/transport.py",
>> >>> line 128, in _send
>> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
>> >>> transport_options=transport_options)
>> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>> >>> line 691, in send
>> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
>> >>> transport_options=transport_options)
>> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/_drivers/amqpdriver.py",
>> >>> line 681, in _send
>> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]     raise result
>> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
>> >>> oslo_messaging.rpc.client.RemoteError: Remote error: ClientException
>> >>> Gateway Time-out (HTTP 504)
>> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] ['Traceback (most recent call
>> >>> last):\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py",
>> >>> line 165, in _process_incoming\n    res =
>> >>> self.dispatcher.dispatch(message)\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>> >>> line 309, in dispatch\n    return self._do_dispatch(endpoint, method,
>> ctxt,
>> >>> args)\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>> >>> line 229, in _do_dispatch\n    result = func(ctxt, **new_args)\n', '
>> File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>> >>> line 72, in wrapped\n    context, exc, binary)\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 200, in force_reraise\n    raise self.value\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>> >>> line 63, in wrapped\n    return f(self, context, *args, **kw)\n', '
>> File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py",
>> >>> line 1439, in decorated_function\n    return function(self, context,
>> *args,
>> >>> **kwargs)\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> >>> line 213, in decorated_function\n    kwargs[\'instance\'], e,
>> >>> sys.exc_info())\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 200, in force_reraise\n    raise self.value\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> >>> line 201, in decorated_function\n    return function(self, context,
>> *args,
>> >>> **kwargs)\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> >>> line 8367, in pre_live_migration\n    bdm.save()\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 200, in force_reraise\n    raise self.value\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> >>> line 8304, in pre_live_migration\n    connector=connector,
>> >>> mountpoint=bdm.device_name)\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> >>> line 395, in wrapper\n    res = method(self, ctx, *args,
>> **kwargs)\n', '
>> >>>  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> >>> line 433, in wrapper\n    res = method(self, ctx, volume_id, *args,
>> >>> **kwargs)\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> >>> line 813, in attachment_create\n    instance_uuid=instance_id)\n', '
>> File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 227, in __exit__\n    self.force_reraise()\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 200, in force_reraise\n    raise self.value\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> >>> line 801, in attachment_create\n    volume_id, _connector,
>> instance_id)\n',
>> >>> '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py",
>> >>> line 421, in substitution\n    return method.func(obj, *args,
>> **kwargs)\n',
>> >>> '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py",
>> >>> line 39, in create\n    retval = self._create(\'/attachments\', body,
>> >>> \'attachment\')\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py",
>> >>> line 306, in _create\n    resp, body = self.api.client.post(url,
>> >>> body=body)\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> >>> line 227, in post\n    return self._cs_request(url, \'POST\',
>> **kwargs)\n',
>> >>> '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> >>> line 215, in _cs_request\n    return self.request(url, method,
>> >>> **kwargs)\n', '  File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> >>> line 201, in request\n    raise exceptions.from_response(resp,
>> body)\n',
>> >>> 'cinderclient.exceptions.ClientException: Gateway Time-out (HTTP
>> 504)\n'].
>> >>> 2023-04-09 11:33:30.118 7 ERROR nova.compute.manager [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7]
>> >>> 2023-04-09 11:33:30.157 7 INFO nova.compute.manager [-] [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Swapping old allocation on
>> >>> dict_keys(['2857ae62-3519-4b13-b700-858c827dd78d']) held by migration
>> >>> f60eb077-8e1c-404a-aca5-64e5609ca02c for instance
>> >>
>> >>
>> >>
>> >> In the destination node :
>> >>
>> >>> nova-compute.log
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> *2023-04-09 11:32:30.052 7 WARNING
>> os_brick.initiator.connectors.nvmeof
>> >>> [req-69822759-d982-4d01-b448-232796077002
>> 0439953e7cfe4a13a1b4bb118b5dc3c4
>> >>> b0f76b5c6dcb457fa716762bbf954837 - default default] Process execution
>> error
>> >>> in _get_host_uuid: Unexpected error while running command.Command:
>> blkid
>> >>> overlay -s UUID -o valueExit code: 2Stdout: ''Stderr: '':
>> >>> oslo_concurrency.processutils.ProcessExecutionError: Unexpected error
>> while
>> >>> running command.*
>> >>>
>> >>> 2023-04-09 11:33:05.354 7 INFO nova.compute.resource_tracker
>> >>> [req-9d480442-87f7-4d4e-a866-c46d645ac7f2 - - - - -] [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Updating resource usage from
>> >>> migration f60eb077-8e1c-404a-aca5-64e5609ca02c
>> >>> 2023-04-09 11:33:05.392 7 WARNING nova.compute.resource_tracker
>> >>> [req-9d480442-87f7-4d4e-a866-c46d645ac7f2 - - - - -] Instance
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7 has been moved to another host
>> >>> computehci01(computehci01). There are allocations remaining against
>> the
>> >>> source host that might need to be removed: {'resources': {'VCPU': 1,
>> >>> 'MEMORY_MB': 2048}}.
>> >>> 2023-04-09 11:33:30.086 7 ERROR nova.volume.cinder
>> >>> [req-69822759-d982-4d01-b448-232796077002
>> 0439953e7cfe4a13a1b4bb118b5dc3c4
>> >>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Create attachment failed for
>> volume
>> >>> 3d7bd0af-5e4c-48fc-a027-f6c9dd6280bb. Error: Gateway Time-out (HTTP
>> 504)
>> >>> Code: 504: cinderclient.exceptions.ClientException: Gateway Time-out
>> (HTTP
>> >>> 504)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> >>> [req-69822759-d982-4d01-b448-232796077002
>> 0439953e7cfe4a13a1b4bb118b5dc3c4
>> >>> b0f76b5c6dcb457fa716762bbf954837 - default default] Exception during
>> >>> message handling: cinderclient.exceptions.ClientException: Gateway
>> Time-out
>> >>> (HTTP 504)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server Traceback
>> >>> (most recent call last):
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/server.py",
>> >>> line 165, in _process_incoming
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     res =
>> >>> self.dispatcher.dispatch(message)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>> >>> line 309, in dispatch
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> >>> self._do_dispatch(endpoint, method, ctxt, args)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_messaging/rpc/dispatcher.py",
>> >>> line 229, in _do_dispatch
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     result =
>> >>> func(ctxt, **new_args)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>> >>> line 72, in wrapped
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     context,
>> >>> exc, binary)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 227, in __exit__
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> >>> self.force_reraise()
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 200, in force_reraise
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>> >>> self.value
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/exception_wrapper.py",
>> >>> line 63, in wrapped
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> >>> f(self, context, *args, **kw)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/utils.py",
>> >>> line 1439, in decorated_function
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> >>> function(self, context, *args, **kwargs)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> >>> line 213, in decorated_function
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> >>> kwargs['instance'], e, sys.exc_info())
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 227, in __exit__
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> >>> self.force_reraise()
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 200, in force_reraise
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>> >>> self.value
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> >>> line 201, in decorated_function
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> >>> function(self, context, *args, **kwargs)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> >>> line 8367, in pre_live_migration
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>>  bdm.save()
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 227, in __exit__
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> >>> self.force_reraise()
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 200, in force_reraise
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>> >>> self.value
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py",
>> >>> line 8304, in pre_live_migration
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> >>> connector=connector, mountpoint=bdm.device_name)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> >>> line 395, in wrapper
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     res =
>> >>> method(self, ctx, *args, **kwargs)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> >>> line 433, in wrapper
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     res =
>> >>> method(self, ctx, volume_id, *args, **kwargs)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> >>> line 813, in attachment_create
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> >>> instance_uuid=instance_id)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 227, in __exit__
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> >>> self.force_reraise()
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/oslo_utils/excutils.py",
>> >>> line 200, in force_reraise
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>> >>> self.value
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/nova/volume/cinder.py",
>> >>> line 801, in attachment_create
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>>  volume_id,
>> >>> _connector, instance_id)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/api_versions.py",
>> >>> line 421, in substitution
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> >>> method.func(obj, *args, **kwargs)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/v3/attachments.py",
>> >>> line 39, in create
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     retval =
>> >>> self._create('/attachments', body, 'attachment')
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/base.py",
>> >>> line 306, in _create
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     resp,
>> body
>> >>> = self.api.client.post(url, body=body)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> >>> line 227, in post
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> >>> self._cs_request(url, 'POST', **kwargs)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> >>> line 215, in _cs_request
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     return
>> >>> self.request(url, method, **kwargs)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server   File
>> >>>
>> "/var/lib/kolla/venv/lib/python3.6/site-packages/cinderclient/client.py",
>> >>> line 201, in request
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server     raise
>> >>> exceptions.from_response(resp, body)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> >>> cinderclient.exceptions.ClientException: Gateway Time-out (HTTP 504)
>> >>> 2023-04-09 11:33:30.115 7 ERROR oslo_messaging.rpc.server
>> >>> 2023-04-09 11:33:30.238 7 INFO nova.virt.block_device
>> >>> [req-69822759-d982-4d01-b448-232796077002
>> 0439953e7cfe4a13a1b4bb118b5dc3c4
>> >>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Attempting to driver detach
>> volume
>> >>> 3d7bd0af-5e4c-48fc-a027-f6c9dd6280bb from mountpoint /dev/vda
>> >>> 2023-04-09 11:33:30.239 7 WARNING nova.virt.block_device
>> >>> [req-69822759-d982-4d01-b448-232796077002
>> 0439953e7cfe4a13a1b4bb118b5dc3c4
>> >>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Detaching volume from unknown
>> instance
>> >>> 2023-04-09 11:33:30.240 7 WARNING nova.virt.libvirt.driver
>> >>> [req-69822759-d982-4d01-b448-232796077002
>> 0439953e7cfe4a13a1b4bb118b5dc3c4
>> >>> b0f76b5c6dcb457fa716762bbf954837 - default default] [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] During detach_volume, instance
>> >>> disappeared.: nova.exception.InstanceNotFound: Instance
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7 could not be found.
>> >>> 2023-04-09 11:33:30.678 7 INFO nova.virt.libvirt.driver [-] [instance:
>> >>> f4c3ee82-d5cf-4b79-8608-76be7faeb2c7] Instance destroyed successfully.
>> >>> 2023-04-09 11:33:30.682 7 INFO os_vif
>> >>> [req-69822759-d982-4d01-b448-232796077002
>> 0439953e7cfe4a13a1b4bb118b5dc3c4
>> >>> b0f76b5c6dcb457fa716762bbf954837 - default default] Successfully
>> unplugged
>> >>> vif
>> >>>
>> VIFBridge(active=True,address=fa:16:3e:9b:92:46,bridge_name='qbr46651303-65',has_traffic_filtering=True,id=46651303-65e1-4809-95cc-7c2d97acf16b,network=Network(532470c1-dd2f-4505-8557-ba24e9d4062b),plugin='ovs',port_profile=VIFPortProfileOpenVSwitch,preserve_on_delete=False,vif_name='tap46651303-65')
>> >>>
>> >>
>> >> All I can see is
>> >>
>> >>
>> >>
>> >>
>> >> *b0f76b5c6dcb457fa716762bbf954837 - default default] Process execution
>> >> error in _get_host_uuid: Unexpected error while running
>> command.Command:
>> >> blkid overlay -s UUID -o valueExit code: 2Stdout: ''Stderr: '':
>> >> oslo_concurrency.processutils.ProcessExecutionError: Unexpected error
>> while
>> >> running command.*
>> >>
>> >> Searching the web I didn't find anything useful about this error, and I
>> >> don't know if it's the origin of the problem.
>> >>
>> >> My default storage is ceph rbd, I have an HCI deployment, and all my
>> VMs
>> >> are for now created on Ceph only. But I have configured two other
>> cinder
>> >> backends, NFS and LVM, but they are node used for now.
>> >>
>> >> Thanks in advance.
>> >>
>> >> Regards.
>> >>
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230411/e775a16b/attachment.htm
>> >
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> openstack-discuss mailing list
>> openstack-discuss at lists.openstack.org
>>
>>
>> ------------------------------
>>
>> End of openstack-discuss Digest, Vol 54, Issue 88
>> *************************************************
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230428/e942c415/attachment-0001.htm>

From vineetthakur09 at gmail.com  Fri Apr 28 09:45:40 2023
From: vineetthakur09 at gmail.com (Vineet Thakur)
Date: Fri, 28 Apr 2023 15:15:40 +0530
Subject: Offline Openstack Release:Train Deployment
Message-ID: <CAH7bWr27JijByLowzEn5Wi-_jbwGaOdvMixY94By1bfbeDnfNw@mail.gmail.com>

Greetings openstack community members,

It's regarding the deployment of openstack release: train on CentoOS 7.9
environment by using openstack-ansible tool. (Offline environment)

We are facing challenges to download the packages, some package links are
not accessible or somewhere PIP packages are not available as per the
constraint requirement list.
See:
https://artifacts.ci.centos.org/sig-cloudinstance/centos-7-191001/x86-64/centos-7-x86_64-docker.tar.xz

For pip packages:
https://opendev.org/openstack/requirements/raw/0cfc2ef6318b639bb4287fa051eae8f3ac8cc426/upper-constraints.txt

During installation we are facing a lot of errors, and not sure what would
be the best approach in such scenarios where packages are not available or
need to be downloaded from random sites. We are in the mid of a mega
deployment and appreciate it if you can guide us through.

Awaiting your response, thank you.

Kind Regards,
Vineet Thakur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230428/f2301d70/attachment.htm>

From noonedeadpunk at gmail.com  Fri Apr 28 15:03:58 2023
From: noonedeadpunk at gmail.com (Dmitriy Rabotyagov)
Date: Fri, 28 Apr 2023 17:03:58 +0200
Subject: Offline Openstack Release:Train Deployment
In-Reply-To: <CAH7bWr27JijByLowzEn5Wi-_jbwGaOdvMixY94By1bfbeDnfNw@mail.gmail.com>
References: <CAH7bWr27JijByLowzEn5Wi-_jbwGaOdvMixY94By1bfbeDnfNw@mail.gmail.com>
Message-ID: <CAPd_6AtuSCoVdLAkEJ9Y4kT+yeriz=AXhU4ohg8DLH55cjPrZw@mail.gmail.com>

Hi there,

Basically, for offline deployment, you still need to have local
mirrors that you sync from time to time. Have you checked this doc:
https://docs.openstack.org/openstack-ansible/latest/user/limited-connectivity/index.html
?
Despite it mostly covering Ubuntu deployment, there's a listing of
things that you should mirror locally that are being used throughout
deployment. Also I'm quite sure that openstack-ansible does not use
docker anywhere, so referring docker package is somehow weird to me.

Though we did a successful deployment on Ubuntu quite recently, so
list of repositories that need to be mirrored are relevant. However,
there might be some more challenges on Train, as this release is quite
old and barely maintained at the moment. A lot of OpenStack projects
have already EOLed Train, just in case.

??, 28 ???. 2023??. ? 16:31, Vineet Thakur <vineetthakur09 at gmail.com>:
>
>
> Greetings openstack community members,
>
> It's regarding the deployment of openstack release: train on CentoOS 7.9 environment by using openstack-ansible tool. (Offline environment)
>
> We are facing challenges to download the packages, some package links are not accessible or somewhere PIP packages are not available as per the constraint requirement list.
> See:
> https://artifacts.ci.centos.org/sig-cloudinstance/centos-7-191001/x86-64/centos-7-x86_64-docker.tar.xz
>
> For pip packages:
> https://opendev.org/openstack/requirements/raw/0cfc2ef6318b639bb4287fa051eae8f3ac8cc426/upper-constraints.txt
>
> During installation we are facing a lot of errors, and not sure what would be the best approach in such scenarios where packages are not available or need to be downloaded from random sites. We are in the mid of a mega deployment and appreciate it if you can guide us through.
>
> Awaiting your response, thank you.
>
> Kind Regards,
> Vineet Thakur
>


From skaplons at redhat.com  Fri Apr 28 15:06:07 2023
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Fri, 28 Apr 2023 17:06:07 +0200
Subject: [neutron] CI meeting on May 2nd cancelled
Message-ID: <5114418.Xo2BTYgDZC@p1>

Hi,

I will be on PTO next Tuesday so lets cancel CI meeting this time. See You on the meeting on May 9th.

-- 
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: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230428/9d4963fd/attachment.sig>

From ralonsoh at redhat.com  Fri Apr 28 16:20:57 2023
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Fri, 28 Apr 2023 18:20:57 +0200
Subject: [neutron] Neutron CI not working
In-Reply-To: <CAECr9X5PPEEWai7__90wAJ5xAVqFEO+qVUfmtF+riNKCFjHBRw@mail.gmail.com>
References: <CAECr9X5PPEEWai7__90wAJ5xAVqFEO+qVUfmtF+riNKCFjHBRw@mail.gmail.com>
Message-ID: <CAECr9X4wycmOc37gTG+WhzsmHC+G0mdJZJxWz=iPYiOiTrVQrA@mail.gmail.com>

Hello Neutrinos:

The patch [1] is now merged and the Neutron CI seems to be working fine.
You can now recheck, if needed, your patches. We'll provide more
information about the status of the node provider.

Regards.

[1]https://bugs.launchpad.net/neutron/+bug/2017992


On Fri, Apr 28, 2023 at 2:45?PM Rodolfo Alonso Hernandez <
ralonsoh at redhat.com> wrote:

> Hello Neutrinos:
>
> There are some problems in a set of nodes that we are using for tempest
> tests. This is also affecting other projects like Octavia. Please follow
> [1] for more information. Yatin has collected information of the error and
> the affected nodes.
>
> Actions:
> * Temporarily disable these nodes from the pool [2]. That will allow us
> (Neutron) to continue the CI testing.
> * Send a support ticket to the node provider. Once we have more
> information, we'll provide it.
>
> Before [2] is merged, please hold your rechecks for the tempest jobs in
> Neutron.
>
> Regards.
>
> [1]https://bugs.launchpad.net/neutron/+bug/2017992
> [2]https://review.opendev.org/c/openstack/project-config/+/881810
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230428/6dcb9fac/attachment.htm>

From yasufum.o at gmail.com  Sat Apr 29 17:33:21 2023
From: yasufum.o at gmail.com (Yasufumi Ogawa)
Date: Sun, 30 Apr 2023 02:33:21 +0900
Subject: [heat][magnum][tacker] Future of SoftwareDeployment support
In-Reply-To: <eb0d30ca-0fc6-e974-9417-68500f5c03bd@ardc.edu.au>
References: <CAL_crJTB_D+Y+LVRs2qNindh8e1Pk=aK2EEx7SP09eSFZDRB5g@mail.gmail.com>
 <6396cae4-9afd-b823-525f-90690d8c29d7@ardc.edu.au>
 <f72fa847-a6d1-c0a2-29d5-3cbb1df738ac@ultimum.io>
 <eb0d30ca-0fc6-e974-9417-68500f5c03bd@ardc.edu.au>
Message-ID: <fe311c2e-3dac-72fa-d037-31b22640220e@gmail.com>

Hi,

For tacker, we've agreed to drop SoftwareDeployment in tacker and 
heat-translator as the result of discussion in our team last week. Sorry 
for the late notice.

Thanks,
Yasufumi

On 2023/04/26 19:07, Jake Yip wrote:
> Hi,
> 
> Yes, there are a couple of WIP reviews in magnum by John.
> 
> Regards,
> Jake
> 
> On 18/4/2023 11:16 pm, Michal Arbet wrote:
>> Hi,
>>
>> Two cycles ? I thought that most of work was implemented by vexxhost ? 
>> https://github.com/vexxhost/magnum-cluster-api
>> Do you have reviews somewhere if you are working on ClusterAPI ?
>>
>>
>> Thanks
>>
>> On 4/18/23 13:53, Jake Yip wrote:
>>> HI Takashi,
>>>
>>> Sorry I missed replying.
>>>
>>> On 30/3/2023 1:46 pm, Takashi Kajinami wrote:
>>>
>>>>
>>>> 1. Magnum
>>>> It seems SoftwareDeployment is used by k8s_fedora_atomic_v1 driver 
>>>> but I'm not too sure whether
>>>> this driver is still supported, because Fedora Atomic was EOLed a 
>>>> while ago, right ?
>>>>
>>>
>>> No It's still in the main k8s_fedora_coreos_v1 driver. It basically 
>>> is how everything is set up, so we still depend on this greatly for now.
>>>
>>> We are also working on a ClusterAPI driver who will bypass heat 
>>> altogether. We hope to get it working within two cycles, then we can 
>>> remove k8s_fedora_coreos_v1 together, possibly within another two 
>>> cycles.
>>>
>>> Thanks!
>>>
>>> Regards
>>> Jake
>>>
>> -- 
>> Michal Arbet
>> Openstack Engineer
>>
>> Ultimum Technologies a.s.
>> Na Po???? 1047/26, 11000 Praha 1
>> Czech Republic
>>
>> +420 604 228 897
>> michal.arbet at ultimum.io
>> _https://ultimum.io_
>>
>> LinkedIn <https://www.linkedin.com/company/ultimum-technologies>?| 
>> Twitter <https://twitter.com/ultimumtech>?| Facebook 
>> <https://www.facebook.com/ultimumtechnologies/timeline>
>>
> 


From mobilebackup95 at gmail.com  Sun Apr 30 10:04:18 2023
From: mobilebackup95 at gmail.com (Modyngs)
Date: Sun, 30 Apr 2023 13:34:18 +0330
Subject: [kolla-ansible][all][nova][zed][latest] USB passthrough / Hot-plug /
 Cold-plug
Message-ID: <CAOV3zY-w5P+NJf7m0zkP-T2SLh1q=22uCiKXN=R3HLz2cZYbvQ@mail.gmail.com>

090c090cFolks,

A USB device (not necessarily a mass/Flash drive) needs to be connected to
one of the VMs (an openstack instance).

Openstack installed with kolla-ansible{Latest version/ Also tested on Zed}
ALL IN ONE Deployments on ubuntu server 22.04 ( Core i9 12900K).

I found the [nova-libvirt] container which contains *virsh *and is able to
edit it or use custom config for VMs.

I've gone through lots of the docs, to name a few:
https://libvirt.org/formatdomain.html
https://wiki.openstack.org/wiki/Nova/USB_device_hot_cold_plug
https://wiki.openstack.org/wiki/Nova/proposal_about_usb_passthrough
https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-libvirt-config-virsh.html
https://wiki.openstack.org/wiki/Nova/USB_device_hot_cold_plug
https://docs.nxp.com/bundle/GUID-487B2E69-BB19-42CB-AC38-7EF18C0FE3AE/page/GUID-A658B311-CE08-4496-9491-1F00687EC4AE.html

but none of them worked for me!!

To reproduce:

*Cold-Plug :*
*$ lsusb  (on host)*
Bus 001 Device 014: ID 090c:1000 Silicon Motion >>>> Note Device number
changed every time I disconnect the device. So it might be different in the
changed attempt shown below)

*$ docker exec -it nova_libvirt /bin/bash*
*%Turn the Desired VM off*
*# virsh list --all*
 Id   Name                State
---------------------------------------------
 2    instance-00000002   running
19   instance-00000008   running
  -    instance-0000000a   shut off
*# virsh edit instance-0000000a*
                    Add the changes [1][2][3][4],... ( many efforts have
been done but few samples of them are)
[1]: under <devices> added

<hostdev mode='subsystem' type='usb'>
  <source>
    <vendor id='0x090c'/>
    <product id='0x1000'/>
  </source>
</hostdev>

[2]:under <devices> added

  <controller type='usb' index='0'/>
  <hostdev mode='subsystem' type='usb'>
    <source>
      <vendor id='0x090c'/>
      <product id='0x1000'/>
    </source>
  </hostdev>

[3]: under <devices> added

<hostdev mode='subsystem' type='usb' managed='yes'>
  <source>
    <vendor id='0x090c'/>
    <product id='0x1000'/>
  </source>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
</hostdev>

[4]: under <devices> added

<controller type='usb' model='nec-xhci' index='0'/>
  <hostdev mode='subsystem' type='usb' managed='yes'>
    <source>
      <vendor id='0x090c'/>
      <product id='0x1000'/>
    </source>
    <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
  </hostdev>

[5]:

<controller type='usb' index='0'>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
</controller>
<hostdev mode='subsystem' type='usb' managed='yes'>
  <source>
    <vendor id='0x090c'/>
    <product id='0x1000'/>
  </source>
  <address type='usb' bus='1' port='2'/>
  <controller type='usb' index='0'/>
</hostdev>


*%Start the VM*
*expected behavior:*
          when login to the VM, lsusb or df -h shows the USB
*what happened:*
          it wont show the USB from the VM

*OR *virsh dumpxml instance-0000000a > instance-0000000a.xml
and then change the configs as above and then

virsh attach-device instance-0000000a --file
/path/to/updated-instance-0000000a.xml --config


*Hot-Plug :*
*$ lsusb  (on host)*
Bus 001 Device 014: ID 090c:1000 Silicon Motion >>>> Note Device number
changed every time I disconnect the device. So it might be different in the
changed attempt shown below)

*$ docker exec -it nova_libvirt /bin/bash*
*# virsh list --all*
 Id   Name                State
---------------------------------------------
 2    instance-00000002   running
19   instance-00000008   running
20   instance-0000000a   running


*#nano USB.xml*
*%add changes explained in *[1][2][3][4],...

*$ virsh attach-device  instance-0000000a   /path/to/USB.xml/file*

*expected behavior:*
          lsusb or df -h shows the USB
*what happened:*
          it wont show the USB from the VM




*Can you please guide me through this? Any recommendation would be much
appreciated!Any custom changes comes to your mind ( Reply it) would be
solution for this problem /;*
Thanks
Best regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230430/70d01d72/attachment.htm>