From whayutin at redhat.com  Tue Sep  1 01:09:14 2020
From: whayutin at redhat.com (Wesley Hayutin)
Date: Mon, 31 Aug 2020 19:09:14 -0600
Subject: [rdo-users] [TripleO][Ussuri] image prepare, cannot download
 containers image prepare recently
In-Reply-To: <CABE5tBaD9qfh8F2bYCVm9QoFXBEG28+FBUM75Wemh1oFk9XUrw@mail.gmail.com>
References: <CABE5tBaD9qfh8F2bYCVm9QoFXBEG28+FBUM75Wemh1oFk9XUrw@mail.gmail.com>
Message-ID: <CAOHJT4Kxow5Ko3S=uScE4DR6As7zLSP5_etyDPmeuv2+4yTpxg@mail.gmail.com>

On Mon, Aug 31, 2020 at 1:23 PM Ruslanas Gžibovskis <ruslanas at lpic.lt>
wrote:

> Hi all,
>
> I have noticed, that recently my undercloud is not able to download images
> [0]. I have provided newly generated containers-prepare-parameter.yaml and
> outputs from container image prepare
>
> providing --verbose and later beginning of --debug (in the end) [0]
>
> were there any changes? As "openstack tripleo container image prepare
> default --output-env-file containers-prepare-parameter.yaml
> --local-push-destination" have prepared a bit different file, compared
> what was previously: NEW # namespace: docker.io/tripleou VS namespace:
> docker.io/tripleomaster # OLD
>
>
> [0] - http://paste.openstack.org/show/rBCNAQJBEe9y7CKyi9aG/
> --
> Ruslanas Gžibovskis
> +370 6030 7030
>

hrm.. seems to be there:
https://hub.docker.com/r/tripleou/centos-binary-gnocchi-metricd/tags?page=1&name=current-tripleo

I see current-tripleo tags

Here are some example config and logs for your reference, although what you
have seems sane to me.

https://logserver.rdoproject.org/61/749161/1/openstack-check/tripleo-ci-centos-8-ovb-3ctlr_1comp-featureset001/f87b9d9/logs/undercloud/home/zuul/containers-prepare-parameter.yaml.txt.gz
https://logserver.rdoproject.org/61/749161/1/openstack-check/tripleo-ci-centos-8-ovb-3ctlr_1comp-featureset001/f87b9d9/logs/undercloud/var/log/tripleo-container-image-prepare-ansible.log.txt.gz
https://logserver.rdoproject.org/61/749161/1/openstack-check/tripleo-ci-centos-8-ovb-3ctlr_1comp-featureset001/f87b9d9/logs/undercloud/var/log/tripleo-container-image-prepare.log.txt.gz
https://647ea51a7c76ba5f17c8-d499b2e7288499505ef93c98963c2e35.ssl.cf5.rackcdn.com/748668/1/gate/tripleo-ci-centos-8-standalone/0c706e1/logs/undercloud/home/zuul/containers-prepare-parameters.yaml




> _______________________________________________
> users mailing list
> users at lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/users
>
> To unsubscribe: users-unsubscribe at lists.rdoproject.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200831/987d31e1/attachment-0001.html>

From yamamoto at midokura.com  Tue Sep  1 01:49:12 2020
From: yamamoto at midokura.com (Takashi Yamamoto)
Date: Tue, 1 Sep 2020 10:49:12 +0900
Subject: [neutron][networking-midonet] Maintainers needed
In-Reply-To: <5E2F5826-559E-42E9-84C5-FA708E5A122A@gmail.com>
References: <0AC5AC07-E97E-43CC-B344-A3E992B8CCA4@netways.de>
 <610412AF-AADF-44BD-ABA2-BA289B7C8F8A@redhat.com>
 <5E2F5826-559E-42E9-84C5-FA708E5A122A@gmail.com>
Message-ID: <CAH=wFzS6usQqLeUtZ3iwyzw5f+ph38eaHCEQ0xsKo2ZzMREBgA@mail.gmail.com>

Sebastian, Sam,

thank you for speaking up.

as Slawek said, the first (and probably the biggest) thing is to fix the ci.
the major part for it is to make midonet itself to run on ubuntu
version used by the ci. (18.04, or maybe directly to 20.04)
https://midonet.atlassian.net/browse/MNA-1344
iirc, the remaining blockers are:
* libreswan (used by vpnaas)
* vpp (used by fip64)
maybe it's the easiest to drop those features along with their
required components, if it's acceptable for your use cases.

alternatively you might want to make midonet run in a container. (so
that you can run it with older ubuntu, or even a container trimmed for
JVM)
there were a few attempts to containerize midonet.
i think this is the latest one: https://github.com/midonet/midonet-docker

On Fri, Aug 28, 2020 at 7:10 AM Sam Morrison <sorrison at gmail.com> wrote:
>
> We (Nectar Research Cloud) use midonet heavily too, it works really well and we haven’t found another driver that works for us. We tried OVN but it just doesn’t scale to the size of environment we have.
>
> I’m happy to help too.
>
> Cheers,
> Sam
>
>
>
> > On 31 Jul 2020, at 2:06 am, Slawek Kaplonski <skaplons at redhat.com> wrote:
> >
> > Hi,
> >
> > Thx Sebastian for stepping in to maintain the project. That is great news.
> > I think that at the beginning You should do 2 things:
> > - sync with Takashi Yamamoto (I added him to the loop) as he is probably most active current maintainer of this project,
> > - focus on fixing networking-midonet ci which is currently broken - all scenario jobs aren’t working fine on Ubuntu 18.04 (and we are going to move to 20.04 in this cycle), migrate jobs to zuulv3 from the legacy ones and finally add them to the ci again,
> >
> > I can of course help You with ci jobs if You need any help. Feel free to ping me on IRC or email (can be off the list).
> >
> >> On 29 Jul 2020, at 15:24, Sebastian Saemann <Sebastian.Saemann at netways.de> wrote:
> >>
> >> Hi Slawek,
> >>
> >> we at NETWAYS are running most of our neutron networking on top of midonet and wouldn't be too happy if it gets deprecated and removed. So we would like to take over the maintainer role for this part.
> >>
> >> Please let me know how to proceed and how we can be onboarded easily.
> >>
> >> Best regards,
> >>
> >> Sebastian
> >>
> >> --
> >> Sebastian Saemann
> >> Head of Managed Services
> >>
> >> NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
> >> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
> >> CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB25207
> >> https://netways.de | sebastian.saemann at netways.de
> >>
> >> ** NETWAYS Web Services - https://nws.netways.de **
> >
> > —
> > Slawek Kaplonski
> > Principal software engineer
> > Red Hat
> >
> >
>


From sorrison at gmail.com  Tue Sep  1 04:39:03 2020
From: sorrison at gmail.com (Sam Morrison)
Date: Tue, 1 Sep 2020 14:39:03 +1000
Subject: [neutron][networking-midonet] Maintainers needed
In-Reply-To: <CAH=wFzS6usQqLeUtZ3iwyzw5f+ph38eaHCEQ0xsKo2ZzMREBgA@mail.gmail.com>
References: <0AC5AC07-E97E-43CC-B344-A3E992B8CCA4@netways.de>
 <610412AF-AADF-44BD-ABA2-BA289B7C8F8A@redhat.com>
 <5E2F5826-559E-42E9-84C5-FA708E5A122A@gmail.com>
 <CAH=wFzS6usQqLeUtZ3iwyzw5f+ph38eaHCEQ0xsKo2ZzMREBgA@mail.gmail.com>
Message-ID: <43C4AF2B-C5C0-40EB-B621-AC6799471D01@gmail.com>



> On 1 Sep 2020, at 11:49 am, Takashi Yamamoto <yamamoto at midokura.com> wrote:
> 
> Sebastian, Sam,
> 
> thank you for speaking up.
> 
> as Slawek said, the first (and probably the biggest) thing is to fix the ci.
> the major part for it is to make midonet itself to run on ubuntu
> version used by the ci. (18.04, or maybe directly to 20.04)
> https://midonet.atlassian.net/browse/MNA-1344
> iirc, the remaining blockers are:
> * libreswan (used by vpnaas)
> * vpp (used by fip64)
> maybe it's the easiest to drop those features along with their
> required components, if it's acceptable for your use cases.

We are running midonet-cluster and midolman on 18.04, we dropped those package dependencies from our ubuntu package to get it working.

We currently have built our own and host in our internal repo but happy to help putting this upstream somehow. Can we upload them to the midonet apt repo, does it still exist?

I’m keen to do the work but might need a bit of guidance to get started,

Sam






> 
> alternatively you might want to make midonet run in a container. (so
> that you can run it with older ubuntu, or even a container trimmed for
> JVM)
> there were a few attempts to containerize midonet.
> i think this is the latest one: https://github.com/midonet/midonet-docker
> 
> On Fri, Aug 28, 2020 at 7:10 AM Sam Morrison <sorrison at gmail.com> wrote:
>> 
>> We (Nectar Research Cloud) use midonet heavily too, it works really well and we haven’t found another driver that works for us. We tried OVN but it just doesn’t scale to the size of environment we have.
>> 
>> I’m happy to help too.
>> 
>> Cheers,
>> Sam
>> 
>> 
>> 
>>> On 31 Jul 2020, at 2:06 am, Slawek Kaplonski <skaplons at redhat.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Thx Sebastian for stepping in to maintain the project. That is great news.
>>> I think that at the beginning You should do 2 things:
>>> - sync with Takashi Yamamoto (I added him to the loop) as he is probably most active current maintainer of this project,
>>> - focus on fixing networking-midonet ci which is currently broken - all scenario jobs aren’t working fine on Ubuntu 18.04 (and we are going to move to 20.04 in this cycle), migrate jobs to zuulv3 from the legacy ones and finally add them to the ci again,
>>> 
>>> I can of course help You with ci jobs if You need any help. Feel free to ping me on IRC or email (can be off the list).
>>> 
>>>> On 29 Jul 2020, at 15:24, Sebastian Saemann <Sebastian.Saemann at netways.de> wrote:
>>>> 
>>>> Hi Slawek,
>>>> 
>>>> we at NETWAYS are running most of our neutron networking on top of midonet and wouldn't be too happy if it gets deprecated and removed. So we would like to take over the maintainer role for this part.
>>>> 
>>>> Please let me know how to proceed and how we can be onboarded easily.
>>>> 
>>>> Best regards,
>>>> 
>>>> Sebastian
>>>> 
>>>> --
>>>> Sebastian Saemann
>>>> Head of Managed Services
>>>> 
>>>> NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
>>>> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
>>>> CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB25207
>>>> https://netways.de | sebastian.saemann at netways.de
>>>> 
>>>> ** NETWAYS Web Services - https://nws.netways.de **
>>> 
>>> —
>>> Slawek Kaplonski
>>> Principal software engineer
>>> Red Hat
>>> 
>>> 
>> 



From yamamoto at midokura.com  Tue Sep  1 04:59:39 2020
From: yamamoto at midokura.com (Takashi Yamamoto)
Date: Tue, 1 Sep 2020 13:59:39 +0900
Subject: [neutron][networking-midonet] Maintainers needed
In-Reply-To: <43C4AF2B-C5C0-40EB-B621-AC6799471D01@gmail.com>
References: <0AC5AC07-E97E-43CC-B344-A3E992B8CCA4@netways.de>
 <610412AF-AADF-44BD-ABA2-BA289B7C8F8A@redhat.com>
 <5E2F5826-559E-42E9-84C5-FA708E5A122A@gmail.com>
 <CAH=wFzS6usQqLeUtZ3iwyzw5f+ph38eaHCEQ0xsKo2ZzMREBgA@mail.gmail.com>
 <43C4AF2B-C5C0-40EB-B621-AC6799471D01@gmail.com>
Message-ID: <CAH=wFzRmjbCy5vQOrpu=rX4Be-_GYPOE602kDShvV-ZtX+eF6g@mail.gmail.com>

hi,

On Tue, Sep 1, 2020 at 1:39 PM Sam Morrison <sorrison at gmail.com> wrote:
>
>
>
> > On 1 Sep 2020, at 11:49 am, Takashi Yamamoto <yamamoto at midokura.com> wrote:
> >
> > Sebastian, Sam,
> >
> > thank you for speaking up.
> >
> > as Slawek said, the first (and probably the biggest) thing is to fix the ci.
> > the major part for it is to make midonet itself to run on ubuntu
> > version used by the ci. (18.04, or maybe directly to 20.04)
> > https://midonet.atlassian.net/browse/MNA-1344
> > iirc, the remaining blockers are:
> > * libreswan (used by vpnaas)
> > * vpp (used by fip64)
> > maybe it's the easiest to drop those features along with their
> > required components, if it's acceptable for your use cases.
>
> We are running midonet-cluster and midolman on 18.04, we dropped those package dependencies from our ubuntu package to get it working.
>
> We currently have built our own and host in our internal repo but happy to help putting this upstream somehow. Can we upload them to the midonet apt repo, does it still exist?

it still exists. but i don't think it's maintained well.
let me find and ask someone in midokura who "owns" that part of infra.

does it also involve some package-related modifications to midonet repo, right?

>
> I’m keen to do the work but might need a bit of guidance to get started,
>
> Sam
>
>
>
>
>
>
> >
> > alternatively you might want to make midonet run in a container. (so
> > that you can run it with older ubuntu, or even a container trimmed for
> > JVM)
> > there were a few attempts to containerize midonet.
> > i think this is the latest one: https://github.com/midonet/midonet-docker
> >
> > On Fri, Aug 28, 2020 at 7:10 AM Sam Morrison <sorrison at gmail.com> wrote:
> >>
> >> We (Nectar Research Cloud) use midonet heavily too, it works really well and we haven’t found another driver that works for us. We tried OVN but it just doesn’t scale to the size of environment we have.
> >>
> >> I’m happy to help too.
> >>
> >> Cheers,
> >> Sam
> >>
> >>
> >>
> >>> On 31 Jul 2020, at 2:06 am, Slawek Kaplonski <skaplons at redhat.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Thx Sebastian for stepping in to maintain the project. That is great news.
> >>> I think that at the beginning You should do 2 things:
> >>> - sync with Takashi Yamamoto (I added him to the loop) as he is probably most active current maintainer of this project,
> >>> - focus on fixing networking-midonet ci which is currently broken - all scenario jobs aren’t working fine on Ubuntu 18.04 (and we are going to move to 20.04 in this cycle), migrate jobs to zuulv3 from the legacy ones and finally add them to the ci again,
> >>>
> >>> I can of course help You with ci jobs if You need any help. Feel free to ping me on IRC or email (can be off the list).
> >>>
> >>>> On 29 Jul 2020, at 15:24, Sebastian Saemann <Sebastian.Saemann at netways.de> wrote:
> >>>>
> >>>> Hi Slawek,
> >>>>
> >>>> we at NETWAYS are running most of our neutron networking on top of midonet and wouldn't be too happy if it gets deprecated and removed. So we would like to take over the maintainer role for this part.
> >>>>
> >>>> Please let me know how to proceed and how we can be onboarded easily.
> >>>>
> >>>> Best regards,
> >>>>
> >>>> Sebastian
> >>>>
> >>>> --
> >>>> Sebastian Saemann
> >>>> Head of Managed Services
> >>>>
> >>>> NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
> >>>> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
> >>>> CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB25207
> >>>> https://netways.de | sebastian.saemann at netways.de
> >>>>
> >>>> ** NETWAYS Web Services - https://nws.netways.de **
> >>>
> >>> —
> >>> Slawek Kaplonski
> >>> Principal software engineer
> >>> Red Hat
> >>>
> >>>
> >>
>


From yasufum.o at gmail.com  Tue Sep  1 05:23:56 2020
From: yasufum.o at gmail.com (Yasufumi Ogawa)
Date: Tue, 1 Sep 2020 14:23:56 +0900
Subject: [tacker] Wallaby vPTG
Message-ID: <e159766b-8508-33fc-d90b-97278356367e@gmail.com>

Hi team,

I booked our slots, 27-29 Oct 6am-8am UTC, for the next vPTG[1] as we 
agreed in previous irc meeting. I also prepared an etherpad [2], so 
please add your name and suggestions.

[1] https://ethercalc.openstack.org/7xp2pcbh1ncb
[2] https://etherpad.opendev.org/p/Tacker-PTG-Wallaby

Thanks,
Yasufumi


From arnaud.morin at gmail.com  Tue Sep  1 05:59:33 2020
From: arnaud.morin at gmail.com (Arnaud MORIN)
Date: Tue, 1 Sep 2020 07:59:33 +0200
Subject: [ops] Restructuring OSOPS tools
In-Reply-To: <cbd0a8a1-348d-2d00-6573-e6a6569cdde9@openstack.org>
References: <f24f25c2-fb44-125c-0306-1a3362732a3f@gmx.com>
 <cbd0a8a1-348d-2d00-6573-e6a6569cdde9@openstack.org>
Message-ID: <CALn_SgYu2oq+ttV-uhcKvAWfZME5pGAv8DTUSSs3gA93Vd7zrg@mail.gmail.com>

Hello,

I also agree with the merging of everything into one repo. When I
discovered those repos, I was surprised that it was split into several
repos.
Keeping a structure with contrib/ folder like Thierry example is the best
imo.

You said it, it will ease discovery of tools, but also maintenance.

Cheers.

Le ven. 28 août 2020 à 12:06, Thierry Carrez <thierry at openstack.org> a
écrit :

> Sean McGinnis wrote:
> > [...]
> > Since these are now owned by an official SIG, we can move this content
> > back under the openstack/ namespace. That should help increase
> > visibility somewhat, and make things look a little more official. It
> > will also allow contributors to tooling to get recognition for
> > contributing to an import part of the OpenStack ecosystem.
> >
> > I do think it's can be a little more difficult to find things spread out
> > over several repos though. For simplicity with finding tooling, as well
> > as watching for reviews and helping with overall maintenance, I would
> > like to move all of these under a common openstack/osops. Under that
> > repo, we can then have a folder structure with tools/logging,
> > tools/monitoring, etc.
>
> Also the original setup[1] called for moving things from one repo to
> another as they get more mature, which loses history. So I agree a
> single repository is better.
>
> However, one benefit of the original setup was that it made it really
> low-friction to land half-baked code in the osops-tools-contrib
> repository. The idea was to encourage tools sharing, rather than judge
> quality or curate a set. I think it's critical for the success of OSops
> that operator code can be brought in with very low friction, and
> curation can happen later.
>
> If we opt for a theme-based directory structure, we could communicate
> that a given tool is in "unmaintained/use-at-your-own-risk" status using
> metadata. But thinking more about it, I would suggest we keep a
> low-friction "contrib/" directory in the repo, which more clearly
> communicates "use at your own risk" for anything within it. Then we
> could move tools under the "tools/" directory structure if a community
> forms within the SIG to support and improve a specific tool. That would
> IMHO allow both low-friction landing *and* curation to happen.
>
> > [...]
> > Please let me know if there are any objects to this plan. Otherwise, I
> > will start cleaning things up and getting it staged in a new repo to be
> > imported as an official repo owned by the SIG.
>
> I like it!
>
> [1] https://wiki.openstack.org/wiki/Osops
>
> --
> Thierry Carrez (ttx)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/b3b5ec8f/attachment-0001.html>

From sorrison at gmail.com  Tue Sep  1 06:03:55 2020
From: sorrison at gmail.com (Sam Morrison)
Date: Tue, 1 Sep 2020 16:03:55 +1000
Subject: [neutron][networking-midonet] Maintainers needed
In-Reply-To: <CAH=wFzRmjbCy5vQOrpu=rX4Be-_GYPOE602kDShvV-ZtX+eF6g@mail.gmail.com>
References: <0AC5AC07-E97E-43CC-B344-A3E992B8CCA4@netways.de>
 <610412AF-AADF-44BD-ABA2-BA289B7C8F8A@redhat.com>
 <5E2F5826-559E-42E9-84C5-FA708E5A122A@gmail.com>
 <CAH=wFzS6usQqLeUtZ3iwyzw5f+ph38eaHCEQ0xsKo2ZzMREBgA@mail.gmail.com>
 <43C4AF2B-C5C0-40EB-B621-AC6799471D01@gmail.com>
 <CAH=wFzRmjbCy5vQOrpu=rX4Be-_GYPOE602kDShvV-ZtX+eF6g@mail.gmail.com>
Message-ID: <92959221-0353-4D48-8726-8FE71AFEA652@gmail.com>



> On 1 Sep 2020, at 2:59 pm, Takashi Yamamoto <yamamoto at midokura.com> wrote:
> 
> hi,
> 
> On Tue, Sep 1, 2020 at 1:39 PM Sam Morrison <sorrison at gmail.com> wrote:
>> 
>> 
>> 
>>> On 1 Sep 2020, at 11:49 am, Takashi Yamamoto <yamamoto at midokura.com> wrote:
>>> 
>>> Sebastian, Sam,
>>> 
>>> thank you for speaking up.
>>> 
>>> as Slawek said, the first (and probably the biggest) thing is to fix the ci.
>>> the major part for it is to make midonet itself to run on ubuntu
>>> version used by the ci. (18.04, or maybe directly to 20.04)
>>> https://midonet.atlassian.net/browse/MNA-1344
>>> iirc, the remaining blockers are:
>>> * libreswan (used by vpnaas)
>>> * vpp (used by fip64)
>>> maybe it's the easiest to drop those features along with their
>>> required components, if it's acceptable for your use cases.
>> 
>> We are running midonet-cluster and midolman on 18.04, we dropped those package dependencies from our ubuntu package to get it working.
>> 
>> We currently have built our own and host in our internal repo but happy to help putting this upstream somehow. Can we upload them to the midonet apt repo, does it still exist?
> 
> it still exists. but i don't think it's maintained well.
> let me find and ask someone in midokura who "owns" that part of infra.
> 
> does it also involve some package-related modifications to midonet repo, right?


Yes a couple, I will send up as as pull requests to https://github.com/midonet/midonet <https://github.com/midonet/midonet> today or tomorrow

Sam



> 
>> 
>> I’m keen to do the work but might need a bit of guidance to get started,
>> 
>> Sam
>> 
>> 
>> 
>> 
>> 
>> 
>>> 
>>> alternatively you might want to make midonet run in a container. (so
>>> that you can run it with older ubuntu, or even a container trimmed for
>>> JVM)
>>> there were a few attempts to containerize midonet.
>>> i think this is the latest one: https://github.com/midonet/midonet-docker
>>> 
>>> On Fri, Aug 28, 2020 at 7:10 AM Sam Morrison <sorrison at gmail.com> wrote:
>>>> 
>>>> We (Nectar Research Cloud) use midonet heavily too, it works really well and we haven’t found another driver that works for us. We tried OVN but it just doesn’t scale to the size of environment we have.
>>>> 
>>>> I’m happy to help too.
>>>> 
>>>> Cheers,
>>>> Sam
>>>> 
>>>> 
>>>> 
>>>>> On 31 Jul 2020, at 2:06 am, Slawek Kaplonski <skaplons at redhat.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> Thx Sebastian for stepping in to maintain the project. That is great news.
>>>>> I think that at the beginning You should do 2 things:
>>>>> - sync with Takashi Yamamoto (I added him to the loop) as he is probably most active current maintainer of this project,
>>>>> - focus on fixing networking-midonet ci which is currently broken - all scenario jobs aren’t working fine on Ubuntu 18.04 (and we are going to move to 20.04 in this cycle), migrate jobs to zuulv3 from the legacy ones and finally add them to the ci again,
>>>>> 
>>>>> I can of course help You with ci jobs if You need any help. Feel free to ping me on IRC or email (can be off the list).
>>>>> 
>>>>>> On 29 Jul 2020, at 15:24, Sebastian Saemann <Sebastian.Saemann at netways.de> wrote:
>>>>>> 
>>>>>> Hi Slawek,
>>>>>> 
>>>>>> we at NETWAYS are running most of our neutron networking on top of midonet and wouldn't be too happy if it gets deprecated and removed. So we would like to take over the maintainer role for this part.
>>>>>> 
>>>>>> Please let me know how to proceed and how we can be onboarded easily.
>>>>>> 
>>>>>> Best regards,
>>>>>> 
>>>>>> Sebastian
>>>>>> 
>>>>>> --
>>>>>> Sebastian Saemann
>>>>>> Head of Managed Services
>>>>>> 
>>>>>> NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
>>>>>> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
>>>>>> CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB25207
>>>>>> https://netways.de | sebastian.saemann at netways.de
>>>>>> 
>>>>>> ** NETWAYS Web Services - https://nws.netways.de **
>>>>> 
>>>>> —
>>>>> Slawek Kaplonski
>>>>> Principal software engineer
>>>>> Red Hat
>>>>> 
>>>>> 
>>>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/b10528f2/attachment.html>

From ralonsoh at redhat.com  Tue Sep  1 06:57:55 2020
From: ralonsoh at redhat.com (Rodolfo Alonso Hernandez)
Date: Tue, 1 Sep 2020 08:57:55 +0200
Subject: [neutron] Bug deputy report August 24 - 30
Message-ID: <CAECr9X4DMAXgxKVNzqXnL1ShUXz3JBoyEN=cVkbSP-9zS0RBow@mail.gmail.com>

Hello:

This is the list of bugs in the period from August 24 to August 30.

Critical:
(none)

High:
- https://bugs.launchpad.net/neutron/+bug/1892861: [neutron-tempest-plugin]
If paramiko SSH client connection fails because of authentication, cannot
reconnect (unassigned)
- https://bugs.launchpad.net/neutron/+bug/1893314: set neutron quota not
take effect (ZhouHeng, https://review.opendev.org/#/c/748578/)

Medium:
- https://bugs.launchpad.net/neutron/+bug/1892496: 500 on SG deletion:
Cannot delete or update a parent row (unassigned)
- https://bugs.launchpad.net/neutron/+bug/1888878:  Data not present in OVN
IDL when requested (fix released)
- https://bugs.launchpad.net/neutron/+bug/1892846: AttributeError in
l3-agent changing HA router to non-HA (Slawek,
https://review.opendev.org/#/c/747922/)

Low:
- https://bugs.launchpad.net/neutron/+bug/1892741: neutron-sriov-nic-agent
cannot be disabled (unassigned)
- https://bugs.launchpad.net/neutron/+bug/1893188: [tempest] Randomize
subnet CIDR to avoid test clashes (Lajos,
https://review.opendev.org/#/c/749041/)

Wishlist:
- https://bugs.launchpad.net/neutron/+bug/1893625: Implement router gateway
IP QoS in OVN backend (zhanghao, https://review.opendev.org/#/c/749012/)

Incomplete:
- https://bugs.launchpad.net/neutron/+bug/1893015: ping with large package
size fails

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/3dcc59e1/attachment.html>

From tonyppe at gmail.com  Tue Sep  1 09:22:32 2020
From: tonyppe at gmail.com (Tony Pearce)
Date: Tue, 1 Sep 2020 17:22:32 +0800
Subject: [Magnum][Kayobe] Magnum Kubernetes clusters failing to be created
 (bugs?)
Message-ID: <CAK1+d=5Gu51t3FDt3htxhZdKf6Uhg26V3VBt5ckp9OR1v8Gktw@mail.gmail.com>

Hi guys, I hope you are all keeping safe and well at the moment.

I am trying to launch Kubernetes clusters into Openstack Train which has
been deployed via Kayobe (Kayobe as I understand is a wrapper for
kolla-ansible). There have been a few strange issues here and I've
struggled to isolate them. These issues started recently after a fresh
Openstack deployment some months ago (around February 2020) to give some
context. This Openstack is not "live" as I've been trying to get to the
bottom of the issues:

Issue 1. When trying to launch a cluster we get error "Resource Create
Failed: Forbidden: Resources.Kube
Masters.Resources[0].Resources.Kube-Master: Only Volume-Backed Servers Are
Allowed For Flavors With Zero Disk. "

Issue 2. After successfully creating a cluster of a smaller node size, the
"resize cluster" is failing (however update the cluster is working).

Some background on this specific environment:
Deployed via Kayobe, with these components:
Cinder, Designate, iscsid, Magnum, Multipathd, neutron provider networks

The Cinder component integrates with iSCSI SAN storage using the Nimble
driver. This is the only storage. In order to prevent Openstack from
allocating Compute node local HDD as instance storage, I have all flavours
configured with root disk / ephemeral disk / swap disk = "0MB". This then
results in all instance data being stored on the backend Cinder storage
appliance.

I was able to get a cluster deployed by first creating the template as
needed, then when launching the cluster Horizon prompts you for items
already there in the template such as number of nodes, node flavour and
labels etc. I re-supplied all of the info (as to duplicate it) and then
tried creating the cluster. After many many times trying over the course of
a few weeks to a few months it was successful. I was then able to work
around the issue #2 above to get it increased in size.

When looking at the logs for issue #2, it looks like some content is
missing in the API but I am not certain. I will include a link to the
pastebin below [1].
When trying to resize the cluster, Horizon gives error: "Error: Unable to
resize given cluster id: 99693dbf-160a-40e0-9ed4-93f3370367ee". I then
searched the controller node /var/log directory for this ID and found
"horizon.log  [:error] [pid 25] Not Found:
/api/container_infra/clusters/99693dbf-160a-40e0-9ed4-93f3370367ee/resize".
Going to the Horizon menu "update cluster" allows you to increase the
number of nodes and then save/apply the config which does indeed resize the
cluster.



Regarding issue #1, we've been unable to deploy a cluster in a new project
and the error is hinting it relates to the flavours having 0MB disk
specified, though this error is new and we've been successful previously
with deploying clusters (albeit with the hit-and-miss experiences) using
the flavour with 0MB disk as described above. Again I searched for the
(stack) ID after the failure, in the logs on the controller and I obtained
not much more than the error already seen with Horizon [2].

I was able to create new flavours with root disk = 15GB and then
successfully deploy a cluster on the next immediate try. Update cluster
from 3 nodes to 6 nodes was also immediately successful. However I see the
compute nodes "used" disk space increasing after increasing the cluster
size which is an issue as the compute node has very limited HDD capacity
(32GB SD card).

At this point I also checked 1) previously installed cluster using the 0MB
disk flavour and 2) new instances using the 0MB disk flavour. I notice that
the previous cluster is having host storage allocated but while the new
instance is not having host storage allocated. So the cluster create
success is using flavour with disk = 0MB while the result is compute HDD
storage being consumed.

So with the above, please may I clarify on the following?
1. It seems that 0MB disk flavours may not be supported with magnum now?
Could the experts confirm? :) Is there another way that I should be
configuring this so that compute node disk is not being consumed (because
it is slow and has limited capacity).
2. The issue #1 looks like a bug to me, is it known? If not, is this mail
enough to get it realised?

Pastebin links as mentioned
[1] http://paste.openstack.org/show/797316/

[2] http://paste.openstack.org/show/797318/


Many thanks,

Regards,


Tony Pearce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/a7954d28/attachment-0001.html>

From e0ne at e0ne.info  Tue Sep  1 10:21:31 2020
From: e0ne at e0ne.info (Ivan Kolodyazhny)
Date: Tue, 1 Sep 2020 13:21:31 +0300
Subject: [horizon] horizon-integration-tests job is broken
In-Reply-To: <CAGocpaHweoJokrJB0=6SM_WtpWk2ALmBdaU57HbUTd96D61DdA@mail.gmail.com>
References: <CAGocpaHweoJokrJB0=6SM_WtpWk2ALmBdaU57HbUTd96D61DdA@mail.gmail.com>
Message-ID: <CAGocpaHrg_uJ3CgNGXPwxAzEjqT2K7cquBE_J4J8oU8rTWRECg@mail.gmail.com>

Fix [3] is merged.

[3] https://review.opendev.org/748881

Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/


On Mon, Aug 31, 2020 at 3:51 PM Ivan Kolodyazhny <e0ne at e0ne.info> wrote:

> Hi team,
>
> Please, do not trigger recheck if horizon-integration-tests failed like
> [1]:
> ______________ TestDashboardHelp.test_dashboard_help_redirection
> _______________
> 'NoneType' object is not iterable
>
> While I'm trying to figure out what is happening there [2], any help with
> troubleshooting is welcome.
>
>
> [1]
> https://51bb980dc10c72928109-9873e0e5415ff38d9f1a5cc3b1681b19.ssl.cf1.rackcdn.com/744847/2/check/horizon-integration-tests/62ace86/job-output.txt
>
> [2] https://review.opendev.org/#/c/749011
>
> Regards,
> Ivan Kolodyazhny,
> http://blog.e0ne.info/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/bda90706/attachment.html>

From ruslanas at lpic.lt  Tue Sep  1 12:22:38 2020
From: ruslanas at lpic.lt (=?UTF-8?Q?Ruslanas_G=C5=BEibovskis?=)
Date: Tue, 1 Sep 2020 14:22:38 +0200
Subject: [tripleo][ussuri][undercloud][tripleo_rabbitmq] do not start after
 reboot
Message-ID: <CABE5tBZ1_h6mkguNFGC7wZTvtcXQ1w_X=eq9Wx+u29aDMw7PfA@mail.gmail.com>

Hi all,

I think this issue might be known to RHOSP16 [1], but it is same in RDO -
ussuri with centos8.
if anything is needed, I could try to help/test.

my workaround is to run openstack undercloud install --force-stack-update

[1] https://access.redhat.com/solutions/5269241

-- 
Ruslanas Gžibovskis
+370 6030 7030
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/a49ecd1f/attachment.html>

From mnaser at vexxhost.com  Tue Sep  1 12:51:34 2020
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Tue, 1 Sep 2020 08:51:34 -0400
Subject: senlin auto scaling question
In-Reply-To: <CAPgF-frPN-Jqq1-UHgP0=Dsc=0AN1sE=VgwUqBWfMO-GObLBhg@mail.gmail.com>
References: <CAPgF-frPN-Jqq1-UHgP0=Dsc=0AN1sE=VgwUqBWfMO-GObLBhg@mail.gmail.com>
Message-ID: <CAEs876jnfQOWEwHrkfscx1z3B2Kc6a7F0tVpVHyoPMHmARcg3Q@mail.gmail.com>

Hi Satish,

I'm interested by this, did you end up finding a solution for this?

Thanks,
Mohammed

On Thu, Aug 27, 2020 at 1:54 PM Satish Patel <satish.txt at gmail.com> wrote:
>
> Folks,
>
> I have created very simple cluster using following command
>
> openstack cluster create --profile myserver --desired-capacity 2
> --min-size 2 --max-size 3 --strict my-asg
>
> It spun up 2 vm immediately now because the desired capacity is 2 so I
> am assuming if any node dies in the cluster it should spin up node to
> make count 2 right?
>
> so i killed one of node with "nove delete <instance-foo-1>"  but
> senlin didn't create node automatically to make desired capacity 2 (In
> AWS when you kill node in ASG it will create new node so is this
> senlin different then AWS?)
>


-- 
Mohammed Naser
VEXXHOST, Inc.


From fungi at yuggoth.org  Tue Sep  1 13:17:53 2020
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Tue, 1 Sep 2020 13:17:53 +0000
Subject: [neutron][security-sig] Bug deputy report August 24 - 30
In-Reply-To: <CAECr9X4DMAXgxKVNzqXnL1ShUXz3JBoyEN=cVkbSP-9zS0RBow@mail.gmail.com>
References: <CAECr9X4DMAXgxKVNzqXnL1ShUXz3JBoyEN=cVkbSP-9zS0RBow@mail.gmail.com>
Message-ID: <20200901131752.pdd7vs3aihz6xmyu@yuggoth.org>

Hopefully it's not a lot of additional work, but the VMT would be
thrilled if projects would also keep Public Security vulnerability
reports in mind and try to wrap up any they can. For example, the
Neutron project on Launchpad has 9 currently unresolved, some opened
more than 3 years ago:

<URL: https://bugs.launchpad.net/neutron/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.information_type%3Alist=PUBLICSECURITY >

I'm willing to bet at least a few are either fixed now, related to
deprecated/removed functionality, or simply unreproducible. And if
they're still real bugs but don't represent an actual exploitable
vulnerability, that's good to know too (in which case we'd just
switch them to regular Public bugs so the VMT no longer needs to
keep track of those).
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/475e9644/attachment.sig>

From zigo at debian.org  Tue Sep  1 14:35:45 2020
From: zigo at debian.org (Thomas Goirand)
Date: Tue, 1 Sep 2020 16:35:45 +0200
Subject: [nova] providing a local disk to a Nova instance
Message-ID: <c0d15c7d-1c4b-a0dd-3f5d-1ff501a58c0e@debian.org>

Hi Nova team!

tl;dr: we would like to contribute giving instances access to physical
block devices directly on the compute hosts. Would this be accepted?

Longer version:

About 3 or 4 years ago, someone wrote a spec, so we'd be able to provide
a local disk of a compute, directly to a VM to use. This was then
rejected, because at the time, Cinder had the blockdevice drive, which
was more or less achieving the same thing. Unfortunately, because nobody
was maintaining the blockdevice driver in Cinder, and because there was
no CI that could test it, the driver got removed.

We've investigated how we could otherwise implement it, and one solution
would be to use Cinder, but then we'd be going through an iSCSI export,
which would drastically reduce performances.

Another solution would be to manage KVM instances by hand, not touching
anything to libvirt and/or OpenVSwitch, but then we would loose the ease
of using the Nova API, so we would prefer to avoid this direction.

So we (ie: employees in my company) need to ask the Nova team: would you
consider a spec to do what was rejected before, since there's now no
other good enough alternative?

Our current goal is to be able to provide a disk directly to a VM, so
that we could build Ceph clusters with an hyper-converged model (ie:
storage hosted on the compute nodes). In this model, we wouldn't need
live-migration of a VM with an attached physical block device (though
the feature could be added on a later stage).

Before we start investigating how this can be done, I need to know if
this has at least some chances to be accepted or not. If there is, then
we'll probably start an experimental patch locally, then write a spec to
properly start this project. So please let us know.

Cheers,

Thomas Goirand (zigo)


From sosogh at 126.com  Tue Sep  1 07:23:51 2020
From: sosogh at 126.com (sosogh)
Date: Tue, 1 Sep 2020 15:23:51 +0800 (CST)
Subject: [kolla] questions when using external  mysql
Message-ID: <5c644eb6.3cda.174488cf629.Coremail.sosogh@126.com>

Hi list:



I want to use kolla-ansible to deploy openstack , but using external mysql. 
I am following these docs:  

https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html

https://docs.openstack.org/kolla-ansible/latest/reference/databases/external-mariadb-guide.html.




I have some questions:



################
##  Question 1 ##
################



 According to the offical doc , if setting it  in inventory file(multinode), 




kolla-ansible -i ./multinode deploy will throw out error:




I guest when kolla-ansible running the playbook against myexternalmariadbloadbalancer.com , 

the """register: find_custom_fluentd_inputs""" in """TASK [common : Find custom fluentd input config files]"""  maybe null .




################
##  Question 2 ##
################

 According to the offical doc , If the MariaDB username is not root, set database_username in /etc/kolla/globals.yml file:  




But in kolla-ansible/ansible/roles/xxxxxx/tasks/bootstrap.yml  , they use  ''' login_user: "{{ database_user }}"  ''' ， for example :



So at last  , I took the following steps:
1. """not""" setting [mariadb] in inventory file(multinode)   
2. set "database_user: openstack" for  "privillegeduser"


PS: 
My idea is that if using an external ready-to-use mysql (cluster),  
it is enough to tell kolla-ansible only the address/user/password of the external DB.
i.e. setting them in the file /etc/kolla/globals.yml and passwords.yml , no need to add it into inventory file(multinode)   


Finally , it is successful to  deploy openstack via kolla-ansible . 
So far I have not found any problems.   
 Are the steps what I took  good ( enough ) ? 
Thank you !



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/5b7b2c58/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2938 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/5b7b2c58/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 95768 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/5b7b2c58/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2508 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/5b7b2c58/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 22016 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/5b7b2c58/attachment-0007.png>

From jimmy at openstack.org  Tue Sep  1 15:00:14 2020
From: jimmy at openstack.org (Jimmy McArthur)
Date: Tue, 1 Sep 2020 10:00:14 -0500
Subject: 2020 Virtual Summit: Forum Submissions Now Accepted
Message-ID: <591437EB-0E99-4F7E-9ED9-482CCEB77C82@getmailspring.com>

Hello Everyone!

We are now accepting Forum [1] submissions for the 2020 Virtual Open Infrastructure Summit [2]. Please submit your ideas through the Summit CFP tool [3] through September 14th. Don't forget to put your brainstorming etherpad up on the Shanghai Forum page [4].

This is not a classic conference track with speakers and presentations. OSF community members (participants in development teams, operators, working groups, SIGs, and other interested individuals) discuss the topics they want to cover and get alignment on and we welcome your participation. The Forum is your opportunity to help shape the development of future project releases. More information about the Forum [1].

The timeline for submissions is as follows:

Aug 31st | Formal topic submission tool opens: https://cfp.openstack.org.
Sep 14th | Deadline for proposing Forum topics. Scheduling committee meeting to make draft agenda.
Sep 21st | Draft Forum schedule published. Crowd sourced session conflict detection. Forum promotion begins.
Sept 28th | Forum schedule final
Oct 19th | Forum begins!

If you have questions or concerns, please reach out to speakersupport at openstack.org.

Cheers,
Jimmy

[1] https://wiki.openstack.org/wiki/Forum
[2] https://www.openstack.org/summit/2020/
[3] https://cfp.openstack.org
[4]https://wiki.openstack.org/wiki/Forum/Virtual2020
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/d7b094ee/attachment.html>

From jimmy at openstack.org  Tue Sep  1 15:13:31 2020
From: jimmy at openstack.org (Jimmy McArthur)
Date: Tue, 1 Sep 2020 10:13:31 -0500
Subject: 2020 Virtual Summit: Forum Submissions Now Accepted
In-Reply-To: <591437EB-0E99-4F7E-9ED9-482CCEB77C82@getmailspring.com>
References: <591437EB-0E99-4F7E-9ED9-482CCEB77C82@getmailspring.com>
Message-ID: <5CFEF7CB-7732-4255-B3FE-CF1105FB994D@getmailspring.com>

Please replace the word "Shanghai" with the word "Virtual" :)

Cheers,
Jimmy "Bad at Email" McArthur

On Sep 1 2020, at 10:00 am, Jimmy McArthur <jimmy at openstack.org> wrote:
> Hello Everyone!
>
> We are now accepting Forum [1] submissions for the 2020 Virtual Open Infrastructure Summit [2]. Please submit your ideas through the Summit CFP tool [3] through September 14th. Don't forget to put your brainstorming etherpad up on the Shanghai Forum page [4].
>
> This is not a classic conference track with speakers and presentations. OSF community members (participants in development teams, operators, working groups, SIGs, and other interested individuals) discuss the topics they want to cover and get alignment on and we welcome your participation. The Forum is your opportunity to help shape the development of future project releases. More information about the Forum [1].
>
> The timeline for submissions is as follows:
>
> Aug 31st | Formal topic submission tool opens: https://cfp.openstack.org.
> Sep 14th | Deadline for proposing Forum topics. Scheduling committee meeting to make draft agenda.
> Sep 21st | Draft Forum schedule published. Crowd sourced session conflict detection. Forum promotion begins.
> Sept 28th | Forum schedule final
> Oct 19th | Forum begins!
>
> If you have questions or concerns, please reach out to speakersupport at openstack.org.
>
> Cheers,
> Jimmy
>
> [1] https://wiki.openstack.org/wiki/Forum
> [2] https://www.openstack.org/summit/2020/
> [3] https://cfp.openstack.org
> [4]https://wiki.openstack.org/wiki/Forum/Virtual2020

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/54fd61d5/attachment.html>

From alifshit at redhat.com  Tue Sep  1 15:15:53 2020
From: alifshit at redhat.com (Artom Lifshitz)
Date: Tue, 1 Sep 2020 11:15:53 -0400
Subject: [nova] providing a local disk to a Nova instance
In-Reply-To: <c0d15c7d-1c4b-a0dd-3f5d-1ff501a58c0e@debian.org>
References: <c0d15c7d-1c4b-a0dd-3f5d-1ff501a58c0e@debian.org>
Message-ID: <CACqyMifPge1yf0wD+y-1ch5B2H=0-ho4J6YJ6K6UO4rDi0c0aA@mail.gmail.com>

IIUC one of our (Red Hat's) customer-facing folks brought us a similar
question recently. In their case they wanted to use PCI passthrough to
pass an NVMe disk to an instance. This is technically possible, but
there would be major privacy concerns in a multi-tenant cloud, as Nova
currently has no way of cleaning up a disk after a VM has left it, so
either the guest OS would have to do it itself, or any subsequent VM
using that disk would have access to all of the previous VM's data
(this could be mitigated by full-disk encryption, though). Cleaning up
disks after VM's would probably fall more within Cybor's scope...

There's also the question of instance move operations like live and
cold migrations - what happens to the passed-through disk in those
cases? Does Nova have to copy it to the destination? I think those
would be fairly easily addressable though (there are no major
technical or political challenges, it's just a matter of someone
writing the code and reviewing).

The disk cleanup thing is going to be harder, I suspect - more
politically than technically. It's a bit of a chicken and egg problem
with Nova and Cyborg, at the moment. Nova can refuse features as being
out of scope and punt them to Cyborg, but I'm not sure how
production-ready Cyborg is...

On Tue, Sep 1, 2020 at 10:41 AM Thomas Goirand <zigo at debian.org> wrote:
>
> Hi Nova team!
>
> tl;dr: we would like to contribute giving instances access to physical
> block devices directly on the compute hosts. Would this be accepted?
>
> Longer version:
>
> About 3 or 4 years ago, someone wrote a spec, so we'd be able to provide
> a local disk of a compute, directly to a VM to use. This was then
> rejected, because at the time, Cinder had the blockdevice drive, which
> was more or less achieving the same thing. Unfortunately, because nobody
> was maintaining the blockdevice driver in Cinder, and because there was
> no CI that could test it, the driver got removed.
>
> We've investigated how we could otherwise implement it, and one solution
> would be to use Cinder, but then we'd be going through an iSCSI export,
> which would drastically reduce performances.
>
> Another solution would be to manage KVM instances by hand, not touching
> anything to libvirt and/or OpenVSwitch, but then we would loose the ease
> of using the Nova API, so we would prefer to avoid this direction.
>
> So we (ie: employees in my company) need to ask the Nova team: would you
> consider a spec to do what was rejected before, since there's now no
> other good enough alternative?
>
> Our current goal is to be able to provide a disk directly to a VM, so
> that we could build Ceph clusters with an hyper-converged model (ie:
> storage hosted on the compute nodes). In this model, we wouldn't need
> live-migration of a VM with an attached physical block device (though
> the feature could be added on a later stage).
>
> Before we start investigating how this can be done, I need to know if
> this has at least some chances to be accepted or not. If there is, then
> we'll probably start an experimental patch locally, then write a spec to
> properly start this project. So please let us know.
>
> Cheers,
>
> Thomas Goirand (zigo)
>



From skaplons at redhat.com  Tue Sep  1 16:44:36 2020
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Tue, 1 Sep 2020 18:44:36 +0200
Subject: [neutron][security-sig] Bug deputy report August 24 - 30
In-Reply-To: <20200901131752.pdd7vs3aihz6xmyu@yuggoth.org>
References: <CAECr9X4DMAXgxKVNzqXnL1ShUXz3JBoyEN=cVkbSP-9zS0RBow@mail.gmail.com>
 <20200901131752.pdd7vs3aihz6xmyu@yuggoth.org>
Message-ID: <20200901164436.uxshmwdjteudvedo@skaplons-mac>

Hi,

On Tue, Sep 01, 2020 at 01:17:53PM +0000, Jeremy Stanley wrote:
> Hopefully it's not a lot of additional work, but the VMT would be
> thrilled if projects would also keep Public Security vulnerability
> reports in mind and try to wrap up any they can. For example, the
> Neutron project on Launchpad has 9 currently unresolved, some opened
> more than 3 years ago:
> 
> <URL: https://bugs.launchpad.net/neutron/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.information_type%3Alist=PUBLICSECURITY >

Thx for the link Jeremy. I will check those bugs.

> 
> I'm willing to bet at least a few are either fixed now, related to
> deprecated/removed functionality, or simply unreproducible. And if
> they're still real bugs but don't represent an actual exploitable
> vulnerability, that's good to know too (in which case we'd just
> switch them to regular Public bugs so the VMT no longer needs to
> keep track of those).
> -- 
> Jeremy Stanley



-- 
Slawek Kaplonski
Principal software engineer
Red Hat



From kennelson11 at gmail.com  Tue Sep  1 17:02:27 2020
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Tue, 1 Sep 2020 10:02:27 -0700
Subject: Mentoring Boston University Students
Message-ID: <CAJ6yrQj40j2tAatjEQSmwJPRh5-TExK4eM3-c1tTpW9XiuNNvQ@mail.gmail.com>

Hello!

As you may or may not know, the last two years various community members
have mentored students from North Dakota State University for a semester to
work on projects in OpenStack. Recently, I learned of a similar program at
Boston University and they are still looking for mentors interested for the
upcoming semester.

Essentially you would have 5 to 7 students for 13 weeks to mentor and work
on some feature or effort in your project.

The time to apply is running out however as the deadline is Sept 3rd. If
you are interested, please let me know ASAP! I am happy to help get the
students up to speed with the community and getting their workspaces set
up, but the actual work they would do is more up to you :)

-Kendall (diablo_rojo)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/eab2e507/attachment-0001.html>

From tim.bell at cern.ch  Tue Sep  1 17:47:28 2020
From: tim.bell at cern.ch (Tim Bell)
Date: Tue, 1 Sep 2020 19:47:28 +0200
Subject: [nova] providing a local disk to a Nova instance
In-Reply-To: <CACqyMifPge1yf0wD+y-1ch5B2H=0-ho4J6YJ6K6UO4rDi0c0aA@mail.gmail.com>
References: <c0d15c7d-1c4b-a0dd-3f5d-1ff501a58c0e@debian.org>
 <CACqyMifPge1yf0wD+y-1ch5B2H=0-ho4J6YJ6K6UO4rDi0c0aA@mail.gmail.com>
Message-ID: <D67DF24C-0D4C-4E22-9707-844DE0C9D963@cern.ch>



> On 1 Sep 2020, at 17:15, Artom Lifshitz <alifshit at redhat.com> wrote:
> 
> IIUC one of our (Red Hat's) customer-facing folks brought us a similar
> question recently. In their case they wanted to use PCI passthrough to
> pass an NVMe disk to an instance. This is technically possible, but
> there would be major privacy concerns in a multi-tenant cloud, as Nova
> currently has no way of cleaning up a disk after a VM has left it, so
> either the guest OS would have to do it itself, or any subsequent VM
> using that disk would have access to all of the previous VM's data
> (this could be mitigated by full-disk encryption, though). Cleaning up
> disks after VM's would probably fall more within Cybor's scope...
> 
> There's also the question of instance move operations like live and
> cold migrations - what happens to the passed-through disk in those
> cases? Does Nova have to copy it to the destination? I think those
> would be fairly easily addressable though (there are no major
> technical or political challenges, it's just a matter of someone
> writing the code and reviewing).
> 
> The disk cleanup thing is going to be harder, I suspect - more
> politically than technically. It's a bit of a chicken and egg problem
> with Nova and Cyborg, at the moment. Nova can refuse features as being
> out of scope and punt them to Cyborg, but I'm not sure how
> production-ready Cyborg is...
> 

Does the LVM pass through option help for direct attach of a local disk ?

https://cloudnull.io/2017/12/nova-lvm-an-iop-love-story/ <https://cloudnull.io/2017/12/nova-lvm-an-iop-love-story/>

Tim
> On Tue, Sep 1, 2020 at 10:41 AM Thomas Goirand <zigo at debian.org> wrote:
>> 
>> Hi Nova team!
>> 
>> tl;dr: we would like to contribute giving instances access to physical
>> block devices directly on the compute hosts. Would this be accepted?
>> 
>> Longer version:
>> 
>> About 3 or 4 years ago, someone wrote a spec, so we'd be able to provide
>> a local disk of a compute, directly to a VM to use. This was then
>> rejected, because at the time, Cinder had the blockdevice drive, which
>> was more or less achieving the same thing. Unfortunately, because nobody
>> was maintaining the blockdevice driver in Cinder, and because there was
>> no CI that could test it, the driver got removed.
>> 
>> We've investigated how we could otherwise implement it, and one solution
>> would be to use Cinder, but then we'd be going through an iSCSI export,
>> which would drastically reduce performances.
>> 
>> Another solution would be to manage KVM instances by hand, not touching
>> anything to libvirt and/or OpenVSwitch, but then we would loose the ease
>> of using the Nova API, so we would prefer to avoid this direction.
>> 
>> So we (ie: employees in my company) need to ask the Nova team: would you
>> consider a spec to do what was rejected before, since there's now no
>> other good enough alternative?
>> 
>> Our current goal is to be able to provide a disk directly to a VM, so
>> that we could build Ceph clusters with an hyper-converged model (ie:
>> storage hosted on the compute nodes). In this model, we wouldn't need
>> live-migration of a VM with an attached physical block device (though
>> the feature could be added on a later stage).
>> 
>> Before we start investigating how this can be done, I need to know if
>> this has at least some chances to be accepted or not. If there is, then
>> we'll probably start an experimental patch locally, then write a spec to
>> properly start this project. So please let us know.
>> 
>> Cheers,
>> 
>> Thomas Goirand (zigo)
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/bb242ee1/attachment.html>

From smooney at redhat.com  Tue Sep  1 18:30:20 2020
From: smooney at redhat.com (Sean Mooney)
Date: Tue, 01 Sep 2020 19:30:20 +0100
Subject: [nova] providing a local disk to a Nova instance
In-Reply-To: <D67DF24C-0D4C-4E22-9707-844DE0C9D963@cern.ch>
References: <c0d15c7d-1c4b-a0dd-3f5d-1ff501a58c0e@debian.org>
 <CACqyMifPge1yf0wD+y-1ch5B2H=0-ho4J6YJ6K6UO4rDi0c0aA@mail.gmail.com>
 <D67DF24C-0D4C-4E22-9707-844DE0C9D963@cern.ch>
Message-ID: <e407907b4f77e81519ecf52718865c3a4d986a2a.camel@redhat.com>

On Tue, 2020-09-01 at 19:47 +0200, Tim Bell wrote:
> > On 1 Sep 2020, at 17:15, Artom Lifshitz <alifshit at redhat.com> wrote:
> > 
> > IIUC one of our (Red Hat's) customer-facing folks brought us a similar
> > question recently. In their case they wanted to use PCI passthrough to
> > pass an NVMe disk to an instance. This is technically possible, but
> > there would be major privacy concerns in a multi-tenant cloud, as Nova
> > currently has no way of cleaning up a disk after a VM has left it, so
> > either the guest OS would have to do it itself, or any subsequent VM
> > using that disk would have access to all of the previous VM's data
> > (this could be mitigated by full-disk encryption, though). Cleaning up
> > disks after VM's would probably fall more within Cybor's scope...
> > 
> > There's also the question of instance move operations like live and
> > cold migrations - what happens to the passed-through disk in those
> > cases? Does Nova have to copy it to the destination? I think those
> > would be fairly easily addressable though (there are no major
> > technical or political challenges, it's just a matter of someone
> > writing the code and reviewing).
> > 
> > The disk cleanup thing is going to be harder, I suspect - more
> > politically than technically. It's a bit of a chicken and egg problem
> > with Nova and Cyborg, at the moment. Nova can refuse features as being
> > out of scope and punt them to Cyborg, but I'm not sure how
> > production-ready Cyborg is...
on the cyborg front i suggested adding a lvm driver to cyborg a few years ago for this usecase.
i wanted to use it for testing in the gate since it would require no hardware and also support "programming" by
copying a glance image to the volmen and cleaning by erasing the vloumne when the vm is deleted. it would solve the
local attach disk usecase too in a way. 1 by providing lvm volumes as disks to the guest and two by extending nova
to support host block devices form cybrog enabling other driver that for example just alloacted an entire blockdevci
instead of a volume to be written without needing nova changes.

but the production readyness was the catch 22 there. because it was not considered production ready i caned the idea
of an lvm driver because there was no path to deliverin gthis to customer downstream so i did not spend time working
on the idea. i still think its the right way to go but currently that is not aligned with the feature im working on.
> > 
> 
> Does the LVM pass through option help for direct attach of a local disk ?
> 
> https://cloudnull.io/2017/12/nova-lvm-an-iop-love-story/ <https://cloudnull.io/2017/12/nova-lvm-an-iop-love-story/>

not really since the lvm image backend for nova just use lvm volumns instead of the root/ephmeral disks in the flavor
its not actully providing a way to attach a local disk or partion so is not really the same usecase.

at least form a down stream peresective its also not supported in the redhat product.
from an upstream perfective it is not tested in the gate as far as i am aware so the maintance of that backend
is questionably although if we get bug reports wew will fix them but novas lvm backend is not really a solution here i
suspect.

that said it did in the past out perform the default flat/qcow backedn for write intensive workloads. not
sure if that has changed over time but there were pros and cons to it.
> 
> Tim
> > On Tue, Sep 1, 2020 at 10:41 AM Thomas Goirand <zigo at debian.org> wrote:
> > > 
> > > Hi Nova team!
> > > 
> > > tl;dr: we would like to contribute giving instances access to physical
> > > block devices directly on the compute hosts. Would this be accepted?
> > > 
> > > Longer version:
> > > 
> > > About 3 or 4 years ago, someone wrote a spec, so we'd be able to provide
> > > a local disk of a compute, directly to a VM to use. This was then
> > > rejected, because at the time, Cinder had the blockdevice drive, which
> > > was more or less achieving the same thing. Unfortunately, because nobody
> > > was maintaining the blockdevice driver in Cinder, and because there was
> > > no CI that could test it, the driver got removed.
> > > 
> > > We've investigated how we could otherwise implement it, and one solution
> > > would be to use Cinder, but then we'd be going through an iSCSI export,
> > > which would drastically reduce performances.
> > > 
> > > Another solution would be to manage KVM instances by hand, not touching
> > > anything to libvirt and/or OpenVSwitch, but then we would loose the ease
> > > of using the Nova API, so we would prefer to avoid this direction.
> > > 
> > > So we (ie: employees in my company) need to ask the Nova team: would you
> > > consider a spec to do what was rejected before, since there's now no
> > > other good enough alternative?
> > > 
> > > Our current goal is to be able to provide a disk directly to a VM, so
> > > that we could build Ceph clusters with an hyper-converged model (ie:
> > > storage hosted on the compute nodes). In this model, we wouldn't need
> > > live-migration of a VM with an attached physical block device (though
> > > the feature could be added on a later stage).
> > > 
> > > Before we start investigating how this can be done, I need to know if
> > > this has at least some chances to be accepted or not. If there is, then
> > > we'll probably start an experimental patch locally, then write a spec to
> > > properly start this project. So please let us know.
> > > 
> > > Cheers,
> > > 
> > > Thomas Goirand (zigo)
> > > 
> > 
> > 
> 
> 



From stig at stackhpc.com  Tue Sep  1 20:20:44 2020
From: stig at stackhpc.com (Stig Telfer)
Date: Tue, 1 Sep 2020 21:20:44 +0100
Subject: [scientific-sig] SIG Meeting: Ironic kexec, CANOPIE-HPC and the PTG
Message-ID: <E24244D3-CE79-4203-A766-7BAF76D698DD@telfer.org>

Hi All - 

We have a Scientific SIG meeting on IRC channel #openstack-meeting at 2100 UTC (about 45 minutes).  Everyone is welcome. 

Agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_September_1st_2020

Today we'd like to talk about supporting the development of kexec support for Ironic deployments.  Also some up-coming CFPs and PTG participation.

Cheers,
Stig



From kennelson11 at gmail.com  Tue Sep  1 21:34:37 2020
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Tue, 1 Sep 2020 14:34:37 -0700
Subject: [all][PTL][release] Victoria Cycle Highlights
Message-ID: <CAJ6yrQh1Sr_TS5_z1OhLt3tvXtPJ6Ubzy1pkAFJqVRbYc9wcVg@mail.gmail.com>

Hello Everyone!

It's time to start thinking about calling out 'cycle-highlights' in your
deliverables!

As PTLs, you probably get many pings and emails from various parties
(marketing, management, journalists, etc) asking for highlights of what is
new and what significant changes are coming in the new release. By putting
them all in the same place it makes them easy to reference because they get
compiled into a pretty website like this from the last few releases:
Rocky[1], Stein[2], Train[3], Ussuri[4].

As usual, we don't need a fully fledged marketing message, just a few
highlights
(3-4 ideally), from each project team. Looking through your release notes
is a good place to start.

*The deadline for cycle highlights is the end of the R-5 week [5] on Sept
11th.*

How To Reminder:
-------------------------

Simply add them to the deliverables/train/$PROJECT.yaml in the
openstack/releases repo like this:

   cycle-highlights:
     - Introduced new service to use unused host to mine bitcoin.

The formatting options for this tag are the same as what you are probably
used to with Reno release notes.

Also, you can check on the formatting of the output by either running
locally:

   tox -e docs

And then checking the resulting doc/build/html/train/highlights.html file
or the output of the build-openstack-sphinx-docs job under html/train/
highlights.html.

Can't wait to see what you've accomplished!

-Kendall Nelson (diablo_rojo)

[1] https://releases.openstack.org/rocky/highlights.html
[2] https://releases.openstack.org/stein/highlights.html
[3] https://releases.openstack.org/train/highlights.html
[4] https://releases.openstack.org/ussuri/highlights.html
[5] htt
<https://releases.openstack.org/train/schedule.html#t-cycle-highlights>
https://releases.openstack.org/victoria/schedule.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/70896e70/attachment.html>

From gouthampravi at gmail.com  Wed Sep  2 01:56:28 2020
From: gouthampravi at gmail.com (Goutham Pacha Ravi)
Date: Tue, 1 Sep 2020 17:56:28 -0800
Subject: Mentoring Boston University Students
In-Reply-To: <CAJ6yrQj40j2tAatjEQSmwJPRh5-TExK4eM3-c1tTpW9XiuNNvQ@mail.gmail.com>
References: <CAJ6yrQj40j2tAatjEQSmwJPRh5-TExK4eM3-c1tTpW9XiuNNvQ@mail.gmail.com>
Message-ID: <CAKSuTPbis1FSrvX+5Zty9P7j3YX56W3KmetNCkLpp56yBK1p=g@mail.gmail.com>

Hi Kendall,

We'd like to help and have help in the manila team. We have a few projects
[1] where the on-ramp may be relatively easy - I can work with you and
define them. How do we apply?

Thanks,
Goutham


[1] https://etherpad.opendev.org/p/manila-todos





On Tue, Sep 1, 2020 at 9:08 AM Kendall Nelson <kennelson11 at gmail.com> wrote:

> Hello!
>
> As you may or may not know, the last two years various community members
> have mentored students from North Dakota State University for a semester to
> work on projects in OpenStack. Recently, I learned of a similar program at
> Boston University and they are still looking for mentors interested for the
> upcoming semester.
>
> Essentially you would have 5 to 7 students for 13 weeks to mentor and work
> on some feature or effort in your project.
>
> The time to apply is running out however as the deadline is Sept 3rd. If
> you are interested, please let me know ASAP! I am happy to help get the
> students up to speed with the community and getting their workspaces set
> up, but the actual work they would do is more up to you :)
>
> -Kendall (diablo_rojo)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200901/cb6e8056/attachment.html>

From anilj.mailing at gmail.com  Wed Sep  2 07:12:33 2020
From: anilj.mailing at gmail.com (Anil Jangam)
Date: Wed, 2 Sep 2020 00:12:33 -0700
Subject: Graceful stopping of RabbitMQ AMQP notification listener
Message-ID: <CAHVD1iau+Wq7kqJuip8S5R3Zd2qMjpcQQiN-kYQzHY3jmmZa0Q@mail.gmail.com>

Hi,

I have coded OpenStack AMQP listener following the example and it is
working fine.
https://github.com/gibizer/nova-notification-demo/blob/master/ws_forwarder.py

The related code snippets of the NotificationHandler class are shown as
follows.

# Initialize the AMQP listener
def init(self, cluster_ip, user, password, port):
    cfg.CONF()
    cluster_url = "rabbit://" + user + ":" + password + "@" +
cluster_ip + ":" + port + "/"
    transport = oslo_messaging.get_notification_transport(cfg.CONF,
url=cluster_url)
    targets = [
        oslo_messaging.Target(topic='versioned_notifications'),
    ]
    endpoints = [self.__endpoint]

    # Initialize the notification listener
    try:
        self.__amqp_listener =
oslo_messaging.get_notification_listener(transport,
                                                                        targets,

 endpoints,

 executor='threading')
    except NotImplementedError as err:
        LOGGER.error("Failed to initialize the notification listener
{}".format(err))
        return False

    LOGGER.debug("Initialized the notification listener {}".format(cluster_url))
    return True

# Arm the compute event listeners
def start_amqp_event_listener(self):
    # Start the notification handler
    LOGGER.debug("Started the OpenStack notification handler")
    self.__amqp_listener.start()

# Disarm the compute event listeners
def stop_amqp_event_listener(self):
    LOGGER.debug("Stopping the OpenStack notification handler")
    if self.__amqp_listener is not None:
        self.__amqp_listener.stop()

I am using this interface from a new process handler function, however,
when I invoke the stop_amqp_eent_listener() method, my process hangs. It
does not terminate naturally.
I verified that the self.__amqp_listener.stop() function is not returning.
Is there anything missing in this code? Is there any specific consideration
when calling the listener from a new process?

Can someone provide a clue?

# Stop the worker
def stop(self):
    # Stop the AMQP notification handler
    self.__amqp_handler.stop_amqp_event_listener()
    LOGGER.debug("Stopped the worker for
{}".format(self.__ops_conn_info.cluster_ip))


/anil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/b72ae94a/attachment-0001.html>

From yongiman at gmail.com  Wed Sep  2 07:23:03 2020
From: yongiman at gmail.com (=?UTF-8?B?7ZWc7Iq57KeE?=)
Date: Wed, 2 Sep 2020 16:23:03 +0900
Subject: [ovn][neutron][ussuri] How to configure for overlay in DPDK with OVN ?
Message-ID: <CADeNzf8CCK1sp1KKZUuLkiikK=Wyxh2FAbBzBv_JGeUpG35iAA@mail.gmail.com>

Hi,


I’m trying to implement dpdk-ovs with ovn for our openstack environment.


I create a bond interface(tunbound) with ovs and tun0 and tun1 are slave
interfaces of the bond interface named tunbond.


    Bridge br-int

        fail_mode: secure

        datapath_type: netdev

        Port tunbond

            Interface tun0

                type: dpdk

                options: {dpdk-devargs="0000:1a:00.1", n_rxq="2"}

            Interface tun1

                type: dpdk

                options: {dpdk-devargs="0000:d8:00.1", n_rxq="2"}

        Port br-int

            Interface br-int

                type: internal

Now, I need to configure remote-ovn options to the ovs.


*I am confused how can I define the IP address of the bonded interface with
ovs?*


Theses are commands for connect remote ovn services.


ovs-vsctl set open . external-ids:ovn-remote=tcp:{controller ip}:6642

ovs-vsctl set open . external-ids:ovn-encap-type=geneve

*1*


This below command make it me confused.


ovs-vsctl set open . external-ids:ovn-encap-ip={local ip}


How should I resolve this issue?


Regards,


John Haan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/8c69a06d/attachment.html>

From yumeng_bao at yahoo.com  Wed Sep  2 07:30:10 2020
From: yumeng_bao at yahoo.com (yumeng bao)
Date: Wed, 2 Sep 2020 15:30:10 +0800
Subject: [ptg][cyborg] Cyborg Wallaby PTG schedule and resources
References: <3F9B2BCB-2C30-4FB0-BF15-F03FAA039827.ref@yahoo.com>
Message-ID: <3F9B2BCB-2C30-4FB0-BF15-F03FAA039827@yahoo.com>

Hi team,

The next virtual Wallaby PTG will be held next month from Oct 26 to Oct 30.

I have booked the same time slots in the ethercalc[0] as our last PTG did. However, these are not fixed, if the booked time does not suit your time, Please don't hesitate to add your availability to the doodle[1]. 

BTW, PTG Topics are open to collect and you can add to the etherpad[2]. 


[0]https://ethercalc.openstack.org/7xp2pcbh1ncb.
[1]https://doodle.com/poll/mrudbrn87vh48ayq
[2]https://etherpad.opendev.org/p/cyborg-wallaby-goals

Regards，
Yumeng


From feilong at catalyst.net.nz  Wed Sep  2 07:41:07 2020
From: feilong at catalyst.net.nz (feilong)
Date: Wed, 2 Sep 2020 19:41:07 +1200
Subject: Issue with heat and magnum
In-Reply-To: <08439410328b4d1ab7ca684d5af2c7c7@stfc.ac.uk>
References: <08439410328b4d1ab7ca684d5af2c7c7@stfc.ac.uk>
Message-ID: <241e821b-4072-e4b8-0ef3-fae4169977a4@catalyst.net.nz>

Hi Alexander,

Firstly, could you please help understand your Heat version and Magnum
version? Secondly, I don't really think it's related to Magnum. As long
as Heat API get the request from Magnum, Magnum conductor just query
Heat API to sync the status.


On 14/08/20 10:49 pm, Alexander Dibbo - UKRI STFC wrote:
>
> Hi,
>
>  
>
> I am having an issue with magnum creating clusters when I have
> multiple active heat-engine daemons running.
>
>  
>
> I get the following error in the heat engine logs:
>
> 2020-08-14 10:36:30.237 598383 INFO heat.engine.resource
> [req-a2c862eb-370c-4e91-a2c6-dca32c7872ce - - - - -] signal
> SoftwareDeployment "master_config_deployment" [67ba9ce2-aba5-4c15-a7ea
> -6b774659a0e2] Stack
> "kubernetes-test-26-3uzjqqob47fh-kube_masters-mhctjio2b4gh-0-pbhumflm5mn5"
> [dc66e4d9-0c9b-4b18-a2c6-dd9724fa51a9] : Authentication cannot be
> scoped to multiple target
> s. Pick one of: project, domain, trust or unscoped
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource Traceback
> (most recent call last):
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource   File
> "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 2462,
> in _handle_signal
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource    
> signal_result = self.handle_signal(details)
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource   File
> "/usr/lib/python2.7/site-packages/heat/engine/resources/openstack/heat/software_deployment.py",
> line 514, in handle_signal
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource    
> timeutils.utcnow().isoformat())
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource   File
> "/usr/lib/python2.7/site-packages/heat/rpc/client.py", line 788, in
> signal_software_deployment
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource
>     version='1.6')
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource   File
> "/usr/lib/python2.7/site-packages/heat/rpc/client.py", line 89, in call
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource     return
> client.call(ctxt, method, **kwargs)
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource   File
> "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line
> 165, in call
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource     msg_ctxt
> = self.serializer.serialize_context(ctxt)
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource   File
> "/usr/lib/python2.7/site-packages/heat/common/messaging.py", line 46,
> in serialize_context
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource     _context
> = ctxt.to_dict()
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource   File
> "/usr/lib/python2.7/site-packages/heat/common/context.py", line 185,
> in to_dict
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource     'roles':
> self.roles,
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource   File
> "/usr/lib/python2.7/site-packages/heat/common/context.py", line 315,
> in roles
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource    
> self._load_keystone_data()
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource   File
> "/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 292, in
> wrapped_f
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource     return
> self.call(f, *args, **kw)
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource   File
> "/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 358, in call
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource     do =
> self.iter(retry_state=retry_state)
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource   File
> "/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 319, in iter
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource     return
> fut.result()
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource   File
> "/usr/lib/python2.7/site-packages/concurrent/futures/_base.py", line
> 422, in result
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource     return
> self.__get_result()
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource   File
> "/usr/lib/python2.7/site-packages/tenacity/__init__.py", line 361, in call
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource     result =
> fn(*args, **kwargs)
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource   File
> "/usr/lib/python2.7/site-packages/heat/common/context.py", line 306,
> in _load_keystone_data
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource     auth_ref
> = self.auth_plugin.get_access(self.keystone_session)
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource   File
> "/usr/lib/python2.7/site-packages/keystoneauth1/identity/base.py",
> line 134, in get_access
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource    
> self.auth_ref = self.get_auth_ref(session)
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource   File
> "/usr/lib/python2.7/site-packages/keystoneauth1/identity/generic/base.py",
> line 208, in get_auth_ref
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource     return
> self._plugin.get_auth_ref(session, **kwargs)
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource   File
> "/usr/lib/python2.7/site-packages/keystoneauth1/identity/v3/base.py",
> line 144, in get_auth_ref
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource    
> message='Authentication cannot be scoped to multiple'
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource
> AuthorizationFailure: Authentication cannot be scoped to multiple
> targets. Pick one of: project, domain, trust or unscoped
> 2020-08-14 10:36:30.237 598383 ERROR heat.engine.resource
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service
> [req-a2c862eb-370c-4e91-a2c6-dca32c7872ce - - - - -] Unhandled error
> in asynchronous task: ResourceFailure: AuthorizationFailure:
> resources.master_config_deployment: Authentication cannot be scoped to
> multiple targets. Pick one of: project, domain, trust or unscoped
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service Traceback
> (most recent call last):
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service   File
> "/usr/lib/python2.7/site-packages/heat/engine/service.py", line 132,
> in log_exceptions
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service     gt.wait()
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service   File
> "/usr/lib/python2.7/site-packages/eventlet/greenthread.py", line 181,
> in wait
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service     return
> self._exit_event.wait()
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service   File
> "/usr/lib/python2.7/site-packages/eventlet/event.py", line 132, in wait
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service    
> current.throw(*self._exc)
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service   File
> "/usr/lib/python2.7/site-packages/eventlet/greenthread.py", line 221,
> in main
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service     result =
> function(*args, **kwargs)
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service   File
> "/usr/lib/python2.7/site-packages/heat/engine/service.py", line 123,
> in _start_with_trace
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service     return
> func(*args, **kwargs)
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service   File
> "/usr/lib/python2.7/site-packages/heat/engine/service.py", line 1871,
> in _resource_signal
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service    
> needs_metadata_updates = rsrc.signal(details, need_check)
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service   File
> "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 2500,
> in signal
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service    
> self._handle_signal(details)
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service   File
> "/usr/lib/python2.7/site-packages/heat/engine/resource.py", line 2480,
> in _handle_signal
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service     raise failure
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service
> ResourceFailure: AuthorizationFailure:
> resources.master_config_deployment: Authentication cannot be scoped to
> multiple targets. Pi
> ck one of: project, domain, trust or unscoped
> 2020-08-14 10:36:30.890 598383 ERROR heat.engine.service
>
>  
>
> Each of the individual heat-engine daemons create magnum clusters
> correctly when they are the only ones online.
>
>  
>
> Attached are the heat and magnum config files.
>
>  
>
> Any ideas where to look would be appreciated?
>
>  
>
>  
>
> Regards
>
>  
>
> Alexander Dibbo – Cloud Architect / Cloud Operations Group Leader
>
> For STFC Cloud Documentation visit
> https://stfc-cloud-docs.readthedocs.io
> <https://stfc-cloud-docs.readthedocs.io/>
>
> To raise a support ticket with the cloud team please email
> cloud-support at gridpp.rl.ac.uk <mailto:cloud-support at gridpp.rl.ac.uk>
>
> To receive notifications about the service please subscribe to our
> mailing list at: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=STFC-CLOUD
>
> To receive fast notifications or to discuss usage of the cloud please
> join our Slack: https://stfc-cloud.slack.com/
>
>  
>
> This email and any attachments are intended solely for the use of the
> named recipients. If you are not the intended recipient you must not
> use, disclose, copy or distribute this email or any of its attachments
> and should notify the sender immediately and delete this email from
> your system. UK Research and Innovation (UKRI) has taken every
> reasonable precaution to minimise risk of this email or any
> attachments containing viruses or malware but the recipient should
> carry out its own virus and malware checks before opening the
> attachments. UKRI does not accept any liability for any losses or
> damages which the recipient may sustain due to presence of any
> viruses. Opinions, conclusions or other information in this message
> and attachments that are not related directly to UKRI business are
> solely those of the author and do not represent the views of UKRI.
>
-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
------------------------------------------------------ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/ccf9084e/attachment-0001.html>

From feilong at catalyst.net.nz  Wed Sep  2 07:44:01 2020
From: feilong at catalyst.net.nz (feilong)
Date: Wed, 2 Sep 2020 19:44:01 +1200
Subject: [Magnum][Kayobe] Magnum Kubernetes clusters failing to be created
 (bugs?)
In-Reply-To: <CAK1+d=5Gu51t3FDt3htxhZdKf6Uhg26V3VBt5ckp9OR1v8Gktw@mail.gmail.com>
References: <CAK1+d=5Gu51t3FDt3htxhZdKf6Uhg26V3VBt5ckp9OR1v8Gktw@mail.gmail.com>
Message-ID: <2b199738-2fe4-631b-6f4e-4050d040abed@catalyst.net.nz>

Hi Tony,

My comments about your two issues:

1. I'm not sure it's a Magnum issue. Did you try to draft a simple Heat
template to use that flavor and same image to create instance? Does it work?

2. When you say "resize cluster" failed, what's the error you got from
magnum conductor log?


On 1/09/20 9:22 pm, Tony Pearce wrote:
> Hi guys, I hope you are all keeping safe and well at the moment. 
>
> I am trying to launch Kubernetes clusters into Openstack Train which
> has been deployed via Kayobe (Kayobe as I understand is a wrapper for
> kolla-ansible). There have been a few strange issues here and I've
> struggled to isolate them. These issues started recently after a fresh
> Openstack deployment some months ago (around February 2020) to give
> some context. This Openstack is not "live" as I've been trying to get
> to the bottom of the issues:
>
> Issue 1. When trying to launch a cluster we get error "Resource Create
> Failed: Forbidden: Resources.Kube
> Masters.Resources[0].Resources.Kube-Master: Only Volume-Backed Servers
> Are Allowed For Flavors With Zero Disk. "
>
> Issue 2. After successfully creating a cluster of a smaller node size,
> the "resize cluster" is failing (however update the cluster is working). 
>
> Some background on this specific environment: 
> Deployed via Kayobe, with these components: 
> Cinder, Designate, iscsid, Magnum, Multipathd, neutron provider networks
>
> The Cinder component integrates with iSCSI SAN storage using the
> Nimble driver. This is the only storage. In order to prevent Openstack
> from allocating Compute node local HDD as instance storage, I have all
> flavours configured with root disk / ephemeral disk / swap disk =
> "0MB". This then results in all instance data being stored on the
> backend Cinder storage appliance. 
>
> I was able to get a cluster deployed by first creating the template as
> needed, then when launching the cluster Horizon prompts you for items
> already there in the template such as number of nodes, node flavour
> and labels etc. I re-supplied all of the info (as to duplicate it) and
> then tried creating the cluster. After many many times trying over the
> course of a few weeks to a few months it was successful. I was then
> able to work around the issue #2 above to get it increased in size. 
>
> When looking at the logs for issue #2, it looks like some content is
> missing in the API but I am not certain. I will include a link to the
> pastebin below [1]. 
> When trying to resize the cluster, Horizon gives error: "Error: Unable
> to resize given cluster id: 99693dbf-160a-40e0-9ed4-93f3370367ee". I
> then searched the controller node /var/log directory for this ID and
> found "horizon.log  [:error] [pid 25] Not Found:
> /api/container_infra/clusters/99693dbf-160a-40e0-9ed4-93f3370367ee/resize". 
> Going to the Horizon menu "update cluster" allows you to increase the
> number of nodes and then save/apply the config which does indeed
> resize the cluster. 
>
>
>
> Regarding issue #1, we've been unable to deploy a cluster in a new
> project and the error is hinting it relates to the flavours having 0MB
> disk specified, though this error is new and we've been successful
> previously with deploying clusters (albeit with the hit-and-miss
> experiences) using the flavour with 0MB disk as described above. Again
> I searched for the (stack) ID after the failure, in the logs on the
> controller and I obtained not much more than the error already seen
> with Horizon [2]. 
>
> I was able to create new flavours with root disk = 15GB and then
> successfully deploy a cluster on the next immediate try. Update
> cluster from 3 nodes to 6 nodes was also immediately successful.
> However I see the compute nodes "used" disk space increasing after
> increasing the cluster size which is an issue as the compute node has
> very limited HDD capacity (32GB SD card). 
>
> At this point I also checked 1) previously installed cluster using the
> 0MB disk flavour and 2) new instances using the 0MB disk flavour. I
> notice that the previous cluster is having host storage allocated but
> while the new instance is not having host storage allocated. So the
> cluster create success is using flavour with disk = 0MB while the
> result is compute HDD storage being consumed.  
>
> So with the above, please may I clarify on the following? 
> 1. It seems that 0MB disk flavours may not be supported with magnum
> now? Could the experts confirm? :) Is there another way that I should
> be configuring this so that compute node disk is not being consumed
> (because it is slow and has limited capacity). 
> 2. The issue #1 looks like a bug to me, is it known? If not, is this
> mail enough to get it realised? 
>
> Pastebin links as mentioned 
> [1] http://paste.openstack.org/show/797316/
>
> [2] http://paste.openstack.org/show/797318/
>
>
> Many thanks,
>
> Regards,
>
>
> Tony Pearce
>
-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
------------------------------------------------------ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/7fe84198/attachment.html>

From tonyppe at gmail.com  Wed Sep  2 08:12:05 2020
From: tonyppe at gmail.com (Tony Pearce)
Date: Wed, 2 Sep 2020 16:12:05 +0800
Subject: [Magnum][Kayobe] Magnum Kubernetes clusters failing to be created
 (bugs?)
In-Reply-To: <2b199738-2fe4-631b-6f4e-4050d040abed@catalyst.net.nz>
References: <CAK1+d=5Gu51t3FDt3htxhZdKf6Uhg26V3VBt5ckp9OR1v8Gktw@mail.gmail.com>
 <2b199738-2fe4-631b-6f4e-4050d040abed@catalyst.net.nz>
Message-ID: <CAK1+d=5UjrMeU=HTKOakpQjfH2Xj8oVr6AyFGxj0exNP-aYiMw@mail.gmail.com>

Hi Feilong, thank you for replying to my message.

"1. I'm not sure it's a Magnum issue. Did you try to draft a simple Heat
template to use that flavor and same image to create instance? Does it
work?"

No I didn't try it and dont think that I know enough about it to try. I am
using Magnum which in turn signals Heat but I've never used Heat directly.
When I use the new flavour with root disk = 15GB then I dont have any issue
with launching the cluster. But I have a future issue of consuming all
available disk space on the compute node.

"2. When you say "resize cluster" failed, what's the error you got from
magnum conductor log?"

I did not see any error in conductor log. Only the Magnum API and Horizon
log as mentioned. It looks like horizon was calling bad URLs so maybe this
is the reason why there was no conductor log? Just to mention again though,
that "update cluster" option is working fine to increase the size of the
cluster.

However my main issue here is with regards to the flavour being used. Can
you or anyone confirm about the root disk = 0MB?
OR can you or anyone share any information about how to utilise
Magnum/Kubernetes without consuming Compute node HDD storage? I've been
unable to achieve this and the docs do not give any information about this
specifically (unless of course I have missed it?). The documentation says I
can use any flavour [1].

[1] https://docs.openstack.org/magnum/latest/user/

Regards,

Tony Pearce


On Wed, 2 Sep 2020 at 15:44, feilong <feilong at catalyst.net.nz> wrote:

> Hi Tony,
>
> My comments about your two issues:
>
> 1. I'm not sure it's a Magnum issue. Did you try to draft a simple Heat
> template to use that flavor and same image to create instance? Does it work?
>
> 2. When you say "resize cluster" failed, what's the error you got from
> magnum conductor log?
>
>
> On 1/09/20 9:22 pm, Tony Pearce wrote:
>
> Hi guys, I hope you are all keeping safe and well at the moment.
>
> I am trying to launch Kubernetes clusters into Openstack Train which has
> been deployed via Kayobe (Kayobe as I understand is a wrapper for
> kolla-ansible). There have been a few strange issues here and I've
> struggled to isolate them. These issues started recently after a fresh
> Openstack deployment some months ago (around February 2020) to give some
> context. This Openstack is not "live" as I've been trying to get to the
> bottom of the issues:
>
> Issue 1. When trying to launch a cluster we get error "Resource Create
> Failed: Forbidden: Resources.Kube
> Masters.Resources[0].Resources.Kube-Master: Only Volume-Backed Servers Are
> Allowed For Flavors With Zero Disk. "
>
> Issue 2. After successfully creating a cluster of a smaller node size, the
> "resize cluster" is failing (however update the cluster is working).
>
> Some background on this specific environment:
> Deployed via Kayobe, with these components:
> Cinder, Designate, iscsid, Magnum, Multipathd, neutron provider networks
>
> The Cinder component integrates with iSCSI SAN storage using the Nimble
> driver. This is the only storage. In order to prevent Openstack from
> allocating Compute node local HDD as instance storage, I have all flavours
> configured with root disk / ephemeral disk / swap disk = "0MB". This then
> results in all instance data being stored on the backend Cinder storage
> appliance.
>
> I was able to get a cluster deployed by first creating the template as
> needed, then when launching the cluster Horizon prompts you for items
> already there in the template such as number of nodes, node flavour and
> labels etc. I re-supplied all of the info (as to duplicate it) and then
> tried creating the cluster. After many many times trying over the course of
> a few weeks to a few months it was successful. I was then able to work
> around the issue #2 above to get it increased in size.
>
> When looking at the logs for issue #2, it looks like some content is
> missing in the API but I am not certain. I will include a link to the
> pastebin below [1].
> When trying to resize the cluster, Horizon gives error: "Error: Unable to
> resize given cluster id: 99693dbf-160a-40e0-9ed4-93f3370367ee". I then
> searched the controller node /var/log directory for this ID and found
> "horizon.log  [:error] [pid 25] Not Found:
> /api/container_infra/clusters/99693dbf-160a-40e0-9ed4-93f3370367ee/resize".
> Going to the Horizon menu "update cluster" allows you to increase the
> number of nodes and then save/apply the config which does indeed resize the
> cluster.
>
>
>
> Regarding issue #1, we've been unable to deploy a cluster in a new project
> and the error is hinting it relates to the flavours having 0MB disk
> specified, though this error is new and we've been successful previously
> with deploying clusters (albeit with the hit-and-miss experiences) using
> the flavour with 0MB disk as described above. Again I searched for the
> (stack) ID after the failure, in the logs on the controller and I obtained
> not much more than the error already seen with Horizon [2].
>
> I was able to create new flavours with root disk = 15GB and then
> successfully deploy a cluster on the next immediate try. Update cluster
> from 3 nodes to 6 nodes was also immediately successful. However I see the
> compute nodes "used" disk space increasing after increasing the cluster
> size which is an issue as the compute node has very limited HDD capacity
> (32GB SD card).
>
> At this point I also checked 1) previously installed cluster using the 0MB
> disk flavour and 2) new instances using the 0MB disk flavour. I notice that
> the previous cluster is having host storage allocated but while the new
> instance is not having host storage allocated. So the cluster create
> success is using flavour with disk = 0MB while the result is compute HDD
> storage being consumed.
>
> So with the above, please may I clarify on the following?
> 1. It seems that 0MB disk flavours may not be supported with magnum now?
> Could the experts confirm? :) Is there another way that I should be
> configuring this so that compute node disk is not being consumed (because
> it is slow and has limited capacity).
> 2. The issue #1 looks like a bug to me, is it known? If not, is this mail
> enough to get it realised?
>
> Pastebin links as mentioned
> [1] http://paste.openstack.org/show/797316/
>
> [2] http://paste.openstack.org/show/797318/
>
>
> Many thanks,
>
> Regards,
>
>
> Tony Pearce
>
> --
> Cheers & Best regards,
> Feilong Wang (王飞龙)
> ------------------------------------------------------
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flwang at catalyst.net.nz
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> ------------------------------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/adbee3c7/attachment-0001.html>

From akekane at redhat.com  Wed Sep  2 08:12:21 2020
From: akekane at redhat.com (Abhishek Kekane)
Date: Wed, 2 Sep 2020 13:42:21 +0530
Subject: [ptg][glance] Wallaby PTG planning etherpad
Message-ID: <CALOt+STybhkfQ_AaZA6GfWFiecxdCNWW2gT+mQYaQnt4CK3=qQ@mail.gmail.com>

Hi All,

The Wallaby PTG will be held next month from Oct 26 to Oct 30.

I have booked some time slots in the ethercalc[0], however these are not
fixed, if the booked time does not suit your time, please let me know. I
have also created a planning etherpad [1] where you can add your topics for
discussion during PTG.


[0]https://ethercalc.openstack.org/7xp2pcbh1ncb.
[1] https://etherpad.opendev.org/p/Glance-Wallaby-PTG-planning

Thank you,

Abhishek Kekane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/8dda4461/attachment.html>

From feilong at catalyst.net.nz  Wed Sep  2 08:53:59 2020
From: feilong at catalyst.net.nz (feilong)
Date: Wed, 2 Sep 2020 20:53:59 +1200
Subject: [Magnum][Kayobe] Magnum Kubernetes clusters failing to be created
 (bugs?)
In-Reply-To: <CAK1+d=5UjrMeU=HTKOakpQjfH2Xj8oVr6AyFGxj0exNP-aYiMw@mail.gmail.com>
References: <CAK1+d=5Gu51t3FDt3htxhZdKf6Uhg26V3VBt5ckp9OR1v8Gktw@mail.gmail.com>
 <2b199738-2fe4-631b-6f4e-4050d040abed@catalyst.net.nz>
 <CAK1+d=5UjrMeU=HTKOakpQjfH2Xj8oVr6AyFGxj0exNP-aYiMw@mail.gmail.com>
Message-ID: <faadfc73-47e4-d9af-a428-b83ac0e94aff@catalyst.net.nz>

Hi Tony,

Let me answer #2 first. Did you try to use CLI? Please make sure using
the latest python-magnumclient version. It should work. As for the
dashboard issue, please try to use the latest version of magnum-ui. I
encourage using resize because the node update is not recommended to use.

As for #1, I probably missed something. If the root disk=0MB, where the
will operating system be installed? It would be nice if you can share
your original requirement to help me understand the issue. e.g why do
you have concern the node disk being used?


On 2/09/20 8:12 pm, Tony Pearce wrote:
> Hi Feilong, thank you for replying to my message.
>
> "1. I'm not sure it's a Magnum issue. Did you try to draft a simple
> Heat template to use that flavor and same image to create instance?
> Does it work?"
>
> No I didn't try it and dont think that I know enough about it to try.
> I am using Magnum which in turn signals Heat but I've never used Heat
> directly. When I use the new flavour with root disk = 15GB then I dont
> have any issue with launching the cluster. But I have a future issue
> of consuming all available disk space on the compute node.
>
> "2. When you say "resize cluster" failed, what's the error you got
> from magnum conductor log?"
>
> I did not see any error in conductor log. Only the Magnum API and
> Horizon log as mentioned. It looks like horizon was calling bad URLs
> so maybe this is the reason why there was no conductor log? Just to
> mention again though, that "update cluster" option is working fine to
> increase the size of the cluster.
>
> However my main issue here is with regards to the flavour being used.
> Can you or anyone confirm about the root disk = 0MB? 
> OR can you or anyone share any information about how to utilise
> Magnum/Kubernetes without consuming Compute node HDD storage? I've
> been unable to achieve this and the docs do not give any information
> about this specifically (unless of course I have missed it?). The
> documentation says I can use any flavour [1].
>
> [1] https://docs.openstack.org/magnum/latest/user/  
>
> Regards, 
>
> Tony Pearce
>
>
> On Wed, 2 Sep 2020 at 15:44, feilong <feilong at catalyst.net.nz
> <mailto:feilong at catalyst.net.nz>> wrote:
>
>     Hi Tony,
>
>     My comments about your two issues:
>
>     1. I'm not sure it's a Magnum issue. Did you try to draft a simple
>     Heat template to use that flavor and same image to create
>     instance? Does it work?
>
>     2. When you say "resize cluster" failed, what's the error you got
>     from magnum conductor log?
>
>
>     On 1/09/20 9:22 pm, Tony Pearce wrote:
>>     Hi guys, I hope you are all keeping safe and well at the moment. 
>>
>>     I am trying to launch Kubernetes clusters into Openstack Train
>>     which has been deployed via Kayobe (Kayobe as I understand is a
>>     wrapper for kolla-ansible). There have been a few strange issues
>>     here and I've struggled to isolate them. These issues started
>>     recently after a fresh Openstack deployment some months ago
>>     (around February 2020) to give some context. This Openstack is
>>     not "live" as I've been trying to get to the bottom of the issues:
>>
>>     Issue 1. When trying to launch a cluster we get error "Resource
>>     Create Failed: Forbidden: Resources.Kube
>>     Masters.Resources[0].Resources.Kube-Master: Only Volume-Backed
>>     Servers Are Allowed For Flavors With Zero Disk. "
>>
>>     Issue 2. After successfully creating a cluster of a smaller node
>>     size, the "resize cluster" is failing (however update the cluster
>>     is working). 
>>
>>     Some background on this specific environment: 
>>     Deployed via Kayobe, with these components: 
>>     Cinder, Designate, iscsid, Magnum, Multipathd, neutron provider
>>     networks
>>
>>     The Cinder component integrates with iSCSI SAN storage using the
>>     Nimble driver. This is the only storage. In order to prevent
>>     Openstack from allocating Compute node local HDD as instance
>>     storage, I have all flavours configured with root disk /
>>     ephemeral disk / swap disk = "0MB". This then results in all
>>     instance data being stored on the backend Cinder storage appliance. 
>>
>>     I was able to get a cluster deployed by first creating the
>>     template as needed, then when launching the cluster Horizon
>>     prompts you for items already there in the template such as
>>     number of nodes, node flavour and labels etc. I re-supplied all
>>     of the info (as to duplicate it) and then tried creating the
>>     cluster. After many many times trying over the course of a few
>>     weeks to a few months it was successful. I was then able to work
>>     around the issue #2 above to get it increased in size. 
>>
>>     When looking at the logs for issue #2, it looks like some content
>>     is missing in the API but I am not certain. I will include a link
>>     to the pastebin below [1]. 
>>     When trying to resize the cluster, Horizon gives error: "Error:
>>     Unable to resize given cluster id:
>>     99693dbf-160a-40e0-9ed4-93f3370367ee". I then searched the
>>     controller node /var/log directory for this ID and found
>>     "horizon.log  [:error] [pid 25] Not Found:
>>     /api/container_infra/clusters/99693dbf-160a-40e0-9ed4-93f3370367ee/resize". 
>>     Going to the Horizon menu "update cluster" allows you to increase
>>     the number of nodes and then save/apply the config which does
>>     indeed resize the cluster. 
>>
>>
>>
>>     Regarding issue #1, we've been unable to deploy a cluster in a
>>     new project and the error is hinting it relates to the flavours
>>     having 0MB disk specified, though this error is new and we've
>>     been successful previously with deploying clusters (albeit with
>>     the hit-and-miss experiences) using the flavour with 0MB disk as
>>     described above. Again I searched for the (stack) ID after the
>>     failure, in the logs on the controller and I obtained not much
>>     more than the error already seen with Horizon [2]. 
>>
>>     I was able to create new flavours with root disk = 15GB and then
>>     successfully deploy a cluster on the next immediate try. Update
>>     cluster from 3 nodes to 6 nodes was also immediately successful.
>>     However I see the compute nodes "used" disk space increasing
>>     after increasing the cluster size which is an issue as the
>>     compute node has very limited HDD capacity (32GB SD card). 
>>
>>     At this point I also checked 1) previously installed cluster
>>     using the 0MB disk flavour and 2) new instances using the 0MB
>>     disk flavour. I notice that the previous cluster is having host
>>     storage allocated but while the new instance is not having host
>>     storage allocated. So the cluster create success is using flavour
>>     with disk = 0MB while the result is compute HDD storage being
>>     consumed.  
>>
>>     So with the above, please may I clarify on the following? 
>>     1. It seems that 0MB disk flavours may not be supported with
>>     magnum now? Could the experts confirm? :) Is there another way
>>     that I should be configuring this so that compute node disk is
>>     not being consumed (because it is slow and has limited capacity). 
>>     2. The issue #1 looks like a bug to me, is it known? If not, is
>>     this mail enough to get it realised? 
>>
>>     Pastebin links as mentioned 
>>     [1] http://paste.openstack.org/show/797316/
>>
>>     [2] http://paste.openstack.org/show/797318/
>>
>>
>>     Many thanks,
>>
>>     Regards,
>>
>>
>>     Tony Pearce
>>
>     -- 
>     Cheers & Best regards,
>     Feilong Wang (王飞龙)
>     ------------------------------------------------------
>     Senior Cloud Software Engineer
>     Tel: +64-48032246
>     Email: flwang at catalyst.net.nz <mailto:flwang at catalyst.net.nz>
>     Catalyst IT Limited
>     Level 6, Catalyst House, 150 Willis Street, Wellington
>     ------------------------------------------------------ 
>
-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
------------------------------------------------------ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/7b97b7af/attachment-0001.html>

From tonyppe at gmail.com  Wed Sep  2 09:17:06 2020
From: tonyppe at gmail.com (Tony Pearce)
Date: Wed, 2 Sep 2020 17:17:06 +0800
Subject: [Magnum][Kayobe] Magnum Kubernetes clusters failing to be created
 (bugs?)
In-Reply-To: <faadfc73-47e4-d9af-a428-b83ac0e94aff@catalyst.net.nz>
References: <CAK1+d=5Gu51t3FDt3htxhZdKf6Uhg26V3VBt5ckp9OR1v8Gktw@mail.gmail.com>
 <2b199738-2fe4-631b-6f4e-4050d040abed@catalyst.net.nz>
 <CAK1+d=5UjrMeU=HTKOakpQjfH2Xj8oVr6AyFGxj0exNP-aYiMw@mail.gmail.com>
 <faadfc73-47e4-d9af-a428-b83ac0e94aff@catalyst.net.nz>
Message-ID: <CAK1+d=6V7czZ85h2DObREYBZGqZ4EL+B_WVY28t4QCHK2jHz4g@mail.gmail.com>

Hi Feilong,

"Let me answer #2 first. Did you try to use CLI? Please make sure using the
latest python-magnumclient version. It should work. As for the dashboard
issue, please try to use the latest version of magnum-ui. I encourage using
resize because the node update is not recommended to use."

I did not attempt the resize via CLI but I can try it. Thank you for your
guidance on this :)

"As for #1, I probably missed something. If the root disk=0MB, where the
will operating system be installed? t would be nice if you can share your
original requirement to help me understand the issue. e.g why do you have
concern the node disk being used?"

Sure, although I'd like to understand why you have no concern that the node
disk is being used :) I may be missing something here...

In this environment I have this setup:
controller node
compute node
network storage appliance, integrated with Cinder iscsi.

All VM/Instance data needs to be on the network storage appliance for the
reasons;
- it's faster than node storage (Flash storage backed array of disks,
provides write-cache and read-cache)
- resilience built into the array
- has much higher storage capacity
- is designed for multi-access (ie many connections from hosts)

There are other reasons as well, such as deploying compute nodes as
disposable services. Example, a compute node dies resulting in a new node
being deployed. Instances are not locked to any node and can be started
again on other nodes.

Going back to 2016 when I deployed Openstack Pike, when running
post-deployment tests I noticed that the node storage was being consumed
even though I have this network storage array. I done some research online
and came to the understanding that the reason was the flavors having "root
disk" (and swap) having some positive value other than 0MB. So since 2016 I
have been using all flavors with disk = 0MB to force the network storage to
be used for instance disks and storage. This is working since 2016 Pike,
Queens and Train for launching instances (but not Magnum).
The requirement is to utilise network storage (not node storage) - is there
some other way that this is achieved today?

I dont understand the point of shared storage options in Openstack if node
storage is being consumed for instances.  Could you help me understand if
this specific environment is just not considered by the Openstack devs? Or
some other reason unknown to me?
For example, in my (limited) experience with other Virtualisation systems
(vmware, ovirt for example) they avoid consuming compute storage for a
number of similar reasons to mine.

So to summarise on this one, I'm not stating that "I am right" here but I
am politely asking for more info on the same so I can better understand
what I am possibly doing wrong with this deployment or other reasons.

Lastly thank you again for your time to reply to me, I really appreciate
this.

Regards,


Tony Pearce


On Wed, 2 Sep 2020 at 16:54, feilong <feilong at catalyst.net.nz> wrote:

> Hi Tony,
>
> Let me answer #2 first. Did you try to use CLI? Please make sure using the
> latest python-magnumclient version. It should work. As for the dashboard
> issue, please try to use the latest version of magnum-ui. I encourage using
> resize because the node update is not recommended to use.
>
> As for #1, I probably missed something. If the root disk=0MB, where the
> will operating system be installed? It would be nice if you can share your
> original requirement to help me understand the issue. e.g why do you have
> concern the node disk being used?
>
>
> On 2/09/20 8:12 pm, Tony Pearce wrote:
>
> Hi Feilong, thank you for replying to my message.
>
> "1. I'm not sure it's a Magnum issue. Did you try to draft a simple Heat
> template to use that flavor and same image to create instance? Does it
> work?"
>
> No I didn't try it and dont think that I know enough about it to try. I am
> using Magnum which in turn signals Heat but I've never used Heat directly.
> When I use the new flavour with root disk = 15GB then I dont have any issue
> with launching the cluster. But I have a future issue of consuming all
> available disk space on the compute node.
>
> "2. When you say "resize cluster" failed, what's the error you got from
> magnum conductor log?"
>
> I did not see any error in conductor log. Only the Magnum API and Horizon
> log as mentioned. It looks like horizon was calling bad URLs so maybe this
> is the reason why there was no conductor log? Just to mention again though,
> that "update cluster" option is working fine to increase the size of the
> cluster.
>
> However my main issue here is with regards to the flavour being used. Can
> you or anyone confirm about the root disk = 0MB?
> OR can you or anyone share any information about how to utilise
> Magnum/Kubernetes without consuming Compute node HDD storage? I've been
> unable to achieve this and the docs do not give any information about this
> specifically (unless of course I have missed it?). The documentation says
> I can use any flavour [1].
>
> [1] https://docs.openstack.org/magnum/latest/user/
>
> Regards,
>
> Tony Pearce
>
>
> On Wed, 2 Sep 2020 at 15:44, feilong <feilong at catalyst.net.nz> wrote:
>
>> Hi Tony,
>>
>> My comments about your two issues:
>>
>> 1. I'm not sure it's a Magnum issue. Did you try to draft a simple Heat
>> template to use that flavor and same image to create instance? Does it work?
>>
>> 2. When you say "resize cluster" failed, what's the error you got from
>> magnum conductor log?
>>
>>
>> On 1/09/20 9:22 pm, Tony Pearce wrote:
>>
>> Hi guys, I hope you are all keeping safe and well at the moment.
>>
>> I am trying to launch Kubernetes clusters into Openstack Train which has
>> been deployed via Kayobe (Kayobe as I understand is a wrapper for
>> kolla-ansible). There have been a few strange issues here and I've
>> struggled to isolate them. These issues started recently after a fresh
>> Openstack deployment some months ago (around February 2020) to give some
>> context. This Openstack is not "live" as I've been trying to get to the
>> bottom of the issues:
>>
>> Issue 1. When trying to launch a cluster we get error "Resource Create
>> Failed: Forbidden: Resources.Kube
>> Masters.Resources[0].Resources.Kube-Master: Only Volume-Backed Servers Are
>> Allowed For Flavors With Zero Disk. "
>>
>> Issue 2. After successfully creating a cluster of a smaller node size,
>> the "resize cluster" is failing (however update the cluster is working).
>>
>> Some background on this specific environment:
>> Deployed via Kayobe, with these components:
>> Cinder, Designate, iscsid, Magnum, Multipathd, neutron provider networks
>>
>> The Cinder component integrates with iSCSI SAN storage using the Nimble
>> driver. This is the only storage. In order to prevent Openstack from
>> allocating Compute node local HDD as instance storage, I have all flavours
>> configured with root disk / ephemeral disk / swap disk = "0MB". This then
>> results in all instance data being stored on the backend Cinder storage
>> appliance.
>>
>> I was able to get a cluster deployed by first creating the template as
>> needed, then when launching the cluster Horizon prompts you for items
>> already there in the template such as number of nodes, node flavour and
>> labels etc. I re-supplied all of the info (as to duplicate it) and then
>> tried creating the cluster. After many many times trying over the course of
>> a few weeks to a few months it was successful. I was then able to work
>> around the issue #2 above to get it increased in size.
>>
>> When looking at the logs for issue #2, it looks like some content is
>> missing in the API but I am not certain. I will include a link to the
>> pastebin below [1].
>> When trying to resize the cluster, Horizon gives error: "Error: Unable to
>> resize given cluster id: 99693dbf-160a-40e0-9ed4-93f3370367ee". I then
>> searched the controller node /var/log directory for this ID and found
>> "horizon.log  [:error] [pid 25] Not Found:
>> /api/container_infra/clusters/99693dbf-160a-40e0-9ed4-93f3370367ee/resize".
>> Going to the Horizon menu "update cluster" allows you to increase the
>> number of nodes and then save/apply the config which does indeed resize the
>> cluster.
>>
>>
>>
>> Regarding issue #1, we've been unable to deploy a cluster in a new
>> project and the error is hinting it relates to the flavours having 0MB disk
>> specified, though this error is new and we've been successful previously
>> with deploying clusters (albeit with the hit-and-miss experiences) using
>> the flavour with 0MB disk as described above. Again I searched for the
>> (stack) ID after the failure, in the logs on the controller and I obtained
>> not much more than the error already seen with Horizon [2].
>>
>> I was able to create new flavours with root disk = 15GB and then
>> successfully deploy a cluster on the next immediate try. Update cluster
>> from 3 nodes to 6 nodes was also immediately successful. However I see the
>> compute nodes "used" disk space increasing after increasing the cluster
>> size which is an issue as the compute node has very limited HDD capacity
>> (32GB SD card).
>>
>> At this point I also checked 1) previously installed cluster using the
>> 0MB disk flavour and 2) new instances using the 0MB disk flavour. I notice
>> that the previous cluster is having host storage allocated but while the
>> new instance is not having host storage allocated. So the cluster create
>> success is using flavour with disk = 0MB while the result is compute HDD
>> storage being consumed.
>>
>> So with the above, please may I clarify on the following?
>> 1. It seems that 0MB disk flavours may not be supported with magnum now?
>> Could the experts confirm? :) Is there another way that I should be
>> configuring this so that compute node disk is not being consumed (because
>> it is slow and has limited capacity).
>> 2. The issue #1 looks like a bug to me, is it known? If not, is this mail
>> enough to get it realised?
>>
>> Pastebin links as mentioned
>> [1] http://paste.openstack.org/show/797316/
>>
>> [2] http://paste.openstack.org/show/797318/
>>
>>
>> Many thanks,
>>
>> Regards,
>>
>>
>> Tony Pearce
>>
>> --
>> Cheers & Best regards,
>> Feilong Wang (王飞龙)
>> ------------------------------------------------------
>> Senior Cloud Software Engineer
>> Tel: +64-48032246
>> Email: flwang at catalyst.net.nz
>> Catalyst IT Limited
>> Level 6, Catalyst House, 150 Willis Street, Wellington
>> ------------------------------------------------------
>>
>> --
> Cheers & Best regards,
> Feilong Wang (王飞龙)
> ------------------------------------------------------
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flwang at catalyst.net.nz
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> ------------------------------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/21cf9d44/attachment-0001.html>

From dtantsur at redhat.com  Wed Sep  2 09:40:25 2020
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Wed, 2 Sep 2020 11:40:25 +0200
Subject: [ironic] Announcing deprecation of the iSCSI deploy interface
Message-ID: <CACNgkFw0Ldbj4DgBdQNar-tc3hBfgau4s7A2N7pKtJXWiif6Pg@mail.gmail.com>

Hi all,

Following up to the previous mailing list [1] and virtual meetup [2]
discussions, I would like to announce the plans to deprecate the 'iscsi'
deploy interface.

This is the updated plan discussed on the virtual meetup:
1) In the Victoria cycle (i.e. right now):
  - Fill in the detected feature gaps [3].
  - Switch off the iscsi deploy interface by default.
  - Change [agent]image_dowload_source to HTTP by default.
  - Give the direct deploy a higher priority, so that it's used by default
unless disabled.
  - Mark it as deprecated in the code (causing warnings when enabled).
  - Release a major version of ironic to highlight the defaults changes.
2) In the W cycle:
  - Keep the iscsi deploy deprecated.
  - Listen to operators' feedback.
3) In the X cycle
  - Remove the iscsi deploy completely from ironic and IPA.
  - Remove support code from ironic-lib with a major version bump.

Please let us know if you have any questions or concerns.

Dmitry

[1]
http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016681.html
[2] https://etherpad.opendev.org/p/Ironic-Victoria-midcycle
[3] https://storyboard.openstack.org/#!/story/2008075

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

From anilj.mailing at gmail.com  Wed Sep  2 09:47:27 2020
From: anilj.mailing at gmail.com (Anil Jangam)
Date: Wed, 2 Sep 2020 02:47:27 -0700
Subject: Graceful stopping of RabbitMQ AMQP notification listener
In-Reply-To: <CAHVD1iau+Wq7kqJuip8S5R3Zd2qMjpcQQiN-kYQzHY3jmmZa0Q@mail.gmail.com>
References: <CAHVD1iau+Wq7kqJuip8S5R3Zd2qMjpcQQiN-kYQzHY3jmmZa0Q@mail.gmail.com>
Message-ID: <CAHVD1ib8_0BbE+suABAtJwsWtNQ3cmstGX0PrqaqL367YR+8PQ@mail.gmail.com>

Hi,

I found the issue and it was the way I was starting and stopping the
listener. I got some more logs below that helped me understand this
deadlock behavior. I have fixed issue in my app.

OPS_WORKER_0--DEBUG-2020-09-02 02:39:30,309-amqpdriver.py-322 -
AMQPListener connection consume
OPS_WORKER_0--DEBUG-2020-09-02 02:39:30,310-connection.py-712 -
heartbeat_tick : for connection b616c1205a61466a94e4ae2e79e6ba84
OPS_WORKER_0--DEBUG-2020-09-02 02:39:30,310-connection.py-734 -
heartbeat_tick : Prev sent/recv: 8/8, now - 8/8, monotonic - 32.014996083,
last_heartbeat_sent - 0.97555832, heartbeat int. - 60 for connection
b616c1205a61466a94e4ae2e79e6ba84
MainProcess--WARNING-2020-09-02 02:39:34,108-server.py-127 - Possible hang:
stop is waiting for start to complete
MainProcess--DEBUG-2020-09-02 02:39:34,117-server.py-128 -
  File "/testprogs/python/oslo_notif/main.py", line 33, in <module> main()
  File "/testprogs/python/oslo_notif/main.py", line 29, in main
worker.stop()
  File "/testprogs/python/oslo_notif/oslo_worker.py", line 85, in stop
self.__amqp_handler.stop_amqp_event_listener()
  File "/testprogs/python/oslo_notif/oslo_notif_handler.py", line 184, in
stop_amqp_event_listener self.__amqp_listener.stop()
  File "/pyvenv37/lib/python3.7/site-packages/oslo_messaging/server.py",
line 264, in wrapper log_after, timeout_timer)
  File "/pyvenv37/lib/python3.7/site-packages/oslo_messaging/server.py",
line 163, in wait_for_completion msg, log_after, timeout_timer)
  File "/pyvenv37/lib/python3.7/site-packages/oslo_messaging/server.py",
line 128, in _wait

/anil.


On Wed, Sep 2, 2020 at 12:12 AM Anil Jangam <anilj.mailing at gmail.com> wrote:

> Hi,
>
> I have coded OpenStack AMQP listener following the example and it is
> working fine.
>
> https://github.com/gibizer/nova-notification-demo/blob/master/ws_forwarder.py
>
> The related code snippets of the NotificationHandler class are shown as
> follows.
>
> # Initialize the AMQP listener
> def init(self, cluster_ip, user, password, port):
>     cfg.CONF()
>     cluster_url = "rabbit://" + user + ":" + password + "@" + cluster_ip + ":" + port + "/"
>     transport = oslo_messaging.get_notification_transport(cfg.CONF, url=cluster_url)
>     targets = [
>         oslo_messaging.Target(topic='versioned_notifications'),
>     ]
>     endpoints = [self.__endpoint]
>
>     # Initialize the notification listener
>     try:
>         self.__amqp_listener = oslo_messaging.get_notification_listener(transport,
>                                                                         targets,
>                                                                         endpoints,
>                                                                         executor='threading')
>     except NotImplementedError as err:
>         LOGGER.error("Failed to initialize the notification listener {}".format(err))
>         return False
>
>     LOGGER.debug("Initialized the notification listener {}".format(cluster_url))
>     return True
>
> # Arm the compute event listeners
> def start_amqp_event_listener(self):
>     # Start the notification handler
>     LOGGER.debug("Started the OpenStack notification handler")
>     self.__amqp_listener.start()
>
> # Disarm the compute event listeners
> def stop_amqp_event_listener(self):
>     LOGGER.debug("Stopping the OpenStack notification handler")
>     if self.__amqp_listener is not None:
>         self.__amqp_listener.stop()
>
> I am using this interface from a new process handler function, however,
> when I invoke the stop_amqp_eent_listener() method, my process hangs. It
> does not terminate naturally.
> I verified that the self.__amqp_listener.stop() function is not
> returning. Is there anything missing in this code? Is there any specific
> consideration when calling the listener from a new process?
>
> Can someone provide a clue?
>
> # Stop the worker
> def stop(self):
>     # Stop the AMQP notification handler
>     self.__amqp_handler.stop_amqp_event_listener()
>     LOGGER.debug("Stopped the worker for {}".format(self.__ops_conn_info.cluster_ip))
>
>
> /anil.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/6a003bd0/attachment.html>

From anlin.kong at gmail.com  Wed Sep  2 10:05:46 2020
From: anlin.kong at gmail.com (Lingxian Kong)
Date: Wed, 2 Sep 2020 22:05:46 +1200
Subject: Trove images for Cluster testing.
In-Reply-To: <MAXPR01MB2126D355F5B43752A1517CCE8A510@MAXPR01MB2126.INDPRD01.PROD.OUTLOOK.COM>
References: <MA1PR01MB21229BC9F1D07FA7F3F571058A540@MA1PR01MB2122.INDPRD01.PROD.OUTLOOK.COM>
 <CALjNAZ3Gog4G-92qEv9z9iLgB89Y_rNPbYn3VbL7ydB3wdaoYA@mail.gmail.com>
 <MAXPR01MB2126D355F5B43752A1517CCE8A510@MAXPR01MB2126.INDPRD01.PROD.OUTLOOK.COM>
Message-ID: <CALjNAZ2vGjfGganzgOBW7Xhk3n7Ergns=SXvr=KZLVU8-dCkhQ@mail.gmail.com>

Hi Arunkumar,

For how to join IRC channel, please see
https://docs.opendev.org/opendev/infra-manual/latest/developers.html#irc-account

Currently there is no trove team meeting because we don't have any other
people interested (for some historical reasons), but if needed, we can
schedule a time suitable for both. I'm in UTC+12 btw.

---
Lingxian Kong
Senior Software Engineer
Catalyst Cloud
www.catalystcloud.nz


On Wed, Sep 2, 2020 at 2:56 AM ARUNKUMAR PALANISAMY <
arunkumar.palanisamy at tcs.com> wrote:

> Hi  Lingxian,
>
>
>
> Hope you are doing Good.
>
>
>
> Thank you for your mail and detailed information.
>
>
>
> We would like to join #openstack-trove IRC channel for discussions. Could
> you  please advise us the process to join IRC channel.
>
>
>
> We came to know that currently there is no IRC channel meeting happening
> for Trove, if there is any meeting scheduled and happening. we would like
> to join and understand the works and progress towards Trove and contribute
> further.
>
>
>
> Regards,
>
> Arunkumar Palanisamy
>
>
>
> *From:* Lingxian Kong <anlin.kong at gmail.com>
> *Sent:* Friday, August 28, 2020 12:09 AM
> *To:* ARUNKUMAR PALANISAMY <arunkumar.palanisamy at tcs.com>
> *Cc:* openstack-discuss at lists.openstack.org; Pravin Mohan <
> pravin.mohan at tcs.com>
> *Subject:* Re: Trove images for Cluster testing.
>
>
> "External email. Open with Caution"
>
> Hi Arunkumar,
>
>
>
> Unfortunately, for now Trove only supports MySQL and MariaDB, I'm working
> on adding PostgreSQL support. All other datastores are unmaintained right
> now.
>
>
>
> Since this(Victoria) dev cycle, docker container was introduced in Trove
> guest agent in order to remove the maintenance overhead for multiple Trove
> guest images. We only need to maintain one single guest image but could
> support different datastores. We have to do that as such a small Trove team
> in the community.
>
>
>
> If supporting Redis, Cassandra, MongoDB or Couchbase is in your feature
> request, you are welcome to contribute to Trove.
>
>
>
> Please let me know if you have any other questions. You are also welcome
> to join #openstack-trove IRC channel for discussion.
>
>
>
> ---
>
> Lingxian Kong
>
> Senior Software Engineer
>
> Catalyst Cloud
>
> www.catalystcloud.nz
>
>
>
>
>
> On Fri, Aug 28, 2020 at 6:45 AM ARUNKUMAR PALANISAMY <
> arunkumar.palanisamy at tcs.com> wrote:
>
> Hello Team,
>
>
>
> My name is ARUNKUMAR PALANISAMY,
>
>
>
> As part of our project requirement, we are evaluating trove components and
> need your support for experimental  datastore Image for testing cluster.
>  (Redis, Cassandra, MongoDB, Couchbase)
>
>
>
> 1.)    We are running devstack enviorment with Victoria Openstack release
> and with this image (trove-master-guest-ubuntu-bionic-dev.qcow2
> <https://tarballs.opendev.org/openstack/trove/images/trove-master-guest-ubuntu-bionic-dev.qcow2>),
> we are able to deploy mysql instance and and getting below error while
> creating mongoDB instances.
>
>
>
> *“ModuleNotFoundError: No module named
> 'trove.guestagent.datastore.experimental' “*
>
>
>
> 2.)    While tried creating mongoDB image with diskimage-builder
> <https://opendev.org/openstack/diskimage-builder> tool, but we are
> getting “Block device ” element error.
>
>
>
>
>
> Regards,
>
> Arunkumar Palanisamy
>
> Cell: +49 172 6972490
>
>
>
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/15f9d6b9/attachment-0001.html>

From whayutin at redhat.com  Wed Sep  2 11:54:29 2020
From: whayutin at redhat.com (Wesley Hayutin)
Date: Wed, 2 Sep 2020 05:54:29 -0600
Subject: [tripleo] docker.io rate limiting
Message-ID: <CAOHJT4LT68KhRBt3vxb+D-6VpNUPgc2=JBae0nwC8xNZj2EJzQ@mail.gmail.com>

Greetings,

Some of you have contacted me regarding the recent news regarding docker.io's
new policy with regards to container pull rate limiting [1].  I wanted to
take the opportunity to further socialize our plan that will completely
remove docker.io from our upstream workflows and avoid any rate limiting
issues.

We will continue to upload containers to docker.io for some time so that
individuals and the community can access the containers.  We will also
start exploring other registries like quay and newly announced github
container registry. These other public registries will NOT be used in our
upstream jobs and will only serve the communities individual contributors.

Our test jobs have been successful and patches are starting to merge to
convert our upstream jobs and remove docker.io from our upstream workflow.
[2].

Standalone and multinode jobs are working quite well.  We are doing some
design work around branchful, update/upgrade jobs at this time.

Thanks 0/


[1] https://hackmd.io/ermQSlQ-Q-mDtZkNN2oihQ
[2]
https://review.opendev.org/#/q/topic:new-ci-job+(status:open+OR+status:merged)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/55500bd6/attachment.html>

From viroel at gmail.com  Wed Sep  2 12:16:22 2020
From: viroel at gmail.com (Douglas)
Date: Wed, 2 Sep 2020 09:16:22 -0300
Subject: [manila] Victoria Collab Review next Tuesday (Sep 1st)
In-Reply-To: <CAE=en=PAHZP-h74pHxqR2FHJm5ZxoNqczOrJ=d3Dkfo=YSJ=OQ@mail.gmail.com>
References: <CAE=en=PAHZP-h74pHxqR2FHJm5ZxoNqczOrJ=d3Dkfo=YSJ=OQ@mail.gmail.com>
Message-ID: <CAE=en=M59CemwANamx4+=7SZYnY==oJOOwvV=sPMVrFzpkAS9Q@mail.gmail.com>

Hi all,

The recording of our collaborative review meeting is available in the
OpenStack/Manila channel[1], and the meetings notes are available at the
meeting etherpad[2].
Thank you everybody that was able to join and participate.

[1] https://youtu.be/CCIhHVKPTx4
[2] https://etherpad.opendev.org/p/manila-victoria-collab-review



On Thu, Aug 27, 2020 at 6:49 PM Douglas <viroel at gmail.com> wrote:

> Hi everybody
>
> We will have a new edition of our collaborative review next Tuesday,
> September 1st, where we'll go through the code and review the proposed
> feature Share Server Migration[1][2].
> This meeting is scheduled for two hours, starting at 5:00PM UTC. Meeting
> notes and videoconference links will be available here[3].
> Feel free to attend if you are interested and available.
>
> Hoping to see you there,
>
> - dviroel
>
> [1]
> https://opendev.org/openstack/manila-specs/src/branch/master/specs/victoria/share-server-migration.rst
> [2]
> https://review.opendev.org/#/q/topic:bp/share-server-migration+(status:open)
> [3] https://etherpad.opendev.org/p/manila-victoria-collab-review
>


-- 
Douglas Viroel (dviroel)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/3d7028ae/attachment.html>

From mark at stackhpc.com  Wed Sep  2 08:35:24 2020
From: mark at stackhpc.com (Mark Goddard)
Date: Wed, 2 Sep 2020 09:35:24 +0100
Subject: [kolla] questions when using external mysql
In-Reply-To: <5c644eb6.3cda.174488cf629.Coremail.sosogh@126.com>
References: <5c644eb6.3cda.174488cf629.Coremail.sosogh@126.com>
Message-ID: <CAFHSqWpa03GBGuDvK7r4-ktV5zyqfKYTEvRq3B3zTd+qqkcs5w@mail.gmail.com>

On Tue, 1 Sep 2020 at 15:48, sosogh <sosogh at 126.com> wrote:

> Hi list:
>
> I want to use kolla-ansible to deploy openstack , but using external
> mysql.
> I am following these docs:
>
> https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html
>
>
> https://docs.openstack.org/kolla-ansible/latest/reference/databases/external-mariadb-guide.html
> .
>

Hi, could you start by telling us which version or branch of Kolla Ansible
you are using?

>
> I have some questions:
>
> ################
> ##  Question 1 ##
> ################
>
>  According to the offical doc , if setting it  in inventory
> file(multinode),
>
>
> kolla-ansible -i ./multinode deploy will throw out error:
>
>
> I guest when kolla-ansible running the playbook against
> myexternalmariadbloadbalancer.com ,
>
> the """register: find_custom_fluentd_inputs""" in """TASK [common : Find
> custom fluentd input config files]"""  maybe null .
>

I think this could be an issue with a recent change to the common role,
where the condition for the 'Find custom fluentd input config files' task
changed slightly. I have proposed a potential fix for this, could you try
it out and report back? https://review.opendev.org/749463

>
> ################
> ##  Question 2 ##
> ################
>
>  According to the offical doc , If the MariaDB username is not root, set
> database_username in /etc/kolla/globals.yml file:
>
>
> But in kolla-ansible/ansible/roles/xxxxxx/tasks/bootstrap.yml  , they use
> ''' login_user: "{{ database_user }}"  ''' ， for example :
>
> You are correct, this is an issue in the documentation. I have proposed a
fix here: https://review.opendev.org/749464


> So at last  , I took the following steps:
> 1. """not""" setting [mariadb] in inventory file(multinode)
> 2. set "database_user: openstack" for  "privillegeduser"
>
> PS:
> My idea is that if using an external ready-to-use mysql (cluster),
> it is enough to tell kolla-ansible only the address/user/password of the
> external DB.
> i.e. setting them in the file /etc/kolla/globals.yml and passwords.yml ,
> no need to add it into inventory file(multinode)
>

I agree, I did not expect to need to change the inventory for this use case.

>
> Finally , it is successful to  deploy openstack via kolla-ansible .
> So far I have not found any problems.
>  Are the steps what I took  good ( enough ) ?
> Thank you !
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/b745ad4d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2938 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/b745ad4d/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 95768 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/b745ad4d/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2508 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/b745ad4d/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 22016 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/b745ad4d/attachment-0007.png>

From sosogh at 126.com  Wed Sep  2 10:00:24 2020
From: sosogh at 126.com (sosogh)
Date: Wed, 2 Sep 2020 18:00:24 +0800 (CST)
Subject: Reply:Re: [kolla] questions when using external mysql
In-Reply-To: <CAFHSqWpa03GBGuDvK7r4-ktV5zyqfKYTEvRq3B3zTd+qqkcs5w@mail.gmail.com>
References: <5c644eb6.3cda.174488cf629.Coremail.sosogh@126.com>
 <CAFHSqWpa03GBGuDvK7r4-ktV5zyqfKYTEvRq3B3zTd+qqkcs5w@mail.gmail.com>
Message-ID: <d4f7b10.55ae.1744e42a364.Coremail.sosogh@126.com>

Hi Mark:


>>  Hi, could you start by telling us which version or branch of Kolla Ansible you are using?


root at ubt-1804:~# pip show kolla-ansible
Name: kolla-ansible
Version: 10.1.0.dev260


I download them via "git clone"  ,  it is master branch by default .


git clone https://github.com/openstack/kolla
git clone https://github.com/openstack/kolla-ansible


>>  could you try it out and report back? https://review.opendev.org/749463


I will try it later.





在 2020-09-02 16:35:24，"Mark Goddard" <mark at stackhpc.com> 写道：





On Tue, 1 Sep 2020 at 15:48, sosogh <sosogh at 126.com> wrote:


Hi list:



I want to use kolla-ansible to deploy openstack , but using external mysql. 
I am following these docs:  

https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html

https://docs.openstack.org/kolla-ansible/latest/reference/databases/external-mariadb-guide.html.



 Hi, could you start by telling us which version or branch of Kolla Ansible you are using?




I have some questions:



################
##  Question 1 ##
################



 According to the offical doc , if setting it  in inventory file(multinode), 




kolla-ansible -i ./multinode deploy will throw out error:




I guest when kolla-ansible running the playbook against myexternalmariadbloadbalancer.com , 

the """register: find_custom_fluentd_inputs""" in """TASK [common : Find custom fluentd input config files]"""  maybe null .



I think this could be an issue with a recent change to the common role, where the condition for the 'Find custom fluentd input config files' task changed slightly. I have proposed a potential fix for this, could you try it out and report back? https://review.opendev.org/749463




################
##  Question 2 ##
################

 According to the offical doc , If the MariaDB username is not root, set database_username in /etc/kolla/globals.yml file:  




But in kolla-ansible/ansible/roles/xxxxxx/tasks/bootstrap.yml  , they use  ''' login_user: "{{ database_user }}"  ''' ， for example :



You are correct, this is an issue in the documentation. I have proposed a fix here: https://review.opendev.org/749464
 
So at last  , I took the following steps:
1. """not""" setting [mariadb] in inventory file(multinode)   
2. set "database_user: openstack" for  "privillegeduser"


PS: 
My idea is that if using an external ready-to-use mysql (cluster),  
it is enough to tell kolla-ansible only the address/user/password of the external DB.
i.e. setting them in the file /etc/kolla/globals.yml and passwords.yml , no need to add it into inventory file(multinode)   


I agree, I did not expect to need to change the inventory for this use case.


Finally , it is successful to  deploy openstack via kolla-ansible . 
So far I have not found any problems.   
 Are the steps what I took  good ( enough ) ? 
Thank you !



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/df7080dd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2938 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/df7080dd/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 95768 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/df7080dd/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2508 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/df7080dd/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 22016 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/df7080dd/attachment-0007.png>

From smooney at redhat.com  Wed Sep  2 12:58:55 2020
From: smooney at redhat.com (Sean Mooney)
Date: Wed, 02 Sep 2020 13:58:55 +0100
Subject: [ovn][neutron][ussuri] How to configure for overlay in DPDK
 with OVN ?
In-Reply-To: <CADeNzf8CCK1sp1KKZUuLkiikK=Wyxh2FAbBzBv_JGeUpG35iAA@mail.gmail.com>
References: <CADeNzf8CCK1sp1KKZUuLkiikK=Wyxh2FAbBzBv_JGeUpG35iAA@mail.gmail.com>
Message-ID: <eb743897daabf4ed0ca27ff6d426fbb5b1b129dc.camel@redhat.com>

On Wed, 2020-09-02 at 16:23 +0900, 한승진 wrote:
> Hi,
> 
> 
> I’m trying to implement dpdk-ovs with ovn for our openstack environment.
> 
> 
> I create a bond interface(tunbound) with ovs and tun0 and tun1 are slave
> interfaces of the bond interface named tunbond.
> 
> 
>     Bridge br-int
> 
>         fail_mode: secure
> 
>         datapath_type: netdev
> 
>         Port tunbond
> 
>             Interface tun0
> 
>                 type: dpdk
> 
>                 options: {dpdk-devargs="0000:1a:00.1", n_rxq="2"}
> 
>             Interface tun1
> 
>                 type: dpdk
> 
>                 options: {dpdk-devargs="0000:d8:00.1", n_rxq="2"}
> 
>         Port br-int
> 
>             Interface br-int
> 
>                 type: internal
> 
> Now, I need to configure remote-ovn options to the ovs.
> 
> 
> *I am confused how can I define the IP address of the bonded interface with
> ovs?*
you dont you set the tunnel local ip on the ovs bridge containing the bond.
when a inteface is managed by ovs (with the excption of the bridge port or type internal ports)
asinging an ip to the interface will do nothing as ovs hooks the packets beofre they reach the ip layer of the kernel
networking stack.

so to make sure that the kernel routes the network packets vi the ovs bridge you need to assign the tunnel local ip to
the ovs bridge with the bound. so br-int in this case

this will cause that bridge to respond to arps form the tunnel local ip and that will cause the back leaning table in
ovs to be populated correctly with the remote mac address for the remote tunnel endpoints via the bound.

if you use ovs-appctl and look at the dataplane(not oepnflow) flows you will see that the tunnel endcap flow is followed
by an out_port action instead of an output action which renques the packet as if it arrived on the port
so when the packet is encaped with the geneve header it will be reporced as if it came form the bridge local port and
then mac learing/the normal action woudl forward it to the bond. at least that is how it would work for ml2/ovs

if we do not have the normal action for that case we would need explcit openflow rules to send the packet to the bound.

if you dont have the local tunnel endpoint ip on the brige however the tunnel traffic will not be dpdk acclerated so
that is important to have set correctly.
> 
> 
> Theses are commands for connect remote ovn services.
> 
> 
> ovs-vsctl set open . external-ids:ovn-remote=tcp:{controller ip}:6642
> 
> ovs-vsctl set open . external-ids:ovn-encap-type=geneve
> 
> *1*
> 
> 
> This below command make it me confused.
> 
> 
> ovs-vsctl set open . external-ids:ovn-encap-ip={local ip}
> 
> 
> How should I resolve this issue?
> 
> 
> Regards,
> 
> 
> John Haan



From CAPSEY at augusta.edu  Wed Sep  2 13:29:48 2020
From: CAPSEY at augusta.edu (Apsey, Christopher)
Date: Wed, 2 Sep 2020 13:29:48 +0000
Subject: [neutron][ovn] OVN Performance
Message-ID: <BN8PR03MB512328A4863092CAEA0561CEDD2F0@BN8PR03MB5123.namprd03.prod.outlook.com>

All,

Just wanted to loop back here and give an update.

For reference, [1] (blue means successful action, red means failed action) is the result we got when booting 5000 instances in rally [2] before the Red Hat OVN devs poked around inside our environment, and [3] is the result after.  The differences are obviously pretty significant.  I think the biggest change was setting metadata_workers = 2 in neutron_ovn_metadata_agent.ini on the compute nodes per https://bugs.launchpad.net/neutron/+bug/1893656.  We have 64C/128T on all compute nodes, so the default neutron calculation of scaling metadata workers based on available cores created 900+ connections to the southbound db at idle; after the control plane got loaded up it just quit around 2500 instances (my guess is it hit the open file limit, although I don’t think increasing it would have made it better for much longer since the number of connections were increasing exponentially).  Capping the number of metadata workers decreased open southbound connections by 90%.  Even more telling was that rally was able to successfully clean up after itself after we made that change, whereas previously it wasn’t even able to successfully tear down any of the instances that were made, indicating that the control plane was completely toast.

Note that the choppiness towards the end of [3] had nothing to do with OVN – our compute nodes had a loadavg approaching 1000 at that point, so they were just starved for cpu cycles.  This would have scaled even better with additional compute nodes.

The other piece was RAFT.  Currently, RDO is shipping with ovs 2.12, but 2.13 has a bunch of RAFT fixes in it that improve stability and knock out some bugs.  We were having issues with chassis registration on 2.12, but after using the 2.13 package from cbs, all those issues went away.

Big thanks to the great people at Red Hat on the cc line for volunteering their valuable time to take a look.

I’m now significantly more comfortable with defaulting to OVN as the backend of choice as the performance delta is now gone.  That said, should the community consider dropping linuxbridge as the backend in the official upstream docs and jump straight to OVN rather than ml2/OVS?  I think that would increase the test base and help shine light on other issues as time goes on.  My org can devote some time to doing this work if the community agrees that it’s the right action to take.

Hope that’s helpful!

[1] https://ibb.co/GTjZP2y
[2] https://pastebin.com/5pEDZ7dY
[3] https://ibb.co/pfB9KTV

Chris Apsey
GEORGIA CYBER CENTER

From: Apsey, Christopher
Sent: Thursday, August 27, 2020 11:33 AM
To: Assaf Muller <amuller at redhat.com>
Cc: openstack-discuss at lists.openstack.org; Lucas Alvares Gomes Martins <lmartins at redhat.com>; Jakub Libosvar <jlibosva at redhat.com>; Daniel Alvarez Sanchez <dalvarez at redhat.com>
Subject: RE: [EXTERNAL] Re: [neutron][ovn] OVN Performance

Assaf,

We can absolutely support engineering poking around in our environment (and possibly an even larger one at my previous employer that was experiencing similar issues during testing).  We can take this offline so we don’t spam the mailing list.

Just let me know how to proceed,

Thanks!

Chris Apsey
GEORGIA CYBER CENTER

From: Assaf Muller <amuller at redhat.com<mailto:amuller at redhat.com>>
Sent: Thursday, August 27, 2020 11:18 AM
To: Apsey, Christopher <CAPSEY at augusta.edu<mailto:CAPSEY at augusta.edu>>
Cc: openstack-discuss at lists.openstack.org<mailto:openstack-discuss at lists.openstack.org>; Lucas Alvares Gomes Martins <lmartins at redhat.com<mailto:lmartins at redhat.com>>; Jakub Libosvar <jlibosva at redhat.com<mailto:jlibosva at redhat.com>>; Daniel Alvarez Sanchez <dalvarez at redhat.com<mailto:dalvarez at redhat.com>>
Subject: [EXTERNAL] Re: [neutron][ovn] OVN Performance

CAUTION: EXTERNAL SENDER This email originated from an external source. Please exercise caution before opening attachments, clicking links, replying, or providing information to the sender. If you believe it to be fraudulent, contact the AU Cybersecurity Hotline at 72-CYBER (2-9237 / 706-722-9237) or 72CYBER at augusta.edu<mailto:72CYBER at augusta.edu>

The most efficient way about this is to give one or more of the
Engineers working on OpenStack OVN upstream (I've added a few to this
thread) temporary access to an environment that can reproduce issues
you're seeing, we could then document the issues and work towards
solutions. If that's not possible, if you could provide reproducer
scripts, or alternatively sharpen the reproduction method, we'll take
a look. What you've described is not something that's 'acceptable',
OVN should definitely not scale worse than Neutron with the Linux
Bridge agent. It's possible that the particular issues you ran in to
is something that we've already seen internally at Red Hat, or with
our customers, and we're already working on fixes in future versions
of OVN - I can't tell you until you elaborate on the details of the
issues you're seeing. In any case, the upstream community is committed
to improving OVN scale and fixing scale issues as they pop up.
Coincidentally, Red Hat scale engineers just published an article [1]
about work they've done to scale RH-OSP 16.1 (== OpenStack Train on
CentOS 8, with OVN 2.13 and TripleO) to 700 compute nodes.

[1] https://www.redhat.com/en/blog/scaling-red-hat-openstack-platform-161-more-700-nodes?source=bloglisting<https://www.redhat.com/en/blog/scaling-red-hat-openstack-platform-161-more-700-nodes?source=bloglisting>

On Thu, Aug 27, 2020 at 10:44 AM Apsey, Christopher <CAPSEY at augusta.edu<mailto:CAPSEY at augusta.edu>> wrote:
>
> All,
>
>
>
> I know that OVN is going to become the default neutron backend at some point and displace linuxbridge as the default configuration option in the docs, but we have noticed a pretty significant performance disparity between OVN and linuxbridge on identical hardware over the past year or so in a few different environments[1]. I know that example is unscientific, but similar results have been borne out in many different scenarios from what we have observed. There are three main problems from what we see:
>
>
>
> 1. OVN does not handle large concurrent requests as well as linuxbridge. Additionally, linuxbridge concurrent capacity grows (not linearly, but grows nonetheless) by adding additional neutron API endpoints and RPC agents. OVN does not really horizontally scale by adding additional API endpoints, from what we have observed.
>
> 2. OVN gets significantly slower as load on the system grows. We have observed a soft cap of about 2000-2500 instances in a given deployment before ovn-backed neutron stops responding altogether to nova requests (even for booting a single instance). We have observed linuxbridge get to 5000+ instances before it starts to struggle on the same hardware (and we think that linuxbridge can go further with improved provider network design in that particular case).
>
> 3. Once the southbound database process hits 100% CPU usage on the leader in the ovn cluster, it’s game over (probably causes 1+2)
>
>
>
> It's entirely possible that we just don’t understand OVN well enough to tune it [2][3][4], but then the question becomes how do we get that tuning knowledge into the docs so people don’t scratch their heads when their cool new OVN deployment scales 40% as well as their ancient linuxbridge-based one?
>
>
>
> If it is ‘known’ that OVN has some scaling challenges, is there a plan to fix it, and what is the best way to contribute to doing so?
>
>
>
> We have observed similar results on Ubuntu 18.04/20.04 and CentOS 7/8 on Stein, Train, and Ussuri.
>
>
>
> [1] https://pastebin.com/kyyURTJm<https://pastebin.com/kyyURTJm>
>
> [2] https://github.com/GeorgiaCyber/kinetic/tree/master/formulas/ovsdb<https://github.com/GeorgiaCyber/kinetic/tree/master/formulas/ovsdb>
>
> [3] https://github.com/GeorgiaCyber/kinetic/tree/master/formulas/neutron<https://github.com/GeorgiaCyber/kinetic/tree/master/formulas/neutron>
>
> [4] https://github.com/GeorgiaCyber/kinetic/tree/master/formulas/compute<https://github.com/GeorgiaCyber/kinetic/tree/master/formulas/compute>
>
>
>
> Chris Apsey
>
> GEORGIA CYBER CENTER
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/0bb541d3/attachment-0001.html>

From dalvarez at redhat.com  Wed Sep  2 13:42:34 2020
From: dalvarez at redhat.com (Daniel Alvarez Sanchez)
Date: Wed, 2 Sep 2020 15:42:34 +0200
Subject: [neutron][ovn] OVN Performance
In-Reply-To: <BN8PR03MB512328A4863092CAEA0561CEDD2F0@BN8PR03MB5123.namprd03.prod.outlook.com>
References: <BN8PR03MB512328A4863092CAEA0561CEDD2F0@BN8PR03MB5123.namprd03.prod.outlook.com>
Message-ID: <CAPXMuf9Ai_mrGouoS2JdWSb2zLXR+tFaYb9Ln-btjR2DuFwqYw@mail.gmail.com>

Hey Chris, thanks for sharing this :)

On Wed, Sep 2, 2020 at 3:30 PM Apsey, Christopher <CAPSEY at augusta.edu>
wrote:

> All,
>
>
>
> Just wanted to loop back here and give an update.
>
>
>
> For reference, [1] (blue means successful action, red means failed action)
> is the result we got when booting 5000 instances in rally [2] before the
> Red Hat OVN devs poked around inside our environment, and [3] is the result
> after.  The differences are obviously pretty significant.  I think the
> biggest change was setting metadata_workers = 2 in
> neutron_ovn_metadata_agent.ini on the compute nodes per
> https://bugs.launchpad.net/neutron/+bug/1893656.  We have 64C/128T on all
> compute nodes, so the default neutron calculation of scaling metadata
> workers based on available cores created 900+ connections to the southbound
> db at idle; after the control plane got loaded up it just quit around 2500
> instances (my guess is it hit the open file limit, although I don’t think
> increasing it would have made it better for much longer since the number of
> connections were increasing exponentially).  Capping the number of metadata
> workers decreased open southbound connections by 90%.  Even more telling
> was that rally was able to successfully clean up after itself after we made
> that change, whereas previously it wasn’t even able to successfully tear
> down any of the instances that were made, indicating that the control plane
> was completely toast.
>
>
>
> Note that the choppiness towards the end of [3] had nothing to do with OVN
> – our compute nodes had a loadavg approaching 1000 at that point, so they
> were just starved for cpu cycles.  This would have scaled even better with
> additional compute nodes.
>
>
>
> The other piece was RAFT.  Currently, RDO is shipping with ovs 2.12, but
> 2.13 has a bunch of RAFT fixes in it that improve stability and knock out
> some bugs.  We were having issues with chassis registration on 2.12, but
> after using the 2.13 package from cbs, all those issues went away.
>
>
>
> Big thanks to the great people at Red Hat on the cc line for volunteering
> their valuable time to take a look.
>

Happy to help, it was fun :) Thanks to you for all the details that made it
easier to debug

>
>
> I’m now significantly more comfortable with defaulting to OVN as the
> backend of choice as the performance delta is now gone.  That said, should
> the community consider dropping linuxbridge as the backend in the official
> upstream docs and jump straight to OVN rather than ml2/OVS?  I think that
> would increase the test base and help shine light on other issues as time
> goes on.  My org can devote some time to doing this work if the community
> agrees that it’s the right action to take.
>

++!!

>
>
> Hope that’s helpful!
>
>
>
> [1] https://ibb.co/GTjZP2y
>
> [2] https://pastebin.com/5pEDZ7dY
>
> [3] https://ibb.co/pfB9KTV
>

Do you have some baseline to compare against? Also I'm curious to see if
you pulled results with and without raft :)

Thanks once again!

>
>
> *Chris Apsey*
>
> *GEORGIA CYBER CENTER*
>
>
>
> *From:* Apsey, Christopher
> *Sent:* Thursday, August 27, 2020 11:33 AM
> *To:* Assaf Muller <amuller at redhat.com>
> *Cc:* openstack-discuss at lists.openstack.org; Lucas Alvares Gomes Martins <
> lmartins at redhat.com>; Jakub Libosvar <jlibosva at redhat.com>; Daniel
> Alvarez Sanchez <dalvarez at redhat.com>
> *Subject:* RE: [EXTERNAL] Re: [neutron][ovn] OVN Performance
>
>
>
> Assaf,
>
>
>
> We can absolutely support engineering poking around in our environment
> (and possibly an even larger one at my previous employer that was
> experiencing similar issues during testing).  We can take this offline so
> we don’t spam the mailing list.
>
>
>
> Just let me know how to proceed,
>
>
>
> Thanks!
>
>
>
> *Chris Apsey*
>
> *GEORGIA CYBER CENTER*
>
>
>
> *From:* Assaf Muller <amuller at redhat.com>
> *Sent:* Thursday, August 27, 2020 11:18 AM
> *To:* Apsey, Christopher <CAPSEY at augusta.edu>
> *Cc:* openstack-discuss at lists.openstack.org; Lucas Alvares Gomes Martins <
> lmartins at redhat.com>; Jakub Libosvar <jlibosva at redhat.com>; Daniel
> Alvarez Sanchez <dalvarez at redhat.com>
> *Subject:* [EXTERNAL] Re: [neutron][ovn] OVN Performance
>
>
>
> CAUTION: EXTERNAL SENDER This email originated from an external source.
> Please exercise caution before opening attachments, clicking links,
> replying, or providing information to the sender. If you believe it to be
> fraudulent, contact the AU Cybersecurity Hotline at 72-CYBER (2-9237 /
> 706-722-9237) or 72CYBER at augusta.edu
>
> The most efficient way about this is to give one or more of the
> Engineers working on OpenStack OVN upstream (I've added a few to this
> thread) temporary access to an environment that can reproduce issues
> you're seeing, we could then document the issues and work towards
> solutions. If that's not possible, if you could provide reproducer
> scripts, or alternatively sharpen the reproduction method, we'll take
> a look. What you've described is not something that's 'acceptable',
> OVN should definitely not scale worse than Neutron with the Linux
> Bridge agent. It's possible that the particular issues you ran in to
> is something that we've already seen internally at Red Hat, or with
> our customers, and we're already working on fixes in future versions
> of OVN - I can't tell you until you elaborate on the details of the
> issues you're seeing. In any case, the upstream community is committed
> to improving OVN scale and fixing scale issues as they pop up.
> Coincidentally, Red Hat scale engineers just published an article [1]
> about work they've done to scale RH-OSP 16.1 (== OpenStack Train on
> CentOS 8, with OVN 2.13 and TripleO) to 700 compute nodes.
>
> [1]
> https://www.redhat.com/en/blog/scaling-red-hat-openstack-platform-161-more-700-nodes?source=bloglisting
>
> On Thu, Aug 27, 2020 at 10:44 AM Apsey, Christopher <CAPSEY at augusta.edu>
> wrote:
> >
> > All,
> >
> >
> >
> > I know that OVN is going to become the default neutron backend at some
> point and displace linuxbridge as the default configuration option in the
> docs, but we have noticed a pretty significant performance disparity
> between OVN and linuxbridge on identical hardware over the past year or so
> in a few different environments[1]. I know that example is unscientific,
> but similar results have been borne out in many different scenarios from
> what we have observed. There are three main problems from what we see:
> >
> >
> >
> > 1. OVN does not handle large concurrent requests as well as linuxbridge.
> Additionally, linuxbridge concurrent capacity grows (not linearly, but
> grows nonetheless) by adding additional neutron API endpoints and RPC
> agents. OVN does not really horizontally scale by adding additional API
> endpoints, from what we have observed.
> >
> > 2. OVN gets significantly slower as load on the system grows. We have
> observed a soft cap of about 2000-2500 instances in a given deployment
> before ovn-backed neutron stops responding altogether to nova requests
> (even for booting a single instance). We have observed linuxbridge get to
> 5000+ instances before it starts to struggle on the same hardware (and we
> think that linuxbridge can go further with improved provider network design
> in that particular case).
> >
> > 3. Once the southbound database process hits 100% CPU usage on the
> leader in the ovn cluster, it’s game over (probably causes 1+2)
> >
> >
> >
> > It's entirely possible that we just don’t understand OVN well enough to
> tune it [2][3][4], but then the question becomes how do we get that tuning
> knowledge into the docs so people don’t scratch their heads when their cool
> new OVN deployment scales 40% as well as their ancient linuxbridge-based
> one?
> >
> >
> >
> > If it is ‘known’ that OVN has some scaling challenges, is there a plan
> to fix it, and what is the best way to contribute to doing so?
> >
> >
> >
> > We have observed similar results on Ubuntu 18.04/20.04 and CentOS 7/8 on
> Stein, Train, and Ussuri.
> >
> >
> >
> > [1] https://pastebin.com/kyyURTJm
> >
> > [2] https://github.com/GeorgiaCyber/kinetic/tree/master/formulas/ovsdb
> >
> > [3] https://github.com/GeorgiaCyber/kinetic/tree/master/formulas/neutron
> >
> > [4] https://github.com/GeorgiaCyber/kinetic/tree/master/formulas/compute
> >
> >
> >
> > Chris Apsey
> >
> > GEORGIA CYBER CENTER
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/32a092a5/attachment-0001.html>

From ruslanas at lpic.lt  Wed Sep  2 14:17:49 2020
From: ruslanas at lpic.lt (=?UTF-8?Q?Ruslanas_G=C5=BEibovskis?=)
Date: Wed, 2 Sep 2020 16:17:49 +0200
Subject: [tripleo] docker.io rate limiting
In-Reply-To: <CAOHJT4LT68KhRBt3vxb+D-6VpNUPgc2=JBae0nwC8xNZj2EJzQ@mail.gmail.com>
References: <CAOHJT4LT68KhRBt3vxb+D-6VpNUPgc2=JBae0nwC8xNZj2EJzQ@mail.gmail.com>
Message-ID: <CABE5tBasc+fsr5P2AwsQ11xBreegK+-cNZZNKjPN_eu3qg6R8Q@mail.gmail.com>

Sorry for the stupid question, but maybe there is some parameter for
tripleo deployment not to generate and download images from docker io each
time? since I already have it downloaded and working?

Or, as I understand, I should be able to create my own snapshot of images
and specify it as a source?

On Wed, 2 Sep 2020 at 13:58, Wesley Hayutin <whayutin at redhat.com> wrote:

> Greetings,
>
> Some of you have contacted me regarding the recent news regarding
> docker.io's new policy with regards to container pull rate limiting [1].
> I wanted to take the opportunity to further socialize our plan that will
> completely remove docker.io from our upstream workflows and avoid any
> rate limiting issues.
>
> We will continue to upload containers to docker.io for some time so that
> individuals and the community can access the containers.  We will also
> start exploring other registries like quay and newly announced github
> container registry. These other public registries will NOT be used in our
> upstream jobs and will only serve the communities individual contributors.
>
> Our test jobs have been successful and patches are starting to merge to
> convert our upstream jobs and remove docker.io from our upstream
> workflow.  [2].
>
> Standalone and multinode jobs are working quite well.  We are doing some
> design work around branchful, update/upgrade jobs at this time.
>
> Thanks 0/
>
>
> [1] https://hackmd.io/ermQSlQ-Q-mDtZkNN2oihQ
> [2]
> https://review.opendev.org/#/q/topic:new-ci-job+(status:open+OR+status:merged)
>


-- 
Ruslanas Gžibovskis
+370 6030 7030
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/caf3cdb2/attachment.html>

From kennelson11 at gmail.com  Wed Sep  2 16:38:19 2020
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Wed, 2 Sep 2020 09:38:19 -0700
Subject: Mentoring Boston University Students
In-Reply-To: <CAKSuTPbis1FSrvX+5Zty9P7j3YX56W3KmetNCkLpp56yBK1p=g@mail.gmail.com>
References: <CAJ6yrQj40j2tAatjEQSmwJPRh5-TExK4eM3-c1tTpW9XiuNNvQ@mail.gmail.com>
 <CAKSuTPbis1FSrvX+5Zty9P7j3YX56W3KmetNCkLpp56yBK1p=g@mail.gmail.com>
Message-ID: <CAJ6yrQi_MCF8_oyfGR0_GsJtavDZoM-a1FoTZUPAqSnJ_XG51g@mail.gmail.com>

Hey Goutham!

Here is the form:
https://docs.google.com/forms/d/e/1FAIpQLSdehzBYqJeJ8x4RlPvQjTZpJ-LXs2A9vPrmRUPZNdawn1LgMg/viewform

-Kendall (diablo_rojo)

On Tue, Sep 1, 2020 at 6:56 PM Goutham Pacha Ravi <gouthampravi at gmail.com>
wrote:

> Hi Kendall,
>
> We'd like to help and have help in the manila team. We have a few projects
> [1] where the on-ramp may be relatively easy - I can work with you and
> define them. How do we apply?
>
> Thanks,
> Goutham
>
>
> [1] https://etherpad.opendev.org/p/manila-todos
>
>
>
>
>
> On Tue, Sep 1, 2020 at 9:08 AM Kendall Nelson <kennelson11 at gmail.com>
> wrote:
>
>> Hello!
>>
>> As you may or may not know, the last two years various community members
>> have mentored students from North Dakota State University for a semester to
>> work on projects in OpenStack. Recently, I learned of a similar program at
>> Boston University and they are still looking for mentors interested for the
>> upcoming semester.
>>
>> Essentially you would have 5 to 7 students for 13 weeks to mentor and
>> work on some feature or effort in your project.
>>
>> The time to apply is running out however as the deadline is Sept 3rd. If
>> you are interested, please let me know ASAP! I am happy to help get the
>> students up to speed with the community and getting their workspaces set
>> up, but the actual work they would do is more up to you :)
>>
>> -Kendall (diablo_rojo)
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/c9c5805c/attachment.html>

From kennelson11 at gmail.com  Wed Sep  2 17:19:24 2020
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Wed, 2 Sep 2020 10:19:24 -0700
Subject: [tacker] Wallaby vPTG
In-Reply-To: <e159766b-8508-33fc-d90b-97278356367e@gmail.com>
References: <e159766b-8508-33fc-d90b-97278356367e@gmail.com>
Message-ID: <CAJ6yrQjif7cLvS0FQkm1vKa-GHV+Zn2Y781nscjtXWnAn73hZQ@mail.gmail.com>

Hello Yasufumi!

Can I get you to fill out the survey for Tacker as well?

https://openstackfoundation.formstack.com/forms/oct2020_vptg_survey

Thanks!

-Kendall (diablo_rojo)

On Mon, Aug 31, 2020 at 10:25 PM Yasufumi Ogawa <yasufum.o at gmail.com> wrote:

> Hi team,
>
> I booked our slots, 27-29 Oct 6am-8am UTC, for the next vPTG[1] as we
> agreed in previous irc meeting. I also prepared an etherpad [2], so
> please add your name and suggestions.
>
> [1] https://ethercalc.openstack.org/7xp2pcbh1ncb
> [2] https://etherpad.opendev.org/p/Tacker-PTG-Wallaby
>
> Thanks,
> Yasufumi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/fd1d7516/attachment.html>

From zaitcev at redhat.com  Wed Sep  2 18:10:14 2020
From: zaitcev at redhat.com (Pete Zaitcev)
Date: Wed, 2 Sep 2020 13:10:14 -0500
Subject: [tripleo, ironic] Error: Could not retrieve ... pxelinux.0
In-Reply-To: <CAFsb3b78ZhNOaF7QM=kR=QxX8L3we7unuYO8xQ7xVTevH9KXHg@mail.gmail.com>
References: <20200828144844.7787707d@suzdal.zaitcev.lan>
 <CAFsb3b78ZhNOaF7QM=kR=QxX8L3we7unuYO8xQ7xVTevH9KXHg@mail.gmail.com>
Message-ID: <20200902131014.59f2553d@suzdal.zaitcev.lan>

Dear Alex,

thanks for the reply. In my case, the undercloud is running on CenOS 8:

[stack at undercloud ~]$ cat /etc/redhat-release 
CentOS Linux release 8.2.2004 (Core) 

What I'm trying to install is "upstream TripleO", if such a thing
even exists. The packages are built for RHEL 8/CentOS 8, at least:

[stack at undercloud ~]$ rpm -qf /usr/bin/openstack
python3-openstackclient-4.0.1-0.20200817052906.bff556c.el8.noarch
[stack at undercloud ~]$ rpm -qf /usr/share/python-tripleoclient/undercloud.conf.sample
python3-tripleoclient-12.3.2-0.20200820055917.c15d0d0.el8.noarch

I'm most curious about what a TripleO developer would do in this case.
Surely there's a way to have some local repository of some yet unknown
component, which I can then instrument or modify, and which is
responsible for dealing with PXE. But what is it?

Yours,
-- Pete

On Fri, 28 Aug 2020 14:00:11 -0600
Alex Schultz <aschultz at redhat.com> wrote:

> I've seen this in the past if there is a mismatch between the host OS
> and the Containers. Centos7 host with centos8 containers or vice
> versa.  Ussuri should be CentOS8 host OS and make sure you're pulling
> the correct containers.  The Ironic containers have some pathing
> mismatches when the configuration gets generated around this. It used
> to be compatible but we broke it at some point when switching some of
> the tftp location bits.
> 
> Thanks,
> -Alex
> 
> On Fri, Aug 28, 2020 at 1:55 PM Pete Zaitcev <zaitcev at redhat.com> wrote:
> >
> > Hello:
> >
> > I wanted to give the TripleO a try, so started follow our
> > installation guide for Ussuri, and eventually made it to
> > "openstack undercloud install". It fails with something like this:
> >
> > Aug 28 10:10:53 undercloud puppet-user[48657]: Error: /Stage[main]/Ironic::Pxe/File[/var/lib/ironic/tftpboot/ipxe.efi]: Could not evaluate: Could not retrieve information from environment production source(s) file:/usr/share/ipxe/ipxe-x86_64.efi
> > Aug 27 20:05:42 undercloud puppet-user[37048]: Error: /Stage[main]/Ironic::Pxe/Ironic::Pxe::Tftpboot_file[pxelinux.0]/File[/var/lib/ironic/tftpboot/pxelinux.0]: Could not evaluate: Could not retrieve information from environment production source(s) file:/tftpboot/pxelinux.0
> >
> > Does anyone have an idea what it wants?
> >
> > I added a couple of packages on the host system that provided
> > the files mentioned in the message, but it made no difference.
> > Ussuri is conteinerized anyway.
> >
> > Since I'm very new to this, I have no clue where to look at all.
> > The nearest task is a wrapper of some kind, so the install-undercloud.log
> > looks like this:
> >
> > 2020-08-28 14:11:31.397 60599 WARNING tripleoclient.v1.tripleo_deploy.Deploy [  ] TASK [Run container-puppet tasks (generate config) during step 1 with paunch] ***
> > 2020-08-28 14:11:31.397 60599 WARNING tripleoclient.v1.tripleo_deploy.Deploy [  ] Friday 28 August 2020  14:11:31 -0400 (0:00:00.302)       0:06:28.734 *********
> > 2020-08-28 14:11:32.223 60599 WARNING tripleoclient.v1.tripleo_deploy.Deploy [  ] changed: [undercloud]
> > 2020-08-28 14:11:32.325 60599 WARNING tripleoclient.v1.tripleo_deploy.Deploy [  ]
> > 2020-08-28 14:11:32.326 60599 WARNING tripleoclient.v1.tripleo_deploy.Deploy [  ] TASK [Wait for container-puppet tasks (generate config) to finish] *************
> > 2020-08-28 14:11:32.326 60599 WARNING tripleoclient.v1.tripleo_deploy.Deploy [  ] Friday 28 August 2020  14:11:32 -0400 (0:00:00.928)       0:06:29.663 *********
> > 2020-08-28 14:11:32.948 60599 WARNING tripleoclient.v1.tripleo_deploy.Deploy [  ] WAITING FOR COMPLETION: Wait for container-puppet tasks (generate config) to finish (1200 retries left).
> > . . .
> >
> > If anyone could tell roughly what is supposed to be going on here,
> > it would be great. I may be able figure out the rest.
> >
> > Greetings,
> > -- Pete



From aschultz at redhat.com  Wed Sep  2 18:28:26 2020
From: aschultz at redhat.com (Alex Schultz)
Date: Wed, 2 Sep 2020 12:28:26 -0600
Subject: [tripleo, ironic] Error: Could not retrieve ... pxelinux.0
In-Reply-To: <20200902131014.59f2553d@suzdal.zaitcev.lan>
References: <20200828144844.7787707d@suzdal.zaitcev.lan>
 <CAFsb3b78ZhNOaF7QM=kR=QxX8L3we7unuYO8xQ7xVTevH9KXHg@mail.gmail.com>
 <20200902131014.59f2553d@suzdal.zaitcev.lan>
Message-ID: <CAFsb3b7u2sncZaEgw=YdEuC5CAZkZRkqXRkkUK3TOqabZ83BFw@mail.gmail.com>

On Wed, Sep 2, 2020 at 12:10 PM Pete Zaitcev <zaitcev at redhat.com> wrote:
>
> Dear Alex,
>
> thanks for the reply. In my case, the undercloud is running on CenOS 8:
>
> [stack at undercloud ~]$ cat /etc/redhat-release
> CentOS Linux release 8.2.2004 (Core)
>
> What I'm trying to install is "upstream TripleO", if such a thing
> even exists. The packages are built for RHEL 8/CentOS 8, at least:
>
> [stack at undercloud ~]$ rpm -qf /usr/bin/openstack
> python3-openstackclient-4.0.1-0.20200817052906.bff556c.el8.noarch
> [stack at undercloud ~]$ rpm -qf /usr/share/python-tripleoclient/undercloud.conf.sample
> python3-tripleoclient-12.3.2-0.20200820055917.c15d0d0.el8.noarch
>
> I'm most curious about what a TripleO developer would do in this case.
> Surely there's a way to have some local repository of some yet unknown
> component, which I can then instrument or modify, and which is
> responsible for dealing with PXE. But what is it?
>

Since this is a puppet error, looking in puppet ironic for what to
fix/address would be the first place to do this.  Since we mount the
puppet modules from the host system, you can debug by modifying the
local modules under /usr/share/openstack-puppet/modules.  In this
particular error, it's trying to copy the ipxe file from
/usr/share/ipxe/ in the container to a different folder. It seems like
either the ipxe location has changed or the package is not installed
in the container.  You could launch an instance to inspect the
contents of the container to troubleshoot.  That being said, since
we're not seeing this in any of the CI jobs, I wonder what your
configuration(s) looks like and if you are pulling the correct
containers/repos/etc.

> Yours,
> -- Pete
>
> On Fri, 28 Aug 2020 14:00:11 -0600
> Alex Schultz <aschultz at redhat.com> wrote:
>
> > I've seen this in the past if there is a mismatch between the host OS
> > and the Containers. Centos7 host with centos8 containers or vice
> > versa.  Ussuri should be CentOS8 host OS and make sure you're pulling
> > the correct containers.  The Ironic containers have some pathing
> > mismatches when the configuration gets generated around this. It used
> > to be compatible but we broke it at some point when switching some of
> > the tftp location bits.
> >
> > Thanks,
> > -Alex
> >
> > On Fri, Aug 28, 2020 at 1:55 PM Pete Zaitcev <zaitcev at redhat.com> wrote:
> > >
> > > Hello:
> > >
> > > I wanted to give the TripleO a try, so started follow our
> > > installation guide for Ussuri, and eventually made it to
> > > "openstack undercloud install". It fails with something like this:
> > >
> > > Aug 28 10:10:53 undercloud puppet-user[48657]: Error: /Stage[main]/Ironic::Pxe/File[/var/lib/ironic/tftpboot/ipxe.efi]: Could not evaluate: Could not retrieve information from environment production source(s) file:/usr/share/ipxe/ipxe-x86_64.efi
> > > Aug 27 20:05:42 undercloud puppet-user[37048]: Error: /Stage[main]/Ironic::Pxe/Ironic::Pxe::Tftpboot_file[pxelinux.0]/File[/var/lib/ironic/tftpboot/pxelinux.0]: Could not evaluate: Could not retrieve information from environment production source(s) file:/tftpboot/pxelinux.0
> > >
> > > Does anyone have an idea what it wants?
> > >
> > > I added a couple of packages on the host system that provided
> > > the files mentioned in the message, but it made no difference.
> > > Ussuri is conteinerized anyway.
> > >
> > > Since I'm very new to this, I have no clue where to look at all.
> > > The nearest task is a wrapper of some kind, so the install-undercloud.log
> > > looks like this:
> > >
> > > 2020-08-28 14:11:31.397 60599 WARNING tripleoclient.v1.tripleo_deploy.Deploy [  ] TASK [Run container-puppet tasks (generate config) during step 1 with paunch] ***
> > > 2020-08-28 14:11:31.397 60599 WARNING tripleoclient.v1.tripleo_deploy.Deploy [  ] Friday 28 August 2020  14:11:31 -0400 (0:00:00.302)       0:06:28.734 *********
> > > 2020-08-28 14:11:32.223 60599 WARNING tripleoclient.v1.tripleo_deploy.Deploy [  ] changed: [undercloud]
> > > 2020-08-28 14:11:32.325 60599 WARNING tripleoclient.v1.tripleo_deploy.Deploy [  ]
> > > 2020-08-28 14:11:32.326 60599 WARNING tripleoclient.v1.tripleo_deploy.Deploy [  ] TASK [Wait for container-puppet tasks (generate config) to finish] *************
> > > 2020-08-28 14:11:32.326 60599 WARNING tripleoclient.v1.tripleo_deploy.Deploy [  ] Friday 28 August 2020  14:11:32 -0400 (0:00:00.928)       0:06:29.663 *********
> > > 2020-08-28 14:11:32.948 60599 WARNING tripleoclient.v1.tripleo_deploy.Deploy [  ] WAITING FOR COMPLETION: Wait for container-puppet tasks (generate config) to finish (1200 retries left).
> > > . . .
> > >
> > > If anyone could tell roughly what is supposed to be going on here,
> > > it would be great. I may be able figure out the rest.
> > >
> > > Greetings,
> > > -- Pete
>



From mnaser at vexxhost.com  Wed Sep  2 19:06:42 2020
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Wed, 2 Sep 2020 15:06:42 -0400
Subject: [tc] monthly meeting
Message-ID: <CAEs876gdBj5oGm=KWrHUJ8dGg43O8ZbgjNWN57kJpcULcy014Q@mail.gmail.com>

Hi everyone,

Here’s the agenda for our monthly TC meeting. It will happen tomorrow
(Thursday the 3rd) at 1400 UTC in #openstack-tc and I will be your
chair.

If you can’t attend, please put your name in the “Apologies for
Absence” section.

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

## ACTIVE INITIATIVES
* Follow up on past action items
* OpenStack User-facing APIs and CLIs (belmoreira)
* W cycle goal selection start
* Completion of retirement cleanup (gmann):
https://etherpad.opendev.org/p/tc-retirement-cleanup
* Audit and clean-up tags (gmann)
+ Remove tc:approved-release tag https://review.opendev.org/#/c/749363

Thank you,
Mohammed

-- 
Mohammed Naser
VEXXHOST, Inc.


From whayutin at redhat.com  Wed Sep  2 19:33:03 2020
From: whayutin at redhat.com (Wesley Hayutin)
Date: Wed, 2 Sep 2020 13:33:03 -0600
Subject: [tripleo] docker.io rate limiting
In-Reply-To: <CABE5tBasc+fsr5P2AwsQ11xBreegK+-cNZZNKjPN_eu3qg6R8Q@mail.gmail.com>
References: <CAOHJT4LT68KhRBt3vxb+D-6VpNUPgc2=JBae0nwC8xNZj2EJzQ@mail.gmail.com>
 <CABE5tBasc+fsr5P2AwsQ11xBreegK+-cNZZNKjPN_eu3qg6R8Q@mail.gmail.com>
Message-ID: <CAOHJT4+kgBxhTm_pWS7AcbmuMAwmCXJ1W-tsi0qR6uR8S7L1Qg@mail.gmail.com>

On Wed, Sep 2, 2020 at 8:18 AM Ruslanas Gžibovskis <ruslanas at lpic.lt> wrote:

> Sorry for the stupid question, but maybe there is some parameter for
> tripleo deployment not to generate and download images from docker io each
> time? since I already have it downloaded and working?
>
> Or, as I understand, I should be able to create my own snapshot of images
> and specify it as a source?
>

Yes, as a user you can download the images and push into your own local
registry and then specify your custom registry in the
container-prepare-parameters.yaml file.



>
> On Wed, 2 Sep 2020 at 13:58, Wesley Hayutin <whayutin at redhat.com> wrote:
>
>> Greetings,
>>
>> Some of you have contacted me regarding the recent news regarding
>> docker.io's new policy with regards to container pull rate limiting
>> [1].  I wanted to take the opportunity to further socialize our plan that
>> will completely remove docker.io from our upstream workflows and avoid
>> any rate limiting issues.
>>
>> We will continue to upload containers to docker.io for some time so that
>> individuals and the community can access the containers.  We will also
>> start exploring other registries like quay and newly announced github
>> container registry. These other public registries will NOT be used in our
>> upstream jobs and will only serve the communities individual contributors.
>>
>> Our test jobs have been successful and patches are starting to merge to
>> convert our upstream jobs and remove docker.io from our upstream
>> workflow.  [2].
>>
>> Standalone and multinode jobs are working quite well.  We are doing some
>> design work around branchful, update/upgrade jobs at this time.
>>
>> Thanks 0/
>>
>>
>> [1] https://hackmd.io/ermQSlQ-Q-mDtZkNN2oihQ
>> [2]
>> https://review.opendev.org/#/q/topic:new-ci-job+(status:open+OR+status:merged)
>>
>
>
> --
> Ruslanas Gžibovskis
> +370 6030 7030
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/1889eb09/attachment.html>

From yongiman at gmail.com  Thu Sep  3 00:18:28 2020
From: yongiman at gmail.com (=?UTF-8?B?7ZWc7Iq57KeE?=)
Date: Thu, 3 Sep 2020 09:18:28 +0900
Subject: [ovn][neutron][ussuri] How to configure for overlay in DPDK with
 OVN ?
In-Reply-To: <eb743897daabf4ed0ca27ff6d426fbb5b1b129dc.camel@redhat.com>
References: <CADeNzf8CCK1sp1KKZUuLkiikK=Wyxh2FAbBzBv_JGeUpG35iAA@mail.gmail.com>
 <eb743897daabf4ed0ca27ff6d426fbb5b1b129dc.camel@redhat.com>
Message-ID: <CADeNzf9r-HfWm9A-3CXhZqH3ZNZY0rhHvF7w6EM+M=5jGkjdbQ@mail.gmail.com>

Hi, Sean

Thank you for your reply.

So I should assign an ip address to the br-int bridge, if I am
understanding correctly.

Thanks,

John Haan.



2020년 9월 2일 (수) 오후 9:59, Sean Mooney <smooney at redhat.com>님이 작성:

> On Wed, 2020-09-02 at 16:23 +0900, 한승진 wrote:
> > Hi,
> >
> >
> > I’m trying to implement dpdk-ovs with ovn for our openstack environment.
> >
> >
> > I create a bond interface(tunbound) with ovs and tun0 and tun1 are slave
> > interfaces of the bond interface named tunbond.
> >
> >
> >     Bridge br-int
> >
> >         fail_mode: secure
> >
> >         datapath_type: netdev
> >
> >         Port tunbond
> >
> >             Interface tun0
> >
> >                 type: dpdk
> >
> >                 options: {dpdk-devargs="0000:1a:00.1", n_rxq="2"}
> >
> >             Interface tun1
> >
> >                 type: dpdk
> >
> >                 options: {dpdk-devargs="0000:d8:00.1", n_rxq="2"}
> >
> >         Port br-int
> >
> >             Interface br-int
> >
> >                 type: internal
> >
> > Now, I need to configure remote-ovn options to the ovs.
> >
> >
> > *I am confused how can I define the IP address of the bonded interface
> with
> > ovs?*
> you dont you set the tunnel local ip on the ovs bridge containing the bond.
> when a inteface is managed by ovs (with the excption of the bridge port or
> type internal ports)
> asinging an ip to the interface will do nothing as ovs hooks the packets
> beofre they reach the ip layer of the kernel
> networking stack.
>
> so to make sure that the kernel routes the network packets vi the ovs
> bridge you need to assign the tunnel local ip to
> the ovs bridge with the bound. so br-int in this case
>
> this will cause that bridge to respond to arps form the tunnel local ip
> and that will cause the back leaning table in
> ovs to be populated correctly with the remote mac address for the remote
> tunnel endpoints via the bound.
>
> if you use ovs-appctl and look at the dataplane(not oepnflow) flows you
> will see that the tunnel endcap flow is followed
> by an out_port action instead of an output action which renques the packet
> as if it arrived on the port
> so when the packet is encaped with the geneve header it will be reporced
> as if it came form the bridge local port and
> then mac learing/the normal action woudl forward it to the bond. at least
> that is how it would work for ml2/ovs
>
> if we do not have the normal action for that case we would need explcit
> openflow rules to send the packet to the bound.
>
> if you dont have the local tunnel endpoint ip on the brige however the
> tunnel traffic will not be dpdk acclerated so
> that is important to have set correctly.
> >
> >
> > Theses are commands for connect remote ovn services.
> >
> >
> > ovs-vsctl set open . external-ids:ovn-remote=tcp:{controller ip}:6642
> >
> > ovs-vsctl set open . external-ids:ovn-encap-type=geneve
> >
> > *1*
> >
> >
> > This below command make it me confused.
> >
> >
> > ovs-vsctl set open . external-ids:ovn-encap-ip={local ip}
> >
> >
> > How should I resolve this issue?
> >
> >
> > Regards,
> >
> >
> > John Haan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/007bb054/attachment.html>

From satish.txt at gmail.com  Thu Sep  3 04:30:51 2020
From: satish.txt at gmail.com (Satish Patel)
Date: Thu, 3 Sep 2020 00:30:51 -0400
Subject: senlin auto scaling question
In-Reply-To: <CAEs876jnfQOWEwHrkfscx1z3B2Kc6a7F0tVpVHyoPMHmARcg3Q@mail.gmail.com>
References: <CAPgF-frPN-Jqq1-UHgP0=Dsc=0AN1sE=VgwUqBWfMO-GObLBhg@mail.gmail.com>
 <CAEs876jnfQOWEwHrkfscx1z3B2Kc6a7F0tVpVHyoPMHmARcg3Q@mail.gmail.com>
Message-ID: <CAPgF-fp2Pe0M4CESpT41Qo-RL_Obhs6OHua6c_0WbeQQyvYBfQ@mail.gmail.com>

Mohammed,

Dis-regard my earlier emails. i found senlin does auto-healing. you
need to create a health policy and attach it to your cluster.

Here is my policy I created to monitor nodes' heath and if for some
reason it dies or crashes, senlin will auto create that instance to
fulfill the need.

type: senlin.policy.health
version: 1.1
description: A policy for maintaining node health from a cluster.
properties:
  detection:
    # Number of seconds between two adjacent checking
    interval: 60

    detection_modes:
      # Type for health checking, valid values include:
      # NODE_STATUS_POLLING, NODE_STATUS_POLL_URL, LIFECYCLE_EVENTS
      - type: NODE_STATUS_POLLING

  recovery:
    # Action that can be retried on a failed node, will improve to
    # support multiple actions in the future. Valid values include:
    # REBOOT, REBUILD, RECREATE
    actions:
      - name: RECREATE


** Here is the POC

[root at os-infra-1-utility-container-e139058e ~]# nova list
+--------------------------------------+---------------+--------+------------+-------------+-------------------+
| ID                                   | Name          | Status | Task
State | Power State | Networks          |
+--------------------------------------+---------------+--------+------------+-------------+-------------------+
| 38ba7f7c-2f5f-4502-a5d0-6c4841d6d145 | cirros_server | ACTIVE | -
      | Running     | net1=192.168.1.26 |
| ba55deb6-9488-4455-a472-a0a957cb388a | cirros_server | ACTIVE | -
      | Running     | net1=192.168.1.14 |
+--------------------------------------+---------------+--------+------------+-------------+-------------------+

** Lets delete one of the nodes.

[root at os-infra-1-utility-container-e139058e ~]# nova delete
ba55deb6-9488-4455-a472-a0a957cb388a
Request to delete server ba55deb6-9488-4455-a472-a0a957cb388a has been accepted.

** After a few min i can see RECOVERING nodes.

[root at os-infra-1-utility-container-e139058e ~]# openstack cluster node list
+----------+---------------+-------+------------+------------+-------------+--------------+----------------------+----------------------+---------+
| id       | name          | index | status     | cluster_id |
physical_id | profile_name | created_at           | updated_at
  | tainted |
+----------+---------------+-------+------------+------------+-------------+--------------+----------------------+----------------------+---------+
| d4a8f219 | node-YPsjB6bV |     6 | RECOVERING | 091fbd52   |
ba55deb6    | myserver     | 2020-09-02T21:01:47Z |
2020-09-03T04:01:58Z | False   |
| bc50c0b9 | node-hoiHkRcS |     7 | ACTIVE     | 091fbd52   |
38ba7f7c    | myserver     | 2020-09-03T03:40:29Z |
2020-09-03T03:57:58Z | False   |
+----------+---------------+-------+------------+------------+-------------+--------------+----------------------+----------------------+---------+

** Finally it's up and running with a new ip address.

[root at os-infra-1-utility-container-e139058e ~]# nova list
+--------------------------------------+---------------+--------+------------+-------------+-------------------+
| ID                                   | Name          | Status | Task
State | Power State | Networks          |
+--------------------------------------+---------------+--------+------------+-------------+-------------------+
| 38ba7f7c-2f5f-4502-a5d0-6c4841d6d145 | cirros_server | ACTIVE | -
      | Running     | net1=192.168.1.26 |
| 73a658cd-c40a-45d8-9b57-cc9e6c2b4dc1 | cirros_server | ACTIVE | -
      | Running     | net1=192.168.1.17 |
+--------------------------------------+---------------+--------+------------+-------------+-------------------+

On Tue, Sep 1, 2020 at 8:51 AM Mohammed Naser <mnaser at vexxhost.com> wrote:
>
> Hi Satish,
>
> I'm interested by this, did you end up finding a solution for this?
>
> Thanks,
> Mohammed
>
> On Thu, Aug 27, 2020 at 1:54 PM Satish Patel <satish.txt at gmail.com> wrote:
> >
> > Folks,
> >
> > I have created very simple cluster using following command
> >
> > openstack cluster create --profile myserver --desired-capacity 2
> > --min-size 2 --max-size 3 --strict my-asg
> >
> > It spun up 2 vm immediately now because the desired capacity is 2 so I
> > am assuming if any node dies in the cluster it should spin up node to
> > make count 2 right?
> >
> > so i killed one of node with "nove delete <instance-foo-1>"  but
> > senlin didn't create node automatically to make desired capacity 2 (In
> > AWS when you kill node in ASG it will create new node so is this
> > senlin different then AWS?)
> >
>
>
> --
> Mohammed Naser
> VEXXHOST, Inc.


From duc.openstack at gmail.com  Thu Sep  3 05:51:37 2020
From: duc.openstack at gmail.com (Duc Truong)
Date: Wed, 2 Sep 2020 22:51:37 -0700
Subject: senlin auto scaling question
In-Reply-To: <CAPgF-fp2Pe0M4CESpT41Qo-RL_Obhs6OHua6c_0WbeQQyvYBfQ@mail.gmail.com>
References: <CAPgF-frPN-Jqq1-UHgP0=Dsc=0AN1sE=VgwUqBWfMO-GObLBhg@mail.gmail.com>
 <CAEs876jnfQOWEwHrkfscx1z3B2Kc6a7F0tVpVHyoPMHmARcg3Q@mail.gmail.com>
 <CAPgF-fp2Pe0M4CESpT41Qo-RL_Obhs6OHua6c_0WbeQQyvYBfQ@mail.gmail.com>
Message-ID: <CAN81NT6wddD3TTwt80dQG7wfENtZ57gpR4gLEHCYXD_uMkdgGQ@mail.gmail.com>

Satish,

I’m glad you were able to find the answer. Just to clarify, your original
email mentioned auto scaling in its title. Auto scaling means creating or
deleting nodes as load goes up or down. Senlin supports scaling clusters
but requires another service to perform the decision making and triggering
of the scaling (i.e. the auto in auto scaling).

But as you correctly pointed out auto healing is fully supported by Senlin
on its own with its health policy.

Duc Truong


On Wed, Sep 2, 2020 at 9:31 PM Satish Patel <satish.txt at gmail.com> wrote:

> Mohammed,
>
> Dis-regard my earlier emails. i found senlin does auto-healing. you
> need to create a health policy and attach it to your cluster.
>
> Here is my policy I created to monitor nodes' heath and if for some
> reason it dies or crashes, senlin will auto create that instance to
> fulfill the need.
>
> type: senlin.policy.health
> version: 1.1
> description: A policy for maintaining node health from a cluster.
> properties:
>   detection:
>     # Number of seconds between two adjacent checking
>     interval: 60
>
>     detection_modes:
>       # Type for health checking, valid values include:
>       # NODE_STATUS_POLLING, NODE_STATUS_POLL_URL, LIFECYCLE_EVENTS
>       - type: NODE_STATUS_POLLING
>
>   recovery:
>     # Action that can be retried on a failed node, will improve to
>     # support multiple actions in the future. Valid values include:
>     # REBOOT, REBUILD, RECREATE
>     actions:
>       - name: RECREATE
>
>
> ** Here is the POC
>
> [root at os-infra-1-utility-container-e139058e ~]# nova list
>
> +--------------------------------------+---------------+--------+------------+-------------+-------------------+
> | ID                                   | Name          | Status | Task
> State | Power State | Networks          |
>
> +--------------------------------------+---------------+--------+------------+-------------+-------------------+
> | 38ba7f7c-2f5f-4502-a5d0-6c4841d6d145 | cirros_server | ACTIVE | -
>       | Running     | net1=192.168.1.26 |
> | ba55deb6-9488-4455-a472-a0a957cb388a | cirros_server | ACTIVE | -
>       | Running     | net1=192.168.1.14 |
>
> +--------------------------------------+---------------+--------+------------+-------------+-------------------+
>
> ** Lets delete one of the nodes.
>
> [root at os-infra-1-utility-container-e139058e ~]# nova delete
> ba55deb6-9488-4455-a472-a0a957cb388a
> Request to delete server ba55deb6-9488-4455-a472-a0a957cb388a has been
> accepted.
>
> ** After a few min i can see RECOVERING nodes.
>
> [root at os-infra-1-utility-container-e139058e ~]# openstack cluster node
> list
>
> +----------+---------------+-------+------------+------------+-------------+--------------+----------------------+----------------------+---------+
> | id       | name          | index | status     | cluster_id |
> physical_id | profile_name | created_at           | updated_at
>   | tainted |
>
> +----------+---------------+-------+------------+------------+-------------+--------------+----------------------+----------------------+---------+
> | d4a8f219 | node-YPsjB6bV |     6 | RECOVERING | 091fbd52   |
> ba55deb6    | myserver     | 2020-09-02T21:01:47Z |
> 2020-09-03T04:01:58Z | False   |
> | bc50c0b9 | node-hoiHkRcS |     7 | ACTIVE     | 091fbd52   |
> 38ba7f7c    | myserver     | 2020-09-03T03:40:29Z |
> 2020-09-03T03:57:58Z | False   |
>
> +----------+---------------+-------+------------+------------+-------------+--------------+----------------------+----------------------+---------+
>
> ** Finally it's up and running with a new ip address.
>
> [root at os-infra-1-utility-container-e139058e ~]# nova list
>
> +--------------------------------------+---------------+--------+------------+-------------+-------------------+
> | ID                                   | Name          | Status | Task
> State | Power State | Networks          |
>
> +--------------------------------------+---------------+--------+------------+-------------+-------------------+
> | 38ba7f7c-2f5f-4502-a5d0-6c4841d6d145 | cirros_server | ACTIVE | -
>       | Running     | net1=192.168.1.26 |
> | 73a658cd-c40a-45d8-9b57-cc9e6c2b4dc1 | cirros_server | ACTIVE | -
>       | Running     | net1=192.168.1.17 |
>
> +--------------------------------------+---------------+--------+------------+-------------+-------------------+
>
> On Tue, Sep 1, 2020 at 8:51 AM Mohammed Naser <mnaser at vexxhost.com> wrote:
> >
> > Hi Satish,
> >
> > I'm interested by this, did you end up finding a solution for this?
> >
> > Thanks,
> > Mohammed
> >
> > On Thu, Aug 27, 2020 at 1:54 PM Satish Patel <satish.txt at gmail.com>
> wrote:
> > >
> > > Folks,
> > >
> > > I have created very simple cluster using following command
> > >
> > > openstack cluster create --profile myserver --desired-capacity 2
> > > --min-size 2 --max-size 3 --strict my-asg
> > >
> > > It spun up 2 vm immediately now because the desired capacity is 2 so I
> > > am assuming if any node dies in the cluster it should spin up node to
> > > make count 2 right?
> > >
> > > so i killed one of node with "nove delete <instance-foo-1>"  but
> > > senlin didn't create node automatically to make desired capacity 2 (In
> > > AWS when you kill node in ASG it will create new node so is this
> > > senlin different then AWS?)
> > >
> >
> >
> > --
> > Mohammed Naser
> > VEXXHOST, Inc.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200902/bfcca8fc/attachment.html>

From cjeanner at redhat.com  Thu Sep  3 05:54:22 2020
From: cjeanner at redhat.com (=?UTF-8?Q?C=c3=a9dric_Jeanneret?=)
Date: Thu, 3 Sep 2020 07:54:22 +0200
Subject: [tripleo] docker.io rate limiting
In-Reply-To: <CAOHJT4+kgBxhTm_pWS7AcbmuMAwmCXJ1W-tsi0qR6uR8S7L1Qg@mail.gmail.com>
References: <CAOHJT4LT68KhRBt3vxb+D-6VpNUPgc2=JBae0nwC8xNZj2EJzQ@mail.gmail.com>
 <CABE5tBasc+fsr5P2AwsQ11xBreegK+-cNZZNKjPN_eu3qg6R8Q@mail.gmail.com>
 <CAOHJT4+kgBxhTm_pWS7AcbmuMAwmCXJ1W-tsi0qR6uR8S7L1Qg@mail.gmail.com>
Message-ID: <01b6ff63-1929-599f-a492-4837edc44312@redhat.com>



On 9/2/20 9:33 PM, Wesley Hayutin wrote:
> 
> 
> On Wed, Sep 2, 2020 at 8:18 AM Ruslanas Gžibovskis <ruslanas at lpic.lt
> <mailto:ruslanas at lpic.lt>> wrote:
> 
>     Sorry for the stupid question, but maybe there is some parameter for
>     tripleo deployment not to generate and download images from docker
>     io each time? since I already have it downloaded and working?
> 
>     Or, as I understand, I should be able to create my own snapshot of
>     images and specify it as a source?
> 
> 
> Yes, as a user you can download the images and push into your own local
> registry and then specify your custom registry in the
> container-prepare-parameters.yaml file.  

that's basically what I'm doing at home, in order to avoid the network
overhead when deploying N times.

Now, there's a new thing with github that could also be leveraged at
some point:
https://github.blog/2020-09-01-introducing-github-container-registry/

Though the solution proposed by Wes and his Team will be more efficient
imho - fresh build of containers within CI makes perfectly sense. And
using TCIB[1] for that task also provides a new layer of CI for this
central tool, which is just about perfect!

Cheers,

C.

[1]
https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/3rd_party.html#building-new-containers-with-tripleo-container-image-build

> 
>  
> 
> 
>     On Wed, 2 Sep 2020 at 13:58, Wesley Hayutin <whayutin at redhat.com
>     <mailto:whayutin at redhat.com>> wrote:
> 
>         Greetings,
> 
>         Some of you have contacted me regarding the recent news
>         regarding docker.io <http://docker.io>'s new policy with regards
>         to container pull rate limiting [1].  I wanted to take the
>         opportunity to further socialize our plan that will completely
>         remove docker.io <http://docker.io> from our upstream workflows
>         and avoid any rate limiting issues.
> 
>         We will continue to upload containers to docker.io
>         <http://docker.io> for some time so that individuals and the
>         community can access the containers.  We will also start
>         exploring other registries like quay and newly announced github
>         container registry. These other public registries will NOT be
>         used in our upstream jobs and will only serve the communities
>         individual contributors.
> 
>         Our test jobs have been successful and patches are starting to
>         merge to convert our upstream jobs and remove docker.io
>         <http://docker.io> from our upstream workflow.  [2].
> 
>         Standalone and multinode jobs are working quite well.  We are
>         doing some design work around branchful, update/upgrade jobs at
>         this time.
> 
>         Thanks 0/
> 
> 
>         [1] https://hackmd.io/ermQSlQ-Q-mDtZkNN2oihQ
>         [2] https://review.opendev.org/#/q/topic:new-ci-job+(status:open+OR+status:merged)
> 
> 
> 
>     -- 
>     Ruslanas Gžibovskis
>     +370 6030 7030
> 

-- 
Cédric Jeanneret (He/Him/His)
Sr. Software Engineer - OpenStack Platform
Deployment Framework TC
Red Hat EMEA
https://www.redhat.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/c0ef329c/attachment.sig>

From yasufum.o at gmail.com  Thu Sep  3 06:02:05 2020
From: yasufum.o at gmail.com (Yasufumi Ogawa)
Date: Thu, 3 Sep 2020 15:02:05 +0900
Subject: [tacker] Wallaby vPTG
In-Reply-To: <CAJ6yrQjif7cLvS0FQkm1vKa-GHV+Zn2Y781nscjtXWnAn73hZQ@mail.gmail.com>
References: <e159766b-8508-33fc-d90b-97278356367e@gmail.com>
 <CAJ6yrQjif7cLvS0FQkm1vKa-GHV+Zn2Y781nscjtXWnAn73hZQ@mail.gmail.com>
Message-ID: <ee9a24c6-1666-0a30-1c47-61ab4d7141bf@gmail.com>

Hi Kendall,

Thanks for the notice! I submitted my survey.

Yasufumi

On 2020/09/03 2:19, Kendall Nelson wrote:
> Hello Yasufumi!
> 
> Can I get you to fill out the survey for Tacker as well?
> 
> https://openstackfoundation.formstack.com/forms/oct2020_vptg_survey
> 
> Thanks!
> 
> -Kendall (diablo_rojo)
> 
> On Mon, Aug 31, 2020 at 10:25 PM Yasufumi Ogawa <yasufum.o at gmail.com 
> <mailto:yasufum.o at gmail.com>> wrote:
> 
>     Hi team,
> 
>     I booked our slots, 27-29 Oct 6am-8am UTC, for the next vPTG[1] as we
>     agreed in previous irc meeting. I also prepared an etherpad [2], so
>     please add your name and suggestions.
> 
>     [1] https://ethercalc.openstack.org/7xp2pcbh1ncb
>     [2] https://etherpad.opendev.org/p/Tacker-PTG-Wallaby
> 
>     Thanks,
>     Yasufumi
> 


From satish.txt at gmail.com  Thu Sep  3 06:09:29 2020
From: satish.txt at gmail.com (Satish Patel)
Date: Thu, 3 Sep 2020 02:09:29 -0400
Subject: senlin auto scaling question
In-Reply-To: <CAN81NT6wddD3TTwt80dQG7wfENtZ57gpR4gLEHCYXD_uMkdgGQ@mail.gmail.com>
References: <CAN81NT6wddD3TTwt80dQG7wfENtZ57gpR4gLEHCYXD_uMkdgGQ@mail.gmail.com>
Message-ID: <4CD8DEAE-CF2D-42CB-BCAF-D8BB08B0DD54@gmail.com>

Sorry about email subject title if that got you confused. But look like now we are on same page :)

Sent from my iPhone

> On Sep 3, 2020, at 1:51 AM, Duc Truong <duc.openstack at gmail.com> wrote:
> 
> 
> Satish,
> 
> I’m glad you were able to find the answer. Just to clarify, your original email mentioned auto scaling in its title. Auto scaling means creating or deleting nodes as load goes up or down. Senlin supports scaling clusters but requires another service to perform the decision making and triggering of the scaling (i.e. the auto in auto scaling).
> 
> But as you correctly pointed out auto healing is fully supported by Senlin on its own with its health policy. 
> 
> Duc Truong
> 
> 
>> On Wed, Sep 2, 2020 at 9:31 PM Satish Patel <satish.txt at gmail.com> wrote:
>> Mohammed,
>> 
>> Dis-regard my earlier emails. i found senlin does auto-healing. you
>> need to create a health policy and attach it to your cluster.
>> 
>> Here is my policy I created to monitor nodes' heath and if for some
>> reason it dies or crashes, senlin will auto create that instance to
>> fulfill the need.
>> 
>> type: senlin.policy.health
>> version: 1.1
>> description: A policy for maintaining node health from a cluster.
>> properties:
>>   detection:
>>     # Number of seconds between two adjacent checking
>>     interval: 60
>> 
>>     detection_modes:
>>       # Type for health checking, valid values include:
>>       # NODE_STATUS_POLLING, NODE_STATUS_POLL_URL, LIFECYCLE_EVENTS
>>       - type: NODE_STATUS_POLLING
>> 
>>   recovery:
>>     # Action that can be retried on a failed node, will improve to
>>     # support multiple actions in the future. Valid values include:
>>     # REBOOT, REBUILD, RECREATE
>>     actions:
>>       - name: RECREATE
>> 
>> 
>> ** Here is the POC
>> 
>> [root at os-infra-1-utility-container-e139058e ~]# nova list
>> +--------------------------------------+---------------+--------+------------+-------------+-------------------+
>> | ID                                   | Name          | Status | Task
>> State | Power State | Networks          |
>> +--------------------------------------+---------------+--------+------------+-------------+-------------------+
>> | 38ba7f7c-2f5f-4502-a5d0-6c4841d6d145 | cirros_server | ACTIVE | -
>>       | Running     | net1=192.168.1.26 |
>> | ba55deb6-9488-4455-a472-a0a957cb388a | cirros_server | ACTIVE | -
>>       | Running     | net1=192.168.1.14 |
>> +--------------------------------------+---------------+--------+------------+-------------+-------------------+
>> 
>> ** Lets delete one of the nodes.
>> 
>> [root at os-infra-1-utility-container-e139058e ~]# nova delete
>> ba55deb6-9488-4455-a472-a0a957cb388a
>> Request to delete server ba55deb6-9488-4455-a472-a0a957cb388a has been accepted.
>> 
>> ** After a few min i can see RECOVERING nodes.
>> 
>> [root at os-infra-1-utility-container-e139058e ~]# openstack cluster node list
>> +----------+---------------+-------+------------+------------+-------------+--------------+----------------------+----------------------+---------+
>> | id       | name          | index | status     | cluster_id |
>> physical_id | profile_name | created_at           | updated_at
>>   | tainted |
>> +----------+---------------+-------+------------+------------+-------------+--------------+----------------------+----------------------+---------+
>> | d4a8f219 | node-YPsjB6bV |     6 | RECOVERING | 091fbd52   |
>> ba55deb6    | myserver     | 2020-09-02T21:01:47Z |
>> 2020-09-03T04:01:58Z | False   |
>> | bc50c0b9 | node-hoiHkRcS |     7 | ACTIVE     | 091fbd52   |
>> 38ba7f7c    | myserver     | 2020-09-03T03:40:29Z |
>> 2020-09-03T03:57:58Z | False   |
>> +----------+---------------+-------+------------+------------+-------------+--------------+----------------------+----------------------+---------+
>> 
>> ** Finally it's up and running with a new ip address.
>> 
>> [root at os-infra-1-utility-container-e139058e ~]# nova list
>> +--------------------------------------+---------------+--------+------------+-------------+-------------------+
>> | ID                                   | Name          | Status | Task
>> State | Power State | Networks          |
>> +--------------------------------------+---------------+--------+------------+-------------+-------------------+
>> | 38ba7f7c-2f5f-4502-a5d0-6c4841d6d145 | cirros_server | ACTIVE | -
>>       | Running     | net1=192.168.1.26 |
>> | 73a658cd-c40a-45d8-9b57-cc9e6c2b4dc1 | cirros_server | ACTIVE | -
>>       | Running     | net1=192.168.1.17 |
>> +--------------------------------------+---------------+--------+------------+-------------+-------------------+
>> 
>> On Tue, Sep 1, 2020 at 8:51 AM Mohammed Naser <mnaser at vexxhost.com> wrote:
>> >
>> > Hi Satish,
>> >
>> > I'm interested by this, did you end up finding a solution for this?
>> >
>> > Thanks,
>> > Mohammed
>> >
>> > On Thu, Aug 27, 2020 at 1:54 PM Satish Patel <satish.txt at gmail.com> wrote:
>> > >
>> > > Folks,
>> > >
>> > > I have created very simple cluster using following command
>> > >
>> > > openstack cluster create --profile myserver --desired-capacity 2
>> > > --min-size 2 --max-size 3 --strict my-asg
>> > >
>> > > It spun up 2 vm immediately now because the desired capacity is 2 so I
>> > > am assuming if any node dies in the cluster it should spin up node to
>> > > make count 2 right?
>> > >
>> > > so i killed one of node with "nove delete <instance-foo-1>"  but
>> > > senlin didn't create node automatically to make desired capacity 2 (In
>> > > AWS when you kill node in ASG it will create new node so is this
>> > > senlin different then AWS?)
>> > >
>> >
>> >
>> > --
>> > Mohammed Naser
>> > VEXXHOST, Inc.
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/abf8ef62/attachment.html>

From ruslanas at lpic.lt  Thu Sep  3 06:10:43 2020
From: ruslanas at lpic.lt (=?UTF-8?Q?Ruslanas_G=C5=BEibovskis?=)
Date: Thu, 3 Sep 2020 09:10:43 +0300
Subject: [tripleo] docker.io rate limiting
In-Reply-To: <01b6ff63-1929-599f-a492-4837edc44312@redhat.com>
References: <CAOHJT4LT68KhRBt3vxb+D-6VpNUPgc2=JBae0nwC8xNZj2EJzQ@mail.gmail.com>
 <CABE5tBasc+fsr5P2AwsQ11xBreegK+-cNZZNKjPN_eu3qg6R8Q@mail.gmail.com>
 <CAOHJT4+kgBxhTm_pWS7AcbmuMAwmCXJ1W-tsi0qR6uR8S7L1Qg@mail.gmail.com>
 <01b6ff63-1929-599f-a492-4837edc44312@redhat.com>
Message-ID: <CABE5tBZz9cbG+SzCXU_swGnLwMXdXwrVuspNCLvs9GLB67dvow@mail.gmail.com>

I am a complete noob in containers, and especially in images. is there a
small "howto" get all OSP related images and (upload to local storage is
podman pull docker.io/tripleou/*:current-tripelo ), but how to get a full
list?

Cause when  I specify undercloud itself :) it do not have
ceilometer-compute, but I have ceilometer disabled, so I believe this is
why it did not download that image. but in general, as I understood, it
checks all and then selects what it needs?

On Thu, 3 Sep 2020 at 08:57, Cédric Jeanneret <cjeanner at redhat.com> wrote:

>
>
> On 9/2/20 9:33 PM, Wesley Hayutin wrote:
> >
> >
> > On Wed, Sep 2, 2020 at 8:18 AM Ruslanas Gžibovskis <ruslanas at lpic.lt
> > <mailto:ruslanas at lpic.lt>> wrote:
> >
> >     Sorry for the stupid question, but maybe there is some parameter for
> >     tripleo deployment not to generate and download images from docker
> >     io each time? since I already have it downloaded and working?
> >
> >     Or, as I understand, I should be able to create my own snapshot of
> >     images and specify it as a source?
> >
> >
> > Yes, as a user you can download the images and push into your own local
> > registry and then specify your custom registry in the
> > container-prepare-parameters.yaml file.
>
> that's basically what I'm doing at home, in order to avoid the network
> overhead when deploying N times.
>
> Now, there's a new thing with github that could also be leveraged at
> some point:
> https://github.blog/2020-09-01-introducing-github-container-registry/
>
> Though the solution proposed by Wes and his Team will be more efficient
> imho - fresh build of containers within CI makes perfectly sense. And
> using TCIB[1] for that task also provides a new layer of CI for this
> central tool, which is just about perfect!
>
> Cheers,
>
> C.
>
> [1]
>
> https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/3rd_party.html#building-new-containers-with-tripleo-container-image-build
>
> >
> >
> >
> >
> >     On Wed, 2 Sep 2020 at 13:58, Wesley Hayutin <whayutin at redhat.com
> >     <mailto:whayutin at redhat.com>> wrote:
> >
> >         Greetings,
> >
> >         Some of you have contacted me regarding the recent news
> >         regarding docker.io <http://docker.io>'s new policy with regards
> >         to container pull rate limiting [1].  I wanted to take the
> >         opportunity to further socialize our plan that will completely
> >         remove docker.io <http://docker.io> from our upstream workflows
> >         and avoid any rate limiting issues.
> >
> >         We will continue to upload containers to docker.io
> >         <http://docker.io> for some time so that individuals and the
> >         community can access the containers.  We will also start
> >         exploring other registries like quay and newly announced github
> >         container registry. These other public registries will NOT be
> >         used in our upstream jobs and will only serve the communities
> >         individual contributors.
> >
> >         Our test jobs have been successful and patches are starting to
> >         merge to convert our upstream jobs and remove docker.io
> >         <http://docker.io> from our upstream workflow.  [2].
> >
> >         Standalone and multinode jobs are working quite well.  We are
> >         doing some design work around branchful, update/upgrade jobs at
> >         this time.
> >
> >         Thanks 0/
> >
> >
> >         [1] https://hackmd.io/ermQSlQ-Q-mDtZkNN2oihQ
> >         [2]
> https://review.opendev.org/#/q/topic:new-ci-job+(status:open+OR+status:merged)
> >
> >
> >
> >     --
> >     Ruslanas Gžibovskis
> >     +370 6030 7030
> >
>
> --
> Cédric Jeanneret (He/Him/His)
> Sr. Software Engineer - OpenStack Platform
> Deployment Framework TC
> Red Hat EMEA
> https://www.redhat.com/
>
>

-- 
Ruslanas Gžibovskis
+370 6030 7030
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/743e5979/attachment-0001.html>

From cjeanner at redhat.com  Thu Sep  3 09:47:58 2020
From: cjeanner at redhat.com (=?UTF-8?Q?C=c3=a9dric_Jeanneret?=)
Date: Thu, 3 Sep 2020 11:47:58 +0200
Subject: [tripleo] docker.io rate limiting
In-Reply-To: <CAOHJT4LT68KhRBt3vxb+D-6VpNUPgc2=JBae0nwC8xNZj2EJzQ@mail.gmail.com>
References: <CAOHJT4LT68KhRBt3vxb+D-6VpNUPgc2=JBae0nwC8xNZj2EJzQ@mail.gmail.com>
Message-ID: <38d87625-d81a-9fb7-f43c-bb75a14e2984@redhat.com>

Hey Wes,

stupid question: what about the molecule tests? Since they are running
within containers (centos-8, centos-7, maybe/probably ubi8 soon), we
might hit some limitations there.... Unless we're NOT using docker.io
already?

Cheers,

C.

On 9/2/20 1:54 PM, Wesley Hayutin wrote:
> Greetings,
> 
> Some of you have contacted me regarding the recent news regarding
> docker.io <http://docker.io>'s new policy with regards to container pull
> rate limiting [1].  I wanted to take the opportunity to further
> socialize our plan that will completely remove docker.io
> <http://docker.io> from our upstream workflows and avoid any rate
> limiting issues.
> 
> We will continue to upload containers to docker.io <http://docker.io>
> for some time so that individuals and the community can access the
> containers.  We will also start exploring other registries like quay and
> newly announced github container registry. These other public registries
> will NOT be used in our upstream jobs and will only serve the
> communities individual contributors.
> 
> Our test jobs have been successful and patches are starting to merge to
> convert our upstream jobs and remove docker.io <http://docker.io> from
> our upstream workflow.  [2].
> 
> Standalone and multinode jobs are working quite well.  We are doing some
> design work around branchful, update/upgrade jobs at this time.
> 
> Thanks 0/
> 
> 
> [1] https://hackmd.io/ermQSlQ-Q-mDtZkNN2oihQ
> [2] https://review.opendev.org/#/q/topic:new-ci-job+(status:open+OR+status:merged)

-- 
Cédric Jeanneret (He/Him/His)
Sr. Software Engineer - OpenStack Platform
Deployment Framework TC
Red Hat EMEA
https://www.redhat.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/52dc3b36/attachment.sig>

From grant at civo.com  Thu Sep  3 09:59:25 2020
From: grant at civo.com (Grant Morley)
Date: Thu, 3 Sep 2020 10:59:25 +0100
Subject: Issue with libvirt unable to kill processes
Message-ID: <2151e1e5-ffeb-52b2-bd8f-68d2f8d93d36@civo.com>

Hi All,

I was wondering if anyone has come across an issue with libvirt 
seemingly having an issue with instances all of a sudden "locking up" 
with the following error:

Failed to terminate process 2263874 with SIGKILL: Device or resource busy

In the nova logs I am seeing:

2020-09-03 09:13:43.208 2659995 INFO nova.compute.manager 
[req-7ffb9b7c-799b-40dc-be04-598bfda2e2fc 
6ddb647baf9343b09d7f8f7a32b0b43d 8cce5e1532e6435a90b168077664bbdf - 
default default] [instance: f3a8c916-28f5-432d-9b8e-c3056d2dee5a] 
Rebooting instance
2020-09-03 09:15:52.429 2659995 WARNING nova.virt.libvirt.driver 
[req-7ffb9b7c-799b-40dc-be04-598bfda2e2fc 
6ddb647baf9343b09d7f8f7a32b0b43d 8cce5e1532e6435a90b168077664bbdf - 
default default] [instance: f3a8c916-28f5-432d-9b8e-c3056d2dee5a] Failed 
to soft reboot instance. Trying hard reboot.
2020-09-03 09:16:32.450 2659995 WARNING nova.virt.libvirt.driver 
[req-7ffb9b7c-799b-40dc-be04-598bfda2e2fc 
6ddb647baf9343b09d7f8f7a32b0b43d 8cce5e1532e6435a90b168077664bbdf - 
default default] [instance: f3a8c916-28f5-432d-9b8e-c3056d2dee5a] Error 
from libvirt during destroy. Code=38 Error=Failed to terminate process 
2263874 with SIGKILL: Device or resource busy; attempt 1 of 3: 
libvirtError: Failed to terminate process 2263874 with SIGKILL: Device 
or resource busy
2020-09-03 09:17:12.484 2659995 WARNING nova.virt.libvirt.driver 
[req-7ffb9b7c-799b-40dc-be04-598bfda2e2fc 
6ddb647baf9343b09d7f8f7a32b0b43d 8cce5e1532e6435a90b168077664bbdf - 
default default] [instance: f3a8c916-28f5-432d-9b8e-c3056d2dee5a] Error 
from libvirt during destroy. Code=38 Error=Failed to terminate process 
2263874 with SIGKILL: Device or resource busy; attempt 2 of 3: 
libvirtError: Failed to terminate process 2263874 with SIGKILL: Device 
or resource busy
2020-09-03 09:17:52.516 2659995 WARNING nova.virt.libvirt.driver 
[req-7ffb9b7c-799b-40dc-be04-598bfda2e2fc 
6ddb647baf9343b09d7f8f7a32b0b43d 8cce5e1532e6435a90b168077664bbdf - 
default default] [instance: f3a8c916-28f5-432d-9b8e-c3056d2dee5a] Error 
from libvirt during destroy. Code=38 Error=Failed to terminate process 
2263874 with SIGKILL: Device or resource busy; attempt 3 of 3: 
libvirtError: Failed to terminate process 2263874 with SIGKILL: Device 
or resource busy
2020-09-03 09:17:52.526 2659995 ERROR nova.compute.manager 
[req-7ffb9b7c-799b-40dc-be04-598bfda2e2fc 
6ddb647baf9343b09d7f8f7a32b0b43d 8cce5e1532e6435a90b168077664bbdf - 
default default] [instance: f3a8c916-28f5-432d-9b8e-c3056d2dee5a] Cannot 
reboot instance: Failed to terminate process 2263874 with SIGKILL: 
Device or resource busy: libvirtError: Failed to terminate process 
2263874 with SIGKILL: Device or resource busy
2020-09-03 09:17:53.026 2659995 INFO nova.compute.manager 
[req-7ffb9b7c-799b-40dc-be04-598bfda2e2fc 
6ddb647baf9343b09d7f8f7a32b0b43d 8cce5e1532e6435a90b168077664bbdf - 
default default] [instance: f3a8c916-28f5-432d-9b8e-c3056d2dee5a] 
Successfully reverted task state from reboot_started on failure for 
instance.

It seems to be caused when a reboot happens to an instance.

If you reset the state and try again, the same error occurs.  You also 
seemingly cannot kill off any libvirt process that is attached to that 
instance.

To me it looks like it could be a kernel issue with libvirt but I could 
be wrong?

Does anyone know of a workaround for this other than maybe restarting a 
compute host?

Many thanks,




From mnaser at vexxhost.com  Thu Sep  3 10:23:12 2020
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Thu, 3 Sep 2020 06:23:12 -0400
Subject: senlin auto scaling question
In-Reply-To: <CAPgF-fp2Pe0M4CESpT41Qo-RL_Obhs6OHua6c_0WbeQQyvYBfQ@mail.gmail.com>
References: <CAPgF-frPN-Jqq1-UHgP0=Dsc=0AN1sE=VgwUqBWfMO-GObLBhg@mail.gmail.com>
 <CAEs876jnfQOWEwHrkfscx1z3B2Kc6a7F0tVpVHyoPMHmARcg3Q@mail.gmail.com>
 <CAPgF-fp2Pe0M4CESpT41Qo-RL_Obhs6OHua6c_0WbeQQyvYBfQ@mail.gmail.com>
Message-ID: <CAEs876iiXLosacddTzBt48KnwP6XqhHrWKSA2TJJ2XtEym6RMw@mail.gmail.com>

That’s awesome. Thank you.

On Thu, Sep 3, 2020 at 12:31 AM Satish Patel <satish.txt at gmail.com> wrote:

> Mohammed,
>
>
>
> Dis-regard my earlier emails. i found senlin does auto-healing. you
>
> need to create a health policy and attach it to your cluster.
>
>
>
> Here is my policy I created to monitor nodes' heath and if for some
>
> reason it dies or crashes, senlin will auto create that instance to
>
> fulfill the need.
>
>
>
> type: senlin.policy.health
>
> version: 1.1
>
> description: A policy for maintaining node health from a cluster.
>
> properties:
>
>   detection:
>
>     # Number of seconds between two adjacent checking
>
>     interval: 60
>
>
>
>     detection_modes:
>
>       # Type for health checking, valid values include:
>
>       # NODE_STATUS_POLLING, NODE_STATUS_POLL_URL, LIFECYCLE_EVENTS
>
>       - type: NODE_STATUS_POLLING
>
>
>
>   recovery:
>
>     # Action that can be retried on a failed node, will improve to
>
>     # support multiple actions in the future. Valid values include:
>
>     # REBOOT, REBUILD, RECREATE
>
>     actions:
>
>       - name: RECREATE
>
>
>
>
>
> ** Here is the POC
>
>
>
> [root at os-infra-1-utility-container-e139058e ~]# nova list
>
>
> +--------------------------------------+---------------+--------+------------+-------------+-------------------+
>
> | ID                                   | Name          | Status | Task
>
> State | Power State | Networks          |
>
>
> +--------------------------------------+---------------+--------+------------+-------------+-------------------+
>
> | 38ba7f7c-2f5f-4502-a5d0-6c4841d6d145 | cirros_server | ACTIVE | -
>
>       | Running     | net1=192.168.1.26 |
>
> | ba55deb6-9488-4455-a472-a0a957cb388a | cirros_server | ACTIVE | -
>
>       | Running     | net1=192.168.1.14 |
>
>
> +--------------------------------------+---------------+--------+------------+-------------+-------------------+
>
>
>
> ** Lets delete one of the nodes.
>
>
>
> [root at os-infra-1-utility-container-e139058e ~]# nova delete
>
> ba55deb6-9488-4455-a472-a0a957cb388a
>
> Request to delete server ba55deb6-9488-4455-a472-a0a957cb388a has been
> accepted.
>
>
>
> ** After a few min i can see RECOVERING nodes.
>
>
>
> [root at os-infra-1-utility-container-e139058e ~]# openstack cluster node
> list
>
>
> +----------+---------------+-------+------------+------------+-------------+--------------+----------------------+----------------------+---------+
>
> | id       | name          | index | status     | cluster_id |
>
> physical_id | profile_name | created_at           | updated_at
>
>   | tainted |
>
>
> +----------+---------------+-------+------------+------------+-------------+--------------+----------------------+----------------------+---------+
>
> | d4a8f219 | node-YPsjB6bV |     6 | RECOVERING | 091fbd52   |
>
> ba55deb6    | myserver     | 2020-09-02T21:01:47Z |
>
> 2020-09-03T04:01:58Z | False   |
>
> | bc50c0b9 | node-hoiHkRcS |     7 | ACTIVE     | 091fbd52   |
>
> 38ba7f7c    | myserver     | 2020-09-03T03:40:29Z |
>
> 2020-09-03T03:57:58Z | False   |
>
>
> +----------+---------------+-------+------------+------------+-------------+--------------+----------------------+----------------------+---------+
>
>
>
> ** Finally it's up and running with a new ip address.
>
>
>
> [root at os-infra-1-utility-container-e139058e ~]# nova list
>
>
> +--------------------------------------+---------------+--------+------------+-------------+-------------------+
>
> | ID                                   | Name          | Status | Task
>
> State | Power State | Networks          |
>
>
> +--------------------------------------+---------------+--------+------------+-------------+-------------------+
>
> | 38ba7f7c-2f5f-4502-a5d0-6c4841d6d145 | cirros_server | ACTIVE | -
>
>       | Running     | net1=192.168.1.26 |
>
> | 73a658cd-c40a-45d8-9b57-cc9e6c2b4dc1 | cirros_server | ACTIVE | -
>
>       | Running     | net1=192.168.1.17 |
>
>
> +--------------------------------------+---------------+--------+------------+-------------+-------------------+
>
>
>
> On Tue, Sep 1, 2020 at 8:51 AM Mohammed Naser <mnaser at vexxhost.com> wrote:
>
> >
>
> > Hi Satish,
>
> >
>
> > I'm interested by this, did you end up finding a solution for this?
>
> >
>
> > Thanks,
>
> > Mohammed
>
> >
>
> > On Thu, Aug 27, 2020 at 1:54 PM Satish Patel <satish.txt at gmail.com>
> wrote:
>
> > >
>
> > > Folks,
>
> > >
>
> > > I have created very simple cluster using following command
>
> > >
>
> > > openstack cluster create --profile myserver --desired-capacity 2
>
> > > --min-size 2 --max-size 3 --strict my-asg
>
> > >
>
> > > It spun up 2 vm immediately now because the desired capacity is 2 so I
>
> > > am assuming if any node dies in the cluster it should spin up node to
>
> > > make count 2 right?
>
> > >
>
> > > so i killed one of node with "nove delete <instance-foo-1>"  but
>
> > > senlin didn't create node automatically to make desired capacity 2 (In
>
> > > AWS when you kill node in ASG it will create new node so is this
>
> > > senlin different then AWS?)
>
> > >
>
> >
>
> >
>
> > --
>
> > Mohammed Naser
>
> > VEXXHOST, Inc.
>
> --
Mohammed Naser
VEXXHOST, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/dc15c748/attachment-0001.html>

From dtantsur at redhat.com  Thu Sep  3 10:30:33 2020
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Thu, 3 Sep 2020 12:30:33 +0200
Subject: [ironic] [stable] Bifrost stable/stein is broken (by eventlet?): help
 needed
Message-ID: <CACNgkFxM0KvtMb6N9X9uOVXfD7ryotv3WomKc0QgHs9rwz4jNg@mail.gmail.com>

Hi folks,

I'm trying to revive the Bifrost stable/stein CI, and after fixing a bunch
of issues in https://review.opendev.org/749014 I've hit a wall with what
seems an eventlet problem: ironic-inspector fails to start with:

Exception AttributeError: "'_SocketDuckForFd' object has no attribute
'_closed'" in <bound method _SocketDuckForFd.__del__ of
_SocketDuckForFd:16> ignored

I've managed to find similar issues, but they should have been resolved in
the eventlet version in stein (0.24.1). Any ideas?

If we cannot fix it, we'll have to EOL stein and earlier on bifrost.

Dmitry

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

From whayutin at redhat.com  Thu Sep  3 11:55:16 2020
From: whayutin at redhat.com (Wesley Hayutin)
Date: Thu, 3 Sep 2020 05:55:16 -0600
Subject: [tripleo] centos-binary -> openstack-
Message-ID: <CAOHJT4Jk-QQES2FU_GSO=M=6F60xyo0tE+zzwXe92PU8oGWKZg@mail.gmail.com>

Greetings,

The container names in master have changed from centos-binary* to
openstack*.
https://opendev.org/openstack/tripleo-common/src/branch/master/container-images/tripleo_containers.yaml

https://opendev.org/openstack/tripleo-common/commit/90f6de7a7fab15e9161c1f03acecaf98726298f1

If your patches are failing to pull
https://registry-1.docker.io/v2/tripleomaster/centos-binary* it's not going
to be fixed in a recheck. Check that your patches are rebased and your
dependent patches are rebased.

Thanks 0/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/d6a82d13/attachment.html>

From moreira.belmiro.email.lists at gmail.com  Thu Sep  3 12:59:53 2020
From: moreira.belmiro.email.lists at gmail.com (Belmiro Moreira)
Date: Thu, 3 Sep 2020 14:59:53 +0200
Subject: [all][TC] OpenStack Client (OSC) vs python-*clients
In-Reply-To: <c79cfe11-985c-2e0b-6834-2b9ab0b28f83@gmx.com>
References: <CAPkQhndGy1VrBT1yOCXQaZcgDxXr5ww9RL1VnU45iHsDJqZpcw@mail.gmail.com>
 <CAKZ_x7_CCbHzVdruU2BvS7kK1mvte+1AW1PJptwVzFJQVVCs4Q@mail.gmail.com>
 <1668118.VLH7GnMWUR@whitebase.usersys.redhat.com>
 <CACqyMicKobe7WnQfKEixAM3pTN0+9JdNGQUR8Z9KeW9bE9Xizw@mail.gmail.com>
 <9cbf9d69a9beb30d03af71e42a3e2446a516292a.camel@redhat.com>
 <CADO3vb4ufSnUpEwk8xk-6WQ9k8QKqnAnkWS1V+6U0x-nZnL7oQ@mail.gmail.com>
 <CAKwVDDOOu_Y6FFu1RQL+vKKg0D+w=qbjzHYzuk06dtjJ4qjjhQ@mail.gmail.com>
 <20200813164131.bdmhankpd2qxycux@yuggoth.org>
 <CACqyMieYo7tTtWVhRFJnEoWGGJrJHxERtDWfjHwE2gg22STMyw@mail.gmail.com>
 <2956d6bd-320e-34ea-64a0-1001e102d75c@gmail.com>
 <c79cfe11-985c-2e0b-6834-2b9ab0b28f83@gmx.com>
Message-ID: <CAPkQhneiV_-7Eiqkf9B=y1N9X-=LjwvnGYj3jGTFyLDJFPdxcA@mail.gmail.com>

Hi everyone,
thank you for all your comments.
However, I don't think we have reached any conclusion.

It would be great if the SDK/openstackclient team and the different
projects that raised some concerns can collaborate and move forward.
Personally, I believe that the current situation is a very bad user
experience.

Let us know how the TC can help.

cheers,
Belmiro

On Fri, Aug 14, 2020 at 3:08 PM Sean McGinnis <sean.mcginnis at gmx.com> wrote:

>
> > And if it's to provide one CLI that rules them all, the individual
> > projects (well, Cinder, anyway) can't stop adding functionality to
> > cinderclient CLI until the openstackclient CLI has feature parity.  At
> > least now, you can use one CLI to do all cinder-related stuff.  If we
> > stop cinderclient CLI development, then you'll need to use
> > openstackclient for some things (old features + the latest features)
> > and the cinderclient for all the in between features, which doesn't
> > seem like progress to me.
> And in reality, I don't think Cinder can even drop cinderclient even if
> we get feature parity. We have python-brick-cinderclient-ext that is
> used in conjunction with python-cinderclient for some standalone use cases.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/e9658c1c/attachment.html>

From alifshit at redhat.com  Thu Sep  3 15:10:01 2020
From: alifshit at redhat.com (Artom Lifshitz)
Date: Thu, 3 Sep 2020 11:10:01 -0400
Subject: [all][TC] OpenStack Client (OSC) vs python-*clients
In-Reply-To: <CAPkQhneiV_-7Eiqkf9B=y1N9X-=LjwvnGYj3jGTFyLDJFPdxcA@mail.gmail.com>
References: <CAPkQhndGy1VrBT1yOCXQaZcgDxXr5ww9RL1VnU45iHsDJqZpcw@mail.gmail.com>
 <CAKZ_x7_CCbHzVdruU2BvS7kK1mvte+1AW1PJptwVzFJQVVCs4Q@mail.gmail.com>
 <1668118.VLH7GnMWUR@whitebase.usersys.redhat.com>
 <CACqyMicKobe7WnQfKEixAM3pTN0+9JdNGQUR8Z9KeW9bE9Xizw@mail.gmail.com>
 <9cbf9d69a9beb30d03af71e42a3e2446a516292a.camel@redhat.com>
 <CADO3vb4ufSnUpEwk8xk-6WQ9k8QKqnAnkWS1V+6U0x-nZnL7oQ@mail.gmail.com>
 <CAKwVDDOOu_Y6FFu1RQL+vKKg0D+w=qbjzHYzuk06dtjJ4qjjhQ@mail.gmail.com>
 <20200813164131.bdmhankpd2qxycux@yuggoth.org>
 <CACqyMieYo7tTtWVhRFJnEoWGGJrJHxERtDWfjHwE2gg22STMyw@mail.gmail.com>
 <2956d6bd-320e-34ea-64a0-1001e102d75c@gmail.com>
 <c79cfe11-985c-2e0b-6834-2b9ab0b28f83@gmx.com>
 <CAPkQhneiV_-7Eiqkf9B=y1N9X-=LjwvnGYj3jGTFyLDJFPdxcA@mail.gmail.com>
Message-ID: <CACqyMicjXQm9gWOb_V6ODo4ziwmLHRhzkHEdbSafpA3ad_aaNg@mail.gmail.com>

On Thu, Sep 3, 2020 at 9:05 AM Belmiro Moreira
<moreira.belmiro.email.lists at gmail.com> wrote:
>
> Hi everyone,
> thank you for all your comments.
> However, I don't think we have reached any conclusion.
>
> It would be great if the SDK/openstackclient team and the different projects that raised some concerns can collaborate and move forward.
> Personally, I believe that the current situation is a very bad user experience.
>
> Let us know how the TC can help.

Can we start by agreeing (or can the TC just top-down mandate?) an end
state we want to get to? The way I've understood it and see it, what
we're aiming for is:

A. osc is user-facing CLI shell around sdk
B. sdk is the only official client library for interacting with the
OpenStack REST APIs

I've been working with those assumptions for [1] and addressing point
B, leaving point A to the osc team.

If we take B to be true, patches like [2] would get blocked and
redirected to the SDK for the API logic, with only the CLI parts in
the osc. That doesn't seem to be the case, so I don't know what to
think anymore.

[1] https://review.opendev.org/#/q/status:open+project:openstack/openstacksdk+branch:master+topic:story/2007929
[2] https://review.opendev.org/#/c/675304/

>
> cheers,
> Belmiro
>
> On Fri, Aug 14, 2020 at 3:08 PM Sean McGinnis <sean.mcginnis at gmx.com> wrote:
>>
>>
>> > And if it's to provide one CLI that rules them all, the individual
>> > projects (well, Cinder, anyway) can't stop adding functionality to
>> > cinderclient CLI until the openstackclient CLI has feature parity.  At
>> > least now, you can use one CLI to do all cinder-related stuff.  If we
>> > stop cinderclient CLI development, then you'll need to use
>> > openstackclient for some things (old features + the latest features)
>> > and the cinderclient for all the in between features, which doesn't
>> > seem like progress to me.
>> And in reality, I don't think Cinder can even drop cinderclient even if
>> we get feature parity. We have python-brick-cinderclient-ext that is
>> used in conjunction with python-cinderclient for some standalone use cases.
>>



From oliver.wenz at dhbw-mannheim.de  Thu Sep  3 15:18:20 2020
From: oliver.wenz at dhbw-mannheim.de (Oliver Wenz)
Date: Thu, 3 Sep 2020 17:18:20 +0200
Subject: [openstack-ansible] OpenStack Ansible deployment fails due to lxc
 containers not having network connection
Message-ID: <152bb1fa-a218-d6b3-5920-1f6867b75726@dhbw-mannheim.de>

I'm trying to deploy OpenStack Ansible. When running the first playbook
```openstack-ansible setup-hosts.yml```, there are errors for all
containers during the task ```[openstack_hosts : Remove the blacklisted
packages]``` (see below) and the playbook fails.

```
fatal: [infra1_repo_container-1f1565cd]: FAILED! => {"changed": false,
"cmd": "apt-get update", "msg": "E: The repository
'http://ubuntu.mirror.lrz.de/ubuntu bionic Release' no longer has a
Release file.
E: The repository 'http://ubuntu.mirror.lrz.de/ubuntu bionic-updates
Release' no longer has a Release file.
E: The repository 'http://ubuntu.mirror.lrz.de/ubuntu bionic-backports
Release' no longer has a Release file.
E: The repository 'http://ubuntu.mirror.lrz.de/ubuntu bionic-security
Release' no longer has a Release file.", "rc": 100, "stderr": "E: The
repository 'http://ubuntu.mirror.lrz.de/ubuntu bionic Release' no longer
has a Release file.
E: The repository 'http://ubuntu.mirror.lrz.de/ubuntu bionic-updates
Release' no longer has a Release file.
E: The repository 'http://ubuntu.mirror.lrz.de/ubuntu bionic-backports
Release' no longer has a Release file.
E: The repository 'http://ubuntu.mirror.lrz.de/ubuntu bionic-security
Release' no longer has a Release file.
", "stderr_lines": ["E: The repository
'http://ubuntu.mirror.lrz.de/ubuntu bionic Release' no longer has a
Release file.", "E: The repository 'http://ubuntu.mirror.lrz.de/ubuntu
bionic-updates Release' no longer has a Release file.", "E: The
repository 'http://ubuntu.mirror.lrz.de/ubuntu bionic-backports Release'
no longer has a Release file.", "E: The repository
'http://ubuntu.mirror.lrz.de/ubuntu bionic-security Release' no longer
has a Release file."], "stdout": "Ign:1
http://ubuntu.mirror.lrz.de/ubuntu bionic InRelease
Ign:2 http://ubuntu.mirror.lrz.de/ubuntu bionic-updates InRelease
Ign:3 http://ubuntu.mirror.lrz.de/ubuntu bionic-backports InRelease
Ign:4 http://ubuntu.mirror.lrz.de/ubuntu bionic-security InRelease
Err:5 http://ubuntu.mirror.lrz.de/ubuntu bionic Release
  Cannot initiate the connection to 192.168.100.6:8000 (192.168.100.6).
- connect (101: Network is unreachable)
Err:6 http://ubuntu.mirror.lrz.de/ubuntu bionic-updates Release
  Cannot initiate the connection to 192.168.100.6:8000 (192.168.100.6).
- connect (101: Network is unreachable)
Err:7 http://ubuntu.mirror.lrz.de/ubuntu bionic-backports Release
  Cannot initiate the connection to 192.168.100.6:8000 (192.168.100.6).
- connect (101: Network is unreachable)
Err:8 http://ubuntu.mirror.lrz.de/ubuntu bionic-security Release
  Cannot initiate the connection to 192.168.100.6:8000 (192.168.100.6).
- connect (101: Network is unreachable)
Reading package lists...
", "stdout_lines": ["Ign:1 http://ubuntu.mirror.lrz.de/ubuntu bionic
InRelease", "Ign:2 http://ubuntu.mirror.lrz.de/ubuntu bionic-updates
InRelease", "Ign:3 http://ubuntu.mirror.lrz.de/ubuntu bionic-backports
InRelease", "Ign:4 http://ubuntu.mirror.lrz.de/ubuntu bionic-security
InRelease", "Err:5 http://ubuntu.mirror.lrz.de/ubuntu bionic Release",
"  Cannot initiate the connection to 192.168.100.6:8000 (192.168.100.6).
- connect (101: Network is unreachable)", "Err:6
http://ubuntu.mirror.lrz.de/ubuntu bionic-updates Release", "  Cannot
initiate the connection to 192.168.100.6:8000 (192.168.100.6). - connect
(101: Network is unreachable)", "Err:7
http://ubuntu.mirror.lrz.de/ubuntu bionic-backports Release", "  Cannot
initiate the connection to 192.168.100.6:8000 (192.168.100.6). - connect
(101: Network is unreachable)", "Err:8
http://ubuntu.mirror.lrz.de/ubuntu bionic-security Release", "  Cannot
initiate the connection to 192.168.100.6:8000 (192.168.100.6). - connect
(101: Network is unreachable)", "Reading package lists..."]}

```

When I attach to any container and run ```ping 192.168.100.6``` (local
DNS), I get the same error (```connect: Network is unreachable```).
However, when I specify an interface by running ```ping -I eth1
192.168.100.6``` there is a successful connection.
Running ```ip r``` on the infra_cinder container yields:
```
10.0.3.0/24 dev eth2 proto kernel scope link src 10.0.3.5
192.168.110.0/24 dev eth1 proto kernel scope link src 192.168.110.232
```
so there seems to be no default route which is why the connection fails
(similar for the other infra containers). Shouldn't OSA automatically
configure this? I didn't find anything regarding a default route on
containers in the Docs.

Here's my openstack_user_config.yml:

```
cidr_networks:
  container: 192.168.110.0/24
  tunnel: 192.168.32.0/24
  storage: 10.0.3.0/24

used_ips:
  - "192.168.110.1,192.168.110.2"
  - "192.168.110.111"
  - "192.168.110.115"
  - "192.168.110.117,192.168.110.118"
  - "192.168.110.131,192.168.110.140"
  - "192.168.110.201,192.168.110.207"
  - "192.168.32.1,192.168.32.2"
  - "192.168.32.201,192.168.32.207"
  - "10.0.3.1"
  - "10.0.3.11,10.0.3.14"
  - "10.0.3.21,10.0.3.24"
  - "10.0.3.31,10.0.3.42"
  - "10.0.3.201,10.0.3.207"

global_overrides:
  # The internal and external VIP should be different IPs, however they
  # do not need to be on separate networks.
  external_lb_vip_address: 192.168.100.168
  internal_lb_vip_address: 192.168.110.201
  management_bridge: "br-mgmt"
  provider_networks:
    - network:
        container_bridge: "br-mgmt"
        container_type: "veth"
        container_interface: "eth1"
        ip_from_q: "container"
        type: "raw"
        group_binds:
          - all_containers
          - hosts
        is_container_address: true
    - network:
        container_bridge: "br-vxlan"
        container_type: "veth"
        container_interface: "eth10"
        ip_from_q: "tunnel"
        type: "vxlan"
        range: "1:1000"
        net_name: "vxlan"
        group_binds:
          - neutron_linuxbridge_agent
    - network:
        container_bridge: "br-ext1"
        container_type: "veth"
        container_interface: "eth12"
        host_bind_override: "eth12"
        type: "flat"
        net_name: "ext_net"
        group_binds:
          - neutron_linuxbridge_agent
    - network:
        container_bridge: "br-storage"
        container_type: "veth"
        container_interface: "eth2"
        ip_from_q: "storage"
        type: "raw"
        group_binds:
          - glance_api
          - cinder_api
          - cinder_volume
          - nova_compute
          - swift-proxy

###
### Infrastructure
###

# galera, memcache, rabbitmq, utility
shared-infra_hosts:
  infra1:
    ip: 192.168.110.201

# repository (apt cache, python packages, etc)
repo-infra_hosts:
  infra1:
    ip: 192.168.110.201

# load balancer
haproxy_hosts:
  infra1:
    ip: 192.168.110.201

###
### OpenStack
###

os-infra_hosts:
   infra1:
     ip: 192.168.110.201

identity_hosts:
   infra1:
     ip: 192.168.110.201

network_hosts:
   infra1:
     ip: 192.168.110.201

compute_hosts:
   compute1:
     ip: 192.168.110.204
   compute2:
     ip: 192.168.110.205
   compute3:
     ip: 192.168.110.206
   compute4:
     ip: 192.168.110.207

storage-infra_hosts:
   infra1:
     ip: 192.168.110.201

storage_hosts:
   lvm-storage1:
     ip: 192.168.110.202
     container_vars:
       cinder_backends:
         lvm:
           volume_backend_name: LVM_iSCSI
           volume_driver: cinder.volume.drivers.lvm.LVMVolumeDriver
           volume_group: cinder_volumes
           iscsi_ip_address: "{{ cinder_storage_address }}"
         limit_container_types: cinder_volume

```

I also asked this question on the server fault stackexchange:
https://serverfault.com/questions/1032573/openstack-ansible-deployment-fails-due-to-lxc-containers-not-having-network-conn


Kind regards,
Oliver



From elmiko at redhat.com  Thu Sep  3 15:41:00 2020
From: elmiko at redhat.com (Michael McCune)
Date: Thu, 3 Sep 2020 11:41:00 -0400
Subject: [API SIG] Ending office hours for the API-SIG
Message-ID: <CADE+ktTFZ6ggOk4WP+Maf-p8NOH+zLmfHjxoQo4UuaKzh66Q4Q@mail.gmail.com>

hello all,

the API-SIG has held meetings and office hours for several years now. since
our migration from a weekly meeting to an office hour we have monitored a
continual decrease in attendance for these hours, aside from the core
membership. after discussion over the course of the last month or two, we
have agreed to end the API-SIG office hours.

we will hold office hours this week as our final meeting. if you need to
contact the SIG in the future, we are still available in the
#openstack-sdks channel on freenode as well as here on the mailing list.

in the future we would like to see continued migration of the API-SIG
closer to the SDKs group. these two groups will essentially become a
singular place to discuss all things related to SDKs and APIs in OpenStack.

thank you all for the years of participation and discussion that helped us
as a community to define a set of best practices and guidelines for API
work in OpenStack.

peace o/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/4066f3d8/attachment.html>

From artem.goncharov at gmail.com  Thu Sep  3 15:45:00 2020
From: artem.goncharov at gmail.com (Artem Goncharov)
Date: Thu, 3 Sep 2020 17:45:00 +0200
Subject: [all][TC] OpenStack Client (OSC) vs python-*clients
In-Reply-To: <CACqyMicjXQm9gWOb_V6ODo4ziwmLHRhzkHEdbSafpA3ad_aaNg@mail.gmail.com>
References: <CAPkQhndGy1VrBT1yOCXQaZcgDxXr5ww9RL1VnU45iHsDJqZpcw@mail.gmail.com>
 <CAKZ_x7_CCbHzVdruU2BvS7kK1mvte+1AW1PJptwVzFJQVVCs4Q@mail.gmail.com>
 <1668118.VLH7GnMWUR@whitebase.usersys.redhat.com>
 <CACqyMicKobe7WnQfKEixAM3pTN0+9JdNGQUR8Z9KeW9bE9Xizw@mail.gmail.com>
 <9cbf9d69a9beb30d03af71e42a3e2446a516292a.camel@redhat.com>
 <CADO3vb4ufSnUpEwk8xk-6WQ9k8QKqnAnkWS1V+6U0x-nZnL7oQ@mail.gmail.com>
 <CAKwVDDOOu_Y6FFu1RQL+vKKg0D+w=qbjzHYzuk06dtjJ4qjjhQ@mail.gmail.com>
 <20200813164131.bdmhankpd2qxycux@yuggoth.org>
 <CACqyMieYo7tTtWVhRFJnEoWGGJrJHxERtDWfjHwE2gg22STMyw@mail.gmail.com>
 <2956d6bd-320e-34ea-64a0-1001e102d75c@gmail.com>
 <c79cfe11-985c-2e0b-6834-2b9ab0b28f83@gmx.com>
 <CAPkQhneiV_-7Eiqkf9B=y1N9X-=LjwvnGYj3jGTFyLDJFPdxcA@mail.gmail.com>
 <CACqyMicjXQm9gWOb_V6ODo4ziwmLHRhzkHEdbSafpA3ad_aaNg@mail.gmail.com>
Message-ID: <ECE19EB9-92E2-4790-A2FF-38378F3E8E7B@gmail.com>



> On 3. Sep 2020, at 17:10, Artom Lifshitz <alifshit at redhat.com> wrote:
> 
> On Thu, Sep 3, 2020 at 9:05 AM Belmiro Moreira
> <moreira.belmiro.email.lists at gmail.com> wrote:
>> 
>> Hi everyone,
>> thank you for all your comments.
>> However, I don't think we have reached any conclusion.
>> 
>> It would be great if the SDK/openstackclient team and the different projects that raised some concerns can collaborate and move forward.
>> Personally, I believe that the current situation is a very bad user experience.
>> 
>> Let us know how the TC can help.
> 
> Can we start by agreeing (or can the TC just top-down mandate?) an end
> state we want to get to? The way I've understood it and see it, what
> we're aiming for is:
> 
> A. osc is user-facing CLI shell around sdk
> B. sdk is the only official client library for interacting with the
> OpenStack REST APIs
> 
> I've been working with those assumptions for [1] and addressing point
> B, leaving point A to the osc team.
> 
> If we take B to be true, patches like [2] would get blocked and
> redirected to the SDK for the API logic, with only the CLI parts in
> the osc. That doesn't seem to be the case, so I don't know what to
> think anymore.
> 

From all the discussions we held over the time, yes, A is definitely our target (while there might be still special cases)

As SDK/OSC team we can say: B is true in a perfect world, but it is not a valid statement today. Somebody need to invest pretty huge effort in making this happen (I know this since I already invested in switching image part). During this time all the changes to OSC for things not based on SDK would need to be blocked. Amount of active people deep in the code of SDK/CLI is too small currently to handle this fast. On the other side, if nova team commits to do their patches to SDK first (what I see you guys are definitely doing, a great Thanks!) - we would be able to switch CLI for nova to SDK much easier.
The more teams would be doing that, the easier would it be to clean OSC up.

Very unfortunately since last PTG there were only very minor activities in SDK/OSC team, but I would like to change this now (unfortunately there are still just 24 hours in the day). Let me see where I can find another few hours a day for repairing things and set a personal (or hopefully SDK team) target to move at least few nova resources onto CLI at SDK until next PTG. ;-)

Regards,
Another Artem

From jonathan.rosser at rd.bbc.co.uk  Thu Sep  3 15:51:51 2020
From: jonathan.rosser at rd.bbc.co.uk (Jonathan Rosser)
Date: Thu, 3 Sep 2020 16:51:51 +0100
Subject: [openstack-ansible] OpenStack Ansible deployment fails due to lxc
 containers not having network connection
In-Reply-To: <152bb1fa-a218-d6b3-5920-1f6867b75726@dhbw-mannheim.de>
References: <152bb1fa-a218-d6b3-5920-1f6867b75726@dhbw-mannheim.de>
Message-ID: <e6746294-ada6-0f29-cdfb-59538396a0e0@rd.bbc.co.uk>

Hi Oliver,

The default route would normally be via eth0 in the container, which I 
suspect has some issue.

This is given an address by dnsmasq/dhcp on the host and attached to 
lxcbr0. This is where I would start to look. I am straight seeing that 
the default address range used for eth0 is in conflict with your storage 
network, so perhaps this is also something to look at. See 
https://github.com/openstack/openstack-ansible-lxc_hosts/blob/master/defaults/main.yml#L104 
<https://github.com/openstack/openstack-ansible-lxc_hosts/blob/master/defaults/main.yml#L104>

You join us on irc at #openstack-ansible for some 'real-time' assistance 
if necessary.

Regards,
Jonathan.

On 03/09/2020 16:18, Oliver Wenz wrote:
> I'm trying to deploy OpenStack Ansible. When running the first playbook
> ```openstack-ansible setup-hosts.yml```, there are errors for all
> containers during the task ```[openstack_hosts : Remove the blacklisted
> packages]``` (see below) and the playbook fails.
>
> ```
> fatal: [infra1_repo_container-1f1565cd]: FAILED! => {"changed": false,
> "cmd": "apt-get update", "msg": "E: The repository
> 'http://ubuntu.mirror.lrz.de/ubuntu bionic Release' no longer has a
> Release file.
> E: The repository 'http://ubuntu.mirror.lrz.de/ubuntu bionic-updates
> Release' no longer has a Release file.
> E: The repository 'http://ubuntu.mirror.lrz.de/ubuntu bionic-backports
> Release' no longer has a Release file.
> E: The repository 'http://ubuntu.mirror.lrz.de/ubuntu bionic-security
> Release' no longer has a Release file.", "rc": 100, "stderr": "E: The
> repository 'http://ubuntu.mirror.lrz.de/ubuntu bionic Release' no longer
> has a Release file.
> E: The repository 'http://ubuntu.mirror.lrz.de/ubuntu bionic-updates
> Release' no longer has a Release file.
> E: The repository 'http://ubuntu.mirror.lrz.de/ubuntu bionic-backports
> Release' no longer has a Release file.
> E: The repository 'http://ubuntu.mirror.lrz.de/ubuntu bionic-security
> Release' no longer has a Release file.
> ", "stderr_lines": ["E: The repository
> 'http://ubuntu.mirror.lrz.de/ubuntu bionic Release' no longer has a
> Release file.", "E: The repository 'http://ubuntu.mirror.lrz.de/ubuntu
> bionic-updates Release' no longer has a Release file.", "E: The
> repository 'http://ubuntu.mirror.lrz.de/ubuntu bionic-backports Release'
> no longer has a Release file.", "E: The repository
> 'http://ubuntu.mirror.lrz.de/ubuntu bionic-security Release' no longer
> has a Release file."], "stdout": "Ign:1
> http://ubuntu.mirror.lrz.de/ubuntu bionic InRelease
> Ign:2 http://ubuntu.mirror.lrz.de/ubuntu bionic-updates InRelease
> Ign:3 http://ubuntu.mirror.lrz.de/ubuntu bionic-backports InRelease
> Ign:4 http://ubuntu.mirror.lrz.de/ubuntu bionic-security InRelease
> Err:5 http://ubuntu.mirror.lrz.de/ubuntu bionic Release
>    Cannot initiate the connection to 192.168.100.6:8000 (192.168.100.6).
> - connect (101: Network is unreachable)
> Err:6 http://ubuntu.mirror.lrz.de/ubuntu bionic-updates Release
>    Cannot initiate the connection to 192.168.100.6:8000 (192.168.100.6).
> - connect (101: Network is unreachable)
> Err:7 http://ubuntu.mirror.lrz.de/ubuntu bionic-backports Release
>    Cannot initiate the connection to 192.168.100.6:8000 (192.168.100.6).
> - connect (101: Network is unreachable)
> Err:8 http://ubuntu.mirror.lrz.de/ubuntu bionic-security Release
>    Cannot initiate the connection to 192.168.100.6:8000 (192.168.100.6).
> - connect (101: Network is unreachable)
> Reading package lists...
> ", "stdout_lines": ["Ign:1 http://ubuntu.mirror.lrz.de/ubuntu bionic
> InRelease", "Ign:2 http://ubuntu.mirror.lrz.de/ubuntu bionic-updates
> InRelease", "Ign:3 http://ubuntu.mirror.lrz.de/ubuntu bionic-backports
> InRelease", "Ign:4 http://ubuntu.mirror.lrz.de/ubuntu bionic-security
> InRelease", "Err:5 http://ubuntu.mirror.lrz.de/ubuntu bionic Release",
> "  Cannot initiate the connection to 192.168.100.6:8000 (192.168.100.6).
> - connect (101: Network is unreachable)", "Err:6
> http://ubuntu.mirror.lrz.de/ubuntu bionic-updates Release", "  Cannot
> initiate the connection to 192.168.100.6:8000 (192.168.100.6). - connect
> (101: Network is unreachable)", "Err:7
> http://ubuntu.mirror.lrz.de/ubuntu bionic-backports Release", "  Cannot
> initiate the connection to 192.168.100.6:8000 (192.168.100.6). - connect
> (101: Network is unreachable)", "Err:8
> http://ubuntu.mirror.lrz.de/ubuntu bionic-security Release", "  Cannot
> initiate the connection to 192.168.100.6:8000 (192.168.100.6). - connect
> (101: Network is unreachable)", "Reading package lists..."]}
>
> ```
>
> When I attach to any container and run ```ping 192.168.100.6``` (local
> DNS), I get the same error (```connect: Network is unreachable```).
> However, when I specify an interface by running ```ping -I eth1
> 192.168.100.6``` there is a successful connection.
> Running ```ip r``` on the infra_cinder container yields:
> ```
> 10.0.3.0/24 dev eth2 proto kernel scope link src 10.0.3.5
> 192.168.110.0/24 dev eth1 proto kernel scope link src 192.168.110.232
> ```
> so there seems to be no default route which is why the connection fails
> (similar for the other infra containers). Shouldn't OSA automatically
> configure this? I didn't find anything regarding a default route on
> containers in the Docs.
>
> Here's my openstack_user_config.yml:
>
> ```
> cidr_networks:
>    container: 192.168.110.0/24
>    tunnel: 192.168.32.0/24
>    storage: 10.0.3.0/24
>
> used_ips:
>    - "192.168.110.1,192.168.110.2"
>    - "192.168.110.111"
>    - "192.168.110.115"
>    - "192.168.110.117,192.168.110.118"
>    - "192.168.110.131,192.168.110.140"
>    - "192.168.110.201,192.168.110.207"
>    - "192.168.32.1,192.168.32.2"
>    - "192.168.32.201,192.168.32.207"
>    - "10.0.3.1"
>    - "10.0.3.11,10.0.3.14"
>    - "10.0.3.21,10.0.3.24"
>    - "10.0.3.31,10.0.3.42"
>    - "10.0.3.201,10.0.3.207"
>
> global_overrides:
>    # The internal and external VIP should be different IPs, however they
>    # do not need to be on separate networks.
>    external_lb_vip_address: 192.168.100.168
>    internal_lb_vip_address: 192.168.110.201
>    management_bridge: "br-mgmt"
>    provider_networks:
>      - network:
>          container_bridge: "br-mgmt"
>          container_type: "veth"
>          container_interface: "eth1"
>          ip_from_q: "container"
>          type: "raw"
>          group_binds:
>            - all_containers
>            - hosts
>          is_container_address: true
>      - network:
>          container_bridge: "br-vxlan"
>          container_type: "veth"
>          container_interface: "eth10"
>          ip_from_q: "tunnel"
>          type: "vxlan"
>          range: "1:1000"
>          net_name: "vxlan"
>          group_binds:
>            - neutron_linuxbridge_agent
>      - network:
>          container_bridge: "br-ext1"
>          container_type: "veth"
>          container_interface: "eth12"
>          host_bind_override: "eth12"
>          type: "flat"
>          net_name: "ext_net"
>          group_binds:
>            - neutron_linuxbridge_agent
>      - network:
>          container_bridge: "br-storage"
>          container_type: "veth"
>          container_interface: "eth2"
>          ip_from_q: "storage"
>          type: "raw"
>          group_binds:
>            - glance_api
>            - cinder_api
>            - cinder_volume
>            - nova_compute
>            - swift-proxy
>
> ###
> ### Infrastructure
> ###
>
> # galera, memcache, rabbitmq, utility
> shared-infra_hosts:
>    infra1:
>      ip: 192.168.110.201
>
> # repository (apt cache, python packages, etc)
> repo-infra_hosts:
>    infra1:
>      ip: 192.168.110.201
>
> # load balancer
> haproxy_hosts:
>    infra1:
>      ip: 192.168.110.201
>
> ###
> ### OpenStack
> ###
>
> os-infra_hosts:
>     infra1:
>       ip: 192.168.110.201
>
> identity_hosts:
>     infra1:
>       ip: 192.168.110.201
>
> network_hosts:
>     infra1:
>       ip: 192.168.110.201
>
> compute_hosts:
>     compute1:
>       ip: 192.168.110.204
>     compute2:
>       ip: 192.168.110.205
>     compute3:
>       ip: 192.168.110.206
>     compute4:
>       ip: 192.168.110.207
>
> storage-infra_hosts:
>     infra1:
>       ip: 192.168.110.201
>
> storage_hosts:
>     lvm-storage1:
>       ip: 192.168.110.202
>       container_vars:
>         cinder_backends:
>           lvm:
>             volume_backend_name: LVM_iSCSI
>             volume_driver: cinder.volume.drivers.lvm.LVMVolumeDriver
>             volume_group: cinder_volumes
>             iscsi_ip_address: "{{ cinder_storage_address }}"
>           limit_container_types: cinder_volume
>
> ```
>
> I also asked this question on the server fault stackexchange:
> https://serverfault.com/questions/1032573/openstack-ansible-deployment-fails-due-to-lxc-containers-not-having-network-conn
>
>
> Kind regards,
> Oliver
>
>
>


From sosogh at 126.com  Thu Sep  3 04:03:47 2020
From: sosogh at 126.com (sosogh)
Date: Thu, 3 Sep 2020 12:03:47 +0800 (CST)
Subject: Reply:Re: [kolla] questions when using external mysql
In-Reply-To: <CAFHSqWpa03GBGuDvK7r4-ktV5zyqfKYTEvRq3B3zTd+qqkcs5w@mail.gmail.com>
References: <5c644eb6.3cda.174488cf629.Coremail.sosogh@126.com>
 <CAFHSqWpa03GBGuDvK7r4-ktV5zyqfKYTEvRq3B3zTd+qqkcs5w@mail.gmail.com>
Message-ID: <64f5b918.2516.17452228292.Coremail.sosogh@126.com>

Hi Mark :


I have read further on external-mariadb-guide.html .


if setting  "use_preconfigured_databases = yes" and  and "use_common_mariadb_user = yes " , 
people has to create the " new fresh " DB (nova , glance ,keystone etc) manually  .
the more openstack serivces  enabled , the more databases have to be created .
so why people will want to create the " new fresh " DB manually  rather than letting kolla-ansible to do it ?
what would be this case ?


IMHO, the blueprint (https://blueprints.launchpad.net/kolla-ansible/+spec/external-mariadb-support) maybe more likely to be:
people create ready-to-use mysql account , and apply  the mysql address/account  to  kolla-ansible , 
then kolla-ansible use  it as  a common user across databases







在 2020-09-02 16:35:24，"Mark Goddard" <mark at stackhpc.com> 写道：





On Tue, 1 Sep 2020 at 15:48, sosogh <sosogh at 126.com> wrote:


Hi list:



I want to use kolla-ansible to deploy openstack , but using external mysql. 
I am following these docs:  

https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html

https://docs.openstack.org/kolla-ansible/latest/reference/databases/external-mariadb-guide.html.



Hi, could you start by telling us which version or branch of Kolla Ansible you are using?




I have some questions:



################
##  Question 1 ##
################



 According to the offical doc , if setting it  in inventory file(multinode), 




kolla-ansible -i ./multinode deploy will throw out error:




I guest when kolla-ansible running the playbook against myexternalmariadbloadbalancer.com , 

the """register: find_custom_fluentd_inputs""" in """TASK [common : Find custom fluentd input config files]"""  maybe null .



I think this could be an issue with a recent change to the common role, where the condition for the 'Find custom fluentd input config files' task changed slightly. I have proposed a potential fix for this, could you try it out and report back? https://review.opendev.org/749463




################
##  Question 2 ##
################

 According to the offical doc , If the MariaDB username is not root, set database_username in /etc/kolla/globals.yml file:  




But in kolla-ansible/ansible/roles/xxxxxx/tasks/bootstrap.yml  , they use  ''' login_user: "{{ database_user }}"  ''' ， for example :



You are correct, this is an issue in the documentation. I have proposed a fix here: https://review.opendev.org/749464
 
So at last  , I took the following steps:
1. """not""" setting [mariadb] in inventory file(multinode)   
2. set "database_user: openstack" for  "privillegeduser"


PS: 
My idea is that if using an external ready-to-use mysql (cluster),  
it is enough to tell kolla-ansible only the address/user/password of the external DB.
i.e. setting them in the file /etc/kolla/globals.yml and passwords.yml , no need to add it into inventory file(multinode)   


I agree, I did not expect to need to change the inventory for this use case.


Finally , it is successful to  deploy openstack via kolla-ansible . 
So far I have not found any problems.   
 Are the steps what I took  good ( enough ) ? 
Thank you !



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/5763151d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2938 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/5763151d/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 95768 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/5763151d/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2508 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/5763151d/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 22016 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/5763151d/attachment-0007.png>

From mark at stackhpc.com  Thu Sep  3 07:33:56 2020
From: mark at stackhpc.com (Mark Goddard)
Date: Thu, 3 Sep 2020 08:33:56 +0100
Subject: Reply:Re: [kolla] questions when using external mysql
In-Reply-To: <64f5b918.2516.17452228292.Coremail.sosogh@126.com>
References: <5c644eb6.3cda.174488cf629.Coremail.sosogh@126.com>
 <CAFHSqWpa03GBGuDvK7r4-ktV5zyqfKYTEvRq3B3zTd+qqkcs5w@mail.gmail.com>
 <64f5b918.2516.17452228292.Coremail.sosogh@126.com>
Message-ID: <CAFHSqWqP8EOESRLQfbsguzj66fTdWDnGUqHMga9TWgNAyf9ECg@mail.gmail.com>

On Thu, 3 Sep 2020 at 05:04, sosogh <sosogh at 126.com> wrote:

> Hi Mark :
>
> I have read further on external-mariadb-guide.html .
>
> if setting  "use_preconfigured_databases = yes" and  and
> "use_common_mariadb_user = yes " ,
> people has to create the " new fresh " DB (nova , glance ,keystone etc)
> manually  .
> the more openstack serivces  enabled , the more databases have to be
> created .
> so why people will want to create the " new fresh " DB manually  rather
> than letting kolla-ansible to do it ?
> what would be this case ?
>

The use case is where the DBMS is entirely managed outside of Kolla
Ansible, and the DB user does not have privileges required to create a
database. If you set use_preconfigured_databases to no (the default), Kolla
Ansible will create the necessary databases.

>
> IMHO, the blueprint (
> https://blueprints.launchpad.net/kolla-ansible/+spec/external-mariadb-support)
> maybe more likely to be:
> people create ready-to-use mysql account , and apply  the mysql
> address/account  to  kolla-ansible ,
> then kolla-ansible use  it as  a common user across databases
>
>
>
> 在 2020-09-02 16:35:24，"Mark Goddard" <mark at stackhpc.com> 写道：
>
>
>
> On Tue, 1 Sep 2020 at 15:48, sosogh <sosogh at 126.com> wrote:
>
>> Hi list:
>>
>> I want to use kolla-ansible to deploy openstack , but using external
>> mysql.
>> I am following these docs:
>>
>> https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html
>>
>>
>> https://docs.openstack.org/kolla-ansible/latest/reference/databases/external-mariadb-guide.html
>> .
>>
>
> Hi, could you start by telling us which version or branch of Kolla Ansible
> you are using?
>
>>
>> I have some questions:
>>
>> ################
>> ##  Question 1 ##
>> ################
>>
>>  According to the offical doc , if setting it  in inventory
>> file(multinode),
>>
>>
>> kolla-ansible -i ./multinode deploy will throw out error:
>>
>>
>> I guest when kolla-ansible running the playbook against
>> myexternalmariadbloadbalancer.com ,
>>
>> the """register: find_custom_fluentd_inputs""" in """TASK [common : Find
>> custom fluentd input config files]"""  maybe null .
>>
>
> I think this could be an issue with a recent change to the common role,
> where the condition for the 'Find custom fluentd input config files' task
> changed slightly. I have proposed a potential fix for this, could you try
> it out and report back? https://review.opendev.org/749463
>
>>
>> ################
>> ##  Question 2 ##
>> ################
>>
>>  According to the offical doc , If the MariaDB username is not root, set
>> database_username in /etc/kolla/globals.yml file:
>>
>>
>> But in kolla-ansible/ansible/roles/xxxxxx/tasks/bootstrap.yml  , they
>> use  ''' login_user: "{{ database_user }}"  ''' ， for example :
>>
>> You are correct, this is an issue in the documentation. I have proposed a
> fix here: https://review.opendev.org/749464
>
>
>> So at last  , I took the following steps:
>> 1. """not""" setting [mariadb] in inventory file(multinode)
>> 2. set "database_user: openstack" for  "privillegeduser"
>>
>> PS:
>> My idea is that if using an external ready-to-use mysql (cluster),
>> it is enough to tell kolla-ansible only the address/user/password of the
>> external DB.
>> i.e. setting them in the file /etc/kolla/globals.yml and passwords.yml ,
>> no need to add it into inventory file(multinode)
>>
>
> I agree, I did not expect to need to change the inventory for this use
> case.
>
>>
>> Finally , it is successful to  deploy openstack via kolla-ansible .
>> So far I have not found any problems.
>>  Are the steps what I took  good ( enough ) ?
>> Thank you !
>>
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/f3b8e3ab/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2938 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/f3b8e3ab/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 95768 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/f3b8e3ab/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 2508 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/f3b8e3ab/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 22016 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/f3b8e3ab/attachment-0007.png>

From mahdi.abbasi.2013 at gmail.com  Thu Sep  3 16:10:42 2020
From: mahdi.abbasi.2013 at gmail.com (mahdi abbasi)
Date: Thu, 3 Sep 2020 20:40:42 +0430
Subject: Kuryr openstack
Message-ID: <CAOgBtR9kaTOjadLjBOOrvCP1ZC4Ef2jQ0tQR6j_E+uGBKkZg0Q@mail.gmail.com>

Hi development team,

Do i need a special configuration to use kuryr when using openvswitch?
I get the following error when starting Docker container in zun.
Please help me.

Best regards
Mahdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/6a5ac6e5/attachment.html>

From mahdi.abbasi.2013 at gmail.com  Thu Sep  3 16:13:48 2020
From: mahdi.abbasi.2013 at gmail.com (mahdi abbasi)
Date: Thu, 3 Sep 2020 20:43:48 +0430
Subject: Kuryr openstack
Message-ID: <CAOgBtR8yT+HZaRizm4H1342zfvoFpm32xCyi++YJZgQ_yOzirQ@mail.gmail.com>

Hi development team,

Do i need a special configuration to use kuryr when using openvswitch?
I get the following error when starting Docker container in zun:

Unable to create the network.No tenant network is availble for allocation.

Please help me.

Best regards
Mahdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/375fd6fb/attachment.html>

From arnaud.morin at gmail.com  Thu Sep  3 17:00:52 2020
From: arnaud.morin at gmail.com (Arnaud Morin)
Date: Thu, 3 Sep 2020 17:00:52 +0000
Subject: Issue with libvirt unable to kill processes
In-Reply-To: <2151e1e5-ffeb-52b2-bd8f-68d2f8d93d36@civo.com>
References: <2151e1e5-ffeb-52b2-bd8f-68d2f8d93d36@civo.com>
Message-ID: <20200903170052.GE31915@sync>

Hello,

Did you check /var/log/libvirt/libvirtd.log?

Cheers,
-- 
Arnaud Morin

On 03.09.20 - 10:59, Grant Morley wrote:
> Hi All,
> 
> I was wondering if anyone has come across an issue with libvirt seemingly
> having an issue with instances all of a sudden "locking up" with the
> following error:
> 
> Failed to terminate process 2263874 with SIGKILL: Device or resource busy
> 
> In the nova logs I am seeing:
> 
> 2020-09-03 09:13:43.208 2659995 INFO nova.compute.manager
> [req-7ffb9b7c-799b-40dc-be04-598bfda2e2fc 6ddb647baf9343b09d7f8f7a32b0b43d
> 8cce5e1532e6435a90b168077664bbdf - default default] [instance:
> f3a8c916-28f5-432d-9b8e-c3056d2dee5a] Rebooting instance
> 2020-09-03 09:15:52.429 2659995 WARNING nova.virt.libvirt.driver
> [req-7ffb9b7c-799b-40dc-be04-598bfda2e2fc 6ddb647baf9343b09d7f8f7a32b0b43d
> 8cce5e1532e6435a90b168077664bbdf - default default] [instance:
> f3a8c916-28f5-432d-9b8e-c3056d2dee5a] Failed to soft reboot instance. Trying
> hard reboot.
> 2020-09-03 09:16:32.450 2659995 WARNING nova.virt.libvirt.driver
> [req-7ffb9b7c-799b-40dc-be04-598bfda2e2fc 6ddb647baf9343b09d7f8f7a32b0b43d
> 8cce5e1532e6435a90b168077664bbdf - default default] [instance:
> f3a8c916-28f5-432d-9b8e-c3056d2dee5a] Error from libvirt during destroy.
> Code=38 Error=Failed to terminate process 2263874 with SIGKILL: Device or
> resource busy; attempt 1 of 3: libvirtError: Failed to terminate process
> 2263874 with SIGKILL: Device or resource busy
> 2020-09-03 09:17:12.484 2659995 WARNING nova.virt.libvirt.driver
> [req-7ffb9b7c-799b-40dc-be04-598bfda2e2fc 6ddb647baf9343b09d7f8f7a32b0b43d
> 8cce5e1532e6435a90b168077664bbdf - default default] [instance:
> f3a8c916-28f5-432d-9b8e-c3056d2dee5a] Error from libvirt during destroy.
> Code=38 Error=Failed to terminate process 2263874 with SIGKILL: Device or
> resource busy; attempt 2 of 3: libvirtError: Failed to terminate process
> 2263874 with SIGKILL: Device or resource busy
> 2020-09-03 09:17:52.516 2659995 WARNING nova.virt.libvirt.driver
> [req-7ffb9b7c-799b-40dc-be04-598bfda2e2fc 6ddb647baf9343b09d7f8f7a32b0b43d
> 8cce5e1532e6435a90b168077664bbdf - default default] [instance:
> f3a8c916-28f5-432d-9b8e-c3056d2dee5a] Error from libvirt during destroy.
> Code=38 Error=Failed to terminate process 2263874 with SIGKILL: Device or
> resource busy; attempt 3 of 3: libvirtError: Failed to terminate process
> 2263874 with SIGKILL: Device or resource busy
> 2020-09-03 09:17:52.526 2659995 ERROR nova.compute.manager
> [req-7ffb9b7c-799b-40dc-be04-598bfda2e2fc 6ddb647baf9343b09d7f8f7a32b0b43d
> 8cce5e1532e6435a90b168077664bbdf - default default] [instance:
> f3a8c916-28f5-432d-9b8e-c3056d2dee5a] Cannot reboot instance: Failed to
> terminate process 2263874 with SIGKILL: Device or resource busy:
> libvirtError: Failed to terminate process 2263874 with SIGKILL: Device or
> resource busy
> 2020-09-03 09:17:53.026 2659995 INFO nova.compute.manager
> [req-7ffb9b7c-799b-40dc-be04-598bfda2e2fc 6ddb647baf9343b09d7f8f7a32b0b43d
> 8cce5e1532e6435a90b168077664bbdf - default default] [instance:
> f3a8c916-28f5-432d-9b8e-c3056d2dee5a] Successfully reverted task state from
> reboot_started on failure for instance.
> 
> It seems to be caused when a reboot happens to an instance.
> 
> If you reset the state and try again, the same error occurs.  You also
> seemingly cannot kill off any libvirt process that is attached to that
> instance.
> 
> To me it looks like it could be a kernel issue with libvirt but I could be
> wrong?
> 
> Does anyone know of a workaround for this other than maybe restarting a
> compute host?
> 
> Many thanks,
> 
> 
> 


From CAPSEY at augusta.edu  Thu Sep  3 19:11:03 2020
From: CAPSEY at augusta.edu (Apsey, Christopher)
Date: Thu, 3 Sep 2020 19:11:03 +0000
Subject: [nova] Session Recording for Feedback
Message-ID: <BN8PR03MB5123CE05020D2CD8CF2D52D8DD2C0@BN8PR03MB5123.namprd03.prod.outlook.com>

Nova supports using the websockify -record functionality to capture frames sent over arbitrary console sessions.  Currently, the record = path/to/file option in nova.conf saves these sessions on nova-(spice|vnc)proxy endpoints at the specified path in the format of /path/to/file.(session number).  These session numbers appear to be incrementally created starting from 1 and don't really have an association with their respective instance from what I can tell.  It would be useful to have these files saved using the instance UUID instead.

Ignoring that minor problem, playing back these files is a challenge.  I've tried using noVNCs vnc_playback.html function from both the master branch and stable/v0.6 with no luck - it looks like the libraries and the utilities haven't been maintained at the same cadence and there are missing functions that the player is expecting.

My goal here is to be able to capture the activities of students as they progress through various exercises and then have instructors be able to go over their work with them after the fact if they have questions.  Has anyone been able to do this (or something like this) successfully, or are we just better off trying to do this in-band per instance?

Chris Apsey
GEORGIA CYBER CENTER

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/ca7dd57b/attachment.html>

From skaplons at redhat.com  Thu Sep  3 20:02:36 2020
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Thu, 3 Sep 2020 22:02:36 +0200
Subject: [neutron] Drivers meeting - 04.09.2020
Message-ID: <20200903200236.efjy5jii3w3rtt4b@skaplons-mac>

Hi,

As there is no agenda for tomorrow's meeting, I will cancel it.
Lets focus on reviewing patches related to the RFE scheduled for Victoria-3:
https://launchpad.net/neutron/+milestone/victoria-3

See You all online and have a great weekend o/

-- 
Slawek Kaplonski
Principal software engineer
Red Hat



From openstack at nemebean.com  Thu Sep  3 21:04:39 2020
From: openstack at nemebean.com (Ben Nemec)
Date: Thu, 3 Sep 2020 16:04:39 -0500
Subject: [oslo] Feature Freeze
Message-ID: <bf654ab7-f2b8-da0c-3aa7-a5b87466345d@nemebean.com>

This is just a heads up that Oslo is now in feature freeze. Any changes 
that would require a feature release of an Oslo library will need to 
request an FFE if they want to make the Victoria release. Please send an 
email tagged "[oslo][ffe]" to the list to make such a request.

I expect we'll branch the Oslo repos in the near future, so some feature 
development can continue then. However, we generally prefer not to merge 
invasive changes between feature freeze and release just in case a 
last-minute bugfix backport is needed. Disentangling a bug fix from a 
major feature could be a chore.

Thanks.

-Ben


From whayutin at redhat.com  Thu Sep  3 23:40:14 2020
From: whayutin at redhat.com (Wesley Hayutin)
Date: Thu, 3 Sep 2020 17:40:14 -0600
Subject: [tripleo] docker.io rate limiting
In-Reply-To: <38d87625-d81a-9fb7-f43c-bb75a14e2984@redhat.com>
References: <CAOHJT4LT68KhRBt3vxb+D-6VpNUPgc2=JBae0nwC8xNZj2EJzQ@mail.gmail.com>
 <38d87625-d81a-9fb7-f43c-bb75a14e2984@redhat.com>
Message-ID: <CAOHJT4JdcH_mV5=UUsqV7MQpJy2WrhFfk86CHA_WiPcuW=agNA@mail.gmail.com>

On Thu, Sep 3, 2020 at 3:48 AM Cédric Jeanneret <cjeanner at redhat.com> wrote:

> Hey Wes,
>
> stupid question: what about the molecule tests? Since they are running
> within containers (centos-8, centos-7, maybe/probably ubi8 soon), we
> might hit some limitations there.... Unless we're NOT using docker.io
> already?
>
> Cheers,
>

OK.. so easy answer
1. we're still going to push to docker.io
2. any content ci uses from docker.io will be mirrored in quay and the rdo
registry including base images.

So I would switch the molecule / tox config to use quay as soon as we have
images there.
I'm searching around for that code in tripleo-ansible and validations and
it's not where I thought it was.

Do you have pointers to where docker.io is configured.
Thanks


>
> C.
>
> On 9/2/20 1:54 PM, Wesley Hayutin wrote:
> > Greetings,
> >
> > Some of you have contacted me regarding the recent news regarding
> > docker.io <http://docker.io>'s new policy with regards to container pull
> > rate limiting [1].  I wanted to take the opportunity to further
> > socialize our plan that will completely remove docker.io
> > <http://docker.io> from our upstream workflows and avoid any rate
> > limiting issues.
> >
> > We will continue to upload containers to docker.io <http://docker.io>
> > for some time so that individuals and the community can access the
> > containers.  We will also start exploring other registries like quay and
> > newly announced github container registry. These other public registries
> > will NOT be used in our upstream jobs and will only serve the
> > communities individual contributors.
> >
> > Our test jobs have been successful and patches are starting to merge to
> > convert our upstream jobs and remove docker.io <http://docker.io> from
> > our upstream workflow.  [2].
> >
> > Standalone and multinode jobs are working quite well.  We are doing some
> > design work around branchful, update/upgrade jobs at this time.
> >
> > Thanks 0/
> >
> >
> > [1] https://hackmd.io/ermQSlQ-Q-mDtZkNN2oihQ
> > [2]
> https://review.opendev.org/#/q/topic:new-ci-job+(status:open+OR+status:merged)
>
> --
> Cédric Jeanneret (He/Him/His)
> Sr. Software Engineer - OpenStack Platform
> Deployment Framework TC
> Red Hat EMEA
> https://www.redhat.com/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200903/ceb440f8/attachment.html>

From pramchan at yahoo.com  Fri Sep  4 01:12:41 2020
From: pramchan at yahoo.com (prakash RAMCHANDRAN)
Date: Fri, 4 Sep 2020 01:12:41 +0000 (UTC)
Subject: [InteropWG] Brainstorming and looking for Ideas from cross project
 teams
References: <1687801759.3070448.1599181961844.ref@mail.yahoo.com>
Message-ID: <1687801759.3070448.1599181961844@mail.yahoo.com>

Hi all,
Interop WG i seeking cross platform participation to enable Baremetal and Kubernetes ready Modules in OpenStack & Open Infrastructure.
Please add what you would like to get help from Interop Group and how in turn you can help Interop WG goals of enabling Multi-Cloud & Hybrid Cloud Logo Programs to be initiated in CY Q4 2019.
We like to discuss and get any new ideas whetted and supported by community. Please add and join us in Forum, PTG and Summit.
https://etherpad.opendev.org/p/2020-Wallaby-interop-brainstorming


Look forward to your Projects valued participation in Interop Branding efforts.Our next Interop Call is shceduled for Sept 11th 10 AM PDT, please add before that all you can bring to table.

For Interop WG Prakash RamchandranIndi Member BoD

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/f2b16cb0/attachment.html>

From sorrison at gmail.com  Fri Sep  4 01:28:23 2020
From: sorrison at gmail.com (Sam Morrison)
Date: Fri, 4 Sep 2020 11:28:23 +1000
Subject: [neutron][networking-midonet] Maintainers needed
In-Reply-To: <92959221-0353-4D48-8726-8FE71AFEA652@gmail.com>
References: <0AC5AC07-E97E-43CC-B344-A3E992B8CCA4@netways.de>
 <610412AF-AADF-44BD-ABA2-BA289B7C8F8A@redhat.com>
 <5E2F5826-559E-42E9-84C5-FA708E5A122A@gmail.com>
 <CAH=wFzS6usQqLeUtZ3iwyzw5f+ph38eaHCEQ0xsKo2ZzMREBgA@mail.gmail.com>
 <43C4AF2B-C5C0-40EB-B621-AC6799471D01@gmail.com>
 <CAH=wFzRmjbCy5vQOrpu=rX4Be-_GYPOE602kDShvV-ZtX+eF6g@mail.gmail.com>
 <92959221-0353-4D48-8726-8FE71AFEA652@gmail.com>
Message-ID: <4D778DBF-F505-462F-B85D-0B372085FA72@gmail.com>

OK have been making some good progress, I now have devstack on bionic working with midonet ml2, it should also work with 20.04 but need to confirm

Needed a couple of patches to networking-midonet to get it working [1]

I also need to point it to our git repo for now until we get the upstream deb packages upgraded

MIDONET_DEB_URI=http://download.rc.nectar.org.au/nectar-ubuntu
MIDONET_DEB_SUITE=bionic

The changes we have on midonet to work with bionic are now in a pull request [2]
Once that’s merged need to find a way to build a new package and upload that to the midonet repo, Yamamoto is that something you can help with?

I’m not sure why the pep8 job is failing, it is complaining about pecan which makes me think this is an issue with neutron itself? Kinda stuck on this one, it’s probably something silly.

For the py3 unit tests they are now failing due to db migration errors in tap-as-a-service, l2-gateway and vpnaas issues I think caused by neutron getting rid of the liberty alembic branch and so we need to squash these on these projects too.



I can now start to look into the devstack zuul jobs.

Cheers,
Sam


[1] https://github.com/NeCTAR-RC/networking-midonet/commits/devstack
[2] https://github.com/midonet/midonet/pull/9




> On 1 Sep 2020, at 4:03 pm, Sam Morrison <sorrison at gmail.com> wrote:
> 
> 
> 
>> On 1 Sep 2020, at 2:59 pm, Takashi Yamamoto <yamamoto at midokura.com> wrote:
>> 
>> hi,
>> 
>> On Tue, Sep 1, 2020 at 1:39 PM Sam Morrison <sorrison at gmail.com> wrote:
>>> 
>>> 
>>> 
>>>> On 1 Sep 2020, at 11:49 am, Takashi Yamamoto <yamamoto at midokura.com> wrote:
>>>> 
>>>> Sebastian, Sam,
>>>> 
>>>> thank you for speaking up.
>>>> 
>>>> as Slawek said, the first (and probably the biggest) thing is to fix the ci.
>>>> the major part for it is to make midonet itself to run on ubuntu
>>>> version used by the ci. (18.04, or maybe directly to 20.04)
>>>> https://midonet.atlassian.net/browse/MNA-1344
>>>> iirc, the remaining blockers are:
>>>> * libreswan (used by vpnaas)
>>>> * vpp (used by fip64)
>>>> maybe it's the easiest to drop those features along with their
>>>> required components, if it's acceptable for your use cases.
>>> 
>>> We are running midonet-cluster and midolman on 18.04, we dropped those package dependencies from our ubuntu package to get it working.
>>> 
>>> We currently have built our own and host in our internal repo but happy to help putting this upstream somehow. Can we upload them to the midonet apt repo, does it still exist?
>> 
>> it still exists. but i don't think it's maintained well.
>> let me find and ask someone in midokura who "owns" that part of infra.
>> 
>> does it also involve some package-related modifications to midonet repo, right?
> 
> 
> Yes a couple, I will send up as as pull requests to https://github.com/midonet/midonet today or tomorrow
> 
> Sam
> 
> 
> 
>> 
>>> 
>>> I’m keen to do the work but might need a bit of guidance to get started,
>>> 
>>> Sam
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> 
>>>> alternatively you might want to make midonet run in a container. (so
>>>> that you can run it with older ubuntu, or even a container trimmed for
>>>> JVM)
>>>> there were a few attempts to containerize midonet.
>>>> i think this is the latest one: https://github.com/midonet/midonet-docker
>>>> 
>>>> On Fri, Aug 28, 2020 at 7:10 AM Sam Morrison <sorrison at gmail.com> wrote:
>>>>> 
>>>>> We (Nectar Research Cloud) use midonet heavily too, it works really well and we haven’t found another driver that works for us. We tried OVN but it just doesn’t scale to the size of environment we have.
>>>>> 
>>>>> I’m happy to help too.
>>>>> 
>>>>> Cheers,
>>>>> Sam
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 31 Jul 2020, at 2:06 am, Slawek Kaplonski <skaplons at redhat.com> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Thx Sebastian for stepping in to maintain the project. That is great news.
>>>>>> I think that at the beginning You should do 2 things:
>>>>>> - sync with Takashi Yamamoto (I added him to the loop) as he is probably most active current maintainer of this project,
>>>>>> - focus on fixing networking-midonet ci which is currently broken - all scenario jobs aren’t working fine on Ubuntu 18.04 (and we are going to move to 20.04 in this cycle), migrate jobs to zuulv3 from the legacy ones and finally add them to the ci again,
>>>>>> 
>>>>>> I can of course help You with ci jobs if You need any help. Feel free to ping me on IRC or email (can be off the list).
>>>>>> 
>>>>>>> On 29 Jul 2020, at 15:24, Sebastian Saemann <Sebastian.Saemann at netways.de> wrote:
>>>>>>> 
>>>>>>> Hi Slawek,
>>>>>>> 
>>>>>>> we at NETWAYS are running most of our neutron networking on top of midonet and wouldn't be too happy if it gets deprecated and removed. So we would like to take over the maintainer role for this part.
>>>>>>> 
>>>>>>> Please let me know how to proceed and how we can be onboarded easily.
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> 
>>>>>>> Sebastian
>>>>>>> 
>>>>>>> --
>>>>>>> Sebastian Saemann
>>>>>>> Head of Managed Services
>>>>>>> 
>>>>>>> NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
>>>>>>> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
>>>>>>> CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB25207
>>>>>>> https://netways.de | sebastian.saemann at netways.de
>>>>>>> 
>>>>>>> ** NETWAYS Web Services - https://nws.netways.de **
>>>>>> 
>>>>>> —
>>>>>> Slawek Kaplonski
>>>>>> Principal software engineer
>>>>>> Red Hat



From ltomasbo at redhat.com  Fri Sep  4 06:38:53 2020
From: ltomasbo at redhat.com (Luis Tomas Bolivar)
Date: Fri, 4 Sep 2020 08:38:53 +0200
Subject: Kuryr openstack
In-Reply-To: <CAOgBtR8yT+HZaRizm4H1342zfvoFpm32xCyi++YJZgQ_yOzirQ@mail.gmail.com>
References: <CAOgBtR8yT+HZaRizm4H1342zfvoFpm32xCyi++YJZgQ_yOzirQ@mail.gmail.com>
Message-ID: <CAAxCcbtF++gOOrpgq5-egK=0a_jjNOAFG2+GcYNrokHjkc-QDQ@mail.gmail.com>

Hi Mahdi,


On Thu, Sep 3, 2020 at 6:46 PM mahdi abbasi <mahdi.abbasi.2013 at gmail.com>
wrote:

> Hi development team,
>
> Do i need a special configuration to use kuryr when using openvswitch?
>

Are you using kuryr-kubernetes or kuryr-libnetwork?

And yes, it works find with openvswitch. Only caveat is that for nested
environments (running kuryr-kubernetes inside OpenStack VMs), the firewall
driver must be set to openvswitch (instead of iptables_hybrid)

> I get the following error when starting Docker container in zun:
>
> Unable to create the network.No tenant network is availble for allocation.
>

Seems like you are using the namespace subnet driver (1 neutron subnet per
k8s namespace) and you have not set up a neutron subnet pool to use.

Cheers,
Luis

>
> Please help me.
>
> Best regards
> Mahdi
>


-- 
LUIS TOMÁS BOLÍVAR
Senior Software Engineer
Red Hat
Madrid, Spain
ltomasbo at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/30415730/attachment.html>

From mark at stackhpc.com  Fri Sep  4 07:26:14 2020
From: mark at stackhpc.com (Mark Goddard)
Date: Fri, 4 Sep 2020 08:26:14 +0100
Subject: [ironic] [stable] Bifrost stable/stein is broken (by eventlet?):
 help needed
In-Reply-To: <CACNgkFxM0KvtMb6N9X9uOVXfD7ryotv3WomKc0QgHs9rwz4jNg@mail.gmail.com>
References: <CACNgkFxM0KvtMb6N9X9uOVXfD7ryotv3WomKc0QgHs9rwz4jNg@mail.gmail.com>
Message-ID: <CAFHSqWqDWGDjrYVD3_msn2EnYd71nWJjjMd9eMB3fzzHG3NCTA@mail.gmail.com>

On Thu, 3 Sep 2020 at 11:31, Dmitry Tantsur <dtantsur at redhat.com> wrote:
>
> Hi folks,
>
> I'm trying to revive the Bifrost stable/stein CI, and after fixing a bunch of issues in https://review.opendev.org/749014 I've hit a wall with what seems an eventlet problem: ironic-inspector fails to start with:
>
> Exception AttributeError: "'_SocketDuckForFd' object has no attribute '_closed'" in <bound method _SocketDuckForFd.__del__ of _SocketDuckForFd:16> ignored
>
> I've managed to find similar issues, but they should have been resolved in the eventlet version in stein (0.24.1). Any ideas?
>
> If we cannot fix it, we'll have to EOL stein and earlier on bifrost.

Strange. Do you know why this affects only bifrost and not ironic inspector CI?

>
> Dmitry
>
> --
> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill


From mark at stackhpc.com  Fri Sep  4 07:31:38 2020
From: mark at stackhpc.com (Mark Goddard)
Date: Fri, 4 Sep 2020 08:31:38 +0100
Subject: [all][TC] OpenStack Client (OSC) vs python-*clients
In-Reply-To: <ECE19EB9-92E2-4790-A2FF-38378F3E8E7B@gmail.com>
References: <CAPkQhndGy1VrBT1yOCXQaZcgDxXr5ww9RL1VnU45iHsDJqZpcw@mail.gmail.com>
 <CAKZ_x7_CCbHzVdruU2BvS7kK1mvte+1AW1PJptwVzFJQVVCs4Q@mail.gmail.com>
 <1668118.VLH7GnMWUR@whitebase.usersys.redhat.com>
 <CACqyMicKobe7WnQfKEixAM3pTN0+9JdNGQUR8Z9KeW9bE9Xizw@mail.gmail.com>
 <9cbf9d69a9beb30d03af71e42a3e2446a516292a.camel@redhat.com>
 <CADO3vb4ufSnUpEwk8xk-6WQ9k8QKqnAnkWS1V+6U0x-nZnL7oQ@mail.gmail.com>
 <CAKwVDDOOu_Y6FFu1RQL+vKKg0D+w=qbjzHYzuk06dtjJ4qjjhQ@mail.gmail.com>
 <20200813164131.bdmhankpd2qxycux@yuggoth.org>
 <CACqyMieYo7tTtWVhRFJnEoWGGJrJHxERtDWfjHwE2gg22STMyw@mail.gmail.com>
 <2956d6bd-320e-34ea-64a0-1001e102d75c@gmail.com>
 <c79cfe11-985c-2e0b-6834-2b9ab0b28f83@gmx.com>
 <CAPkQhneiV_-7Eiqkf9B=y1N9X-=LjwvnGYj3jGTFyLDJFPdxcA@mail.gmail.com>
 <CACqyMicjXQm9gWOb_V6ODo4ziwmLHRhzkHEdbSafpA3ad_aaNg@mail.gmail.com>
 <ECE19EB9-92E2-4790-A2FF-38378F3E8E7B@gmail.com>
Message-ID: <CAFHSqWoEf3SB6WuWJBYZWjJ5mS8ONOuevEgD=rDHKrN+3MhQ5w@mail.gmail.com>

On Thu, 3 Sep 2020 at 16:45, Artem Goncharov <artem.goncharov at gmail.com> wrote:
>
>
>
> > On 3. Sep 2020, at 17:10, Artom Lifshitz <alifshit at redhat.com> wrote:
> >
> > On Thu, Sep 3, 2020 at 9:05 AM Belmiro Moreira
> > <moreira.belmiro.email.lists at gmail.com> wrote:
> >>
> >> Hi everyone,
> >> thank you for all your comments.
> >> However, I don't think we have reached any conclusion.
> >>
> >> It would be great if the SDK/openstackclient team and the different projects that raised some concerns can collaborate and move forward.
> >> Personally, I believe that the current situation is a very bad user experience.
> >>
> >> Let us know how the TC can help.
> >
> > Can we start by agreeing (or can the TC just top-down mandate?) an end
> > state we want to get to? The way I've understood it and see it, what
> > we're aiming for is:
> >
> > A. osc is user-facing CLI shell around sdk
> > B. sdk is the only official client library for interacting with the
> > OpenStack REST APIs
> >
> > I've been working with those assumptions for [1] and addressing point
> > B, leaving point A to the osc team.
> >
> > If we take B to be true, patches like [2] would get blocked and
> > redirected to the SDK for the API logic, with only the CLI parts in
> > the osc. That doesn't seem to be the case, so I don't know what to
> > think anymore.
> >
>
> From all the discussions we held over the time, yes, A is definitely our target (while there might be still special cases)
>
> As SDK/OSC team we can say: B is true in a perfect world, but it is not a valid statement today. Somebody need to invest pretty huge effort in making this happen (I know this since I already invested in switching image part). During this time all the changes to OSC for things not based on SDK would need to be blocked. Amount of active people deep in the code of SDK/CLI is too small currently to handle this fast. On the other side, if nova team commits to do their patches to SDK first (what I see you guys are definitely doing, a great Thanks!) - we would be able to switch CLI for nova to SDK much easier.
> The more teams would be doing that, the easier would it be to clean OSC up.
>
> Very unfortunately since last PTG there were only very minor activities in SDK/OSC team, but I would like to change this now (unfortunately there are still just 24 hours in the day). Let me see where I can find another few hours a day for repairing things and set a personal (or hopefully SDK team) target to move at least few nova resources onto CLI at SDK until next PTG. ;-)

I'm not working on this, and haven't been following it, but honestly
given the current level of activity in OpenStack this sounds unlikely
to happen. IMO from a user perspective, focussing on feature parity
for OSC for all clients should be the priority, especially when teams
like Glance say they would need multiple cycles with both clients
maintaining parity in order to deprecate and drop their legacy client.

>
> Regards,
> Another Artem


From mark at stackhpc.com  Fri Sep  4 07:32:45 2020
From: mark at stackhpc.com (Mark Goddard)
Date: Fri, 4 Sep 2020 08:32:45 +0100
Subject: [tripleo] centos-binary -> openstack-
In-Reply-To: <CAOHJT4Jk-QQES2FU_GSO=M=6F60xyo0tE+zzwXe92PU8oGWKZg@mail.gmail.com>
References: <CAOHJT4Jk-QQES2FU_GSO=M=6F60xyo0tE+zzwXe92PU8oGWKZg@mail.gmail.com>
Message-ID: <CAFHSqWp0pcEgLUoQPupCb9Z7ykqsyWay=b-U+CJjiX8VygvpUw@mail.gmail.com>

On Thu, 3 Sep 2020 at 12:56, Wesley Hayutin <whayutin at redhat.com> wrote:
>
> Greetings,
>
> The container names in master have changed from centos-binary* to openstack*.
> https://opendev.org/openstack/tripleo-common/src/branch/master/container-images/tripleo_containers.yaml
>
> https://opendev.org/openstack/tripleo-common/commit/90f6de7a7fab15e9161c1f03acecaf98726298f1
>
> If your patches are failing to pull https://registry-1.docker.io/v2/tripleomaster/centos-binary* it's not going to be fixed in a recheck. Check that your patches are rebased and your dependent patches are rebased.

Hi Wes,

Can we infer from this that Tripleo is no longer using Kolla on master?

>
> Thanks 0/


From hberaud at redhat.com  Fri Sep  4 07:44:19 2020
From: hberaud at redhat.com (Herve Beraud)
Date: Fri, 4 Sep 2020 09:44:19 +0200
Subject: [oslo][ffe] request for oslo
Message-ID: <CAFDq9gUjij-4yBsVEgNz8ZFno_+JbCs0e4ie5TnA9x8Fi5+v-Q@mail.gmail.com>

Hey Oslofolk,

I request an FFE for these oslo.messaging changes [1].

The goal of these changes is to run rabbitmq heartbeat in python thread by
default.

Also these changes deprecating this option to prepare future removal and
force to always run heartbeat in a python thread whatever the context.

Land these changes during the victoria cycle can help us to prime the
option removal during the next cycle.

Thanks for your time,

[1] https://review.opendev.org/#/c/747395/

-- 
Hervé Beraud
Senior Software Engineer
Red Hat - Openstack Oslo
irc: hberaud
-----BEGIN PGP SIGNATURE-----

wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+
Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+
RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP
F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G
5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g
glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw
m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ
hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0
qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y
F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3
B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O
v6rDpkeNksZ9fFSyoY2o
=ECSj
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/203fba34/attachment.html>

From zhangbailin at inspur.com  Fri Sep  4 08:41:21 2020
From: zhangbailin at inspur.com (=?gb2312?B?QnJpbiBaaGFuZyjVxbDZwdYp?=)
Date: Fri, 4 Sep 2020 08:41:21 +0000
Subject: [mq][mariadb] What kind of reasons are considered when choosing the
 mq/mariadb version
Message-ID: <a6a8446b15de42cfb6bae54bff7b7b11@inspur.com>

Hi all



We are using kolla to build the OpenStack, use kolla-ansible to deploy

rabbitmq is v3.7.10, mariadb is v10.1.x when building Rocky release

rabbitmq is v3.8.5, mariadb is v10.3.x when building Ussuri release



what kind of reasons are considered as rabbitmq version is changed from v3.7.10 to v3.8.5 ?

what kind of reasons are considered as mariadb version is changed from v10.1.x to v10.3.x ?



If you can provide an explanation, or key explanation, we would be very grateful.

Thanks.



brinzhang



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/69dc349f/attachment-0001.html>

From yamamoto at midokura.com  Fri Sep  4 08:47:04 2020
From: yamamoto at midokura.com (Takashi Yamamoto)
Date: Fri, 4 Sep 2020 17:47:04 +0900
Subject: [neutron][networking-midonet] Maintainers needed
In-Reply-To: <4D778DBF-F505-462F-B85D-0B372085FA72@gmail.com>
References: <0AC5AC07-E97E-43CC-B344-A3E992B8CCA4@netways.de>
 <610412AF-AADF-44BD-ABA2-BA289B7C8F8A@redhat.com>
 <5E2F5826-559E-42E9-84C5-FA708E5A122A@gmail.com>
 <CAH=wFzS6usQqLeUtZ3iwyzw5f+ph38eaHCEQ0xsKo2ZzMREBgA@mail.gmail.com>
 <43C4AF2B-C5C0-40EB-B621-AC6799471D01@gmail.com>
 <CAH=wFzRmjbCy5vQOrpu=rX4Be-_GYPOE602kDShvV-ZtX+eF6g@mail.gmail.com>
 <92959221-0353-4D48-8726-8FE71AFEA652@gmail.com>
 <4D778DBF-F505-462F-B85D-0B372085FA72@gmail.com>
Message-ID: <CAH=wFzRiJd=93cYsK5FJxJcmMb6eY-XDco1zQOfueMw-0s2Tcw@mail.gmail.com>

On Fri, Sep 4, 2020 at 10:28 AM Sam Morrison <sorrison at gmail.com> wrote:
>
> OK have been making some good progress, I now have devstack on bionic working with midonet ml2, it should also work with 20.04 but need to confirm

nice work. thank you.

>
> Needed a couple of patches to networking-midonet to get it working [1]
>
> I also need to point it to our git repo for now until we get the upstream deb packages upgraded
>
> MIDONET_DEB_URI=http://download.rc.nectar.org.au/nectar-ubuntu
> MIDONET_DEB_SUITE=bionic
>
> The changes we have on midonet to work with bionic are now in a pull request [2]
> Once that’s merged need to find a way to build a new package and upload that to the midonet repo, Yamamoto is that something you can help with?

i'm talking to our infra folks but it might take longer than i hoped.
if you or someone else can provide a public repo, it might be faster.
(i have looked at launchpad PPA while ago. but it didn't seem
straightforward given the complex build machinary in midonet.)

>
> I’m not sure why the pep8 job is failing, it is complaining about pecan which makes me think this is an issue with neutron itself? Kinda stuck on this one, it’s probably something silly.

probably.

>
> For the py3 unit tests they are now failing due to db migration errors in tap-as-a-service, l2-gateway and vpnaas issues I think caused by neutron getting rid of the liberty alembic branch and so we need to squash these on these projects too.

this thing? https://review.opendev.org/#/c/749866/

>
>
>
> I can now start to look into the devstack zuul jobs.
>
> Cheers,
> Sam
>
>
> [1] https://github.com/NeCTAR-RC/networking-midonet/commits/devstack
> [2] https://github.com/midonet/midonet/pull/9
>
>
>
>
> > On 1 Sep 2020, at 4:03 pm, Sam Morrison <sorrison at gmail.com> wrote:
> >
> >
> >
> >> On 1 Sep 2020, at 2:59 pm, Takashi Yamamoto <yamamoto at midokura.com> wrote:
> >>
> >> hi,
> >>
> >> On Tue, Sep 1, 2020 at 1:39 PM Sam Morrison <sorrison at gmail.com> wrote:
> >>>
> >>>
> >>>
> >>>> On 1 Sep 2020, at 11:49 am, Takashi Yamamoto <yamamoto at midokura.com> wrote:
> >>>>
> >>>> Sebastian, Sam,
> >>>>
> >>>> thank you for speaking up.
> >>>>
> >>>> as Slawek said, the first (and probably the biggest) thing is to fix the ci.
> >>>> the major part for it is to make midonet itself to run on ubuntu
> >>>> version used by the ci. (18.04, or maybe directly to 20.04)
> >>>> https://midonet.atlassian.net/browse/MNA-1344
> >>>> iirc, the remaining blockers are:
> >>>> * libreswan (used by vpnaas)
> >>>> * vpp (used by fip64)
> >>>> maybe it's the easiest to drop those features along with their
> >>>> required components, if it's acceptable for your use cases.
> >>>
> >>> We are running midonet-cluster and midolman on 18.04, we dropped those package dependencies from our ubuntu package to get it working.
> >>>
> >>> We currently have built our own and host in our internal repo but happy to help putting this upstream somehow. Can we upload them to the midonet apt repo, does it still exist?
> >>
> >> it still exists. but i don't think it's maintained well.
> >> let me find and ask someone in midokura who "owns" that part of infra.
> >>
> >> does it also involve some package-related modifications to midonet repo, right?
> >
> >
> > Yes a couple, I will send up as as pull requests to https://github.com/midonet/midonet today or tomorrow
> >
> > Sam
> >
> >
> >
> >>
> >>>
> >>> I’m keen to do the work but might need a bit of guidance to get started,
> >>>
> >>> Sam
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>> alternatively you might want to make midonet run in a container. (so
> >>>> that you can run it with older ubuntu, or even a container trimmed for
> >>>> JVM)
> >>>> there were a few attempts to containerize midonet.
> >>>> i think this is the latest one: https://github.com/midonet/midonet-docker
> >>>>
> >>>> On Fri, Aug 28, 2020 at 7:10 AM Sam Morrison <sorrison at gmail.com> wrote:
> >>>>>
> >>>>> We (Nectar Research Cloud) use midonet heavily too, it works really well and we haven’t found another driver that works for us. We tried OVN but it just doesn’t scale to the size of environment we have.
> >>>>>
> >>>>> I’m happy to help too.
> >>>>>
> >>>>> Cheers,
> >>>>> Sam
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On 31 Jul 2020, at 2:06 am, Slawek Kaplonski <skaplons at redhat.com> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> Thx Sebastian for stepping in to maintain the project. That is great news.
> >>>>>> I think that at the beginning You should do 2 things:
> >>>>>> - sync with Takashi Yamamoto (I added him to the loop) as he is probably most active current maintainer of this project,
> >>>>>> - focus on fixing networking-midonet ci which is currently broken - all scenario jobs aren’t working fine on Ubuntu 18.04 (and we are going to move to 20.04 in this cycle), migrate jobs to zuulv3 from the legacy ones and finally add them to the ci again,
> >>>>>>
> >>>>>> I can of course help You with ci jobs if You need any help. Feel free to ping me on IRC or email (can be off the list).
> >>>>>>
> >>>>>>> On 29 Jul 2020, at 15:24, Sebastian Saemann <Sebastian.Saemann at netways.de> wrote:
> >>>>>>>
> >>>>>>> Hi Slawek,
> >>>>>>>
> >>>>>>> we at NETWAYS are running most of our neutron networking on top of midonet and wouldn't be too happy if it gets deprecated and removed. So we would like to take over the maintainer role for this part.
> >>>>>>>
> >>>>>>> Please let me know how to proceed and how we can be onboarded easily.
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>>
> >>>>>>> Sebastian
> >>>>>>>
> >>>>>>> --
> >>>>>>> Sebastian Saemann
> >>>>>>> Head of Managed Services
> >>>>>>>
> >>>>>>> NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
> >>>>>>> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
> >>>>>>> CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB25207
> >>>>>>> https://netways.de | sebastian.saemann at netways.de
> >>>>>>>
> >>>>>>> ** NETWAYS Web Services - https://nws.netways.de **
> >>>>>>
> >>>>>> —
> >>>>>> Slawek Kaplonski
> >>>>>> Principal software engineer
> >>>>>> Red Hat
>


From radoslaw.piliszek at gmail.com  Fri Sep  4 10:16:29 2020
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Fri, 4 Sep 2020 12:16:29 +0200
Subject: [mq][mariadb] What kind of reasons are considered when choosing
 the mq/mariadb version
In-Reply-To: <a6a8446b15de42cfb6bae54bff7b7b11@inspur.com>
References: <a6a8446b15de42cfb6bae54bff7b7b11@inspur.com>
Message-ID: <CAKZ_x7-TbJYFiz9WoUuoc=Od_xCYSXJbY8gsD+sF93gwL5JaXg@mail.gmail.com>

Hi Brin,

most of the time the distribution dictates the new version.
However, sometimes it is forced due to issues with new versions of
OpenStack and old versions of these dependencies (for example MariaDB
10.1 would fail to work with newer releases due to lack of MySQL
compatibility).
Newer versions usually mean new features that are useful for end
users. In this case RabbitMQ 3.8 shines with its new Prometheus
exporter.
We generally try to avoid needless updates but still stay current
enough to receive proper support from upstreams and satisfy the users.

-yoctozepto

On Fri, Sep 4, 2020 at 10:54 AM Brin Zhang(张百林) <zhangbailin at inspur.com> wrote:
>
> Hi all
>
>
>
> We are using kolla to build the OpenStack, use kolla-ansible to deploy
>
> rabbitmq is v3.7.10, mariadb is v10.1.x when building Rocky release
>
> rabbitmq is v3.8.5, mariadb is v10.3.x when building Ussuri release
>
>
>
> what kind of reasons are considered as rabbitmq version is changed from v3.7.10 to v3.8.5 ?
>
> what kind of reasons are considered as mariadb version is changed from v10.1.x to v10.3.x ?
>
>
>
> If you can provide an explanation, or key explanation, we would be very grateful.
>
> Thanks.
>
>
>
> brinzhang
>
>


From tom.v.black at gmail.com  Fri Sep  4 10:29:49 2020
From: tom.v.black at gmail.com (Tom Black)
Date: Fri, 4 Sep 2020 18:29:49 +0800
Subject: [mq][mariadb] What kind of reasons are considered when choosing
 the mq/mariadb version
In-Reply-To: <CAKZ_x7-TbJYFiz9WoUuoc=Od_xCYSXJbY8gsD+sF93gwL5JaXg@mail.gmail.com>
References: <a6a8446b15de42cfb6bae54bff7b7b11@inspur.com>
 <CAKZ_x7-TbJYFiz9WoUuoc=Od_xCYSXJbY8gsD+sF93gwL5JaXg@mail.gmail.com>
Message-ID: <ea60983b-88f0-7342-c56d-7247e3fb2d3e@gmail.com>

Also rabbitmq 3.8 has a lot of performance improvement than the older 
versions.

regards.

Radosław Piliszek wrote:
> Newer versions usually mean new features that are useful for end
> users. In this case RabbitMQ 3.8 shines with its new Prometheus
> exporter.


From smooney at redhat.com  Fri Sep  4 11:02:54 2020
From: smooney at redhat.com (Sean Mooney)
Date: Fri, 04 Sep 2020 12:02:54 +0100
Subject: [nova] Session Recording for Feedback
In-Reply-To: <BN8PR03MB5123CE05020D2CD8CF2D52D8DD2C0@BN8PR03MB5123.namprd03.prod.outlook.com>
References: <BN8PR03MB5123CE05020D2CD8CF2D52D8DD2C0@BN8PR03MB5123.namprd03.prod.outlook.com>
Message-ID: <8ba2f8e59877f796558158a950be3acbd10eb0f9.camel@redhat.com>

On Thu, 2020-09-03 at 19:11 +0000, Apsey, Christopher wrote:
> Nova supports using the websockify -record functionality to capture frames sent over arbitrary console sessions.
am that is an overstatement of novas capablity.
you may be able to use -record but that is not a deliberate feature that we support as far as i am aware.
we do not have a rest api for this functionality so ist not consumable by non admins that dont have access to the host.
the capability is really an implematnion detail that is not well deocumented and not part fo the public api. so i would
not frame it as nova supports this usecase more that the config option was just added when nova-novncproce was brought
back into nova in https://github.com/openstack/nova/commit/13871ad4f39361531dff1abd7f9257369862cccc

its proably something that never should have existed in the nova tree. suspect it was added by the novnc folks
when the nova novncproxy code was in the novnc repo and it was included in our repo to have parity when we imported it.
so its an option that still exits but i like me im sure its news to others and i dont think its something we would want
to continue to support in its current form.

>   Currently, the record = path/to/file option in nova.conf saves these sessions on nova-(spice|vnc)proxy endpoints at
> the specified path in the format of /path/to/file.(session number).  These session numbers appear to be incrementally
> created starting from 1 and don't really have an association with their respective instance from what I can tell.  It
> would be useful to have these files saved using the instance UUID instead.
you are refering to this options
https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.record
https://github.com/openstack/nova/blob/master/nova/conf/novnc.py#L19-L24

i assume that you would prefer that instead of recoding the info via session id it was using the instace uuid or a
combination of both for simple correalation. im more of thet mind that now that we have observed this still exists we
proably should deprecated it and remove it rather then enhance it

> 
> Ignoring that minor problem, playing back these files is a challenge.  I've tried using noVNCs vnc_playback.html
> function from both the master branch and stable/v0.6 with no luck - it looks like the libraries and the utilities
> haven't been maintained at the same cadence and there are missing functions that the player is expecting.
> 
> My goal here is to be able to capture the activities of students as they progress through various exercises and then
> have instructors be able to go over their work with them after the fact if they have questions.  Has anyone been able
> to do this (or something like this) successfully, or are we just better off trying to do this in-band per instance?
i would suggest doing it in band. it is an interesting usecase ill admit but im not trilled by the idea of having files
recored to the novncproxy host that are never cleaned up. this is off by default so its not a security risk but other
wise it could be a vector to fill the disk of the contoler or novnc proxy host. if we were to properly support this in
nova i would want to see a way to enabel or disable this per instace at the api level an retrive the files possible
storing them to swift or something periodicly at a given size or time interval.  i certenly would want to see size limit
and session limits per instance before considering it supported for production use.

> 
> Chris Apsey
> GEORGIA CYBER CENTER
> 



From emilien at redhat.com  Fri Sep  4 12:11:06 2020
From: emilien at redhat.com (Emilien Macchi)
Date: Fri, 4 Sep 2020 08:11:06 -0400
Subject: [tripleo] centos-binary -> openstack-
In-Reply-To: <CAFHSqWp0pcEgLUoQPupCb9Z7ykqsyWay=b-U+CJjiX8VygvpUw@mail.gmail.com>
References: <CAOHJT4Jk-QQES2FU_GSO=M=6F60xyo0tE+zzwXe92PU8oGWKZg@mail.gmail.com>
 <CAFHSqWp0pcEgLUoQPupCb9Z7ykqsyWay=b-U+CJjiX8VygvpUw@mail.gmail.com>
Message-ID: <CACu=hyt=QkogFfVgLKvzQoQA6_ey93Y6N4-EG=x=93Q9gCEdXQ@mail.gmail.com>

On Fri, Sep 4, 2020 at 3:40 AM Mark Goddard <mark at stackhpc.com> wrote:

> On Thu, 3 Sep 2020 at 12:56, Wesley Hayutin <whayutin at redhat.com> wrote:
> >
> > Greetings,
> >
> > The container names in master have changed from centos-binary* to
> openstack*.
> >
> https://opendev.org/openstack/tripleo-common/src/branch/master/container-images/tripleo_containers.yaml
> >
> >
> https://opendev.org/openstack/tripleo-common/commit/90f6de7a7fab15e9161c1f03acecaf98726298f1
> >
> > If your patches are failing to pull
> https://registry-1.docker.io/v2/tripleomaster/centos-binary* it's not
> going to be fixed in a recheck. Check that your patches are rebased and
> your dependent patches are rebased.
>
> Hi Wes,
>
> Can we infer from this that Tripleo is no longer using Kolla on master?
>

Mark, true, we no longer rely on Kolla on master, and removed our
overrides.
We backported all the work to Ussuri and Train but for backward
compatibility will keep Kolla support.
-- 
Emilien Macchi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/e24ab69d/attachment.html>

From skaplons at redhat.com  Fri Sep  4 12:37:57 2020
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Fri, 4 Sep 2020 14:37:57 +0200
Subject: [neutron][networking-midonet] Maintainers needed
In-Reply-To: <CAH=wFzRiJd=93cYsK5FJxJcmMb6eY-XDco1zQOfueMw-0s2Tcw@mail.gmail.com>
References: <0AC5AC07-E97E-43CC-B344-A3E992B8CCA4@netways.de>
 <610412AF-AADF-44BD-ABA2-BA289B7C8F8A@redhat.com>
 <5E2F5826-559E-42E9-84C5-FA708E5A122A@gmail.com>
 <CAH=wFzS6usQqLeUtZ3iwyzw5f+ph38eaHCEQ0xsKo2ZzMREBgA@mail.gmail.com>
 <43C4AF2B-C5C0-40EB-B621-AC6799471D01@gmail.com>
 <CAH=wFzRmjbCy5vQOrpu=rX4Be-_GYPOE602kDShvV-ZtX+eF6g@mail.gmail.com>
 <92959221-0353-4D48-8726-8FE71AFEA652@gmail.com>
 <4D778DBF-F505-462F-B85D-0B372085FA72@gmail.com>
 <CAH=wFzRiJd=93cYsK5FJxJcmMb6eY-XDco1zQOfueMw-0s2Tcw@mail.gmail.com>
Message-ID: <20200904123757.d6mpyjcyxlgk63od@skaplons-mac>

Hi,

On Fri, Sep 04, 2020 at 05:47:04PM +0900, Takashi Yamamoto wrote:
> On Fri, Sep 4, 2020 at 10:28 AM Sam Morrison <sorrison at gmail.com> wrote:
> >
> > OK have been making some good progress, I now have devstack on bionic working with midonet ml2, it should also work with 20.04 but need to confirm
> 
> nice work. thank you.
> 
> >
> > Needed a couple of patches to networking-midonet to get it working [1]
> >
> > I also need to point it to our git repo for now until we get the upstream deb packages upgraded
> >
> > MIDONET_DEB_URI=http://download.rc.nectar.org.au/nectar-ubuntu
> > MIDONET_DEB_SUITE=bionic
> >
> > The changes we have on midonet to work with bionic are now in a pull request [2]
> > Once that’s merged need to find a way to build a new package and upload that to the midonet repo, Yamamoto is that something you can help with?
> 
> i'm talking to our infra folks but it might take longer than i hoped.
> if you or someone else can provide a public repo, it might be faster.
> (i have looked at launchpad PPA while ago. but it didn't seem
> straightforward given the complex build machinary in midonet.)
> 
> >
> > I’m not sure why the pep8 job is failing, it is complaining about pecan which makes me think this is an issue with neutron itself? Kinda stuck on this one, it’s probably something silly.
> 
> probably.
> 
> >
> > For the py3 unit tests they are now failing due to db migration errors in tap-as-a-service, l2-gateway and vpnaas issues I think caused by neutron getting rid of the liberty alembic branch and so we need to squash these on these projects too.
> 
> this thing? https://review.opendev.org/#/c/749866/

Yes, this revert should solve problem with db migration of some stadium
projects.

> 
> >
> >
> >
> > I can now start to look into the devstack zuul jobs.
> >
> > Cheers,
> > Sam
> >
> >
> > [1] https://github.com/NeCTAR-RC/networking-midonet/commits/devstack
> > [2] https://github.com/midonet/midonet/pull/9
> >
> >
> >
> >
> > > On 1 Sep 2020, at 4:03 pm, Sam Morrison <sorrison at gmail.com> wrote:
> > >
> > >
> > >
> > >> On 1 Sep 2020, at 2:59 pm, Takashi Yamamoto <yamamoto at midokura.com> wrote:
> > >>
> > >> hi,
> > >>
> > >> On Tue, Sep 1, 2020 at 1:39 PM Sam Morrison <sorrison at gmail.com> wrote:
> > >>>
> > >>>
> > >>>
> > >>>> On 1 Sep 2020, at 11:49 am, Takashi Yamamoto <yamamoto at midokura.com> wrote:
> > >>>>
> > >>>> Sebastian, Sam,
> > >>>>
> > >>>> thank you for speaking up.
> > >>>>
> > >>>> as Slawek said, the first (and probably the biggest) thing is to fix the ci.
> > >>>> the major part for it is to make midonet itself to run on ubuntu
> > >>>> version used by the ci. (18.04, or maybe directly to 20.04)
> > >>>> https://midonet.atlassian.net/browse/MNA-1344
> > >>>> iirc, the remaining blockers are:
> > >>>> * libreswan (used by vpnaas)
> > >>>> * vpp (used by fip64)
> > >>>> maybe it's the easiest to drop those features along with their
> > >>>> required components, if it's acceptable for your use cases.
> > >>>
> > >>> We are running midonet-cluster and midolman on 18.04, we dropped those package dependencies from our ubuntu package to get it working.
> > >>>
> > >>> We currently have built our own and host in our internal repo but happy to help putting this upstream somehow. Can we upload them to the midonet apt repo, does it still exist?
> > >>
> > >> it still exists. but i don't think it's maintained well.
> > >> let me find and ask someone in midokura who "owns" that part of infra.
> > >>
> > >> does it also involve some package-related modifications to midonet repo, right?
> > >
> > >
> > > Yes a couple, I will send up as as pull requests to https://github.com/midonet/midonet today or tomorrow
> > >
> > > Sam
> > >
> > >
> > >
> > >>
> > >>>
> > >>> I’m keen to do the work but might need a bit of guidance to get started,
> > >>>
> > >>> Sam
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>
> > >>>> alternatively you might want to make midonet run in a container. (so
> > >>>> that you can run it with older ubuntu, or even a container trimmed for
> > >>>> JVM)
> > >>>> there were a few attempts to containerize midonet.
> > >>>> i think this is the latest one: https://github.com/midonet/midonet-docker
> > >>>>
> > >>>> On Fri, Aug 28, 2020 at 7:10 AM Sam Morrison <sorrison at gmail.com> wrote:
> > >>>>>
> > >>>>> We (Nectar Research Cloud) use midonet heavily too, it works really well and we haven’t found another driver that works for us. We tried OVN but it just doesn’t scale to the size of environment we have.
> > >>>>>
> > >>>>> I’m happy to help too.
> > >>>>>
> > >>>>> Cheers,
> > >>>>> Sam
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> On 31 Jul 2020, at 2:06 am, Slawek Kaplonski <skaplons at redhat.com> wrote:
> > >>>>>>
> > >>>>>> Hi,
> > >>>>>>
> > >>>>>> Thx Sebastian for stepping in to maintain the project. That is great news.
> > >>>>>> I think that at the beginning You should do 2 things:
> > >>>>>> - sync with Takashi Yamamoto (I added him to the loop) as he is probably most active current maintainer of this project,
> > >>>>>> - focus on fixing networking-midonet ci which is currently broken - all scenario jobs aren’t working fine on Ubuntu 18.04 (and we are going to move to 20.04 in this cycle), migrate jobs to zuulv3 from the legacy ones and finally add them to the ci again,
> > >>>>>>
> > >>>>>> I can of course help You with ci jobs if You need any help. Feel free to ping me on IRC or email (can be off the list).
> > >>>>>>
> > >>>>>>> On 29 Jul 2020, at 15:24, Sebastian Saemann <Sebastian.Saemann at netways.de> wrote:
> > >>>>>>>
> > >>>>>>> Hi Slawek,
> > >>>>>>>
> > >>>>>>> we at NETWAYS are running most of our neutron networking on top of midonet and wouldn't be too happy if it gets deprecated and removed. So we would like to take over the maintainer role for this part.
> > >>>>>>>
> > >>>>>>> Please let me know how to proceed and how we can be onboarded easily.
> > >>>>>>>
> > >>>>>>> Best regards,
> > >>>>>>>
> > >>>>>>> Sebastian
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Sebastian Saemann
> > >>>>>>> Head of Managed Services
> > >>>>>>>
> > >>>>>>> NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
> > >>>>>>> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
> > >>>>>>> CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB25207
> > >>>>>>> https://netways.de | sebastian.saemann at netways.de
> > >>>>>>>
> > >>>>>>> ** NETWAYS Web Services - https://nws.netways.de **
> > >>>>>>
> > >>>>>> —
> > >>>>>> Slawek Kaplonski
> > >>>>>> Principal software engineer
> > >>>>>> Red Hat
> >
> 

-- 
Slawek Kaplonski
Principal software engineer
Red Hat



From sean.mcginnis at gmx.com  Fri Sep  4 12:46:59 2020
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Fri, 4 Sep 2020 07:46:59 -0500
Subject: [oslo][ffe] request for oslo
In-Reply-To: <CAFDq9gUjij-4yBsVEgNz8ZFno_+JbCs0e4ie5TnA9x8Fi5+v-Q@mail.gmail.com>
References: <CAFDq9gUjij-4yBsVEgNz8ZFno_+JbCs0e4ie5TnA9x8Fi5+v-Q@mail.gmail.com>
Message-ID: <a1236fc1-12f6-3cae-e6a0-8a148e164c0d@gmx.com>

On 9/4/20 2:44 AM, Herve Beraud wrote:
> Hey Oslofolk,
>
> I request an FFE for these oslo.messaging changes [1].
>
> The goal of these changes is to run rabbitmq heartbeat in python
> thread by default.
>
> Also these changes deprecating this option to prepare future removal
> and force to always run heartbeat in a python thread whatever the context.
>
> Land these changes during the victoria cycle can help us to prime the
> option removal during the next cycle.
>
> Thanks for your time,
>
> [1] https://review.opendev.org/#/c/747395/
>
With the overall non-client library freeze yesterday, this isn't just an
Oslo feature freeze request. It is also a release and requirements
exception as well.

The code change itself is very minor. But this flips a default for a
behavior that hasn't been given very wide usage and runtime. I would be
very cautious about making a change like that right as we are locking
down things and trying to stabilize for the final release. It's a nice
change, but personally I would feel more comfortable giving it all of
the wallaby development cycle running as the new default to make sure
there are no unintended side effects.

I am interested in hearing Ben's opinion though.

Sean



From gfidente at redhat.com  Fri Sep  4 13:22:51 2020
From: gfidente at redhat.com (Giulio Fidente)
Date: Fri, 4 Sep 2020 15:22:51 +0200
Subject: [tripleo] docker.io rate limiting
In-Reply-To: <CAOHJT4LT68KhRBt3vxb+D-6VpNUPgc2=JBae0nwC8xNZj2EJzQ@mail.gmail.com>
References: <CAOHJT4LT68KhRBt3vxb+D-6VpNUPgc2=JBae0nwC8xNZj2EJzQ@mail.gmail.com>
Message-ID: <9f9606a3-d8e8-bc66-3440-8cc5ae080d64@redhat.com>

On 9/2/20 1:54 PM, Wesley Hayutin wrote:
> Greetings,
> 
> Some of you have contacted me regarding the recent news regarding
> docker.io <http://docker.io>'s new policy with regards to container pull
> rate limiting [1].  I wanted to take the opportunity to further
> socialize our plan that will completely remove docker.io
> <http://docker.io> from our upstream workflows and avoid any rate
> limiting issues.

thanks; I guess this will be a problem for the ceph containers as well

> We will continue to upload containers to docker.io <http://docker.io>
> for some time so that individuals and the community can access the
> containers.  We will also start exploring other registries like quay and
> newly announced github container registry. These other public registries
> will NOT be used in our upstream jobs and will only serve the
> communities individual contributors.

I don't think ceph found alternatives yet, but Guillaume or Dimitri
might know more about it
-- 
Giulio Fidente
GPG KEY: 08D733BA



From dtroyer at gmail.com  Fri Sep  4 14:15:48 2020
From: dtroyer at gmail.com (Dean Troyer)
Date: Fri, 4 Sep 2020 09:15:48 -0500
Subject: [all][TC] OpenStack Client (OSC) vs python-*clients
In-Reply-To: <CAPkQhneiV_-7Eiqkf9B=y1N9X-=LjwvnGYj3jGTFyLDJFPdxcA@mail.gmail.com>
References: <CAPkQhndGy1VrBT1yOCXQaZcgDxXr5ww9RL1VnU45iHsDJqZpcw@mail.gmail.com>
 <CAKZ_x7_CCbHzVdruU2BvS7kK1mvte+1AW1PJptwVzFJQVVCs4Q@mail.gmail.com>
 <1668118.VLH7GnMWUR@whitebase.usersys.redhat.com>
 <CACqyMicKobe7WnQfKEixAM3pTN0+9JdNGQUR8Z9KeW9bE9Xizw@mail.gmail.com>
 <9cbf9d69a9beb30d03af71e42a3e2446a516292a.camel@redhat.com>
 <CADO3vb4ufSnUpEwk8xk-6WQ9k8QKqnAnkWS1V+6U0x-nZnL7oQ@mail.gmail.com>
 <CAKwVDDOOu_Y6FFu1RQL+vKKg0D+w=qbjzHYzuk06dtjJ4qjjhQ@mail.gmail.com>
 <20200813164131.bdmhankpd2qxycux@yuggoth.org>
 <CACqyMieYo7tTtWVhRFJnEoWGGJrJHxERtDWfjHwE2gg22STMyw@mail.gmail.com>
 <2956d6bd-320e-34ea-64a0-1001e102d75c@gmail.com>
 <c79cfe11-985c-2e0b-6834-2b9ab0b28f83@gmx.com>
 <CAPkQhneiV_-7Eiqkf9B=y1N9X-=LjwvnGYj3jGTFyLDJFPdxcA@mail.gmail.com>
Message-ID: <CAOJFoEs5rKw9mVxRwbkgmsmQ8gZ2fiDyChapTVzz=8Y7wj7w2g@mail.gmail.com>

On Thu, Sep 3, 2020 at 8:07 AM Belmiro Moreira
<moreira.belmiro.email.lists at gmail.com> wrote:
> However, I don't think we have reached any conclusion.

You have reached the same conclusion that gets reached whenever this
comes up.  Lots of desire and hope, no resources.

> It would be great if the SDK/openstackclient team and the different projects that raised some concerns can collaborate and move forward.

I am going to be blunt.  Until someone steps up to dedicate resources
to both projects the overall situation will only continue to
deteriorate.  Foundation member companies do not see a CLI as a
priority.[0]  And it is much more than a single person can carry...

The SDK is clearly in better shape than OSC, Monty and team are making
great progress there.  For OSC, Keystone was completed as early as it
was because of the priority they put on getting out of the CLI
business and the enormous amount of work Keystone devs did for
OSC..[1]

dt

[0] I was told once by one of the Platinum CEOs that clients (not just
CLIs) were unimportant.  History seems to be more on his side than
ours.
[1] In lieu of forgetting someone I'll just say that said stevemar's
contributions to OSC as a whole are still unequalled.  Thanks Steve!

-- 
Dean Troyer
dtroyer at gmail.com


From Lukasluedke at web.de  Fri Sep  4 14:46:43 2020
From: Lukasluedke at web.de (Lukasluedke at web.de)
Date: Fri, 4 Sep 2020 16:46:43 +0200
Subject: [Kolla Ansible] Error in "heat" stage during deployment - Followed
 Quick Start Guide (ubuntu 18.04.5, virtualbox)
Message-ID: <trinity-902b6c38-b646-4d58-8a2c-779df8554be0-1599230803694@3c-app-webde-bs61>

Hi everyone,
 
I am new to openstack and just followed
the "Quick Start" guide for kolla-ansible
[https://docs.openstack.org/kolla-ansible/ussuri/user/quickstart.html]
on ussuri release, but now having some problems during deployment.
I used virtualbox to create a new vm with ubuntu 18.04.5
[https://releases.ubuntu.com/18.04/ubuntu-18.04.5-live-server-amd64.iso.torrent]
and attached one interface (enp0s3, 10.0.2.15) with Nat-Network and
the second interface as for the neutron interface (enp0s8, no ip)
an internal network and named it "neutron".
Then I followed the guide to create a new virtual python environment
(logged in over ssh using "user" user).
--
sudo apt-get update
sudo apt-get install python3-dev libffi-dev gcc libssl-dev
sudo apt-get install python3-venv

python3 -m venv $(pwd)
source $(pwd)/bin/activate
pip install -U pip
pip install 'ansible<2.10'
--

Everything seems to work as mentioned with no problems so far.
(Beside the missing "python-venv" package in the docs)
--
pip install kolla-ansible
sudo mkdir -p /etc/kolla
sudo chown $USER:$USER /etc/kolla
cp -r $(pwd)/share/kolla-ansible/etc_examples/kolla/* /etc/kolla
cp $(pwd)/share/kolla-ansible/ansible/inventory/* .

mkdir /etc/ansible
sudo nano /etc/ansible/ansible.cfg
### content from /etc/ansible/ansible.cfg
[defaults]
host_key_checking=False
pipelining=True
forks=100
###
--

I then modified the "multinode" file to only deploy on localhost
(replaced all control01, etc. with localhost) as I first wanted
to try openstack on one node.
The ping worked, changed the globals.yml file according to the
documentation, then bootstrap and the prechecks worked
so far with no issue.
--
ansible -i multinode all -m ping
kolla-genpwd

sudo nano /etc/kolla/globals.yml
### additional content of /etc/kolla/globals.yml
kolla_base_distro: "ubuntu"
kolla_install_type: "source"
network_interface: "enp0s3"
neutron_external_interface: "enp0s8"
kolla_internal_vip_address: "10.0.2.10"
###

kolla-ansible -i ./multinode bootstrap-servers
kolla-ansible -i ./multinode prechecks
--

But on the deploy stage I am stuck right now:
--
kolla-ansible -i ./multinode deploy
--

The mentioned error is telling me,
that the keystone service is not available.
I attached the error log file, because the error is longer.
As a side node, now when I try to login using tty,
the vm is nearly frozen and only prompts very, very slowly
(about 10 minutes for prompt). ssh in putty is also frozen
and the connection broke after about 30 minutes.

Does anyone know what is wrong or has some hints/insight on how
to correctly deploy openstack using kolla-ansible?

Best Regards,
Lukas Lüdke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openstack_kolla_error_heat.log
Type: application/octet-stream
Size: 10818 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/285c4bba/attachment.obj>

From mahdi.abbasi.2013 at gmail.com  Fri Sep  4 06:44:33 2020
From: mahdi.abbasi.2013 at gmail.com (mahdi abbasi)
Date: Fri, 4 Sep 2020 11:14:33 +0430
Subject: Kuryr openstack
In-Reply-To: <CAAxCcbtF++gOOrpgq5-egK=0a_jjNOAFG2+GcYNrokHjkc-QDQ@mail.gmail.com>
References: <CAOgBtR8yT+HZaRizm4H1342zfvoFpm32xCyi++YJZgQ_yOzirQ@mail.gmail.com>
 <CAAxCcbtF++gOOrpgq5-egK=0a_jjNOAFG2+GcYNrokHjkc-QDQ@mail.gmail.com>
Message-ID: <CAOgBtR9Cpgv_CiHk1+W-srn7vMw=z-rSzLH92KPMAp7Y=azr4w@mail.gmail.com>

Thanks a alot
This issue has been resolved

On Fri, 4 Sep 2020, 11:09 Luis Tomas Bolivar, <ltomasbo at redhat.com> wrote:

> Hi Mahdi,
>
>
> On Thu, Sep 3, 2020 at 6:46 PM mahdi abbasi <mahdi.abbasi.2013 at gmail.com>
> wrote:
>
>> Hi development team,
>>
>> Do i need a special configuration to use kuryr when using openvswitch?
>>
>
> Are you using kuryr-kubernetes or kuryr-libnetwork?
>
> And yes, it works find with openvswitch. Only caveat is that for nested
> environments (running kuryr-kubernetes inside OpenStack VMs), the firewall
> driver must be set to openvswitch (instead of iptables_hybrid)
>
>> I get the following error when starting Docker container in zun:
>>
>> Unable to create the network.No tenant network is availble for allocation.
>>
>
> Seems like you are using the namespace subnet driver (1 neutron subnet per
> k8s namespace) and you have not set up a neutron subnet pool to use.
>
> Cheers,
> Luis
>
>>
>> Please help me.
>>
>> Best regards
>> Mahdi
>>
>
>
> --
> LUIS TOMÁS BOLÍVAR
> Senior Software Engineer
> Red Hat
> Madrid, Spain
> ltomasbo at redhat.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/2a46ec6f/attachment-0001.html>

From mahdi.abbasi.2013 at gmail.com  Fri Sep  4 06:45:30 2020
From: mahdi.abbasi.2013 at gmail.com (mahdi abbasi)
Date: Fri, 4 Sep 2020 11:15:30 +0430
Subject: Kuryr openstack
In-Reply-To: <CAKZ_x79C-Rvce6GnTCX-g3cgSNfCbcNstjAbZjwdrDcosgJd8g@mail.gmail.com>
References: <CAOgBtR8yT+HZaRizm4H1342zfvoFpm32xCyi++YJZgQ_yOzirQ@mail.gmail.com>
 <CAKZ_x79C-Rvce6GnTCX-g3cgSNfCbcNstjAbZjwdrDcosgJd8g@mail.gmail.com>
Message-ID: <CAOgBtR9+xefqq40E2duCZeRwYGbRp77tE0qtFtpDO8JFJCvOzw@mail.gmail.com>

Thanks a lot
This issue has been resolved

On Thu, 3 Sep 2020, 23:28 Radosław Piliszek, <radoslaw.piliszek at gmail.com>
wrote:

> Hi Mahdi,
>
> have you created any networks (as in Neutron resource) in that project?
> You need to have at least one network for Zun to use.
>
> -yoctozepto
>
> On Thu, Sep 3, 2020 at 6:50 PM mahdi abbasi <mahdi.abbasi.2013 at gmail.com>
> wrote:
> >
> > Hi development team,
> >
> > Do i need a special configuration to use kuryr when using openvswitch?
> > I get the following error when starting Docker container in zun:
> >
> > Unable to create the network.No tenant network is availble for
> allocation.
> >
> > Please help me.
> >
> > Best regards
> > Mahdi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/86d89cdf/attachment-0001.html>

From huyp at inspur.com  Fri Sep  4 08:29:12 2020
From: huyp at inspur.com (=?gb2312?B?U2hlbGRvbiBIdSi6+tPxxfQp?=)
Date: Fri, 4 Sep 2020 08:29:12 +0000
Subject: [mq][mariadb] what kind of reasons are considered when choosing the
 mq/mariadb version
Message-ID: <e4a8d798d84f4fc4b4db5ddb6b1b9f7b@inspur.com>

Hi all

 

I use kolla to build the openstack version, use kolla-ansible to deploy

rabbitmq is v3.7.10, mariadb is v10.1.x when building rocky version

rabbitmq is v3.8.5, mariadb is v10.3.x when building ussuri version

 

what kind of reasons are considered as rabbitmq version is changed from
v3.7.10 to v3.8.5 ?

what kind of reasons are considered as mariadb version is changed from
v10.1.x to v10.3.x ?

 

many thanks.

 

 

 




 


 

 


Sheldon Hu    |  胡玉鹏

 


CBRD  |  云计算与大数据研发部

 


T: 18663761785

 


E:  <mailto:huyp at inspur.com> huyp at inspur.com

 


 




浪潮电子信息产业股份有限公司


Inspur Electronic Information Industry Co.,Ltd.


山东省济南市历城区东八区企业公馆A7-1


Building A7-1, Dongbaqu Office Block, Licheng District, Jinan,Shandong
Province, PRC

浪潮云海

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/74c3979c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7250 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/74c3979c/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 3667 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/74c3979c/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4081 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/74c3979c/attachment-0001.bin>

From pierre at stackhpc.com  Fri Sep  4 15:46:46 2020
From: pierre at stackhpc.com (Pierre Riteau)
Date: Fri, 4 Sep 2020 17:46:46 +0200
Subject: [cloudkitty] Virtual PTG planning
Message-ID: <CA+ny2syPgqQ-mH5ibEdznxca+YNOVRQfJCjY+oRO-Nx5hpPxDw@mail.gmail.com>

Hi,

You may know that the next PTG will be held virtually during the week
of October 26-30, 2020.
I will very likely *not* be available during that time, so I would like to
hear from the CloudKitty community:

- if you would like to meet and for how long (a half day may be enough
depending on the agenda)
- what day and time is preferred (see list in
https://ethercalc.openstack.org/7xp2pcbh1ncb)
- if anyone is willing to chair the discussions (I can help you prepare an
agenda before the event)

Thanks in advance,
Pierre Riteau (priteau)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/ede1c221/attachment.html>

From whayutin at redhat.com  Fri Sep  4 16:12:49 2020
From: whayutin at redhat.com (Wesley Hayutin)
Date: Fri, 4 Sep 2020 10:12:49 -0600
Subject: [tripleo] docker.io rate limiting
In-Reply-To: <9f9606a3-d8e8-bc66-3440-8cc5ae080d64@redhat.com>
References: <CAOHJT4LT68KhRBt3vxb+D-6VpNUPgc2=JBae0nwC8xNZj2EJzQ@mail.gmail.com>
 <9f9606a3-d8e8-bc66-3440-8cc5ae080d64@redhat.com>
Message-ID: <CAOHJT4JQf4Z2y=u2crH0_4=8c8M_7SN-kxyt8UHXoFkMoyXjFA@mail.gmail.com>

On Fri, Sep 4, 2020 at 7:23 AM Giulio Fidente <gfidente at redhat.com> wrote:

> On 9/2/20 1:54 PM, Wesley Hayutin wrote:
> > Greetings,
> >
> > Some of you have contacted me regarding the recent news regarding
> > docker.io <http://docker.io>'s new policy with regards to container pull
> > rate limiting [1].  I wanted to take the opportunity to further
> > socialize our plan that will completely remove docker.io
> > <http://docker.io> from our upstream workflows and avoid any rate
> > limiting issues.
>
> thanks; I guess this will be a problem for the ceph containers as well
>
> > We will continue to upload containers to docker.io <http://docker.io>
> > for some time so that individuals and the community can access the
> > containers.  We will also start exploring other registries like quay and
> > newly announced github container registry. These other public registries
> > will NOT be used in our upstream jobs and will only serve the
> > communities individual contributors.
>
> I don't think ceph found alternatives yet, but Guillaume or Dimitri
> might know more about it
> --
>

talk to Fulton.. I think we'll have ceph covered from a tripleo
perspective.  Not sure about anything else.


> Giulio Fidente
> GPG KEY: 08D733BA
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/3241fbe2/attachment.html>

From radoslaw.piliszek at gmail.com  Fri Sep  4 16:19:02 2020
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Fri, 4 Sep 2020 18:19:02 +0200
Subject: [Kolla Ansible] Error in "heat" stage during deployment -
 Followed Quick Start Guide (ubuntu 18.04.5, virtualbox)
In-Reply-To: <trinity-902b6c38-b646-4d58-8a2c-779df8554be0-1599230803694@3c-app-webde-bs61>
References: <trinity-902b6c38-b646-4d58-8a2c-779df8554be0-1599230803694@3c-app-webde-bs61>
Message-ID: <CAKZ_x7982aEuJ6xP2h7Ai_MuJ6VNKj0DXy6NBB3BX-ZWMRFqFQ@mail.gmail.com>

Hello Lukas,

It sounds like you did it well overally.

Did you check the load on that machine?
It could be that it turned out to be too weak to handle the desired
set of services.
It sounds like it started to swap crazy.
Try something like 4G for starters (it would probably work with 2 but
4 is safe for sure!).

Another reason could be that networking went wrong with that VIP address.
But it would likely have occurred earlier than the heat deployment step.

-yoctozepto

On Fri, Sep 4, 2020 at 5:01 PM Lukasluedke at web.de <Lukasluedke at web.de> wrote:
>
> Hi everyone,
>
> I am new to openstack and just followed
> the "Quick Start" guide for kolla-ansible
> [https://docs.openstack.org/kolla-ansible/ussuri/user/quickstart.html]
> on ussuri release, but now having some problems during deployment.
> I used virtualbox to create a new vm with ubuntu 18.04.5
> [https://releases.ubuntu.com/18.04/ubuntu-18.04.5-live-server-amd64.iso.torrent]
> and attached one interface (enp0s3, 10.0.2.15) with Nat-Network and
> the second interface as for the neutron interface (enp0s8, no ip)
> an internal network and named it "neutron".
> Then I followed the guide to create a new virtual python environment
> (logged in over ssh using "user" user).
> --
> sudo apt-get update
> sudo apt-get install python3-dev libffi-dev gcc libssl-dev
> sudo apt-get install python3-venv
>
> python3 -m venv $(pwd)
> source $(pwd)/bin/activate
> pip install -U pip
> pip install 'ansible<2.10'
> --
>
> Everything seems to work as mentioned with no problems so far.
> (Beside the missing "python-venv" package in the docs)
> --
> pip install kolla-ansible
> sudo mkdir -p /etc/kolla
> sudo chown $USER:$USER /etc/kolla
> cp -r $(pwd)/share/kolla-ansible/etc_examples/kolla/* /etc/kolla
> cp $(pwd)/share/kolla-ansible/ansible/inventory/* .
>
> mkdir /etc/ansible
> sudo nano /etc/ansible/ansible.cfg
> ### content from /etc/ansible/ansible.cfg
> [defaults]
> host_key_checking=False
> pipelining=True
> forks=100
> ###
> --
>
> I then modified the "multinode" file to only deploy on localhost
> (replaced all control01, etc. with localhost) as I first wanted
> to try openstack on one node.
> The ping worked, changed the globals.yml file according to the
> documentation, then bootstrap and the prechecks worked
> so far with no issue.
> --
> ansible -i multinode all -m ping
> kolla-genpwd
>
> sudo nano /etc/kolla/globals.yml
> ### additional content of /etc/kolla/globals.yml
> kolla_base_distro: "ubuntu"
> kolla_install_type: "source"
> network_interface: "enp0s3"
> neutron_external_interface: "enp0s8"
> kolla_internal_vip_address: "10.0.2.10"
> ###
>
> kolla-ansible -i ./multinode bootstrap-servers
> kolla-ansible -i ./multinode prechecks
> --
>
> But on the deploy stage I am stuck right now:
> --
> kolla-ansible -i ./multinode deploy
> --
>
> The mentioned error is telling me,
> that the keystone service is not available.
> I attached the error log file, because the error is longer.
> As a side node, now when I try to login using tty,
> the vm is nearly frozen and only prompts very, very slowly
> (about 10 minutes for prompt). ssh in putty is also frozen
> and the connection broke after about 30 minutes.
>
> Does anyone know what is wrong or has some hints/insight on how
> to correctly deploy openstack using kolla-ansible?
>
> Best Regards,
> Lukas Lüdke


From hberaud at redhat.com  Fri Sep  4 16:34:35 2020
From: hberaud at redhat.com (Herve Beraud)
Date: Fri, 4 Sep 2020 18:34:35 +0200
Subject: [oslo][ffe] request for oslo
In-Reply-To: <a1236fc1-12f6-3cae-e6a0-8a148e164c0d@gmx.com>
References: <CAFDq9gUjij-4yBsVEgNz8ZFno_+JbCs0e4ie5TnA9x8Fi5+v-Q@mail.gmail.com>
 <a1236fc1-12f6-3cae-e6a0-8a148e164c0d@gmx.com>
Message-ID: <CAFDq9gV_a1DUhgZEHppr87Tcgpd0kXPwLCqhErYVSKZchzBm6Q@mail.gmail.com>

Le ven. 4 sept. 2020 à 14:50, Sean McGinnis <sean.mcginnis at gmx.com> a
écrit :

> On 9/4/20 2:44 AM, Herve Beraud wrote:
> > Hey Oslofolk,
> >
> > I request an FFE for these oslo.messaging changes [1].
> >
> > The goal of these changes is to run rabbitmq heartbeat in python
> > thread by default.
> >
> > Also these changes deprecating this option to prepare future removal
> > and force to always run heartbeat in a python thread whatever the
> context.
> >
> > Land these changes during the victoria cycle can help us to prime the
> > option removal during the next cycle.
> >
> > Thanks for your time,
> >
> > [1] https://review.opendev.org/#/c/747395/
> >
> With the overall non-client library freeze yesterday, this isn't just an
> Oslo feature freeze request. It is also a release and requirements
> exception as well.
>

Right, good point.


> The code change itself is very minor. But this flips a default for a
> behavior that hasn't been given very wide usage and runtime. I would be
> very cautious about making a change like that right as we are locking
> down things and trying to stabilize for the final release. It's a nice
> change, but personally I would feel more comfortable giving it all of
> the wallaby development cycle running as the new default to make sure
> there are no unintended side effects.
>

Sure we can survive without these changes until the Wallaby cycle.


> I am interested in hearing Ben's opinion though.
>
> Sean
>
>
>

-- 
Hervé Beraud
Senior Software Engineer
Red Hat - Openstack Oslo
irc: hberaud
-----BEGIN PGP SIGNATURE-----

wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+
Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+
RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP
F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G
5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g
glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw
m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ
hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0
qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y
F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3
B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O
v6rDpkeNksZ9fFSyoY2o
=ECSj
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/aac470be/attachment.html>

From johfulto at redhat.com  Fri Sep  4 16:42:10 2020
From: johfulto at redhat.com (John Fulton)
Date: Fri, 4 Sep 2020 12:42:10 -0400
Subject: [tripleo] docker.io rate limiting
In-Reply-To: <CAOHJT4JQf4Z2y=u2crH0_4=8c8M_7SN-kxyt8UHXoFkMoyXjFA@mail.gmail.com>
References: <CAOHJT4LT68KhRBt3vxb+D-6VpNUPgc2=JBae0nwC8xNZj2EJzQ@mail.gmail.com>
 <9f9606a3-d8e8-bc66-3440-8cc5ae080d64@redhat.com>
 <CAOHJT4JQf4Z2y=u2crH0_4=8c8M_7SN-kxyt8UHXoFkMoyXjFA@mail.gmail.com>
Message-ID: <CAE66OMBZqoUK3+7+6y73-eJUqs1dN_8CVp7juZ2+Toz4TqDKRA@mail.gmail.com>

On Fri, Sep 4, 2020 at 12:13 PM Wesley Hayutin <whayutin at redhat.com> wrote:

>
> On Fri, Sep 4, 2020 at 7:23 AM Giulio Fidente <gfidente at redhat.com> wrote:
>
>> On 9/2/20 1:54 PM, Wesley Hayutin wrote:
>> > Greetings,
>> >
>> > Some of you have contacted me regarding the recent news regarding
>> > docker.io <http://docker.io>'s new policy with regards to container
>> pull
>> > rate limiting [1].  I wanted to take the opportunity to further
>> > socialize our plan that will completely remove docker.io
>> > <http://docker.io> from our upstream workflows and avoid any rate
>> > limiting issues.
>>
>> thanks; I guess this will be a problem for the ceph containers as well
>>
>> > We will continue to upload containers to docker.io <http://docker.io>
>> > for some time so that individuals and the community can access the
>> > containers.  We will also start exploring other registries like quay and
>> > newly announced github container registry. These other public registries
>> > will NOT be used in our upstream jobs and will only serve the
>> > communities individual contributors.
>>
>> I don't think ceph found alternatives yet, but Guillaume or Dimitri
>> might know more about it
>> --
>>
>
> talk to Fulton.. I think we'll have ceph covered from a tripleo
> perspective.  Not sure about anything else.
>

Yes, thank you Wes for your help on the plan to cover the TripleO CI
perspective. A thread similar to this one has been posted on ceph-dev [1]
the outcome so far is that some Ceph projects are using quay.ceph.com to
store temporary CI images to deal with the docker.io rate limits.

As per an IRC conversation I had with Dimitri, ceph-ansible is not using
quay.ceph.com but has made some changes to deal with current rate limits
[2]. I expect they'll need to make further changes for November but my
understanding is that they're still looking to push the authoritative copy
of the Ceph container image [3] we use to docker.io.

On the TripleO side we change that image rarely so provided it can be
cached for CI jobs we should be safe. When we do change the image to the
newer version we use a DNM patch [4] to pull it directly from docker. We
could continue to do this as only that patch would be vulnerable to the
rate limit. If we then see by way of the CI to the DNM patch that the new
image is good, we can pursue getting it cached as the new image for TripleO
CI Ceph jobs. One thing that's not clear to me is the mechanism to do this.

  John

[1]
https://lists.ceph.io/hyperkitty/list/dev at ceph.io/thread/BYZOGN3Y3CJLY35QLDL7SX6SOX74YZCE/#BYZOGN3Y3CJLY35QLDL7SX6SOX74YZCE
[2] https://github.com/ceph/ceph-container/blob/master/tests/tox.sh#L86-L110
[3] https://hub.docker.com/r/ceph/daemon
[4] https://review.opendev.org/#/c/690036/



>
>
>> Giulio Fidente
>> GPG KEY: 08D733BA
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/82c71c55/attachment-0001.html>

From mihalis68 at gmail.com  Fri Sep  4 17:48:14 2020
From: mihalis68 at gmail.com (Chris Morgan)
Date: Fri, 4 Sep 2020 13:48:14 -0400
Subject: [ops] picking up some activity
Message-ID: <CA+NmNoNiNBYN2hU7X4qQEZuX2HZmO=mqbaSSYNBwBgao6PtiXQ@mail.gmail.com>

Greetings!

The OpenStack Operators ("ops") meetups team will attempt to have an IRC
meeting at the normal time and place (#openstack-operators on freenode at
10am EST/DST) on *Sept 15th*( following a period of complete inactivity for
obvious reasons.

If you're an official member of the team or even just interested in what we
do, please feel free to join us. Whilst we can't yet contemplate resuming
in-person meetups during this global pandemic, we can resume attempting to
build the openstack operators community, share knowledge and perhaps even
do some more virtual get-togethers.

See you then

Chris
on behalf of the openstack ops meetups team

-- 
Chris Morgan <mihalis68 at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/e83fdb66/attachment.html>

From radoslaw.piliszek at gmail.com  Fri Sep  4 17:49:05 2020
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Fri, 4 Sep 2020 19:49:05 +0200
Subject: [oslo][ffe] request for oslo
In-Reply-To: <CAFDq9gV_a1DUhgZEHppr87Tcgpd0kXPwLCqhErYVSKZchzBm6Q@mail.gmail.com>
References: <CAFDq9gUjij-4yBsVEgNz8ZFno_+JbCs0e4ie5TnA9x8Fi5+v-Q@mail.gmail.com>
 <a1236fc1-12f6-3cae-e6a0-8a148e164c0d@gmx.com>
 <CAFDq9gV_a1DUhgZEHppr87Tcgpd0kXPwLCqhErYVSKZchzBm6Q@mail.gmail.com>
Message-ID: <CAKZ_x7_fe6K9Yw0LYRJR2zavtiLZs-2m9g9-GYfGbqOzi7zBdg@mail.gmail.com>

I agree with Sean in that it is quite dangerous this late in the cycle.
Let's do it early in the Wallaby cycle.

-yoctozepto

On Fri, Sep 4, 2020 at 6:44 PM Herve Beraud <hberaud at redhat.com> wrote:
>
>
>
> Le ven. 4 sept. 2020 à 14:50, Sean McGinnis <sean.mcginnis at gmx.com> a écrit :
>>
>> On 9/4/20 2:44 AM, Herve Beraud wrote:
>> > Hey Oslofolk,
>> >
>> > I request an FFE for these oslo.messaging changes [1].
>> >
>> > The goal of these changes is to run rabbitmq heartbeat in python
>> > thread by default.
>> >
>> > Also these changes deprecating this option to prepare future removal
>> > and force to always run heartbeat in a python thread whatever the context.
>> >
>> > Land these changes during the victoria cycle can help us to prime the
>> > option removal during the next cycle.
>> >
>> > Thanks for your time,
>> >
>> > [1] https://review.opendev.org/#/c/747395/
>> >
>> With the overall non-client library freeze yesterday, this isn't just an
>> Oslo feature freeze request. It is also a release and requirements
>> exception as well.
>
>
> Right, good point.
>
>>
>> The code change itself is very minor. But this flips a default for a
>> behavior that hasn't been given very wide usage and runtime. I would be
>> very cautious about making a change like that right as we are locking
>> down things and trying to stabilize for the final release. It's a nice
>> change, but personally I would feel more comfortable giving it all of
>> the wallaby development cycle running as the new default to make sure
>> there are no unintended side effects.
>
>
> Sure we can survive without these changes until the Wallaby cycle.
>
>>
>> I am interested in hearing Ben's opinion though.
>>
>> Sean
>>
>>
>
>
> --
> Hervé Beraud
> Senior Software Engineer
> Red Hat - Openstack Oslo
> irc: hberaud
> -----BEGIN PGP SIGNATURE-----
>
> wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+
> Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+
> RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP
> F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G
> 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g
> glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw
> m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ
> hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0
> qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y
> F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3
> B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O
> v6rDpkeNksZ9fFSyoY2o
> =ECSj
> -----END PGP SIGNATURE-----
>


From radoslaw.piliszek at gmail.com  Fri Sep  4 17:54:06 2020
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Fri, 4 Sep 2020 19:54:06 +0200
Subject: [tripleo] centos-binary -> openstack-
In-Reply-To: <CACu=hyt=QkogFfVgLKvzQoQA6_ey93Y6N4-EG=x=93Q9gCEdXQ@mail.gmail.com>
References: <CAOHJT4Jk-QQES2FU_GSO=M=6F60xyo0tE+zzwXe92PU8oGWKZg@mail.gmail.com>
 <CAFHSqWp0pcEgLUoQPupCb9Z7ykqsyWay=b-U+CJjiX8VygvpUw@mail.gmail.com>
 <CACu=hyt=QkogFfVgLKvzQoQA6_ey93Y6N4-EG=x=93Q9gCEdXQ@mail.gmail.com>
Message-ID: <CAKZ_x7_zKzpn6HG8HjEo4RWqgiWOcpps+kpCZ8brX6PWCVF2Vg@mail.gmail.com>

Hi Emilien and Wes,

I proposed to drop the job from Kolla's pipeline then.

[1] https://review.opendev.org/750004

-yoctozepto

On Fri, Sep 4, 2020 at 2:22 PM Emilien Macchi <emilien at redhat.com> wrote:
>
>
>
> On Fri, Sep 4, 2020 at 3:40 AM Mark Goddard <mark at stackhpc.com> wrote:
>>
>> On Thu, 3 Sep 2020 at 12:56, Wesley Hayutin <whayutin at redhat.com> wrote:
>> >
>> > Greetings,
>> >
>> > The container names in master have changed from centos-binary* to openstack*.
>> > https://opendev.org/openstack/tripleo-common/src/branch/master/container-images/tripleo_containers.yaml
>> >
>> > https://opendev.org/openstack/tripleo-common/commit/90f6de7a7fab15e9161c1f03acecaf98726298f1
>> >
>> > If your patches are failing to pull https://registry-1.docker.io/v2/tripleomaster/centos-binary* it's not going to be fixed in a recheck. Check that your patches are rebased and your dependent patches are rebased.
>>
>> Hi Wes,
>>
>> Can we infer from this that Tripleo is no longer using Kolla on master?
>
>
> Mark, true, we no longer rely on Kolla on master, and removed our overrides.
> We backported all the work to Ussuri and Train but for backward compatibility will keep Kolla support.
> --
> Emilien Macchi


From kennelson11 at gmail.com  Fri Sep  4 17:58:10 2020
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Fri, 4 Sep 2020 10:58:10 -0700
Subject: [TC][PTG] Virtual PTG Planning
Message-ID: <CAJ6yrQh-OK+GMtzpHBJ4Kj+2jhZ7VjOumxc_meEd02hhfBXazw@mail.gmail.com>

Hello!

So as you might have seen, the deadline to sign up for PTG time by the end
of next week. To coordinate our time to meet as the TC, please fill out the
poll[1] that Mohammed kindly put together for us. *We need responses by EOD
Thursday September 10th* so that we can book the time in the ethercalc and
fill out the survey to reserve our space before the deadline.

Also, I created this planning etherpad [2] to start collecting ideas for
discussion topics!

Can't wait to see you all there!

-Kendall & Mohammed

[1] https://doodle.com/poll/hkbg44da2udxging
[2] https://etherpad.opendev.org/p/tc-wallaby-ptg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/4a21414d/attachment.html>

From gouthampravi at gmail.com  Fri Sep  4 18:28:06 2020
From: gouthampravi at gmail.com (Goutham Pacha Ravi)
Date: Fri, 4 Sep 2020 10:28:06 -0800
Subject: Mentoring Boston University Students
In-Reply-To: <CAJ6yrQi_MCF8_oyfGR0_GsJtavDZoM-a1FoTZUPAqSnJ_XG51g@mail.gmail.com>
References: <CAJ6yrQj40j2tAatjEQSmwJPRh5-TExK4eM3-c1tTpW9XiuNNvQ@mail.gmail.com>
 <CAKSuTPbis1FSrvX+5Zty9P7j3YX56W3KmetNCkLpp56yBK1p=g@mail.gmail.com>
 <CAJ6yrQi_MCF8_oyfGR0_GsJtavDZoM-a1FoTZUPAqSnJ_XG51g@mail.gmail.com>
Message-ID: <CAKSuTPYFn0A_zYhjf3nMq0bpr=OyO8vJxo1TWzAYB2hryWryJw@mail.gmail.com>

On Wed, Sep 2, 2020 at 8:38 AM Kendall Nelson <kennelson11 at gmail.com> wrote:

> Hey Goutham!
>
> Here is the form:
> https://docs.google.com/forms/d/e/1FAIpQLSdehzBYqJeJ8x4RlPvQjTZpJ-LXs2A9vPrmRUPZNdawn1LgMg/viewform
>

Great, thank you Kendall! :)


>
> -Kendall (diablo_rojo)
>
> On Tue, Sep 1, 2020 at 6:56 PM Goutham Pacha Ravi <gouthampravi at gmail.com>
> wrote:
>
>> Hi Kendall,
>>
>> We'd like to help and have help in the manila team. We have a few
>> projects [1] where the on-ramp may be relatively easy - I can work with you
>> and define them. How do we apply?
>>
>> Thanks,
>> Goutham
>>
>>
>> [1] https://etherpad.opendev.org/p/manila-todos
>>
>>
>>
>>
>>
>> On Tue, Sep 1, 2020 at 9:08 AM Kendall Nelson <kennelson11 at gmail.com>
>> wrote:
>>
>>> Hello!
>>>
>>> As you may or may not know, the last two years various community members
>>> have mentored students from North Dakota State University for a semester to
>>> work on projects in OpenStack. Recently, I learned of a similar program at
>>> Boston University and they are still looking for mentors interested for the
>>> upcoming semester.
>>>
>>> Essentially you would have 5 to 7 students for 13 weeks to mentor and
>>> work on some feature or effort in your project.
>>>
>>> The time to apply is running out however as the deadline is Sept 3rd. If
>>> you are interested, please let me know ASAP! I am happy to help get the
>>> students up to speed with the community and getting their workspaces set
>>> up, but the actual work they would do is more up to you :)
>>>
>>> -Kendall (diablo_rojo)
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/b631fb2f/attachment-0001.html>

From admin at gibdev.ru  Fri Sep  4 18:43:57 2020
From: admin at gibdev.ru (admin)
Date: Fri, 4 Sep 2020 21:43:57 +0300
Subject: how-to enable s3api
Message-ID: <06322a0a-eba3-d2a1-432a-761d001bf05d@gibdev.ru>

hi

where is there a normal manual on how to enable s3api support in swift? 
trying to go through 
https://docs.openstack.org/swift/latest/middleware.html and as a result 
keystone gives an error in authorization (trying to connect via (s3curl)
Authorization failed. The request you have made requires authentication. 
from x.x.x.x Unauthorized: The request you have made requires 
authentication.






From tburke at nvidia.com  Fri Sep  4 21:09:07 2020
From: tburke at nvidia.com (Tim Burke)
Date: Fri, 4 Sep 2020 14:09:07 -0700
Subject: [ironic] [stable] Bifrost stable/stein is broken (by eventlet?):
 help needed
In-Reply-To: <CACNgkFxM0KvtMb6N9X9uOVXfD7ryotv3WomKc0QgHs9rwz4jNg@mail.gmail.com>
References: <CACNgkFxM0KvtMb6N9X9uOVXfD7ryotv3WomKc0QgHs9rwz4jNg@mail.gmail.com>
Message-ID: <65108979-a4d2-e9ea-266c-01d624269773@nvidia.com>

On 9/3/20 3:30 AM, Dmitry Tantsur wrote:
> *External email: Use caution opening links or attachments*
> 
> 
> Hi folks,
> 
> I'm trying to revive the Bifrost stable/stein CI, and after fixing a 
> bunch of issues in https://review.opendev.org/749014 I've hit a wall 
> with what seems an eventlet problem: ironic-inspector fails to start with:
> 
> Exception AttributeError: "'_SocketDuckForFd' object has no attribute 
> '_closed'" in <bound method _SocketDuckForFd.__del__ of 
> _SocketDuckForFd:16> ignored
> 
> I've managed to find similar issues, but they should have been resolved 
> in the eventlet version in stein (0.24.1). Any ideas?
> 
> If we cannot fix it, we'll have to EOL stein and earlier on bifrost.
> 
> Dmitry
> 
> -- 
> Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
> Commercial register: Amtsgericht Muenchen, HRB 153243,
> Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael 
> O'Neill

The "ignored" makes me think that it shouldn't actually be a problem -- 
are we assuming that's the error because of logs like 
https://c972f4bb262ae2d5c5d6-598e1d61c0aab85aa3b67b337ca2c556.ssl.cf2.rackcdn.com/749014/2/check/bifrost-integration-tinyipa-ubuntu-xenial/9d2905c/logs/ironic-inspector.log 
?

Digging down to 
https://c972f4bb262ae2d5c5d6-598e1d61c0aab85aa3b67b337ca2c556.ssl.cf2.rackcdn.com/749014/2/check/bifrost-integration-tinyipa-ubuntu-xenial/9d2905c/logs/all/syslog 
shows tracebacks like

   File ".../eventlet/hubs/__init__.py", line 39, in get_default_hub
     import eventlet.hubs.epolls
   File ".../eventlet/hubs/epolls.py", line 13, in <module>
     from eventlet.hubs.hub import BaseHub
   File ".../eventlet/hubs/hub.py", line 24, in <module>
     import monotonic
   File ".../monotonic.py", line 169, in <module>
     raise RuntimeError('no suitable implementation for this system: ' + 
repr(e))
RuntimeError: no suitable implementation for this system: 
AttributeError("'module' object has no attribute 'epolls'",)

Maybe it's worth looking at why monotonic can't find a suitable 
implementation?

Tim


From nate.johnston at redhat.com  Fri Sep  4 21:33:13 2020
From: nate.johnston at redhat.com (Nate Johnston)
Date: Fri, 4 Sep 2020 17:33:13 -0400
Subject: [TC] Looking for a volunteer to help with community goal selection
Message-ID: <20200904213313.5xotjz47vdamypzy@firewall>

TC members,

Since I have not been able to get in contact with Graham, I would like to see if
there is anyone who would like to work with me for the selection of community
goals for the W series.  The commitment would be to identify a few good
candidates that have well formulated goal proposals and champions, which usually
involves a meeting followed by some reaching out and logistical work.  I am
hoping to increase the pool of those familiar with the goal selection process,
so this is a great place to jump in if you have not done this before.

Also, if Graham does have time then we can make sure to include him as well.
Two is good but three is better!

Please let me know if you are interested.

Thanks!

Nate



From dsavinea at redhat.com  Fri Sep  4 17:26:00 2020
From: dsavinea at redhat.com (Dimitri Savineau)
Date: Fri, 4 Sep 2020 13:26:00 -0400
Subject: [tripleo] docker.io rate limiting
In-Reply-To: <CAE66OMBZqoUK3+7+6y73-eJUqs1dN_8CVp7juZ2+Toz4TqDKRA@mail.gmail.com>
References: <CAOHJT4LT68KhRBt3vxb+D-6VpNUPgc2=JBae0nwC8xNZj2EJzQ@mail.gmail.com>
 <9f9606a3-d8e8-bc66-3440-8cc5ae080d64@redhat.com>
 <CAOHJT4JQf4Z2y=u2crH0_4=8c8M_7SN-kxyt8UHXoFkMoyXjFA@mail.gmail.com>
 <CAE66OMBZqoUK3+7+6y73-eJUqs1dN_8CVp7juZ2+Toz4TqDKRA@mail.gmail.com>
Message-ID: <CAFz7x+Q5gG+NvhcRrXEGHPsaT-h0jFzvwSw7S=Ng1zDEjHde7A@mail.gmail.com>

Hi,

We're currently in the progress of using the quay.ceph.io registry [1] with
a copy of the ceph container images from docker.io and consumed by the
ceph-ansible CI [2].

Official ceph images will still be updated on docker.io.

Note that from a ceph-ansible point of view, switching to the quay.ceph.io
registry isn't enough to get rid of the docker.io registry when deploying
with the Ceph dashboard enabled.
The whole monitoring stack (alertmanager, prometheus, grafana and
node-exporter) coming with the Ceph dashboard is still using docker.io by
default [3][4][5][6].

As an alternative, you can use the official quay registry (quay.io) for
altermanager, prometheus and node-exporter images [7] from the prometheus
namespace like we're doing in [2].
Only the grafana container image will still be pulled from docker.io.

Regards,

Dimitri


[1] https://quay.ceph.io/repository/ceph-ci/daemon?tab=tags
[2] https://github.com/ceph/ceph-ansible/pull/5726
[3]
https://github.com/ceph/ceph-ansible/blob/master/roles/ceph-defaults/defaults/main.yml#L802
[4]
https://github.com/ceph/ceph-ansible/blob/master/roles/ceph-defaults/defaults/main.yml#L793
[5]
https://github.com/ceph/ceph-ansible/blob/master/roles/ceph-defaults/defaults/main.yml#L767
[6]
https://github.com/ceph/ceph-ansible/blob/master/roles/ceph-defaults/defaults/main.yml#L757
[7] https://quay.io/organization/prometheus

On Fri, Sep 4, 2020 at 12:42 PM John Fulton <johfulto at redhat.com> wrote:

> On Fri, Sep 4, 2020 at 12:13 PM Wesley Hayutin <whayutin at redhat.com>
> wrote:
>
>>
>> On Fri, Sep 4, 2020 at 7:23 AM Giulio Fidente <gfidente at redhat.com>
>> wrote:
>>
>>> On 9/2/20 1:54 PM, Wesley Hayutin wrote:
>>> > Greetings,
>>> >
>>> > Some of you have contacted me regarding the recent news regarding
>>> > docker.io <http://docker.io>'s new policy with regards to container
>>> pull
>>> > rate limiting [1].  I wanted to take the opportunity to further
>>> > socialize our plan that will completely remove docker.io
>>> > <http://docker.io> from our upstream workflows and avoid any rate
>>> > limiting issues.
>>>
>>> thanks; I guess this will be a problem for the ceph containers as well
>>>
>>> > We will continue to upload containers to docker.io <http://docker.io>
>>> > for some time so that individuals and the community can access the
>>> > containers.  We will also start exploring other registries like quay
>>> and
>>> > newly announced github container registry. These other public
>>> registries
>>> > will NOT be used in our upstream jobs and will only serve the
>>> > communities individual contributors.
>>>
>>> I don't think ceph found alternatives yet, but Guillaume or Dimitri
>>> might know more about it
>>> --
>>>
>>
>> talk to Fulton.. I think we'll have ceph covered from a tripleo
>> perspective.  Not sure about anything else.
>>
>
> Yes, thank you Wes for your help on the plan to cover the TripleO CI
> perspective. A thread similar to this one has been posted on ceph-dev [1]
> the outcome so far is that some Ceph projects are using quay.ceph.com to
> store temporary CI images to deal with the docker.io rate limits.
>
> As per an IRC conversation I had with Dimitri, ceph-ansible is not using
> quay.ceph.com but has made some changes to deal with current rate limits
> [2]. I expect they'll need to make further changes for November but my
> understanding is that they're still looking to push the authoritative copy
> of the Ceph container image [3] we use to docker.io.
>
> On the TripleO side we change that image rarely so provided it can be
> cached for CI jobs we should be safe. When we do change the image to the
> newer version we use a DNM patch [4] to pull it directly from docker. We
> could continue to do this as only that patch would be vulnerable to the
> rate limit. If we then see by way of the CI to the DNM patch that the new
> image is good, we can pursue getting it cached as the new image for TripleO
> CI Ceph jobs. One thing that's not clear to me is the mechanism to do this.
>
>   John
>
> [1]
> https://lists.ceph.io/hyperkitty/list/dev at ceph.io/thread/BYZOGN3Y3CJLY35QLDL7SX6SOX74YZCE/#BYZOGN3Y3CJLY35QLDL7SX6SOX74YZCE
> [2]
> https://github.com/ceph/ceph-container/blob/master/tests/tox.sh#L86-L110
> [3] https://hub.docker.com/r/ceph/daemon
> [4] https://review.opendev.org/#/c/690036/
>
>
>
>>
>>
>>> Giulio Fidente
>>> GPG KEY: 08D733BA
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/3b89d215/attachment-0001.html>

From foundjem at ieee.org  Fri Sep  4 19:49:39 2020
From: foundjem at ieee.org (Foundjem Armstrong)
Date: Fri, 4 Sep 2020 15:49:39 -0400
Subject: [scientific]
Message-ID: <FCEBD557-A67A-428C-ACDE-92C0D3F3D57B@ieee.org>

Hello Blair,
I am wondering of this email is still functional. 

Regards,
Armstrong




From fungi at yuggoth.org  Fri Sep  4 22:14:49 2020
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 4 Sep 2020 22:14:49 +0000
Subject: [scientific-sig] ping
In-Reply-To: <FCEBD557-A67A-428C-ACDE-92C0D3F3D57B@ieee.org>
References: <FCEBD557-A67A-428C-ACDE-92C0D3F3D57B@ieee.org>
Message-ID: <20200904221449.tytpnafbjph3triq@yuggoth.org>

On 2020-09-04 15:49:39 -0400 (-0400), Foundjem Armstrong wrote:
> I am wondering of this email is still functional.

Yes, the old openstack-sigs mailing list was folded into
openstack-discuss nearly two years ago, so the Scientific SIG's
discussions now happen on this merged mailing list using the
[scientific-sig] subject tag.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200904/d349d5bb/attachment.sig>

From tom.v.black at gmail.com  Sat Sep  5 02:57:42 2020
From: tom.v.black at gmail.com (Tom Black)
Date: Sat, 5 Sep 2020 10:57:42 +0800
Subject: [mq][mariadb] what kind of reasons are considered when choosing
 the mq/mariadb version
In-Reply-To: <e4a8d798d84f4fc4b4db5ddb6b1b9f7b@inspur.com>
References: <e4a8d798d84f4fc4b4db5ddb6b1b9f7b@inspur.com>
Message-ID: <CAMn7GY=ZUgf-SPsiDZqQGaJVM5v5TsUXnEEftrbKJ7z4aJNNnQ@mail.gmail.com>

RMQ 3.9 will release in short time future, thus 3.7 will not be supported
after that. You should upgrade to use 3.8 version. Please see RMQ official
release notes.

Regards

On Fri, Sep 4, 2020 at 11:47 PM Sheldon Hu(胡玉鹏) <huyp at inspur.com> wrote:

> Hi all
>
>
>
> I use kolla to build the openstack version, use kolla-ansible to deploy
>
> rabbitmq is v3.7.10, mariadb is v10.1.x when building rocky version
>
> rabbitmq is v3.8.5, mariadb is v10.3.x when building ussuri version
>
>
>
> what kind of reasons are considered as rabbitmq version is changed from
> v3.7.10 to v3.8.5 ?
>
> what kind of reasons are considered as mariadb version is changed from
> v10.1.x to v10.3.x ?
>
>
>
> many thanks.
>
>
>
>
>
>
>
> [image: cid:image005.png at 01D65C4D.EFF29CE0]
>
>
>
>
>
>
>
> Sheldon Hu    *|*  胡玉鹏
>
>
>
> CBRD * |*  云计算与大数据研发部
>
>
>
> *T:* 18663761785
>
>
>
> *E:* huyp at inspur.com
>
>
>
>
>
> [image: cid:image002.jpg at 01D66A3B.5CCD6E30]
>
> 浪潮电子信息产业股份有限公司
>
> Inspur Electronic Information Industry Co.,Ltd.
>
> 山东省济南市历城区东八区企业公馆A7-1
>
> Building A7-1, Dongbaqu Office Block, Licheng District, Jinan,Shandong
> Province, PRC
>
> 浪潮云海
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200905/66624a26/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7250 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200905/66624a26/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 3667 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200905/66624a26/attachment-0001.jpg>

From radoslaw.piliszek at gmail.com  Sat Sep  5 08:54:52 2020
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Sat, 5 Sep 2020 10:54:52 +0200
Subject: [mq][mariadb] What kind of reasons are considered when choosing
 the mq/mariadb version
In-Reply-To: <823f98c6dc954e90a27f3d46974c9dd5@inspur.com>
References: <dd0bd9114cb895be115ca2970c0394f6@sslemail.net>
 <CAKZ_x7-TbJYFiz9WoUuoc=Od_xCYSXJbY8gsD+sF93gwL5JaXg@mail.gmail.com>
 <823f98c6dc954e90a27f3d46974c9dd5@inspur.com>
Message-ID: <CAKZ_x7_qEMubhV1q0HHPQF0NAf3O3Tr4jQ44rMF0-6FC-73-9w@mail.gmail.com>

Hi Sheldon,

On Sat, Sep 5, 2020 at 3:52 AM Sheldon Hu(胡玉鹏) <huyp at inspur.com> wrote:
>
> Thx for reply
>
> As of mysql compatibility, could you give me a 'for instance' to detail like 'which part of ussuri code must need mysql v10.3.x, if we use mysql v10.1, the code will not run correctly '.

I just reviewed this and it was even earlier - in Train:
https://bugs.launchpad.net/kolla/+bug/1841907
afair, some other projects also introduced such incompatibilities due
to testing against MySQL.

-yoctozepto


From donny at fortnebula.com  Sat Sep  5 15:26:02 2020
From: donny at fortnebula.com (Donny Davis)
Date: Sat, 5 Sep 2020 11:26:02 -0400
Subject: how-to enable s3api
In-Reply-To: <06322a0a-eba3-d2a1-432a-761d001bf05d@gibdev.ru>
References: <06322a0a-eba3-d2a1-432a-761d001bf05d@gibdev.ru>
Message-ID: <CAMHmko-YtaEe0UUecjzua75+EStBTXg822g=wN0=At_x+EgFFw@mail.gmail.com>

Did you create ec2 credentials using keystone?

On Fri, Sep 4, 2020 at 2:47 PM admin <admin at gibdev.ru> wrote:

> hi
>
> where is there a normal manual on how to enable s3api support in swift?
> trying to go through
> https://docs.openstack.org/swift/latest/middleware.html and as a result
> keystone gives an error in authorization (trying to connect via (s3curl)
> Authorization failed. The request you have made requires authentication.
> from x.x.x.x Unauthorized: The request you have made requires
> authentication.
>
>
>
>
>
>

-- 
~/DonnyD
C: 805 814 6800
"No mission too difficult. No sacrifice too great. Duty First"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200905/b1f0ce01/attachment.html>

From dangerzonen at gmail.com  Sat Sep  5 16:21:32 2020
From: dangerzonen at gmail.com (dangerzone ar)
Date: Sun, 6 Sep 2020 00:21:32 +0800
Subject: New deployed packstack openstack, Failed create instance due to
 volume failed to created
Message-ID: <CADuLHcWf-Eo8q6S9j1R-0RoD+_9fEQgdzh3GcDR77s2P86SQuw@mail.gmail.com>

Hi, my clean install openstack queens are not able to create simple
instance. Got error

*Error: Failed to perform requested operation on instance "test1", the
instance has an error status: Please try again later [Error: Build of
instance 18c607fd-e919-4022-be7d-d178d7ab410e aborted: Volume
8a3b3e80-1593-46e5-8aa8-a5083bfbb46f did not finish being created even
after we waited 9 seconds or 4 attempts. And its status is error.].*

Filesystem               Size  Used Avail Use% Mounted on
devtmpfs                 3.9G     0  3.9G   0% /dev
tmpfs                    3.9G  4.0K  3.9G   1% /dev/shm
tmpfs                    3.9G   25M  3.8G   1% /run
tmpfs                    3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/mapper/centos-root   48G   34G   15G  71% /
/dev/sda1               1014M  182M  833M  18% /boot
/dev/mapper/centos-home   24G   33M   24G   1% /home
tmpfs                    783M     0  783M   0% /run/user/1000
/dev/loop1               1.9G  6.1M  1.7G   1% /srv/node/swiftloopback
tmpfs                    783M     0  783M   0% /run/user/0

pvs
  PV         VG             Fmt  Attr PSize   PFree
  /dev/loop0 cinder-volumes lvm2 a--  <20.60g 1012.00m
  /dev/sda2  centos         lvm2 a--  <79.00g    4.00m

vgs
  VG             #PV #LV #SN Attr   VSize   VFree
  centos           1   3   0 wz--n- <79.00g    4.00m
  cinder-volumes   1   1   0 wz--n- <20.60g 1012.00m

seems my cinder volume no free space. I install VM with 80G storage but
cinder volume no space.
I tried extend cinder volume as follows








*lvm vgextend "cinder-volumes" /dev/loop3  Physical volume "/dev/loop3"
successfully created.  Volume group "cinder-volumes" successfully
extendedpvscan  PV /dev/loop0   VG cinder-volumes   lvm2 [<20.60 GiB /
1012.00 MiB free]  PV /dev/loop3   VG cinder-volumes   lvm2 [<30.00 GiB /
<30.00 GiB free]  PV /dev/sda2    VG centos           lvm2 [<79.00 GiB /
4.00 MiB free]  Total: 3 [<129.59 GiB] / in use: 3 [<129.59 GiB] / in no
VG: 0 [0   ]*





*vgs  VG             #PV #LV #SN Attr   VSize   VFree  centos           1
3   0 wz--n- <79.00g  4.00m  cinder-volumes   2   1   0 wz--n-  50.59g
30.98g*

When try to create new instance I keep getting the same volume error...
Please help and advise what should I do...Please help...why 80G still not
enough for cinder volume.

Appreciate help. Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200906/c5d40ee4/attachment.html>

From huyp at inspur.com  Sat Sep  5 01:52:24 2020
From: huyp at inspur.com (=?utf-8?B?U2hlbGRvbiBIdSjog6HnjonpuY8p?=)
Date: Sat, 5 Sep 2020 01:52:24 +0000
Subject: =?utf-8?B?562U5aSNOiBbbXFdW21hcmlhZGJdIFdoYXQga2luZCBvZiByZWFzb25zIGFy?=
 =?utf-8?B?ZSBjb25zaWRlcmVkIHdoZW4gY2hvb3NpbmcgdGhlIG1xL21hcmlhZGIgdmVy?=
 =?utf-8?Q?sion?=
In-Reply-To: <CAKZ_x7-TbJYFiz9WoUuoc=Od_xCYSXJbY8gsD+sF93gwL5JaXg@mail.gmail.com>
References: <dd0bd9114cb895be115ca2970c0394f6@sslemail.net>
 <CAKZ_x7-TbJYFiz9WoUuoc=Od_xCYSXJbY8gsD+sF93gwL5JaXg@mail.gmail.com>
Message-ID: <823f98c6dc954e90a27f3d46974c9dd5@inspur.com>

Thx for reply

As of mysql compatibility, could you give me a 'for instance' to detail like 'which part of ussuri code must need mysql v10.3.x, if we use mysql v10.1, the code will not run correctly '.

Prometheus exporter was depended on rabbitmq 3.8, so if vendor distribution doesn’t contain Prometheus,  rabbitmq v3.7.10 would be ok or not ?

I suggest the community that it add a doc page about why openstack version chooses the common component like 'mq/db/memcache' version.

When openstack version is released , in addition to release note is published , community releases this doc page to statement the reason of the common component version choice.

thx



Sheldon Hu    |  胡玉鹏

CBRD  |  云计算与大数据研发部

T: 18663761785

E: huyp at inspur.com



浪潮电子信息产业股份有限公司

Inspur Electronic Information Industry Co.,Ltd.

山东省济南市历城区东八区企业公馆A7-1

Building A7-1, Dongbaqu Office Block, Licheng District, Jinan,Shandong Province, PRC
浪潮云海


-----邮件原件-----
发件人: Radosław Piliszek [mailto:radoslaw.piliszek at gmail.com] 
发送时间: 2020年9月4日 18:16
收件人: Brin Zhang(张百林) <zhangbailin at inspur.com>
抄送: openstack-discuss at lists.openstack.org; Sheldon Hu(胡玉鹏) <huyp at inspur.com>
主题: Re: [mq][mariadb] What kind of reasons are considered when choosing the mq/mariadb version

Hi Brin,

most of the time the distribution dictates the new version.
However, sometimes it is forced due to issues with new versions of OpenStack and old versions of these dependencies (for example MariaDB
10.1 would fail to work with newer releases due to lack of MySQL compatibility).
Newer versions usually mean new features that are useful for end users. In this case RabbitMQ 3.8 shines with its new Prometheus exporter.
We generally try to avoid needless updates but still stay current enough to receive proper support from upstreams and satisfy the users.

-yoctozepto

On Fri, Sep 4, 2020 at 10:54 AM Brin Zhang(张百林) <zhangbailin at inspur.com> wrote:
>
> Hi all
>
>
>
> We are using kolla to build the OpenStack, use kolla-ansible to deploy
>
> rabbitmq is v3.7.10, mariadb is v10.1.x when building Rocky release
>
> rabbitmq is v3.8.5, mariadb is v10.3.x when building Ussuri release
>
>
>
> what kind of reasons are considered as rabbitmq version is changed from v3.7.10 to v3.8.5 ?
>
> what kind of reasons are considered as mariadb version is changed from v10.1.x to v10.3.x ?
>
>
>
> If you can provide an explanation, or key explanation, we would be very grateful.
>
> Thanks.
>
>
>
> brinzhang
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4081 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200905/a5c0ca76/attachment.bin>

From Lukasluedke at web.de  Sat Sep  5 17:59:45 2020
From: Lukasluedke at web.de (Lukasluedke at web.de)
Date: Sat, 05 Sep 2020 19:59:45 +0200
Subject: AW: [Kolla Ansible] Error in "heat" stage during deployment -
 Followed Quick Start Guide (ubuntu 18.04.5, virtualbox)
References: <trinity-902b6c38-b646-4d58-8a2c-779df8554be0-1599230803694@3c-app-webde-bs61>
 <CAKZ_x7982aEuJ6xP2h7Ai_MuJ6VNKj0DXy6NBB3BX-ZWMRFqFQ@mail.gmail.com>
Message-ID: <-sk5j4f-1lniqv-fndwmj1idcasr57jwc-bcfh079f6zk7-pvzmj86mtr5t-wm0xmqpd9s9vdrkh6f-p2hkss-swownxttvthsfi209p-6tg9cx3lcps1-h64ohhwx6wo9-nssug-sfesmsqm5l17-ghm78e.1599250755418@email.android.com>

An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200905/22bd4506/attachment-0001.html>

From donny at fortnebula.com  Sat Sep  5 20:22:02 2020
From: donny at fortnebula.com (Donny Davis)
Date: Sat, 5 Sep 2020 16:22:02 -0400
Subject: New deployed packstack openstack, Failed create instance due to
 volume failed to created
In-Reply-To: <CADuLHcWf-Eo8q6S9j1R-0RoD+_9fEQgdzh3GcDR77s2P86SQuw@mail.gmail.com>
References: <CADuLHcWf-Eo8q6S9j1R-0RoD+_9fEQgdzh3GcDR77s2P86SQuw@mail.gmail.com>
Message-ID: <CAMHmko__EvULa0bLyMYrsPoonZD3QkKwMLp3peyWzc_LeuLgOw@mail.gmail.com>

What is the output of lvs? Also what size block device are you trying to
create?

Donny Davis
c: 805 814 6800

On Sat, Sep 5, 2020, 12:27 PM dangerzone ar <dangerzonen at gmail.com> wrote:

> Hi, my clean install openstack queens are not able to create simple
> instance. Got error
>
> *Error: Failed to perform requested operation on instance "test1", the
> instance has an error status: Please try again later [Error: Build of
> instance 18c607fd-e919-4022-be7d-d178d7ab410e aborted: Volume
> 8a3b3e80-1593-46e5-8aa8-a5083bfbb46f did not finish being created even
> after we waited 9 seconds or 4 attempts. And its status is error.].*
>
> Filesystem               Size  Used Avail Use% Mounted on
> devtmpfs                 3.9G     0  3.9G   0% /dev
> tmpfs                    3.9G  4.0K  3.9G   1% /dev/shm
> tmpfs                    3.9G   25M  3.8G   1% /run
> tmpfs                    3.9G     0  3.9G   0% /sys/fs/cgroup
> /dev/mapper/centos-root   48G   34G   15G  71% /
> /dev/sda1               1014M  182M  833M  18% /boot
> /dev/mapper/centos-home   24G   33M   24G   1% /home
> tmpfs                    783M     0  783M   0% /run/user/1000
> /dev/loop1               1.9G  6.1M  1.7G   1% /srv/node/swiftloopback
> tmpfs                    783M     0  783M   0% /run/user/0
>
> pvs
>   PV         VG             Fmt  Attr PSize   PFree
>   /dev/loop0 cinder-volumes lvm2 a--  <20.60g 1012.00m
>   /dev/sda2  centos         lvm2 a--  <79.00g    4.00m
>
> vgs
>   VG             #PV #LV #SN Attr   VSize   VFree
>   centos           1   3   0 wz--n- <79.00g    4.00m
>   cinder-volumes   1   1   0 wz--n- <20.60g 1012.00m
>
> seems my cinder volume no free space. I install VM with 80G storage but
> cinder volume no space.
> I tried extend cinder volume as follows
>
>
>
>
>
>
>
>
> *lvm vgextend "cinder-volumes" /dev/loop3  Physical volume "/dev/loop3"
> successfully created.  Volume group "cinder-volumes" successfully
> extendedpvscan  PV /dev/loop0   VG cinder-volumes   lvm2 [<20.60 GiB /
> 1012.00 MiB free]  PV /dev/loop3   VG cinder-volumes   lvm2 [<30.00 GiB /
> <30.00 GiB free]  PV /dev/sda2    VG centos           lvm2 [<79.00 GiB /
> 4.00 MiB free]  Total: 3 [<129.59 GiB] / in use: 3 [<129.59 GiB] / in no
> VG: 0 [0   ]*
>
>
>
>
>
> *vgs  VG             #PV #LV #SN Attr   VSize   VFree  centos           1
>   3   0 wz--n- <79.00g  4.00m  cinder-volumes   2   1   0 wz--n-  50.59g
> 30.98g*
>
> When try to create new instance I keep getting the same volume error...
> Please help and advise what should I do...Please help...why 80G still not
> enough for cinder volume.
>
> Appreciate help. Thank you
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200905/ad48cc5b/attachment.html>

From tonyliu0592 at hotmail.com  Sat Sep  5 23:41:29 2020
From: tonyliu0592 at hotmail.com (Tony Liu)
Date: Sat, 5 Sep 2020 23:41:29 +0000
Subject: [kolla-ansible] prometheus.yml is empty
Message-ID: <MWHPR08MB238200E8E6BA56E3F020ADF3BD2A0@MWHPR08MB2382.namprd08.prod.outlook.com>

Hi,

I deployed Prometheus with Kolla Ansible (10.1.0.dev36 from PIP).
Given the following log, the change has been made on nodes.
=============================
TASK [prometheus : Copying over prometheus config file] ************************
skipping: [os-control-2] => (item=/usr/local/share/kolla-ansible/ansible/roles/prometheus/templates/prometheus.yml.j2)
skipping: [os-control-1] => (item=/usr/local/share/kolla-ansible/ansible/roles/prometheus/templates/prometheus.yml.j2)
skipping: [os-control-3] => (item=/usr/local/share/kolla-ansible/ansible/roles/prometheus/templates/prometheus.yml.j2)
skipping: [compute-1] => (item=/usr/local/share/kolla-ansible/ansible/roles/prometheus/templates/prometheus.yml.j2)
changed: [monitor-2] => (item=/usr/local/share/kolla-ansible/ansible/roles/prometheus/templates/prometheus.yml.j2)
changed: [monitor-1] => (item=/usr/local/share/kolla-ansible/ansible/roles/prometheus/templates/prometheus.yml.j2)
changed: [monitor-3] => (item=/usr/local/share/kolla-ansible/ansible/roles/prometheus/templates/prometheus.yml.j2)
=============================
But the /etc/kolla/prometheus-server/prometheus.yml on monitor-*
nodes is empty.
=============================
{}
=============================
Anything I am missing here?

Thanks!
Tony



From dangerzonen at gmail.com  Sat Sep  5 23:50:03 2020
From: dangerzonen at gmail.com (dangerzone ar)
Date: Sun, 6 Sep 2020 07:50:03 +0800
Subject: New deployed packstack openstack, Failed create instance due to
 volume failed to created
In-Reply-To: <CAMHmko__EvULa0bLyMYrsPoonZD3QkKwMLp3peyWzc_LeuLgOw@mail.gmail.com>
References: <CADuLHcWf-Eo8q6S9j1R-0RoD+_9fEQgdzh3GcDR77s2P86SQuw@mail.gmail.com>
 <CAMHmko__EvULa0bLyMYrsPoonZD3QkKwMLp3peyWzc_LeuLgOw@mail.gmail.com>
Message-ID: <CADuLHcVrqVJT=VgUPo5cqSS5+aV=ghuy2mhFmc364qY5+-BZDg@mail.gmail.com>

Hi Donny and team,
This is the output of lvs and vgdisplay.
I have tried reinstall my OS with different storage size (60G and 80G) both
setup also got problem openstack to create new instance error with the
volume and similar output where
storage of cinder is too small.... even when I extend cinder volume and the
size has been extended, still got volume error when trying to spin new
vm... all this is new deployment.
May I know how to resolve this...I want to test openstack. Thank you

lvs
  LV                  VG             Attr       LSize   Pool Origin Data%
 Meta%  Move Log Cpy%Sync Convert
  home                centos         -wi-ao----  23.33g
  root                centos         -wi-ao---- <47.79g
  swap                centos         -wi-ao----  <7.88g
  cinder-volumes-pool cinder-volumes twi-aotz--  19.57g             0.00
10.55

vgdisplay
  --- Volume group ---
  VG Name               cinder-volumes
  System ID
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  17
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               0
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               50.59 GiB
  PE Size               4.00 MiB
  Total PE              12952
  Alloc PE / Size       5020 / <19.61 GiB
  Free  PE / Size       7932 / 30.98 GiB
  VG UUID               LUenAt-0zrU-42HE-dmc3-bb2e-g4bi-HFDOTA

  --- Volume group ---
  VG Name               centos
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  4
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                3
  Open LV               3
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <79.00 GiB
  PE Size               4.00 MiB
  Total PE              20223
  Alloc PE / Size       20222 / 78.99 GiB
  Free  PE / Size       1 / 4.00 MiB
  VG UUID               CKC4EU-9qXu-m77Z-x1O4-S0Rq-eLdZ-VczPOb

On Sun, Sep 6, 2020 at 4:22 AM Donny Davis <donny at fortnebula.com> wrote:

> What is the output of lvs? Also what size block device are you trying to
> create?
>
> Donny Davis
> c: 805 814 6800
>
> On Sat, Sep 5, 2020, 12:27 PM dangerzone ar <dangerzonen at gmail.com> wrote:
>
>> Hi, my clean install openstack queens are not able to create simple
>> instance. Got error
>>
>> *Error: Failed to perform requested operation on instance "test1", the
>> instance has an error status: Please try again later [Error: Build of
>> instance 18c607fd-e919-4022-be7d-d178d7ab410e aborted: Volume
>> 8a3b3e80-1593-46e5-8aa8-a5083bfbb46f did not finish being created even
>> after we waited 9 seconds or 4 attempts. And its status is error.].*
>>
>> Filesystem               Size  Used Avail Use% Mounted on
>> devtmpfs                 3.9G     0  3.9G   0% /dev
>> tmpfs                    3.9G  4.0K  3.9G   1% /dev/shm
>> tmpfs                    3.9G   25M  3.8G   1% /run
>> tmpfs                    3.9G     0  3.9G   0% /sys/fs/cgroup
>> /dev/mapper/centos-root   48G   34G   15G  71% /
>> /dev/sda1               1014M  182M  833M  18% /boot
>> /dev/mapper/centos-home   24G   33M   24G   1% /home
>> tmpfs                    783M     0  783M   0% /run/user/1000
>> /dev/loop1               1.9G  6.1M  1.7G   1% /srv/node/swiftloopback
>> tmpfs                    783M     0  783M   0% /run/user/0
>>
>> pvs
>>   PV         VG             Fmt  Attr PSize   PFree
>>   /dev/loop0 cinder-volumes lvm2 a--  <20.60g 1012.00m
>>   /dev/sda2  centos         lvm2 a--  <79.00g    4.00m
>>
>> vgs
>>   VG             #PV #LV #SN Attr   VSize   VFree
>>   centos           1   3   0 wz--n- <79.00g    4.00m
>>   cinder-volumes   1   1   0 wz--n- <20.60g 1012.00m
>>
>> seems my cinder volume no free space. I install VM with 80G storage but
>> cinder volume no space.
>> I tried extend cinder volume as follows
>>
>>
>>
>>
>>
>>
>>
>>
>> *lvm vgextend "cinder-volumes" /dev/loop3  Physical volume "/dev/loop3"
>> successfully created.  Volume group "cinder-volumes" successfully
>> extendedpvscan  PV /dev/loop0   VG cinder-volumes   lvm2 [<20.60 GiB /
>> 1012.00 MiB free]  PV /dev/loop3   VG cinder-volumes   lvm2 [<30.00 GiB /
>> <30.00 GiB free]  PV /dev/sda2    VG centos           lvm2 [<79.00 GiB /
>> 4.00 MiB free]  Total: 3 [<129.59 GiB] / in use: 3 [<129.59 GiB] / in no
>> VG: 0 [0   ]*
>>
>>
>>
>>
>>
>> *vgs  VG             #PV #LV #SN Attr   VSize   VFree  centos           1
>>   3   0 wz--n- <79.00g  4.00m  cinder-volumes   2   1   0 wz--n-  50.59g
>> 30.98g*
>>
>> When try to create new instance I keep getting the same volume error...
>> Please help and advise what should I do...Please help...why 80G still not
>> enough for cinder volume.
>>
>> Appreciate help. Thank you
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200906/2567c727/attachment-0001.html>

From tonyliu0592 at hotmail.com  Sun Sep  6 00:11:10 2020
From: tonyliu0592 at hotmail.com (Tony Liu)
Date: Sun, 6 Sep 2020 00:11:10 +0000
Subject: [kolla-ansible] Difference between deploy and reconfigure?
Message-ID: <MWHPR08MB2382E92D4D3B28787CF1BE80BD2B0@MWHPR08MB2382.namprd08.prod.outlook.com>

Hi,

What's the difference between deploy and reconfigure?
I checked some roles, reconfigure.yml just include_tasks deploy.yml.
And I didn't find reconfigure as a condition for any tasks or handlers.
I checked kolla-ansible script, the difference is ANSIBLE_SERIAL
is specified by reconfigure. I also see comment saying "Serial is not
recommended and disabled by default.".

Here are some cases. I'd like to know which should be used.

#1 Add compute.
After updating inventory with the new compute node,
"deploy --limit new-compute" and "reconfigure --limit new-compute",
do they have the same result? If not, what's the difference?

#2 Change configuration.
In case configuration is changed in global.yml or inventory,
which of "deploy" or "reconfigure" should be executed to update
the cluster? Same or any difference?

#3 Fix the cluster
I was told to rerun playbook to fix some problems, like a container
was deleted. "deploy --limit host" or "reconfigure --limit host"?
Same or any difference?


Thanks!
Tony



From donny at fortnebula.com  Sun Sep  6 07:15:23 2020
From: donny at fortnebula.com (Donny Davis)
Date: Sun, 6 Sep 2020 03:15:23 -0400
Subject: New deployed packstack openstack, Failed create instance due to
 volume failed to created
In-Reply-To: <CADuLHcVrqVJT=VgUPo5cqSS5+aV=ghuy2mhFmc364qY5+-BZDg@mail.gmail.com>
References: <CADuLHcWf-Eo8q6S9j1R-0RoD+_9fEQgdzh3GcDR77s2P86SQuw@mail.gmail.com>
 <CAMHmko__EvULa0bLyMYrsPoonZD3QkKwMLp3peyWzc_LeuLgOw@mail.gmail.com>
 <CADuLHcVrqVJT=VgUPo5cqSS5+aV=ghuy2mhFmc364qY5+-BZDg@mail.gmail.com>
Message-ID: <CAMHmko-HwTbA2iUgd5KcBju2T_-H+-H2g7b7uiL4eQDgmo1iyg@mail.gmail.com>

I would start by looking at the logs for cinder.

Donny Davis
c: 805 814 6800

On Sat, Sep 5, 2020, 7:50 PM dangerzone ar <dangerzonen at gmail.com> wrote:

> Hi Donny and team,
> This is the output of lvs and vgdisplay.
> I have tried reinstall my OS with different storage size (60G and 80G)
> both setup also got problem openstack to create new instance error with the
> volume and similar output where
> storage of cinder is too small.... even when I extend cinder volume and
> the size has been extended, still got volume error when trying to spin new
> vm... all this is new deployment.
> May I know how to resolve this...I want to test openstack. Thank you
>
> lvs
>   LV                  VG             Attr       LSize   Pool Origin Data%
>  Meta%  Move Log Cpy%Sync Convert
>   home                centos         -wi-ao----  23.33g
>   root                centos         -wi-ao---- <47.79g
>   swap                centos         -wi-ao----  <7.88g
>   cinder-volumes-pool cinder-volumes twi-aotz--  19.57g             0.00
> 10.55
>
> vgdisplay
>   --- Volume group ---
>   VG Name               cinder-volumes
>   System ID
>   Format                lvm2
>   Metadata Areas        2
>   Metadata Sequence No  17
>   VG Access             read/write
>   VG Status             resizable
>   MAX LV                0
>   Cur LV                1
>   Open LV               0
>   Max PV                0
>   Cur PV                2
>   Act PV                2
>   VG Size               50.59 GiB
>   PE Size               4.00 MiB
>   Total PE              12952
>   Alloc PE / Size       5020 / <19.61 GiB
>   Free  PE / Size       7932 / 30.98 GiB
>   VG UUID               LUenAt-0zrU-42HE-dmc3-bb2e-g4bi-HFDOTA
>
>   --- Volume group ---
>   VG Name               centos
>   System ID
>   Format                lvm2
>   Metadata Areas        1
>   Metadata Sequence No  4
>   VG Access             read/write
>   VG Status             resizable
>   MAX LV                0
>   Cur LV                3
>   Open LV               3
>   Max PV                0
>   Cur PV                1
>   Act PV                1
>   VG Size               <79.00 GiB
>   PE Size               4.00 MiB
>   Total PE              20223
>   Alloc PE / Size       20222 / 78.99 GiB
>   Free  PE / Size       1 / 4.00 MiB
>   VG UUID               CKC4EU-9qXu-m77Z-x1O4-S0Rq-eLdZ-VczPOb
>
> On Sun, Sep 6, 2020 at 4:22 AM Donny Davis <donny at fortnebula.com> wrote:
>
>> What is the output of lvs? Also what size block device are you trying to
>> create?
>>
>> Donny Davis
>> c: 805 814 6800
>>
>> On Sat, Sep 5, 2020, 12:27 PM dangerzone ar <dangerzonen at gmail.com>
>> wrote:
>>
>>> Hi, my clean install openstack queens are not able to create simple
>>> instance. Got error
>>>
>>> *Error: Failed to perform requested operation on instance "test1", the
>>> instance has an error status: Please try again later [Error: Build of
>>> instance 18c607fd-e919-4022-be7d-d178d7ab410e aborted: Volume
>>> 8a3b3e80-1593-46e5-8aa8-a5083bfbb46f did not finish being created even
>>> after we waited 9 seconds or 4 attempts. And its status is error.].*
>>>
>>> Filesystem               Size  Used Avail Use% Mounted on
>>> devtmpfs                 3.9G     0  3.9G   0% /dev
>>> tmpfs                    3.9G  4.0K  3.9G   1% /dev/shm
>>> tmpfs                    3.9G   25M  3.8G   1% /run
>>> tmpfs                    3.9G     0  3.9G   0% /sys/fs/cgroup
>>> /dev/mapper/centos-root   48G   34G   15G  71% /
>>> /dev/sda1               1014M  182M  833M  18% /boot
>>> /dev/mapper/centos-home   24G   33M   24G   1% /home
>>> tmpfs                    783M     0  783M   0% /run/user/1000
>>> /dev/loop1               1.9G  6.1M  1.7G   1% /srv/node/swiftloopback
>>> tmpfs                    783M     0  783M   0% /run/user/0
>>>
>>> pvs
>>>   PV         VG             Fmt  Attr PSize   PFree
>>>   /dev/loop0 cinder-volumes lvm2 a--  <20.60g 1012.00m
>>>   /dev/sda2  centos         lvm2 a--  <79.00g    4.00m
>>>
>>> vgs
>>>   VG             #PV #LV #SN Attr   VSize   VFree
>>>   centos           1   3   0 wz--n- <79.00g    4.00m
>>>   cinder-volumes   1   1   0 wz--n- <20.60g 1012.00m
>>>
>>> seems my cinder volume no free space. I install VM with 80G storage but
>>> cinder volume no space.
>>> I tried extend cinder volume as follows
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *lvm vgextend "cinder-volumes" /dev/loop3  Physical volume "/dev/loop3"
>>> successfully created.  Volume group "cinder-volumes" successfully
>>> extendedpvscan  PV /dev/loop0   VG cinder-volumes   lvm2 [<20.60 GiB /
>>> 1012.00 MiB free]  PV /dev/loop3   VG cinder-volumes   lvm2 [<30.00 GiB /
>>> <30.00 GiB free]  PV /dev/sda2    VG centos           lvm2 [<79.00 GiB /
>>> 4.00 MiB free]  Total: 3 [<129.59 GiB] / in use: 3 [<129.59 GiB] / in no
>>> VG: 0 [0   ]*
>>>
>>>
>>>
>>>
>>>
>>> *vgs  VG             #PV #LV #SN Attr   VSize   VFree  centos
>>> 1   3   0 wz--n- <79.00g  4.00m  cinder-volumes   2   1   0 wz--n-  50.59g
>>> 30.98g*
>>>
>>> When try to create new instance I keep getting the same volume error...
>>> Please help and advise what should I do...Please help...why 80G still not
>>> enough for cinder volume.
>>>
>>> Appreciate help. Thank you
>>>
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200906/01d2d6d4/attachment.html>

From zhangbailin at inspur.com  Sun Sep  6 07:47:15 2020
From: zhangbailin at inspur.com (=?utf-8?B?QnJpbiBaaGFuZyjlvKDnmb7mnpcp?=)
Date: Sun, 6 Sep 2020 07:47:15 +0000
Subject: =?utf-8?B?562U5aSNOiBbbXFdW21hcmlhZGJdIFdoYXQga2luZCBvZiByZWFzb25zIGFy?=
 =?utf-8?B?ZSBjb25zaWRlcmVkIHdoZW4gY2hvb3NpbmcgdGhlIG1xL21hcmlhZGIgdmVy?=
 =?utf-8?Q?sion?=
In-Reply-To: <CAKZ_x7_qEMubhV1q0HHPQF0NAf3O3Tr4jQ44rMF0-6FC-73-9w@mail.gmail.com>
References: <dd0bd9114cb895be115ca2970c0394f6@sslemail.net>
 <CAKZ_x7-TbJYFiz9WoUuoc=Od_xCYSXJbY8gsD+sF93gwL5JaXg@mail.gmail.com>
 <823f98c6dc954e90a27f3d46974c9dd5@inspur.com>
 <CAKZ_x7_qEMubhV1q0HHPQF0NAf3O3Tr4jQ44rMF0-6FC-73-9w@mail.gmail.com>
Message-ID: <5efadef480e849f095dfd8649680bf7b@inspur.com>

Hi Radoslaw.

I have a doubt, https://review.opendev.org/#/c/677221 "op.alter_column('subnets','network_id', nullable=False, existing_type=sa.String(36))" altered ' network_id' attribute, but why does this make it necessary to upgrade the version of mariadb? 

"op.alter_column('subnets','network_id', nullable=False, existing_type=sa.String(36))" run *-db sync" it will be upgrade our local project's db, I think it's ok to run even if I don't upgrade the mariadb from v10.1 to v 10.3, right?

brinzhang

> Hi Sheldon,

> On Sat, Sep 5, 2020 at 3:52 AM Sheldon Hu(胡玉鹏) <huyp at inspur.com> wrote:
>
> Thx for reply
>
> As of mysql compatibility, could you give me a 'for instance' to detail like 'which part of ussuri code must need mysql v10.3.x, if we use mysql v10.1, the code will not run correctly '.

> I just reviewed this and it was even earlier - in Train:
> https://bugs.launchpad.net/kolla/+bug/1841907
> afair, some other projects also introduced such incompatibilities due to testing against MySQL.

> -yoctozepto


From radoslaw.piliszek at gmail.com  Sun Sep  6 07:52:51 2020
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Sun, 6 Sep 2020 09:52:51 +0200
Subject: [mq][mariadb] What kind of reasons are considered when choosing
 the mq/mariadb version
In-Reply-To: <5efadef480e849f095dfd8649680bf7b@inspur.com>
References: <dd0bd9114cb895be115ca2970c0394f6@sslemail.net>
 <CAKZ_x7-TbJYFiz9WoUuoc=Od_xCYSXJbY8gsD+sF93gwL5JaXg@mail.gmail.com>
 <823f98c6dc954e90a27f3d46974c9dd5@inspur.com>
 <CAKZ_x7_qEMubhV1q0HHPQF0NAf3O3Tr4jQ44rMF0-6FC-73-9w@mail.gmail.com>
 <5efadef480e849f095dfd8649680bf7b@inspur.com>
Message-ID: <CAKZ_x7-Wr1Vj7VOqSGriSBXyU+i2MZS03HtRWgvE6bPujS=Lrg@mail.gmail.com>

Hi Brin,

the issue is that, per the bug report, MariaDB 10.1 cannot handle such
changes to foreign keys:
  Cannot change column 'network_id': used in a foreign key constraint
'subnets_ibfk_1'
It received support later.

Is there a particular reason you are trying to keep MariaDB 10.1?

-yoctozepto

On Sun, Sep 6, 2020 at 9:47 AM Brin Zhang(张百林) <zhangbailin at inspur.com> wrote:
>
> Hi Radoslaw.
>
> I have a doubt, https://review.opendev.org/#/c/677221 "op.alter_column('subnets','network_id', nullable=False, existing_type=sa.String(36))" altered ' network_id' attribute, but why does this make it necessary to upgrade the version of mariadb?
>
> "op.alter_column('subnets','network_id', nullable=False, existing_type=sa.String(36))" run *-db sync" it will be upgrade our local project's db, I think it's ok to run even if I don't upgrade the mariadb from v10.1 to v 10.3, right?
>
> brinzhang
>
> > Hi Sheldon,
>
> > On Sat, Sep 5, 2020 at 3:52 AM Sheldon Hu(胡玉鹏) <huyp at inspur.com> wrote:
> >
> > Thx for reply
> >
> > As of mysql compatibility, could you give me a 'for instance' to detail like 'which part of ussuri code must need mysql v10.3.x, if we use mysql v10.1, the code will not run correctly '.
>
> > I just reviewed this and it was even earlier - in Train:
> > https://bugs.launchpad.net/kolla/+bug/1841907
> > afair, some other projects also introduced such incompatibilities due to testing against MySQL.
>
> > -yoctozepto
>


From radoslaw.piliszek at gmail.com  Sun Sep  6 07:55:24 2020
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Sun, 6 Sep 2020 09:55:24 +0200
Subject: [kolla-ansible] Difference between deploy and reconfigure?
In-Reply-To: <MWHPR08MB2382E92D4D3B28787CF1BE80BD2B0@MWHPR08MB2382.namprd08.prod.outlook.com>
References: <MWHPR08MB2382E92D4D3B28787CF1BE80BD2B0@MWHPR08MB2382.namprd08.prod.outlook.com>
Message-ID: <CAKZ_x7-eXg3PW+DQQsKkSwnFah7BB=6sYKdFEY5sAPNBox-8-w@mail.gmail.com>

Hi Tony,

at the moment:
  deploy == reconfigure
Except for the special cases of Bifrost and Swift.
If it ever changes, you will read about it in the release notes.

-yoctozepto

On Sun, Sep 6, 2020 at 2:13 AM Tony Liu <tonyliu0592 at hotmail.com> wrote:
>
> Hi,
>
> What's the difference between deploy and reconfigure?
> I checked some roles, reconfigure.yml just include_tasks deploy.yml.
> And I didn't find reconfigure as a condition for any tasks or handlers.
> I checked kolla-ansible script, the difference is ANSIBLE_SERIAL
> is specified by reconfigure. I also see comment saying "Serial is not
> recommended and disabled by default.".
>
> Here are some cases. I'd like to know which should be used.
>
> #1 Add compute.
> After updating inventory with the new compute node,
> "deploy --limit new-compute" and "reconfigure --limit new-compute",
> do they have the same result? If not, what's the difference?
>
> #2 Change configuration.
> In case configuration is changed in global.yml or inventory,
> which of "deploy" or "reconfigure" should be executed to update
> the cluster? Same or any difference?
>
> #3 Fix the cluster
> I was told to rerun playbook to fix some problems, like a container
> was deleted. "deploy --limit host" or "reconfigure --limit host"?
> Same or any difference?
>
>
> Thanks!
> Tony
>
>


From zhangbailin at inspur.com  Sun Sep  6 08:05:23 2020
From: zhangbailin at inspur.com (=?utf-8?B?QnJpbiBaaGFuZyjlvKDnmb7mnpcp?=)
Date: Sun, 6 Sep 2020 08:05:23 +0000
Subject: =?utf-8?B?562U5aSNOiBbbXFdW21hcmlhZGJdIFdoYXQga2luZCBvZiByZWFzb25zIGFy?=
 =?utf-8?B?ZSBjb25zaWRlcmVkIHdoZW4gY2hvb3NpbmcgdGhlIG1xL21hcmlhZGIgdmVy?=
 =?utf-8?Q?sion?=
In-Reply-To: <CAKZ_x7-Wr1Vj7VOqSGriSBXyU+i2MZS03HtRWgvE6bPujS=Lrg@mail.gmail.com>
References: <dd0bd9114cb895be115ca2970c0394f6@sslemail.net>
 <CAKZ_x7-TbJYFiz9WoUuoc=Od_xCYSXJbY8gsD+sF93gwL5JaXg@mail.gmail.com>
 <823f98c6dc954e90a27f3d46974c9dd5@inspur.com>
 <CAKZ_x7_qEMubhV1q0HHPQF0NAf3O3Tr4jQ44rMF0-6FC-73-9w@mail.gmail.com>
 <5efadef480e849f095dfd8649680bf7b@inspur.com>
 <CAKZ_x7-Wr1Vj7VOqSGriSBXyU+i2MZS03HtRWgvE6bPujS=Lrg@mail.gmail.com>
Message-ID: <d7f72dce32c8478da75fb7d4158a13d2@inspur.com>

>Hi Brin,

> the issue is that, per the bug report, MariaDB 10.1 cannot handle such changes to foreign keys:
  Cannot change column 'network_id': used in a foreign key constraint 'subnets_ibfk_1'
> It received support later.

> Is there a particular reason you are trying to keep MariaDB 10.1?

No, we want to upgrade openstack release, but I don’t know upgrade MariaDB whether is necessary (used 10.1 now), your suggestion will be very helpful to our choice. Therefore, for features that are highly dependent, or bug fixes, further verification is required.

Thanks.

-yoctozepto

On Sun, Sep 6, 2020 at 9:47 AM Brin Zhang(张百林) <zhangbailin at inspur.com> wrote:
>
> Hi Radoslaw.
>
> I have a doubt, https://review.opendev.org/#/c/677221 "op.alter_column('subnets','network_id', nullable=False, existing_type=sa.String(36))" altered ' network_id' attribute, but why does this make it necessary to upgrade the version of mariadb?
>
> "op.alter_column('subnets','network_id', nullable=False, existing_type=sa.String(36))" run *-db sync" it will be upgrade our local project's db, I think it's ok to run even if I don't upgrade the mariadb from v10.1 to v 10.3, right?
>
> brinzhang
>
> > Hi Sheldon,
>
> > On Sat, Sep 5, 2020 at 3:52 AM Sheldon Hu(胡玉鹏) <huyp at inspur.com> wrote:
> >
> > Thx for reply
> >
> > As of mysql compatibility, could you give me a 'for instance' to detail like 'which part of ussuri code must need mysql v10.3.x, if we use mysql v10.1, the code will not run correctly '.
>
> > I just reviewed this and it was even earlier - in Train:
> > https://bugs.launchpad.net/kolla/+bug/1841907
> > afair, some other projects also introduced such incompatibilities due to testing against MySQL.
>
> > -yoctozepto
>

From rncchae at gmail.com  Sun Sep  6 11:30:32 2020
From: rncchae at gmail.com (Myeong Chul Chae)
Date: Sun, 6 Sep 2020 20:30:32 +0900
Subject: [sdk][python-openstackclient] Request the code review about the
 story: openstack CLI - Create an instance using --image-property filtering
 not working.
Message-ID: <CAHj9ddLFhy2x5R7YFqMAMfLFUjVgxwWPEiNcuMhYN=EED9S=sA@mail.gmail.com>

Hi.

I researched the story 'openstack CLI - Create an instance using
--image-property filtering not working' and modified the code to
solve it.

This is the issue that I opened. - Link
<https://review.opendev.org/#/c/746405/>

And the hyperlink of the story is here
<https://storyboard.openstack.org/#!/story/2007860>.

In addition, there is a review <https://review.opendev.org/#/c/740455/> posted
before my review of the same
story, so conflict resolution is necessary.

Please check the commit message and history of the two reviews
and continue the discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200906/d19bc392/attachment.html>

From tonyliu0592 at hotmail.com  Mon Sep  7 02:57:00 2020
From: tonyliu0592 at hotmail.com (Tony Liu)
Date: Mon, 7 Sep 2020 02:57:00 +0000
Subject: [kolla-ansible] prometheus.yml is empty
In-Reply-To: <MWHPR08MB238200E8E6BA56E3F020ADF3BD2A0@MWHPR08MB2382.namprd08.prod.outlook.com>
References: <MWHPR08MB238200E8E6BA56E3F020ADF3BD2A0@MWHPR08MB2382.namprd08.prod.outlook.com>
Message-ID: <MWHPR08MB238277FDCBAB54FC52C98C8CBD280@MWHPR08MB2382.namprd08.prod.outlook.com>

Please discard my report. The issue was fixed by this commit.
https://github.com/openstack/kolla-ansible/commit/6f1bd3e35b46b8c4feb179e697348a5a0efd1549#diff-aba4fa152ad54e1eaaf5cfd43a99b62d

Tony
> -----Original Message-----
> From: Tony Liu <tonyliu0592 at hotmail.com>
> Sent: Saturday, September 5, 2020 4:41 PM
> To: openstack-discuss <openstack-discuss at lists.openstack.org>
> Subject: [kolla-ansible] prometheus.yml is empty
> 
> Hi,
> 
> I deployed Prometheus with Kolla Ansible (10.1.0.dev36 from PIP).
> Given the following log, the change has been made on nodes.
> =============================
> TASK [prometheus : Copying over prometheus config file]
> ************************
> skipping: [os-control-2] => (item=/usr/local/share/kolla-
> ansible/ansible/roles/prometheus/templates/prometheus.yml.j2)
> skipping: [os-control-1] => (item=/usr/local/share/kolla-
> ansible/ansible/roles/prometheus/templates/prometheus.yml.j2)
> skipping: [os-control-3] => (item=/usr/local/share/kolla-
> ansible/ansible/roles/prometheus/templates/prometheus.yml.j2)
> skipping: [compute-1] => (item=/usr/local/share/kolla-
> ansible/ansible/roles/prometheus/templates/prometheus.yml.j2)
> changed: [monitor-2] => (item=/usr/local/share/kolla-
> ansible/ansible/roles/prometheus/templates/prometheus.yml.j2)
> changed: [monitor-1] => (item=/usr/local/share/kolla-
> ansible/ansible/roles/prometheus/templates/prometheus.yml.j2)
> changed: [monitor-3] => (item=/usr/local/share/kolla-
> ansible/ansible/roles/prometheus/templates/prometheus.yml.j2)
> =============================
> But the /etc/kolla/prometheus-server/prometheus.yml on monitor-* nodes
> is empty.
> =============================
> {}
> =============================
> Anything I am missing here?
> 
> Thanks!
> Tony
> 



From chkumar246 at gmail.com  Mon Sep  7 03:31:59 2020
From: chkumar246 at gmail.com (Chandan kumar)
Date: Mon, 7 Sep 2020 09:01:59 +0530
Subject: [tripleo] docker.io rate limiting
In-Reply-To: <CAFz7x+Q5gG+NvhcRrXEGHPsaT-h0jFzvwSw7S=Ng1zDEjHde7A@mail.gmail.com>
References: <CAOHJT4LT68KhRBt3vxb+D-6VpNUPgc2=JBae0nwC8xNZj2EJzQ@mail.gmail.com>
 <9f9606a3-d8e8-bc66-3440-8cc5ae080d64@redhat.com>
 <CAOHJT4JQf4Z2y=u2crH0_4=8c8M_7SN-kxyt8UHXoFkMoyXjFA@mail.gmail.com>
 <CAE66OMBZqoUK3+7+6y73-eJUqs1dN_8CVp7juZ2+Toz4TqDKRA@mail.gmail.com>
 <CAFz7x+Q5gG+NvhcRrXEGHPsaT-h0jFzvwSw7S=Ng1zDEjHde7A@mail.gmail.com>
Message-ID: <CAMzQOd=SaumHQ0niMihJ3G49CJbWyxQCdTKFnxbC=o0JuZS=_g@mail.gmail.com>

Hello,

On Sat, Sep 5, 2020 at 3:44 AM Dimitri Savineau <dsavinea at redhat.com> wrote:
>
> Hi,
>
> We're currently in the progress of using the quay.ceph.io registry [1] with a copy of the ceph container images from docker.io and consumed by the ceph-ansible CI [2].
>
> Official ceph images will still be updated on docker.io.
>
> Note that from a ceph-ansible point of view, switching to the quay.ceph.io registry isn't enough to get rid of the docker.io registry when deploying with the Ceph dashboard enabled.
> The whole monitoring stack (alertmanager, prometheus, grafana and node-exporter) coming with the Ceph dashboard is still using docker.io by default [3][4][5][6].
>
> As an alternative, you can use the official quay registry (quay.io) for altermanager, prometheus and node-exporter images [7] from the prometheus namespace like we're doing in [2].

> Only the grafana container image will still be pulled from docker.io.
>

The app-sre team mirrors the grafana image from docker.io on quay.
https://quay.io/repository/app-sre/grafana?tab=tags , we reuse the same in CI?

I have proposed a patch on tripleo-common to switch to quay.io ->
https://review.opendev.org/#/c/750119/

Thanks,

Chandan Kumar


From jpena at redhat.com  Mon Sep  7 07:23:43 2020
From: jpena at redhat.com (Javier Pena)
Date: Mon, 7 Sep 2020 03:23:43 -0400 (EDT)
Subject: New deployed packstack openstack, Failed create instance due to
 volume failed to created
In-Reply-To: <CADuLHcWf-Eo8q6S9j1R-0RoD+_9fEQgdzh3GcDR77s2P86SQuw@mail.gmail.com>
References: <CADuLHcWf-Eo8q6S9j1R-0RoD+_9fEQgdzh3GcDR77s2P86SQuw@mail.gmail.com>
Message-ID: <1685671078.48951829.1599463423232.JavaMail.zimbra@redhat.com>

Hi, 

If SELinux is enabled on your machine, could you check if there are any AVCs (grep avc /var/log/audit/audit.log) related to iscsiadm? I have seen that in some deployments, and found out the instructions in [1] to be helpful. 

Regards, 
Javier 

[1] - https://www.server-world.info/en/note?os=CentOS_8&p=openstack_ussuri2&f=8 

----- Original Message -----

> Hi, my clean install openstack queens are not able to create simple instance.
> Got error

> Error: Failed to perform requested operation on instance "test1", the
> instance has an error status: Please try again later [Error: Build of
> instance 18c607fd-e919-4022-be7d-d178d7ab410e aborted: Volume
> 8a3b3e80-1593-46e5-8aa8-a5083bfbb46f did not finish being created even after
> we waited 9 seconds or 4 attempts. And its status is error.].

> Filesystem Size Used Avail Use% Mounted on
> devtmpfs 3.9G 0 3.9G 0% /dev
> tmpfs 3.9G 4.0K 3.9G 1% /dev/shm
> tmpfs 3.9G 25M 3.8G 1% /run
> tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
> /dev/mapper/centos-root 48G 34G 15G 71% /
> /dev/sda1 1014M 182M 833M 18% /boot
> /dev/mapper/centos-home 24G 33M 24G 1% /home
> tmpfs 783M 0 783M 0% /run/user/1000
> /dev/loop1 1.9G 6.1M 1.7G 1% /srv/node/swiftloopback
> tmpfs 783M 0 783M 0% /run/user/0

> pvs
> PV VG Fmt Attr PSize PFree
> /dev/loop0 cinder-volumes lvm2 a-- <20.60g 1012.00m
> /dev/sda2 centos lvm2 a-- <79.00g 4.00m

> vgs
> VG #PV #LV #SN Attr VSize VFree
> centos 1 3 0 wz--n- <79.00g 4.00m
> cinder-volumes 1 1 0 wz--n- <20.60g 1012.00m

> seems my cinder volume no free space. I install VM with 80G storage but
> cinder volume no space.
> I tried extend cinder volume as follows

> lvm vgextend "cinder-volumes" /dev/loop3
> Physical volume "/dev/loop3" successfully created.
> Volume group "cinder-volumes" successfully extended
> pvscan
> PV /dev/loop0 VG cinder-volumes lvm2 [<20.60 GiB / 1012.00 MiB free]
> PV /dev/loop3 VG cinder-volumes lvm2 [<30.00 GiB / <30.00 GiB free]
> PV /dev/sda2 VG centos lvm2 [<79.00 GiB / 4.00 MiB free]
> Total: 3 [<129.59 GiB] / in use: 3 [<129.59 GiB] / in no VG: 0 [0 ]

> vgs
> VG #PV #LV #SN Attr VSize VFree
> centos 1 3 0 wz--n- <79.00g 4.00m
> cinder-volumes 2 1 0 wz--n- 50.59g 30.98g

> When try to create new instance I keep getting the same volume error...
> Please help and advise what should I do...Please help...why 80G still not
> enough for cinder volume.

> Appreciate help. Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200907/ed67e68f/attachment.html>

From changzhi at cn.ibm.com  Mon Sep  7 07:52:54 2020
From: changzhi at cn.ibm.com (Zhi CZ Chang)
Date: Mon, 7 Sep 2020 07:52:54 +0000
Subject: [neutron][policy] Admin user can do anything without the control of
 policy.json?
Message-ID: <OF76D4E342.88BA2577-ON002585DC.002AA055-002585DC.002B4B9E@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200907/59c4973b/attachment-0001.html>

From mark at stackhpc.com  Mon Sep  7 08:08:02 2020
From: mark at stackhpc.com (Mark Goddard)
Date: Mon, 7 Sep 2020 09:08:02 +0100
Subject: [mq][mariadb] What kind of reasons are considered when choosing
 the mq/mariadb version
In-Reply-To: <d7f72dce32c8478da75fb7d4158a13d2@inspur.com>
References: <dd0bd9114cb895be115ca2970c0394f6@sslemail.net>
 <CAKZ_x7-TbJYFiz9WoUuoc=Od_xCYSXJbY8gsD+sF93gwL5JaXg@mail.gmail.com>
 <823f98c6dc954e90a27f3d46974c9dd5@inspur.com>
 <CAKZ_x7_qEMubhV1q0HHPQF0NAf3O3Tr4jQ44rMF0-6FC-73-9w@mail.gmail.com>
 <5efadef480e849f095dfd8649680bf7b@inspur.com>
 <CAKZ_x7-Wr1Vj7VOqSGriSBXyU+i2MZS03HtRWgvE6bPujS=Lrg@mail.gmail.com>
 <d7f72dce32c8478da75fb7d4158a13d2@inspur.com>
Message-ID: <CAFHSqWrREp2vmWqMtp1uD1xZS55UVFRi+AzrzGS-esmstzC5jw@mail.gmail.com>

On Sun, 6 Sep 2020 at 09:06, Brin Zhang(张百林) <zhangbailin at inspur.com> wrote:
>
> >Hi Brin,
>
> > the issue is that, per the bug report, MariaDB 10.1 cannot handle such changes to foreign keys:
>   Cannot change column 'network_id': used in a foreign key constraint 'subnets_ibfk_1'
> > It received support later.
>
> > Is there a particular reason you are trying to keep MariaDB 10.1?
>
> No, we want to upgrade openstack release, but I don’t know upgrade MariaDB whether is necessary (used 10.1 now), your suggestion will be very helpful to our choice. Therefore, for features that are highly dependent, or bug fixes, further verification is required.

Hi Brin, as always it would be helpful to know exactly the problem you
are facing, and if there is a reason why you are considering to choose
a version of these key components that differs from the versions
tested upstream. Are you using an external DB & MQ outside of kolla
that you do not have control over?

>
> Thanks.
>
> -yoctozepto
>
> On Sun, Sep 6, 2020 at 9:47 AM Brin Zhang(张百林) <zhangbailin at inspur.com> wrote:
> >
> > Hi Radoslaw.
> >
> > I have a doubt, https://review.opendev.org/#/c/677221 "op.alter_column('subnets','network_id', nullable=False, existing_type=sa.String(36))" altered ' network_id' attribute, but why does this make it necessary to upgrade the version of mariadb?
> >
> > "op.alter_column('subnets','network_id', nullable=False, existing_type=sa.String(36))" run *-db sync" it will be upgrade our local project's db, I think it's ok to run even if I don't upgrade the mariadb from v10.1 to v 10.3, right?
> >
> > brinzhang
> >
> > > Hi Sheldon,
> >
> > > On Sat, Sep 5, 2020 at 3:52 AM Sheldon Hu(胡玉鹏) <huyp at inspur.com> wrote:
> > >
> > > Thx for reply
> > >
> > > As of mysql compatibility, could you give me a 'for instance' to detail like 'which part of ussuri code must need mysql v10.3.x, if we use mysql v10.1, the code will not run correctly '.
> >
> > > I just reviewed this and it was even earlier - in Train:
> > > https://bugs.launchpad.net/kolla/+bug/1841907
> > > afair, some other projects also introduced such incompatibilities due to testing against MySQL.
> >
> > > -yoctozepto
> >


From bcafarel at redhat.com  Mon Sep  7 08:24:19 2020
From: bcafarel at redhat.com (Bernard Cafarelli)
Date: Mon, 7 Sep 2020 10:24:19 +0200
Subject: [neutron] Bug deputy report (week starting on 2020-08-31)
Message-ID: <CABHdKwo5g88BXvfeRQeUsWQsNVRuD3gHoJm1C62Zs8_6T860eg@mail.gmail.com>

Hello neutrinos,

back to school week in some parts of the world, and new bug deputy rotation
for us! Here is the bug list for week 36
A relatively quiet week on the new numbers count, all urgent bugs were
handled

Critical
* openstack-tox-py36-with-ovsdbapp-master periodic job is failing everyday
since 28.08.2020 - https://bugs.launchpad.net/neutron/+bug/1893965/
  Patch merged in neutron https://review.opendev.org/#/c/749537/

High
* [OVN Octavia Provider] OVN provider fails during listener delete -
https://bugs.launchpad.net/neutron/+bug/1894136
  Assigned to Brian

Medium
* [ovn] Limit the number of metadata workers -
https://bugs.launchpad.net/neutron/+bug/1893656
  Aims to use a separate config option than metadata_workers one,
unassigned in neutron (working in tripleo and fixed in charm)
* neutron-ovn-db-sync-util: Unhandled error:
oslo_config.cfg.NoSuchOptError: no such option keystone_authtoken in group
[DEFAULT] - https://bugs.launchpad.net/neutron/+bug/1894048
  This was fixed previously in bug 1882020, but is observed again,
unassigned
* ovn: filtering hash ring nodes is not time zone aware -
https://bugs.launchpad.net/neutron/+bug/1894117
  Timezone fun, unassigned

Wishlist
* For neutron-l3-agent, after the execution of the linux command fails, it
is not displayed which command failed to execute -
https://bugs.launchpad.net/neutron/+bug/1893627
  Add failed command to error log
  Patch merged: https://review.opendev.org/#/c/749076/

Incomplete
* Upgrading from train(el7) to ussuri(el8): Packet sequence number wrong -
got 2 expected 1 - https://bugs.launchpad.net/neutron/+bug/1894077
  Migration error on port forwarding description

Undecided
* Get domain name for dhcp from neutron db -
https://bugs.launchpad.net/neutron/+bug/1893802
   This one needs confirmation from subject experts, but as described in
comment I think this was attempted and reverted before - and this marked as
invalid (or to fix in another way)

-- 
Bernard Cafarelli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200907/c010b4b6/attachment.html>

From skaplons at redhat.com  Mon Sep  7 09:41:09 2020
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Mon, 7 Sep 2020 11:41:09 +0200
Subject: [neutron][policy] Admin user can do anything without the control
 of policy.json?
In-Reply-To: <OF76D4E342.88BA2577-ON002585DC.002AA055-002585DC.002B4B9E@notes.na.collabserv.com>
References: <OF76D4E342.88BA2577-ON002585DC.002AA055-002585DC.002B4B9E@notes.na.collabserv.com>
Message-ID: <20200907094109.g6tjbb5e4yiqp4za@skaplons-mac>

Hi,

I'm adding Akihiro to the thread as maybe he will have some more knowledge about
why it is like that in Neutron.

On Mon, Sep 07, 2020 at 07:52:54AM +0000, Zhi CZ Chang wrote:
>    Hi, all
>     
>    I have a question about Neutron Policy.
>     
>    I create some neutron policies in the file /etc/neutron/policy.json, plus
>    in this policy file, I don't want to anyone to create address scope and
>    set " "create_address_scope": "!" ". 
>     
>    After that, I execute the command line " openstack address scope create
>    test " by the admin user and it works fine.
>     
>    This is not my expected. 
>     
>    After some investigation, I find that in this pr[1], it will return True
>    directly even if the admin user. 
>     
>    Could someone tell me why the admin user can do anything without the
>    control of policies? Or maybe I make some mistakes?
>     
>     
>    Thanks
>     
>    1. https://review.opendev.org/#/c/175238/11/neutron/policy.py

-- 
Slawek Kaplonski
Principal software engineer
Red Hat



From mark at stackhpc.com  Mon Sep  7 11:32:49 2020
From: mark at stackhpc.com (Mark Goddard)
Date: Mon, 7 Sep 2020 12:32:49 +0100
Subject: [kolla] virtual PTG
Message-ID: <CAFHSqWpHfeN0THWNGZS+R0PKLKxbObG1Tce9Zi+m=sSWiaA7tA@mail.gmail.com>

Hi,

The next PTG will be virtual again, and held from Monday October 26th
to Friday October 30th. For those who have not attended before, the
PTG is where we discuss various aspects of the project, and eventually
decide on priorities for the next development cycle.

I have provisionally booked the same slots as last time:

* Monday 26th 13:00 - 17:00 UTC (kolla & kolla ansible)
* Tuesday 27th 13:00 - 17:00 UTC (kolla & kolla ansible)
* Wednesday 28th 13:00 - 15:00 UTC (kayobe)

Please get in touch if you would like to attend but these slots are
not suitable for you. In particular, if you are in a time zone where
these times are unsociable, we could consider running some sessions
during a different 4 hour block.

Thanks,
Mark


From mark at stackhpc.com  Mon Sep  7 11:35:54 2020
From: mark at stackhpc.com (Mark Goddard)
Date: Mon, 7 Sep 2020 12:35:54 +0100
Subject: [kolla] Kolla klub break
In-Reply-To: <CAFHSqWoGTAircETLV-e6VeUAns134P3sWx7fCQOzHhWViWUgsA@mail.gmail.com>
References: <CAFHSqWoGTAircETLV-e6VeUAns134P3sWx7fCQOzHhWViWUgsA@mail.gmail.com>
Message-ID: <CAFHSqWp+Q9Cx=rOGgJ+KDe1n+KPPe4GdXL0on=DYDUQnW25B+w@mail.gmail.com>

Hi,

Apologies, I will be on holiday on Thursday 10th September. Let's get
started again on 24th September, hopefully everyone will be feeling
refreshed after a long break from the Klub.

Thanks,
Mark

On Fri, 7 Aug 2020 at 15:11, Mark Goddard <mark at stackhpc.com> wrote:
>
> Hi,
>
> We agreed in Wednesday's IRC meeting to take a short summer break from
> the klub. Let's meet again on 10th September.
>
> Thanks to everyone who has taken part in these meetings so far, we've
> had some really great discussions. As always, if anyone has ideas for
> topics, please add them to the Google doc.
>
> Looking forward to some more great sessions in September.
>
> https://docs.google.com/document/d/1EwQs2GXF-EvJZamEx9vQAOSDB5tCjsDCJyHQN5_4_Sw/edit#
>
> Thanks,
> Mark


From dangerzonen at gmail.com  Mon Sep  7 11:37:39 2020
From: dangerzonen at gmail.com (dangerzone ar)
Date: Mon, 7 Sep 2020 19:37:39 +0800
Subject: New deployed packstack openstack, Failed create instance due to
 volume failed to created
In-Reply-To: <1685671078.48951829.1599463423232.JavaMail.zimbra@redhat.com>
References: <CADuLHcWf-Eo8q6S9j1R-0RoD+_9fEQgdzh3GcDR77s2P86SQuw@mail.gmail.com>
 <1685671078.48951829.1599463423232.JavaMail.zimbra@redhat.com>
Message-ID: <CADuLHcXOV7rjpjKB-7oFc9H8nZiSTWx6-1FOPByotJCJz_Uk3Q@mail.gmail.com>

Hi sir...Selinux is set to permissiv mode. I tried deploy packstack and
devstack..both give me error volume when create new instanc..i can create
instance without volume but i cannot console to the vm...both fresh
instaltn over virtualbox (windows10).
Tried wth centos7 and storage 60G and 80G....

This really puzzl me...everythg is new setup...and success deploy openstack
till completed... i want to test openstack further...but this problm really
stuck me... i hope to be advised further... i will setup another vm and
instll via packstack.

Thank you

On Mon, 7 Sep 2020 15:23 Javier Pena, <jpena at redhat.com> wrote:

> Hi,
>
> If SELinux is enabled on your machine, could you check if there are any
> AVCs (grep avc /var/log/audit/audit.log) related to iscsiadm? I have seen
> that in some deployments, and found out the instructions in [1] to be
> helpful.
>
> Regards,
> Javier
>
> [1] -
> https://www.server-world.info/en/note?os=CentOS_8&p=openstack_ussuri2&f=8
>
> ------------------------------
>
> Hi, my clean install openstack queens are not able to create simple
> instance. Got error
>
> *Error: Failed to perform requested operation on instance "test1", the
> instance has an error status: Please try again later [Error: Build of
> instance 18c607fd-e919-4022-be7d-d178d7ab410e aborted: Volume
> 8a3b3e80-1593-46e5-8aa8-a5083bfbb46f did not finish being created even
> after we waited 9 seconds or 4 attempts. And its status is error.].*
>
> Filesystem               Size  Used Avail Use% Mounted on
> devtmpfs                 3.9G     0  3.9G   0% /dev
> tmpfs                    3.9G  4.0K  3.9G   1% /dev/shm
> tmpfs                    3.9G   25M  3.8G   1% /run
> tmpfs                    3.9G     0  3.9G   0% /sys/fs/cgroup
> /dev/mapper/centos-root   48G   34G   15G  71% /
> /dev/sda1               1014M  182M  833M  18% /boot
> /dev/mapper/centos-home   24G   33M   24G   1% /home
> tmpfs                    783M     0  783M   0% /run/user/1000
> /dev/loop1               1.9G  6.1M  1.7G   1% /srv/node/swiftloopback
> tmpfs                    783M     0  783M   0% /run/user/0
>
> pvs
>   PV         VG             Fmt  Attr PSize   PFree
>   /dev/loop0 cinder-volumes lvm2 a--  <20.60g 1012.00m
>   /dev/sda2  centos         lvm2 a--  <79.00g    4.00m
>
> vgs
>   VG             #PV #LV #SN Attr   VSize   VFree
>   centos           1   3   0 wz--n- <79.00g    4.00m
>   cinder-volumes   1   1   0 wz--n- <20.60g 1012.00m
>
> seems my cinder volume no free space. I install VM with 80G storage but
> cinder volume no space.
> I tried extend cinder volume as follows
>
>
>
>
>
>
>
>
> *lvm vgextend "cinder-volumes" /dev/loop3  Physical volume "/dev/loop3"
> successfully created.  Volume group "cinder-volumes" successfully
> extendedpvscan  PV /dev/loop0   VG cinder-volumes   lvm2 [<20.60 GiB /
> 1012.00 MiB free]  PV /dev/loop3   VG cinder-volumes   lvm2 [<30.00 GiB /
> <30.00 GiB free]  PV /dev/sda2    VG centos           lvm2 [<79.00 GiB /
> 4.00 MiB free]  Total: 3 [<129.59 GiB] / in use: 3 [<129.59 GiB] / in no
> VG: 0 [0   ]*
>
>
>
>
>
> *vgs  VG             #PV #LV #SN Attr   VSize   VFree  centos           1
>   3   0 wz--n- <79.00g  4.00m  cinder-volumes   2   1   0 wz--n-  50.59g
> 30.98g*
>
> When try to create new instance I keep getting the same volume error...
> Please help and advise what should I do...Please help...why 80G still not
> enough for cinder volume.
>
> Appreciate help. Thank you
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200907/57d0865d/attachment-0001.html>

From reza.b2008 at gmail.com  Mon Sep  7 13:53:44 2020
From: reza.b2008 at gmail.com (Reza Bakhshayeshi)
Date: Mon, 7 Sep 2020 18:23:44 +0430
Subject: Floating IP problem in HA OVN DVR with TripleO
Message-ID: <CAMGoRG0AGUbqwkeT1R+1r=1ScTKMySkJ4b6yZpjYDC-49FAr1Q@mail.gmail.com>

Hi all,

I deployed an environment with TripleO Ussuri with 3 HA Controllers and
some Compute nodes with neutron-ovn-dvr-ha.yaml
Instances have Internet access through routers with SNAT traffic (in this
case traffic is routed via a controller node), and by assigning IP address
directly from provider network (not having a router).

But in case of assigning FIP from provider to an instance, VM Internet
connection is lost.
Here is the output of router nat lists, which seems OK:


# ovn-nbctl lr-nat-list 587182a4-4d6b-41b0-9fd8-4c1be58811b0
TYPE             EXTERNAL_IP        EXTERNAL_PORT    LOGICAL_IP
 EXTERNAL_MAC         LOGICAL_PORT
dnat_and_snat    X.X.X.X                      192.168.0.153
fa:16:3e:0a:86:4d    e65bd8e9-5f95-4eb2-a316-97e86fbdb9b6
snat             Y.Y.Y.Y                      192.168.0.0/24


I replaced FIP with X.X.X.X and router IP with Y.Y.Y.Y

When I remove * EXTERNAL_MAC* and *LOGICAL_PORT*, FIP works fine and as it
has to be, but traffic routes from a Controller node and it won't be
distributed anymore.

Any idea or suggestion would be grateful.
Regards,
Reza
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200907/245fc2a4/attachment.html>

From gmann at ghanshyammann.com  Mon Sep  7 14:29:40 2020
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Mon, 07 Sep 2020 09:29:40 -0500
Subject: [all][tc][goals] Migrate CI/CD jobs to new Ubuntu LTS Focal: Week
 R-4 Update
Message-ID: <17468f8f785.1123a07e6307801.3844845549431858647@ghanshyammann.com>

Hello Everyone,

Please find the week R-4 updates on 'Ubuntu Focal migration' community goal. Its time to force the base jobs migration which can
break the projects gate if not yet taken care of. Read below for the plan.

Tracking: https://storyboard.openstack.org/#!/story/2007865

Progress:
=======
* We are close to V-3 release and this is time we have to complete this migration otherwise doing it in RC period can add
unnecessary and last min delay. I am going to plan this migration in two-part. This will surely break some projects gate
which is not yet finished the migration but we have to do at some time. Please let me know if any objection to the below
plan.

* Part1: Migrating tox base job tomorrow (8th Sept):

** I am going to open tox base jobs migration (doc, unit, functional, lower-constraints etc) to merge by tomorrow. which is this
series (all base patches of this):  https://review.opendev.org/#/c/738328/ . 

**There are few repos still failing on requirements lower-constraints job specifically which I tried my best to fix as many as possible.
 Many are ready to merge also. Please merge or work on your projects repo testing before that or fix on priority if failing.

* Part2: Migrating devstack/tempest  base job on 10th sept:

* We have few open bugs for this which are not yet resolved, we will see how it goes but the current plan is to migrate by 10th Sept.

** Bug#1882521
** DB migration issues,
*** alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003


Testing Till now:
============
* ~200 repos gate have been tested or fixed till now.
** https://review.opendev.org/#/q/topic:migrate-to-focal+(status:abandoned+OR+status:merged)

* ~100 repos are under test and failing. Debugging and fixing are in progress (If you would like to help, please check your
project repos if I am late to fix them):
** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open

* ~30repos fixes ready to merge:
** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open+label%3AVerified%3E%3D1%2Czuul+NOT+label%3AWorkflow%3C%3D-1


Bugs Report:
==========

1. Bug#1882521. (IN-PROGRESS)
There is open bug for nova/cinder where three tempest tests are failing for
volume detach operation. There is no clear root cause found yet
-https://bugs.launchpad.net/cinder/+bug/1882521
We have skipped the tests in tempest base patch to proceed with the other
projects testing but this is blocking things for the migration.

2. DB migration issues (IN-PROGRESS)
* alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003

3. We encountered the nodeset name conflict with x/tobiko. (FIXED)
nodeset conflict is resolved now and devstack provides all focal nodes now.

4. Bug#1886296. (IN-PROGRESS)
pyflakes till 2.1.0 is not compatible with python 3.8 which is the default python version
on ubuntu focal[1]. With pep8 job running on focal faces the issue and fail. We need to bump
the pyflakes to 2.1.1 as min version to run pep8 jobs on py3.8.
As of now, many projects are using old hacking version so I am explicitly adding pyflakes>=2.1.1
on the project side[2] but for the long term easy maintenance, I am doing it in 'hacking' requirements.txt[3]
nd will release a new hacking version. After that project can move to new hacking and do not need
to maintain pyflakes version compatibility.

5. Bug#1886298. (IN-PROGRESS)
'Markupsafe' 1.0 is not compatible with the latest version of setuptools[4],
We need to bump the lower-constraint for Markupsafe to 1.1.1 to make it work.
There are a few more issues[5] with lower-constraint jobs which I am debugging.


What work to be done on the project side:
================================
This goal is more of testing the jobs on focal and fixing bugs if any otherwise
migrate jobs by switching the nodeset to focal node sets defined in devstack.

1. Start a patch in your repo by making depends-on on either of below:
devstack base patch if you are using only devstack base jobs not tempest:

Depends-on: https://review.opendev.org/#/c/731207/
OR
tempest base patch if you are using the tempest base job (like devstack-tempest):
Depends-on: https://review.opendev.org/#/c/734700/

Both have depends-on on the series where I am moving unit/functional/doc/cover/nodejs tox jobs to focal. So
you can test the complete gate jobs(unit/functional/doc/integration) together.
This and its base patches - https://review.opendev.org/#/c/738328/

Example: https://review.opendev.org/#/c/738126/

2. If none of your project jobs override the nodeset then above patch will be
testing patch(do not merge) otherwise change the nodeset to focal.
Example: https://review.opendev.org/#/c/737370/

3. If the jobs are defined in branchless repo and override the nodeset then you need to override the branches
variant to adjust the nodeset so that those jobs run on Focal on victoria onwards only. If no nodeset
is overridden then devstack being branched and stable base job using bionic/xenial will take care of
this.
Example: https://review.opendev.org/#/c/744056/2

4. If no updates need you can abandon the testing patch (https://review.opendev.org/#/c/744341/). If it need
updates then modify the same patch with proper commit msg, once it pass the gate then remove the Depends-On
so that you can merge your patch before base jobs are switched to focal. This way we make sure no gate downtime in
this migration.
Example: https://review.opendev.org/#/c/744056/1..2//COMMIT_MSG

Once we finish the testing on projects side and no failure then we will merge the devstack and tempest
base patches.


Important things to note:
===================
* Do not forgot to add the story and task link to your patch so that we can track it smoothly.
* Use gerrit topic 'migrate-to-focal'
* Do not backport any of the patches.


References:
=========
Goal doc: https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-jobs-to-ubuntu-focal.html
Storyboard tracking: https://storyboard.openstack.org/#!/story/2007865

[1] https://github.com/PyCQA/pyflakes/issues/367
[2] https://review.opendev.org/#/c/739315/
[3] https://review.opendev.org/#/c/739334/
[4] https://github.com/pallets/markupsafe/issues/116
[5] https://zuul.opendev.org/t/openstack/build/7ecd9cf100194bc99b3b70fa1e6de032

-gmann


From dtantsur at redhat.com  Mon Sep  7 14:29:47 2020
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Mon, 7 Sep 2020 16:29:47 +0200
Subject: [ironic] [stable] Bifrost stable/stein is broken (by eventlet?):
 help needed
In-Reply-To: <CAFHSqWqDWGDjrYVD3_msn2EnYd71nWJjjMd9eMB3fzzHG3NCTA@mail.gmail.com>
References: <CACNgkFxM0KvtMb6N9X9uOVXfD7ryotv3WomKc0QgHs9rwz4jNg@mail.gmail.com>
 <CAFHSqWqDWGDjrYVD3_msn2EnYd71nWJjjMd9eMB3fzzHG3NCTA@mail.gmail.com>
Message-ID: <CACNgkFzti6g15zESjW-cX-ivPbyBOAFZKVnv8hA9Rrh9+KiSrw@mail.gmail.com>

On Fri, Sep 4, 2020 at 9:26 AM Mark Goddard <mark at stackhpc.com> wrote:

> On Thu, 3 Sep 2020 at 11:31, Dmitry Tantsur <dtantsur at redhat.com> wrote:
> >
> > Hi folks,
> >
> > I'm trying to revive the Bifrost stable/stein CI, and after fixing a
> bunch of issues in https://review.opendev.org/749014 I've hit a wall with
> what seems an eventlet problem: ironic-inspector fails to start with:
> >
> > Exception AttributeError: "'_SocketDuckForFd' object has no attribute
> '_closed'" in <bound method _SocketDuckForFd.__del__ of
> _SocketDuckForFd:16> ignored
> >
> > I've managed to find similar issues, but they should have been resolved
> in the eventlet version in stein (0.24.1). Any ideas?
> >
> > If we cannot fix it, we'll have to EOL stein and earlier on bifrost.
>
> Strange. Do you know why this affects only bifrost and not ironic
> inspector CI?
>

I'm totally lost, but at the very least the normal CI is devstack, so a lot
of things can be different.

Dmitry


>
> >
> > Dmitry
> >
> > --
> > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
> > Commercial register: Amtsgericht Muenchen, HRB 153243,
> > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
> O'Neill
>
>

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

From dtantsur at redhat.com  Mon Sep  7 14:30:35 2020
From: dtantsur at redhat.com (Dmitry Tantsur)
Date: Mon, 7 Sep 2020 16:30:35 +0200
Subject: [ironic] [stable] Bifrost stable/stein is broken (by eventlet?):
 help needed
In-Reply-To: <65108979-a4d2-e9ea-266c-01d624269773@nvidia.com>
References: <CACNgkFxM0KvtMb6N9X9uOVXfD7ryotv3WomKc0QgHs9rwz4jNg@mail.gmail.com>
 <65108979-a4d2-e9ea-266c-01d624269773@nvidia.com>
Message-ID: <CACNgkFxNLONatTvo5tf4ngw=2jz1=F=+o4gzPcOCbj0-U67kUQ@mail.gmail.com>

On Fri, Sep 4, 2020 at 11:12 PM Tim Burke <tburke at nvidia.com> wrote:

> On 9/3/20 3:30 AM, Dmitry Tantsur wrote:
> > *External email: Use caution opening links or attachments*
> >
> >
> > Hi folks,
> >
> > I'm trying to revive the Bifrost stable/stein CI, and after fixing a
> > bunch of issues in https://review.opendev.org/749014 I've hit a wall
> > with what seems an eventlet problem: ironic-inspector fails to start
> with:
> >
> > Exception AttributeError: "'_SocketDuckForFd' object has no attribute
> > '_closed'" in <bound method _SocketDuckForFd.__del__ of
> > _SocketDuckForFd:16> ignored
> >
> > I've managed to find similar issues, but they should have been resolved
> > in the eventlet version in stein (0.24.1). Any ideas?
> >
> > If we cannot fix it, we'll have to EOL stein and earlier on bifrost.
> >
> > Dmitry
> >
> > --
> > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
> > Commercial register: Amtsgericht Muenchen, HRB 153243,
> > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
> > O'Neill
>
> The "ignored" makes me think that it shouldn't actually be a problem --
> are we assuming that's the error because of logs like
>
> https://c972f4bb262ae2d5c5d6-598e1d61c0aab85aa3b67b337ca2c556.ssl.cf2.rackcdn.com/749014/2/check/bifrost-integration-tinyipa-ubuntu-xenial/9d2905c/logs/ironic-inspector.log
> ?
>
> Digging down to
>
> https://c972f4bb262ae2d5c5d6-598e1d61c0aab85aa3b67b337ca2c556.ssl.cf2.rackcdn.com/749014/2/check/bifrost-integration-tinyipa-ubuntu-xenial/9d2905c/logs/all/syslog
> shows tracebacks like
>
>    File ".../eventlet/hubs/__init__.py", line 39, in get_default_hub
>      import eventlet.hubs.epolls
>    File ".../eventlet/hubs/epolls.py", line 13, in <module>
>      from eventlet.hubs.hub import BaseHub
>    File ".../eventlet/hubs/hub.py", line 24, in <module>
>      import monotonic
>    File ".../monotonic.py", line 169, in <module>
>      raise RuntimeError('no suitable implementation for this system: ' +
> repr(e))
> RuntimeError: no suitable implementation for this system:
> AttributeError("'module' object has no attribute 'epolls'",)
>
> Maybe it's worth looking at why monotonic can't find a suitable
> implementation?
>

It used to be an issue in eventlet, but we seem to be using a new enough
version to avoid it (the initial problem was IIRC around the pike
timeframe).

Dmitry


>
> Tim
>
>

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

From balazs.gibizer at est.tech  Mon Sep  7 14:49:35 2020
From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer)
Date: Mon, 07 Sep 2020 16:49:35 +0200
Subject: [nova] virtual PTG and Forum planning
In-Reply-To: <MMHKFQ.Y4T3UHA0QRRJ@est.tech>
References: <MMHKFQ.Y4T3UHA0QRRJ@est.tech>
Message-ID: <NIMAGQ.Y4QUXFH9SFY2@est.tech>

Hi,

I've booked Wed - Fri, 13:00 UTC - 17:00 UTC slots for the Nova PTG. 
Cyborg indicated that they would like to have a cross project session 
so I added one at Wed 13:00 - 14:00. If we need cross project sessions 
with other teams please let me know and I will book them as well. I'd 
like to have them on Wednesday if possible.

Cheers,
gibi

On Mon, Aug 24, 2020 at 14:06, Balázs Gibizer 
<balazs.gibizer at est.tech> wrote:
> Hi,
> 
> As you probably know the next virtual PTG will be held between 
> October 26-30. I need to book time slots for Nova [1] so please add 
> your availability to the doodle [2] before 7th of September.
> 
> I have created an etherpad [3] to collect the PTG topics for the Nova 
> sessions. Feel free to add your topics.
> 
> Also there will be a Forum between October 19-23 [4]. You can use the 
> PTG etherpad [3] to brainstorm forum topics before the official CFP 
> opens.
> 
> Cheers,
> gibi
> 
> [1] https://ethercalc.openstack.org/7xp2pcbh1ncb
> [2] https://doodle.com/poll/a5pgqh7bypq8piew
> [3] https://etherpad.opendev.org/p/nova-wallaby-ptg
> [4] https://wiki.openstack.org/wiki/Forum/Virtual202
> 
> 
> 




From artem.goncharov at gmail.com  Mon Sep  7 15:10:08 2020
From: artem.goncharov at gmail.com (Artem Goncharov)
Date: Mon, 7 Sep 2020 17:10:08 +0200
Subject: [sdk/cli] virtual PTG planning
Message-ID: <A2032A85-E445-460C-AB9C-3D13C014F76F@gmail.com>

Hi all,

I’ve booked a slot for SDK/CLI PTG on 28th of Oct 14:00-17:00 UTC time. Please fill in the etherpad [1] if you want to come in.

Regards,
Artem (gtema)

[1] https://meetpad.opendev.org/etherpad/p/wallaby_sdk_cli <https://meetpad.opendev.org/etherpad/p/wallaby_sdk_cli>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200907/f09eef13/attachment.html>

From rafaelweingartner at gmail.com  Mon Sep  7 15:25:34 2020
From: rafaelweingartner at gmail.com (=?UTF-8?Q?Rafael_Weing=C3=A4rtner?=)
Date: Mon, 7 Sep 2020 12:25:34 -0300
Subject: [cloudkitty] Virtual PTG planning
In-Reply-To: <CA+ny2syPgqQ-mH5ibEdznxca+YNOVRQfJCjY+oRO-Nx5hpPxDw@mail.gmail.com>
References: <CA+ny2syPgqQ-mH5ibEdznxca+YNOVRQfJCjY+oRO-Nx5hpPxDw@mail.gmail.com>
Message-ID: <CAG97rac1gsfH_NT0vznVQy2s=FUFkrmFWJivDCUWktiauJY8+Q@mail.gmail.com>

I'm available.  I am not sure though if we need half a day. That seems
quite a lot, but I might be mistaken (as I have never participated in a PTG
planning meeting).
14 UTC works for me on any of the proposed days (Friday October 30 seems to
be free a series of slots in the Cactus room). I could also help being the
chair, if needed.


On Fri, Sep 4, 2020 at 12:47 PM Pierre Riteau <pierre at stackhpc.com> wrote:

> Hi,
>
> You may know that the next PTG will be held virtually during the week
> of October 26-30, 2020.
> I will very likely *not* be available during that time, so I would like to
> hear from the CloudKitty community:
>
> - if you would like to meet and for how long (a half day may be enough
> depending on the agenda)
> - what day and time is preferred (see list in
> https://ethercalc.openstack.org/7xp2pcbh1ncb)
> - if anyone is willing to chair the discussions (I can help you prepare an
> agenda before the event)
>
> Thanks in advance,
> Pierre Riteau (priteau)
>


-- 
Rafael Weingärtner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200907/593a0af5/attachment.html>

From Lukasluedke at web.de  Mon Sep  7 15:45:32 2020
From: Lukasluedke at web.de (Lukasluedke at web.de)
Date: Mon, 07 Sep 2020 17:45:32 +0200
Subject: [Kolla Ansible] Unable to connect to external network after Initial
 deployment
Message-ID: <i3c9w3-qrcyuzm8kldc-98guc2-4pqkrt-tabkkzgn367uomsudj-t33ob8uuda88pmjqe49shzyp7yvpmfzi3ngy6n4epvgb86oyq0o4jlrnmnsu-ty3h0z-vvfevy-2vwbo3-h3cd5x-8q19s3-ku0wv6.1599492229104@email.android.com>

An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200907/03609251/attachment.html>

From rdhasman at redhat.com  Mon Sep  7 16:04:34 2020
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Mon, 7 Sep 2020 21:34:34 +0530
Subject: [gance_store][FFE] Cinder multiple stores support
Message-ID: <CAARK8KS6imQqv=gG9AJmXJDQE0LXwi2+jHqoMFYXrRQRYyEHVQ@mail.gmail.com>

Hi Team,

Last week we released glance_store 2.3.0 which adds support for
configuring cinder multiple stores as glance backend.
While adding functional tests in glance for the same [1], we have
noticed that it is failing with some hard requirements from oslo side
to use project_id instead of tenant and user_id instead of user.
It is really strange behavior as this failure occurs only in
functional tests but works properly in the actual environment without
any issue. The fix is proposed in glance_store [2] to resolve this
issue.

I would like to apply for FFE with this glance_store patch [2] to be
approved and release a new version of glance_store 2.3.1.

Kindly provide approval for the same.

[1] https://review.opendev.org/#/c/750144/
[2] https://review.opendev.org/#/c/750131/

Thanks and Regards,
Rajat Dhasmana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200907/278b1d52/attachment-0001.html>

From akekane at redhat.com  Mon Sep  7 16:25:50 2020
From: akekane at redhat.com (Abhishek Kekane)
Date: Mon, 7 Sep 2020 21:55:50 +0530
Subject: [gance_store][FFE] Cinder multiple stores support
In-Reply-To: <CAARK8KS6imQqv=gG9AJmXJDQE0LXwi2+jHqoMFYXrRQRYyEHVQ@mail.gmail.com>
References: <CAARK8KS6imQqv=gG9AJmXJDQE0LXwi2+jHqoMFYXrRQRYyEHVQ@mail.gmail.com>
Message-ID: <CALOt+SS+jBVV6zqHdB=eT=xN145yjDLYzS2MGCVWHQhGGBML3g@mail.gmail.com>

+1 from me, glance_store 2.3.0 contains the actual functionality and glance
functionality patch [1] is also in good shape.

[1] https://review.opendev.org/#/c/748039/11

Thanks & Best Regards,

Abhishek Kekane


On Mon, Sep 7, 2020 at 9:40 PM Rajat Dhasmana <rdhasman at redhat.com> wrote:

> Hi Team,
>
> Last week we released glance_store 2.3.0 which adds support for configuring cinder multiple stores as glance backend.
> While adding functional tests in glance for the same [1], we have noticed that it is failing with some hard requirements from oslo side to use project_id instead of tenant and user_id instead of user.
> It is really strange behavior as this failure occurs only in functional tests but works properly in the actual environment without any issue. The fix is proposed in glance_store [2] to resolve this issue.
>
> I would like to apply for FFE with this glance_store patch [2] to be approved and release a new version of glance_store 2.3.1.
>
> Kindly provide approval for the same.
>
> [1] https://review.opendev.org/#/c/750144/
> [2] https://review.opendev.org/#/c/750131/
>
> Thanks and Regards,
> Rajat Dhasmana
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200907/63668abe/attachment.html>

From knikolla at bu.edu  Mon Sep  7 21:50:50 2020
From: knikolla at bu.edu (Kristi Nikolla)
Date: Mon, 7 Sep 2020 17:50:50 -0400
Subject: [keystone][ptg] Keystone vPTG Planning
Message-ID: <CAK5XOBFKGYKv0uOMG+fOfvsk5Y=ibZokWc15ZoyaaYJNs1WrMA@mail.gmail.com>

Hi all,

I have started a doodle poll for scheduling our sessions during the
vPTG. Please fill it out by September 10. [0]

The etherpad that we are using for brainstorming the topics is [1].
Please fill it out with anything you would like us to schedule time
for.

More information on the vPTG and links to register can be found at [2].

[0]. https://doodle.com/poll/czgyuwepxk348vqq
[1]. https://etherpad.opendev.org/p/keystone-wallaby-ptg
[2]. https://www.openstack.org/ptg/


From satish.txt at gmail.com  Tue Sep  8 03:17:35 2020
From: satish.txt at gmail.com (Satish Patel)
Date: Mon, 7 Sep 2020 23:17:35 -0400
Subject: who is running RabbitMQ HiPE mode?
Message-ID: <CAPgF-foQHwj_CsLiR0oWAjk+aEsLQ84ztpRycpUU-no+8HAz-g@mail.gmail.com>

Folks,

I was reading about HiPE mode and thinking to give it a shot but i
would like to know feedback from the community?

Is it safe to enable HiPE for rabbitMQ to boost performance?


From dev.faz at gmail.com  Tue Sep  8 04:24:23 2020
From: dev.faz at gmail.com (Fabian Zimmermann)
Date: Tue, 8 Sep 2020 06:24:23 +0200
Subject: who is running RabbitMQ HiPE mode?
In-Reply-To: <CAPgF-foQHwj_CsLiR0oWAjk+aEsLQ84ztpRycpUU-no+8HAz-g@mail.gmail.com>
References: <CAPgF-foQHwj_CsLiR0oWAjk+aEsLQ84ztpRycpUU-no+8HAz-g@mail.gmail.com>
Message-ID: <CAA857Vy1of8jTYj189hJGv2HgPzGKB4Yze0bS9xh0jSit1OoCA@mail.gmail.com>

Hi,

HiPE is deprecated, so you should think twice about using it.

Maybe the rabbitmq-mailinglist is also a good place to ask for more
information.

 Fabian

Satish Patel <satish.txt at gmail.com> schrieb am Di., 8. Sept. 2020, 05:23:

> Folks,
>
> I was reading about HiPE mode and thinking to give it a shot but i
> would like to know feedback from the community?
>
> Is it safe to enable HiPE for rabbitMQ to boost performance?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/4f85c5fe/attachment.html>

From sorrison at gmail.com  Tue Sep  8 05:13:17 2020
From: sorrison at gmail.com (Sam Morrison)
Date: Tue, 8 Sep 2020 15:13:17 +1000
Subject: [neutron][networking-midonet] Maintainers needed
In-Reply-To: <CAH=wFzRiJd=93cYsK5FJxJcmMb6eY-XDco1zQOfueMw-0s2Tcw@mail.gmail.com>
References: <0AC5AC07-E97E-43CC-B344-A3E992B8CCA4@netways.de>
 <610412AF-AADF-44BD-ABA2-BA289B7C8F8A@redhat.com>
 <5E2F5826-559E-42E9-84C5-FA708E5A122A@gmail.com>
 <CAH=wFzS6usQqLeUtZ3iwyzw5f+ph38eaHCEQ0xsKo2ZzMREBgA@mail.gmail.com>
 <43C4AF2B-C5C0-40EB-B621-AC6799471D01@gmail.com>
 <CAH=wFzRmjbCy5vQOrpu=rX4Be-_GYPOE602kDShvV-ZtX+eF6g@mail.gmail.com>
 <92959221-0353-4D48-8726-8FE71AFEA652@gmail.com>
 <4D778DBF-F505-462F-B85D-0B372085FA72@gmail.com>
 <CAH=wFzRiJd=93cYsK5FJxJcmMb6eY-XDco1zQOfueMw-0s2Tcw@mail.gmail.com>
Message-ID: <AB1C90C1-96EE-4D1B-AA3B-63A565A41B61@gmail.com>

Hi Yamamoto,


> On 4 Sep 2020, at 6:47 pm, Takashi Yamamoto <yamamoto at midokura.com> wrote:

> i'm talking to our infra folks but it might take longer than i hoped.
> if you or someone else can provide a public repo, it might be faster.
> (i have looked at launchpad PPA while ago. but it didn't seem
> straightforward given the complex build machinary in midonet.)

Yeah that’s no problem, I’ve set up a repo with the latest midonet debs in it and happy to use that for the time being.

> 
>> 
>> I’m not sure why the pep8 job is failing, it is complaining about pecan which makes me think this is an issue with neutron itself? Kinda stuck on this one, it’s probably something silly.
> 
> probably.

Yeah this looks like a neutron or neutron-lib issue

> 
>> 
>> For the py3 unit tests they are now failing due to db migration errors in tap-as-a-service, l2-gateway and vpnaas issues I think caused by neutron getting rid of the liberty alembic branch and so we need to squash these on these projects too.
> 
> this thing? https://review.opendev.org/#/c/749866/

Yeah that fixed that issue.


I have been working to get everything fixed in this review [1]

The pep8 job is working but not in the gate due to neutron issues [2]
The py36/py38 jobs have 2 tests failing both relating to tap-as-a-service which I don’t really have any idea about, never used it. [3]
The tempest aio job is working well now, I’m not sure what tempest tests were run before but it’s just doing what ever is the default at the moment.
The tempest multinode job isn’t working due to what I think is networking issues between the 2 nodes. I don’t really know what I’m doing here so any pointers would be helpful. [4]
The grenade job is also failing because I also need to put these fixes on the stable/ussuri branch to make it work so will need to figure that out too

Cheers,
Sam

[1] https://review.opendev.org/#/c/749857/
[2] https://zuul.opendev.org/t/openstack/build/e94e873cbf0443c0a7f25ffe76b3b00b
[3] https://b1a2669063d97482275a-410cecb8410320c66fb802e0a530979a.ssl.cf5.rackcdn.com/749857/18/check/openstack-tox-py36/0344651/testr_results.html
[4] https://zuul.opendev.org/t/openstack/build/61f6dd3dc3d74a81b7a3f5968b4d8c72


> 
>> 
>> 
>> 
>> I can now start to look into the devstack zuul jobs.
>> 
>> Cheers,
>> Sam
>> 
>> 
>> [1] https://github.com/NeCTAR-RC/networking-midonet/commits/devstack
>> [2] https://github.com/midonet/midonet/pull/9
>> 
>> 
>> 
>> 
>>> On 1 Sep 2020, at 4:03 pm, Sam Morrison <sorrison at gmail.com> wrote:
>>> 
>>> 
>>> 
>>>> On 1 Sep 2020, at 2:59 pm, Takashi Yamamoto <yamamoto at midokura.com> wrote:
>>>> 
>>>> hi,
>>>> 
>>>> On Tue, Sep 1, 2020 at 1:39 PM Sam Morrison <sorrison at gmail.com> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 1 Sep 2020, at 11:49 am, Takashi Yamamoto <yamamoto at midokura.com> wrote:
>>>>>> 
>>>>>> Sebastian, Sam,
>>>>>> 
>>>>>> thank you for speaking up.
>>>>>> 
>>>>>> as Slawek said, the first (and probably the biggest) thing is to fix the ci.
>>>>>> the major part for it is to make midonet itself to run on ubuntu
>>>>>> version used by the ci. (18.04, or maybe directly to 20.04)
>>>>>> https://midonet.atlassian.net/browse/MNA-1344
>>>>>> iirc, the remaining blockers are:
>>>>>> * libreswan (used by vpnaas)
>>>>>> * vpp (used by fip64)
>>>>>> maybe it's the easiest to drop those features along with their
>>>>>> required components, if it's acceptable for your use cases.
>>>>> 
>>>>> We are running midonet-cluster and midolman on 18.04, we dropped those package dependencies from our ubuntu package to get it working.
>>>>> 
>>>>> We currently have built our own and host in our internal repo but happy to help putting this upstream somehow. Can we upload them to the midonet apt repo, does it still exist?
>>>> 
>>>> it still exists. but i don't think it's maintained well.
>>>> let me find and ask someone in midokura who "owns" that part of infra.
>>>> 
>>>> does it also involve some package-related modifications to midonet repo, right?
>>> 
>>> 
>>> Yes a couple, I will send up as as pull requests to https://github.com/midonet/midonet today or tomorrow
>>> 
>>> Sam
>>> 
>>> 
>>> 
>>>> 
>>>>> 
>>>>> I’m keen to do the work but might need a bit of guidance to get started,
>>>>> 
>>>>> Sam
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> alternatively you might want to make midonet run in a container. (so
>>>>>> that you can run it with older ubuntu, or even a container trimmed for
>>>>>> JVM)
>>>>>> there were a few attempts to containerize midonet.
>>>>>> i think this is the latest one: https://github.com/midonet/midonet-docker
>>>>>> 
>>>>>> On Fri, Aug 28, 2020 at 7:10 AM Sam Morrison <sorrison at gmail.com> wrote:
>>>>>>> 
>>>>>>> We (Nectar Research Cloud) use midonet heavily too, it works really well and we haven’t found another driver that works for us. We tried OVN but it just doesn’t scale to the size of environment we have.
>>>>>>> 
>>>>>>> I’m happy to help too.
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> Sam
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On 31 Jul 2020, at 2:06 am, Slawek Kaplonski <skaplons at redhat.com> wrote:
>>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Thx Sebastian for stepping in to maintain the project. That is great news.
>>>>>>>> I think that at the beginning You should do 2 things:
>>>>>>>> - sync with Takashi Yamamoto (I added him to the loop) as he is probably most active current maintainer of this project,
>>>>>>>> - focus on fixing networking-midonet ci which is currently broken - all scenario jobs aren’t working fine on Ubuntu 18.04 (and we are going to move to 20.04 in this cycle), migrate jobs to zuulv3 from the legacy ones and finally add them to the ci again,
>>>>>>>> 
>>>>>>>> I can of course help You with ci jobs if You need any help. Feel free to ping me on IRC or email (can be off the list).
>>>>>>>> 
>>>>>>>>> On 29 Jul 2020, at 15:24, Sebastian Saemann <Sebastian.Saemann at netways.de> wrote:
>>>>>>>>> 
>>>>>>>>> Hi Slawek,
>>>>>>>>> 
>>>>>>>>> we at NETWAYS are running most of our neutron networking on top of midonet and wouldn't be too happy if it gets deprecated and removed. So we would like to take over the maintainer role for this part.
>>>>>>>>> 
>>>>>>>>> Please let me know how to proceed and how we can be onboarded easily.
>>>>>>>>> 
>>>>>>>>> Best regards,
>>>>>>>>> 
>>>>>>>>> Sebastian
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Sebastian Saemann
>>>>>>>>> Head of Managed Services
>>>>>>>>> 
>>>>>>>>> NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
>>>>>>>>> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
>>>>>>>>> CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB25207
>>>>>>>>> https://netways.de | sebastian.saemann at netways.de
>>>>>>>>> 
>>>>>>>>> ** NETWAYS Web Services - https://nws.netways.de **
>>>>>>>> 
>>>>>>>> —
>>>>>>>> Slawek Kaplonski
>>>>>>>> Principal software engineer
>>>>>>>> Red Hat
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/1ef97a99/attachment-0001.html>

From bshewale at redhat.com  Tue Sep  8 05:18:12 2020
From: bshewale at redhat.com (Bhagyashri Shewale)
Date: Tue, 8 Sep 2020 10:48:12 +0530
Subject: [tripleo] Proposing Takashi Kajinami to be core on puppet-tripleo
In-Reply-To: <CACu=hytgMt=4whc8vVRMLw-gkrfZ-rYiX26sNH78jnvgwu_zjQ@mail.gmail.com>
References: <CACu=hytgMt=4whc8vVRMLw-gkrfZ-rYiX26sNH78jnvgwu_zjQ@mail.gmail.com>
Message-ID: <CAOCqp5fJPWf5OyEqa=tBcrbDFhrVxFaQz6B2sQkj_Ma2a4VRuw@mail.gmail.com>

Congratulations Kajinami San :)

Regards,
Bhagyashri Shewale

On Tue, Aug 18, 2020 at 8:02 PM Emilien Macchi <emilien at redhat.com> wrote:

> Hi people,
>
> If you don't know Takashi yet, he has been involved in the Puppet
> OpenStack project and helped *a lot* in its maintenance (and by maintenance
> I mean not-funny-work). When our community was getting smaller and smaller,
> he joined us and our review velicity went back to eleven. He became a core
> maintainer very quickly and we're glad to have him onboard.
>
> He's also been involved in taking care of puppet-tripleo for a few months
> and I believe he has more than enough knowledge on the module to provide
> core reviews and be part of the core maintainer group. I also noticed his
> amount of contribution (bug fixes, improvements, reviews, etc) in other
> TripleO repos and I'm confident he'll make his road to be core in TripleO
> at some point. For now I would like him to propose him to be core in
> puppet-tripleo.
>
> As usual, any feedback is welcome but in the meantime I want to thank
> Takashi for his work in TripleO and we're super happy to have new
> contributors!
>
> Thanks,
> --
> Emilien Macchi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/f81683dd/attachment.html>

From chkumar246 at gmail.com  Tue Sep  8 07:30:20 2020
From: chkumar246 at gmail.com (Chandan kumar)
Date: Tue, 8 Sep 2020 13:00:20 +0530
Subject: [tripleo] docker.io rate limiting
In-Reply-To: <CAMzQOd=SaumHQ0niMihJ3G49CJbWyxQCdTKFnxbC=o0JuZS=_g@mail.gmail.com>
References: <CAOHJT4LT68KhRBt3vxb+D-6VpNUPgc2=JBae0nwC8xNZj2EJzQ@mail.gmail.com>
 <9f9606a3-d8e8-bc66-3440-8cc5ae080d64@redhat.com>
 <CAOHJT4JQf4Z2y=u2crH0_4=8c8M_7SN-kxyt8UHXoFkMoyXjFA@mail.gmail.com>
 <CAE66OMBZqoUK3+7+6y73-eJUqs1dN_8CVp7juZ2+Toz4TqDKRA@mail.gmail.com>
 <CAFz7x+Q5gG+NvhcRrXEGHPsaT-h0jFzvwSw7S=Ng1zDEjHde7A@mail.gmail.com>
 <CAMzQOd=SaumHQ0niMihJ3G49CJbWyxQCdTKFnxbC=o0JuZS=_g@mail.gmail.com>
Message-ID: <CAMzQOdmLfvwpp0fVzmrHtQTUvrRc1JsqH80pt9c9OC+TkSJwZQ@mail.gmail.com>

Hello Dimitri,

On Mon, Sep 7, 2020 at 9:01 AM Chandan kumar <chkumar246 at gmail.com> wrote:
>
> Hello,
>
> On Sat, Sep 5, 2020 at 3:44 AM Dimitri Savineau <dsavinea at redhat.com> wrote:
> >
> > Hi,
> >
> > We're currently in the progress of using the quay.ceph.io registry [1] with a copy of the ceph container images from docker.io and consumed by the ceph-ansible CI [2].
> >

In TripleO side, daemon:v4.0.12-stable-4.0-nautilus-centos-7-x86_64 is
used but this image is not available on quay.io registry
<https://quay.ceph.io/repository/ceph-ci/daemon?tab=tags>
But v4.0.13-stable-4.0-nautilus-centos-7-x86_64 is available there.
Can we get daemon:v4.0.12-stable-4.0-nautilus-centos-7-x86_64 in
quay.ceph.io registry? or we switch to
v4.0.13-stable-4.0-nautilus-centos-7-x86_64 this tag?

> > Official ceph images will still be updated on docker.io.
> >
> > Note that from a ceph-ansible point of view, switching to the quay.ceph.io registry isn't enough to get rid of the docker.io registry when deploying with the Ceph dashboard enabled.
> > The whole monitoring stack (alertmanager, prometheus, grafana and node-exporter) coming with the Ceph dashboard is still using docker.io by default [3][4][5][6].
> >
> > As an alternative, you can use the official quay registry (quay.io) for altermanager, prometheus and node-exporter images [7] from the prometheus namespace like we're doing in [2].
>
> > Only the grafana container image will still be pulled from docker.io.
> >
>
> The app-sre team mirrors the grafana image from docker.io on quay.
> https://quay.io/repository/app-sre/grafana?tab=tags , we reuse the same in CI?
>
> I have proposed a patch on tripleo-common to switch to quay.io ->
> https://review.opendev.org/#/c/750119/
>

Thanks,

Chandan Kumar


From gfidente at redhat.com  Tue Sep  8 07:42:31 2020
From: gfidente at redhat.com (Giulio Fidente)
Date: Tue, 8 Sep 2020 09:42:31 +0200
Subject: [tripleo] docker.io rate limiting
In-Reply-To: <CAMzQOdmLfvwpp0fVzmrHtQTUvrRc1JsqH80pt9c9OC+TkSJwZQ@mail.gmail.com>
References: <CAOHJT4LT68KhRBt3vxb+D-6VpNUPgc2=JBae0nwC8xNZj2EJzQ@mail.gmail.com>
 <9f9606a3-d8e8-bc66-3440-8cc5ae080d64@redhat.com>
 <CAOHJT4JQf4Z2y=u2crH0_4=8c8M_7SN-kxyt8UHXoFkMoyXjFA@mail.gmail.com>
 <CAE66OMBZqoUK3+7+6y73-eJUqs1dN_8CVp7juZ2+Toz4TqDKRA@mail.gmail.com>
 <CAFz7x+Q5gG+NvhcRrXEGHPsaT-h0jFzvwSw7S=Ng1zDEjHde7A@mail.gmail.com>
 <CAMzQOd=SaumHQ0niMihJ3G49CJbWyxQCdTKFnxbC=o0JuZS=_g@mail.gmail.com>
 <CAMzQOdmLfvwpp0fVzmrHtQTUvrRc1JsqH80pt9c9OC+TkSJwZQ@mail.gmail.com>
Message-ID: <43572ab6-d0d3-7e36-0dde-505e89e7c7fc@redhat.com>

On 9/8/20 9:30 AM, Chandan kumar wrote:
> Hello Dimitri,
> 
> On Mon, Sep 7, 2020 at 9:01 AM Chandan kumar <chkumar246 at gmail.com> wrote:
>>
>> Hello,
>>
>> On Sat, Sep 5, 2020 at 3:44 AM Dimitri Savineau <dsavinea at redhat.com> wrote:
>>>
>>> Hi,
>>>
>>> We're currently in the progress of using the quay.ceph.io registry [1] with a copy of the ceph container images from docker.io and consumed by the ceph-ansible CI [2].
>>>
> 
> In TripleO side, daemon:v4.0.12-stable-4.0-nautilus-centos-7-x86_64 is
> used but this image is not available on quay.io registry
> <https://quay.ceph.io/repository/ceph-ci/daemon?tab=tags>
> But v4.0.13-stable-4.0-nautilus-centos-7-x86_64 is available there.
> Can we get daemon:v4.0.12-stable-4.0-nautilus-centos-7-x86_64 in
> quay.ceph.io registry? or we switch to
> v4.0.13-stable-4.0-nautilus-centos-7-x86_64 this tag?
we can switch to the newer image version ... but what will in the future 
control which image is copied from docker.io to quay.io

this is the same question I had in 
https://review.opendev.org/#/c/750119/4 ; I guess we can continue the 
conversation there
-- 
Giulio Fidente
GPG KEY: 08D733BA



From skaplons at redhat.com  Tue Sep  8 08:09:00 2020
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Tue, 8 Sep 2020 10:09:00 +0200
Subject: Floating IP problem in HA OVN DVR with TripleO
In-Reply-To: <CAMGoRG0AGUbqwkeT1R+1r=1ScTKMySkJ4b6yZpjYDC-49FAr1Q@mail.gmail.com>
References: <CAMGoRG0AGUbqwkeT1R+1r=1ScTKMySkJ4b6yZpjYDC-49FAr1Q@mail.gmail.com>
Message-ID: <20200908080900.efy7bs2qnkzpwbwk@skaplons-mac>

Hi,

Maybe You hit this bug [1]. Please check what ovn version do You have and maybe
update it if needed.

On Mon, Sep 07, 2020 at 06:23:44PM +0430, Reza Bakhshayeshi wrote:
> Hi all,
> 
> I deployed an environment with TripleO Ussuri with 3 HA Controllers and
> some Compute nodes with neutron-ovn-dvr-ha.yaml
> Instances have Internet access through routers with SNAT traffic (in this
> case traffic is routed via a controller node), and by assigning IP address
> directly from provider network (not having a router).
> 
> But in case of assigning FIP from provider to an instance, VM Internet
> connection is lost.
> Here is the output of router nat lists, which seems OK:
> 
> 
> # ovn-nbctl lr-nat-list 587182a4-4d6b-41b0-9fd8-4c1be58811b0
> TYPE             EXTERNAL_IP        EXTERNAL_PORT    LOGICAL_IP
>  EXTERNAL_MAC         LOGICAL_PORT
> dnat_and_snat    X.X.X.X                      192.168.0.153
> fa:16:3e:0a:86:4d    e65bd8e9-5f95-4eb2-a316-97e86fbdb9b6
> snat             Y.Y.Y.Y                      192.168.0.0/24
> 
> 
> I replaced FIP with X.X.X.X and router IP with Y.Y.Y.Y
> 
> When I remove * EXTERNAL_MAC* and *LOGICAL_PORT*, FIP works fine and as it
> has to be, but traffic routes from a Controller node and it won't be
> distributed anymore.
> 
> Any idea or suggestion would be grateful.
> Regards,
> Reza

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

-- 
Slawek Kaplonski
Principal software engineer
Red Hat



From skaplons at redhat.com  Tue Sep  8 08:30:08 2020
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Tue, 8 Sep 2020 10:30:08 +0200
Subject: [neutron] Wallaby PTG planning
In-Reply-To: <20200821072155.pfdjttikum5r54hz@skaplons-mac>
References: <20200821072155.pfdjttikum5r54hz@skaplons-mac>
Message-ID: <20200908083008.3ykanudjhg5fsavs@skaplons-mac>

Hi,

Based on doodle [1] I just booked slots:
Monday 15 - 17 UTC
Tuesday 14 - 17 UTC
Wednesday 14 - 17 UTC
Thursday 14 - 17 UTC
Friday 14 - 17 UTC

For now I don't have any agenda for those sessions yet. Please add Your
topics to the etherpad [2].
If You need some cross project session with Neutron, please also let me know so
we can book some slot for that.

On Fri, Aug 21, 2020 at 09:21:55AM +0200, Slawek Kaplonski wrote:
> Hi,
> 
> It's again that time of the cycle (time flies) when we need to start thinking
> about next cycle already.
> As You probably know, next virtual PTG will be in October 26-30.
> I need to book some space for the Neuton team before 11th of September so I
> prepared doodle [1] with possible time slots. Please reply there what are the
> best days and hours for You so we can try to schedule our sessions in the time
> slots which fits best most of us :)
> Please fill this doodle before 4.09 so I will have time to summarize it and book
> some slots for us.
> 
> I also prepared etherpad [2]. Please add Your name if You are going to attend
> the PTG sessions.
> Please also add proposals of the topics which You want to discuss during the
> PTG.
> 
> [1] https://doodle.com/poll/2ppmnua2nuva5nyp
> [2] https://etherpad.opendev.org/p/neutron-wallaby-ptg
> 
> -- 
> Slawek Kaplonski
> Principal software engineer
> Red Hat

-- 
Slawek Kaplonski
Principal software engineer
Red Hat



From lyarwood at redhat.com  Tue Sep  8 10:12:40 2020
From: lyarwood at redhat.com (Lee Yarwood)
Date: Tue, 8 Sep 2020 11:12:40 +0100
Subject: [all][tc][goals] Migrate CI/CD jobs to new Ubuntu LTS Focal:
 Week R-4 Update
In-Reply-To: <17468f8f785.1123a07e6307801.3844845549431858647@ghanshyammann.com>
References: <17468f8f785.1123a07e6307801.3844845549431858647@ghanshyammann.com>
Message-ID: <20200908101240.3kxygycjgo6cqh5u@lyarwood.usersys.redhat.com>

On 07-09-20 09:29:40, Ghanshyam Mann wrote:
> Bugs Report:
> ==========
> 
> 1. Bug#1882521. (IN-PROGRESS)
> There is open bug for nova/cinder where three tempest tests are failing for
> volume detach operation. There is no clear root cause found yet
> -https://bugs.launchpad.net/cinder/+bug/1882521
> We have skipped the tests in tempest base patch to proceed with the other
> projects testing but this is blocking things for the migration.

FWIW this looks like a QEMU 4.2 issue and I've raised the following bug:

Second DEVICE_DELETED event missing during virtio-blk disk device detach
https://bugs.launchpad.net/qemu/+bug/1894804

-- 
Lee Yarwood                 A5D1 9385 88CB 7E5F BE64  6618 BCA6 6E33 F672 2D76
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/ab400910/attachment.sig>

From sean.mcginnis at gmx.com  Tue Sep  8 10:57:28 2020
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Tue, 8 Sep 2020 05:57:28 -0500
Subject: [release] Release countdown for week R-5 Sept 7 - 11
Message-ID: <20200908105728.GA725930@sm-workstation>

We are getting close to the end of the Victoria cycle! Next week on
September 10 is the victoria-3 milestone, also known as feature freeze.
It's time to wrap up feature work in the services and their client
libraries, and defer features that won't make it to Wallaby.

General Information
-------------------

This coming week is the deadline for client libraries: their last feature
release needs to happen before "Client library freeze" on September 3.
Only bugfix releases will be allowed beyond this point.

When requesting those library releases, you can also include the
stable/victoria branching request with the review. As an example, see the
"branches" section here:
https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/os-brick.yaml#n2

September 10 is also the deadline for feature work in all OpenStack
deliverables following the cycle-with-rc model. To help those projects
produce a first release candidate in time, only bugfixes should be allowed
in the master branch beyond this point. Any feature work past that deadline
has to be raised as a Feature Freeze Exception (FFE) and approved by the
team PTL.

Finally, feature freeze is also the deadline for submitting a first version
of your cycle-highlights. Cycle highlights are the raw data hat helps shape
what is communicated in press releases and other release activity at the
end of the cycle, avoiding direct contacts from marketing folks. See
https://docs.openstack.org/project-team-guide/release-management.html#cycle-highlights
for more details.

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

Client library freeze: September 10 (R-5 week)
Victoria-3 milestone: September 10 (R-5 week)
Cycle Highlights Due: September 10 (R-5 week)
Final Victoria release: October 14
Open Infra Summit: October 19-23
Wallaby PTG: October 26-30


From reza.b2008 at gmail.com  Tue Sep  8 11:03:30 2020
From: reza.b2008 at gmail.com (Reza Bakhshayeshi)
Date: Tue, 8 Sep 2020 15:33:30 +0430
Subject: Floating IP problem in HA OVN DVR with TripleO
In-Reply-To: <20200908080900.efy7bs2qnkzpwbwk@skaplons-mac>
References: <CAMGoRG0AGUbqwkeT1R+1r=1ScTKMySkJ4b6yZpjYDC-49FAr1Q@mail.gmail.com>
 <20200908080900.efy7bs2qnkzpwbwk@skaplons-mac>
Message-ID: <CAMGoRG0_na+9W_dhJiOV_mDYLSFj3Yj0rWzKJhGQoJsKWzuivg@mail.gmail.com>

Hi Slawek,

I'm using the latest CentOS 8 Ussuri OVN packages at:
https://trunk.rdoproject.org/centos8-ussuri/deps/latest/x86_64/

On both Controller and Compute I get:

# rpm -qa | grep ovn
ovn-host-20.03.0-4.el8.x86_64
ovn-20.03.0-4.el8.x86_64

# yum info ovn
Installed Packages
Name         : ovn
Version      : 20.03.0
Release      : 4.el8
Architecture : x86_64
Size         : 12 M
Source       : ovn-20.03.0-4.el8.src.rpm
Repository   : @System
>From repo    : delorean-ussuri-testing
Summary      : Open Virtual Network support
URL          : http://www.openvswitch.org/
License      : ASL 2.0 and LGPLv2+ and SISSL

Do you suggest installing ovn manually from source on containers?
ي

On Tue, 8 Sep 2020 at 12:39, Slawek Kaplonski <skaplons at redhat.com> wrote:

> Hi,
>
> Maybe You hit this bug [1]. Please check what ovn version do You have and
> maybe
> update it if needed.
>
> On Mon, Sep 07, 2020 at 06:23:44PM +0430, Reza Bakhshayeshi wrote:
> > Hi all,
> >
> > I deployed an environment with TripleO Ussuri with 3 HA Controllers and
> > some Compute nodes with neutron-ovn-dvr-ha.yaml
> > Instances have Internet access through routers with SNAT traffic (in this
> > case traffic is routed via a controller node), and by assigning IP
> address
> > directly from provider network (not having a router).
> >
> > But in case of assigning FIP from provider to an instance, VM Internet
> > connection is lost.
> > Here is the output of router nat lists, which seems OK:
> >
> >
> > # ovn-nbctl lr-nat-list 587182a4-4d6b-41b0-9fd8-4c1be58811b0
> > TYPE             EXTERNAL_IP        EXTERNAL_PORT    LOGICAL_IP
> >  EXTERNAL_MAC         LOGICAL_PORT
> > dnat_and_snat    X.X.X.X                      192.168.0.153
> > fa:16:3e:0a:86:4d    e65bd8e9-5f95-4eb2-a316-97e86fbdb9b6
> > snat             Y.Y.Y.Y                      192.168.0.0/24
> >
> >
> > I replaced FIP with X.X.X.X and router IP with Y.Y.Y.Y
> >
> > When I remove * EXTERNAL_MAC* and *LOGICAL_PORT*, FIP works fine and as
> it
> > has to be, but traffic routes from a Controller node and it won't be
> > distributed anymore.
> >
> > Any idea or suggestion would be grateful.
> > Regards,
> > Reza
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1834433
>
> --
> Slawek Kaplonski
> Principal software engineer
> Red Hat
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/1626d2ec/attachment.html>

From alexander.dibbo at stfc.ac.uk  Tue Sep  8 12:47:43 2020
From: alexander.dibbo at stfc.ac.uk (Alexander Dibbo - UKRI STFC)
Date: Tue, 8 Sep 2020 12:47:43 +0000
Subject: Create Application Credential not appearing in Horizon
Message-ID: <6fd945e064ad4be88bad05c17594b067@stfc.ac.uk>

Hi All,

I'm having an issue where users with the "user" role in my deployment are not seeing the "Create Application Credential" button in horizon although users with the "admin" role can.

I have tried modifying the keystone policy a couple of different ways to fix this but none have worked:
"identity:create_application_credential": "user_id:%(user_id)s",
"identity:create_application_credential": "role: user",
"identity:create_application_credential": "rule:owner",
"identity:create_application_credential": "",

Could anyone point me in the right direction?

My deployment is running the Train release of OpenStack

Thanks,

Alex


Regards

Alexander Dibbo - Cloud Architect / Cloud Operations Group Leader
For STFC Cloud Documentation visit https://stfc-cloud-docs.readthedocs.io<https://stfc-cloud-docs.readthedocs.io/>
To raise a support ticket with the cloud team please email cloud-support at gridpp.rl.ac.uk<mailto:cloud-support at gridpp.rl.ac.uk>
To receive notifications about the service please subscribe to our mailing list at: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=STFC-CLOUD
To receive fast notifications or to discuss usage of the cloud please join our Slack: https://stfc-cloud.slack.com/


This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/b949f979/attachment.html>

From rsafrono at redhat.com  Tue Sep  8 12:50:49 2020
From: rsafrono at redhat.com (Roman Safronov)
Date: Tue, 8 Sep 2020 15:50:49 +0300
Subject: Floating IP problem in HA OVN DVR with TripleO
In-Reply-To: <CAMGoRG0_na+9W_dhJiOV_mDYLSFj3Yj0rWzKJhGQoJsKWzuivg@mail.gmail.com>
References: <CAMGoRG0AGUbqwkeT1R+1r=1ScTKMySkJ4b6yZpjYDC-49FAr1Q@mail.gmail.com>
 <20200908080900.efy7bs2qnkzpwbwk@skaplons-mac>
 <CAMGoRG0_na+9W_dhJiOV_mDYLSFj3Yj0rWzKJhGQoJsKWzuivg@mail.gmail.com>
Message-ID: <CAD0t2fnLO8YVOtpeQBDK5Ue2hHt85U_T=kS0VE3++y7JhNP7HA@mail.gmail.com>

Hi Reza,

Are you using 'geneve' tenant networks or 'vlan' ones? I am asking because
with VLAN we have the following DVR issue [1]

[1] Bug 1704596 - FIP traffix does not work on OVN-DVR setup when using
VLAN tenant network type
<https://bugzilla.redhat.com/show_bug.cgi?id=1704596>

On Tue, Sep 8, 2020 at 2:04 PM Reza Bakhshayeshi <reza.b2008 at gmail.com>
wrote:

> Hi Slawek,
>
> I'm using the latest CentOS 8 Ussuri OVN packages at:
> https://trunk.rdoproject.org/centos8-ussuri/deps/latest/x86_64/
>
> On both Controller and Compute I get:
>
> # rpm -qa | grep ovn
> ovn-host-20.03.0-4.el8.x86_64
> ovn-20.03.0-4.el8.x86_64
>
> # yum info ovn
> Installed Packages
> Name         : ovn
> Version      : 20.03.0
> Release      : 4.el8
> Architecture : x86_64
> Size         : 12 M
> Source       : ovn-20.03.0-4.el8.src.rpm
> Repository   : @System
> From repo    : delorean-ussuri-testing
> Summary      : Open Virtual Network support
> URL          : http://www.openvswitch.org/
> License      : ASL 2.0 and LGPLv2+ and SISSL
>
> Do you suggest installing ovn manually from source on containers?
> ي
>
> On Tue, 8 Sep 2020 at 12:39, Slawek Kaplonski <skaplons at redhat.com> wrote:
>
>> Hi,
>>
>> Maybe You hit this bug [1]. Please check what ovn version do You have and
>> maybe
>> update it if needed.
>>
>> On Mon, Sep 07, 2020 at 06:23:44PM +0430, Reza Bakhshayeshi wrote:
>> > Hi all,
>> >
>> > I deployed an environment with TripleO Ussuri with 3 HA Controllers and
>> > some Compute nodes with neutron-ovn-dvr-ha.yaml
>> > Instances have Internet access through routers with SNAT traffic (in
>> this
>> > case traffic is routed via a controller node), and by assigning IP
>> address
>> > directly from provider network (not having a router).
>> >
>> > But in case of assigning FIP from provider to an instance, VM Internet
>> > connection is lost.
>> > Here is the output of router nat lists, which seems OK:
>> >
>> >
>> > # ovn-nbctl lr-nat-list 587182a4-4d6b-41b0-9fd8-4c1be58811b0
>> > TYPE             EXTERNAL_IP        EXTERNAL_PORT    LOGICAL_IP
>> >  EXTERNAL_MAC         LOGICAL_PORT
>> > dnat_and_snat    X.X.X.X                      192.168.0.153
>> > fa:16:3e:0a:86:4d    e65bd8e9-5f95-4eb2-a316-97e86fbdb9b6
>> > snat             Y.Y.Y.Y                      192.168.0.0/24
>> >
>> >
>> > I replaced FIP with X.X.X.X and router IP with Y.Y.Y.Y
>> >
>> > When I remove * EXTERNAL_MAC* and *LOGICAL_PORT*, FIP works fine and as
>> it
>> > has to be, but traffic routes from a Controller node and it won't be
>> > distributed anymore.
>> >
>> > Any idea or suggestion would be grateful.
>> > Regards,
>> > Reza
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1834433
>>
>> --
>> Slawek Kaplonski
>> Principal software engineer
>> Red Hat
>>
>>

-- 

ROMAN SAFRONOV

SENIOR QE, OPENSTACK NETWORKING

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

Israel

M: +972545433957

<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/d6490c93/attachment.html>

From ligang6 at huawei.com  Mon Sep  7 14:04:20 2020
From: ligang6 at huawei.com (ligang (P))
Date: Mon, 7 Sep 2020 14:04:20 +0000
Subject: watchdog fed successfully event of 6300esb
Message-ID: <624825e298f94650a7b69f483c9de84d@huawei.com>

Hi folks,

I have an question to discuss about the 6300esb watchdog.

I think is it possible that qemu can send an event while the watchdog successfully fed by the vm at the first time.

Here is the situation:

Qemu will send an VIR_DOMAIN_EVENT_ID_WATCHDOG event while watch dog timeout, and if the action of the watchdog in xml of the vm was set to "reset", the vm will be rebooted while timeout.

I have an monitor process that register callback function of the VIR_DOMAIN_EVENT_ID_WATCHDOG event, the callback function will send an alarm to my upper layer monitor platform indicate that the vm is fault, and the cluster deployed business on the vm will isolate the vm by the alarm.

And after the vm rebooted , the monitor process will receive an reboot event and send it to the platform, the upper layer monitor platform will clear the alarm, and business continue to run on the vm.

In most cases ,the watch dog process in vm will feed the watchdog after vm rebooted and all things go back on track.

In some other cases,the guestos may failed to start (in my environment vm start failed by io error), but the reboot event will still be received and the alarm will be cleared and the vm is still fault. So the this may not a good idea to clear the alarm by the reboot event.

So, I think it will be helpful that the qemu can send an event while the watchdog successfully fed by the vm at the first time. So I can exactly know that the guest os go back on running and the watch dog initialized successfully.

Or any other opintion about this situation.

Thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200907/bba30622/attachment-0001.html>

From pierre at stackhpc.com  Tue Sep  8 14:18:14 2020
From: pierre at stackhpc.com (Pierre Riteau)
Date: Tue, 8 Sep 2020 16:18:14 +0200
Subject: Create Application Credential not appearing in Horizon
In-Reply-To: <6fd945e064ad4be88bad05c17594b067@stfc.ac.uk>
References: <6fd945e064ad4be88bad05c17594b067@stfc.ac.uk>
Message-ID: <CA+ny2sz4bi79b9FA5f=P4+nabPyDXcriu56zUwS0nsxvKCf4mA@mail.gmail.com>

Hi Alex,

In addition to adding this setting to Keystone's policy file, does Horizon
have its own copy of the keystone policy file accessible and including
these settings? By default it is named keystone_policy.json.

Best wishes,
Pierre

On Tue, 8 Sep 2020 at 14:48, Alexander Dibbo - UKRI STFC <
alexander.dibbo at stfc.ac.uk> wrote:

> Hi All,
>
>
>
> I’m having an issue where users with the “user” role in my deployment are
> not seeing the “Create Application Credential” button in horizon although
> users with the “admin” role can.
>
>
>
> I have tried modifying the keystone policy a couple of different ways to
> fix this but none have worked:
>
> "identity:create_application_credential": "user_id:%(user_id)s",
>
> "identity:create_application_credential": "role: user",
>
> "identity:create_application_credential": "rule:owner",
>
> "identity:create_application_credential": "",
>
>
>
> Could anyone point me in the right direction?
>
>
>
> My deployment is running the Train release of OpenStack
>
>
>
> Thanks,
>
>
>
> Alex
>
>
>
>
>
> Regards
>
>
>
> Alexander Dibbo – Cloud Architect / Cloud Operations Group Leader
>
> For STFC Cloud Documentation visit https://stfc-cloud-docs.readthedocs.io
>
> To raise a support ticket with the cloud team please email
> cloud-support at gridpp.rl.ac.uk
>
> To receive notifications about the service please subscribe to our mailing
> list at: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=STFC-CLOUD
>
> To receive fast notifications or to discuss usage of the cloud please join
> our Slack: https://stfc-cloud.slack.com/
>
>
>
> This email and any attachments are intended solely for the use of the
> named recipients. If you are not the intended recipient you must not use,
> disclose, copy or distribute this email or any of its attachments and
> should notify the sender immediately and delete this email from your
> system. UK Research and Innovation (UKRI) has taken every reasonable
> precaution to minimise risk of this email or any attachments containing
> viruses or malware but the recipient should carry out its own virus and
> malware checks before opening the attachments. UKRI does not accept any
> liability for any losses or damages which the recipient may sustain due to
> presence of any viruses. Opinions, conclusions or other information in this
> message and attachments that are not related directly to UKRI business are
> solely those of the author and do not represent the views of UKRI.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/40700e98/attachment.html>

From alexander.dibbo at stfc.ac.uk  Tue Sep  8 14:25:38 2020
From: alexander.dibbo at stfc.ac.uk (Alexander Dibbo - UKRI STFC)
Date: Tue, 8 Sep 2020 14:25:38 +0000
Subject: Create Application Credential not appearing in Horizon
In-Reply-To: <CA+ny2sz4bi79b9FA5f=P4+nabPyDXcriu56zUwS0nsxvKCf4mA@mail.gmail.com>
References: <6fd945e064ad4be88bad05c17594b067@stfc.ac.uk>
 <CA+ny2sz4bi79b9FA5f=P4+nabPyDXcriu56zUwS0nsxvKCf4mA@mail.gmail.com>
Message-ID: <a811aba342b9404d9f5ea67c98673264@stfc.ac.uk>

Thanks Pierre,

That’s got it, I knew it would be something simple

Thanks

Regards

Alexander Dibbo – Cloud Architect / Cloud Operations Group Leader
For STFC Cloud Documentation visit https://stfc-cloud-docs.readthedocs.io<https://stfc-cloud-docs.readthedocs.io/>
To raise a support ticket with the cloud team please email cloud-support at gridpp.rl.ac.uk<mailto:cloud-support at gridpp.rl.ac.uk>
To receive notifications about the service please subscribe to our mailing list at: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=STFC-CLOUD
To receive fast notifications or to discuss usage of the cloud please join our Slack: https://stfc-cloud.slack.com/

From: Pierre Riteau <pierre at stackhpc.com>
Sent: 08 September 2020 15:18
To: Dibbo, Alexander (STFC,RAL,SC) <alexander.dibbo at stfc.ac.uk>
Cc: openstack-discuss at lists.openstack.org
Subject: Re: Create Application Credential not appearing in Horizon

Hi Alex,

In addition to adding this setting to Keystone's policy file, does Horizon have its own copy of the keystone policy file accessible and including these settings? By default it is named keystone_policy.json.

Best wishes,
Pierre

On Tue, 8 Sep 2020 at 14:48, Alexander Dibbo - UKRI STFC <alexander.dibbo at stfc.ac.uk<mailto:alexander.dibbo at stfc.ac.uk>> wrote:
Hi All,

I’m having an issue where users with the “user” role in my deployment are not seeing the “Create Application Credential” button in horizon although users with the “admin” role can.

I have tried modifying the keystone policy a couple of different ways to fix this but none have worked:
"identity:create_application_credential": "user_id:%(user_id)s",
"identity:create_application_credential": "role: user",
"identity:create_application_credential": "rule:owner",
"identity:create_application_credential": "",

Could anyone point me in the right direction?

My deployment is running the Train release of OpenStack

Thanks,

Alex


Regards

Alexander Dibbo – Cloud Architect / Cloud Operations Group Leader
For STFC Cloud Documentation visit https://stfc-cloud-docs.readthedocs.io<https://stfc-cloud-docs.readthedocs.io/>
To raise a support ticket with the cloud team please email cloud-support at gridpp.rl.ac.uk<mailto:cloud-support at gridpp.rl.ac.uk>
To receive notifications about the service please subscribe to our mailing list at: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=STFC-CLOUD
To receive fast notifications or to discuss usage of the cloud please join our Slack: https://stfc-cloud.slack.com/


This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/d15aba0a/attachment-0001.html>

From pierre at stackhpc.com  Tue Sep  8 14:40:43 2020
From: pierre at stackhpc.com (Pierre Riteau)
Date: Tue, 8 Sep 2020 16:40:43 +0200
Subject: [cloudkitty] Virtual PTG planning
In-Reply-To: <CAG97rac1gsfH_NT0vznVQy2s=FUFkrmFWJivDCUWktiauJY8+Q@mail.gmail.com>
References: <CA+ny2syPgqQ-mH5ibEdznxca+YNOVRQfJCjY+oRO-Nx5hpPxDw@mail.gmail.com>
 <CAG97rac1gsfH_NT0vznVQy2s=FUFkrmFWJivDCUWktiauJY8+Q@mail.gmail.com>
Message-ID: <CA+ny2swTHsL-fJmiEz2Zn8XYVDc00Tfts7F5JpyVYiV8t2qpAg@mail.gmail.com>

Hi Rafael,

Thanks a lot for your reply and for volunteering to help moderate the
discussion.

I've answered the survey to register our interest in attending. I also
booked three hours in the Cactus room starting at 14 UTC on Friday, October
30. That's probably above what we really need, so don't feel like you have
to use it all if there's no more to discuss.

Best wishes,
Pierre

On Mon, 7 Sep 2020 at 17:26, Rafael Weingärtner <rafaelweingartner at gmail.com>
wrote:

> I'm available.  I am not sure though if we need half a day. That seems
> quite a lot, but I might be mistaken (as I have never participated in a PTG
> planning meeting).
> 14 UTC works for me on any of the proposed days (Friday October 30 seems
> to be free a series of slots in the Cactus room). I could also help being
> the chair, if needed.
>
>
> On Fri, Sep 4, 2020 at 12:47 PM Pierre Riteau <pierre at stackhpc.com> wrote:
>
>> Hi,
>>
>> You may know that the next PTG will be held virtually during the week
>> of October 26-30, 2020.
>> I will very likely *not* be available during that time, so I would like
>> to hear from the CloudKitty community:
>>
>> - if you would like to meet and for how long (a half day may be enough
>> depending on the agenda)
>> - what day and time is preferred (see list in
>> https://ethercalc.openstack.org/7xp2pcbh1ncb)
>> - if anyone is willing to chair the discussions (I can help you prepare
>> an agenda before the event)
>>
>> Thanks in advance,
>> Pierre Riteau (priteau)
>>
>
>
> --
> Rafael Weingärtner
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/5e4a47d0/attachment.html>

From rdhasman at redhat.com  Tue Sep  8 15:13:05 2020
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Tue, 8 Sep 2020 20:43:05 +0530
Subject: [requirements][FFE] Cinder multiple stores support
Message-ID: <CAARK8KQE+wR3tjzYt0jiTRcaa71siOG6VZTUWnX=N7kM+dABHw@mail.gmail.com>

Hi Team,

Last week we released glance_store 2.3.0 which adds support for
configuring cinder multiple stores as glance backend.
While adding functional tests in glance for the same [1], we have
noticed that it is failing with some hard requirements from oslo side
to use project_id instead of tenant and user_id instead of user.
It is really strange behavior as this failure occurs only in
functional tests but works properly in the actual environment without
any issue. The fix is proposed in glance_store [2] to resolve this
issue.

I would like to apply for FFE with this glance_store patch [2] to be
approved and release a new version of glance_store 2.3.1.

Kindly provide approval for the same.

[1] https://review.opendev.org/#/c/750144/
[2] https://review.opendev.org/#/c/750131/

Thanks and Regards,
Rajat Dhasmana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/fb7b477e/attachment.html>

From akekane at redhat.com  Tue Sep  8 15:23:03 2020
From: akekane at redhat.com (Abhishek Kekane)
Date: Tue, 8 Sep 2020 20:53:03 +0530
Subject: [requirements][FFE] Cinder multiple stores support
In-Reply-To: <CAARK8KQE+wR3tjzYt0jiTRcaa71siOG6VZTUWnX=N7kM+dABHw@mail.gmail.com>
References: <CAARK8KQE+wR3tjzYt0jiTRcaa71siOG6VZTUWnX=N7kM+dABHw@mail.gmail.com>
Message-ID: <CALOt+SSwMyAHZNPMyqwJewid5+Y7E3LToiV1B2Tm4YOwohnLWw@mail.gmail.com>

Hi Team,

The reason for failure is we are suppressing Deprecation warning into error
in glance [1] and we are using those deprecated parameters in glance_store.
This is the reason why it is only failing in functional tests [2] and not
in actual scenarios.

[1]
https://opendev.org/openstack/glance/src/branch/master/glance/tests/unit/fixtures.py#L133-L136
[2]https://review.opendev.org/#/c/750144/

Thanks & Best Regards,

Abhishek Kekane


On Tue, Sep 8, 2020 at 8:48 PM Rajat Dhasmana <rdhasman at redhat.com> wrote:

> Hi Team,
>
> Last week we released glance_store 2.3.0 which adds support for configuring cinder multiple stores as glance backend.
> While adding functional tests in glance for the same [1], we have noticed that it is failing with some hard requirements from oslo side to use project_id instead of tenant and user_id instead of user.
> It is really strange behavior as this failure occurs only in functional tests but works properly in the actual environment without any issue. The fix is proposed in glance_store [2] to resolve this issue.
>
> I would like to apply for FFE with this glance_store patch [2] to be approved and release a new version of glance_store 2.3.1.
>
> Kindly provide approval for the same.
>
> [1] https://review.opendev.org/#/c/750144/
> [2] https://review.opendev.org/#/c/750131/
>
> Thanks and Regards,
> Rajat Dhasmana
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/f693dc03/attachment.html>

From alexander.dibbo at stfc.ac.uk  Tue Sep  8 15:28:01 2020
From: alexander.dibbo at stfc.ac.uk (Alexander Dibbo - UKRI STFC)
Date: Tue, 8 Sep 2020 15:28:01 +0000
Subject: Application Credentials with federated users
Message-ID: <7fc8d66653064962aa458e13124bcb9d@stfc.ac.uk>

Hi All,

Is it possible for a user logging in via an oidc provider to generate application credentials?

When I try it I get an error about there being no role for the user in the project.

We map the users to groups based on assertions in their tokens.

It looks like it would work if we mapped users individually to local users in keystone and then gave those roles. I would prefer to avoid using per user mappings for this if possible as it would be a lot of extra work for my team.

Regards

Alexander Dibbo - Cloud Architect / Cloud Operations Group Leader
For STFC Cloud Documentation visit https://stfc-cloud-docs.readthedocs.io<https://stfc-cloud-docs.readthedocs.io/>
To raise a support ticket with the cloud team please email cloud-support at gridpp.rl.ac.uk<mailto:cloud-support at gridpp.rl.ac.uk>
To receive notifications about the service please subscribe to our mailing list at: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=STFC-CLOUD
To receive fast notifications or to discuss usage of the cloud please join our Slack: https://stfc-cloud.slack.com/


This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/1a6a9502/attachment-0001.html>

From gmann at ghanshyammann.com  Tue Sep  8 15:45:36 2020
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Tue, 08 Sep 2020 10:45:36 -0500
Subject: [oslo][release][requirement] FFE request for Oslo lib
Message-ID: <1746e64d702.ee80b0bc1249.5426348472779199647@ghanshyammann.com>

Hello Team,

This is regarding FFE for Focal migration work. As planned, we have to move the Victoria testing to Focal and
base job switch is planned to be switched by today[1].

There are few oslo lib need work (especially tox job-based testing not user-facing changes) to pass on Focal
- https://review.opendev.org/#/q/topic:migrate-to-focal-oslo+(status:open+OR+status:merged)

If we move the base tox jobs to Focal then these lib victoria gates (especially lower-constraint job) will be failing.
We can either do these as FFE or backport (as this is lib own CI fixes only) later once the victoria branch is open.
 
Opinion?

[1] http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017060.html

-gmann



From its-openstack at zohocorp.com  Tue Sep  8 16:49:51 2020
From: its-openstack at zohocorp.com (its-openstack at zohocorp.com)
Date: Tue, 08 Sep 2020 22:19:51 +0530
Subject: Windows 10 instance hostname not updating
Message-ID: <1746e9fa998.113c837477438.2565411855453438482@zohocorp.com>

Dear openstack,

I have installed openstack train branch, I am facing issue with windows image. all windows 10 instance dosen't get its hostname updated from the metadata, 
but able to get the metadata(hostname) from inside the instance using powershell.
``` $ Invoke-WebRequest http://169.254.169.254/latest/meta-data/hostname -UseBasicParsing  ```
 
windows2016 instance no issue.

using the stable cloudbase-init package for preparation of windows 10. if you would so kindly help us with this issue

Regards
sysadmin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/9b05ca42/attachment.html>

From reza.b2008 at gmail.com  Tue Sep  8 16:51:32 2020
From: reza.b2008 at gmail.com (Reza Bakhshayeshi)
Date: Tue, 8 Sep 2020 21:21:32 +0430
Subject: Floating IP problem in HA OVN DVR with TripleO
In-Reply-To: <CAD0t2fnLO8YVOtpeQBDK5Ue2hHt85U_T=kS0VE3++y7JhNP7HA@mail.gmail.com>
References: <CAMGoRG0AGUbqwkeT1R+1r=1ScTKMySkJ4b6yZpjYDC-49FAr1Q@mail.gmail.com>
 <20200908080900.efy7bs2qnkzpwbwk@skaplons-mac>
 <CAMGoRG0_na+9W_dhJiOV_mDYLSFj3Yj0rWzKJhGQoJsKWzuivg@mail.gmail.com>
 <CAD0t2fnLO8YVOtpeQBDK5Ue2hHt85U_T=kS0VE3++y7JhNP7HA@mail.gmail.com>
Message-ID: <CAMGoRG1LTjcrU+HTtA4xuUurb92MWbyR-hCgtBqeEXyyzR=iNw@mail.gmail.com>

Hi Roman,

I'm using 'geneve' for my tenant networks.

By the way, by pinging 8.8.8.8 from an instance with FIP, tcpdump on its
Compute node shows an ARP request for every lost ping. Is it normal
behaviour?

21:13:04.808508 ARP, Request who-has dns.google tell  X.X.X.X , length 28
21:13:05.808726 ARP, Request who-has dns.google tell  X.X.X.X , length 28
21:13:06.808900 ARP, Request who-has dns.google tell  X.X.X.X , length 28
.
.
.
X.X.X.X if FIP of VM.


On Tue, 8 Sep 2020 at 17:21, Roman Safronov <rsafrono at redhat.com> wrote:

> Hi Reza,
>
> Are you using 'geneve' tenant networks or 'vlan' ones? I am asking because
> with VLAN we have the following DVR issue [1]
>
> [1] Bug 1704596 - FIP traffix does not work on OVN-DVR setup when using
> VLAN tenant network type
> <https://bugzilla.redhat.com/show_bug.cgi?id=1704596>
>
> On Tue, Sep 8, 2020 at 2:04 PM Reza Bakhshayeshi <reza.b2008 at gmail.com>
> wrote:
>
>> Hi Slawek,
>>
>> I'm using the latest CentOS 8 Ussuri OVN packages at:
>> https://trunk.rdoproject.org/centos8-ussuri/deps/latest/x86_64/
>>
>> On both Controller and Compute I get:
>>
>> # rpm -qa | grep ovn
>> ovn-host-20.03.0-4.el8.x86_64
>> ovn-20.03.0-4.el8.x86_64
>>
>> # yum info ovn
>> Installed Packages
>> Name         : ovn
>> Version      : 20.03.0
>> Release      : 4.el8
>> Architecture : x86_64
>> Size         : 12 M
>> Source       : ovn-20.03.0-4.el8.src.rpm
>> Repository   : @System
>> From repo    : delorean-ussuri-testing
>> Summary      : Open Virtual Network support
>> URL          : http://www.openvswitch.org/
>> License      : ASL 2.0 and LGPLv2+ and SISSL
>>
>> Do you suggest installing ovn manually from source on containers?
>> ي
>>
>> On Tue, 8 Sep 2020 at 12:39, Slawek Kaplonski <skaplons at redhat.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Maybe You hit this bug [1]. Please check what ovn version do You have
>>> and maybe
>>> update it if needed.
>>>
>>> On Mon, Sep 07, 2020 at 06:23:44PM +0430, Reza Bakhshayeshi wrote:
>>> > Hi all,
>>> >
>>> > I deployed an environment with TripleO Ussuri with 3 HA Controllers and
>>> > some Compute nodes with neutron-ovn-dvr-ha.yaml
>>> > Instances have Internet access through routers with SNAT traffic (in
>>> this
>>> > case traffic is routed via a controller node), and by assigning IP
>>> address
>>> > directly from provider network (not having a router).
>>> >
>>> > But in case of assigning FIP from provider to an instance, VM Internet
>>> > connection is lost.
>>> > Here is the output of router nat lists, which seems OK:
>>> >
>>> >
>>> > # ovn-nbctl lr-nat-list 587182a4-4d6b-41b0-9fd8-4c1be58811b0
>>> > TYPE             EXTERNAL_IP        EXTERNAL_PORT    LOGICAL_IP
>>> >  EXTERNAL_MAC         LOGICAL_PORT
>>> > dnat_and_snat    X.X.X.X                      192.168.0.153
>>> > fa:16:3e:0a:86:4d    e65bd8e9-5f95-4eb2-a316-97e86fbdb9b6
>>> > snat             Y.Y.Y.Y                      192.168.0.0/24
>>> >
>>> >
>>> > I replaced FIP with X.X.X.X and router IP with Y.Y.Y.Y
>>> >
>>> > When I remove * EXTERNAL_MAC* and *LOGICAL_PORT*, FIP works fine and
>>> as it
>>> > has to be, but traffic routes from a Controller node and it won't be
>>> > distributed anymore.
>>> >
>>> > Any idea or suggestion would be grateful.
>>> > Regards,
>>> > Reza
>>>
>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1834433
>>>
>>> --
>>> Slawek Kaplonski
>>> Principal software engineer
>>> Red Hat
>>>
>>>
>
> --
>
> ROMAN SAFRONOV
>
> SENIOR QE, OPENSTACK NETWORKING
>
> Red Hat <https://www.redhat.com/>
>
> Israel
>
> M: +972545433957
>
> <https://red.ht/sig>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/979e85c7/attachment.html>

From rsafrono at redhat.com  Tue Sep  8 17:10:15 2020
From: rsafrono at redhat.com (Roman Safronov)
Date: Tue, 8 Sep 2020 20:10:15 +0300
Subject: Floating IP problem in HA OVN DVR with TripleO
In-Reply-To: <CAMGoRG1LTjcrU+HTtA4xuUurb92MWbyR-hCgtBqeEXyyzR=iNw@mail.gmail.com>
References: <CAMGoRG0AGUbqwkeT1R+1r=1ScTKMySkJ4b6yZpjYDC-49FAr1Q@mail.gmail.com>
 <20200908080900.efy7bs2qnkzpwbwk@skaplons-mac>
 <CAMGoRG0_na+9W_dhJiOV_mDYLSFj3Yj0rWzKJhGQoJsKWzuivg@mail.gmail.com>
 <CAD0t2fnLO8YVOtpeQBDK5Ue2hHt85U_T=kS0VE3++y7JhNP7HA@mail.gmail.com>
 <CAMGoRG1LTjcrU+HTtA4xuUurb92MWbyR-hCgtBqeEXyyzR=iNw@mail.gmail.com>
Message-ID: <CAD0t2fmJwqWrh3qZnaBpGcoBucipgsL5vk4snEMaYhms8mbm_Q@mail.gmail.com>

>
> I'm using 'geneve' for my tenant networks.
>
> By the way, by pinging 8.8.8.8 from an instance with FIP, tcpdump on its
> Compute node shows an ARP request for every lost ping. Is it normal
> behaviour?
>
> 21:13:04.808508 ARP, Request who-has dns.google tell  X.X.X.X , length 28
> 21:13:05.808726 ARP, Request who-has dns.google tell  X.X.X.X , length 28
> 21:13:06.808900 ARP, Request who-has dns.google tell  X.X.X.X , length 28
> .
> .
> .
> X.X.X.X if FIP of VM.
>

If so, it looks like the bug
<https://bugzilla.redhat.com/show_bug.cgi?id=1834433> mentioned above.

On Tue, Sep 8, 2020 at 7:51 PM Reza Bakhshayeshi <reza.b2008 at gmail.com>
wrote:

> Hi Roman,
>
> I'm using 'geneve' for my tenant networks.
>
> By the way, by pinging 8.8.8.8 from an instance with FIP, tcpdump on its
> Compute node shows an ARP request for every lost ping. Is it normal
> behaviour?
>
> 21:13:04.808508 ARP, Request who-has dns.google tell  X.X.X.X , length 28
> 21:13:05.808726 ARP, Request who-has dns.google tell  X.X.X.X , length 28
> 21:13:06.808900 ARP, Request who-has dns.google tell  X.X.X.X , length 28
> .
> .
> .
> X.X.X.X if FIP of VM.
>
>
> On Tue, 8 Sep 2020 at 17:21, Roman Safronov <rsafrono at redhat.com> wrote:
>
>> Hi Reza,
>>
>> Are you using 'geneve' tenant networks or 'vlan' ones? I am asking
>> because with VLAN we have the following DVR issue [1]
>>
>> [1] Bug 1704596 - FIP traffix does not work on OVN-DVR setup when using
>> VLAN tenant network type
>> <https://bugzilla.redhat.com/show_bug.cgi?id=1704596>
>>
>> On Tue, Sep 8, 2020 at 2:04 PM Reza Bakhshayeshi <reza.b2008 at gmail.com>
>> wrote:
>>
>>> Hi Slawek,
>>>
>>> I'm using the latest CentOS 8 Ussuri OVN packages at:
>>> https://trunk.rdoproject.org/centos8-ussuri/deps/latest/x86_64/
>>>
>>> On both Controller and Compute I get:
>>>
>>> # rpm -qa | grep ovn
>>> ovn-host-20.03.0-4.el8.x86_64
>>> ovn-20.03.0-4.el8.x86_64
>>>
>>> # yum info ovn
>>> Installed Packages
>>> Name         : ovn
>>> Version      : 20.03.0
>>> Release      : 4.el8
>>> Architecture : x86_64
>>> Size         : 12 M
>>> Source       : ovn-20.03.0-4.el8.src.rpm
>>> Repository   : @System
>>> From repo    : delorean-ussuri-testing
>>> Summary      : Open Virtual Network support
>>> URL          : http://www.openvswitch.org/
>>> License      : ASL 2.0 and LGPLv2+ and SISSL
>>>
>>> Do you suggest installing ovn manually from source on containers?
>>> ي
>>>
>>> On Tue, 8 Sep 2020 at 12:39, Slawek Kaplonski <skaplons at redhat.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Maybe You hit this bug [1]. Please check what ovn version do You have
>>>> and maybe
>>>> update it if needed.
>>>>
>>>> On Mon, Sep 07, 2020 at 06:23:44PM +0430, Reza Bakhshayeshi wrote:
>>>> > Hi all,
>>>> >
>>>> > I deployed an environment with TripleO Ussuri with 3 HA Controllers
>>>> and
>>>> > some Compute nodes with neutron-ovn-dvr-ha.yaml
>>>> > Instances have Internet access through routers with SNAT traffic (in
>>>> this
>>>> > case traffic is routed via a controller node), and by assigning IP
>>>> address
>>>> > directly from provider network (not having a router).
>>>> >
>>>> > But in case of assigning FIP from provider to an instance, VM Internet
>>>> > connection is lost.
>>>> > Here is the output of router nat lists, which seems OK:
>>>> >
>>>> >
>>>> > # ovn-nbctl lr-nat-list 587182a4-4d6b-41b0-9fd8-4c1be58811b0
>>>> > TYPE             EXTERNAL_IP        EXTERNAL_PORT    LOGICAL_IP
>>>> >  EXTERNAL_MAC         LOGICAL_PORT
>>>> > dnat_and_snat    X.X.X.X                      192.168.0.153
>>>> > fa:16:3e:0a:86:4d    e65bd8e9-5f95-4eb2-a316-97e86fbdb9b6
>>>> > snat             Y.Y.Y.Y                      192.168.0.0/24
>>>> >
>>>> >
>>>> > I replaced FIP with X.X.X.X and router IP with Y.Y.Y.Y
>>>> >
>>>> > When I remove * EXTERNAL_MAC* and *LOGICAL_PORT*, FIP works fine and
>>>> as it
>>>> > has to be, but traffic routes from a Controller node and it won't be
>>>> > distributed anymore.
>>>> >
>>>> > Any idea or suggestion would be grateful.
>>>> > Regards,
>>>> > Reza
>>>>
>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1834433
>>>>
>>>> --
>>>> Slawek Kaplonski
>>>> Principal software engineer
>>>> Red Hat
>>>>
>>>>
>>
>> --
>>
>> ROMAN SAFRONOV
>>
>> SENIOR QE, OPENSTACK NETWORKING
>>
>> Red Hat <https://www.redhat.com/>
>>
>> Israel
>>
>> M: +972545433957
>>
>> <https://red.ht/sig>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/a54c130d/attachment-0001.html>

From mnasiadka at gmail.com  Tue Sep  8 17:12:33 2020
From: mnasiadka at gmail.com (=?UTF-8?Q?Micha=C5=82_Nasiadka?=)
Date: Tue, 8 Sep 2020 19:12:33 +0200
Subject: Floating IP problem in HA OVN DVR with TripleO
In-Reply-To: <CAMGoRG1LTjcrU+HTtA4xuUurb92MWbyR-hCgtBqeEXyyzR=iNw@mail.gmail.com>
References: <CAMGoRG0AGUbqwkeT1R+1r=1ScTKMySkJ4b6yZpjYDC-49FAr1Q@mail.gmail.com>
 <20200908080900.efy7bs2qnkzpwbwk@skaplons-mac>
 <CAMGoRG0_na+9W_dhJiOV_mDYLSFj3Yj0rWzKJhGQoJsKWzuivg@mail.gmail.com>
 <CAD0t2fnLO8YVOtpeQBDK5Ue2hHt85U_T=kS0VE3++y7JhNP7HA@mail.gmail.com>
 <CAMGoRG1LTjcrU+HTtA4xuUurb92MWbyR-hCgtBqeEXyyzR=iNw@mail.gmail.com>
Message-ID: <CANhpHj-ijDAA-TfeGDKt7vTOdCkqDgmuYMYtGsJ6PbUd1VPF_w@mail.gmail.com>

Hi Reza,

Here is a related bug:
https://bugs.launchpad.net/bugs/1881041

I had to use ovn/ovs 2.13 builds from cbs to overcome this issue (
https://cbs.centos.org/koji/buildinfo?buildID=30482)

Regards,
Michal

On Tue, 8 Sep 2020 at 18:52, Reza Bakhshayeshi <reza.b2008 at gmail.com> wrote:

> Hi Roman,
>
> I'm using 'geneve' for my tenant networks.
>
> By the way, by pinging 8.8.8.8 from an instance with FIP, tcpdump on its
> Compute node shows an ARP request for every lost ping. Is it normal
> behaviour?
>
> 21:13:04.808508 ARP, Request who-has dns.google tell
>
> X.X.X.X
>
>
>
> , length 28
> 21:13:05.808726 ARP, Request who-has dns.google tell
>
> X.X.X.X
>
>
>
> , length 28
> 21:13:06.808900 ARP, Request who-has dns.google tell
>
> X.X.X.X
>
>
>
> , length 28
> .
> .
> .
> X.X.X.X if FIP of VM.
>
>
> On Tue, 8 Sep 2020 at 17:21, Roman Safronov <rsafrono at redhat.com> wrote:
>
>> Hi Reza,
>>
>> Are you using 'geneve' tenant networks or 'vlan' ones? I am asking
>> because with VLAN we have the following DVR issue [1]
>>
>> [1] Bug 1704596 - FIP traffix does not work on OVN-DVR setup when using
>> VLAN tenant network type
>> <https://bugzilla.redhat.com/show_bug.cgi?id=1704596>
>>
>> On Tue, Sep 8, 2020 at 2:04 PM Reza Bakhshayeshi <reza.b2008 at gmail.com>
>> wrote:
>>
>>> Hi Slawek,
>>>
>>> I'm using the latest CentOS 8 Ussuri OVN packages at:
>>> https://trunk.rdoproject.org/centos8-ussuri/deps/latest/x86_64/
>>>
>>> On both Controller and Compute I get:
>>>
>>> # rpm -qa | grep ovn
>>> ovn-host-20.03.0-4.el8.x86_64
>>> ovn-20.03.0-4.el8.x86_64
>>>
>>> # yum info ovn
>>> Installed Packages
>>> Name         : ovn
>>> Version      : 20.03.0
>>> Release      : 4.el8
>>> Architecture : x86_64
>>> Size         : 12 M
>>> Source       : ovn-20.03.0-4.el8.src.rpm
>>> Repository   : @System
>>> From repo    : delorean-ussuri-testing
>>> Summary      : Open Virtual Network support
>>> URL          : http://www.openvswitch.org/
>>> License      : ASL 2.0 and LGPLv2+ and SISSL
>>>
>>> Do you suggest installing ovn manually from source on containers?
>>> ي
>>>
>>> On Tue, 8 Sep 2020 at 12:39, Slawek Kaplonski <skaplons at redhat.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Maybe You hit this bug [1]. Please check what ovn version do You have
>>>> and maybe
>>>>
>>>>
>>>> update it if needed.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Sep 07, 2020 at 06:23:44PM +0430, Reza Bakhshayeshi wrote:
>>>>
>>>>
>>>> > Hi all,
>>>>
>>>>
>>>> >
>>>>
>>>>
>>>> > I deployed an environment with TripleO Ussuri with 3 HA Controllers
>>>> and
>>>>
>>>>
>>>> > some Compute nodes with neutron-ovn-dvr-ha.yaml
>>>>
>>>>
>>>> > Instances have Internet access through routers with SNAT traffic (in
>>>> this
>>>>
>>>>
>>>> > case traffic is routed via a controller node), and by assigning IP
>>>> address
>>>>
>>>>
>>>> > directly from provider network (not having a router).
>>>>
>>>>
>>>> >
>>>>
>>>>
>>>> > But in case of assigning FIP from provider to an instance, VM Internet
>>>>
>>>>
>>>> > connection is lost.
>>>>
>>>>
>>>> > Here is the output of router nat lists, which seems OK:
>>>>
>>>>
>>>> >
>>>>
>>>>
>>>> >
>>>>
>>>>
>>>> > # ovn-nbctl lr-nat-list 587182a4-4d6b-41b0-9fd8-4c1be58811b0
>>>>
>>>>
>>>> > TYPE             EXTERNAL_IP        EXTERNAL_PORT    LOGICAL_IP
>>>>
>>>>
>>>> >  EXTERNAL_MAC         LOGICAL_PORT
>>>>
>>>>
>>>> > dnat_and_snat    X.X.X.X                      192.168.0.153
>>>>
>>>>
>>>> > fa:16:3e:0a:86:4d    e65bd8e9-5f95-4eb2-a316-97e86fbdb9b6
>>>>
>>>>
>>>> > snat             Y.Y.Y.Y                      192.168.0.0/24
>>>>
>>>>
>>>> >
>>>>
>>>>
>>>> >
>>>>
>>>>
>>>> > I replaced FIP with X.X.X.X and router IP with Y.Y.Y.Y
>>>>
>>>>
>>>> >
>>>>
>>>>
>>>> > When I remove * EXTERNAL_MAC* and *LOGICAL_PORT*, FIP works fine and
>>>> as it
>>>>
>>>>
>>>> > has to be, but traffic routes from a Controller node and it won't be
>>>>
>>>>
>>>> > distributed anymore.
>>>>
>>>>
>>>> >
>>>>
>>>>
>>>> > Any idea or suggestion would be grateful.
>>>>
>>>>
>>>> > Regards,
>>>>
>>>>
>>>> > Reza
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1834433
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> Slawek Kaplonski
>>>>
>>>>
>>>> Principal software engineer
>>>>
>>>>
>>>> Red Hat
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>>
>> ROMAN SAFRONOV
>>
>> SENIOR QE, OPENSTACK NETWORKING
>>
>> Red Hat <https://www.redhat.com/>
>>
>> Israel
>>
>> M: +972545433957
>>
>> <https://red.ht/sig>
>>
>>
>>
>
> --
Michał Nasiadka
mnasiadka at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/cbc02dfb/attachment.html>

From cohuck at redhat.com  Tue Sep  8 14:41:30 2020
From: cohuck at redhat.com (Cornelia Huck)
Date: Tue, 8 Sep 2020 16:41:30 +0200
Subject: device compatibility interface for live migration with assigned
 devices
In-Reply-To: <20200831044344.GB13784@joy-OptiPlex-7040>
References: <3a073222-dcfe-c02d-198b-29f6a507b2e1@redhat.com>
 <20200818091628.GC20215@redhat.com>
 <20200818113652.5d81a392.cohuck@redhat.com>
 <20200820003922.GE21172@joy-OptiPlex-7040>
 <20200819212234.223667b3@x1.home>
 <20200820031621.GA24997@joy-OptiPlex-7040>
 <20200825163925.1c19b0f0.cohuck@redhat.com>
 <20200826064117.GA22243@joy-OptiPlex-7040>
 <20200828154741.30cfc1a3.cohuck@redhat.com>
 <8f5345be73ebf4f8f7f51d6cdc9c2a0d8e0aa45e.camel@redhat.com>
 <20200831044344.GB13784@joy-OptiPlex-7040>
Message-ID: <20200908164130.2fe0d106.cohuck@redhat.com>

On Mon, 31 Aug 2020 12:43:44 +0800
Yan Zhao <yan.y.zhao at intel.com> wrote:

> On Fri, Aug 28, 2020 at 03:04:12PM +0100, Sean Mooney wrote:
> > On Fri, 2020-08-28 at 15:47 +0200, Cornelia Huck wrote:  
> > > On Wed, 26 Aug 2020 14:41:17 +0800
> > > Yan Zhao <yan.y.zhao at intel.com> wrote:
> > >   
> > > > previously, we want to regard the two mdevs created with dsa-1dwq x 30 and
> > > > dsa-2dwq x 15 as compatible, because the two mdevs consist equal resources.
> > > > 
> > > > But, as it's a burden to upper layer, we agree that if this condition
> > > > happens, we still treat the two as incompatible.
> > > > 
> > > > To fix it, either the driver should expose dsa-1dwq only, or the target
> > > > dsa-2dwq needs to be destroyed and reallocated via dsa-1dwq x 30.  
> > > 
> > > AFAIU, these are mdev types, aren't they? So, basically, any management
> > > software needs to take care to use the matching mdev type on the target
> > > system for device creation?  
> > 
> > or just do the simple thing of use the same mdev type on the source and dest.
> > matching mdevtypes is not nessiarly trivial. we could do that but we woudl have
> > to do that in python rather then sql so it would be slower to do at least today.
> > 
> > we dont currently have the ablity to say the resouce provider must have 1 of these
> > set of traits. just that we must have a specific trait. this is a feature we have
> > disucssed a couple of times and delayed untill we really really need it but its not out
> > of the question that we could add it for this usecase. i suspect however we would do exact
> > match first and explore this later after the inital mdev migration works.  
> 
> Yes, I think it's good.
> 
> still, I'd like to put it more explicitly to make ensure it's not missed:
> the reason we want to specify compatible_type as a trait and check
> whether target compatible_type is the superset of source
> compatible_type is for the consideration of backward compatibility.
> e.g.
> an old generation device may have a mdev type xxx-v4-yyy, while a newer
> generation  device may be of mdev type xxx-v5-yyy.
> with the compatible_type traits, the old generation device is still
> able to be regarded as compatible to newer generation device even their
> mdev types are not equal.

If you want to support migration from v4 to v5, can't the (presumably
newer) driver that supports v5 simply register the v4 type as well, so
that the mdev can be created as v4? (Just like QEMU versioned machine
types work.)



From alexis.deberg at ubisoft.com  Tue Sep  8 14:46:29 2020
From: alexis.deberg at ubisoft.com (Alexis Deberg)
Date: Tue, 8 Sep 2020 14:46:29 +0000
Subject: [neutron] Flow drop on agent restart with openvswitch firewall driver
Message-ID: <DM6PR17MB36108DF4942A4B8C72675D73F2290@DM6PR17MB3610.namprd17.prod.outlook.com>

Hi All,

I'm looking for ideas as we need to upgrade our Neutron deployment and it looks like it would impact workloads a bit much for now to do so and i'm no master of the neutron code...

We're running Neutron 14.0.2 with ml2 plugin and firewall_driver set as openvswitch. drop_flows_on_start is default False.

Reading at some old bug reports my understanding was that a restart of the neutron-openvswitch-agent should not impact existing flows and be seamless, but this is not what I'm experiencing as I see some temporary drop(s) around when ovs-fctl del-flows/add-flows is called on br-int (either east-west traffic or north-south). I tried switching to iptables_hybrid driver instead and I don't see the issue in that case.

e.g when a wget download is happening on an instance while the agent is restarting, I see the following: 2020-09-08 14:26:09 (12.2 MB/s) - Read error at byte 146971864/7416743936 (Success). Retrying

I'm a bit lot so i'm wondering if that's expected/known behavior, if a workaround is possible....

Let me know if a bug report might be a better place to dig deeper or not or if you want additional information... or if I missed a closed bug.

Thanks !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/7f576de7/attachment-0001.html>

From yuuta.takanashi at aol.com  Tue Sep  8 16:24:38 2020
From: yuuta.takanashi at aol.com (yuuta.takanashi at aol.com)
Date: Tue, 8 Sep 2020 16:24:38 +0000 (UTC)
Subject: Tripleo Standalone Deployment Issues - Reproduceable
References: <432018575.3487968.1599582278275.ref@mail.yahoo.com>
Message-ID: <432018575.3487968.1599582278275@mail.yahoo.com>

Hi Experts, 

I am facing on below issues while following guide of Tripleo Standalone Deployment: 
https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/standalone.html
Issue 1) Using custom domain will cause vm instantiation error after machine reboot


Description
===========
After Openstack installed, it's adding centos82.localdomain on /etc/hosts and causing OVN Southbound (ovn-sbctl show) using this centos82.localdomain. But after the machine rebooted, "ovn-sbctl show" is showing the correct fqdn: centos82.domain.tld, and it is causing VM instantiate error (Refusing to bind port <UUID> due to no OVN chassis for host: centos82.localdomain).


Steps to reproduce
==================
Base installation: https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/standalone.html
Tested on Centos 8.2 latest, tested several times on Train and Ussuri. 
100% reproduceable. 


Set the custom FQDN hostname

hostnamectl set-hostname centos82.domain.tld
hostnamectl set-hostname centos82.domain.tld --transient    (also tested with or without this line)

cat /etc/hosts
127.0.0.1       centos82.domain.tld localhost localhost.localdomain localhost4 localhost4.localdomain4
::1             centos82.domain.tld localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.156.82  centos82.domain.tld

also tested with

hostnamectl set-hostname centos82.domain.tld
hostnamectl set-hostname centos82.domain.tld --transient    (also tested with or without this line)
cat /etc/hosts
127.0.0.1       localhost localhost.localdomain localhost4 localhost4.localdomain4
::1             localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.156.82  centos82.domain.tld centos82

also tested with

hostnamectl set-hostname centos82.domain.tld
hostnamectl set-hostname centos82.domain.tld --transient    (also tested with or without this line)
cat /etc/hosts
127.0.0.1       localhost localhost.localdomain localhost4 localhost4.localdomain4
::1             localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.156.82  centos82.domain.tld


Part of standalone_parameters.yaml for domain: 
  # domain name used by the host
  NeutronDnsDomain: domain.tld        



Follow the guide to install (without ceph)

(Issue 1B) with ceph was having another error, just tested once on Train:
fatal: [undercloud]: FAILED! => {
    "ceph_ansible_std_out_err": [
        "Using /home/stack/standalone-ansible-huva1ccw/ansible.cfg as config file",
        "ERROR! the playbook: /usr/share/ceph-ansible/site-container.yml.sample could not be found"
    ],
    "failed_when_result": true
}




All will be installed successfully, and able to instantiate VMs and these VMs are able to ping to each other. 

Then do "reboot" on this standalone host/server. 

Do instantiate a new VM, and then this new VM status will be ERROR. 

On Neutron logs: 
Refusing to bind port <UUID> due to no OVN chassis for host: centos82.localdomain bind_port



Found the cause on OVN: 

Previous after installed (before reboot)

[root at centos82 /]# ovn-sbctl show
Chassis "<UUID>"
    hostname: centos82.localdomain
    Encap geneve
        ip: "192.168.156.82"
        options: {csum="true"}
[root at centos82 /]# 


After reboot

[root at centos82 /]# ovn-sbctl show
Chassis "<UUID>"
    hostname: centos82.domain.tld
    Encap geneve
        ip: "192.168.156.82"
        options: {csum="true"}
[root at centos82 /]# 


So that the OVN seems could not bind the port to different hostname (that already changed). 


Environment
===========
1. Exact version of OpenStack you are running: Any, tested Train and Ussuri
2. Centos 8.2 latest update
Others (without ceph): https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/standalone.html



Workaround
==========
Don't use custom domain, instead use "localdomain" as on the document

hostnamectl set-hostname centos82.localdomain

[root at centos82 ~]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.156.82 centos82.localdomain centos82

Deploy, test instantiate, reboot, test instantiate, and working perfectly fine. 


Question: For custom domain, where did I do wrongly? Is it expected or kind of bugs?





Issue 2) This is not Openstack issue, perhaps bugs or perhaps my issue, but it is still related with the topic on Tripleo Standalone Deployment.

On the same Standalone Deployment Guide (https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/standalone.html)
with Centos 7.6 or 7.7 with "python-tripleoclient" and this has dependency of Docker 1.13.1, encounters kind of Dns querying issue which I posted here: https://serverfault.com/questions/1032816/centos-7-and-docker-1-13-1-error-timeout-exceeded-while-awaiting-headers-no
Perhaps if anybody knows how to resolve this.
Also, just wondering is there any way for "python-tripleoclient" to use newer docker-ce 1.19.x instead of docker 1.13.1?




ThanksBest regards, 
TY

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/73efa24c/attachment.html>

From johfulto at redhat.com  Tue Sep  8 18:19:03 2020
From: johfulto at redhat.com (John Fulton)
Date: Tue, 8 Sep 2020 14:19:03 -0400
Subject: Tripleo Standalone Deployment Issues - Reproduceable
In-Reply-To: <432018575.3487968.1599582278275@mail.yahoo.com>
References: <432018575.3487968.1599582278275.ref@mail.yahoo.com>
 <432018575.3487968.1599582278275@mail.yahoo.com>
Message-ID: <CAE66OMC1gZVpa96dCnWzyAWOV6nuaAzzbtC3WZV_ZUSJ2xpWvQ@mail.gmail.com>

On Tue, Sep 8, 2020 at 2:07 PM <yuuta.takanashi at aol.com> wrote:
>
> Hi Experts,
>
> I am facing on below issues while following guide of Tripleo Standalone Deployment:
> https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/standalone.html
>
> Issue 1) Using custom domain will cause vm instantiation error after machine reboot
>
>
> Description
> ===========
> After Openstack installed, it's adding centos82.localdomain on /etc/hosts and causing OVN Southbound (ovn-sbctl show) using this centos82.localdomain. But after the machine rebooted, "ovn-sbctl show" is showing the correct fqdn: centos82.domain.tld, and it is causing VM instantiate error (Refusing to bind port <UUID> due to no OVN chassis for host: centos82.localdomain).
>
>
> Steps to reproduce
> ==================
> Base installation: https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/standalone.html
> Tested on Centos 8.2 latest, tested several times on Train and Ussuri.
> 100% reproduceable.
>
>
> Set the custom FQDN hostname
>
> hostnamectl set-hostname centos82.domain.tld
> hostnamectl set-hostname centos82.domain.tld --transient    (also tested with or without this line)
>
> cat /etc/hosts
> 127.0.0.1       centos82.domain.tld localhost localhost.localdomain localhost4 localhost4.localdomain4
> ::1             centos82.domain.tld localhost localhost.localdomain localhost6 localhost6.localdomain6
> 192.168.156.82  centos82.domain.tld
>
> also tested with
>
> hostnamectl set-hostname centos82.domain.tld
> hostnamectl set-hostname centos82.domain.tld --transient    (also tested with or without this line)
>
> cat /etc/hosts
> 127.0.0.1       localhost localhost.localdomain localhost4 localhost4.localdomain4
> ::1             localhost localhost.localdomain localhost6 localhost6.localdomain6
> 192.168.156.82  centos82.domain.tld centos82
>
> also tested with
>
> hostnamectl set-hostname centos82.domain.tld
> hostnamectl set-hostname centos82.domain.tld --transient    (also tested with or without this line)
>
> cat /etc/hosts
> 127.0.0.1       localhost localhost.localdomain localhost4 localhost4.localdomain4
> ::1             localhost localhost.localdomain localhost6 localhost6.localdomain6
> 192.168.156.82  centos82.domain.tld
>
>
> Part of standalone_parameters.yaml for domain:
>   # domain name used by the host
>   NeutronDnsDomain: domain.tld
>
>
>
> Follow the guide to install (without ceph)
>
> (Issue 1B) with ceph was having another error, just tested once on Train:
> fatal: [undercloud]: FAILED! => {
>     "ceph_ansible_std_out_err": [
>         "Using /home/stack/standalone-ansible-huva1ccw/ansible.cfg as config file",
>         "ERROR! the playbook: /usr/share/ceph-ansible/site-container.yml.sample could not be found"
>     ],
>     "failed_when_result": true
> }

It looks like ceph-ansible was executed by tripleo but that
ceph-ansible isn't installed. Either install ceph-ansible or ensure
your deployment command does not include:

  -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml
\

  John

>
>
>
>
> All will be installed successfully, and able to instantiate VMs and these VMs are able to ping to each other.
>
> Then do "reboot" on this standalone host/server.
>
> Do instantiate a new VM, and then this new VM status will be ERROR.
>
> On Neutron logs:
> Refusing to bind port <UUID> due to no OVN chassis for host: centos82.localdomain bind_port
>
>
>
> Found the cause on OVN:
>
> Previous after installed (before reboot)
>
> [root at centos82 /]# ovn-sbctl show
> Chassis "<UUID>"
>     hostname: centos82.localdomain
>     Encap geneve
>         ip: "192.168.156.82"
>         options: {csum="true"}
> [root at centos82 /]#
>
>
> After reboot
>
> [root at centos82 /]# ovn-sbctl show
> Chassis "<UUID>"
>     hostname: centos82.domain.tld
>     Encap geneve
>         ip: "192.168.156.82"
>         options: {csum="true"}
> [root at centos82 /]#
>
>
> So that the OVN seems could not bind the port to different hostname (that already changed).
>
>
> Environment
> ===========
> 1. Exact version of OpenStack you are running: Any, tested Train and Ussuri
> 2. Centos 8.2 latest update
> Others (without ceph): https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/standalone.html
>
>
>
> Workaround
> ==========
> Don't use custom domain, instead use "localdomain" as on the document
>
> hostnamectl set-hostname centos82.localdomain
>
> [root at centos82 ~]# cat /etc/hosts
> 127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
> ::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
> 192.168.156.82 centos82.localdomain centos82
>
> Deploy, test instantiate, reboot, test instantiate, and working perfectly fine.
>
>
> Question: For custom domain, where did I do wrongly? Is it expected or kind of bugs?
>
>
>
>
>
> Issue 2) This is not Openstack issue, perhaps bugs or perhaps my issue, but it is still related with the topic on Tripleo Standalone Deployment.
>
> On the same Standalone Deployment Guide (https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/deployment/standalone.html)
> with Centos 7.6 or 7.7 with "python-tripleoclient" and this has dependency of Docker 1.13.1, encounters kind of Dns querying issue which I posted here: https://serverfault.com/questions/1032816/centos-7-and-docker-1-13-1-error-timeout-exceeded-while-awaiting-headers-no
> Perhaps if anybody knows how to resolve this.
> Also, just wondering is there any way for "python-tripleoclient" to use newer docker-ce 1.19.x instead of docker 1.13.1?
>
>
>
>
> Thanks
> Best regards,
> TY
>



From dwakefi2 at gmu.edu  Tue Sep  8 18:51:20 2020
From: dwakefi2 at gmu.edu (Thomas Wakefield)
Date: Tue, 8 Sep 2020 18:51:20 +0000
Subject: Kolla-ansible ironic 
Message-ID: <A902C99C-08E1-403B-BF55-C940136DB89A@gmu.edu>

All-

We are new to using OpenStack and are testing out Kolla-ansible with hopes of using Ironic as a deployment tool.  Our issue is we can’t use the openstack baremetal command, it’s not found after deployment.  Our current test environment is built using Train on CentOS 7.  And all other basic OpenStack functionality seems to be working with our Kolla install (nova, glance, horizon, etc).

We followed these docs, https://docs.openstack.org/kolla-ansible/train/reference/bare-metal/ironic-guide.html , but when we get to running any “openstack baremetal” commands we don’t seem to have the baremetal commands available in openstack.

Globals.yml lines that should be relavent:

enable_horizon_ironic: "{{ enable_ironic | bool }}"
enable_ironic: "yes"
enable_ironic_ipxe: "yes"
enable_ironic_neutron_agent: "{{ enable_neutron | bool and enable_ironic | bool }}"
enable_ironic_pxe_uefi: "no"
#enable_iscsid: "{{ (enable_cinder | bool and enable_cinder_backend_iscsi | bool) or enable_ironic | bool }}"
ironic_dnsmasq_interface: "em1"
# The following value must be set when enabling ironic,
ironic_dnsmasq_dhcp_range: "192.168.2.230,192.168.2.239"
ironic_dnsmasq_boot_file: "pxelinux.0"
ironic_cleaning_network: "demo-net"


Ironic is listed as an installed service, but you can see the baremetal commands are not found:
root at orc-os5:~## openstack service list
+----------------------------------+------------------+-------------------------+
| ID                               | Name             | Type                    |
+----------------------------------+------------------+-------------------------+
| 0e5119acbf384714ab11520fadce36bb | nova_legacy      | compute_legacy          |
| 2ed83015047249f38b782901e03bcfc1 | ironic-inspector | baremetal-introspection |
| 5d7aabf15bdc415387fac54fa1ca21df | ironic           | baremetal               |
| 6d05cdce019347e9940389abed959ffb | neutron          | network                 |
| 7d9485969e504b2e90273af75e9b1713 | cinderv3         | volumev3                |
| a11dc04e83ed4d9ba65474b9de947d1b | keystone         | identity                |
| ad0c2db47b414b34b86a5f6a5aca597c | glance           | image                   |
| dcbbc90813714c989b82bece1c0d9d9f | nova             | compute                 |
| de0ee6b55486495296516e07d2e9e97c | heat             | orchestration           |
| df605d671d88496d91530fbc01573589 | cinderv2         | volumev2                |
| e211294ca78a418ea34d9c29d86b05f1 | placement        | placement               |
| f62ba90bc0b94cb9b3d573605f800a1f | heat-cfn         | cloudformation          |
+----------------------------------+------------------+-------------------------+
root at orc-os5:~## openstack baremetal
openstack: 'baremetal' is not an openstack command. See 'openstack --help'.
Did you mean one of these?
  credential create
  credential delete
  credential list
  credential set
  credential show


Is there anything else that needs configured to activate ironic?

Thanks in advance.
Tom

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/fd6b37bf/attachment.html>

From pierre at stackhpc.com  Tue Sep  8 19:10:34 2020
From: pierre at stackhpc.com (Pierre Riteau)
Date: Tue, 8 Sep 2020 21:10:34 +0200
Subject: Kolla-ansible ironic
In-Reply-To: <A902C99C-08E1-403B-BF55-C940136DB89A@gmu.edu>
References: <A902C99C-08E1-403B-BF55-C940136DB89A@gmu.edu>
Message-ID: <CA+ny2sz5gCiCzv1d47Xx1oEZNdgBqPAfydQ-cNdbq9m8X_b+AA@mail.gmail.com>

The openstack CLI only includes support for core OpenStack services.
Support for additional services is implemented through plugins, generally
included in the client package of each service. Run `pip install
python-ironicclient` and you will get access to `openstack baremetal`
commands.

On Tue, 8 Sep 2020 at 20:51, Thomas Wakefield <dwakefi2 at gmu.edu> wrote:

> All-
>
>
> We are new to using OpenStack and are testing out Kolla-ansible with hopes
> of using Ironic as a deployment tool.  Our issue is we can’t use the
> openstack baremetal command, it’s not found after deployment.  Our current
> test environment is built using Train on CentOS 7.  And all other basic
> OpenStack functionality seems to be working with our Kolla install (nova,
> glance, horizon, etc).
>
>
>
> We followed these docs,
> https://docs.openstack.org/kolla-ansible/train/reference/bare-metal/ironic-guide.html ,
> but when we get to running any “openstack baremetal” commands we don’t seem
> to have the baremetal commands available in openstack.
>
>
>
> Globals.yml lines that should be relavent:
>
>
>
> enable_horizon_*ironic*: "{{ enable_*ironic* | bool }}"
>
> enable_*ironic*: "yes"
>
> enable_*ironic*_ipxe: "yes"
>
> enable_*ironic*_neutron_agent: "{{ enable_neutron | bool and enable_
> *ironic* | bool }}"
>
> enable_*ironic*_pxe_uefi: "no"
>
> #enable_iscsid: "{{ (enable_cinder | bool and enable_cinder_backend_iscsi
> | bool) or enable_*ironic* | bool }}"
>
> *ironic*_dnsmasq_interface: "em1"
>
> # The following value must be set when enabling *ironic*,
>
> *ironic*_dnsmasq_dhcp_range: "192.168.2.230,192.168.2.239"
>
> *ironic*_dnsmasq_boot_file: "pxelinux.0"
>
> *ironic*_cleaning_network: "demo-net"
>
>
>
>
>
> Ironic is listed as an installed service, but you can see the baremetal
> commands are not found:
>
> root at orc-os5:~## openstack service list
>
>
> +----------------------------------+------------------+-------------------------+
>
> | ID                               | Name             | Type
>       |
>
>
> +----------------------------------+------------------+-------------------------+
>
> | 0e5119acbf384714ab11520fadce36bb | nova_legacy      | compute_legacy
>       |
>
> | 2ed83015047249f38b782901e03bcfc1 | ironic-inspector |
> baremetal-introspection |
>
> | 5d7aabf15bdc415387fac54fa1ca21df | ironic           | baremetal
>       |
>
> | 6d05cdce019347e9940389abed959ffb | neutron          | network
>       |
>
> | 7d9485969e504b2e90273af75e9b1713 | cinderv3         | volumev3
>       |
>
> | a11dc04e83ed4d9ba65474b9de947d1b | keystone         | identity
>       |
>
> | ad0c2db47b414b34b86a5f6a5aca597c | glance           | image
>       |
>
> | dcbbc90813714c989b82bece1c0d9d9f | nova             | compute
>       |
>
> | de0ee6b55486495296516e07d2e9e97c | heat             | orchestration
>       |
>
> | df605d671d88496d91530fbc01573589 | cinderv2         | volumev2
>       |
>
> | e211294ca78a418ea34d9c29d86b05f1 | placement        | placement
>       |
>
> | f62ba90bc0b94cb9b3d573605f800a1f | heat-cfn         | cloudformation
>       |
>
>
> +----------------------------------+------------------+-------------------------+
>
> root at orc-os5:~## openstack baremetal
>
> openstack: 'baremetal' is not an openstack command. See 'openstack --help'.
>
> Did you mean one of these?
>
>   credential create
>
>   credential delete
>
>   credential list
>
>   credential set
>
>   credential show
>
>
>
>
>
> Is there anything else that needs configured to activate ironic?
>
>
>
> Thanks in advance.
>
> Tom
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/ab7c166b/attachment-0001.html>

From dwakefi2 at gmu.edu  Tue Sep  8 19:14:59 2020
From: dwakefi2 at gmu.edu (Thomas Wakefield)
Date: Tue, 8 Sep 2020 19:14:59 +0000
Subject: Kolla-ansible ironic
In-Reply-To: <CA+ny2sz5gCiCzv1d47Xx1oEZNdgBqPAfydQ-cNdbq9m8X_b+AA@mail.gmail.com>
References: <A902C99C-08E1-403B-BF55-C940136DB89A@gmu.edu>
 <CA+ny2sz5gCiCzv1d47Xx1oEZNdgBqPAfydQ-cNdbq9m8X_b+AA@mail.gmail.com>
Message-ID: <A0FD981B-9C47-4E8C-B587-6F34FC5471F0@gmu.edu>

Pierre-
Huge thanks, that seems to have solved it.

-Tom


From: Pierre Riteau <pierre at stackhpc.com>
Date: Tuesday, September 8, 2020 at 3:11 PM
To: Thomas Wakefield <dwakefi2 at gmu.edu>
Cc: "openstack-discuss at lists.openstack.org" <openstack-discuss at lists.openstack.org>
Subject: Re: Kolla-ansible ironic

The openstack CLI only includes support for core OpenStack services. Support for additional services is implemented through plugins, generally included in the client package of each service. Run `pip install python-ironicclient` and you will get access to `openstack baremetal` commands.

On Tue, 8 Sep 2020 at 20:51, Thomas Wakefield <dwakefi2 at gmu.edu<mailto:dwakefi2 at gmu.edu>> wrote:
All-

We are new to using OpenStack and are testing out Kolla-ansible with hopes of using Ironic as a deployment tool.  Our issue is we can’t use the openstack baremetal command, it’s not found after deployment.  Our current test environment is built using Train on CentOS 7.  And all other basic OpenStack functionality seems to be working with our Kolla install (nova, glance, horizon, etc).

We followed these docs, https://docs.openstack.org/kolla-ansible/train/reference/bare-metal/ironic-guide.html , but when we get to running any “openstack baremetal” commands we don’t seem to have the baremetal commands available in openstack.

Globals.yml lines that should be relavent:

enable_horizon_ironic: "{{ enable_ironic | bool }}"
enable_ironic: "yes"
enable_ironic_ipxe: "yes"
enable_ironic_neutron_agent: "{{ enable_neutron | bool and enable_ironic | bool }}"
enable_ironic_pxe_uefi: "no"
#enable_iscsid: "{{ (enable_cinder | bool and enable_cinder_backend_iscsi | bool) or enable_ironic | bool }}"
ironic_dnsmasq_interface: "em1"
# The following value must be set when enabling ironic,
ironic_dnsmasq_dhcp_range: "192.168.2.230,192.168.2.239"
ironic_dnsmasq_boot_file: "pxelinux.0"
ironic_cleaning_network: "demo-net"


Ironic is listed as an installed service, but you can see the baremetal commands are not found:
root at orc-os5:~## openstack service list
+----------------------------------+------------------+-------------------------+
| ID                               | Name             | Type                    |
+----------------------------------+------------------+-------------------------+
| 0e5119acbf384714ab11520fadce36bb | nova_legacy      | compute_legacy          |
| 2ed83015047249f38b782901e03bcfc1 | ironic-inspector | baremetal-introspection |
| 5d7aabf15bdc415387fac54fa1ca21df | ironic           | baremetal               |
| 6d05cdce019347e9940389abed959ffb | neutron          | network                 |
| 7d9485969e504b2e90273af75e9b1713 | cinderv3         | volumev3                |
| a11dc04e83ed4d9ba65474b9de947d1b | keystone         | identity                |
| ad0c2db47b414b34b86a5f6a5aca597c | glance           | image                   |
| dcbbc90813714c989b82bece1c0d9d9f | nova             | compute                 |
| de0ee6b55486495296516e07d2e9e97c | heat             | orchestration           |
| df605d671d88496d91530fbc01573589 | cinderv2         | volumev2                |
| e211294ca78a418ea34d9c29d86b05f1 | placement        | placement               |
| f62ba90bc0b94cb9b3d573605f800a1f | heat-cfn         | cloudformation          |
+----------------------------------+------------------+-------------------------+
root at orc-os5:~## openstack baremetal
openstack: 'baremetal' is not an openstack command. See 'openstack --help'.
Did you mean one of these?
  credential create
  credential delete
  credential list
  credential set
  credential show


Is there anything else that needs configured to activate ironic?

Thanks in advance.
Tom

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/11d10142/attachment.html>

From pierre at stackhpc.com  Tue Sep  8 19:18:23 2020
From: pierre at stackhpc.com (Pierre Riteau)
Date: Tue, 8 Sep 2020 21:18:23 +0200
Subject: [blazar] Wallaby PTG
Message-ID: <CA+ny2sw3to32O1rw5vHPULgfP4e4wNiVeKW-epUtrWqh2Q8Z6Q@mail.gmail.com>

Hello,

As mentioned in a recent IRC meeting [1], I likely won't be able to attend
the PTG this year.
Tetsuro Nakamura who is the only other active core reviewer at the moment
said he won't have time either.

Given that we still have lots of pending tasks on Blazar from the last PTG
[2], I propose that we don't plan to meet during the PTG in October 2020.

Best wishes,
Pierre Riteau (priteau)

[1]
http://eavesdrop.openstack.org/meetings/blazar/2020/blazar.2020-08-18-09.00.log.html
[2] https://etherpad.opendev.org/p/blazar-ptg-victoria
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200908/7c1f282c/attachment-0001.html>

From sorrison at gmail.com  Tue Sep  8 22:36:19 2020
From: sorrison at gmail.com (Sam Morrison)
Date: Wed, 9 Sep 2020 08:36:19 +1000
Subject: [neutron][networking-midonet] Maintainers needed
In-Reply-To: <AB1C90C1-96EE-4D1B-AA3B-63A565A41B61@gmail.com>
References: <0AC5AC07-E97E-43CC-B344-A3E992B8CCA4@netways.de>
 <610412AF-AADF-44BD-ABA2-BA289B7C8F8A@redhat.com>
 <5E2F5826-559E-42E9-84C5-FA708E5A122A@gmail.com>
 <CAH=wFzS6usQqLeUtZ3iwyzw5f+ph38eaHCEQ0xsKo2ZzMREBgA@mail.gmail.com>
 <43C4AF2B-C5C0-40EB-B621-AC6799471D01@gmail.com>
 <CAH=wFzRmjbCy5vQOrpu=rX4Be-_GYPOE602kDShvV-ZtX+eF6g@mail.gmail.com>
 <92959221-0353-4D48-8726-8FE71AFEA652@gmail.com>
 <4D778DBF-F505-462F-B85D-0B372085FA72@gmail.com>
 <CAH=wFzRiJd=93cYsK5FJxJcmMb6eY-XDco1zQOfueMw-0s2Tcw@mail.gmail.com>
 <AB1C90C1-96EE-4D1B-AA3B-63A565A41B61@gmail.com>
Message-ID: <5B9D2CB0-8B81-4533-A072-9A51B4A44364@gmail.com>



> On 8 Sep 2020, at 3:13 pm, Sam Morrison <sorrison at gmail.com> wrote:
> 
> Hi Yamamoto,
> 
> 
>> On 4 Sep 2020, at 6:47 pm, Takashi Yamamoto <yamamoto at midokura.com <mailto:yamamoto at midokura.com>> wrote:
> 
>> i'm talking to our infra folks but it might take longer than i hoped.
>> if you or someone else can provide a public repo, it might be faster.
>> (i have looked at launchpad PPA while ago. but it didn't seem
>> straightforward given the complex build machinary in midonet.)
> 
> Yeah that’s no problem, I’ve set up a repo with the latest midonet debs in it and happy to use that for the time being.
> 
>> 
>>> 
>>> I’m not sure why the pep8 job is failing, it is complaining about pecan which makes me think this is an issue with neutron itself? Kinda stuck on this one, it’s probably something silly.
>> 
>> probably.
> 
> Yeah this looks like a neutron or neutron-lib issue
> 
>> 
>>> 
>>> For the py3 unit tests they are now failing due to db migration errors in tap-as-a-service, l2-gateway and vpnaas issues I think caused by neutron getting rid of the liberty alembic branch and so we need to squash these on these projects too.
>> 
>> this thing? https://review.opendev.org/#/c/749866/ <https://review.opendev.org/#/c/749866/>
> 
> Yeah that fixed that issue.
> 
> 
> I have been working to get everything fixed in this review [1]
> 
> The pep8 job is working but not in the gate due to neutron issues [2]
> The py36/py38 jobs have 2 tests failing both relating to tap-as-a-service which I don’t really have any idea about, never used it. [3]

These are failing because of this patch on tap-as-a-service 
https://opendev.org/x/tap-as-a-service/commit/8332a396b1b046eb370c0cb377d836d0c6b6d6ca

Really have no idea how this works, does anyone use tap-as-a-service with midonet and can help me fix it, else I’m wondering if we disable tests for taas and make it an unsupported feature for now.

Sam



> The tempest aio job is working well now, I’m not sure what tempest tests were run before but it’s just doing what ever is the default at the moment.
> The tempest multinode job isn’t working due to what I think is networking issues between the 2 nodes. I don’t really know what I’m doing here so any pointers would be helpful. [4]
> The grenade job is also failing because I also need to put these fixes on the stable/ussuri branch to make it work so will need to figure that out too
> 
> Cheers,
> Sam
> 
> [1] https://review.opendev.org/#/c/749857/ <https://review.opendev.org/#/c/749857/>
> [2] https://zuul.opendev.org/t/openstack/build/e94e873cbf0443c0a7f25ffe76b3b00b <https://zuul.opendev.org/t/openstack/build/e94e873cbf0443c0a7f25ffe76b3b00b>
> [3] https://b1a2669063d97482275a-410cecb8410320c66fb802e0a530979a.ssl.cf5.rackcdn.com/749857/18/check/openstack-tox-py36/0344651/testr_results.html <https://b1a2669063d97482275a-410cecb8410320c66fb802e0a530979a.ssl.cf5.rackcdn.com/749857/18/check/openstack-tox-py36/0344651/testr_results.html>
> [4] https://zuul.opendev.org/t/openstack/build/61f6dd3dc3d74a81b7a3f5968b4d8c72 <https://zuul.opendev.org/t/openstack/build/61f6dd3dc3d74a81b7a3f5968b4d8c72>
> 
> 
>> 
>>> 
>>> 
>>> 
>>> I can now start to look into the devstack zuul jobs.
>>> 
>>> Cheers,
>>> Sam
>>> 
>>> 
>>> [1] https://github.com/NeCTAR-RC/networking-midonet/commits/devstack <https://github.com/NeCTAR-RC/networking-midonet/commits/devstack>
>>> [2] https://github.com/midonet/midonet/pull/9 <https://github.com/midonet/midonet/pull/9>
>>> 
>>> 
>>> 
>>> 
>>>> On 1 Sep 2020, at 4:03 pm, Sam Morrison <sorrison at gmail.com <mailto:sorrison at gmail.com>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On 1 Sep 2020, at 2:59 pm, Takashi Yamamoto <yamamoto at midokura.com <mailto:yamamoto at midokura.com>> wrote:
>>>>> 
>>>>> hi,
>>>>> 
>>>>> On Tue, Sep 1, 2020 at 1:39 PM Sam Morrison <sorrison at gmail.com <mailto:sorrison at gmail.com>> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On 1 Sep 2020, at 11:49 am, Takashi Yamamoto <yamamoto at midokura.com <mailto:yamamoto at midokura.com>> wrote:
>>>>>>> 
>>>>>>> Sebastian, Sam,
>>>>>>> 
>>>>>>> thank you for speaking up.
>>>>>>> 
>>>>>>> as Slawek said, the first (and probably the biggest) thing is to fix the ci.
>>>>>>> the major part for it is to make midonet itself to run on ubuntu
>>>>>>> version used by the ci. (18.04, or maybe directly to 20.04)
>>>>>>> https://midonet.atlassian.net/browse/MNA-1344 <https://midonet.atlassian.net/browse/MNA-1344>
>>>>>>> iirc, the remaining blockers are:
>>>>>>> * libreswan (used by vpnaas)
>>>>>>> * vpp (used by fip64)
>>>>>>> maybe it's the easiest to drop those features along with their
>>>>>>> required components, if it's acceptable for your use cases.
>>>>>> 
>>>>>> We are running midonet-cluster and midolman on 18.04, we dropped those package dependencies from our ubuntu package to get it working.
>>>>>> 
>>>>>> We currently have built our own and host in our internal repo but happy to help putting this upstream somehow. Can we upload them to the midonet apt repo, does it still exist?
>>>>> 
>>>>> it still exists. but i don't think it's maintained well.
>>>>> let me find and ask someone in midokura who "owns" that part of infra.
>>>>> 
>>>>> does it also involve some package-related modifications to midonet repo, right?
>>>> 
>>>> 
>>>> Yes a couple, I will send up as as pull requests to https://github.com/midonet/midonet <https://github.com/midonet/midonet> today or tomorrow
>>>> 
>>>> Sam
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>>> 
>>>>>> I’m keen to do the work but might need a bit of guidance to get started,
>>>>>> 
>>>>>> Sam
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> alternatively you might want to make midonet run in a container. (so
>>>>>>> that you can run it with older ubuntu, or even a container trimmed for
>>>>>>> JVM)
>>>>>>> there were a few attempts to containerize midonet.
>>>>>>> i think this is the latest one: https://github.com/midonet/midonet-docker <https://github.com/midonet/midonet-docker>
>>>>>>> 
>>>>>>> On Fri, Aug 28, 2020 at 7:10 AM Sam Morrison <sorrison at gmail.com <mailto:sorrison at gmail.com>> wrote:
>>>>>>>> 
>>>>>>>> We (Nectar Research Cloud) use midonet heavily too, it works really well and we haven’t found another driver that works for us. We tried OVN but it just doesn’t scale to the size of environment we have.
>>>>>>>> 
>>>>>>>> I’m happy to help too.
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> Sam
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 31 Jul 2020, at 2:06 am, Slawek Kaplonski <skaplons at redhat.com <mailto:skaplons at redhat.com>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> Thx Sebastian for stepping in to maintain the project. That is great news.
>>>>>>>>> I think that at the beginning You should do 2 things:
>>>>>>>>> - sync with Takashi Yamamoto (I added him to the loop) as he is probably most active current maintainer of this project,
>>>>>>>>> - focus on fixing networking-midonet ci which is currently broken - all scenario jobs aren’t working fine on Ubuntu 18.04 (and we are going to move to 20.04 in this cycle), migrate jobs to zuulv3 from the legacy ones and finally add them to the ci again,
>>>>>>>>> 
>>>>>>>>> I can of course help You with ci jobs if You need any help. Feel free to ping me on IRC or email (can be off the list).
>>>>>>>>> 
>>>>>>>>>> On 29 Jul 2020, at 15:24, Sebastian Saemann <Sebastian.Saemann at netways.de <mailto:Sebastian.Saemann at netways.de>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi Slawek,
>>>>>>>>>> 
>>>>>>>>>> we at NETWAYS are running most of our neutron networking on top of midonet and wouldn't be too happy if it gets deprecated and removed. So we would like to take over the maintainer role for this part.
>>>>>>>>>> 
>>>>>>>>>> Please let me know how to proceed and how we can be onboarded easily.
>>>>>>>>>> 
>>>>>>>>>> Best regards,
>>>>>>>>>> 
>>>>>>>>>> Sebastian
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Sebastian Saemann
>>>>>>>>>> Head of Managed Services
>>>>>>>>>> 
>>>>>>>>>> NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
>>>>>>>>>> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
>>>>>>>>>> CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB25207
>>>>>>>>>> https://netways.de <https://netways.de/> | sebastian.saemann at netways.de <mailto:sebastian.saemann at netways.de>
>>>>>>>>>> 
>>>>>>>>>> ** NETWAYS Web Services - https://nws.netways.de <https://nws.netways.de/> **
>>>>>>>>> 
>>>>>>>>> —
>>>>>>>>> Slawek Kaplonski
>>>>>>>>> Principal software engineer
>>>>>>>>> Red Hat
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200909/3b2f0065/attachment.html>

From gmann at ghanshyammann.com  Tue Sep  8 22:56:05 2020
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Tue, 08 Sep 2020 17:56:05 -0500
Subject: [all][tc][goals] Migrate CI/CD jobs to new Ubuntu LTS Focal:
 Week R-4 Update
In-Reply-To: <17468f8f785.1123a07e6307801.3844845549431858647@ghanshyammann.com>
References: <17468f8f785.1123a07e6307801.3844845549431858647@ghanshyammann.com>
Message-ID: <1746feef403.c41c848411058.2421030943223377212@ghanshyammann.com>

Updates:
After working more on failing one today and listing the blocking one, I think we are good to switch tox based testing today
and discuss the integration testing switch tomorrow in TC office hours. 

> * Part1: Migrating tox base job tomorrow (8th Sept):
 
I have checked it again and fixed many repos that are up for review and merge. Most python clients are already fixed
or their fixes are up for merge so they can make it before the feature freeze on 10th. If any repo is broken then it will be pretty quick
to fix by lower constraint bump (see the example under https://review.opendev.org/#/q/topic:migrate-to-focal)

Even if any of the fixes miss the victoria release then those can be backported easily. I am opening the tox base jobs migration to merge: 
 - All patches in this series https://review.opendev.org/#/c/738328/


 > * Part2: Migrating devstack/tempest  base job on 10th sept:

We have three blocking open bugs here so I would like to discuss it in tomorrow's TC office hour also about how to proceed on this.

1. Nova: https://bugs.launchpad.net/nova/+bug/1882521  (https://bugs.launchpad.net/qemu/+bug/1894804)
2. Barbican: https://storyboard.openstack.org/#!/story/2007732
3. Ceilometer: https://storyboard.openstack.org/#!/story/2008121


-gmann


 ---- On Mon, 07 Sep 2020 09:29:40 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > Hello Everyone,
 > 
 > Please find the week R-4 updates on 'Ubuntu Focal migration' community goal. Its time to force the base jobs migration which can
 > break the projects gate if not yet taken care of. Read below for the plan.
 > 
 > Tracking: https://storyboard.openstack.org/#!/story/2007865
 > 
 > Progress:
 > =======
 > * We are close to V-3 release and this is time we have to complete this migration otherwise doing it in RC period can add
 > unnecessary and last min delay. I am going to plan this migration in two-part. This will surely break some projects gate
 > which is not yet finished the migration but we have to do at some time. Please let me know if any objection to the below
 > plan.
 > 
 > * Part1: Migrating tox base job tomorrow (8th Sept):
 > 
 > ** I am going to open tox base jobs migration (doc, unit, functional, lower-constraints etc) to merge by tomorrow. which is this
 > series (all base patches of this):  https://review.opendev.org/#/c/738328/ . 
 > 
 > **There are few repos still failing on requirements lower-constraints job specifically which I tried my best to fix as many as possible.
 >  Many are ready to merge also. Please merge or work on your projects repo testing before that or fix on priority if failing.
 > 
 > * Part2: Migrating devstack/tempest  base job on 10th sept:
 > 
 > * We have few open bugs for this which are not yet resolved, we will see how it goes but the current plan is to migrate by 10th Sept.
 > 
 > ** Bug#1882521
 > ** DB migration issues,
 > *** alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003
 > 
 > 
 > Testing Till now:
 > ============
 > * ~200 repos gate have been tested or fixed till now.
 > ** https://review.opendev.org/#/q/topic:migrate-to-focal+(status:abandoned+OR+status:merged)
 > 
 > * ~100 repos are under test and failing. Debugging and fixing are in progress (If you would like to help, please check your
 > project repos if I am late to fix them):
 > ** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open
 > 
 > * ~30repos fixes ready to merge:
 > ** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open+label%3AVerified%3E%3D1%2Czuul+NOT+label%3AWorkflow%3C%3D-1
 > 
 > 
 > Bugs Report:
 > ==========
 > 
 > 1. Bug#1882521. (IN-PROGRESS)
 > There is open bug for nova/cinder where three tempest tests are failing for
 > volume detach operation. There is no clear root cause found yet
 > -https://bugs.launchpad.net/cinder/+bug/1882521
 > We have skipped the tests in tempest base patch to proceed with the other
 > projects testing but this is blocking things for the migration.
 > 
 > 2. DB migration issues (IN-PROGRESS)
 > * alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003
 > 
 > 3. We encountered the nodeset name conflict with x/tobiko. (FIXED)
 > nodeset conflict is resolved now and devstack provides all focal nodes now.
 > 
 > 4. Bug#1886296. (IN-PROGRESS)
 > pyflakes till 2.1.0 is not compatible with python 3.8 which is the default python version
 > on ubuntu focal[1]. With pep8 job running on focal faces the issue and fail. We need to bump
 > the pyflakes to 2.1.1 as min version to run pep8 jobs on py3.8.
 > As of now, many projects are using old hacking version so I am explicitly adding pyflakes>=2.1.1
 > on the project side[2] but for the long term easy maintenance, I am doing it in 'hacking' requirements.txt[3]
 > nd will release a new hacking version. After that project can move to new hacking and do not need
 > to maintain pyflakes version compatibility.
 > 
 > 5. Bug#1886298. (IN-PROGRESS)
 > 'Markupsafe' 1.0 is not compatible with the latest version of setuptools[4],
 > We need to bump the lower-constraint for Markupsafe to 1.1.1 to make it work.
 > There are a few more issues[5] with lower-constraint jobs which I am debugging.
 > 
 > 
 > What work to be done on the project side:
 > ================================
 > This goal is more of testing the jobs on focal and fixing bugs if any otherwise
 > migrate jobs by switching the nodeset to focal node sets defined in devstack.
 > 
 > 1. Start a patch in your repo by making depends-on on either of below:
 > devstack base patch if you are using only devstack base jobs not tempest:
 > 
 > Depends-on: https://review.opendev.org/#/c/731207/
 > OR
 > tempest base patch if you are using the tempest base job (like devstack-tempest):
 > Depends-on: https://review.opendev.org/#/c/734700/
 > 
 > Both have depends-on on the series where I am moving unit/functional/doc/cover/nodejs tox jobs to focal. So
 > you can test the complete gate jobs(unit/functional/doc/integration) together.
 > This and its base patches - https://review.opendev.org/#/c/738328/
 > 
 > Example: https://review.opendev.org/#/c/738126/
 > 
 > 2. If none of your project jobs override the nodeset then above patch will be
 > testing patch(do not merge) otherwise change the nodeset to focal.
 > Example: https://review.opendev.org/#/c/737370/
 > 
 > 3. If the jobs are defined in branchless repo and override the nodeset then you need to override the branches
 > variant to adjust the nodeset so that those jobs run on Focal on victoria onwards only. If no nodeset
 > is overridden then devstack being branched and stable base job using bionic/xenial will take care of
 > this.
 > Example: https://review.opendev.org/#/c/744056/2
 > 
 > 4. If no updates need you can abandon the testing patch (https://review.opendev.org/#/c/744341/). If it need
 > updates then modify the same patch with proper commit msg, once it pass the gate then remove the Depends-On
 > so that you can merge your patch before base jobs are switched to focal. This way we make sure no gate downtime in
 > this migration.
 > Example: https://review.opendev.org/#/c/744056/1..2//COMMIT_MSG
 > 
 > Once we finish the testing on projects side and no failure then we will merge the devstack and tempest
 > base patches.
 > 
 > 
 > Important things to note:
 > ===================
 > * Do not forgot to add the story and task link to your patch so that we can track it smoothly.
 > * Use gerrit topic 'migrate-to-focal'
 > * Do not backport any of the patches.
 > 
 > 
 > References:
 > =========
 > Goal doc: https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-jobs-to-ubuntu-focal.html
 > Storyboard tracking: https://storyboard.openstack.org/#!/story/2007865
 > 
 > [1] https://github.com/PyCQA/pyflakes/issues/367
 > [2] https://review.opendev.org/#/c/739315/
 > [3] https://review.opendev.org/#/c/739334/
 > [4] https://github.com/pallets/markupsafe/issues/116
 > [5] https://zuul.opendev.org/t/openstack/build/7ecd9cf100194bc99b3b70fa1e6de032
 > 
 > -gmann
 > 
 > 


From katonalala at gmail.com  Wed Sep  9 06:52:22 2020
From: katonalala at gmail.com (Lajos Katona)
Date: Wed, 9 Sep 2020 08:52:22 +0200
Subject: [neutron][networking-midonet] Maintainers needed
In-Reply-To: <5B9D2CB0-8B81-4533-A072-9A51B4A44364@gmail.com>
References: <0AC5AC07-E97E-43CC-B344-A3E992B8CCA4@netways.de>
 <610412AF-AADF-44BD-ABA2-BA289B7C8F8A@redhat.com>
 <5E2F5826-559E-42E9-84C5-FA708E5A122A@gmail.com>
 <CAH=wFzS6usQqLeUtZ3iwyzw5f+ph38eaHCEQ0xsKo2ZzMREBgA@mail.gmail.com>
 <43C4AF2B-C5C0-40EB-B621-AC6799471D01@gmail.com>
 <CAH=wFzRmjbCy5vQOrpu=rX4Be-_GYPOE602kDShvV-ZtX+eF6g@mail.gmail.com>
 <92959221-0353-4D48-8726-8FE71AFEA652@gmail.com>
 <4D778DBF-F505-462F-B85D-0B372085FA72@gmail.com>
 <CAH=wFzRiJd=93cYsK5FJxJcmMb6eY-XDco1zQOfueMw-0s2Tcw@mail.gmail.com>
 <AB1C90C1-96EE-4D1B-AA3B-63A565A41B61@gmail.com>
 <5B9D2CB0-8B81-4533-A072-9A51B4A44364@gmail.com>
Message-ID: <CALg0jKksi08Tq-H7xXGiNXqO3W9rtioERr9y7mN_us24GN+mBQ@mail.gmail.com>

Hi,
Could you please  point to the issue with taas?

Regards
Lajos (lajoskatona)

Sam Morrison <sorrison at gmail.com> ezt írta (időpont: 2020. szept. 9., Sze,
0:44):

>
>
> On 8 Sep 2020, at 3:13 pm, Sam Morrison <sorrison at gmail.com> wrote:
>
> Hi Yamamoto,
>
>
> On 4 Sep 2020, at 6:47 pm, Takashi Yamamoto <yamamoto at midokura.com> wrote:
>
>
> i'm talking to our infra folks but it might take longer than i hoped.
> if you or someone else can provide a public repo, it might be faster.
> (i have looked at launchpad PPA while ago. but it didn't seem
> straightforward given the complex build machinary in midonet.)
>
>
> Yeah that’s no problem, I’ve set up a repo with the latest midonet debs in
> it and happy to use that for the time being.
>
>
>
> I’m not sure why the pep8 job is failing, it is complaining about pecan
> which makes me think this is an issue with neutron itself? Kinda stuck on
> this one, it’s probably something silly.
>
>
> probably.
>
>
> Yeah this looks like a neutron or neutron-lib issue
>
>
>
> For the py3 unit tests they are now failing due to db migration errors in
> tap-as-a-service, l2-gateway and vpnaas issues I think caused by neutron
> getting rid of the liberty alembic branch and so we need to squash these on
> these projects too.
>
>
> this thing? https://review.opendev.org/#/c/749866/
>
>
> Yeah that fixed that issue.
>
>
> I have been working to get everything fixed in this review [1]
>
> The pep8 job is working but not in the gate due to neutron issues [2]
> The py36/py38 jobs have 2 tests failing both relating to tap-as-a-service
> which I don’t really have any idea about, never used it. [3]
>
>
> These are failing because of this patch on tap-as-a-service
>
> https://opendev.org/x/tap-as-a-service/commit/8332a396b1b046eb370c0cb377d836d0c6b6d6ca
>
> Really have no idea how this works, does anyone use tap-as-a-service with
> midonet and can help me fix it, else I’m wondering if we disable tests for
> taas and make it an unsupported feature for now.
>
> Sam
>
>
>
> The tempest aio job is working well now, I’m not sure what tempest tests
> were run before but it’s just doing what ever is the default at the moment.
> The tempest multinode job isn’t working due to what I think is networking
> issues between the 2 nodes. I don’t really know what I’m doing here so any
> pointers would be helpful. [4]
> The grenade job is also failing because I also need to put these fixes on
> the stable/ussuri branch to make it work so will need to figure that out too
>
> Cheers,
> Sam
>
> [1] https://review.opendev.org/#/c/749857/
> [2]
> https://zuul.opendev.org/t/openstack/build/e94e873cbf0443c0a7f25ffe76b3b00b
> [3]
> https://b1a2669063d97482275a-410cecb8410320c66fb802e0a530979a.ssl.cf5.rackcdn.com/749857/18/check/openstack-tox-py36/0344651/testr_results.html
> [4]
> https://zuul.opendev.org/t/openstack/build/61f6dd3dc3d74a81b7a3f5968b4d8c72
>
>
>
>
>
>
> I can now start to look into the devstack zuul jobs.
>
> Cheers,
> Sam
>
>
> [1] https://github.com/NeCTAR-RC/networking-midonet/commits/devstack
> [2] https://github.com/midonet/midonet/pull/9
>
>
>
>
> On 1 Sep 2020, at 4:03 pm, Sam Morrison <sorrison at gmail.com> wrote:
>
>
>
> On 1 Sep 2020, at 2:59 pm, Takashi Yamamoto <yamamoto at midokura.com> wrote:
>
> hi,
>
> On Tue, Sep 1, 2020 at 1:39 PM Sam Morrison <sorrison at gmail.com> wrote:
>
>
>
>
> On 1 Sep 2020, at 11:49 am, Takashi Yamamoto <yamamoto at midokura.com>
> wrote:
>
> Sebastian, Sam,
>
> thank you for speaking up.
>
> as Slawek said, the first (and probably the biggest) thing is to fix the
> ci.
> the major part for it is to make midonet itself to run on ubuntu
> version used by the ci. (18.04, or maybe directly to 20.04)
> https://midonet.atlassian.net/browse/MNA-1344
> iirc, the remaining blockers are:
> * libreswan (used by vpnaas)
> * vpp (used by fip64)
> maybe it's the easiest to drop those features along with their
> required components, if it's acceptable for your use cases.
>
>
> We are running midonet-cluster and midolman on 18.04, we dropped those
> package dependencies from our ubuntu package to get it working.
>
> We currently have built our own and host in our internal repo but happy to
> help putting this upstream somehow. Can we upload them to the midonet apt
> repo, does it still exist?
>
>
> it still exists. but i don't think it's maintained well.
> let me find and ask someone in midokura who "owns" that part of infra.
>
> does it also involve some package-related modifications to midonet repo,
> right?
>
>
>
> Yes a couple, I will send up as as pull requests to
> https://github.com/midonet/midonet today or tomorrow
>
> Sam
>
>
>
>
>
> I’m keen to do the work but might need a bit of guidance to get started,
>
> Sam
>
>
>
>
>
>
>
> alternatively you might want to make midonet run in a container. (so
> that you can run it with older ubuntu, or even a container trimmed for
> JVM)
> there were a few attempts to containerize midonet.
> i think this is the latest one: https://github.com/midonet/midonet-docker
>
> On Fri, Aug 28, 2020 at 7:10 AM Sam Morrison <sorrison at gmail.com> wrote:
>
>
> We (Nectar Research Cloud) use midonet heavily too, it works really well
> and we haven’t found another driver that works for us. We tried OVN but it
> just doesn’t scale to the size of environment we have.
>
> I’m happy to help too.
>
> Cheers,
> Sam
>
>
>
> On 31 Jul 2020, at 2:06 am, Slawek Kaplonski <skaplons at redhat.com> wrote:
>
> Hi,
>
> Thx Sebastian for stepping in to maintain the project. That is great news.
> I think that at the beginning You should do 2 things:
> - sync with Takashi Yamamoto (I added him to the loop) as he is probably
> most active current maintainer of this project,
> - focus on fixing networking-midonet ci which is currently broken - all
> scenario jobs aren’t working fine on Ubuntu 18.04 (and we are going to move
> to 20.04 in this cycle), migrate jobs to zuulv3 from the legacy ones and
> finally add them to the ci again,
>
> I can of course help You with ci jobs if You need any help. Feel free to
> ping me on IRC or email (can be off the list).
>
> On 29 Jul 2020, at 15:24, Sebastian Saemann <Sebastian.Saemann at netways.de>
> wrote:
>
> Hi Slawek,
>
> we at NETWAYS are running most of our neutron networking on top of midonet
> and wouldn't be too happy if it gets deprecated and removed. So we would
> like to take over the maintainer role for this part.
>
> Please let me know how to proceed and how we can be onboarded easily.
>
> Best regards,
>
> Sebastian
>
> --
> Sebastian Saemann
> Head of Managed Services
>
> NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
> CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB25207
> https://netways.de | sebastian.saemann at netways.de
>
> ** NETWAYS Web Services - https://nws.netways.de **
>
>
> —
> Slawek Kaplonski
> Principal software engineer
> Red Hat
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200909/b7840ae9/attachment.html>

From skaplons at redhat.com  Wed Sep  9 06:56:39 2020
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Wed, 9 Sep 2020 08:56:39 +0200
Subject: [neutron] CI meeting 09/09/2020 cancelled
Message-ID: <20200909065639.45fheyj5kworzgok@skaplons-mac>

Hi,

I'm off today and I will not be able to chair our CI meeting this week. So lets
cancel it and see You on the meeting next week.

-- 
Slawek Kaplonski
Principal software engineer
Red Hat



From thierry at openstack.org  Wed Sep  9 07:29:23 2020
From: thierry at openstack.org (Thierry Carrez)
Date: Wed, 9 Sep 2020 09:29:23 +0200
Subject: [largescale-sig] Next meeting: September 9, 16utc
Message-ID: <5983106a-fda8-2e5f-b4b3-1fe609f5843d@openstack.org>

Hi everyone,

Our next meeting will be a EU-US-friendly meeting, today Wednesday, 
September 9 at 16 UTC[1] in the #openstack-meeting-3 channel on IRC:

https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200909T16

Feel free to add topics to our agenda at:

https://etherpad.openstack.org/p/large-scale-sig-meeting

A reminder of the TODOs we had from last meeting, in case you have time 
to make progress on them:

- all to contact US large deployment friends to invite them to next 
EU-US meeting
- ttx to request Forum/PTG sessions
- belmoreira, ttx to push for OSops resurrection
- all to describe briefly how you solved metrics/billing in your 
deployment in https://etherpad.openstack.org/p/large-scale-sig-documentation
- masahito to push latest patches to oslo.metrics
- ttx to look into a basic test framework for oslo,metrics
- amorin to see if oslo.metrics could be tested at OVH

Talk to you all later,

-- 
Thierry Carrez


From skaplons at redhat.com  Wed Sep  9 07:50:42 2020
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Wed, 9 Sep 2020 09:50:42 +0200
Subject: [neutron] Flow drop on agent restart with openvswitch firewall
 driver
In-Reply-To: <DM6PR17MB36108DF4942A4B8C72675D73F2290@DM6PR17MB3610.namprd17.prod.outlook.com>
References: <DM6PR17MB36108DF4942A4B8C72675D73F2290@DM6PR17MB3610.namprd17.prod.outlook.com>
Message-ID: <20200909075042.qyxbnq7li2zm5oo4@skaplons-mac>

Hi,

On Tue, Sep 08, 2020 at 02:46:29PM +0000, Alexis Deberg wrote:
> Hi All,
> 
> I'm looking for ideas as we need to upgrade our Neutron deployment and it looks like it would impact workloads a bit much for now to do so and i'm no master of the neutron code...
> 
> We're running Neutron 14.0.2 with ml2 plugin and firewall_driver set as openvswitch. drop_flows_on_start is default False.
> 
> Reading at some old bug reports my understanding was that a restart of the neutron-openvswitch-agent should not impact existing flows and be seamless, but this is not what I'm experiencing as I see some temporary drop(s) around when ovs-fctl del-flows/add-flows is called on br-int (either east-west traffic or north-south). I tried switching to iptables_hybrid driver instead and I don't see the issue in that case.
> 
> e.g when a wget download is happening on an instance while the agent is restarting, I see the following: 2020-09-08 14:26:09 (12.2 MB/s) - Read error at byte 146971864/7416743936 (Success). Retrying
> 
> I'm a bit lot so i'm wondering if that's expected/known behavior, if a workaround is possible....

I don't think it is expected behaviour. All flows should be first installed with
new cookie id and then old ones should be removed. And that shouldn't impact
existing traffic.

> 
> Let me know if a bug report might be a better place to dig deeper or not or if you want additional information... or if I missed a closed bug.

Yes, please report bug on Neutron's launchpad. And, if that is possible, please
also try to reproduce the issue on current master branch (maybe deployed from
devstack simply).

> 
> Thanks !

-- 
Slawek Kaplonski
Principal software engineer
Red Hat



From josephine.seifert at secustack.com  Wed Sep  9 07:51:00 2020
From: josephine.seifert at secustack.com (Josephine Seifert)
Date: Wed, 9 Sep 2020 09:51:00 +0200
Subject: [Image Encryption] No meeting next week
Message-ID: <f1de4253-d5ec-4cbe-29d1-a83434615019@secustack.com>

Hi,

I will be on vacation next week, so there will be no meeting.

Josephine(Luzi)




From bdobreli at redhat.com  Wed Sep  9 08:25:08 2020
From: bdobreli at redhat.com (Bogdan Dobrelya)
Date: Wed, 9 Sep 2020 10:25:08 +0200
Subject: [tripleo][ansible] ensure python dependencies on hosts for
 modules/plugins
Message-ID: <4acfd8e1-5e9e-433e-3b1f-bd3e8a159033@redhat.com>

Since most of tripleo-ansible modules do 'import foobar', we should 
ensure that we have the corresponding python packages installed on 
target hosts. Some of them, like python3-dmidecode may be in base 
Centos8 images. But some may not, especially for custom deployed-servers 
provided by users for deployments.

Those packages must be tracked and ensured to be installed by tripleo 
(preferred), or validated deploy-time (nah...), or at least documented 
as the modules get created or changed by devs.

That also applies to adding action plugins' deps for 
python-tripleoclient or tripleo-ansible perhaps.

Shall we write a spec for that or just address that as a bug [0]?

[0] https://bugs.launchpad.net/tripleo/+bug/1894957

-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando



From balazs.gibizer at est.tech  Wed Sep  9 10:26:50 2020
From: balazs.gibizer at est.tech (=?iso-8859-1?q?Bal=E1zs?= Gibizer)
Date: Wed, 09 Sep 2020 12:26:50 +0200
Subject: [nova] Feature Freeze is coming
Message-ID: <QOZDGQ.VR6W8PZCYKE73@est.tech>

Hi,

Nova will hit Feature Freeze for Victoria release on Thursday. Feature 
patches that are approved before end of Thursday can be rechecked and 
rebased to get them merged. Feature authors having patches that are not 
approved until the freeze but are close can request Feature Freeze 
Exception on the ML. Granting FFE requires ready patches and a core 
sponsor who will review those patches. Please observer that we only 
have 2 weeks before RC1 so time are short for FFEs.

Cheers,
gibi




From sorrison at gmail.com  Wed Sep  9 10:49:19 2020
From: sorrison at gmail.com (Sam Morrison)
Date: Wed, 9 Sep 2020 20:49:19 +1000
Subject: [neutron][networking-midonet] Maintainers needed
In-Reply-To: <CALg0jKksi08Tq-H7xXGiNXqO3W9rtioERr9y7mN_us24GN+mBQ@mail.gmail.com>
References: <0AC5AC07-E97E-43CC-B344-A3E992B8CCA4@netways.de>
 <610412AF-AADF-44BD-ABA2-BA289B7C8F8A@redhat.com>
 <5E2F5826-559E-42E9-84C5-FA708E5A122A@gmail.com>
 <CAH=wFzS6usQqLeUtZ3iwyzw5f+ph38eaHCEQ0xsKo2ZzMREBgA@mail.gmail.com>
 <43C4AF2B-C5C0-40EB-B621-AC6799471D01@gmail.com>
 <CAH=wFzRmjbCy5vQOrpu=rX4Be-_GYPOE602kDShvV-ZtX+eF6g@mail.gmail.com>
 <92959221-0353-4D48-8726-8FE71AFEA652@gmail.com>
 <4D778DBF-F505-462F-B85D-0B372085FA72@gmail.com>
 <CAH=wFzRiJd=93cYsK5FJxJcmMb6eY-XDco1zQOfueMw-0s2Tcw@mail.gmail.com>
 <AB1C90C1-96EE-4D1B-AA3B-63A565A41B61@gmail.com>
 <5B9D2CB0-8B81-4533-A072-9A51B4A44364@gmail.com>
 <CALg0jKksi08Tq-H7xXGiNXqO3W9rtioERr9y7mN_us24GN+mBQ@mail.gmail.com>
Message-ID: <C4587E9A-5E13-4AB5-801E-129BB470F73C@gmail.com>



> On 9 Sep 2020, at 4:52 pm, Lajos Katona <katonalala at gmail.com> wrote:
> 
> Hi,
> Could you please  point to the issue with taas?

Networking-midonet unit tests [1] are failing with the addition of this patch [2]

[1] https://b1a2669063d97482275a-410cecb8410320c66fb802e0a530979a.ssl.cf5.rackcdn.com/749857/18/check/openstack-tox-py36/0344651/testr_results.html
[2] https://opendev.org/x/tap-as-a-service/commit/8332a396b1b046eb370c0cb377d836d0c6b6d6ca <https://opendev.org/x/tap-as-a-service/commit/8332a396b1b046eb370c0cb377d836d0c6b6d6ca>

I’m not really familiar with all of this so not sure how to fix these up.

Cheers,
Sam



> 
> Regards
> Lajos (lajoskatona)
> 
> Sam Morrison <sorrison at gmail.com <mailto:sorrison at gmail.com>> ezt írta (időpont: 2020. szept. 9., Sze, 0:44):
> 
> 
>> On 8 Sep 2020, at 3:13 pm, Sam Morrison <sorrison at gmail.com <mailto:sorrison at gmail.com>> wrote:
>> 
>> Hi Yamamoto,
>> 
>> 
>>> On 4 Sep 2020, at 6:47 pm, Takashi Yamamoto <yamamoto at midokura.com <mailto:yamamoto at midokura.com>> wrote:
>> 
>>> i'm talking to our infra folks but it might take longer than i hoped.
>>> if you or someone else can provide a public repo, it might be faster.
>>> (i have looked at launchpad PPA while ago. but it didn't seem
>>> straightforward given the complex build machinary in midonet.)
>> 
>> Yeah that’s no problem, I’ve set up a repo with the latest midonet debs in it and happy to use that for the time being.
>> 
>>> 
>>>> 
>>>> I’m not sure why the pep8 job is failing, it is complaining about pecan which makes me think this is an issue with neutron itself? Kinda stuck on this one, it’s probably something silly.
>>> 
>>> probably.
>> 
>> Yeah this looks like a neutron or neutron-lib issue
>> 
>>> 
>>>> 
>>>> For the py3 unit tests they are now failing due to db migration errors in tap-as-a-service, l2-gateway and vpnaas issues I think caused by neutron getting rid of the liberty alembic branch and so we need to squash these on these projects too.
>>> 
>>> this thing? https://review.opendev.org/#/c/749866/ <https://review.opendev.org/#/c/749866/>
>> 
>> Yeah that fixed that issue.
>> 
>> 
>> I have been working to get everything fixed in this review [1]
>> 
>> The pep8 job is working but not in the gate due to neutron issues [2]
>> The py36/py38 jobs have 2 tests failing both relating to tap-as-a-service which I don’t really have any idea about, never used it. [3]
> 
> These are failing because of this patch on tap-as-a-service 
> https://opendev.org/x/tap-as-a-service/commit/8332a396b1b046eb370c0cb377d836d0c6b6d6ca <https://opendev.org/x/tap-as-a-service/commit/8332a396b1b046eb370c0cb377d836d0c6b6d6ca>
> 
> Really have no idea how this works, does anyone use tap-as-a-service with midonet and can help me fix it, else I’m wondering if we disable tests for taas and make it an unsupported feature for now.
> 
> Sam
> 
> 
> 
>> The tempest aio job is working well now, I’m not sure what tempest tests were run before but it’s just doing what ever is the default at the moment.
>> The tempest multinode job isn’t working due to what I think is networking issues between the 2 nodes. I don’t really know what I’m doing here so any pointers would be helpful. [4]
>> The grenade job is also failing because I also need to put these fixes on the stable/ussuri branch to make it work so will need to figure that out too
>> 
>> Cheers,
>> Sam
>> 
>> [1] https://review.opendev.org/#/c/749857/ <https://review.opendev.org/#/c/749857/>
>> [2] https://zuul.opendev.org/t/openstack/build/e94e873cbf0443c0a7f25ffe76b3b00b <https://zuul.opendev.org/t/openstack/build/e94e873cbf0443c0a7f25ffe76b3b00b>
>> [3] https://b1a2669063d97482275a-410cecb8410320c66fb802e0a530979a.ssl.cf5.rackcdn.com/749857/18/check/openstack-tox-py36/0344651/testr_results.html <https://b1a2669063d97482275a-410cecb8410320c66fb802e0a530979a.ssl.cf5.rackcdn.com/749857/18/check/openstack-tox-py36/0344651/testr_results.html>
>> [4] https://zuul.opendev.org/t/openstack/build/61f6dd3dc3d74a81b7a3f5968b4d8c72 <https://zuul.opendev.org/t/openstack/build/61f6dd3dc3d74a81b7a3f5968b4d8c72>
>> 
>> 
>>> 
>>>> 
>>>> 
>>>> 
>>>> I can now start to look into the devstack zuul jobs.
>>>> 
>>>> Cheers,
>>>> Sam
>>>> 
>>>> 
>>>> [1] https://github.com/NeCTAR-RC/networking-midonet/commits/devstack <https://github.com/NeCTAR-RC/networking-midonet/commits/devstack>
>>>> [2] https://github.com/midonet/midonet/pull/9 <https://github.com/midonet/midonet/pull/9>
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On 1 Sep 2020, at 4:03 pm, Sam Morrison <sorrison at gmail.com <mailto:sorrison at gmail.com>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 1 Sep 2020, at 2:59 pm, Takashi Yamamoto <yamamoto at midokura.com <mailto:yamamoto at midokura.com>> wrote:
>>>>>> 
>>>>>> hi,
>>>>>> 
>>>>>> On Tue, Sep 1, 2020 at 1:39 PM Sam Morrison <sorrison at gmail.com <mailto:sorrison at gmail.com>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On 1 Sep 2020, at 11:49 am, Takashi Yamamoto <yamamoto at midokura.com <mailto:yamamoto at midokura.com>> wrote:
>>>>>>>> 
>>>>>>>> Sebastian, Sam,
>>>>>>>> 
>>>>>>>> thank you for speaking up.
>>>>>>>> 
>>>>>>>> as Slawek said, the first (and probably the biggest) thing is to fix the ci.
>>>>>>>> the major part for it is to make midonet itself to run on ubuntu
>>>>>>>> version used by the ci. (18.04, or maybe directly to 20.04)
>>>>>>>> https://midonet.atlassian.net/browse/MNA-1344 <https://midonet.atlassian.net/browse/MNA-1344>
>>>>>>>> iirc, the remaining blockers are:
>>>>>>>> * libreswan (used by vpnaas)
>>>>>>>> * vpp (used by fip64)
>>>>>>>> maybe it's the easiest to drop those features along with their
>>>>>>>> required components, if it's acceptable for your use cases.
>>>>>>> 
>>>>>>> We are running midonet-cluster and midolman on 18.04, we dropped those package dependencies from our ubuntu package to get it working.
>>>>>>> 
>>>>>>> We currently have built our own and host in our internal repo but happy to help putting this upstream somehow. Can we upload them to the midonet apt repo, does it still exist?
>>>>>> 
>>>>>> it still exists. but i don't think it's maintained well.
>>>>>> let me find and ask someone in midokura who "owns" that part of infra.
>>>>>> 
>>>>>> does it also involve some package-related modifications to midonet repo, right?
>>>>> 
>>>>> 
>>>>> Yes a couple, I will send up as as pull requests to https://github.com/midonet/midonet <https://github.com/midonet/midonet> today or tomorrow
>>>>> 
>>>>> Sam
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> I’m keen to do the work but might need a bit of guidance to get started,
>>>>>>> 
>>>>>>> Sam
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> alternatively you might want to make midonet run in a container. (so
>>>>>>>> that you can run it with older ubuntu, or even a container trimmed for
>>>>>>>> JVM)
>>>>>>>> there were a few attempts to containerize midonet.
>>>>>>>> i think this is the latest one: https://github.com/midonet/midonet-docker <https://github.com/midonet/midonet-docker>
>>>>>>>> 
>>>>>>>> On Fri, Aug 28, 2020 at 7:10 AM Sam Morrison <sorrison at gmail.com <mailto:sorrison at gmail.com>> wrote:
>>>>>>>>> 
>>>>>>>>> We (Nectar Research Cloud) use midonet heavily too, it works really well and we haven’t found another driver that works for us. We tried OVN but it just doesn’t scale to the size of environment we have.
>>>>>>>>> 
>>>>>>>>> I’m happy to help too.
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> Sam
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On 31 Jul 2020, at 2:06 am, Slawek Kaplonski <skaplons at redhat.com <mailto:skaplons at redhat.com>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> Thx Sebastian for stepping in to maintain the project. That is great news.
>>>>>>>>>> I think that at the beginning You should do 2 things:
>>>>>>>>>> - sync with Takashi Yamamoto (I added him to the loop) as he is probably most active current maintainer of this project,
>>>>>>>>>> - focus on fixing networking-midonet ci which is currently broken - all scenario jobs aren’t working fine on Ubuntu 18.04 (and we are going to move to 20.04 in this cycle), migrate jobs to zuulv3 from the legacy ones and finally add them to the ci again,
>>>>>>>>>> 
>>>>>>>>>> I can of course help You with ci jobs if You need any help. Feel free to ping me on IRC or email (can be off the list).
>>>>>>>>>> 
>>>>>>>>>>> On 29 Jul 2020, at 15:24, Sebastian Saemann <Sebastian.Saemann at netways.de <mailto:Sebastian.Saemann at netways.de>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi Slawek,
>>>>>>>>>>> 
>>>>>>>>>>> we at NETWAYS are running most of our neutron networking on top of midonet and wouldn't be too happy if it gets deprecated and removed. So we would like to take over the maintainer role for this part.
>>>>>>>>>>> 
>>>>>>>>>>> Please let me know how to proceed and how we can be onboarded easily.
>>>>>>>>>>> 
>>>>>>>>>>> Best regards,
>>>>>>>>>>> 
>>>>>>>>>>> Sebastian
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Sebastian Saemann
>>>>>>>>>>> Head of Managed Services
>>>>>>>>>>> 
>>>>>>>>>>> NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
>>>>>>>>>>> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
>>>>>>>>>>> CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB25207
>>>>>>>>>>> https://netways.de <https://netways.de/> | sebastian.saemann at netways.de <mailto:sebastian.saemann at netways.de>
>>>>>>>>>>> 
>>>>>>>>>>> ** NETWAYS Web Services - https://nws.netways.de <https://nws.netways.de/> **
>>>>>>>>>> 
>>>>>>>>>> —
>>>>>>>>>> Slawek Kaplonski
>>>>>>>>>> Principal software engineer
>>>>>>>>>> Red Hat
>>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200909/2216b8fd/attachment-0001.html>

From reza.b2008 at gmail.com  Wed Sep  9 10:54:28 2020
From: reza.b2008 at gmail.com (Reza Bakhshayeshi)
Date: Wed, 9 Sep 2020 15:24:28 +0430
Subject: Floating IP problem in HA OVN DVR with TripleO
In-Reply-To: <CANhpHj-ijDAA-TfeGDKt7vTOdCkqDgmuYMYtGsJ6PbUd1VPF_w@mail.gmail.com>
References: <CAMGoRG0AGUbqwkeT1R+1r=1ScTKMySkJ4b6yZpjYDC-49FAr1Q@mail.gmail.com>
 <20200908080900.efy7bs2qnkzpwbwk@skaplons-mac>
 <CAMGoRG0_na+9W_dhJiOV_mDYLSFj3Yj0rWzKJhGQoJsKWzuivg@mail.gmail.com>
 <CAD0t2fnLO8YVOtpeQBDK5Ue2hHt85U_T=kS0VE3++y7JhNP7HA@mail.gmail.com>
 <CAMGoRG1LTjcrU+HTtA4xuUurb92MWbyR-hCgtBqeEXyyzR=iNw@mail.gmail.com>
 <CANhpHj-ijDAA-TfeGDKt7vTOdCkqDgmuYMYtGsJ6PbUd1VPF_w@mail.gmail.com>
Message-ID: <CAMGoRG0Oc4KBf6rW-J46DyEC3mL8NRjvi9n-zW1-q9=d+QUcyw@mail.gmail.com>

Hi all,

Thanks a lot for your guidance.
I didn't have such a problem in TripleO Stein.
Do you think using OVN DVR in a production environment is a wise choice?

Regards,
Reza

On Tue, 8 Sep 2020 at 21:42, Michał Nasiadka <mnasiadka at gmail.com> wrote:

> Hi Reza,
>
> Here is a related bug:
> https://bugs.launchpad.net/bugs/1881041
>
> I had to use ovn/ovs 2.13 builds from cbs to overcome this issue (
> https://cbs.centos.org/koji/buildinfo?buildID=30482)
>
> Regards,
> Michal
>
> On Tue, 8 Sep 2020 at 18:52, Reza Bakhshayeshi <reza.b2008 at gmail.com>
> wrote:
>
>> Hi Roman,
>>
>> I'm using 'geneve' for my tenant networks.
>>
>> By the way, by pinging 8.8.8.8 from an instance with FIP, tcpdump on its
>> Compute node shows an ARP request for every lost ping. Is it normal
>> behaviour?
>>
>> 21:13:04.808508 ARP, Request who-has dns.google tell
>>
>> X.X.X.X
>>
>>
>>
>> , length 28
>> 21:13:05.808726 ARP, Request who-has dns.google tell
>>
>> X.X.X.X
>>
>>
>>
>> , length 28
>> 21:13:06.808900 ARP, Request who-has dns.google tell
>>
>> X.X.X.X
>>
>>
>>
>> , length 28
>> .
>> .
>> .
>> X.X.X.X if FIP of VM.
>>
>>
>> On Tue, 8 Sep 2020 at 17:21, Roman Safronov <rsafrono at redhat.com> wrote:
>>
>>> Hi Reza,
>>>
>>> Are you using 'geneve' tenant networks or 'vlan' ones? I am asking
>>> because with VLAN we have the following DVR issue [1]
>>>
>>> [1] Bug 1704596 - FIP traffix does not work on OVN-DVR setup when using
>>> VLAN tenant network type
>>> <https://bugzilla.redhat.com/show_bug.cgi?id=1704596>
>>>
>>> On Tue, Sep 8, 2020 at 2:04 PM Reza Bakhshayeshi <reza.b2008 at gmail.com>
>>> wrote:
>>>
>>>> Hi Slawek,
>>>>
>>>> I'm using the latest CentOS 8 Ussuri OVN packages at:
>>>> https://trunk.rdoproject.org/centos8-ussuri/deps/latest/x86_64/
>>>>
>>>> On both Controller and Compute I get:
>>>>
>>>> # rpm -qa | grep ovn
>>>> ovn-host-20.03.0-4.el8.x86_64
>>>> ovn-20.03.0-4.el8.x86_64
>>>>
>>>> # yum info ovn
>>>> Installed Packages
>>>> Name         : ovn
>>>> Version      : 20.03.0
>>>> Release      : 4.el8
>>>> Architecture : x86_64
>>>> Size         : 12 M
>>>> Source       : ovn-20.03.0-4.el8.src.rpm
>>>> Repository   : @System
>>>> From repo    : delorean-ussuri-testing
>>>> Summary      : Open Virtual Network support
>>>> URL          : http://www.openvswitch.org/
>>>> License      : ASL 2.0 and LGPLv2+ and SISSL
>>>>
>>>> Do you suggest installing ovn manually from source on containers?
>>>> ي
>>>>
>>>> On Tue, 8 Sep 2020 at 12:39, Slawek Kaplonski <skaplons at redhat.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Maybe You hit this bug [1]. Please check what ovn version do You have
>>>>> and maybe
>>>>>
>>>>>
>>>>> update it if needed.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 07, 2020 at 06:23:44PM +0430, Reza Bakhshayeshi wrote:
>>>>>
>>>>>
>>>>> > Hi all,
>>>>>
>>>>>
>>>>> >
>>>>>
>>>>>
>>>>> > I deployed an environment with TripleO Ussuri with 3 HA Controllers
>>>>> and
>>>>>
>>>>>
>>>>> > some Compute nodes with neutron-ovn-dvr-ha.yaml
>>>>>
>>>>>
>>>>> > Instances have Internet access through routers with SNAT traffic (in
>>>>> this
>>>>>
>>>>>
>>>>> > case traffic is routed via a controller node), and by assigning IP
>>>>> address
>>>>>
>>>>>
>>>>> > directly from provider network (not having a router).
>>>>>
>>>>>
>>>>> >
>>>>>
>>>>>
>>>>> > But in case of assigning FIP from provider to an instance, VM
>>>>> Internet
>>>>>
>>>>>
>>>>> > connection is lost.
>>>>>
>>>>>
>>>>> > Here is the output of router nat lists, which seems OK:
>>>>>
>>>>>
>>>>> >
>>>>>
>>>>>
>>>>> >
>>>>>
>>>>>
>>>>> > # ovn-nbctl lr-nat-list 587182a4-4d6b-41b0-9fd8-4c1be58811b0
>>>>>
>>>>>
>>>>> > TYPE             EXTERNAL_IP        EXTERNAL_PORT    LOGICAL_IP
>>>>>
>>>>>
>>>>> >  EXTERNAL_MAC         LOGICAL_PORT
>>>>>
>>>>>
>>>>> > dnat_and_snat    X.X.X.X                      192.168.0.153
>>>>>
>>>>>
>>>>> > fa:16:3e:0a:86:4d    e65bd8e9-5f95-4eb2-a316-97e86fbdb9b6
>>>>>
>>>>>
>>>>> > snat             Y.Y.Y.Y                      192.168.0.0/24
>>>>>
>>>>>
>>>>> >
>>>>>
>>>>>
>>>>> >
>>>>>
>>>>>
>>>>> > I replaced FIP with X.X.X.X and router IP with Y.Y.Y.Y
>>>>>
>>>>>
>>>>> >
>>>>>
>>>>>
>>>>> > When I remove * EXTERNAL_MAC* and *LOGICAL_PORT*, FIP works fine and
>>>>> as it
>>>>>
>>>>>
>>>>> > has to be, but traffic routes from a Controller node and it won't be
>>>>>
>>>>>
>>>>> > distributed anymore.
>>>>>
>>>>>
>>>>> >
>>>>>
>>>>>
>>>>> > Any idea or suggestion would be grateful.
>>>>>
>>>>>
>>>>> > Regards,
>>>>>
>>>>>
>>>>> > Reza
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1834433
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>
>>>>> Slawek Kaplonski
>>>>>
>>>>>
>>>>> Principal software engineer
>>>>>
>>>>>
>>>>> Red Hat
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>>
>>> ROMAN SAFRONOV
>>>
>>> SENIOR QE, OPENSTACK NETWORKING
>>>
>>> Red Hat <https://www.redhat.com/>
>>>
>>> Israel
>>>
>>> M: +972545433957
>>>
>>> <https://red.ht/sig>
>>>
>>>
>>>
>>
>> --
> Michał Nasiadka
> mnasiadka at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200909/3df9cc61/attachment.html>

From john at johngarbutt.com  Wed Sep  9 11:28:24 2020
From: john at johngarbutt.com (John Garbutt)
Date: Wed, 9 Sep 2020 12:28:24 +0100
Subject: Application Credentials with federated users
In-Reply-To: <7fc8d66653064962aa458e13124bcb9d@stfc.ac.uk>
References: <7fc8d66653064962aa458e13124bcb9d@stfc.ac.uk>
Message-ID: <CABib2_p=2XACtBSbtLvAYVT0GX=gV0fgw7u2nc1Y3_FWNZnizg@mail.gmail.com>

Hi Alex,

In my experience it worked fine, with a major limitation about groups.

This, merged in ussri, should have fixed the group issues:
https://bugs.launchpad.net/keystone/+bug/1809116
I had planned on testing that by now, but that work hasn't been
started/agreed yet.

My current workaround for not having groups is for the federation
mapping to add users directly into projects:
https://github.com/RSE-Cambridge/cumulus-config

I planned to map from an OIDC group attribute into a specific concrete
project, but the above puts everyone in a holding project and does
static role assignments, due to issues with group management in the
OIDC provider.

As an aside, this the way were were configuring keystone, incase that
is important to making things work:
https://github.com/RSE-Cambridge/cumulus-kayobe-config/tree/train-preprod/etc/kayobe/kolla/config/keystone
https://github.com/RSE-Cambridge/cumulus-kayobe-config/blob/0dc43a0f5c7b76f6913dea0fdda2b1674511c3f4/etc/kayobe/kolla.yml#L122

Horizon and the CLI tools in train didn't really agree, I think the
auth url is now missing "/v3", but I believe that is fixed in latest
keystoneauth client:
https://bugs.launchpad.net/keystoneauth/+bug/1876317

Hopefully that helps?

Thanks,
John

On Tue, 8 Sep 2020 at 16:33, Alexander Dibbo - UKRI STFC
<alexander.dibbo at stfc.ac.uk> wrote:
>
> Hi All,
>
>
>
> Is it possible for a user logging in via an oidc provider to generate application credentials?
>
>
>
> When I try it I get an error about there being no role for the user in the project.
>
>
>
> We map the users to groups based on assertions in their tokens.
>
>
>
> It looks like it would work if we mapped users individually to local users in keystone and then gave those roles. I would prefer to avoid using per user mappings for this if possible as it would be a lot of extra work for my team.
>
>
>
> Regards
>
>
>
> Alexander Dibbo – Cloud Architect / Cloud Operations Group Leader
>
> For STFC Cloud Documentation visit https://stfc-cloud-docs.readthedocs.io
>
> To raise a support ticket with the cloud team please email cloud-support at gridpp.rl.ac.uk
>
> To receive notifications about the service please subscribe to our mailing list at: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A0=STFC-CLOUD
>
> To receive fast notifications or to discuss usage of the cloud please join our Slack: https://stfc-cloud.slack.com/
>
>
>
> This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI.


From katonalala at gmail.com  Wed Sep  9 12:18:37 2020
From: katonalala at gmail.com (Lajos Katona)
Date: Wed, 9 Sep 2020 14:18:37 +0200
Subject: [neutron][networking-midonet] Maintainers needed
In-Reply-To: <C4587E9A-5E13-4AB5-801E-129BB470F73C@gmail.com>
References: <0AC5AC07-E97E-43CC-B344-A3E992B8CCA4@netways.de>
 <610412AF-AADF-44BD-ABA2-BA289B7C8F8A@redhat.com>
 <5E2F5826-559E-42E9-84C5-FA708E5A122A@gmail.com>
 <CAH=wFzS6usQqLeUtZ3iwyzw5f+ph38eaHCEQ0xsKo2ZzMREBgA@mail.gmail.com>
 <43C4AF2B-C5C0-40EB-B621-AC6799471D01@gmail.com>
 <CAH=wFzRmjbCy5vQOrpu=rX4Be-_GYPOE602kDShvV-ZtX+eF6g@mail.gmail.com>
 <92959221-0353-4D48-8726-8FE71AFEA652@gmail.com>
 <4D778DBF-F505-462F-B85D-0B372085FA72@gmail.com>
 <CAH=wFzRiJd=93cYsK5FJxJcmMb6eY-XDco1zQOfueMw-0s2Tcw@mail.gmail.com>
 <AB1C90C1-96EE-4D1B-AA3B-63A565A41B61@gmail.com>
 <5B9D2CB0-8B81-4533-A072-9A51B4A44364@gmail.com>
 <CALg0jKksi08Tq-H7xXGiNXqO3W9rtioERr9y7mN_us24GN+mBQ@mail.gmail.com>
 <C4587E9A-5E13-4AB5-801E-129BB470F73C@gmail.com>
Message-ID: <CALg0jK=qEWFSwA5T-+fKwKsamqTK_mqhUW+ZY6fqCxk5xm0m0A@mail.gmail.com>

Hi,
I pushed a fix for it https://review.opendev.org/750633, I added Deepak for
reviewer as he is the owner of the taas patch.

Sorry for the problem.
Lajos (lajoskatona)

Sam Morrison <sorrison at gmail.com> ezt írta (időpont: 2020. szept. 9., Sze,
12:49):

>
>
> On 9 Sep 2020, at 4:52 pm, Lajos Katona <katonalala at gmail.com> wrote:
>
> Hi,
> Could you please  point to the issue with taas?
>
>
> Networking-midonet unit tests [1] are failing with the addition of this
> patch [2]
>
> [1]
> https://b1a2669063d97482275a-410cecb8410320c66fb802e0a530979a.ssl.cf5.rackcdn.com/749857/18/check/openstack-tox-py36/0344651/testr_results.html
> [2]
> https://opendev.org/x/tap-as-a-service/commit/8332a396b1b046eb370c0cb377d836d0c6b6d6ca
>
> I’m not really familiar with all of this so not sure how to fix these up.
>
> Cheers,
> Sam
>
>
>
>
> Regards
> Lajos (lajoskatona)
>
> Sam Morrison <sorrison at gmail.com> ezt írta (időpont: 2020. szept. 9.,
> Sze, 0:44):
>
>>
>>
>> On 8 Sep 2020, at 3:13 pm, Sam Morrison <sorrison at gmail.com> wrote:
>>
>> Hi Yamamoto,
>>
>>
>> On 4 Sep 2020, at 6:47 pm, Takashi Yamamoto <yamamoto at midokura.com>
>> wrote:
>>
>>
>> i'm talking to our infra folks but it might take longer than i hoped.
>> if you or someone else can provide a public repo, it might be faster.
>> (i have looked at launchpad PPA while ago. but it didn't seem
>> straightforward given the complex build machinary in midonet.)
>>
>>
>> Yeah that’s no problem, I’ve set up a repo with the latest midonet debs
>> in it and happy to use that for the time being.
>>
>>
>>
>> I’m not sure why the pep8 job is failing, it is complaining about pecan
>> which makes me think this is an issue with neutron itself? Kinda stuck on
>> this one, it’s probably something silly.
>>
>>
>> probably.
>>
>>
>> Yeah this looks like a neutron or neutron-lib issue
>>
>>
>>
>> For the py3 unit tests they are now failing due to db migration errors in
>> tap-as-a-service, l2-gateway and vpnaas issues I think caused by neutron
>> getting rid of the liberty alembic branch and so we need to squash these on
>> these projects too.
>>
>>
>> this thing? https://review.opendev.org/#/c/749866/
>>
>>
>> Yeah that fixed that issue.
>>
>>
>> I have been working to get everything fixed in this review [1]
>>
>> The pep8 job is working but not in the gate due to neutron issues [2]
>> The py36/py38 jobs have 2 tests failing both relating to tap-as-a-service
>> which I don’t really have any idea about, never used it. [3]
>>
>>
>> These are failing because of this patch on tap-as-a-service
>>
>> https://opendev.org/x/tap-as-a-service/commit/8332a396b1b046eb370c0cb377d836d0c6b6d6ca
>>
>> Really have no idea how this works, does anyone use tap-as-a-service with
>> midonet and can help me fix it, else I’m wondering if we disable tests for
>> taas and make it an unsupported feature for now.
>>
>> Sam
>>
>>
>>
>> The tempest aio job is working well now, I’m not sure what tempest tests
>> were run before but it’s just doing what ever is the default at the moment.
>> The tempest multinode job isn’t working due to what I think is networking
>> issues between the 2 nodes. I don’t really know what I’m doing here so any
>> pointers would be helpful. [4]
>> The grenade job is also failing because I also need to put these fixes on
>> the stable/ussuri branch to make it work so will need to figure that out too
>>
>> Cheers,
>> Sam
>>
>> [1] https://review.opendev.org/#/c/749857/
>> [2]
>> https://zuul.opendev.org/t/openstack/build/e94e873cbf0443c0a7f25ffe76b3b00b
>> [3]
>> https://b1a2669063d97482275a-410cecb8410320c66fb802e0a530979a.ssl.cf5.rackcdn.com/749857/18/check/openstack-tox-py36/0344651/testr_results.html
>> [4]
>> https://zuul.opendev.org/t/openstack/build/61f6dd3dc3d74a81b7a3f5968b4d8c72
>>
>>
>>
>>
>>
>>
>> I can now start to look into the devstack zuul jobs.
>>
>> Cheers,
>> Sam
>>
>>
>> [1] https://github.com/NeCTAR-RC/networking-midonet/commits/devstack
>> [2] https://github.com/midonet/midonet/pull/9
>>
>>
>>
>>
>> On 1 Sep 2020, at 4:03 pm, Sam Morrison <sorrison at gmail.com> wrote:
>>
>>
>>
>> On 1 Sep 2020, at 2:59 pm, Takashi Yamamoto <yamamoto at midokura.com>
>> wrote:
>>
>> hi,
>>
>> On Tue, Sep 1, 2020 at 1:39 PM Sam Morrison <sorrison at gmail.com> wrote:
>>
>>
>>
>>
>> On 1 Sep 2020, at 11:49 am, Takashi Yamamoto <yamamoto at midokura.com>
>> wrote:
>>
>> Sebastian, Sam,
>>
>> thank you for speaking up.
>>
>> as Slawek said, the first (and probably the biggest) thing is to fix the
>> ci.
>> the major part for it is to make midonet itself to run on ubuntu
>> version used by the ci. (18.04, or maybe directly to 20.04)
>> https://midonet.atlassian.net/browse/MNA-1344
>> iirc, the remaining blockers are:
>> * libreswan (used by vpnaas)
>> * vpp (used by fip64)
>> maybe it's the easiest to drop those features along with their
>> required components, if it's acceptable for your use cases.
>>
>>
>> We are running midonet-cluster and midolman on 18.04, we dropped those
>> package dependencies from our ubuntu package to get it working.
>>
>> We currently have built our own and host in our internal repo but happy
>> to help putting this upstream somehow. Can we upload them to the midonet
>> apt repo, does it still exist?
>>
>>
>> it still exists. but i don't think it's maintained well.
>> let me find and ask someone in midokura who "owns" that part of infra.
>>
>> does it also involve some package-related modifications to midonet repo,
>> right?
>>
>>
>>
>> Yes a couple, I will send up as as pull requests to
>> https://github.com/midonet/midonet today or tomorrow
>>
>> Sam
>>
>>
>>
>>
>>
>> I’m keen to do the work but might need a bit of guidance to get started,
>>
>> Sam
>>
>>
>>
>>
>>
>>
>>
>> alternatively you might want to make midonet run in a container. (so
>> that you can run it with older ubuntu, or even a container trimmed for
>> JVM)
>> there were a few attempts to containerize midonet.
>> i think this is the latest one: https://github.com/midonet/midonet-docker
>>
>> On Fri, Aug 28, 2020 at 7:10 AM Sam Morrison <sorrison at gmail.com> wrote:
>>
>>
>> We (Nectar Research Cloud) use midonet heavily too, it works really well
>> and we haven’t found another driver that works for us. We tried OVN but it
>> just doesn’t scale to the size of environment we have.
>>
>> I’m happy to help too.
>>
>> Cheers,
>> Sam
>>
>>
>>
>> On 31 Jul 2020, at 2:06 am, Slawek Kaplonski <skaplons at redhat.com> wrote:
>>
>> Hi,
>>
>> Thx Sebastian for stepping in to maintain the project. That is great news.
>> I think that at the beginning You should do 2 things:
>> - sync with Takashi Yamamoto (I added him to the loop) as he is probably
>> most active current maintainer of this project,
>> - focus on fixing networking-midonet ci which is currently broken - all
>> scenario jobs aren’t working fine on Ubuntu 18.04 (and we are going to move
>> to 20.04 in this cycle), migrate jobs to zuulv3 from the legacy ones and
>> finally add them to the ci again,
>>
>> I can of course help You with ci jobs if You need any help. Feel free to
>> ping me on IRC or email (can be off the list).
>>
>> On 29 Jul 2020, at 15:24, Sebastian Saemann <Sebastian.Saemann at netways.de>
>> wrote:
>>
>> Hi Slawek,
>>
>> we at NETWAYS are running most of our neutron networking on top of
>> midonet and wouldn't be too happy if it gets deprecated and removed. So we
>> would like to take over the maintainer role for this part.
>>
>> Please let me know how to proceed and how we can be onboarded easily.
>>
>> Best regards,
>>
>> Sebastian
>>
>> --
>> Sebastian Saemann
>> Head of Managed Services
>>
>> NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
>> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
>> CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB25207
>> https://netways.de | sebastian.saemann at netways.de
>>
>> ** NETWAYS Web Services - https://nws.netways.de **
>>
>>
>> —
>> Slawek Kaplonski
>> Principal software engineer
>> Red Hat
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200909/eb16c50d/attachment.html>

From gmann at ghanshyammann.com  Wed Sep  9 13:04:09 2020
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 09 Sep 2020 08:04:09 -0500
Subject: [neutron][networking-midonet] Maintainers needed
In-Reply-To: <CALg0jK=qEWFSwA5T-+fKwKsamqTK_mqhUW+ZY6fqCxk5xm0m0A@mail.gmail.com>
References: <0AC5AC07-E97E-43CC-B344-A3E992B8CCA4@netways.de>
 <610412AF-AADF-44BD-ABA2-BA289B7C8F8A@redhat.com>
 <5E2F5826-559E-42E9-84C5-FA708E5A122A@gmail.com>
 <CAH=wFzS6usQqLeUtZ3iwyzw5f+ph38eaHCEQ0xsKo2ZzMREBgA@mail.gmail.com>
 <43C4AF2B-C5C0-40EB-B621-AC6799471D01@gmail.com>
 <CAH=wFzRmjbCy5vQOrpu=rX4Be-_GYPOE602kDShvV-ZtX+eF6g@mail.gmail.com>
 <92959221-0353-4D48-8726-8FE71AFEA652@gmail.com>
 <4D778DBF-F505-462F-B85D-0B372085FA72@gmail.com>
 <CAH=wFzRiJd=93cYsK5FJxJcmMb6eY-XDco1zQOfueMw-0s2Tcw@mail.gmail.com>
 <AB1C90C1-96EE-4D1B-AA3B-63A565A41B61@gmail.com>
 <5B9D2CB0-8B81-4533-A072-9A51B4A44364@gmail.com>
 <CALg0jKksi08Tq-H7xXGiNXqO3W9rtioERr9y7mN_us24GN+mBQ@mail.gmail.com>
 <C4587E9A-5E13-4AB5-801E-129BB470F73C@gmail.com>
 <CALg0jK=qEWFSwA5T-+fKwKsamqTK_mqhUW+ZY6fqCxk5xm0m0A@mail.gmail.com>
Message-ID: <17472f764b8.1292d333d6181.3892285235847293323@ghanshyammann.com>

Also we need to merge the networking-l2gw project new location fix

 - https://review.opendev.org/#/c/738046/

It's leading to many errors as pointed by AJaeger  - https://zuul.opendev.org/t/openstack/config-errors


-gmann

 ---- On Wed, 09 Sep 2020 07:18:37 -0500 Lajos Katona <katonalala at gmail.com> wrote ----
 > Hi,I pushed a fix for it https://review.opendev.org/750633, I added Deepak for reviewer as he is the owner of the taas patch.
 > Sorry for the problem.Lajos (lajoskatona)
 > Sam Morrison <sorrison at gmail.com> ezt írta (időpont: 2020. szept. 9., Sze, 12:49):
 > 
 > 
 > On 9 Sep 2020, at 4:52 pm, Lajos Katona <katonalala at gmail.com> wrote:
 > Hi,Could you please  point to the issue with taas?
 > Networking-midonet unit tests [1] are failing with the addition of this patch [2]
 > [1] https://b1a2669063d97482275a-410cecb8410320c66fb802e0a530979a.ssl.cf5.rackcdn.com/749857/18/check/openstack-tox-py36/0344651/testr_results.html[2] https://opendev.org/x/tap-as-a-service/commit/8332a396b1b046eb370c0cb377d836d0c6b6d6ca
 > I’m not really familiar with all of this so not sure how to fix these up.
 > Cheers,Sam
 > 
 > 
 > 
 > RegardsLajos (lajoskatona)
 > Sam Morrison <sorrison at gmail.com> ezt írta (időpont: 2020. szept. 9., Sze, 0:44):
 > 
 > 
 > On 8 Sep 2020, at 3:13 pm, Sam Morrison <sorrison at gmail.com> wrote:
 > Hi Yamamoto,
 > 
 > On 4 Sep 2020, at 6:47 pm, Takashi Yamamoto <yamamoto at midokura.com> wrote:
 > i'm talking to our infra folks but it might take longer than i hoped.
 > if you or someone else can provide a public repo, it might be faster.
 > (i have looked at launchpad PPA while ago. but it didn't seem
 > straightforward given the complex build machinary in midonet.)
 > 
 > Yeah that’s no problem, I’ve set up a repo with the latest midonet debs in it and happy to use that for the time being.
 > 
 > 
 > I’m not sure why the pep8 job is failing, it is complaining about pecan which makes me think this is an issue with neutron itself? Kinda stuck on this one, it’s probably something silly.
 > 
 > probably.
 > 
 > Yeah this looks like a neutron or neutron-lib issue
 > 
 > 
 > For the py3 unit tests they are now failing due to db migration errors in tap-as-a-service, l2-gateway and vpnaas issues I think caused by neutron getting rid of the liberty alembic branch and so we need to squash these on these projects too.
 > 
 > this thing? https://review.opendev.org/#/c/749866/
 > 
 > Yeah that fixed that issue.
 > 
 > I have been working to get everything fixed in this review [1]
 > The pep8 job is working but not in the gate due to neutron issues [2]The py36/py38 jobs have 2 tests failing both relating to tap-as-a-service which I don’t really have any idea about, never used it. [3]
 > These are failing because of this patch on tap-as-a-service https://opendev.org/x/tap-as-a-service/commit/8332a396b1b046eb370c0cb377d836d0c6b6d6ca
 > Really have no idea how this works, does anyone use tap-as-a-service with midonet and can help me fix it, else I’m wondering if we disable tests for taas and make it an unsupported feature for now.
 > Sam
 > 
 > 
 > The tempest aio job is working well now, I’m not sure what tempest tests were run before but it’s just doing what ever is the default at the moment.The tempest multinode job isn’t working due to what I think is networking issues between the 2 nodes. I don’t really know what I’m doing here so any pointers would be helpful. [4]The grenade job is also failing because I also need to put these fixes on the stable/ussuri branch to make it work so will need to figure that out too
 > Cheers,Sam
 > [1] https://review.opendev.org/#/c/749857/[2] https://zuul.opendev.org/t/openstack/build/e94e873cbf0443c0a7f25ffe76b3b00b[3] https://b1a2669063d97482275a-410cecb8410320c66fb802e0a530979a.ssl.cf5.rackcdn.com/749857/18/check/openstack-tox-py36/0344651/testr_results.html[4] https://zuul.opendev.org/t/openstack/build/61f6dd3dc3d74a81b7a3f5968b4d8c72
 > 
 > 
 > 
 > 
 > 
 > I can now start to look into the devstack zuul jobs.
 > 
 > Cheers,
 > Sam
 > 
 > 
 > [1] https://github.com/NeCTAR-RC/networking-midonet/commits/devstack
 > [2] https://github.com/midonet/midonet/pull/9
 > 
 > 
 > 
 > 
 > On 1 Sep 2020, at 4:03 pm, Sam Morrison <sorrison at gmail.com> wrote:
 > 
 > 
 > 
 > On 1 Sep 2020, at 2:59 pm, Takashi Yamamoto <yamamoto at midokura.com> wrote:
 > 
 > hi,
 > 
 > On Tue, Sep 1, 2020 at 1:39 PM Sam Morrison <sorrison at gmail.com> wrote:
 > 
 > 
 > 
 > On 1 Sep 2020, at 11:49 am, Takashi Yamamoto <yamamoto at midokura.com> wrote:
 > 
 > Sebastian, Sam,
 > 
 > thank you for speaking up.
 > 
 > as Slawek said, the first (and probably the biggest) thing is to fix the ci.
 > the major part for it is to make midonet itself to run on ubuntu
 > version used by the ci. (18.04, or maybe directly to 20.04)
 > https://midonet.atlassian.net/browse/MNA-1344
 > iirc, the remaining blockers are:
 > * libreswan (used by vpnaas)
 > * vpp (used by fip64)
 > maybe it's the easiest to drop those features along with their
 > required components, if it's acceptable for your use cases.
 > 
 > We are running midonet-cluster and midolman on 18.04, we dropped those package dependencies from our ubuntu package to get it working.
 > 
 > We currently have built our own and host in our internal repo but happy to help putting this upstream somehow. Can we upload them to the midonet apt repo, does it still exist?
 > 
 > it still exists. but i don't think it's maintained well.
 > let me find and ask someone in midokura who "owns" that part of infra.
 > 
 > does it also involve some package-related modifications to midonet repo, right?
 > 
 > 
 > Yes a couple, I will send up as as pull requests to https://github.com/midonet/midonet today or tomorrow
 > 
 > Sam
 > 
 > 
 > 
 > 
 > 
 > I’m keen to do the work but might need a bit of guidance to get started,
 > 
 > Sam
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > alternatively you might want to make midonet run in a container. (so
 > that you can run it with older ubuntu, or even a container trimmed for
 > JVM)
 > there were a few attempts to containerize midonet.
 > i think this is the latest one: https://github.com/midonet/midonet-docker
 > 
 > On Fri, Aug 28, 2020 at 7:10 AM Sam Morrison <sorrison at gmail.com> wrote:
 > 
 > We (Nectar Research Cloud) use midonet heavily too, it works really well and we haven’t found another driver that works for us. We tried OVN but it just doesn’t scale to the size of environment we have.
 > 
 > I’m happy to help too.
 > 
 > Cheers,
 > Sam
 > 
 > 
 > 
 > On 31 Jul 2020, at 2:06 am, Slawek Kaplonski <skaplons at redhat.com> wrote:
 > 
 > Hi,
 > 
 > Thx Sebastian for stepping in to maintain the project. That is great news.
 > I think that at the beginning You should do 2 things:
 > - sync with Takashi Yamamoto (I added him to the loop) as he is probably most active current maintainer of this project,
 > - focus on fixing networking-midonet ci which is currently broken - all scenario jobs aren’t working fine on Ubuntu 18.04 (and we are going to move to 20.04 in this cycle), migrate jobs to zuulv3 from the legacy ones and finally add them to the ci again,
 > 
 > I can of course help You with ci jobs if You need any help. Feel free to ping me on IRC or email (can be off the list).
 > 
 > On 29 Jul 2020, at 15:24, Sebastian Saemann <Sebastian.Saemann at netways.de> wrote:
 > 
 > Hi Slawek,
 > 
 > we at NETWAYS are running most of our neutron networking on top of midonet and wouldn't be too happy if it gets deprecated and removed. So we would like to take over the maintainer role for this part.
 > 
 > Please let me know how to proceed and how we can be onboarded easily.
 > 
 > Best regards,
 > 
 > Sebastian
 > 
 > --
 > Sebastian Saemann
 > Head of Managed Services
 > 
 > NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
 > Tel: +49 911 92885-0 | Fax: +49 911 92885-77
 > CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB25207
 > https://netways.de | sebastian.saemann at netways.de
 > 
 > ** NETWAYS Web Services - https://nws.netways.de **
 > 
 > —
 > Slawek Kaplonski
 > Principal software engineer
 > Red Hat
 > 
 > 
 > 
 > 
 > 


From cjeanner at redhat.com  Wed Sep  9 14:33:38 2020
From: cjeanner at redhat.com (=?UTF-8?Q?C=c3=a9dric_Jeanneret?=)
Date: Wed, 9 Sep 2020 16:33:38 +0200
Subject: [tripleo][ansible] ensure python dependencies on hosts for
 modules/plugins
In-Reply-To: <4acfd8e1-5e9e-433e-3b1f-bd3e8a159033@redhat.com>
References: <4acfd8e1-5e9e-433e-3b1f-bd3e8a159033@redhat.com>
Message-ID: <f41e0eca-ce07-8e6e-9e14-d6ad40e934ef@redhat.com>


On 9/9/20 10:25 AM, Bogdan Dobrelya wrote:
> Since most of tripleo-ansible modules do 'import foobar', we should
> ensure that we have the corresponding python packages installed on
> target hosts. Some of them, like python3-dmidecode may be in base
> Centos8 images. But some may not, especially for custom deployed-servers
> provided by users for deployments.
> 
> Those packages must be tracked and ensured to be installed by tripleo
> (preferred), or validated deploy-time (nah...), or at least documented
> as the modules get created or changed by devs.
> 
> That also applies to adding action plugins' deps for
> python-tripleoclient or tripleo-ansible perhaps.
> 
> Shall we write a spec for that or just address that as a bug [0]?
> 
> [0] https://bugs.launchpad.net/tripleo/+bug/1894957
> 

If we're talking only about tripleo-ansible, we might "just" add the new
dependencies in the spec file in tripleo-ansible-distgit.
If we're talking more broadly, as said in the LP, a meta-package
(tripleo-dependencies for instance) might be a nice thing, since it
would allow to take care of:
- package pinning (staring at YOU, podman)
- package dependencies

As for a proper spec, it might be interesting for future reference. Not
really sure if it's really needed, but...

Cheers,

C.


-- 
Cédric Jeanneret (He/Him/His)
Sr. Software Engineer - OpenStack Platform
Deployment Framework TC
Red Hat EMEA
https://www.redhat.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200909/12dab6ed/attachment.sig>

From aschultz at redhat.com  Wed Sep  9 14:46:58 2020
From: aschultz at redhat.com (Alex Schultz)
Date: Wed, 9 Sep 2020 08:46:58 -0600
Subject: [tripleo][ansible] ensure python dependencies on hosts for
 modules/plugins
In-Reply-To: <f41e0eca-ce07-8e6e-9e14-d6ad40e934ef@redhat.com>
References: <4acfd8e1-5e9e-433e-3b1f-bd3e8a159033@redhat.com>
 <f41e0eca-ce07-8e6e-9e14-d6ad40e934ef@redhat.com>
Message-ID: <CAFsb3b5x9F_dLN5_BPh2o_-96irMuYdDQVqJ+8a2dRK3QTUkng@mail.gmail.com>

On Wed, Sep 9, 2020 at 8:43 AM Cédric Jeanneret <cjeanner at redhat.com> wrote:
>
>
> On 9/9/20 10:25 AM, Bogdan Dobrelya wrote:
> > Since most of tripleo-ansible modules do 'import foobar', we should
> > ensure that we have the corresponding python packages installed on
> > target hosts. Some of them, like python3-dmidecode may be in base
> > Centos8 images. But some may not, especially for custom deployed-servers
> > provided by users for deployments.
> >
> > Those packages must be tracked and ensured to be installed by tripleo
> > (preferred), or validated deploy-time (nah...), or at least documented
> > as the modules get created or changed by devs.
> >
> > That also applies to adding action plugins' deps for
> > python-tripleoclient or tripleo-ansible perhaps.
> >
> > Shall we write a spec for that or just address that as a bug [0]?
> >
> > [0] https://bugs.launchpad.net/tripleo/+bug/1894957
> >
>
> If we're talking only about tripleo-ansible, we might "just" add the new
> dependencies in the spec file in tripleo-ansible-distgit.
> If we're talking more broadly, as said in the LP, a meta-package
> (tripleo-dependencies for instance) might be a nice thing, since it
> would allow to take care of:
> - package pinning (staring at YOU, podman)
> - package dependencies
>

So the problem here is tripleo-ansible is not installed on the remote
system. So modules need packages installed there.  Currently this is
solved in two ways:

1) overcloud-full contains all the packages
2) use tripleo_bootstrap role to install dependencies

While having a meta-package that we install that lists all the deps
would be nice you still have the same issue to ensure it ends up where
it needs to be.  I don't think we need to over engineer this as we
already have two ways that have been in place for many releases now.

Thanks,
-Alex

> As for a proper spec, it might be interesting for future reference. Not
> really sure if it's really needed, but...
>
> Cheers,
>
> C.
>
>
> --
> Cédric Jeanneret (He/Him/His)
> Sr. Software Engineer - OpenStack Platform
> Deployment Framework TC
> Red Hat EMEA
> https://www.redhat.com/
>



From mnaser at vexxhost.com  Wed Sep  9 14:58:06 2020
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Wed, 9 Sep 2020 10:58:06 -0400
Subject: [tc] weekly update
Message-ID: <CAEs876gw=_U80s57=Hyg_AMiEapZyQ7MPK1UmPejXevKM4S=kA@mail.gmail.com>

Hi everyone,

Here's an update for what happened in the OpenStack TC this week. You
can get more information by checking for changes in
openstack/governance repository.  We've also included a few references
to some important mailing list threads that you should check out.

# Patches
## Open Reviews
- Add openstack/osops to Ops Docs and Tooling SIG
https://review.opendev.org/749835
- Reinstate weekly meetings https://review.opendev.org/749279
- Create starter-kit:kubernetes-in-virt tag https://review.opendev.org/736369
- Resolution to define distributed leadership for projects
https://review.opendev.org/744995
- Add assert:supports-standalone https://review.opendev.org/722399
- Retire devstack-plugin-pika project https://review.opendev.org/748730
- Remove tc:approved-release tag https://review.opendev.org/749363
- Retire the devstack-plugin-zmq project https://review.opendev.org/748731

## Project Updates
- Add openstack-helm-deployments to openstack-helm
https://review.opendev.org/748302
- Add openstack-ansible/os_senlin role https://review.opendev.org/748677
- kolla-cli: deprecation - Mark as deprecated https://review.opendev.org/749694
- Move ansible-role-XXX-hsm projects to Barbican team
https://review.opendev.org/748027

## General Changes
- Drop all exceptions for legacy validation https://review.opendev.org/745403

## Abandoned Changes
- kolla-cli: deprecation - Mark kolla-cli as Deprecated
https://review.opendev.org/749746

# Email Threads
- Focal Goal Update #4:
http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017078.html
- Forum Submissions Open:
http://lists.openstack.org/pipermail/openstack-discuss/2020-September/016933.html

# Other Reminders
- Forum CFP closes Sept 14th!
- PTG Signup closes Sept 11th!

Thanks for reading!
Mohammed & Kendall

-- 
Mohammed Naser
VEXXHOST, Inc.


From thierry at openstack.org  Wed Sep  9 15:05:40 2020
From: thierry at openstack.org (Thierry Carrez)
Date: Wed, 9 Sep 2020 17:05:40 +0200
Subject: [summit] Schedule is Live for the 2020 Virtual Open Infrastructure
 Summit
Message-ID: <1211c678-52fb-8509-5e67-0fc4e93c8eb2@openstack.org>

Hi everyone,

We are excited to announce that the schedule[1] for the virtual 2020 
Open Infrastructure Summit is now live featuring keynotes and sessions 
from users like Volvo, Workday, Société Générale and Ant Group:

[1] https://www.openstack.org/summit/2020/summit-schedule

The virtual event takes place October 19-23 and includes more than 100 
sessions and thousands of attendees are expected to participate, 
representing 30+ open source communities from more than 100 countries.

Sessions for the virtual summit are led by users from global enterprises 
and research institutions building and operating open infrastructure at 
scale. The Summit includes:

- Sessions spanning 30+ open source projects from technical community 
leaders and organizations including Alibaba Cloud, AT&T, China Mobile, 
CERN, European Weather Cloud, GE Digital and Volvo Cars and many more.

- Collaborative sessions with project leaders and open source 
communities, including Airship, Ansible, Ceph, Docker, Kata Containers, 
Kubernetes, ONAP, OpenStack, Open vSwitch, OPNFV, StarlingX, and Zuul.

- Get hands on workshops around open source technologies directly from 
the developers and operators building the software.

- Familiarize with the updated Certified OpenStack Administrator (COA) 
exam and test your OpenStack knowledge at the COA sessions, sponsored by 
the OpenStack Foundation, in collaboration with Mirantis.

Now what?

Register[2] for your free virtual Summit pass and meet the users, 
developers, and vendors who are building and operating open 
infrastructure on October 19-23!

[2] 
https://www.eventbrite.com/e/open-infrastructure-summit-2020-tickets-96967218561

Thank you to our Summit Headline, Premier and Exhibitor sponsors: 
Huawei, Cisco, InMotion Hosting, Trilio and ZTE. Event sponsors gain 
visibility with a wide array of open source infrastructure developers, 
operators and decision makers. Download the Open Infrastructure Summit 
sponsor prospectus[3] for more information.

[3] https://www.openstack.org/summit/2020/sponsors/

Questions? Reach out to summit at openstack.org

“See you” in October!

Cheers,

-- 
Thierry Carrez (ttx)


From stephenfin at redhat.com  Wed Sep  9 15:48:14 2020
From: stephenfin at redhat.com (Stephen Finucane)
Date: Wed, 09 Sep 2020 16:48:14 +0100
Subject: [nova] Changes for out-of-tree drivers
Message-ID: <1dea07eda965f2a2f9a38b59d885fe905c62205b.camel@redhat.com>

We're aiming to remove the long-deprecated XenAPI driver before
Victoria ends. With that removed, there are a number of XenAPI-specific 
virt driver APIs that we plan to remove in follow-ups. These are noted
at [1]. If you maintain an out-of-tree driver, you will need to account
for these changes.

Cheers,
Stephen

[1] https://review.opendev.org/#/c/749300/1/nova/virt/driver.py



From mordred at inaugust.com  Wed Sep  9 16:10:52 2020
From: mordred at inaugust.com (Monty Taylor)
Date: Wed, 9 Sep 2020 11:10:52 -0500
Subject: Moving on
Message-ID: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>

Hi everybody,

After 10 years of OpenStack, the time has come for me to move on to the next challenge. Actually, the time came a few weeks ago, but writing farewells has always been something I’m particularly bad at. My last day at Red Hat was actually July 31 and I’m now working in a non-OpenStack job.

I’m at a loss for words as to what more to say. I’ve never done anything for 10 years before, and I’ll be very surprised if I do anything else for 10 years again. While I’m excited about the new things on my plate, I’ll obviously miss everyone.

As I am no longer being paid by an OpenStack employer, I will not be doing any OpenStack things as part of my day job. I’m not sure how much spare time I’ll have to be able to contribute. I’m going to hold off on resigning core memberships pending a better understanding of that. I think it’s safe to assume I won’t be able to continue on as SDK PTL though.

I wish everyone all the best, and I hope life conspires to keep us all connected.

Thank you to everyone for an amazing 10 years.

Monty

From amy at demarco.com  Wed Sep  9 16:17:31 2020
From: amy at demarco.com (Amy Marrich)
Date: Wed, 9 Sep 2020 11:17:31 -0500
Subject: Moving on
In-Reply-To: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
References: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
Message-ID: <CAFs83Qq_Z76USOjT27r2VJr4WJBca0rDLRBo37ArYv7tnh9Efg@mail.gmail.com>

Monty,

It has been a pleasure being in the community with you all these years and
I can't even begin to count or describe all you've done for it.

Thank you for being a part of the journey and best wishes on your future
endeavours.

Amy (spotz)

On Wed, Sep 9, 2020 at 11:11 AM Monty Taylor <mordred at inaugust.com> wrote:

> Hi everybody,
>
> After 10 years of OpenStack, the time has come for me to move on to the
> next challenge. Actually, the time came a few weeks ago, but writing
> farewells has always been something I’m particularly bad at. My last day at
> Red Hat was actually July 31 and I’m now working in a non-OpenStack job.
>
> I’m at a loss for words as to what more to say. I’ve never done anything
> for 10 years before, and I’ll be very surprised if I do anything else for
> 10 years again. While I’m excited about the new things on my plate, I’ll
> obviously miss everyone.
>
> As I am no longer being paid by an OpenStack employer, I will not be doing
> any OpenStack things as part of my day job. I’m not sure how much spare
> time I’ll have to be able to contribute. I’m going to hold off on resigning
> core memberships pending a better understanding of that. I think it’s safe
> to assume I won’t be able to continue on as SDK PTL though.
>
> I wish everyone all the best, and I hope life conspires to keep us all
> connected.
>
> Thank you to everyone for an amazing 10 years.
>
> Monty
> _______________________________________________
> Zuul-discuss mailing list
> Zuul-discuss at lists.zuul-ci.org
> http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200909/2750a1e7/attachment.html>

From fungi at yuggoth.org  Wed Sep  9 16:19:30 2020
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 9 Sep 2020 16:19:30 +0000
Subject: Moving on
In-Reply-To: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
References: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
Message-ID: <20200909161930.m2xichrlfmhu4tmv@yuggoth.org>

On 2020-09-09 11:10:52 -0500 (-0500), Monty Taylor wrote:
> After 10 years of OpenStack, the time has come for me to move on
> to the next challenge.
[...]

Don't think this gets you out of coming to visit once the current
crisis blows over!

Also, you won't be missed because I'll make sure to continue to
pester you with absurd questions. After all, you know where all the
bodies are buried.

Best of luck on your new gig!
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200909/80577e06/attachment.sig>

From artem.goncharov at gmail.com  Wed Sep  9 16:24:19 2020
From: artem.goncharov at gmail.com (Artem Goncharov)
Date: Wed, 9 Sep 2020 18:24:19 +0200
Subject: Moving on
In-Reply-To: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
References: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
Message-ID: <4248B7F8-BD6F-48F0-B510-5BBDD70D7EE6@gmail.com>

Thanks a lot, Monty, for doing such a great job in and for the community.

We will terribly miss chatting with you on a daily basis, but the life goes on, as you said. Your heritage is so huge, that taking it over is not something easy :-)


Definitely all of us would be glad to keep you core as long as you want and as long as at all possible (even agains your wish).

Best regards in your new life section and hope to still have chance to have a beer with you in person.

Artem

> On 9. Sep 2020, at 18:10, Monty Taylor <mordred at inaugust.com> wrote:
> 
> Hi everybody,
> 
> After 10 years of OpenStack, the time has come for me to move on to the next challenge. Actually, the time came a few weeks ago, but writing farewells has always been something I’m particularly bad at. My last day at Red Hat was actually July 31 and I’m now working in a non-OpenStack job.
> 
> I’m at a loss for words as to what more to say. I’ve never done anything for 10 years before, and I’ll be very surprised if I do anything else for 10 years again. While I’m excited about the new things on my plate, I’ll obviously miss everyone.
> 
> As I am no longer being paid by an OpenStack employer, I will not be doing any OpenStack things as part of my day job. I’m not sure how much spare time I’ll have to be able to contribute. I’m going to hold off on resigning core memberships pending a better understanding of that. I think it’s safe to assume I won’t be able to continue on as SDK PTL though.
> 
> I wish everyone all the best, and I hope life conspires to keep us all connected.
> 
> Thank you to everyone for an amazing 10 years.
> 
> Monty
> _______________________________________________
> Zuul-discuss mailing list
> Zuul-discuss at lists.zuul-ci.org
> http://lists.zuul-ci.org/cgi-bin/mailman/listinfo/zuul-discuss



From mnaser at vexxhost.com  Wed Sep  9 16:26:50 2020
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Wed, 9 Sep 2020 12:26:50 -0400
Subject: Moving on
In-Reply-To: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
References: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
Message-ID: <CAEs876jTvY=_mAxqST1FxKruDC_nFVqbU51H0_zcpUg0CJX32A@mail.gmail.com>

Thanks for everything Monty.

It's been a pleasure working alongside you since first meeting in
person at PyCon in Montreal, quite a long time ago. :)

Good luck with everything, and hope to see you in some way in the future :)

On Wed, Sep 9, 2020 at 12:11 PM Monty Taylor <mordred at inaugust.com> wrote:
>
> Hi everybody,
>
> After 10 years of OpenStack, the time has come for me to move on to the next challenge. Actually, the time came a few weeks ago, but writing farewells has always been something I’m particularly bad at. My last day at Red Hat was actually July 31 and I’m now working in a non-OpenStack job.
>
> I’m at a loss for words as to what more to say. I’ve never done anything for 10 years before, and I’ll be very surprised if I do anything else for 10 years again. While I’m excited about the new things on my plate, I’ll obviously miss everyone.
>
> As I am no longer being paid by an OpenStack employer, I will not be doing any OpenStack things as part of my day job. I’m not sure how much spare time I’ll have to be able to contribute. I’m going to hold off on resigning core memberships pending a better understanding of that. I think it’s safe to assume I won’t be able to continue on as SDK PTL though.
>
> I wish everyone all the best, and I hope life conspires to keep us all connected.
>
> Thank you to everyone for an amazing 10 years.
>
> Monty



-- 
Mohammed Naser
VEXXHOST, Inc.


From juliaashleykreger at gmail.com  Wed Sep  9 16:31:12 2020
From: juliaashleykreger at gmail.com (Julia Kreger)
Date: Wed, 9 Sep 2020 09:31:12 -0700
Subject: Moving on
In-Reply-To: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
References: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
Message-ID: <CAF7gwdiTBuzAn0Q=9HfzLUU+yg=XGWgVP79BHk_AJpn0OncFfQ@mail.gmail.com>

Monty,

It has been an absolute pleasure working with you, and I'm sure paths
will cross again in the future. Even if it is for just a good cup of
coffee or just a reunion of stackers.

-Julia

On Wed, Sep 9, 2020 at 9:12 AM Monty Taylor <mordred at inaugust.com> wrote:
>
> Hi everybody,
>
> After 10 years of OpenStack, the time has come for me to move on to the next challenge. Actually, the time came a few weeks ago, but writing farewells has always been something I’m particularly bad at. My last day at Red Hat was actually July 31 and I’m now working in a non-OpenStack job.
>
> I’m at a loss for words as to what more to say. I’ve never done anything for 10 years before, and I’ll be very surprised if I do anything else for 10 years again. While I’m excited about the new things on my plate, I’ll obviously miss everyone.
>
> As I am no longer being paid by an OpenStack employer, I will not be doing any OpenStack things as part of my day job. I’m not sure how much spare time I’ll have to be able to contribute. I’m going to hold off on resigning core memberships pending a better understanding of that. I think it’s safe to assume I won’t be able to continue on as SDK PTL though.
>
> I wish everyone all the best, and I hope life conspires to keep us all connected.
>
> Thank you to everyone for an amazing 10 years.
>
> Monty


From gmann at ghanshyammann.com  Wed Sep  9 16:46:13 2020
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 09 Sep 2020 11:46:13 -0500
Subject: Moving on
In-Reply-To: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
References: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
Message-ID: <17473c2b34c.fd061e2319472.3266951661606969893@ghanshyammann.com>

Thank you Monty for everything and being a learning model in the community.

You are one of the inspiring personalities for me in OSS world and motivate me to learn & do more.

-gmann


 ---- On Wed, 09 Sep 2020 11:10:52 -0500 Monty Taylor <mordred at inaugust.com> wrote ----
 > Hi everybody,
 > 
 > After 10 years of OpenStack, the time has come for me to move on to the next challenge. Actually, the time came a few weeks ago, but writing farewells has always been something I’m particularly bad at. My last day at Red Hat was actually July 31 and I’m now working in a non-OpenStack job.
 > 
 > I’m at a loss for words as to what more to say. I’ve never done anything for 10 years before, and I’ll be very surprised if I do anything else for 10 years again. While I’m excited about the new things on my plate, I’ll obviously miss everyone.
 > 
 > As I am no longer being paid by an OpenStack employer, I will not be doing any OpenStack things as part of my day job. I’m not sure how much spare time I’ll have to be able to contribute. I’m going to hold off on resigning core memberships pending a better understanding of that. I think it’s safe to assume I won’t be able to continue on as SDK PTL though.
 > 
 > I wish everyone all the best, and I hope life conspires to keep us all connected.
 > 
 > Thank you to everyone for an amazing 10 years.
 > 
 > Monty
 > 


From kevin at cloudnull.com  Wed Sep  9 16:55:18 2020
From: kevin at cloudnull.com (Carter, Kevin)
Date: Wed, 9 Sep 2020 11:55:18 -0500
Subject: Moving on
In-Reply-To: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
References: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
Message-ID: <CAAG3CGpW3ZyS7RNWF827Y=u7vsKBje1JF6n+pe9BGCdX9kFdiQ@mail.gmail.com>

It's been an absolute pleasure working with you. Thank you for everything
you've done for the community, in and outside of OpenStack.

Please keep in touch. I'd love to know more about your new endeavours,
which I'm sure will be wildly successful.

--

Kevin Carter
IRC: Cloudnull


On Wed, Sep 9, 2020 at 11:16 AM Monty Taylor <mordred at inaugust.com> wrote:

> Hi everybody,
>
> After 10 years of OpenStack, the time has come for me to move on to the
> next challenge. Actually, the time came a few weeks ago, but writing
> farewells has always been something I’m particularly bad at. My last day at
> Red Hat was actually July 31 and I’m now working in a non-OpenStack job.
>
> I’m at a loss for words as to what more to say. I’ve never done anything
> for 10 years before, and I’ll be very surprised if I do anything else for
> 10 years again. While I’m excited about the new things on my plate, I’ll
> obviously miss everyone.
>
> As I am no longer being paid by an OpenStack employer, I will not be doing
> any OpenStack things as part of my day job. I’m not sure how much spare
> time I’ll have to be able to contribute. I’m going to hold off on resigning
> core memberships pending a better understanding of that. I think it’s safe
> to assume I won’t be able to continue on as SDK PTL though.
>
> I wish everyone all the best, and I hope life conspires to keep us all
> connected.
>
> Thank you to everyone for an amazing 10 years.
>
> Monty
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200909/9744d818/attachment.html>

From openstack at nemebean.com  Wed Sep  9 17:04:51 2020
From: openstack at nemebean.com (Ben Nemec)
Date: Wed, 9 Sep 2020 12:04:51 -0500
Subject: [oslo][release][requirement] FFE request for Oslo lib
In-Reply-To: <1746e64d702.ee80b0bc1249.5426348472779199647@ghanshyammann.com>
References: <1746e64d702.ee80b0bc1249.5426348472779199647@ghanshyammann.com>
Message-ID: <bc93768b-cf66-d66b-5fc6-78ac07797991@nemebean.com>


On 9/8/20 10:45 AM, Ghanshyam Mann wrote:
> Hello Team,
> 
> This is regarding FFE for Focal migration work. As planned, we have to move the Victoria testing to Focal and
> base job switch is planned to be switched by today[1].
> 
> There are few oslo lib need work (especially tox job-based testing not user-facing changes) to pass on Focal
> - https://review.opendev.org/#/q/topic:migrate-to-focal-oslo+(status:open+OR+status:merged)
> 
> If we move the base tox jobs to Focal then these lib victoria gates (especially lower-constraint job) will be failing.
> We can either do these as FFE or backport (as this is lib own CI fixes only) later once the victoria branch is open.
>   
> Opinion?

As I noted in the meeting, if we have to do this to keep the gates 
working then I'd rather do it as an FFE than have to backport all of the 
relevant patches. IMHO we should only decline this FFE if we are going 
to also change our statement of support for Python/Ubuntu in Victoria.

> 
> [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017060.html
> 
> -gmann
> 
> 


From jungleboyj at gmail.com  Wed Sep  9 17:32:39 2020
From: jungleboyj at gmail.com (Jay Bryant)
Date: Wed, 9 Sep 2020 12:32:39 -0500
Subject: Moving on
In-Reply-To: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
References: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
Message-ID: <2b723849-a83e-16e0-c920-2eeecfd382fa@gmail.com>

Monty,

It has been great to work with you through OpenStack.  Thank you for all 
you have done to support the community and keep it innovative.

Best of luck at your next endeavor and I look forward to crossing paths 
with you in the future!

Best wishes,

Jay


On 9/9/2020 11:10 AM, Monty Taylor wrote:
> Hi everybody,
>
> After 10 years of OpenStack, the time has come for me to move on to the next challenge. Actually, the time came a few weeks ago, but writing farewells has always been something I’m particularly bad at. My last day at Red Hat was actually July 31 and I’m now working in a non-OpenStack job.
>
> I’m at a loss for words as to what more to say. I’ve never done anything for 10 years before, and I’ll be very surprised if I do anything else for 10 years again. While I’m excited about the new things on my plate, I’ll obviously miss everyone.
>
> As I am no longer being paid by an OpenStack employer, I will not be doing any OpenStack things as part of my day job. I’m not sure how much spare time I’ll have to be able to contribute. I’m going to hold off on resigning core memberships pending a better understanding of that. I think it’s safe to assume I won’t be able to continue on as SDK PTL though.
>
> I wish everyone all the best, and I hope life conspires to keep us all connected.
>
> Thank you to everyone for an amazing 10 years.
>
> Monty


From yan.y.zhao at intel.com  Wed Sep  9 02:13:09 2020
From: yan.y.zhao at intel.com (Yan Zhao)
Date: Wed, 9 Sep 2020 10:13:09 +0800
Subject: device compatibility interface for live migration with assigned
 devices
In-Reply-To: <20200908164130.2fe0d106.cohuck@redhat.com>
References: <20200818113652.5d81a392.cohuck@redhat.com>
 <20200820003922.GE21172@joy-OptiPlex-7040>
 <20200819212234.223667b3@x1.home>
 <20200820031621.GA24997@joy-OptiPlex-7040>
 <20200825163925.1c19b0f0.cohuck@redhat.com>
 <20200826064117.GA22243@joy-OptiPlex-7040>
 <20200828154741.30cfc1a3.cohuck@redhat.com>
 <8f5345be73ebf4f8f7f51d6cdc9c2a0d8e0aa45e.camel@redhat.com>
 <20200831044344.GB13784@joy-OptiPlex-7040>
 <20200908164130.2fe0d106.cohuck@redhat.com>
Message-ID: <20200909021308.GA1277@joy-OptiPlex-7040>

> > still, I'd like to put it more explicitly to make ensure it's not missed:
> > the reason we want to specify compatible_type as a trait and check
> > whether target compatible_type is the superset of source
> > compatible_type is for the consideration of backward compatibility.
> > e.g.
> > an old generation device may have a mdev type xxx-v4-yyy, while a newer
> > generation  device may be of mdev type xxx-v5-yyy.
> > with the compatible_type traits, the old generation device is still
> > able to be regarded as compatible to newer generation device even their
> > mdev types are not equal.
> 
> If you want to support migration from v4 to v5, can't the (presumably
> newer) driver that supports v5 simply register the v4 type as well, so
> that the mdev can be created as v4? (Just like QEMU versioned machine
> types work.)
yes, it should work in some conditions.
but it may not be that good in some cases when v5 and v4 in the name string
of mdev type identify hardware generation (e.g. v4 for gen8, and v5 for
gen9)

e.g.
(1). when src mdev type is v4 and target mdev type is v5 as
software does not support it initially, and v4 and v5 identify hardware
differences.
then after software upgrade, v5 is now compatible to v4, should the
software now downgrade mdev type from v5 to v4?
not sure if moving hardware generation info into a separate attribute
from mdev type name is better. e.g. remove v4, v5 in mdev type, while use
compatible_pci_ids to identify compatibility.

(2) name string of mdev type is composed by "driver_name + type_name".
in some devices, e.g. qat, different generations of devices are binding to
drivers of different names, e.g. "qat-v4", "qat-v5".
then though type_name is equal, mdev type is not equal. e.g.
"qat-v4-type1", "qat-v5-type1".

Thanks
Yan



From yan.y.zhao at intel.com  Wed Sep  9 05:37:56 2020
From: yan.y.zhao at intel.com (Yan Zhao)
Date: Wed, 9 Sep 2020 13:37:56 +0800
Subject: device compatibility interface for live migration with assigned
 devices
In-Reply-To: <20200831044344.GB13784@joy-OptiPlex-7040>
References: <20200818091628.GC20215@redhat.com>
 <20200818113652.5d81a392.cohuck@redhat.com>
 <20200820003922.GE21172@joy-OptiPlex-7040>
 <20200819212234.223667b3@x1.home>
 <20200820031621.GA24997@joy-OptiPlex-7040>
 <20200825163925.1c19b0f0.cohuck@redhat.com>
 <20200826064117.GA22243@joy-OptiPlex-7040>
 <20200828154741.30cfc1a3.cohuck@redhat.com>
 <8f5345be73ebf4f8f7f51d6cdc9c2a0d8e0aa45e.camel@redhat.com>
 <20200831044344.GB13784@joy-OptiPlex-7040>
Message-ID: <20200909053755.GA721@joy-OptiPlex-7040>

hi All,
Per our previous discussion, there are two main concerns to the previous
proposal:
(1) it's currently hard for openstack to match mdev types.
(2) complicated.

so, we further propose below changes:
(1) requiring two compatible mdevs to have the same mdev type for now.
    (though kernel still exposes compatible_type attributes for future use)  
(2) requiring 1:1 match for other attributes under sysfs type node for now
    (those attributes are specified via compatible_<attribute name> but
    with only 1 value in it.)
(3) do not match attributes under device instance node.
    rather, they are regarded as part of resource claiming process.
    so src and dest values are ensured to be 1:1.
    A dynamic_resources attribute under sysfs <type-id> node is added to
    list the attributes under device instance that mgt tools need to
    ensure 1:1 from src and dest.
    the "aggregator" attribute under device instance node is such one that
    needs to be listed.
    Those listed attributes can actually be treated as device state set by
    vendor driver during live migration. but we still want to ask for them to
    be set by mgt tools before live migration starts, in oder to reduce the
    chance of live migration failure.

do you like those changes?

after the changes, the sysfs interface would look like blow:

  |- [parent physical device]
  |--- Vendor-specific-attributes [optional]
  |--- [mdev_supported_types]
  |     |--- [<type-id>]
  |     |   |--- create
  |     |   |--- name
  |     |   |--- available_instances
  |     |   |--- device_api
  |     |   |--- software_version
  |     |   |--- compatible_type
  |     |   |--- compatible_<device_api_specific_field>
  |     |   |--- compatible_<type_specific_field>
  |     |   |--- dynamic_resources
  |     |   |--- description
  |     |   |--- [devices]

- device_api : exact match between src and dest is required.
               its value can be one of 
               "vfio-pci", "vfio-platform", "vfio-amba", "vfio-ccw", "vfio-ap"
- software_version: version of vendor driver.
                    in major.minor.bugfix scheme. 
                    dest major should be equal to src major,
	            dest minor should be no less than src minor.
		    once migration stream related code changed, vendor
		    drivers need to bump the version.
- compatible_type: not used by mgt tools currently.
                   vendor drivers can provide this attribute, but need to
		   know that mgt apps would ignore it.
		   when in future mgt tools support this attribute, it
		   would allow migration across different mdev types,
		   so that devices of older generation may be able to
		   migrate to newer generations.

- compatible_<device_api_specific_field>: for device api specific attributes,
                  e.g. compatible_subchannel_type,
                  dest values should be superset of arc values.
		  vendor drivers can specify only one value in this attribute,
		  in order to do exact match between src and dest.
		  It's ok for mgt tools to only read one value in the
		  attribute so that src:dest values are 1:1.

- compatible_<type_specific_field>: for mdev type specific attributes,
                  e.g. compatible_pci_ids, compatible_chpid_type
                  dest values should be superset of arc values.
		  vendor drivers can specify only one value in the attribute
		  in order to do exact match between src and dest.
		  It's ok for mgt tools to only read one value in the
		  attribute so that src:dest values are 1:1.

- dynamic_resources: though defined statically under <type-id>,
                  this attribute lists attributes under device instance that
		  need to be set as part of claiming dest resources.
		  e.g. $cat dynamic_resources: aggregator, fps,...
		  then after dest device is created, values of its device
		  attributes need to be set to that of src device attributes.
		  Failure in syncing src device values to dest device
		  values is treated the same as failing to claiming
		  dest resources.
		  attributes under device instance that are not listed
		  in this attribute would not be part of resource checking in
		  mgt tools.



Thanks
Yan


From jungleboyj at gmail.com  Wed Sep  9 18:23:14 2020
From: jungleboyj at gmail.com (Jay Bryant)
Date: Wed, 9 Sep 2020 13:23:14 -0500
Subject: [tc] monthly meeting
In-Reply-To: <CAEs876gdBj5oGm=KWrHUJ8dGg43O8ZbgjNWN57kJpcULcy014Q@mail.gmail.com>
References: <CAEs876gdBj5oGm=KWrHUJ8dGg43O8ZbgjNWN57kJpcULcy014Q@mail.gmail.com>
Message-ID: <f8071c86-3f2a-9028-bcdf-a44205efb11f@gmail.com>

All,

Apologies for not making the meeting and for not getting caught up on 
e-mail until now.    Was on vacation last week.

Jay


On 9/2/2020 2:06 PM, Mohammed Naser wrote:
> Hi everyone,
>
> Here’s the agenda for our monthly TC meeting. It will happen tomorrow
> (Thursday the 3rd) at 1400 UTC in #openstack-tc and I will be your
> chair.
>
> If you can’t attend, please put your name in the “Apologies for
> Absence” section.
>
> https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting
>
> ## ACTIVE INITIATIVES
> * Follow up on past action items
> * OpenStack User-facing APIs and CLIs (belmoreira)
> * W cycle goal selection start
> * Completion of retirement cleanup (gmann):
> https://etherpad.opendev.org/p/tc-retirement-cleanup
> * Audit and clean-up tags (gmann)
> + Remove tc:approved-release tag https://review.opendev.org/#/c/749363
>
> Thank you,
> Mohammed
>


From kennelson11 at gmail.com  Wed Sep  9 18:28:18 2020
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Wed, 9 Sep 2020 11:28:18 -0700
Subject: vPTG October 2020 Team Signup Reminder
In-Reply-To: <5F13B10F-C0C5-4761-8AD2-9B3A55F67441@openstack.org>
References: <5F13B10F-C0C5-4761-8AD2-9B3A55F67441@openstack.org>
Message-ID: <CAJ6yrQjGCT+pMxM0BJMcQ4Z2B8fFQqVcFkzPghFM=H+h3ye1sQ@mail.gmail.com>

Hello Everyone!

This is your final reminder! You have until *September 11th at 7:00 UTC to
sign up your team for the PTG! You must complete **BOTH** the survey[1] AND
reserve time in the ethercalc[2] to sign up your team. *

And don't forget to register! [3]

- TheKendalls (diablo_rojo & wendallkaters)

[1] Team Survey:
https://openstackfoundation.formstack.com/forms/oct2020_vptg_survey
[2] Ethercalc Signup: https://ethercalc.openstack.org/7xp2pcbh1ncb
[3] PTG Registration: https://october2020ptg.eventbrite.com

On Mon, Aug 31, 2020 at 10:39 AM Kendall Waters <kendall at openstack.org>
wrote:

> Hello Everyone!
>
> Wanted to give you all a reminder that the deadline for signing up teams
> for the PTG is approaching!
>
> The virtual PTG will be held from Monday October 26th to Friday October
> 30th, 2020.
>
> *To signup your team, you must complete **BOTH** the survey[1] AND
> reserve time in the ethercalc[2] by September 11th at 7:00 UTC.*
>
> We ask that the PTL/SIG Chair/Team lead sign up for time to have their
> discussions in with 4 rules/guidelines.
>
> 1. Cross project discussions (like SIGs or support project teams) should
> be scheduled towards the start of the week so that any discussions that
> might shape those of other teams happen first.
> 2. No team should sign up for more than 4 hours per UTC day to help keep
> participants actively engaged.
> 3. No team should sign up for more than 16 hours across all time slots to
> avoid burning out our contributors and to enable participation in multiple
> teams discussions.
>
> Once your team is signed up, please register[3]! And remind your team to
> register! Registration is free, but since it will be how we contact you
> with passwords, event details, etc. it is still important!
>
> If you have any questions, please let us know.
>
> -The Kendalls (diablo_rojo & wendallkaters)
>
> [1] Team Survey:
> https://openstackfoundation.formstack.com/forms/oct2020_vptg_survey
> [2] Ethercalc Signup: https://ethercalc.openstack.org/7xp2pcbh1ncb
> [3] PTG Registration: https://october2020ptg.eventbrite.com
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200909/c6417b54/attachment.html>

From gmann at ghanshyammann.com  Wed Sep  9 19:05:17 2020
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 09 Sep 2020 14:05:17 -0500
Subject: [all][tc][goals] Migrate CI/CD jobs to new Ubuntu LTS Focal:
 Week R-4 Update
In-Reply-To: <1746feef403.c41c848411058.2421030943223377212@ghanshyammann.com>
References: <17468f8f785.1123a07e6307801.3844845549431858647@ghanshyammann.com>
 <1746feef403.c41c848411058.2421030943223377212@ghanshyammann.com>
Message-ID: <1747442027f.bb3f3d1823475.212800600164097649@ghanshyammann.com>

 ---- On Tue, 08 Sep 2020 17:56:05 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > Updates:
 > After working more on failing one today and listing the blocking one, I think we are good to switch tox based testing today
 > and discuss the integration testing switch tomorrow in TC office hours. 
 > 
 > > * Part1: Migrating tox base job tomorrow (8th Sept):
 >  
 > I have checked it again and fixed many repos that are up for review and merge. Most python clients are already fixed
 > or their fixes are up for merge so they can make it before the feature freeze on 10th. If any repo is broken then it will be pretty quick
 > to fix by lower constraint bump (see the example under https://review.opendev.org/#/q/topic:migrate-to-focal)
 > 
 > Even if any of the fixes miss the victoria release then those can be backported easily. I am opening the tox base jobs migration to merge: 
 >  - All patches in this series https://review.opendev.org/#/c/738328/

All these tox base jobs are merged now and running on Focal. If any of your repo is failing, please fix on priority or ping me on IRC if failure not clear.
You can find most of the fixes for possible failure in this topic:
- https://review.opendev.org/#/q/topic:migrate-to-focal+(status:open+OR+status:merged)

-gmann


 > 
 > 
 >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
 > 
 > We have three blocking open bugs here so I would like to discuss it in tomorrow's TC office hour also about how to proceed on this.
 > 
 > 1. Nova: https://bugs.launchpad.net/nova/+bug/1882521  (https://bugs.launchpad.net/qemu/+bug/1894804)
 > 2. Barbican: https://storyboard.openstack.org/#!/story/2007732
 > 3. Ceilometer: https://storyboard.openstack.org/#!/story/2008121
 > 
 > 
 > -gmann
 > 
 > 
 >  ---- On Mon, 07 Sep 2020 09:29:40 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 >  > Hello Everyone,
 >  > 
 >  > Please find the week R-4 updates on 'Ubuntu Focal migration' community goal. Its time to force the base jobs migration which can
 >  > break the projects gate if not yet taken care of. Read below for the plan.
 >  > 
 >  > Tracking: https://storyboard.openstack.org/#!/story/2007865
 >  > 
 >  > Progress:
 >  > =======
 >  > * We are close to V-3 release and this is time we have to complete this migration otherwise doing it in RC period can add
 >  > unnecessary and last min delay. I am going to plan this migration in two-part. This will surely break some projects gate
 >  > which is not yet finished the migration but we have to do at some time. Please let me know if any objection to the below
 >  > plan.
 >  > 
 >  > * Part1: Migrating tox base job tomorrow (8th Sept):
 >  > 
 >  > ** I am going to open tox base jobs migration (doc, unit, functional, lower-constraints etc) to merge by tomorrow. which is this
 >  > series (all base patches of this):  https://review.opendev.org/#/c/738328/ . 
 >  > 
 >  > **There are few repos still failing on requirements lower-constraints job specifically which I tried my best to fix as many as possible.
 >  >  Many are ready to merge also. Please merge or work on your projects repo testing before that or fix on priority if failing.
 >  > 
 >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
 >  > 
 >  > * We have few open bugs for this which are not yet resolved, we will see how it goes but the current plan is to migrate by 10th Sept.
 >  > 
 >  > ** Bug#1882521
 >  > ** DB migration issues,
 >  > *** alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003
 >  > 
 >  > 
 >  > Testing Till now:
 >  > ============
 >  > * ~200 repos gate have been tested or fixed till now.
 >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+(status:abandoned+OR+status:merged)
 >  > 
 >  > * ~100 repos are under test and failing. Debugging and fixing are in progress (If you would like to help, please check your
 >  > project repos if I am late to fix them):
 >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open
 >  > 
 >  > * ~30repos fixes ready to merge:
 >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open+label%3AVerified%3E%3D1%2Czuul+NOT+label%3AWorkflow%3C%3D-1
 >  > 
 >  > 
 >  > Bugs Report:
 >  > ==========
 >  > 
 >  > 1. Bug#1882521. (IN-PROGRESS)
 >  > There is open bug for nova/cinder where three tempest tests are failing for
 >  > volume detach operation. There is no clear root cause found yet
 >  > -https://bugs.launchpad.net/cinder/+bug/1882521
 >  > We have skipped the tests in tempest base patch to proceed with the other
 >  > projects testing but this is blocking things for the migration.
 >  > 
 >  > 2. DB migration issues (IN-PROGRESS)
 >  > * alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003
 >  > 
 >  > 3. We encountered the nodeset name conflict with x/tobiko. (FIXED)
 >  > nodeset conflict is resolved now and devstack provides all focal nodes now.
 >  > 
 >  > 4. Bug#1886296. (IN-PROGRESS)
 >  > pyflakes till 2.1.0 is not compatible with python 3.8 which is the default python version
 >  > on ubuntu focal[1]. With pep8 job running on focal faces the issue and fail. We need to bump
 >  > the pyflakes to 2.1.1 as min version to run pep8 jobs on py3.8.
 >  > As of now, many projects are using old hacking version so I am explicitly adding pyflakes>=2.1.1
 >  > on the project side[2] but for the long term easy maintenance, I am doing it in 'hacking' requirements.txt[3]
 >  > nd will release a new hacking version. After that project can move to new hacking and do not need
 >  > to maintain pyflakes version compatibility.
 >  > 
 >  > 5. Bug#1886298. (IN-PROGRESS)
 >  > 'Markupsafe' 1.0 is not compatible with the latest version of setuptools[4],
 >  > We need to bump the lower-constraint for Markupsafe to 1.1.1 to make it work.
 >  > There are a few more issues[5] with lower-constraint jobs which I am debugging.
 >  > 
 >  > 
 >  > What work to be done on the project side:
 >  > ================================
 >  > This goal is more of testing the jobs on focal and fixing bugs if any otherwise
 >  > migrate jobs by switching the nodeset to focal node sets defined in devstack.
 >  > 
 >  > 1. Start a patch in your repo by making depends-on on either of below:
 >  > devstack base patch if you are using only devstack base jobs not tempest:
 >  > 
 >  > Depends-on: https://review.opendev.org/#/c/731207/
 >  > OR
 >  > tempest base patch if you are using the tempest base job (like devstack-tempest):
 >  > Depends-on: https://review.opendev.org/#/c/734700/
 >  > 
 >  > Both have depends-on on the series where I am moving unit/functional/doc/cover/nodejs tox jobs to focal. So
 >  > you can test the complete gate jobs(unit/functional/doc/integration) together.
 >  > This and its base patches - https://review.opendev.org/#/c/738328/
 >  > 
 >  > Example: https://review.opendev.org/#/c/738126/
 >  > 
 >  > 2. If none of your project jobs override the nodeset then above patch will be
 >  > testing patch(do not merge) otherwise change the nodeset to focal.
 >  > Example: https://review.opendev.org/#/c/737370/
 >  > 
 >  > 3. If the jobs are defined in branchless repo and override the nodeset then you need to override the branches
 >  > variant to adjust the nodeset so that those jobs run on Focal on victoria onwards only. If no nodeset
 >  > is overridden then devstack being branched and stable base job using bionic/xenial will take care of
 >  > this.
 >  > Example: https://review.opendev.org/#/c/744056/2
 >  > 
 >  > 4. If no updates need you can abandon the testing patch (https://review.opendev.org/#/c/744341/). If it need
 >  > updates then modify the same patch with proper commit msg, once it pass the gate then remove the Depends-On
 >  > so that you can merge your patch before base jobs are switched to focal. This way we make sure no gate downtime in
 >  > this migration.
 >  > Example: https://review.opendev.org/#/c/744056/1..2//COMMIT_MSG
 >  > 
 >  > Once we finish the testing on projects side and no failure then we will merge the devstack and tempest
 >  > base patches.
 >  > 
 >  > 
 >  > Important things to note:
 >  > ===================
 >  > * Do not forgot to add the story and task link to your patch so that we can track it smoothly.
 >  > * Use gerrit topic 'migrate-to-focal'
 >  > * Do not backport any of the patches.
 >  > 
 >  > 
 >  > References:
 >  > =========
 >  > Goal doc: https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-jobs-to-ubuntu-focal.html
 >  > Storyboard tracking: https://storyboard.openstack.org/#!/story/2007865
 >  > 
 >  > [1] https://github.com/PyCQA/pyflakes/issues/367
 >  > [2] https://review.opendev.org/#/c/739315/
 >  > [3] https://review.opendev.org/#/c/739334/
 >  > [4] https://github.com/pallets/markupsafe/issues/116
 >  > [5] https://zuul.opendev.org/t/openstack/build/7ecd9cf100194bc99b3b70fa1e6de032
 >  > 
 >  > -gmann
 >  > 
 >  > 
 > 
 > 


From kennelson11 at gmail.com  Wed Sep  9 19:21:52 2020
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Wed, 9 Sep 2020 12:21:52 -0700
Subject: [tc] [all] Topics for Cross Community Discussion with Kubernetes
 ...
In-Reply-To: <e835baa5-38fe-e8af-56bf-7ceaacdf5cfa@gmail.com>
References: <e835baa5-38fe-e8af-56bf-7ceaacdf5cfa@gmail.com>
Message-ID: <CAJ6yrQi2qivWL6qaHGHZMeizfYv2eGfLyRar_8LzNM5D6Gus_g@mail.gmail.com>

Hello :)

Wanted to revive this thread and see if we maybe wanted to add it to our
PTG topics? We could maybe see if any of them are available/want to join
our PTG sessions to chat about things.

-Kendall (diablo_rojo)

On Fri, Jul 10, 2020 at 5:33 AM Jay Bryant <jungleboyj at gmail.com> wrote:

> All,
>
> Recently, the OpenStack TC has reached out to the Kubernetes Steering
> Committee for input as we have proposed adding a
> starter-kit:kubernetes-in-virt tag for projects in OpenStack. This
> request was received positively and as a result the TC has started
> brainstorming other topics that we could approach with the k8s community
> in this [1] etherpad.
>
> If you have topics that may be appropriate for this discussion please
> see the etherpad and add your ideas.
>
> Thanks!
>
> Jay
>
> IRC: jungleboyj
>
> [1] https://etherpad.opendev.org/p/kubernetes-cross-community-topics
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200909/04e132f7/attachment.html>

From fungi at yuggoth.org  Wed Sep  9 19:24:55 2020
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Wed, 9 Sep 2020 19:24:55 +0000
Subject: [infra][tact-sig] October 2020 vPTG space for TaCT SIG work
Message-ID: <20200909183945.sw2mvkhoqlqb4nql@yuggoth.org>

Just one last quick check, does anyone think we need dedicated TaCT
SIG space in the vPTG schedule? I can snag some for us if so.

There seemed to be some consensus on IRC that the OpenStack Testing
and Collaboration Tools SIG can just glom onto OpenDev and OpenStack
QA team vPTG sessions where relevant, which seems entirely prudent
to me, and means we don't need our own separate times to talk about
things which are neither relevant to OpenDev nor QA (which I
estimate to be roughly nil).
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200909/a525c8e9/attachment.sig>

From mthode at mthode.org  Wed Sep  9 19:25:43 2020
From: mthode at mthode.org (Matthew Thode)
Date: Wed, 9 Sep 2020 14:25:43 -0500
Subject: [oslo][release][requirement] FFE request for Oslo lib
In-Reply-To: <bc93768b-cf66-d66b-5fc6-78ac07797991@nemebean.com>
References: <1746e64d702.ee80b0bc1249.5426348472779199647@ghanshyammann.com>
 <bc93768b-cf66-d66b-5fc6-78ac07797991@nemebean.com>
Message-ID: <20200909192543.b2d2ksruoqtbgcfy@mthode.org>

On 20-09-09 12:04:51, Ben Nemec wrote:
> 
> On 9/8/20 10:45 AM, Ghanshyam Mann wrote:
> > Hello Team,
> > 
> > This is regarding FFE for Focal migration work. As planned, we have to move the Victoria testing to Focal and
> > base job switch is planned to be switched by today[1].
> > 
> > There are few oslo lib need work (especially tox job-based testing not user-facing changes) to pass on Focal
> > - https://review.opendev.org/#/q/topic:migrate-to-focal-oslo+(status:open+OR+status:merged)
> > 
> > If we move the base tox jobs to Focal then these lib victoria gates (especially lower-constraint job) will be failing.
> > We can either do these as FFE or backport (as this is lib own CI fixes only) later once the victoria branch is open.
> > Opinion?
> 
> As I noted in the meeting, if we have to do this to keep the gates working
> then I'd rather do it as an FFE than have to backport all of the relevant
> patches. IMHO we should only decline this FFE if we are going to also change
> our statement of support for Python/Ubuntu in Victoria.
> 
> > 
> > [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017060.html
> > 
> > -gmann
> > 
> > 
> 

https://review.opendev.org/#/c/750089 seems like the only functional
change.  It has my ACK with my requirements hat on.

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

From jungleboyj at gmail.com  Wed Sep  9 19:26:21 2020
From: jungleboyj at gmail.com (Jay Bryant)
Date: Wed, 9 Sep 2020 14:26:21 -0500
Subject: [tc] [all] Topics for Cross Community Discussion with Kubernetes
 ...
In-Reply-To: <CAJ6yrQi2qivWL6qaHGHZMeizfYv2eGfLyRar_8LzNM5D6Gus_g@mail.gmail.com>
References: <e835baa5-38fe-e8af-56bf-7ceaacdf5cfa@gmail.com>
 <CAJ6yrQi2qivWL6qaHGHZMeizfYv2eGfLyRar_8LzNM5D6Gus_g@mail.gmail.com>
Message-ID: <8ed717c5-aa88-fe07-ae58-ca0fdf3c35d8@gmail.com>


On 9/9/2020 2:21 PM, Kendall Nelson wrote:
> Hello :)
>
> Wanted to revive this thread and see if we maybe wanted to add it to 
> our PTG topics? We could maybe see if any of them are available/want 
> to join our PTG sessions to chat about things.
>
> -Kendall (diablo_rojo)
>

Kendall,

Thank you for reviving this.  I think this would be good to add to the 
agenda for our PTG topics and to invite k8s people to join if possible.

Jay

> On Fri, Jul 10, 2020 at 5:33 AM Jay Bryant <jungleboyj at gmail.com 
> <mailto:jungleboyj at gmail.com>> wrote:
>
>     All,
>
>     Recently, the OpenStack TC has reached out to the Kubernetes Steering
>     Committee for input as we have proposed adding a
>     starter-kit:kubernetes-in-virt tag for projects in OpenStack. This
>     request was received positively and as a result the TC has started
>     brainstorming other topics that we could approach with the k8s
>     community
>     in this [1] etherpad.
>
>     If you have topics that may be appropriate for this discussion please
>     see the etherpad and add your ideas.
>
>     Thanks!
>
>     Jay
>
>     IRC: jungleboyj
>
>     [1] https://etherpad.opendev.org/p/kubernetes-cross-community-topics
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200909/a7ec7ef0/attachment.html>

From tpb at dyncloud.net  Wed Sep  9 19:33:09 2020
From: tpb at dyncloud.net (Tom Barron)
Date: Wed, 9 Sep 2020 15:33:09 -0400
Subject: [tc] [all] Topics for Cross Community Discussion with Kubernetes
 ...
In-Reply-To: <CAJ6yrQi2qivWL6qaHGHZMeizfYv2eGfLyRar_8LzNM5D6Gus_g@mail.gmail.com>
References: <e835baa5-38fe-e8af-56bf-7ceaacdf5cfa@gmail.com>
 <CAJ6yrQi2qivWL6qaHGHZMeizfYv2eGfLyRar_8LzNM5D6Gus_g@mail.gmail.com>
Message-ID: <20200909193309.cpjuda2y2jqsht5a@barron.net>

On 09/09/20 12:21 -0700, Kendall Nelson wrote:
>Hello :)
>
>Wanted to revive this thread and see if we maybe wanted to add it to our
>PTG topics? We could maybe see if any of them are available/want to join
>our PTG sessions to chat about things.
>
>-Kendall (diablo_rojo)

+1, and I'd love to join the sessions.

>
>On Fri, Jul 10, 2020 at 5:33 AM Jay Bryant <jungleboyj at gmail.com> wrote:
>
>> All,
>>
>> Recently, the OpenStack TC has reached out to the Kubernetes Steering
>> Committee for input as we have proposed adding a
>> starter-kit:kubernetes-in-virt tag for projects in OpenStack. This
>> request was received positively and as a result the TC has started
>> brainstorming other topics that we could approach with the k8s community
>> in this [1] etherpad.
>>
>> If you have topics that may be appropriate for this discussion please
>> see the etherpad and add your ideas.
>>
>> Thanks!
>>
>> Jay
>>
>> IRC: jungleboyj
>>
>> [1] https://etherpad.opendev.org/p/kubernetes-cross-community-topics
>>
>>
>>


From alexis.deberg at ubisoft.com  Wed Sep  9 18:30:55 2020
From: alexis.deberg at ubisoft.com (Alexis Deberg)
Date: Wed, 9 Sep 2020 18:30:55 +0000
Subject: [neutron] Flow drop on agent restart with openvswitch firewall
 driver
In-Reply-To: <20200909075042.qyxbnq7li2zm5oo4@skaplons-mac>
References: <DM6PR17MB36108DF4942A4B8C72675D73F2290@DM6PR17MB3610.namprd17.prod.outlook.com>,
 <20200909075042.qyxbnq7li2zm5oo4@skaplons-mac>
Message-ID: <DM6PR17MB361085CE869B739505B1C5EDF2260@DM6PR17MB3610.namprd17.prod.outlook.com>

Sure, opened https://bugs.launchpad.net/neutron/+bug/1895038 with all the details I got at hand.
As I said in the bug report, I'll try to reproduce with a up to date devstack asap.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200909/271e58c4/attachment-0001.html>

From gmann at ghanshyammann.com  Wed Sep  9 19:54:05 2020
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 09 Sep 2020 14:54:05 -0500
Subject: [oslo][release][requirement] FFE request for Oslo lib
In-Reply-To: <20200909192543.b2d2ksruoqtbgcfy@mthode.org>
References: <1746e64d702.ee80b0bc1249.5426348472779199647@ghanshyammann.com>
 <bc93768b-cf66-d66b-5fc6-78ac07797991@nemebean.com>
 <20200909192543.b2d2ksruoqtbgcfy@mthode.org>
Message-ID: <174746eb120.1229d07d224552.356509349559116522@ghanshyammann.com>


 ---- On Wed, 09 Sep 2020 14:25:43 -0500 Matthew Thode <mthode at mthode.org> wrote ----
 > On 20-09-09 12:04:51, Ben Nemec wrote:
 > > 
 > > On 9/8/20 10:45 AM, Ghanshyam Mann wrote:
 > > > Hello Team,
 > > > 
 > > > This is regarding FFE for Focal migration work. As planned, we have to move the Victoria testing to Focal and
 > > > base job switch is planned to be switched by today[1].
 > > > 
 > > > There are few oslo lib need work (especially tox job-based testing not user-facing changes) to pass on Focal
 > > > - https://review.opendev.org/#/q/topic:migrate-to-focal-oslo+(status:open+OR+status:merged)
 > > > 
 > > > If we move the base tox jobs to Focal then these lib victoria gates (especially lower-constraint job) will be failing.
 > > > We can either do these as FFE or backport (as this is lib own CI fixes only) later once the victoria branch is open.
 > > > Opinion?
 > > 
 > > As I noted in the meeting, if we have to do this to keep the gates working
 > > then I'd rather do it as an FFE than have to backport all of the relevant
 > > patches. IMHO we should only decline this FFE if we are going to also change
 > > our statement of support for Python/Ubuntu in Victoria.
 > > 
 > > > 
 > > > [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017060.html
 > > > 
 > > > -gmann
 > > > 
 > > > 
 > > 
 > 
 > https://review.opendev.org/#/c/750089 seems like the only functional
 > change.  It has my ACK with my requirements hat on.

yeah, and this one changing one test with #noqa  - https://review.opendev.org/#/c/744323/5
The rest all are l-c bump.

Also all the tox base jobs are migrated to Focal now.
- http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017136.html

 > 
 > -- 
 > Matthew Thode
 > 


From rosmaita.fossdev at gmail.com  Wed Sep  9 20:18:36 2020
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Wed, 9 Sep 2020 16:18:36 -0400
Subject: [cinder][requirements] FFE request for os-brick
Message-ID: <15d7208b-f006-0e06-3502-55309de3f8f4@gmail.com>

Hello Requirements Team,

The victoria release of os-brick 4.0.0 that we did last week contained a 
bugfix that requires a heavyweight binary dependency.  Unfortunately, we 
did not realize this until yesterday.  The cinder team reverted that 
patch [0] and replaced it with a lightweight fix [1] that does not 
require any new dependencies and has proposed the release of os-brick 
4.0.1 [2].  We are asking for a requirements freeze exception so that 
os-brick 4.0.1 can be included in the victoria openstack release.

[0] https://review.opendev.org/750649
[1] https://review.opendev.org/750655
[2] https://review.opendev.org/#/c/750808/


thank you,
brian


From skaplons at redhat.com  Wed Sep  9 20:43:16 2020
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Wed, 9 Sep 2020 22:43:16 +0200
Subject: Moving on
In-Reply-To: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
References: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
Message-ID: <20200909204316.tfuvkvc6rcih6akq@skaplons-mac>

Thank You Monty for all what You have done for OpenStack and SDK especially. It
was big pleasure to work with You.

All the best in Your new role!

On Wed, Sep 09, 2020 at 11:10:52AM -0500, Monty Taylor wrote:
> Hi everybody,
> 
> After 10 years of OpenStack, the time has come for me to move on to the next challenge. Actually, the time came a few weeks ago, but writing farewells has always been something I’m particularly bad at. My last day at Red Hat was actually July 31 and I’m now working in a non-OpenStack job.
> 
> I’m at a loss for words as to what more to say. I’ve never done anything for 10 years before, and I’ll be very surprised if I do anything else for 10 years again. While I’m excited about the new things on my plate, I’ll obviously miss everyone.
> 
> As I am no longer being paid by an OpenStack employer, I will not be doing any OpenStack things as part of my day job. I’m not sure how much spare time I’ll have to be able to contribute. I’m going to hold off on resigning core memberships pending a better understanding of that. I think it’s safe to assume I won’t be able to continue on as SDK PTL though.
> 
> I wish everyone all the best, and I hope life conspires to keep us all connected.
> 
> Thank you to everyone for an amazing 10 years.
> 
> Monty
> 

-- 
Slawek Kaplonski
Principal software engineer
Red Hat



From mthode at mthode.org  Wed Sep  9 21:09:59 2020
From: mthode at mthode.org (Matthew Thode)
Date: Wed, 9 Sep 2020 16:09:59 -0500
Subject: [cinder][requirements] FFE request for os-brick
In-Reply-To: <15d7208b-f006-0e06-3502-55309de3f8f4@gmail.com>
References: <15d7208b-f006-0e06-3502-55309de3f8f4@gmail.com>
Message-ID: <20200909210959.ijzgfw672rxwi7lu@mthode.org>

On 20-09-09 16:18:36, Brian Rosmaita wrote:
> Hello Requirements Team,
> 
> The victoria release of os-brick 4.0.0 that we did last week contained a
> bugfix that requires a heavyweight binary dependency.  Unfortunately, we did
> not realize this until yesterday.  The cinder team reverted that patch [0]
> and replaced it with a lightweight fix [1] that does not require any new
> dependencies and has proposed the release of os-brick 4.0.1 [2].  We are
> asking for a requirements freeze exception so that os-brick 4.0.1 can be
> included in the victoria openstack release.
> 
> [0] https://review.opendev.org/750649
> [1] https://review.opendev.org/750655
> [2] https://review.opendev.org/#/c/750808/
> 
> 
> thank you,
> brian
> 

This looks fine to me.

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

From kennelson11 at gmail.com  Wed Sep  9 21:19:16 2020
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Wed, 9 Sep 2020 14:19:16 -0700
Subject: [release][heat][karbor][patrole][requirements][swift][tempest][vitrage]
 Cycle With Intermediary Unreleased Deliverables
Message-ID: <CAJ6yrQjOwDHHXXNcULyLk07i8wWHbEni1UFXveGiTegzcj4U-w@mail.gmail.com>

Hello!

Quick reminder that we'll need a release very soon for a number of deliverables
following a cycle-with-intermediary release model but which have not done
*any* release yet in the Victoria cycle:

heat-agents
karbor-dashboard
karbor
patrole
requirements
swift
tempest
vitrage-dashboard
vitrage

Those should be released ASAP, and in all cases before $rc1-deadline, so that
we have a release to include in the final $series release.

- Kendall Nelson (diablo_rojo)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200909/a639a391/attachment.html>

From kennelson11 at gmail.com  Wed Sep  9 21:36:35 2020
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Wed, 9 Sep 2020 14:36:35 -0700
Subject: [all][PTL][release] Victoria Cycle Highlights
In-Reply-To: <CAJ6yrQh1Sr_TS5_z1OhLt3tvXtPJ6Ubzy1pkAFJqVRbYc9wcVg@mail.gmail.com>
References: <CAJ6yrQh1Sr_TS5_z1OhLt3tvXtPJ6Ubzy1pkAFJqVRbYc9wcVg@mail.gmail.com>
Message-ID: <CAJ6yrQgq4=5uueSWh-ut=hLmrt+K0fsqCiSVnGM--zv4ScCXgQ@mail.gmail.com>

Hello Everyone!

Wanted to give you another reminder!

Looking forward to see your highlights by the end of the week!

-Kendall (diablo_rojo)

On Tue, Sep 1, 2020 at 2:34 PM Kendall Nelson <kennelson11 at gmail.com> wrote:

> Hello Everyone!
>
> It's time to start thinking about calling out 'cycle-highlights' in your
> deliverables!
>
> As PTLs, you probably get many pings and emails from various parties
> (marketing, management, journalists, etc) asking for highlights of what
> is new and what significant changes are coming in the new release. By
> putting them all in the same place it makes them easy to reference because
> they get compiled into a pretty website like this from the last few
> releases: Rocky[1], Stein[2], Train[3], Ussuri[4].
>
> As usual, we don't need a fully fledged marketing message, just a few highlights
> (3-4 ideally), from each project team. Looking through your release notes
> is a good place to start.
>
> *The deadline for cycle highlights is the end of the R-5 week [5] on Sept
> 11th.*
>
> How To Reminder:
> -------------------------
>
> Simply add them to the deliverables/train/$PROJECT.yaml in the
> openstack/releases repo like this:
>
>    cycle-highlights:
>      - Introduced new service to use unused host to mine bitcoin.
>
> The formatting options for this tag are the same as what you are probably
> used to with Reno release notes.
>
> Also, you can check on the formatting of the output by either running
> locally:
>
>    tox -e docs
>
> And then checking the resulting doc/build/html/train/highlights.html file
> or the output of the build-openstack-sphinx-docs job under html/train/
> highlights.html.
>
> Can't wait to see what you've accomplished!
>
> -Kendall Nelson (diablo_rojo)
>
> [1] https://releases.openstack.org/rocky/highlights.html
> [2] https://releases.openstack.org/stein/highlights.html
> [3] https://releases.openstack.org/train/highlights.html
> [4] https://releases.openstack.org/ussuri/highlights.html
> [5] htt
> <https://releases.openstack.org/train/schedule.html#t-cycle-highlights>
> https://releases.openstack.org/victoria/schedule.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200909/fe3b8035/attachment-0001.html>

From feilong at catalyst.net.nz  Wed Sep  9 22:07:42 2020
From: feilong at catalyst.net.nz (feilong)
Date: Thu, 10 Sep 2020 10:07:42 +1200
Subject: Moving on
In-Reply-To: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
References: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
Message-ID: <1218aab0-3c6f-3ad3-81b0-114752aba5d3@catalyst.net.nz>

Thank you for all you have done for OpenStack and the community, Monty.

On 10/09/20 4:10 am, Monty Taylor wrote:
> Hi everybody,
>
> After 10 years of OpenStack, the time has come for me to move on to the next challenge. Actually, the time came a few weeks ago, but writing farewells has always been something I’m particularly bad at. My last day at Red Hat was actually July 31 and I’m now working in a non-OpenStack job.
>
> I’m at a loss for words as to what more to say. I’ve never done anything for 10 years before, and I’ll be very surprised if I do anything else for 10 years again. While I’m excited about the new things on my plate, I’ll obviously miss everyone.
>
> As I am no longer being paid by an OpenStack employer, I will not be doing any OpenStack things as part of my day job. I’m not sure how much spare time I’ll have to be able to contribute. I’m going to hold off on resigning core memberships pending a better understanding of that. I think it’s safe to assume I won’t be able to continue on as SDK PTL though.
>
> I wish everyone all the best, and I hope life conspires to keep us all connected.
>
> Thank you to everyone for an amazing 10 years.
>
> Monty

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
------------------------------------------------------ 



From Arkady.Kanevsky at dell.com  Wed Sep  9 22:24:27 2020
From: Arkady.Kanevsky at dell.com (Kanevsky, Arkady)
Date: Wed, 9 Sep 2020 22:24:27 +0000
Subject: Moving on
In-Reply-To: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
References: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
Message-ID: <BN8PR19MB3076A645D49ADEFBE0E05A19F9260@BN8PR19MB3076.namprd19.prod.outlook.com>

Monty,
Thank you very very much for all you time and dedication to OpenStack and Zuul.
It was a pleasure working with you. 
And best of luck on your new endeavor.
We will miss you.
Arkady

-----Original Message-----
From: Monty Taylor <mordred at inaugust.com> 
Sent: Wednesday, September 9, 2020 11:11 AM
To: openstack-discuss; service-discuss at lists.opendev.org; Zuul-discuss at lists.zuul-ci.org
Subject: Moving on


[EXTERNAL EMAIL] 

Hi everybody,

After 10 years of OpenStack, the time has come for me to move on to the next challenge. Actually, the time came a few weeks ago, but writing farewells has always been something I’m particularly bad at. My last day at Red Hat was actually July 31 and I’m now working in a non-OpenStack job.

I’m at a loss for words as to what more to say. I’ve never done anything for 10 years before, and I’ll be very surprised if I do anything else for 10 years again. While I’m excited about the new things on my plate, I’ll obviously miss everyone.

As I am no longer being paid by an OpenStack employer, I will not be doing any OpenStack things as part of my day job. I’m not sure how much spare time I’ll have to be able to contribute. I’m going to hold off on resigning core memberships pending a better understanding of that. I think it’s safe to assume I won’t be able to continue on as SDK PTL though.

I wish everyone all the best, and I hope life conspires to keep us all connected.

Thank you to everyone for an amazing 10 years.

Monty

From jimmy at openstack.org  Wed Sep  9 22:57:00 2020
From: jimmy at openstack.org (Jimmy McArthur)
Date: Wed, 9 Sep 2020 17:57:00 -0500
Subject: REMINDER: 2020 Virtual Summit: Forum Submissions Now Accepted
Message-ID: <C8569E82-1666-4C60-8BA5-A39C4240EF22@getmailspring.com>

Hello Everyone!

We are now accepting Forum [1] submissions for the 2020 Virtual Open Infrastructure Summit [2]. Please submit your ideas through the Summit CFP tool [3] through September 14th. Don't forget to put your brainstorming etherpad up on the Virtual Forum page [4].

This is not a classic conference track with speakers and presentations. OSF community members (participants in development teams, operators, working groups, SIGs, and other interested individuals) discuss the topics they want to cover and get alignment on and we welcome your participation. The Forum is your opportunity to help shape the development of future project releases. More information about the Forum [1].

The timeline for submissions is as follows:

Aug 31st | Formal topic submission tool opens: https://cfp.openstack.org.
Sep 14th | Deadline for proposing Forum topics. Scheduling committee meeting to make draft agenda.
Sep 21st | Draft Forum schedule published. Crowd sourced session conflict detection. Forum promotion begins.
Sept 28th | Forum schedule final
Oct 19th | Forum begins!

If you have questions or concerns, please reach out to speakersupport at openstack.org (mailto:speakersupport at openstack.org).

Cheers,
Jimmy

[1] https://wiki.openstack.org/wiki/Forum
[2] https://www.openstack.org/summit/2020/
[3] https://cfp.openstack.org
[4]https://wiki.openstack.org/wiki/Forum/Virtual2020
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200909/ea7c76e1/attachment.html>

From zigo at debian.org  Wed Sep  9 23:15:14 2020
From: zigo at debian.org (Thomas Goirand)
Date: Thu, 10 Sep 2020 01:15:14 +0200
Subject: Moving on
In-Reply-To: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
References: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
Message-ID: <4965dddc-9480-ecff-1004-6aeb2fc39619@debian.org>

On 9/9/20 6:10 PM, Monty Taylor wrote:
> Hi everybody,
> 
> After 10 years of OpenStack, the time has come for me to move on to the next challenge. Actually, the time came a few weeks ago, but writing farewells has always been something I’m particularly bad at. My last day at Red Hat was actually July 31 and I’m now working in a non-OpenStack job.
> 
> I’m at a loss for words as to what more to say. I’ve never done anything for 10 years before, and I’ll be very surprised if I do anything else for 10 years again. While I’m excited about the new things on my plate, I’ll obviously miss everyone.
> 
> As I am no longer being paid by an OpenStack employer, I will not be doing any OpenStack things as part of my day job. I’m not sure how much spare time I’ll have to be able to contribute. I’m going to hold off on resigning core memberships pending a better understanding of that. I think it’s safe to assume I won’t be able to continue on as SDK PTL though.
> 
> I wish everyone all the best, and I hope life conspires to keep us all connected.
> 
> Thank you to everyone for an amazing 10 years.
> 
> Monty
> 

Monty,

We'll miss you! Both for your technical excellence, and for the nicer
person that you are. Good luck for whatever's next.

Cheers,

Thomas Goirand (zigo)


From sorrison at gmail.com  Thu Sep 10 00:58:43 2020
From: sorrison at gmail.com (Sam Morrison)
Date: Thu, 10 Sep 2020 10:58:43 +1000
Subject: [neutron][networking-midonet] Maintainers needed
In-Reply-To: <17472f764b8.1292d333d6181.3892285235847293323@ghanshyammann.com>
References: <0AC5AC07-E97E-43CC-B344-A3E992B8CCA4@netways.de>
 <610412AF-AADF-44BD-ABA2-BA289B7C8F8A@redhat.com>
 <5E2F5826-559E-42E9-84C5-FA708E5A122A@gmail.com>
 <CAH=wFzS6usQqLeUtZ3iwyzw5f+ph38eaHCEQ0xsKo2ZzMREBgA@mail.gmail.com>
 <43C4AF2B-C5C0-40EB-B621-AC6799471D01@gmail.com>
 <CAH=wFzRmjbCy5vQOrpu=rX4Be-_GYPOE602kDShvV-ZtX+eF6g@mail.gmail.com>
 <92959221-0353-4D48-8726-8FE71AFEA652@gmail.com>
 <4D778DBF-F505-462F-B85D-0B372085FA72@gmail.com>
 <CAH=wFzRiJd=93cYsK5FJxJcmMb6eY-XDco1zQOfueMw-0s2Tcw@mail.gmail.com>
 <AB1C90C1-96EE-4D1B-AA3B-63A565A41B61@gmail.com>
 <5B9D2CB0-8B81-4533-A072-9A51B4A44364@gmail.com>
 <CALg0jKksi08Tq-H7xXGiNXqO3W9rtioERr9y7mN_us24GN+mBQ@mail.gmail.com>
 <C4587E9A-5E13-4AB5-801E-129BB470F73C@gmail.com>
 <CALg0jK=qEWFSwA5T-+fKwKsamqTK_mqhUW+ZY6fqCxk5xm0m0A@mail.gmail.com>
 <17472f764b8.1292d333d6181.3892285235847293323@ghanshyammann.com>
Message-ID: <2AB30A6D-9B6C-4D18-8FAB-C1022965657A@gmail.com>

OK thanks for the fix for TaaS, https://review.opendev.org/#/c/750633/4 should be good to be merged (even though its failing)

Also https://review.opendev.org/#/c/749641/3 should be good to go. This will get all the unit tests working. 

The pep8 tests are broken due to the pecan 1.4.0 issue being discussed at https://review.opendev.org/#/c/747419/

My zuul v3 aio tempest devstack job is working well now, still having some issues with the multinode one which I’m working on now.

Sam

 

> On 9 Sep 2020, at 11:04 pm, Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
> 
> Also we need to merge the networking-l2gw project new location fix
> 
> - https://review.opendev.org/#/c/738046/
> 
> It's leading to many errors as pointed by AJaeger  - https://zuul.opendev.org/t/openstack/config-errors
> 
> 
> -gmann
> 
> ---- On Wed, 09 Sep 2020 07:18:37 -0500 Lajos Katona <katonalala at gmail.com> wrote ----
>> Hi,I pushed a fix for it https://review.opendev.org/750633, I added Deepak for reviewer as he is the owner of the taas patch.
>> Sorry for the problem.Lajos (lajoskatona)
>> Sam Morrison <sorrison at gmail.com> ezt írta (időpont: 2020. szept. 9., Sze, 12:49):
>> 
>> 
>> On 9 Sep 2020, at 4:52 pm, Lajos Katona <katonalala at gmail.com> wrote:
>> Hi,Could you please  point to the issue with taas?
>> Networking-midonet unit tests [1] are failing with the addition of this patch [2]
>> [1] https://b1a2669063d97482275a-410cecb8410320c66fb802e0a530979a.ssl.cf5.rackcdn.com/749857/18/check/openstack-tox-py36/0344651/testr_results.html[2] https://opendev.org/x/tap-as-a-service/commit/8332a396b1b046eb370c0cb377d836d0c6b6d6ca
>> I’m not really familiar with all of this so not sure how to fix these up.
>> Cheers,Sam
>> 
>> 
>> 
>> RegardsLajos (lajoskatona)
>> Sam Morrison <sorrison at gmail.com> ezt írta (időpont: 2020. szept. 9., Sze, 0:44):
>> 
>> 
>> On 8 Sep 2020, at 3:13 pm, Sam Morrison <sorrison at gmail.com> wrote:
>> Hi Yamamoto,
>> 
>> On 4 Sep 2020, at 6:47 pm, Takashi Yamamoto <yamamoto at midokura.com> wrote:
>> i'm talking to our infra folks but it might take longer than i hoped.
>> if you or someone else can provide a public repo, it might be faster.
>> (i have looked at launchpad PPA while ago. but it didn't seem
>> straightforward given the complex build machinary in midonet.)
>> 
>> Yeah that’s no problem, I’ve set up a repo with the latest midonet debs in it and happy to use that for the time being.
>> 
>> 
>> I’m not sure why the pep8 job is failing, it is complaining about pecan which makes me think this is an issue with neutron itself? Kinda stuck on this one, it’s probably something silly.
>> 
>> probably.
>> 
>> Yeah this looks like a neutron or neutron-lib issue
>> 
>> 
>> For the py3 unit tests they are now failing due to db migration errors in tap-as-a-service, l2-gateway and vpnaas issues I think caused by neutron getting rid of the liberty alembic branch and so we need to squash these on these projects too.
>> 
>> this thing? https://review.opendev.org/#/c/749866/
>> 
>> Yeah that fixed that issue.
>> 
>> I have been working to get everything fixed in this review [1]
>> The pep8 job is working but not in the gate due to neutron issues [2]The py36/py38 jobs have 2 tests failing both relating to tap-as-a-service which I don’t really have any idea about, never used it. [3]
>> These are failing because of this patch on tap-as-a-service https://opendev.org/x/tap-as-a-service/commit/8332a396b1b046eb370c0cb377d836d0c6b6d6ca
>> Really have no idea how this works, does anyone use tap-as-a-service with midonet and can help me fix it, else I’m wondering if we disable tests for taas and make it an unsupported feature for now.
>> Sam
>> 
>> 
>> The tempest aio job is working well now, I’m not sure what tempest tests were run before but it’s just doing what ever is the default at the moment.The tempest multinode job isn’t working due to what I think is networking issues between the 2 nodes. I don’t really know what I’m doing here so any pointers would be helpful. [4]The grenade job is also failing because I also need to put these fixes on the stable/ussuri branch to make it work so will need to figure that out too
>> Cheers,Sam
>> [1] https://review.opendev.org/#/c/749857/[2] https://zuul.opendev.org/t/openstack/build/e94e873cbf0443c0a7f25ffe76b3b00b[3] https://b1a2669063d97482275a-410cecb8410320c66fb802e0a530979a.ssl.cf5.rackcdn.com/749857/18/check/openstack-tox-py36/0344651/testr_results.html[4] https://zuul.opendev.org/t/openstack/build/61f6dd3dc3d74a81b7a3f5968b4d8c72
>> 
>> 
>> 
>> 
>> 
>> I can now start to look into the devstack zuul jobs.
>> 
>> Cheers,
>> Sam
>> 
>> 
>> [1] https://github.com/NeCTAR-RC/networking-midonet/commits/devstack
>> [2] https://github.com/midonet/midonet/pull/9
>> 
>> 
>> 
>> 
>> On 1 Sep 2020, at 4:03 pm, Sam Morrison <sorrison at gmail.com> wrote:
>> 
>> 
>> 
>> On 1 Sep 2020, at 2:59 pm, Takashi Yamamoto <yamamoto at midokura.com> wrote:
>> 
>> hi,
>> 
>> On Tue, Sep 1, 2020 at 1:39 PM Sam Morrison <sorrison at gmail.com> wrote:
>> 
>> 
>> 
>> On 1 Sep 2020, at 11:49 am, Takashi Yamamoto <yamamoto at midokura.com> wrote:
>> 
>> Sebastian, Sam,
>> 
>> thank you for speaking up.
>> 
>> as Slawek said, the first (and probably the biggest) thing is to fix the ci.
>> the major part for it is to make midonet itself to run on ubuntu
>> version used by the ci. (18.04, or maybe directly to 20.04)
>> https://midonet.atlassian.net/browse/MNA-1344
>> iirc, the remaining blockers are:
>> * libreswan (used by vpnaas)
>> * vpp (used by fip64)
>> maybe it's the easiest to drop those features along with their
>> required components, if it's acceptable for your use cases.
>> 
>> We are running midonet-cluster and midolman on 18.04, we dropped those package dependencies from our ubuntu package to get it working.
>> 
>> We currently have built our own and host in our internal repo but happy to help putting this upstream somehow. Can we upload them to the midonet apt repo, does it still exist?
>> 
>> it still exists. but i don't think it's maintained well.
>> let me find and ask someone in midokura who "owns" that part of infra.
>> 
>> does it also involve some package-related modifications to midonet repo, right?
>> 
>> 
>> Yes a couple, I will send up as as pull requests to https://github.com/midonet/midonet today or tomorrow
>> 
>> Sam
>> 
>> 
>> 
>> 
>> 
>> I’m keen to do the work but might need a bit of guidance to get started,
>> 
>> Sam
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> alternatively you might want to make midonet run in a container. (so
>> that you can run it with older ubuntu, or even a container trimmed for
>> JVM)
>> there were a few attempts to containerize midonet.
>> i think this is the latest one: https://github.com/midonet/midonet-docker
>> 
>> On Fri, Aug 28, 2020 at 7:10 AM Sam Morrison <sorrison at gmail.com> wrote:
>> 
>> We (Nectar Research Cloud) use midonet heavily too, it works really well and we haven’t found another driver that works for us. We tried OVN but it just doesn’t scale to the size of environment we have.
>> 
>> I’m happy to help too.
>> 
>> Cheers,
>> Sam
>> 
>> 
>> 
>> On 31 Jul 2020, at 2:06 am, Slawek Kaplonski <skaplons at redhat.com> wrote:
>> 
>> Hi,
>> 
>> Thx Sebastian for stepping in to maintain the project. That is great news.
>> I think that at the beginning You should do 2 things:
>> - sync with Takashi Yamamoto (I added him to the loop) as he is probably most active current maintainer of this project,
>> - focus on fixing networking-midonet ci which is currently broken - all scenario jobs aren’t working fine on Ubuntu 18.04 (and we are going to move to 20.04 in this cycle), migrate jobs to zuulv3 from the legacy ones and finally add them to the ci again,
>> 
>> I can of course help You with ci jobs if You need any help. Feel free to ping me on IRC or email (can be off the list).
>> 
>> On 29 Jul 2020, at 15:24, Sebastian Saemann <Sebastian.Saemann at netways.de> wrote:
>> 
>> Hi Slawek,
>> 
>> we at NETWAYS are running most of our neutron networking on top of midonet and wouldn't be too happy if it gets deprecated and removed. So we would like to take over the maintainer role for this part.
>> 
>> Please let me know how to proceed and how we can be onboarded easily.
>> 
>> Best regards,
>> 
>> Sebastian
>> 
>> --
>> Sebastian Saemann
>> Head of Managed Services
>> 
>> NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
>> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
>> CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB25207
>> https://netways.de | sebastian.saemann at netways.de
>> 
>> ** NETWAYS Web Services - https://nws.netways.de **
>> 
>> —
>> Slawek Kaplonski
>> Principal software engineer
>> Red Hat
>> 
>> 
>> 
>> 
>> 



From gmann at ghanshyammann.com  Thu Sep 10 03:22:13 2020
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 09 Sep 2020 22:22:13 -0500
Subject: [oslo][release][requirement] FFE request for Oslo lib
In-Reply-To: <174746eb120.1229d07d224552.356509349559116522@ghanshyammann.com>
References: <1746e64d702.ee80b0bc1249.5426348472779199647@ghanshyammann.com>
 <bc93768b-cf66-d66b-5fc6-78ac07797991@nemebean.com>
 <20200909192543.b2d2ksruoqtbgcfy@mthode.org>
 <174746eb120.1229d07d224552.356509349559116522@ghanshyammann.com>
Message-ID: <1747608f93e.d7ec085f28282.4985395579846058200@ghanshyammann.com>

 ---- On Wed, 09 Sep 2020 14:54:05 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > 
 >  ---- On Wed, 09 Sep 2020 14:25:43 -0500 Matthew Thode <mthode at mthode.org> wrote ----
 >  > On 20-09-09 12:04:51, Ben Nemec wrote:
 >  > > 
 >  > > On 9/8/20 10:45 AM, Ghanshyam Mann wrote:
 >  > > > Hello Team,
 >  > > > 
 >  > > > This is regarding FFE for Focal migration work. As planned, we have to move the Victoria testing to Focal and
 >  > > > base job switch is planned to be switched by today[1].
 >  > > > 
 >  > > > There are few oslo lib need work (especially tox job-based testing not user-facing changes) to pass on Focal
 >  > > > - https://review.opendev.org/#/q/topic:migrate-to-focal-oslo+(status:open+OR+status:merged)
 >  > > > 
 >  > > > If we move the base tox jobs to Focal then these lib victoria gates (especially lower-constraint job) will be failing.
 >  > > > We can either do these as FFE or backport (as this is lib own CI fixes only) later once the victoria branch is open.
 >  > > > Opinion?
 >  > > 
 >  > > As I noted in the meeting, if we have to do this to keep the gates working
 >  > > then I'd rather do it as an FFE than have to backport all of the relevant
 >  > > patches. IMHO we should only decline this FFE if we are going to also change
 >  > > our statement of support for Python/Ubuntu in Victoria.
 >  > > 
 >  > > > 
 >  > > > [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017060.html
 >  > > > 
 >  > > > -gmann
 >  > > > 
 >  > > > 
 >  > > 
 >  > 
 >  > https://review.opendev.org/#/c/750089 seems like the only functional
 >  > change.  It has my ACK with my requirements hat on.

NOTE: There is one py3.8 bug fix also merged in oslo.uitls which is not yet released. This made py3.8 job voting in oslo.utils gate.
- https://review.opendev.org/#/c/750216/

Rest all l-c bump are now passing on Focal
- https://review.opendev.org/#/q/topic:migrate-to-focal-oslo+(status:open+OR+status:merged)

-gmann

 > 
 > yeah, and this one changing one test with #noqa  - https://review.opendev.org/#/c/744323/5
 > The rest all are l-c bump.
 > 
 > Also all the tox base jobs are migrated to Focal now.
 > - http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017136.html
 > 
 >  > 
 >  > -- 
 >  > Matthew Thode
 >  > 
 > 
 > 


From gmann at ghanshyammann.com  Thu Sep 10 03:32:38 2020
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Wed, 09 Sep 2020 22:32:38 -0500
Subject: [all][tc][goals] Migrate CI/CD jobs to new Ubuntu LTS Focal:
 Week R-4 Update
In-Reply-To: <1747442027f.bb3f3d1823475.212800600164097649@ghanshyammann.com>
References: <17468f8f785.1123a07e6307801.3844845549431858647@ghanshyammann.com>
 <1746feef403.c41c848411058.2421030943223377212@ghanshyammann.com>
 <1747442027f.bb3f3d1823475.212800600164097649@ghanshyammann.com>
Message-ID: <17476128313.f7b6001e28321.7088729119972703547@ghanshyammann.com>

Updates: 

Fixed a few more projects today which I found failing on Focal:

- OpenStack SDKs repos : ready to merge
- All remaining Oslo lib fixes:  we are discussing FFE on these in separate ML thread.
- Keystone: Fix is up, it should pass now.
- Manila: Fix is up, it should pass gate.
- Tacker: Ready to merge
- neutron-dynamic-routing: Ready to merge
- Cinder- it seems l-c job still failing. I will dig into it tomorrow or it will be appreciated if anyone can take a look before my morning.
this is the patch -https://review.opendev.org/#/c/743080/

Note: all tox based jobs (Except py36/3.7) are running on Focal now so If any of you gate failing, feel free to ping me on #openstack-qa

No more energy left for today, I will continue the remaining work tomorrow.

-gmann

 ---- On Wed, 09 Sep 2020 14:05:17 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 >  ---- On Tue, 08 Sep 2020 17:56:05 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 >  > Updates:
 >  > After working more on failing one today and listing the blocking one, I think we are good to switch tox based testing today
 >  > and discuss the integration testing switch tomorrow in TC office hours. 
 >  > 
 >  > > * Part1: Migrating tox base job tomorrow (8th Sept):
 >  >  
 >  > I have checked it again and fixed many repos that are up for review and merge. Most python clients are already fixed
 >  > or their fixes are up for merge so they can make it before the feature freeze on 10th. If any repo is broken then it will be pretty quick
 >  > to fix by lower constraint bump (see the example under https://review.opendev.org/#/q/topic:migrate-to-focal)
 >  > 
 >  > Even if any of the fixes miss the victoria release then those can be backported easily. I am opening the tox base jobs migration to merge: 
 >  >  - All patches in this series https://review.opendev.org/#/c/738328/
 > 
 > All these tox base jobs are merged now and running on Focal. If any of your repo is failing, please fix on priority or ping me on IRC if failure not clear.
 > You can find most of the fixes for possible failure in this topic:
 > - https://review.opendev.org/#/q/topic:migrate-to-focal+(status:open+OR+status:merged)
 > 
 > -gmann
 > 
 > 
 >  > 
 >  > 
 >  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
 >  > 
 >  > We have three blocking open bugs here so I would like to discuss it in tomorrow's TC office hour also about how to proceed on this.
 >  > 
 >  > 1. Nova: https://bugs.launchpad.net/nova/+bug/1882521  (https://bugs.launchpad.net/qemu/+bug/1894804)
 >  > 2. Barbican: https://storyboard.openstack.org/#!/story/2007732
 >  > 3. Ceilometer: https://storyboard.openstack.org/#!/story/2008121
 >  > 
 >  > 
 >  > -gmann
 >  > 
 >  > 
 >  >  ---- On Mon, 07 Sep 2020 09:29:40 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 >  >  > Hello Everyone,
 >  >  > 
 >  >  > Please find the week R-4 updates on 'Ubuntu Focal migration' community goal. Its time to force the base jobs migration which can
 >  >  > break the projects gate if not yet taken care of. Read below for the plan.
 >  >  > 
 >  >  > Tracking: https://storyboard.openstack.org/#!/story/2007865
 >  >  > 
 >  >  > Progress:
 >  >  > =======
 >  >  > * We are close to V-3 release and this is time we have to complete this migration otherwise doing it in RC period can add
 >  >  > unnecessary and last min delay. I am going to plan this migration in two-part. This will surely break some projects gate
 >  >  > which is not yet finished the migration but we have to do at some time. Please let me know if any objection to the below
 >  >  > plan.
 >  >  > 
 >  >  > * Part1: Migrating tox base job tomorrow (8th Sept):
 >  >  > 
 >  >  > ** I am going to open tox base jobs migration (doc, unit, functional, lower-constraints etc) to merge by tomorrow. which is this
 >  >  > series (all base patches of this):  https://review.opendev.org/#/c/738328/ . 
 >  >  > 
 >  >  > **There are few repos still failing on requirements lower-constraints job specifically which I tried my best to fix as many as possible.
 >  >  >  Many are ready to merge also. Please merge or work on your projects repo testing before that or fix on priority if failing.
 >  >  > 
 >  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
 >  >  > 
 >  >  > * We have few open bugs for this which are not yet resolved, we will see how it goes but the current plan is to migrate by 10th Sept.
 >  >  > 
 >  >  > ** Bug#1882521
 >  >  > ** DB migration issues,
 >  >  > *** alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003
 >  >  > 
 >  >  > 
 >  >  > Testing Till now:
 >  >  > ============
 >  >  > * ~200 repos gate have been tested or fixed till now.
 >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+(status:abandoned+OR+status:merged)
 >  >  > 
 >  >  > * ~100 repos are under test and failing. Debugging and fixing are in progress (If you would like to help, please check your
 >  >  > project repos if I am late to fix them):
 >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open
 >  >  > 
 >  >  > * ~30repos fixes ready to merge:
 >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open+label%3AVerified%3E%3D1%2Czuul+NOT+label%3AWorkflow%3C%3D-1
 >  >  > 
 >  >  > 
 >  >  > Bugs Report:
 >  >  > ==========
 >  >  > 
 >  >  > 1. Bug#1882521. (IN-PROGRESS)
 >  >  > There is open bug for nova/cinder where three tempest tests are failing for
 >  >  > volume detach operation. There is no clear root cause found yet
 >  >  > -https://bugs.launchpad.net/cinder/+bug/1882521
 >  >  > We have skipped the tests in tempest base patch to proceed with the other
 >  >  > projects testing but this is blocking things for the migration.
 >  >  > 
 >  >  > 2. DB migration issues (IN-PROGRESS)
 >  >  > * alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003
 >  >  > 
 >  >  > 3. We encountered the nodeset name conflict with x/tobiko. (FIXED)
 >  >  > nodeset conflict is resolved now and devstack provides all focal nodes now.
 >  >  > 
 >  >  > 4. Bug#1886296. (IN-PROGRESS)
 >  >  > pyflakes till 2.1.0 is not compatible with python 3.8 which is the default python version
 >  >  > on ubuntu focal[1]. With pep8 job running on focal faces the issue and fail. We need to bump
 >  >  > the pyflakes to 2.1.1 as min version to run pep8 jobs on py3.8.
 >  >  > As of now, many projects are using old hacking version so I am explicitly adding pyflakes>=2.1.1
 >  >  > on the project side[2] but for the long term easy maintenance, I am doing it in 'hacking' requirements.txt[3]
 >  >  > nd will release a new hacking version. After that project can move to new hacking and do not need
 >  >  > to maintain pyflakes version compatibility.
 >  >  > 
 >  >  > 5. Bug#1886298. (IN-PROGRESS)
 >  >  > 'Markupsafe' 1.0 is not compatible with the latest version of setuptools[4],
 >  >  > We need to bump the lower-constraint for Markupsafe to 1.1.1 to make it work.
 >  >  > There are a few more issues[5] with lower-constraint jobs which I am debugging.
 >  >  > 
 >  >  > 
 >  >  > What work to be done on the project side:
 >  >  > ================================
 >  >  > This goal is more of testing the jobs on focal and fixing bugs if any otherwise
 >  >  > migrate jobs by switching the nodeset to focal node sets defined in devstack.
 >  >  > 
 >  >  > 1. Start a patch in your repo by making depends-on on either of below:
 >  >  > devstack base patch if you are using only devstack base jobs not tempest:
 >  >  > 
 >  >  > Depends-on: https://review.opendev.org/#/c/731207/
 >  >  > OR
 >  >  > tempest base patch if you are using the tempest base job (like devstack-tempest):
 >  >  > Depends-on: https://review.opendev.org/#/c/734700/
 >  >  > 
 >  >  > Both have depends-on on the series where I am moving unit/functional/doc/cover/nodejs tox jobs to focal. So
 >  >  > you can test the complete gate jobs(unit/functional/doc/integration) together.
 >  >  > This and its base patches - https://review.opendev.org/#/c/738328/
 >  >  > 
 >  >  > Example: https://review.opendev.org/#/c/738126/
 >  >  > 
 >  >  > 2. If none of your project jobs override the nodeset then above patch will be
 >  >  > testing patch(do not merge) otherwise change the nodeset to focal.
 >  >  > Example: https://review.opendev.org/#/c/737370/
 >  >  > 
 >  >  > 3. If the jobs are defined in branchless repo and override the nodeset then you need to override the branches
 >  >  > variant to adjust the nodeset so that those jobs run on Focal on victoria onwards only. If no nodeset
 >  >  > is overridden then devstack being branched and stable base job using bionic/xenial will take care of
 >  >  > this.
 >  >  > Example: https://review.opendev.org/#/c/744056/2
 >  >  > 
 >  >  > 4. If no updates need you can abandon the testing patch (https://review.opendev.org/#/c/744341/). If it need
 >  >  > updates then modify the same patch with proper commit msg, once it pass the gate then remove the Depends-On
 >  >  > so that you can merge your patch before base jobs are switched to focal. This way we make sure no gate downtime in
 >  >  > this migration.
 >  >  > Example: https://review.opendev.org/#/c/744056/1..2//COMMIT_MSG
 >  >  > 
 >  >  > Once we finish the testing on projects side and no failure then we will merge the devstack and tempest
 >  >  > base patches.
 >  >  > 
 >  >  > 
 >  >  > Important things to note:
 >  >  > ===================
 >  >  > * Do not forgot to add the story and task link to your patch so that we can track it smoothly.
 >  >  > * Use gerrit topic 'migrate-to-focal'
 >  >  > * Do not backport any of the patches.
 >  >  > 
 >  >  > 
 >  >  > References:
 >  >  > =========
 >  >  > Goal doc: https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-jobs-to-ubuntu-focal.html
 >  >  > Storyboard tracking: https://storyboard.openstack.org/#!/story/2007865
 >  >  > 
 >  >  > [1] https://github.com/PyCQA/pyflakes/issues/367
 >  >  > [2] https://review.opendev.org/#/c/739315/
 >  >  > [3] https://review.opendev.org/#/c/739334/
 >  >  > [4] https://github.com/pallets/markupsafe/issues/116
 >  >  > [5] https://zuul.opendev.org/t/openstack/build/7ecd9cf100194bc99b3b70fa1e6de032
 >  >  > 
 >  >  > -gmann
 >  >  > 
 >  >  > 
 >  > 
 >  > 
 > 
 > 


From tonyppe at gmail.com  Thu Sep 10 04:35:32 2020
From: tonyppe at gmail.com (Tony Pearce)
Date: Thu, 10 Sep 2020 12:35:32 +0800
Subject: [Magnum][kolla-ansible][kayobe] Information gathering for 2 blocking
 issues
Message-ID: <CAK1+d=4nKMsqOcH+e0iB6jmY=0e=gEvk817sSDdEpJ+kUP-5vQ@mail.gmail.com>

Hi all, hope you are all keeping safe and well. I am looking for
information on the following two issues that I have which surrounds Magnum
project:

1. Magnum does not support Openstack API with HTTPS
2. Magnum forces compute nodes to consume disk capacity for instance data

My environment: Openstack Train deployed using Kayobe (Kolla-ansible).

With regards to the HTTPS issue, Magnum stops working after enabling HTTPS
because the certificate / CA certificate is not trusted by Magnum. The
certificate which I am using is one that was purchased from GoDaddy and is
trusted in web browsers (and is valid), just not trusted by the Magnum
component.

Regarding compute node disk consumption issue - I'm at a loss with regards
to this and so I'm looking for more information about why this is being
done and is there any way that I could avoid it?  I have storage provided
by a Cinder integration and so the consumption of compute node disk for
instance data I need to avoid.

Any information the community could provide to me with regards to the above
would be much appreciated. I would very much like to use the Magnum project
in this deployment for Kubernetes deployment within projects.

Thanks in advance,

Regards,

Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200910/97425cda/attachment.html>

From radoslaw.piliszek at gmail.com  Thu Sep 10 07:18:02 2020
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Thu, 10 Sep 2020 09:18:02 +0200
Subject: [all][tc][goals] Migrate CI/CD jobs to new Ubuntu LTS Focal: Week
 R-4 Update
In-Reply-To: <17476128313.f7b6001e28321.7088729119972703547@ghanshyammann.com>
References: <17468f8f785.1123a07e6307801.3844845549431858647@ghanshyammann.com>
 <1746feef403.c41c848411058.2421030943223377212@ghanshyammann.com>
 <1747442027f.bb3f3d1823475.212800600164097649@ghanshyammann.com>
 <17476128313.f7b6001e28321.7088729119972703547@ghanshyammann.com>
Message-ID: <CAKZ_x78soqu_Wq3n8c5KX0DHKqPBactUEo95eazVxb7sbZA-dQ@mail.gmail.com>

I've triaged this for Kolla and Kolla-Ansible too.

Bifrost is also affected (but it's on Storyboard).

-yoctozepto

On Thu, Sep 10, 2020 at 5:42 AM Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
>
> Updates:
>
> Fixed a few more projects today which I found failing on Focal:
>
> - OpenStack SDKs repos : ready to merge
> - All remaining Oslo lib fixes:  we are discussing FFE on these in separate ML thread.
> - Keystone: Fix is up, it should pass now.
> - Manila: Fix is up, it should pass gate.
> - Tacker: Ready to merge
> - neutron-dynamic-routing: Ready to merge
> - Cinder- it seems l-c job still failing. I will dig into it tomorrow or it will be appreciated if anyone can take a look before my morning.
> this is the patch -https://review.opendev.org/#/c/743080/
>
> Note: all tox based jobs (Except py36/3.7) are running on Focal now so If any of you gate failing, feel free to ping me on #openstack-qa
>
> No more energy left for today, I will continue the remaining work tomorrow.
>
> -gmann
>
>  ---- On Wed, 09 Sep 2020 14:05:17 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
>  >  ---- On Tue, 08 Sep 2020 17:56:05 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
>  >  > Updates:
>  >  > After working more on failing one today and listing the blocking one, I think we are good to switch tox based testing today
>  >  > and discuss the integration testing switch tomorrow in TC office hours.
>  >  >
>  >  > > * Part1: Migrating tox base job tomorrow (8th Sept):
>  >  >
>  >  > I have checked it again and fixed many repos that are up for review and merge. Most python clients are already fixed
>  >  > or their fixes are up for merge so they can make it before the feature freeze on 10th. If any repo is broken then it will be pretty quick
>  >  > to fix by lower constraint bump (see the example under https://review.opendev.org/#/q/topic:migrate-to-focal)
>  >  >
>  >  > Even if any of the fixes miss the victoria release then those can be backported easily. I am opening the tox base jobs migration to merge:
>  >  >  - All patches in this series https://review.opendev.org/#/c/738328/
>  >
>  > All these tox base jobs are merged now and running on Focal. If any of your repo is failing, please fix on priority or ping me on IRC if failure not clear.
>  > You can find most of the fixes for possible failure in this topic:
>  > - https://review.opendev.org/#/q/topic:migrate-to-focal+(status:open+OR+status:merged)
>  >
>  > -gmann
>  >
>  >
>  >  >
>  >  >
>  >  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
>  >  >
>  >  > We have three blocking open bugs here so I would like to discuss it in tomorrow's TC office hour also about how to proceed on this.
>  >  >
>  >  > 1. Nova: https://bugs.launchpad.net/nova/+bug/1882521  (https://bugs.launchpad.net/qemu/+bug/1894804)
>  >  > 2. Barbican: https://storyboard.openstack.org/#!/story/2007732
>  >  > 3. Ceilometer: https://storyboard.openstack.org/#!/story/2008121
>  >  >
>  >  >
>  >  > -gmann
>  >  >
>  >  >
>  >  >  ---- On Mon, 07 Sep 2020 09:29:40 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
>  >  >  > Hello Everyone,
>  >  >  >
>  >  >  > Please find the week R-4 updates on 'Ubuntu Focal migration' community goal. Its time to force the base jobs migration which can
>  >  >  > break the projects gate if not yet taken care of. Read below for the plan.
>  >  >  >
>  >  >  > Tracking: https://storyboard.openstack.org/#!/story/2007865
>  >  >  >
>  >  >  > Progress:
>  >  >  > =======
>  >  >  > * We are close to V-3 release and this is time we have to complete this migration otherwise doing it in RC period can add
>  >  >  > unnecessary and last min delay. I am going to plan this migration in two-part. This will surely break some projects gate
>  >  >  > which is not yet finished the migration but we have to do at some time. Please let me know if any objection to the below
>  >  >  > plan.
>  >  >  >
>  >  >  > * Part1: Migrating tox base job tomorrow (8th Sept):
>  >  >  >
>  >  >  > ** I am going to open tox base jobs migration (doc, unit, functional, lower-constraints etc) to merge by tomorrow. which is this
>  >  >  > series (all base patches of this):  https://review.opendev.org/#/c/738328/ .
>  >  >  >
>  >  >  > **There are few repos still failing on requirements lower-constraints job specifically which I tried my best to fix as many as possible.
>  >  >  >  Many are ready to merge also. Please merge or work on your projects repo testing before that or fix on priority if failing.
>  >  >  >
>  >  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
>  >  >  >
>  >  >  > * We have few open bugs for this which are not yet resolved, we will see how it goes but the current plan is to migrate by 10th Sept.
>  >  >  >
>  >  >  > ** Bug#1882521
>  >  >  > ** DB migration issues,
>  >  >  > *** alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003
>  >  >  >
>  >  >  >
>  >  >  > Testing Till now:
>  >  >  > ============
>  >  >  > * ~200 repos gate have been tested or fixed till now.
>  >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+(status:abandoned+OR+status:merged)
>  >  >  >
>  >  >  > * ~100 repos are under test and failing. Debugging and fixing are in progress (If you would like to help, please check your
>  >  >  > project repos if I am late to fix them):
>  >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open
>  >  >  >
>  >  >  > * ~30repos fixes ready to merge:
>  >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open+label%3AVerified%3E%3D1%2Czuul+NOT+label%3AWorkflow%3C%3D-1
>  >  >  >
>  >  >  >
>  >  >  > Bugs Report:
>  >  >  > ==========
>  >  >  >
>  >  >  > 1. Bug#1882521. (IN-PROGRESS)
>  >  >  > There is open bug for nova/cinder where three tempest tests are failing for
>  >  >  > volume detach operation. There is no clear root cause found yet
>  >  >  > -https://bugs.launchpad.net/cinder/+bug/1882521
>  >  >  > We have skipped the tests in tempest base patch to proceed with the other
>  >  >  > projects testing but this is blocking things for the migration.
>  >  >  >
>  >  >  > 2. DB migration issues (IN-PROGRESS)
>  >  >  > * alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003
>  >  >  >
>  >  >  > 3. We encountered the nodeset name conflict with x/tobiko. (FIXED)
>  >  >  > nodeset conflict is resolved now and devstack provides all focal nodes now.
>  >  >  >
>  >  >  > 4. Bug#1886296. (IN-PROGRESS)
>  >  >  > pyflakes till 2.1.0 is not compatible with python 3.8 which is the default python version
>  >  >  > on ubuntu focal[1]. With pep8 job running on focal faces the issue and fail. We need to bump
>  >  >  > the pyflakes to 2.1.1 as min version to run pep8 jobs on py3.8.
>  >  >  > As of now, many projects are using old hacking version so I am explicitly adding pyflakes>=2.1.1
>  >  >  > on the project side[2] but for the long term easy maintenance, I am doing it in 'hacking' requirements.txt[3]
>  >  >  > nd will release a new hacking version. After that project can move to new hacking and do not need
>  >  >  > to maintain pyflakes version compatibility.
>  >  >  >
>  >  >  > 5. Bug#1886298. (IN-PROGRESS)
>  >  >  > 'Markupsafe' 1.0 is not compatible with the latest version of setuptools[4],
>  >  >  > We need to bump the lower-constraint for Markupsafe to 1.1.1 to make it work.
>  >  >  > There are a few more issues[5] with lower-constraint jobs which I am debugging.
>  >  >  >
>  >  >  >
>  >  >  > What work to be done on the project side:
>  >  >  > ================================
>  >  >  > This goal is more of testing the jobs on focal and fixing bugs if any otherwise
>  >  >  > migrate jobs by switching the nodeset to focal node sets defined in devstack.
>  >  >  >
>  >  >  > 1. Start a patch in your repo by making depends-on on either of below:
>  >  >  > devstack base patch if you are using only devstack base jobs not tempest:
>  >  >  >
>  >  >  > Depends-on: https://review.opendev.org/#/c/731207/
>  >  >  > OR
>  >  >  > tempest base patch if you are using the tempest base job (like devstack-tempest):
>  >  >  > Depends-on: https://review.opendev.org/#/c/734700/
>  >  >  >
>  >  >  > Both have depends-on on the series where I am moving unit/functional/doc/cover/nodejs tox jobs to focal. So
>  >  >  > you can test the complete gate jobs(unit/functional/doc/integration) together.
>  >  >  > This and its base patches - https://review.opendev.org/#/c/738328/
>  >  >  >
>  >  >  > Example: https://review.opendev.org/#/c/738126/
>  >  >  >
>  >  >  > 2. If none of your project jobs override the nodeset then above patch will be
>  >  >  > testing patch(do not merge) otherwise change the nodeset to focal.
>  >  >  > Example: https://review.opendev.org/#/c/737370/
>  >  >  >
>  >  >  > 3. If the jobs are defined in branchless repo and override the nodeset then you need to override the branches
>  >  >  > variant to adjust the nodeset so that those jobs run on Focal on victoria onwards only. If no nodeset
>  >  >  > is overridden then devstack being branched and stable base job using bionic/xenial will take care of
>  >  >  > this.
>  >  >  > Example: https://review.opendev.org/#/c/744056/2
>  >  >  >
>  >  >  > 4. If no updates need you can abandon the testing patch (https://review.opendev.org/#/c/744341/). If it need
>  >  >  > updates then modify the same patch with proper commit msg, once it pass the gate then remove the Depends-On
>  >  >  > so that you can merge your patch before base jobs are switched to focal. This way we make sure no gate downtime in
>  >  >  > this migration.
>  >  >  > Example: https://review.opendev.org/#/c/744056/1..2//COMMIT_MSG
>  >  >  >
>  >  >  > Once we finish the testing on projects side and no failure then we will merge the devstack and tempest
>  >  >  > base patches.
>  >  >  >
>  >  >  >
>  >  >  > Important things to note:
>  >  >  > ===================
>  >  >  > * Do not forgot to add the story and task link to your patch so that we can track it smoothly.
>  >  >  > * Use gerrit topic 'migrate-to-focal'
>  >  >  > * Do not backport any of the patches.
>  >  >  >
>  >  >  >
>  >  >  > References:
>  >  >  > =========
>  >  >  > Goal doc: https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-jobs-to-ubuntu-focal.html
>  >  >  > Storyboard tracking: https://storyboard.openstack.org/#!/story/2007865
>  >  >  >
>  >  >  > [1] https://github.com/PyCQA/pyflakes/issues/367
>  >  >  > [2] https://review.opendev.org/#/c/739315/
>  >  >  > [3] https://review.opendev.org/#/c/739334/
>  >  >  > [4] https://github.com/pallets/markupsafe/issues/116
>  >  >  > [5] https://zuul.opendev.org/t/openstack/build/7ecd9cf100194bc99b3b70fa1e6de032
>  >  >  >
>  >  >  > -gmann
>  >  >  >
>  >  >  >
>  >  >
>  >  >
>  >
>  >
>


From feilong at catalyst.net.nz  Thu Sep 10 08:01:38 2020
From: feilong at catalyst.net.nz (feilong)
Date: Thu, 10 Sep 2020 20:01:38 +1200
Subject: [Magnum][kolla-ansible][kayobe] Information gathering for 2
 blocking issues
In-Reply-To: <CAK1+d=4nKMsqOcH+e0iB6jmY=0e=gEvk817sSDdEpJ+kUP-5vQ@mail.gmail.com>
References: <CAK1+d=4nKMsqOcH+e0iB6jmY=0e=gEvk817sSDdEpJ+kUP-5vQ@mail.gmail.com>
Message-ID: <bda84189-d92d-0326-3dba-a41155f53a39@catalyst.net.nz>

Hi Tony,

Sorry for the late response for your thread.

For you HTTPS issue, we (Catalyst Cloud) are using Magnum with HTTPS and
it works.

For the 2nd issue, I think we were misunderstanding the nodes disk
capacity. I was assuming you're talking about the k8s nodes, but seems
you're talking about the physical compute host. I still don't think it's
a Magnum issue because a k8s master/worker nodes are just normal Nova
instances and managed by Heat. So I would suggest you use a simple HOT
to test it, you can use this
https://gist.github.com/openstacker/26e31c9715d52cc502397b65d3cebab6

Most of the cloud providers or organizations who have adopted Magnum are
using Ceph as far as I know, just FYI.


On 10/09/20 4:35 pm, Tony Pearce wrote:
> Hi all, hope you are all keeping safe and well. I am looking for
> information on the following two issues that I have which surrounds
> Magnum project:
>
> 1. Magnum does not support Openstack API with HTTPS
> 2. Magnum forces compute nodes to consume disk capacity for instance data
>
> My environment: Openstack Train deployed using Kayobe (Kolla-ansible). 
>
> With regards to the HTTPS issue, Magnum stops working after enabling
> HTTPS because the certificate / CA certificate is not trusted by
> Magnum. The certificate which I am using is one that was purchased
> from GoDaddy and is trusted in web browsers (and is valid), just not
> trusted by the Magnum component. 
>
> Regarding compute node disk consumption issue - I'm at a loss with
> regards to this and so I'm looking for more information about why this
> is being done and is there any way that I could avoid it?  I have
> storage provided by a Cinder integration and so the consumption of
> compute node disk for instance data I need to avoid. 
>
> Any information the community could provide to me with regards to the
> above would be much appreciated. I would very much like to use the
> Magnum project in this deployment for Kubernetes deployment within
> projects. 
>
> Thanks in advance, 
>
> Regards,
>
> Tony

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
------------------------------------------------------ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200910/16973970/attachment-0001.html>

From renat.akhmerov at gmail.com  Thu Sep 10 08:04:51 2020
From: renat.akhmerov at gmail.com (Renat Akhmerov)
Date: Thu, 10 Sep 2020 15:04:51 +0700
Subject: Moving on
In-Reply-To: <4965dddc-9480-ecff-1004-6aeb2fc39619@debian.org>
References: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
 <4965dddc-9480-ecff-1004-6aeb2fc39619@debian.org>
Message-ID: <ef55a44c-181d-418d-b0ca-4820417087e1@Spark>

Oooh, wooow! You seemed a person who were going to be with OpenStack like… forever! Really sorry to hear your OpenStack time is about to end. Such a huge loss for us.

Anyway, I wish you all the best at whatever you’re going to do!

Thanks

Renat Akhmerov
@Nokia
On 10 Sep 2020, 06:16 +0700, Thomas Goirand <zigo at debian.org>, wrote:
> On 9/9/20 6:10 PM, Monty Taylor wrote:
> > Hi everybody,
> >
> > After 10 years of OpenStack, the time has come for me to move on to the next challenge. Actually, the time came a few weeks ago, but writing farewells has always been something I’m particularly bad at. My last day at Red Hat was actually July 31 and I’m now working in a non-OpenStack job.
> >
> > I’m at a loss for words as to what more to say. I’ve never done anything for 10 years before, and I’ll be very surprised if I do anything else for 10 years again. While I’m excited about the new things on my plate, I’ll obviously miss everyone.
> >
> > As I am no longer being paid by an OpenStack employer, I will not be doing any OpenStack things as part of my day job. I’m not sure how much spare time I’ll have to be able to contribute. I’m going to hold off on resigning core memberships pending a better understanding of that. I think it’s safe to assume I won’t be able to continue on as SDK PTL though.
> >
> > I wish everyone all the best, and I hope life conspires to keep us all connected.
> >
> > Thank you to everyone for an amazing 10 years.
> >
> > Monty
> >
>
> Monty,
>
> We'll miss you! Both for your technical excellence, and for the nicer
> person that you are. Good luck for whatever's next.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200910/92ea3e4b/attachment.html>

From thierry at openstack.org  Thu Sep 10 08:37:38 2020
From: thierry at openstack.org (Thierry Carrez)
Date: Thu, 10 Sep 2020 10:37:38 +0200
Subject: Moving on
In-Reply-To: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
References: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
Message-ID: <9d6ea1dd-440a-45be-8d74-add6db3222a2@openstack.org>

Monty Taylor wrote:
> [...]
> Thank you to everyone for an amazing 10 years.
> [...]
Good luck in your future endeavors, Monty.

I traveled the world and the seven seas with you, from walking the 
streets of Jerusalem, to eating fries by the Ixelles ponds in Brussels, 
to drinking cocktails in a Dallas pool. Looking forward to when we can 
do that again!

Cheers,

-- 
Thierry Carrez (ttx)


From vijarad1 at in.ibm.com  Thu Sep 10 09:22:08 2020
From: vijarad1 at in.ibm.com (Vijayendra R Radhakrishna)
Date: Thu, 10 Sep 2020 09:22:08 +0000
Subject: Cloudinit resets network scripts to default configuration DHCP once
 Config Drive is removed after sometime on Openstack platform
Message-ID: <OF8368D99C.E2499442-ON002585DF.0030ECE4-002585DF.00337743@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200910/12bbab28/attachment.html>

From thierry at openstack.org  Thu Sep 10 09:29:33 2020
From: thierry at openstack.org (Thierry Carrez)
Date: Thu, 10 Sep 2020 11:29:33 +0200
Subject: [largescale-sig] Next meeting: September 9, 16utc
In-Reply-To: <5983106a-fda8-2e5f-b4b3-1fe609f5843d@openstack.org>
References: <5983106a-fda8-2e5f-b4b3-1fe609f5843d@openstack.org>
Message-ID: <f43fa4c4-5d75-3775-fed6-6fe5193f9c50@openstack.org>

Two new US-based participants joined the meeting, James Penick and Erik 
Andersson. We identified a new work area that the SIG should work on: 
meaningful monitoring.

Meeting logs at:
http://eavesdrop.openstack.org/meetings/large_scale_sig/2020/large_scale_sig.2020-09-09-16.00.html

TODOs:
- all to describe briefly how you solved metrics/billing in your 
deployment in https://etherpad.openstack.org/p/large-scale-sig-documentation
- ttx to look into a basic test framework for oslo.metrics
- masahito to push latest patches to oslo.metrics
- amorin to see if oslo.metrics could be tested at OVH
- ttx to file Scaling Stories forum session, with amorin and someone 
from penick's team to help get it off the ground

Next meetings: Sep 23, 8:00UTC; Oct 7, 16:00UTC (#openstack-meeting-3)

-- 
Thierry Carrez (ttx)


From yasufum.o at gmail.com  Thu Sep 10 09:31:17 2020
From: yasufum.o at gmail.com (Yasufumi Ogawa)
Date: Thu, 10 Sep 2020 18:31:17 +0900
Subject: [all][tc][goals] Migrate CI/CD jobs to new Ubuntu LTS Focal: Week
 R-4 Update
In-Reply-To: <17476128313.f7b6001e28321.7088729119972703547@ghanshyammann.com>
References: <17468f8f785.1123a07e6307801.3844845549431858647@ghanshyammann.com>
 <1746feef403.c41c848411058.2421030943223377212@ghanshyammann.com>
 <1747442027f.bb3f3d1823475.212800600164097649@ghanshyammann.com>
 <17476128313.f7b6001e28321.7088729119972703547@ghanshyammann.com>
Message-ID: <236b2c69-530a-2266-08e3-170b86c16a9d@gmail.com>

Hi gmann,

Sorry for that we've not merged your patch to Tacker because devstack on 
Focal fails in functional test. It seems gnocchi installation on Focal 
has some problems.

Anyway, although this issue isn't fixed yet, we'll proceed to merge the 
patch immediately.

Thanks,
Yasufumi

On 2020/09/10 12:32, Ghanshyam Mann wrote:
> Updates:
> 
> Fixed a few more projects today which I found failing on Focal:
> 
> - OpenStack SDKs repos : ready to merge
> - All remaining Oslo lib fixes:  we are discussing FFE on these in separate ML thread.
> - Keystone: Fix is up, it should pass now.
> - Manila: Fix is up, it should pass gate.
> - Tacker: Ready to merge
> - neutron-dynamic-routing: Ready to merge
> - Cinder- it seems l-c job still failing. I will dig into it tomorrow or it will be appreciated if anyone can take a look before my morning.
> this is the patch -https://review.opendev.org/#/c/743080/
> 
> Note: all tox based jobs (Except py36/3.7) are running on Focal now so If any of you gate failing, feel free to ping me on #openstack-qa
> 
> No more energy left for today, I will continue the remaining work tomorrow.
> 
> -gmann
> 
>   ---- On Wed, 09 Sep 2020 14:05:17 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
>   >  ---- On Tue, 08 Sep 2020 17:56:05 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
>   >  > Updates:
>   >  > After working more on failing one today and listing the blocking one, I think we are good to switch tox based testing today
>   >  > and discuss the integration testing switch tomorrow in TC office hours.
>   >  >
>   >  > > * Part1: Migrating tox base job tomorrow (8th Sept):
>   >  >
>   >  > I have checked it again and fixed many repos that are up for review and merge. Most python clients are already fixed
>   >  > or their fixes are up for merge so they can make it before the feature freeze on 10th. If any repo is broken then it will be pretty quick
>   >  > to fix by lower constraint bump (see the example under https://review.opendev.org/#/q/topic:migrate-to-focal)
>   >  >
>   >  > Even if any of the fixes miss the victoria release then those can be backported easily. I am opening the tox base jobs migration to merge:
>   >  >  - All patches in this series https://review.opendev.org/#/c/738328/
>   >
>   > All these tox base jobs are merged now and running on Focal. If any of your repo is failing, please fix on priority or ping me on IRC if failure not clear.
>   > You can find most of the fixes for possible failure in this topic:
>   > - https://review.opendev.org/#/q/topic:migrate-to-focal+(status:open+OR+status:merged)
>   >
>   > -gmann
>   >
>   >
>   >  >
>   >  >
>   >  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
>   >  >
>   >  > We have three blocking open bugs here so I would like to discuss it in tomorrow's TC office hour also about how to proceed on this.
>   >  >
>   >  > 1. Nova: https://bugs.launchpad.net/nova/+bug/1882521  (https://bugs.launchpad.net/qemu/+bug/1894804)
>   >  > 2. Barbican: https://storyboard.openstack.org/#!/story/2007732
>   >  > 3. Ceilometer: https://storyboard.openstack.org/#!/story/2008121
>   >  >
>   >  >
>   >  > -gmann
>   >  >
>   >  >
>   >  >  ---- On Mon, 07 Sep 2020 09:29:40 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
>   >  >  > Hello Everyone,
>   >  >  >
>   >  >  > Please find the week R-4 updates on 'Ubuntu Focal migration' community goal. Its time to force the base jobs migration which can
>   >  >  > break the projects gate if not yet taken care of. Read below for the plan.
>   >  >  >
>   >  >  > Tracking: https://storyboard.openstack.org/#!/story/2007865
>   >  >  >
>   >  >  > Progress:
>   >  >  > =======
>   >  >  > * We are close to V-3 release and this is time we have to complete this migration otherwise doing it in RC period can add
>   >  >  > unnecessary and last min delay. I am going to plan this migration in two-part. This will surely break some projects gate
>   >  >  > which is not yet finished the migration but we have to do at some time. Please let me know if any objection to the below
>   >  >  > plan.
>   >  >  >
>   >  >  > * Part1: Migrating tox base job tomorrow (8th Sept):
>   >  >  >
>   >  >  > ** I am going to open tox base jobs migration (doc, unit, functional, lower-constraints etc) to merge by tomorrow. which is this
>   >  >  > series (all base patches of this):  https://review.opendev.org/#/c/738328/ .
>   >  >  >
>   >  >  > **There are few repos still failing on requirements lower-constraints job specifically which I tried my best to fix as many as possible.
>   >  >  >  Many are ready to merge also. Please merge or work on your projects repo testing before that or fix on priority if failing.
>   >  >  >
>   >  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
>   >  >  >
>   >  >  > * We have few open bugs for this which are not yet resolved, we will see how it goes but the current plan is to migrate by 10th Sept.
>   >  >  >
>   >  >  > ** Bug#1882521
>   >  >  > ** DB migration issues,
>   >  >  > *** alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003
>   >  >  >
>   >  >  >
>   >  >  > Testing Till now:
>   >  >  > ============
>   >  >  > * ~200 repos gate have been tested or fixed till now.
>   >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+(status:abandoned+OR+status:merged)
>   >  >  >
>   >  >  > * ~100 repos are under test and failing. Debugging and fixing are in progress (If you would like to help, please check your
>   >  >  > project repos if I am late to fix them):
>   >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open
>   >  >  >
>   >  >  > * ~30repos fixes ready to merge:
>   >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open+label%3AVerified%3E%3D1%2Czuul+NOT+label%3AWorkflow%3C%3D-1
>   >  >  >
>   >  >  >
>   >  >  > Bugs Report:
>   >  >  > ==========
>   >  >  >
>   >  >  > 1. Bug#1882521. (IN-PROGRESS)
>   >  >  > There is open bug for nova/cinder where three tempest tests are failing for
>   >  >  > volume detach operation. There is no clear root cause found yet
>   >  >  > -https://bugs.launchpad.net/cinder/+bug/1882521
>   >  >  > We have skipped the tests in tempest base patch to proceed with the other
>   >  >  > projects testing but this is blocking things for the migration.
>   >  >  >
>   >  >  > 2. DB migration issues (IN-PROGRESS)
>   >  >  > * alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003
>   >  >  >
>   >  >  > 3. We encountered the nodeset name conflict with x/tobiko. (FIXED)
>   >  >  > nodeset conflict is resolved now and devstack provides all focal nodes now.
>   >  >  >
>   >  >  > 4. Bug#1886296. (IN-PROGRESS)
>   >  >  > pyflakes till 2.1.0 is not compatible with python 3.8 which is the default python version
>   >  >  > on ubuntu focal[1]. With pep8 job running on focal faces the issue and fail. We need to bump
>   >  >  > the pyflakes to 2.1.1 as min version to run pep8 jobs on py3.8.
>   >  >  > As of now, many projects are using old hacking version so I am explicitly adding pyflakes>=2.1.1
>   >  >  > on the project side[2] but for the long term easy maintenance, I am doing it in 'hacking' requirements.txt[3]
>   >  >  > nd will release a new hacking version. After that project can move to new hacking and do not need
>   >  >  > to maintain pyflakes version compatibility.
>   >  >  >
>   >  >  > 5. Bug#1886298. (IN-PROGRESS)
>   >  >  > 'Markupsafe' 1.0 is not compatible with the latest version of setuptools[4],
>   >  >  > We need to bump the lower-constraint for Markupsafe to 1.1.1 to make it work.
>   >  >  > There are a few more issues[5] with lower-constraint jobs which I am debugging.
>   >  >  >
>   >  >  >
>   >  >  > What work to be done on the project side:
>   >  >  > ================================
>   >  >  > This goal is more of testing the jobs on focal and fixing bugs if any otherwise
>   >  >  > migrate jobs by switching the nodeset to focal node sets defined in devstack.
>   >  >  >
>   >  >  > 1. Start a patch in your repo by making depends-on on either of below:
>   >  >  > devstack base patch if you are using only devstack base jobs not tempest:
>   >  >  >
>   >  >  > Depends-on: https://review.opendev.org/#/c/731207/
>   >  >  > OR
>   >  >  > tempest base patch if you are using the tempest base job (like devstack-tempest):
>   >  >  > Depends-on: https://review.opendev.org/#/c/734700/
>   >  >  >
>   >  >  > Both have depends-on on the series where I am moving unit/functional/doc/cover/nodejs tox jobs to focal. So
>   >  >  > you can test the complete gate jobs(unit/functional/doc/integration) together.
>   >  >  > This and its base patches - https://review.opendev.org/#/c/738328/
>   >  >  >
>   >  >  > Example: https://review.opendev.org/#/c/738126/
>   >  >  >
>   >  >  > 2. If none of your project jobs override the nodeset then above patch will be
>   >  >  > testing patch(do not merge) otherwise change the nodeset to focal.
>   >  >  > Example: https://review.opendev.org/#/c/737370/
>   >  >  >
>   >  >  > 3. If the jobs are defined in branchless repo and override the nodeset then you need to override the branches
>   >  >  > variant to adjust the nodeset so that those jobs run on Focal on victoria onwards only. If no nodeset
>   >  >  > is overridden then devstack being branched and stable base job using bionic/xenial will take care of
>   >  >  > this.
>   >  >  > Example: https://review.opendev.org/#/c/744056/2
>   >  >  >
>   >  >  > 4. If no updates need you can abandon the testing patch (https://review.opendev.org/#/c/744341/). If it need
>   >  >  > updates then modify the same patch with proper commit msg, once it pass the gate then remove the Depends-On
>   >  >  > so that you can merge your patch before base jobs are switched to focal. This way we make sure no gate downtime in
>   >  >  > this migration.
>   >  >  > Example: https://review.opendev.org/#/c/744056/1..2//COMMIT_MSG
>   >  >  >
>   >  >  > Once we finish the testing on projects side and no failure then we will merge the devstack and tempest
>   >  >  > base patches.
>   >  >  >
>   >  >  >
>   >  >  > Important things to note:
>   >  >  > ===================
>   >  >  > * Do not forgot to add the story and task link to your patch so that we can track it smoothly.
>   >  >  > * Use gerrit topic 'migrate-to-focal'
>   >  >  > * Do not backport any of the patches.
>   >  >  >
>   >  >  >
>   >  >  > References:
>   >  >  > =========
>   >  >  > Goal doc: https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-jobs-to-ubuntu-focal.html
>   >  >  > Storyboard tracking: https://storyboard.openstack.org/#!/story/2007865
>   >  >  >
>   >  >  > [1] https://github.com/PyCQA/pyflakes/issues/367
>   >  >  > [2] https://review.opendev.org/#/c/739315/
>   >  >  > [3] https://review.opendev.org/#/c/739334/
>   >  >  > [4] https://github.com/pallets/markupsafe/issues/116
>   >  >  > [5] https://zuul.opendev.org/t/openstack/build/7ecd9cf100194bc99b3b70fa1e6de032
>   >  >  >
>   >  >  > -gmann
>   >  >  >
>   >  >  >
>   >  >
>   >  >
>   >
>   >
> 


From radoslaw.piliszek at gmail.com  Thu Sep 10 11:10:44 2020
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Thu, 10 Sep 2020 13:10:44 +0200
Subject: Is Storyboard really the future?
Message-ID: <CAKZ_x7_kN4PBRKfTPL0PNOyxqbkL3Di1MV9AFkYnaU75mzeD8Q@mail.gmail.com>

Hi fellow OpenStackers,

The subject is the question I am posing.
The general recommendation is to use Storyboard for new projects [1].
However, Storyboard does not seem to be receiving enough love recently [2] [3].
It's generally deemed as slow [4] and is missing quite a few usability
enhancements [2].
Considering the alternative, and the actual previous recommendation,
is Launchpad, I find it no-brainer to revert to recommending Launchpad
still, even paving a way for projects wishing to escape the Storyboard
nightmare. :-)

Don't get me wrong, I really like the Story/Task orientation but
Storyboard results in a frustrating experience. In addition to being
slow, it has issues with search/filter, sorting and pagination which
make issue browsing an utter pain.
I know Launchpad is not without issues but it's certainly a much
better platform at the moment.
And many projects are still there.

The Launchpad-Storyboard split is also introducing confusion for users
[5] and coordinability issues for teams as we need to cross-link
manually to get proper visibility.

All in all, I ask you to consider recommending Launchpad again and
encourage OpenStack projects to move to Launchpad.

Extra note: I find it in a similar spot as ask.o.o - nice it has been
tried, but unfortunately it did not stand the test of time.

[1] https://docs.opendev.org/opendev/infra-manual/latest/creators.html
[2] https://storyboard.openstack.org/#!/project/opendev/storyboard
[3] https://opendev.org/opendev/storyboard/commits/branch/master
[4] https://storyboard.openstack.org/#!/story/2007829
[5] https://storyboard.openstack.org/#!/story/2000890

-yoctozepto


From mnaser at vexxhost.com  Thu Sep 10 11:55:32 2020
From: mnaser at vexxhost.com (Mohammed Naser)
Date: Thu, 10 Sep 2020 07:55:32 -0400
Subject: [tc] meeting summary
Message-ID: <CAEs876i15odcQQ9pjfCTYphTOSwwMGsmbJp1Z1EX27cZuWxZQg@mail.gmail.com>

Hi everyone,

Here's a summary of what happened in our TC monthly meeting last
Thursday, September 3.

# ATTENDEES (LINES SAID)
- mnaser (72)
- gmann (35)
- ttx (22)
- diablo_rojo (19)
- belmoreira (18)
- knikolla (16)
- njohnston (11)
- fungi (7)
- smcginnis (2)
- ricolin (2)

# MEETING SUMMARY
1. Rollcall (mnaser, 14:01:13)
2. Follow up on past action items (mnaser, 14:04:27)
- http://eavesdrop.openstack.org/meetings/tc/2020/tc.2020-08-06-14.00.html
(mnaser, 14:04:59)
3. OpenStack User-facing APIs and CLIs (belmoreira, 14:11:33)
4. W cycle goal selection start (mnaser, 14:33:43)
5. Completion of retirement cleanup (gmann, 14:34:45)
- https://etherpad.opendev.org/p/tc-retirement-cleanup (mnaser, 14:34:52)
- https://review.opendev.org/#/c/745403/ (mnaser, 14:35:06)
6. Audit and clean-up tags (gmann, 14:37:25)
- https://review.opendev.org/#/c/749363/ (mnaser, 14:37:35)
7. open discussion (mnaser, 14:43:54)

# ACTION ITEMS
- tc-members to follow up and review "Resolution to define distributed
leadership for projects".
- mnaser schedule session with sig-arch and k8s steering committee.
- njohnston to find someone to work with on getting goals
groomed/proposed for W cycle.
- belmoreira/knikolla figure out logistics of a document with gaps within osc.
- diablo_rojo help schedule forum session for OSC gaps.

To read the full logs of the meeting, please refer to
http://eavesdrop.openstack.org/meetings/tc/2020/tc.2020-09-03-14.01.log.html

Thanks,
Mohammed
-- 
Mohammed Naser
VEXXHOST, Inc.


From smooney at redhat.com  Thu Sep 10 12:06:52 2020
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 10 Sep 2020 13:06:52 +0100
Subject: Is Storyboard really the future?
In-Reply-To: <CAKZ_x7_kN4PBRKfTPL0PNOyxqbkL3Di1MV9AFkYnaU75mzeD8Q@mail.gmail.com>
References: <CAKZ_x7_kN4PBRKfTPL0PNOyxqbkL3Di1MV9AFkYnaU75mzeD8Q@mail.gmail.com>
Message-ID: <0116e7bfa3c5b0dc81b5f6086c96f4e4d51b7627.camel@redhat.com>

On Thu, 2020-09-10 at 13:10 +0200, Radosław Piliszek wrote:
> Hi fellow OpenStackers,
> 
> The subject is the question I am posing.
> The general recommendation is to use Storyboard for new projects [1].
> However, Storyboard does not seem to be receiving enough love recently [2] [3].
> It's generally deemed as slow [4] and is missing quite a few usability
> enhancements [2].
> Considering the alternative, and the actual previous recommendation,
> is Launchpad, I find it no-brainer to revert to recommending Launchpad
> still, even paving a way for projects wishing to escape the Storyboard
> nightmare. :-)
> 
> Don't get me wrong, I really like the Story/Task orientation but
> Storyboard results in a frustrating experience. In addition to being
> slow, it has issues with search/filter, sorting and pagination which
> make issue browsing an utter pain.
> I know Launchpad is not without issues but it's certainly a much
> better platform at the moment.
> And many projects are still there.
> 
> The Launchpad-Storyboard split is also introducing confusion for users
> [5] and coordinability issues for teams as we need to cross-link
> manually to get proper visibility.
> 
> All in all, I ask you to consider recommending Launchpad again and
> encourage OpenStack projects to move to Launchpad.
some porjects like nova and neutron never left launchpad and personally
i had hopped they never would so that is still my preference but as far
as i know there is notihgn preventing any project form move too or moving
from launchpad as it stands.

if kolla* waht move they can without needing to change any other policies
the cookie cutter templeate for seting up new repo also support both you can
select it when you create the repo. im not sure what the default is currently
but you are given the choice if i recall correctly.
> 
> Extra note: I find it in a similar spot as ask.o.o - nice it has been
> tried, but unfortunately it did not stand the test of time.
> 
> [1] https://docs.opendev.org/opendev/infra-manual/latest/creators.html
> [2] https://storyboard.openstack.org/#!/project/opendev/storyboard
> [3] https://opendev.org/opendev/storyboard/commits/branch/master
> [4] https://storyboard.openstack.org/#!/story/2007829
> [5] https://storyboard.openstack.org/#!/story/2000890
> 
> -yoctozepto
> 



From elod.illes at est.tech  Thu Sep 10 12:40:53 2020
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Thu, 10 Sep 2020 14:40:53 +0200
Subject: [cinder][stable][infra] branch freeze for ocata, pike
In-Reply-To: <ed869983-18e0-b8b8-1c50-a697e990be72@gmail.com>
References: <ed869983-18e0-b8b8-1c50-a697e990be72@gmail.com>
Message-ID: <56e12f48-f2f8-0a26-1830-093c9fe9d9db@est.tech>

Hi Infra Team,

While reviewing Andreas' patch [1], I have realized, that Cinder's 
stable/ocata and stable/pike branches were not deleted yet, however 
those branches were EOL'd already (see mail below).

According to the process [2], since the EOL patches have merged already, 
if @Brian doesn't object, can you please delete

- cinder stable/ocata
- cinder stable/pike

Thanks in advance,

Előd

[1] https://review.opendev.org/#/c/750887/
[2] 
https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-life


On 2020. 07. 28. 16:23, Brian Rosmaita wrote:
> tl;dr - do not approve any backports to stable/ocata or stable/pike in 
> any Cinder project deliverable
>
> stable/ocata has been tagged with ocata-eol in cinder, os-brick, 
> python-cinderclient, and python-brick-cinderclient-ext.  Nothing 
> should be merged into stable/ocata in any of these repositories during 
> the interim period before the branches are deleted.
>
> stable/pike: the changes discussed in [0] have merged, and I've
> proposed the pike-eol tags [1].  Nothing should be merged into 
> stable/pike in any of our code repositories from now until the 
> branches are deleted.
>
> [0] 
> http://lists.openstack.org/pipermail/openstack-discuss/2020-July/016076.html
> [1] https://review.opendev.org/#/c/742523/
>



From elmiko at redhat.com  Thu Sep 10 12:41:37 2020
From: elmiko at redhat.com (Michael McCune)
Date: Thu, 10 Sep 2020 08:41:37 -0400
Subject: Moving on
In-Reply-To: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
References: <4625D3D3-CDE8-4E4C-9318-013DC2895F26@inaugust.com>
Message-ID: <CADE+ktQM2ir1faJWK8_e2gsDYXwVkWMsv8Xk0g3tf1w-HXwoQw@mail.gmail.com>

Monty, it was a true pleasure having the opportunity to cross paths and
collaborate with you. 10 years is a great run and we are richer for your
contributions, best wishes for your next adventure =)

peace o/

On Wed, Sep 9, 2020 at 12:16 PM Monty Taylor <mordred at inaugust.com> wrote:

> Hi everybody,
>
> After 10 years of OpenStack, the time has come for me to move on to the
> next challenge. Actually, the time came a few weeks ago, but writing
> farewells has always been something I’m particularly bad at. My last day at
> Red Hat was actually July 31 and I’m now working in a non-OpenStack job.
>
> I’m at a loss for words as to what more to say. I’ve never done anything
> for 10 years before, and I’ll be very surprised if I do anything else for
> 10 years again. While I’m excited about the new things on my plate, I’ll
> obviously miss everyone.
>
> As I am no longer being paid by an OpenStack employer, I will not be doing
> any OpenStack things as part of my day job. I’m not sure how much spare
> time I’ll have to be able to contribute. I’m going to hold off on resigning
> core memberships pending a better understanding of that. I think it’s safe
> to assume I won’t be able to continue on as SDK PTL though.
>
> I wish everyone all the best, and I hope life conspires to keep us all
> connected.
>
> Thank you to everyone for an amazing 10 years.
>
> Monty
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200910/c29aca78/attachment.html>

From aj at suse.com  Thu Sep 10 12:42:39 2020
From: aj at suse.com (Andreas Jaeger)
Date: Thu, 10 Sep 2020 14:42:39 +0200
Subject: [cinder][stable] branch freeze for ocata, pike
In-Reply-To: <ed869983-18e0-b8b8-1c50-a697e990be72@gmail.com>
References: <ed869983-18e0-b8b8-1c50-a697e990be72@gmail.com>
Message-ID: <5af2fc9b-dfeb-f7cf-a491-fb4eab14f76f@suse.com>

On 28.07.20 16:23, Brian Rosmaita wrote:
> tl;dr - do not approve any backports to stable/ocata or stable/pike in
> any Cinder project deliverable
> 
> stable/ocata has been tagged with ocata-eol in cinder, os-brick,
> python-cinderclient, and python-brick-cinderclient-ext.  Nothing should
> be merged into stable/ocata in any of these repositories during the
> interim period before the branches are deleted.

When do you plan to delete those branches? We have Zuul jobs that are
broken, for example due to removal of devstack-plugin-zmq and we either
should remove these from the branch or delete the branch. Currently Zuul
complains about broken jobs.

The two changes I talk about are:
https://review.opendev.org/750887
https://review.opendev.org/750886

Andreas

> 
> stable/pike: the changes discussed in [0] have merged, and I've
> proposed the pike-eol tags [1].  Nothing should be merged into
> stable/pike in any of our code repositories from now until the branches
> are deleted.
> 
> [0]
> http://lists.openstack.org/pipermail/openstack-discuss/2020-July/016076.html
> 
> [1] https://review.opendev.org/#/c/742523/
> 


-- 
 Andreas Jaeger aj at suse.com Twitter: jaegerandi
  SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg
   (HRB 36809, AG Nürnberg) GF: Felix Imendörffer
    GPG fingerprint = EF18 1673 38C4 A372 86B1  E699 5294 24A3 FF91 2ACB



From radoslaw.piliszek at gmail.com  Thu Sep 10 13:22:44 2020
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Thu, 10 Sep 2020 15:22:44 +0200
Subject: Is Storyboard really the future?
In-Reply-To: <0116e7bfa3c5b0dc81b5f6086c96f4e4d51b7627.camel@redhat.com>
References: <CAKZ_x7_kN4PBRKfTPL0PNOyxqbkL3Di1MV9AFkYnaU75mzeD8Q@mail.gmail.com>
 <0116e7bfa3c5b0dc81b5f6086c96f4e4d51b7627.camel@redhat.com>
Message-ID: <CAKZ_x794eixUCBco1KvKUDqX8q6xZMgX8DnG4zr0BOLF_BF+kg@mail.gmail.com>

Hi Sean,

On Thu, Sep 10, 2020 at 2:06 PM Sean Mooney <smooney at redhat.com> wrote:
>
> On Thu, 2020-09-10 at 13:10 +0200, Radosław Piliszek wrote:
> > Hi fellow OpenStackers,
> >
> > The subject is the question I am posing.
> > The general recommendation is to use Storyboard for new projects [1].
> > However, Storyboard does not seem to be receiving enough love recently [2] [3].
> > It's generally deemed as slow [4] and is missing quite a few usability
> > enhancements [2].
> > Considering the alternative, and the actual previous recommendation,
> > is Launchpad, I find it no-brainer to revert to recommending Launchpad
> > still, even paving a way for projects wishing to escape the Storyboard
> > nightmare. :-)
> >
> > Don't get me wrong, I really like the Story/Task orientation but
> > Storyboard results in a frustrating experience. In addition to being
> > slow, it has issues with search/filter, sorting and pagination which
> > make issue browsing an utter pain.
> > I know Launchpad is not without issues but it's certainly a much
> > better platform at the moment.
> > And many projects are still there.
> >
> > The Launchpad-Storyboard split is also introducing confusion for users
> > [5] and coordinability issues for teams as we need to cross-link
> > manually to get proper visibility.
> >
> > All in all, I ask you to consider recommending Launchpad again and
> > encourage OpenStack projects to move to Launchpad.
> some porjects like nova and neutron never left launchpad and personally
> i had hopped they never would so that is still my preference but as far
> as i know there is notihgn preventing any project form move too or moving
> from launchpad as it stands.

Kolla did neither. We only have Kayobe that's on Storyboard (due to
recommendation).

I did not want to sound like it was enforced. It is not - as far as I
understand it.

The thing is: recommending a perceivably worse solution does not seem like
a good idea to me. It also does not benefit the scene to split it
between two worlds.

-yoctozepto

> if kolla* waht move they can without needing to change any other policies
> the cookie cutter templeate for seting up new repo also support both you can
> select it when you create the repo. im not sure what the default is currently
> but you are given the choice if i recall correctly.
> >
> > Extra note: I find it in a similar spot as ask.o.o - nice it has been
> > tried, but unfortunately it did not stand the test of time.
> >
> > [1] https://docs.opendev.org/opendev/infra-manual/latest/creators.html
> > [2] https://storyboard.openstack.org/#!/project/opendev/storyboard
> > [3] https://opendev.org/opendev/storyboard/commits/branch/master
> > [4] https://storyboard.openstack.org/#!/story/2007829
> > [5] https://storyboard.openstack.org/#!/story/2000890
> >
> > -yoctozepto
> >
>


From rosmaita.fossdev at gmail.com  Thu Sep 10 13:30:20 2020
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Thu, 10 Sep 2020 09:30:20 -0400
Subject: [cinder][stable][infra] branch freeze for ocata, pike
In-Reply-To: <56e12f48-f2f8-0a26-1830-093c9fe9d9db@est.tech>
References: <ed869983-18e0-b8b8-1c50-a697e990be72@gmail.com>
 <56e12f48-f2f8-0a26-1830-093c9fe9d9db@est.tech>
Message-ID: <2013dd9e-386a-1190-8e5b-33338cc44d59@gmail.com>

On 9/10/20 8:40 AM, Előd Illés wrote:
> Hi Infra Team,
> 
> While reviewing Andreas' patch [1], I have realized, that Cinder's 
> stable/ocata and stable/pike branches were not deleted yet, however 
> those branches were EOL'd already (see mail below).
> 
> According to the process [2], since the EOL patches have merged already, 
> if @Brian doesn't object, can you please delete
> 
> - cinder stable/ocata
> - cinder stable/pike

I have no objection, but I haven't pushed the infra team about the 
actual branch deletion because as far as I know, cinder is the first 
project to actually request removal, and I suspect all sorts of stuff 
will break.  I suggest we wait until at least after RC-time to give us 
all one less thing to worry about.

As far as avoiding breakage goes, I put up two patches to devstack so 
that it will check out the -eol tag of cinder/brick/cinderclient instead 
of the stable branch, but I suspect these only scratch the surface of 
what can be broken once the cinder project branches are deleted.

https://review.opendev.org/#/c/742953/
https://review.opendev.org/#/c/742952/

Sean suggested in an earlier thread on this topic [0] that instead of 
deleting very old EM branches that some projects have EOL'd 
project-by-project, we should just delete them wholesale across 
openstack.  That makes a lot of sense to me.

[0] 
http://lists.openstack.org/pipermail/openstack-discuss/2020-May/015115.html


cheers,
brian

> 
> Thanks in advance,
> 
> Előd
> 
> [1] https://review.opendev.org/#/c/750887/
> [2] 
> https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-life 
> 
> 
> 
> On 2020. 07. 28. 16:23, Brian Rosmaita wrote:
>> tl;dr - do not approve any backports to stable/ocata or stable/pike in 
>> any Cinder project deliverable
>>
>> stable/ocata has been tagged with ocata-eol in cinder, os-brick, 
>> python-cinderclient, and python-brick-cinderclient-ext.  Nothing 
>> should be merged into stable/ocata in any of these repositories during 
>> the interim period before the branches are deleted.
>>
>> stable/pike: the changes discussed in [0] have merged, and I've
>> proposed the pike-eol tags [1].  Nothing should be merged into 
>> stable/pike in any of our code repositories from now until the 
>> branches are deleted.
>>
>> [0] 
>> http://lists.openstack.org/pipermail/openstack-discuss/2020-July/016076.html 
>>
>> [1] https://review.opendev.org/#/c/742523/
>>
> 



From gmann at ghanshyammann.com  Thu Sep 10 13:43:15 2020
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 10 Sep 2020 08:43:15 -0500
Subject: [all][tc][goals] Migrate CI/CD jobs to new Ubuntu LTS Focal:
 Week R-4 Update
In-Reply-To: <236b2c69-530a-2266-08e3-170b86c16a9d@gmail.com>
References: <17468f8f785.1123a07e6307801.3844845549431858647@ghanshyammann.com>
 <1746feef403.c41c848411058.2421030943223377212@ghanshyammann.com>
 <1747442027f.bb3f3d1823475.212800600164097649@ghanshyammann.com>
 <17476128313.f7b6001e28321.7088729119972703547@ghanshyammann.com>
 <236b2c69-530a-2266-08e3-170b86c16a9d@gmail.com>
Message-ID: <17478418b45.c9cb264d62678.8113988885859095234@ghanshyammann.com>

 ---- On Thu, 10 Sep 2020 04:31:17 -0500 Yasufumi Ogawa <yasufum.o at gmail.com> wrote ----
 > Hi gmann,
 > 
 > Sorry for that we've not merged your patch to Tacker because devstack on 
 > Focal fails in functional test. It seems gnocchi installation on Focal 
 > has some problems.
 > 
 > Anyway, although this issue isn't fixed yet, we'll proceed to merge the 
 > patch immediately.

Thanks Yasufumi.

I reported the gnoochi issue in the below storyboard and tried to reach out to the ceilometer team
also but found not get any response.  I will check what to do on this blocker.

https://storyboard.openstack.org/#!/story/2008121


-gmann

 > 
 > Thanks,
 > Yasufumi
 > 
 > On 2020/09/10 12:32, Ghanshyam Mann wrote:
 > > Updates:
 > > 
 > > Fixed a few more projects today which I found failing on Focal:
 > > 
 > > - OpenStack SDKs repos : ready to merge
 > > - All remaining Oslo lib fixes:  we are discussing FFE on these in separate ML thread.
 > > - Keystone: Fix is up, it should pass now.
 > > - Manila: Fix is up, it should pass gate.
 > > - Tacker: Ready to merge
 > > - neutron-dynamic-routing: Ready to merge
 > > - Cinder- it seems l-c job still failing. I will dig into it tomorrow or it will be appreciated if anyone can take a look before my morning.
 > > this is the patch -https://review.opendev.org/#/c/743080/
 > > 
 > > Note: all tox based jobs (Except py36/3.7) are running on Focal now so If any of you gate failing, feel free to ping me on #openstack-qa
 > > 
 > > No more energy left for today, I will continue the remaining work tomorrow.
 > > 
 > > -gmann
 > > 
 > >   ---- On Wed, 09 Sep 2020 14:05:17 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > >   >  ---- On Tue, 08 Sep 2020 17:56:05 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > >   >  > Updates:
 > >   >  > After working more on failing one today and listing the blocking one, I think we are good to switch tox based testing today
 > >   >  > and discuss the integration testing switch tomorrow in TC office hours.
 > >   >  >
 > >   >  > > * Part1: Migrating tox base job tomorrow (8th Sept):
 > >   >  >
 > >   >  > I have checked it again and fixed many repos that are up for review and merge. Most python clients are already fixed
 > >   >  > or their fixes are up for merge so they can make it before the feature freeze on 10th. If any repo is broken then it will be pretty quick
 > >   >  > to fix by lower constraint bump (see the example under https://review.opendev.org/#/q/topic:migrate-to-focal)
 > >   >  >
 > >   >  > Even if any of the fixes miss the victoria release then those can be backported easily. I am opening the tox base jobs migration to merge:
 > >   >  >  - All patches in this series https://review.opendev.org/#/c/738328/
 > >   >
 > >   > All these tox base jobs are merged now and running on Focal. If any of your repo is failing, please fix on priority or ping me on IRC if failure not clear.
 > >   > You can find most of the fixes for possible failure in this topic:
 > >   > - https://review.opendev.org/#/q/topic:migrate-to-focal+(status:open+OR+status:merged)
 > >   >
 > >   > -gmann
 > >   >
 > >   >
 > >   >  >
 > >   >  >
 > >   >  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
 > >   >  >
 > >   >  > We have three blocking open bugs here so I would like to discuss it in tomorrow's TC office hour also about how to proceed on this.
 > >   >  >
 > >   >  > 1. Nova: https://bugs.launchpad.net/nova/+bug/1882521  (https://bugs.launchpad.net/qemu/+bug/1894804)
 > >   >  > 2. Barbican: https://storyboard.openstack.org/#!/story/2007732
 > >   >  > 3. Ceilometer: https://storyboard.openstack.org/#!/story/2008121
 > >   >  >
 > >   >  >
 > >   >  > -gmann
 > >   >  >
 > >   >  >
 > >   >  >  ---- On Mon, 07 Sep 2020 09:29:40 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > >   >  >  > Hello Everyone,
 > >   >  >  >
 > >   >  >  > Please find the week R-4 updates on 'Ubuntu Focal migration' community goal. Its time to force the base jobs migration which can
 > >   >  >  > break the projects gate if not yet taken care of. Read below for the plan.
 > >   >  >  >
 > >   >  >  > Tracking: https://storyboard.openstack.org/#!/story/2007865
 > >   >  >  >
 > >   >  >  > Progress:
 > >   >  >  > =======
 > >   >  >  > * We are close to V-3 release and this is time we have to complete this migration otherwise doing it in RC period can add
 > >   >  >  > unnecessary and last min delay. I am going to plan this migration in two-part. This will surely break some projects gate
 > >   >  >  > which is not yet finished the migration but we have to do at some time. Please let me know if any objection to the below
 > >   >  >  > plan.
 > >   >  >  >
 > >   >  >  > * Part1: Migrating tox base job tomorrow (8th Sept):
 > >   >  >  >
 > >   >  >  > ** I am going to open tox base jobs migration (doc, unit, functional, lower-constraints etc) to merge by tomorrow. which is this
 > >   >  >  > series (all base patches of this):  https://review.opendev.org/#/c/738328/ .
 > >   >  >  >
 > >   >  >  > **There are few repos still failing on requirements lower-constraints job specifically which I tried my best to fix as many as possible.
 > >   >  >  >  Many are ready to merge also. Please merge or work on your projects repo testing before that or fix on priority if failing.
 > >   >  >  >
 > >   >  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
 > >   >  >  >
 > >   >  >  > * We have few open bugs for this which are not yet resolved, we will see how it goes but the current plan is to migrate by 10th Sept.
 > >   >  >  >
 > >   >  >  > ** Bug#1882521
 > >   >  >  > ** DB migration issues,
 > >   >  >  > *** alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003
 > >   >  >  >
 > >   >  >  >
 > >   >  >  > Testing Till now:
 > >   >  >  > ============
 > >   >  >  > * ~200 repos gate have been tested or fixed till now.
 > >   >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+(status:abandoned+OR+status:merged)
 > >   >  >  >
 > >   >  >  > * ~100 repos are under test and failing. Debugging and fixing are in progress (If you would like to help, please check your
 > >   >  >  > project repos if I am late to fix them):
 > >   >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open
 > >   >  >  >
 > >   >  >  > * ~30repos fixes ready to merge:
 > >   >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open+label%3AVerified%3E%3D1%2Czuul+NOT+label%3AWorkflow%3C%3D-1
 > >   >  >  >
 > >   >  >  >
 > >   >  >  > Bugs Report:
 > >   >  >  > ==========
 > >   >  >  >
 > >   >  >  > 1. Bug#1882521. (IN-PROGRESS)
 > >   >  >  > There is open bug for nova/cinder where three tempest tests are failing for
 > >   >  >  > volume detach operation. There is no clear root cause found yet
 > >   >  >  > -https://bugs.launchpad.net/cinder/+bug/1882521
 > >   >  >  > We have skipped the tests in tempest base patch to proceed with the other
 > >   >  >  > projects testing but this is blocking things for the migration.
 > >   >  >  >
 > >   >  >  > 2. DB migration issues (IN-PROGRESS)
 > >   >  >  > * alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003
 > >   >  >  >
 > >   >  >  > 3. We encountered the nodeset name conflict with x/tobiko. (FIXED)
 > >   >  >  > nodeset conflict is resolved now and devstack provides all focal nodes now.
 > >   >  >  >
 > >   >  >  > 4. Bug#1886296. (IN-PROGRESS)
 > >   >  >  > pyflakes till 2.1.0 is not compatible with python 3.8 which is the default python version
 > >   >  >  > on ubuntu focal[1]. With pep8 job running on focal faces the issue and fail. We need to bump
 > >   >  >  > the pyflakes to 2.1.1 as min version to run pep8 jobs on py3.8.
 > >   >  >  > As of now, many projects are using old hacking version so I am explicitly adding pyflakes>=2.1.1
 > >   >  >  > on the project side[2] but for the long term easy maintenance, I am doing it in 'hacking' requirements.txt[3]
 > >   >  >  > nd will release a new hacking version. After that project can move to new hacking and do not need
 > >   >  >  > to maintain pyflakes version compatibility.
 > >   >  >  >
 > >   >  >  > 5. Bug#1886298. (IN-PROGRESS)
 > >   >  >  > 'Markupsafe' 1.0 is not compatible with the latest version of setuptools[4],
 > >   >  >  > We need to bump the lower-constraint for Markupsafe to 1.1.1 to make it work.
 > >   >  >  > There are a few more issues[5] with lower-constraint jobs which I am debugging.
 > >   >  >  >
 > >   >  >  >
 > >   >  >  > What work to be done on the project side:
 > >   >  >  > ================================
 > >   >  >  > This goal is more of testing the jobs on focal and fixing bugs if any otherwise
 > >   >  >  > migrate jobs by switching the nodeset to focal node sets defined in devstack.
 > >   >  >  >
 > >   >  >  > 1. Start a patch in your repo by making depends-on on either of below:
 > >   >  >  > devstack base patch if you are using only devstack base jobs not tempest:
 > >   >  >  >
 > >   >  >  > Depends-on: https://review.opendev.org/#/c/731207/
 > >   >  >  > OR
 > >   >  >  > tempest base patch if you are using the tempest base job (like devstack-tempest):
 > >   >  >  > Depends-on: https://review.opendev.org/#/c/734700/
 > >   >  >  >
 > >   >  >  > Both have depends-on on the series where I am moving unit/functional/doc/cover/nodejs tox jobs to focal. So
 > >   >  >  > you can test the complete gate jobs(unit/functional/doc/integration) together.
 > >   >  >  > This and its base patches - https://review.opendev.org/#/c/738328/
 > >   >  >  >
 > >   >  >  > Example: https://review.opendev.org/#/c/738126/
 > >   >  >  >
 > >   >  >  > 2. If none of your project jobs override the nodeset then above patch will be
 > >   >  >  > testing patch(do not merge) otherwise change the nodeset to focal.
 > >   >  >  > Example: https://review.opendev.org/#/c/737370/
 > >   >  >  >
 > >   >  >  > 3. If the jobs are defined in branchless repo and override the nodeset then you need to override the branches
 > >   >  >  > variant to adjust the nodeset so that those jobs run on Focal on victoria onwards only. If no nodeset
 > >   >  >  > is overridden then devstack being branched and stable base job using bionic/xenial will take care of
 > >   >  >  > this.
 > >   >  >  > Example: https://review.opendev.org/#/c/744056/2
 > >   >  >  >
 > >   >  >  > 4. If no updates need you can abandon the testing patch (https://review.opendev.org/#/c/744341/). If it need
 > >   >  >  > updates then modify the same patch with proper commit msg, once it pass the gate then remove the Depends-On
 > >   >  >  > so that you can merge your patch before base jobs are switched to focal. This way we make sure no gate downtime in
 > >   >  >  > this migration.
 > >   >  >  > Example: https://review.opendev.org/#/c/744056/1..2//COMMIT_MSG
 > >   >  >  >
 > >   >  >  > Once we finish the testing on projects side and no failure then we will merge the devstack and tempest
 > >   >  >  > base patches.
 > >   >  >  >
 > >   >  >  >
 > >   >  >  > Important things to note:
 > >   >  >  > ===================
 > >   >  >  > * Do not forgot to add the story and task link to your patch so that we can track it smoothly.
 > >   >  >  > * Use gerrit topic 'migrate-to-focal'
 > >   >  >  > * Do not backport any of the patches.
 > >   >  >  >
 > >   >  >  >
 > >   >  >  > References:
 > >   >  >  > =========
 > >   >  >  > Goal doc: https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-jobs-to-ubuntu-focal.html
 > >   >  >  > Storyboard tracking: https://storyboard.openstack.org/#!/story/2007865
 > >   >  >  >
 > >   >  >  > [1] https://github.com/PyCQA/pyflakes/issues/367
 > >   >  >  > [2] https://review.opendev.org/#/c/739315/
 > >   >  >  > [3] https://review.opendev.org/#/c/739334/
 > >   >  >  > [4] https://github.com/pallets/markupsafe/issues/116
 > >   >  >  > [5] https://zuul.opendev.org/t/openstack/build/7ecd9cf100194bc99b3b70fa1e6de032
 > >   >  >  >
 > >   >  >  > -gmann
 > >   >  >  >
 > >   >  >  >
 > >   >  >
 > >   >  >
 > >   >
 > >   >
 > > 
 > 


From gmann at ghanshyammann.com  Thu Sep 10 13:46:19 2020
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 10 Sep 2020 08:46:19 -0500
Subject: [all][tc][goals] Migrate CI/CD jobs to new Ubuntu LTS Focal:
 Week R-4 Update
In-Reply-To: <CAKZ_x78soqu_Wq3n8c5KX0DHKqPBactUEo95eazVxb7sbZA-dQ@mail.gmail.com>
References: <17468f8f785.1123a07e6307801.3844845549431858647@ghanshyammann.com>
 <1746feef403.c41c848411058.2421030943223377212@ghanshyammann.com>
 <1747442027f.bb3f3d1823475.212800600164097649@ghanshyammann.com>
 <17476128313.f7b6001e28321.7088729119972703547@ghanshyammann.com>
 <CAKZ_x78soqu_Wq3n8c5KX0DHKqPBactUEo95eazVxb7sbZA-dQ@mail.gmail.com>
Message-ID: <17478445846.1153c6daf62908.4233237804379232164@ghanshyammann.com>

 ---- On Thu, 10 Sep 2020 02:18:02 -0500 Radosław Piliszek <radoslaw.piliszek at gmail.com> wrote ----
 > I've triaged this for Kolla and Kolla-Ansible too.
 > 
 > Bifrost is also affected (but it's on Storyboard).

Thanks yoctozepto for fixing these.

-gmann

 > 
 > -yoctozepto
 > 
 > On Thu, Sep 10, 2020 at 5:42 AM Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
 > >
 > > Updates:
 > >
 > > Fixed a few more projects today which I found failing on Focal:
 > >
 > > - OpenStack SDKs repos : ready to merge
 > > - All remaining Oslo lib fixes:  we are discussing FFE on these in separate ML thread.
 > > - Keystone: Fix is up, it should pass now.
 > > - Manila: Fix is up, it should pass gate.
 > > - Tacker: Ready to merge
 > > - neutron-dynamic-routing: Ready to merge
 > > - Cinder- it seems l-c job still failing. I will dig into it tomorrow or it will be appreciated if anyone can take a look before my morning.
 > > this is the patch -https://review.opendev.org/#/c/743080/
 > >
 > > Note: all tox based jobs (Except py36/3.7) are running on Focal now so If any of you gate failing, feel free to ping me on #openstack-qa
 > >
 > > No more energy left for today, I will continue the remaining work tomorrow.
 > >
 > > -gmann
 > >
 > >  ---- On Wed, 09 Sep 2020 14:05:17 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > >  >  ---- On Tue, 08 Sep 2020 17:56:05 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > >  >  > Updates:
 > >  >  > After working more on failing one today and listing the blocking one, I think we are good to switch tox based testing today
 > >  >  > and discuss the integration testing switch tomorrow in TC office hours.
 > >  >  >
 > >  >  > > * Part1: Migrating tox base job tomorrow (8th Sept):
 > >  >  >
 > >  >  > I have checked it again and fixed many repos that are up for review and merge. Most python clients are already fixed
 > >  >  > or their fixes are up for merge so they can make it before the feature freeze on 10th. If any repo is broken then it will be pretty quick
 > >  >  > to fix by lower constraint bump (see the example under https://review.opendev.org/#/q/topic:migrate-to-focal)
 > >  >  >
 > >  >  > Even if any of the fixes miss the victoria release then those can be backported easily. I am opening the tox base jobs migration to merge:
 > >  >  >  - All patches in this series https://review.opendev.org/#/c/738328/
 > >  >
 > >  > All these tox base jobs are merged now and running on Focal. If any of your repo is failing, please fix on priority or ping me on IRC if failure not clear.
 > >  > You can find most of the fixes for possible failure in this topic:
 > >  > - https://review.opendev.org/#/q/topic:migrate-to-focal+(status:open+OR+status:merged)
 > >  >
 > >  > -gmann
 > >  >
 > >  >
 > >  >  >
 > >  >  >
 > >  >  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
 > >  >  >
 > >  >  > We have three blocking open bugs here so I would like to discuss it in tomorrow's TC office hour also about how to proceed on this.
 > >  >  >
 > >  >  > 1. Nova: https://bugs.launchpad.net/nova/+bug/1882521  (https://bugs.launchpad.net/qemu/+bug/1894804)
 > >  >  > 2. Barbican: https://storyboard.openstack.org/#!/story/2007732
 > >  >  > 3. Ceilometer: https://storyboard.openstack.org/#!/story/2008121
 > >  >  >
 > >  >  >
 > >  >  > -gmann
 > >  >  >
 > >  >  >
 > >  >  >  ---- On Mon, 07 Sep 2020 09:29:40 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > >  >  >  > Hello Everyone,
 > >  >  >  >
 > >  >  >  > Please find the week R-4 updates on 'Ubuntu Focal migration' community goal. Its time to force the base jobs migration which can
 > >  >  >  > break the projects gate if not yet taken care of. Read below for the plan.
 > >  >  >  >
 > >  >  >  > Tracking: https://storyboard.openstack.org/#!/story/2007865
 > >  >  >  >
 > >  >  >  > Progress:
 > >  >  >  > =======
 > >  >  >  > * We are close to V-3 release and this is time we have to complete this migration otherwise doing it in RC period can add
 > >  >  >  > unnecessary and last min delay. I am going to plan this migration in two-part. This will surely break some projects gate
 > >  >  >  > which is not yet finished the migration but we have to do at some time. Please let me know if any objection to the below
 > >  >  >  > plan.
 > >  >  >  >
 > >  >  >  > * Part1: Migrating tox base job tomorrow (8th Sept):
 > >  >  >  >
 > >  >  >  > ** I am going to open tox base jobs migration (doc, unit, functional, lower-constraints etc) to merge by tomorrow. which is this
 > >  >  >  > series (all base patches of this):  https://review.opendev.org/#/c/738328/ .
 > >  >  >  >
 > >  >  >  > **There are few repos still failing on requirements lower-constraints job specifically which I tried my best to fix as many as possible.
 > >  >  >  >  Many are ready to merge also. Please merge or work on your projects repo testing before that or fix on priority if failing.
 > >  >  >  >
 > >  >  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
 > >  >  >  >
 > >  >  >  > * We have few open bugs for this which are not yet resolved, we will see how it goes but the current plan is to migrate by 10th Sept.
 > >  >  >  >
 > >  >  >  > ** Bug#1882521
 > >  >  >  > ** DB migration issues,
 > >  >  >  > *** alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003
 > >  >  >  >
 > >  >  >  >
 > >  >  >  > Testing Till now:
 > >  >  >  > ============
 > >  >  >  > * ~200 repos gate have been tested or fixed till now.
 > >  >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+(status:abandoned+OR+status:merged)
 > >  >  >  >
 > >  >  >  > * ~100 repos are under test and failing. Debugging and fixing are in progress (If you would like to help, please check your
 > >  >  >  > project repos if I am late to fix them):
 > >  >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open
 > >  >  >  >
 > >  >  >  > * ~30repos fixes ready to merge:
 > >  >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open+label%3AVerified%3E%3D1%2Czuul+NOT+label%3AWorkflow%3C%3D-1
 > >  >  >  >
 > >  >  >  >
 > >  >  >  > Bugs Report:
 > >  >  >  > ==========
 > >  >  >  >
 > >  >  >  > 1. Bug#1882521. (IN-PROGRESS)
 > >  >  >  > There is open bug for nova/cinder where three tempest tests are failing for
 > >  >  >  > volume detach operation. There is no clear root cause found yet
 > >  >  >  > -https://bugs.launchpad.net/cinder/+bug/1882521
 > >  >  >  > We have skipped the tests in tempest base patch to proceed with the other
 > >  >  >  > projects testing but this is blocking things for the migration.
 > >  >  >  >
 > >  >  >  > 2. DB migration issues (IN-PROGRESS)
 > >  >  >  > * alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003
 > >  >  >  >
 > >  >  >  > 3. We encountered the nodeset name conflict with x/tobiko. (FIXED)
 > >  >  >  > nodeset conflict is resolved now and devstack provides all focal nodes now.
 > >  >  >  >
 > >  >  >  > 4. Bug#1886296. (IN-PROGRESS)
 > >  >  >  > pyflakes till 2.1.0 is not compatible with python 3.8 which is the default python version
 > >  >  >  > on ubuntu focal[1]. With pep8 job running on focal faces the issue and fail. We need to bump
 > >  >  >  > the pyflakes to 2.1.1 as min version to run pep8 jobs on py3.8.
 > >  >  >  > As of now, many projects are using old hacking version so I am explicitly adding pyflakes>=2.1.1
 > >  >  >  > on the project side[2] but for the long term easy maintenance, I am doing it in 'hacking' requirements.txt[3]
 > >  >  >  > nd will release a new hacking version. After that project can move to new hacking and do not need
 > >  >  >  > to maintain pyflakes version compatibility.
 > >  >  >  >
 > >  >  >  > 5. Bug#1886298. (IN-PROGRESS)
 > >  >  >  > 'Markupsafe' 1.0 is not compatible with the latest version of setuptools[4],
 > >  >  >  > We need to bump the lower-constraint for Markupsafe to 1.1.1 to make it work.
 > >  >  >  > There are a few more issues[5] with lower-constraint jobs which I am debugging.
 > >  >  >  >
 > >  >  >  >
 > >  >  >  > What work to be done on the project side:
 > >  >  >  > ================================
 > >  >  >  > This goal is more of testing the jobs on focal and fixing bugs if any otherwise
 > >  >  >  > migrate jobs by switching the nodeset to focal node sets defined in devstack.
 > >  >  >  >
 > >  >  >  > 1. Start a patch in your repo by making depends-on on either of below:
 > >  >  >  > devstack base patch if you are using only devstack base jobs not tempest:
 > >  >  >  >
 > >  >  >  > Depends-on: https://review.opendev.org/#/c/731207/
 > >  >  >  > OR
 > >  >  >  > tempest base patch if you are using the tempest base job (like devstack-tempest):
 > >  >  >  > Depends-on: https://review.opendev.org/#/c/734700/
 > >  >  >  >
 > >  >  >  > Both have depends-on on the series where I am moving unit/functional/doc/cover/nodejs tox jobs to focal. So
 > >  >  >  > you can test the complete gate jobs(unit/functional/doc/integration) together.
 > >  >  >  > This and its base patches - https://review.opendev.org/#/c/738328/
 > >  >  >  >
 > >  >  >  > Example: https://review.opendev.org/#/c/738126/
 > >  >  >  >
 > >  >  >  > 2. If none of your project jobs override the nodeset then above patch will be
 > >  >  >  > testing patch(do not merge) otherwise change the nodeset to focal.
 > >  >  >  > Example: https://review.opendev.org/#/c/737370/
 > >  >  >  >
 > >  >  >  > 3. If the jobs are defined in branchless repo and override the nodeset then you need to override the branches
 > >  >  >  > variant to adjust the nodeset so that those jobs run on Focal on victoria onwards only. If no nodeset
 > >  >  >  > is overridden then devstack being branched and stable base job using bionic/xenial will take care of
 > >  >  >  > this.
 > >  >  >  > Example: https://review.opendev.org/#/c/744056/2
 > >  >  >  >
 > >  >  >  > 4. If no updates need you can abandon the testing patch (https://review.opendev.org/#/c/744341/). If it need
 > >  >  >  > updates then modify the same patch with proper commit msg, once it pass the gate then remove the Depends-On
 > >  >  >  > so that you can merge your patch before base jobs are switched to focal. This way we make sure no gate downtime in
 > >  >  >  > this migration.
 > >  >  >  > Example: https://review.opendev.org/#/c/744056/1..2//COMMIT_MSG
 > >  >  >  >
 > >  >  >  > Once we finish the testing on projects side and no failure then we will merge the devstack and tempest
 > >  >  >  > base patches.
 > >  >  >  >
 > >  >  >  >
 > >  >  >  > Important things to note:
 > >  >  >  > ===================
 > >  >  >  > * Do not forgot to add the story and task link to your patch so that we can track it smoothly.
 > >  >  >  > * Use gerrit topic 'migrate-to-focal'
 > >  >  >  > * Do not backport any of the patches.
 > >  >  >  >
 > >  >  >  >
 > >  >  >  > References:
 > >  >  >  > =========
 > >  >  >  > Goal doc: https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-jobs-to-ubuntu-focal.html
 > >  >  >  > Storyboard tracking: https://storyboard.openstack.org/#!/story/2007865
 > >  >  >  >
 > >  >  >  > [1] https://github.com/PyCQA/pyflakes/issues/367
 > >  >  >  > [2] https://review.opendev.org/#/c/739315/
 > >  >  >  > [3] https://review.opendev.org/#/c/739334/
 > >  >  >  > [4] https://github.com/pallets/markupsafe/issues/116
 > >  >  >  > [5] https://zuul.opendev.org/t/openstack/build/7ecd9cf100194bc99b3b70fa1e6de032
 > >  >  >  >
 > >  >  >  > -gmann
 > >  >  >  >
 > >  >  >  >
 > >  >  >
 > >  >  >
 > >  >
 > >  >
 > >
 > 
 > 


From elod.illes at est.tech  Thu Sep 10 13:59:24 2020
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Thu, 10 Sep 2020 15:59:24 +0200
Subject: [cinder][stable][infra] branch freeze for ocata, pike
In-Reply-To: <2013dd9e-386a-1190-8e5b-33338cc44d59@gmail.com>
References: <ed869983-18e0-b8b8-1c50-a697e990be72@gmail.com>
 <56e12f48-f2f8-0a26-1830-093c9fe9d9db@est.tech>
 <2013dd9e-386a-1190-8e5b-33338cc44d59@gmail.com>
Message-ID: <bcd64732-5d4b-8cf7-89c3-ec0ffe030652@est.tech>

On 2020. 09. 10. 15:30, Brian Rosmaita wrote:
> On 9/10/20 8:40 AM, Előd Illés wrote:
>> Hi Infra Team,
>>
>> While reviewing Andreas' patch [1], I have realized, that Cinder's 
>> stable/ocata and stable/pike branches were not deleted yet, however 
>> those branches were EOL'd already (see mail below).
>>
>> According to the process [2], since the EOL patches have merged 
>> already, if @Brian doesn't object, can you please delete
>>
>> - cinder stable/ocata
>> - cinder stable/pike
>
> I have no objection, but I haven't pushed the infra team about the 
> actual branch deletion because as far as I know, cinder is the first 
> project to actually request removal, and I suspect all sorts of stuff 
> will break.  I suggest we wait until at least after RC-time to give us 
> all one less thing to worry about.

Sound good to me, thanks Brian!


>
> As far as avoiding breakage goes, I put up two patches to devstack so 
> that it will check out the -eol tag of cinder/brick/cinderclient 
> instead of the stable branch, but I suspect these only scratch the 
> surface of what can be broken once the cinder project branches are 
> deleted.
>
> https://review.opendev.org/#/c/742953/
> https://review.opendev.org/#/c/742952/
>
> Sean suggested in an earlier thread on this topic [0] that instead of 
> deleting very old EM branches that some projects have EOL'd 
> project-by-project, we should just delete them wholesale across 
> openstack.  That makes a lot of sense to me.

Ocata is quite abandoned nowadays so that makes sense. However, Pike has 
been active in the past months [3] more or less, so mass-deletion is not 
an option for Pike, I think.

Thanks,

Előd

[3] https://review.opendev.org/#/q/branch:stable/pike+status:merged


>
> [0] 
> http://lists.openstack.org/pipermail/openstack-discuss/2020-May/015115.html
>
>
> cheers,
> brian
>
>>
>> Thanks in advance,
>>
>> Előd
>>
>> [1] https://review.opendev.org/#/c/750887/
>> [2] 
>> https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-life 
>>
>>
>>
>> On 2020. 07. 28. 16:23, Brian Rosmaita wrote:
>>> tl;dr - do not approve any backports to stable/ocata or stable/pike 
>>> in any Cinder project deliverable
>>>
>>> stable/ocata has been tagged with ocata-eol in cinder, os-brick, 
>>> python-cinderclient, and python-brick-cinderclient-ext.  Nothing 
>>> should be merged into stable/ocata in any of these repositories 
>>> during the interim period before the branches are deleted.
>>>
>>> stable/pike: the changes discussed in [0] have merged, and I've
>>> proposed the pike-eol tags [1].  Nothing should be merged into 
>>> stable/pike in any of our code repositories from now until the 
>>> branches are deleted.
>>>
>>> [0] 
>>> http://lists.openstack.org/pipermail/openstack-discuss/2020-July/016076.html 
>>>
>>> [1] https://review.opendev.org/#/c/742523/
>>>
>>
>



From akekane at redhat.com  Thu Sep 10 14:37:45 2020
From: akekane at redhat.com (Abhishek Kekane)
Date: Thu, 10 Sep 2020 20:07:45 +0530
Subject: [requirements][FFE] Cinder multiple stores support
In-Reply-To: <CALOt+SSwMyAHZNPMyqwJewid5+Y7E3LToiV1B2Tm4YOwohnLWw@mail.gmail.com>
References: <CAARK8KQE+wR3tjzYt0jiTRcaa71siOG6VZTUWnX=N7kM+dABHw@mail.gmail.com>
 <CALOt+SSwMyAHZNPMyqwJewid5+Y7E3LToiV1B2Tm4YOwohnLWw@mail.gmail.com>
Message-ID: <CALOt+SQ_VRmCicE_T49+kskCjsuMsgnxMQHk9MERyBtVQSm_Vg@mail.gmail.com>

Hi Team,

FFE is not needed as the failures were related to tests only and does not
impact actual functionality.

Thanks & Best Regards,

Abhishek Kekane


On Tue, Sep 8, 2020 at 8:53 PM Abhishek Kekane <akekane at redhat.com> wrote:

> Hi Team,
>
> The reason for failure is we are suppressing Deprecation warning into
> error in glance [1] and we are using those deprecated parameters in
> glance_store.
> This is the reason why it is only failing in functional tests [2] and not
> in actual scenarios.
>
> [1]
> https://opendev.org/openstack/glance/src/branch/master/glance/tests/unit/fixtures.py#L133-L136
> [2]https://review.opendev.org/#/c/750144/
>
> Thanks & Best Regards,
>
> Abhishek Kekane
>
>
> On Tue, Sep 8, 2020 at 8:48 PM Rajat Dhasmana <rdhasman at redhat.com> wrote:
>
>> Hi Team,
>>
>> Last week we released glance_store 2.3.0 which adds support for configuring cinder multiple stores as glance backend.
>> While adding functional tests in glance for the same [1], we have noticed that it is failing with some hard requirements from oslo side to use project_id instead of tenant and user_id instead of user.
>> It is really strange behavior as this failure occurs only in functional tests but works properly in the actual environment without any issue. The fix is proposed in glance_store [2] to resolve this issue.
>>
>> I would like to apply for FFE with this glance_store patch [2] to be approved and release a new version of glance_store 2.3.1.
>>
>> Kindly provide approval for the same.
>>
>> [1] https://review.opendev.org/#/c/750144/
>> [2] https://review.opendev.org/#/c/750131/
>>
>> Thanks and Regards,
>> Rajat Dhasmana
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200910/d022ba18/attachment.html>

From corvus at inaugust.com  Thu Sep 10 15:07:25 2020
From: corvus at inaugust.com (James E. Blair)
Date: Thu, 10 Sep 2020 08:07:25 -0700
Subject: Farewell Party for Monty
Message-ID: <878sdhy8k2.fsf@meyer.lemoncheese.net>

Hi,

Monty is starting a new gig and won't be spending as much time with us.

Since we all haven't seen each other in a while, let's have one more
beer[1] together and say farewell.

Join us for a virtual going-away party on meetpad tomorrow (Friday) at
21:00 UTC at this URL:

  https://meetpad.opendev.org/farewell-mordred

Stop by and chat for old time's sake.

-Jim

[1] Bring your own beer.


From rdhasman at redhat.com  Thu Sep 10 15:21:26 2020
From: rdhasman at redhat.com (Rajat Dhasmana)
Date: Thu, 10 Sep 2020 20:51:26 +0530
Subject: [gance_store][FFE] Cinder multiple stores support
In-Reply-To: <CALOt+SS+jBVV6zqHdB=eT=xN145yjDLYzS2MGCVWHQhGGBML3g@mail.gmail.com>
References: <CAARK8KS6imQqv=gG9AJmXJDQE0LXwi2+jHqoMFYXrRQRYyEHVQ@mail.gmail.com>
 <CALOt+SS+jBVV6zqHdB=eT=xN145yjDLYzS2MGCVWHQhGGBML3g@mail.gmail.com>
Message-ID: <CAARK8KQW0P90sJM379qQ1smVBZXxW7UBZZc-t3xaea93jb24Ow@mail.gmail.com>

Hi Glance Team,

The cinder multiple store feature has merged and the glance store
dependency is only on the functional tests so we don't need an FFE anymore.

Thanks and Regards
Rajat Dhasmana

On Mon, Sep 7, 2020 at 9:56 PM Abhishek Kekane <akekane at redhat.com> wrote:

> +1 from me, glance_store 2.3.0 contains the actual functionality and
> glance functionality patch [1] is also in good shape.
>
> [1] https://review.opendev.org/#/c/748039/11
>
> Thanks & Best Regards,
>
> Abhishek Kekane
>
>
> On Mon, Sep 7, 2020 at 9:40 PM Rajat Dhasmana <rdhasman at redhat.com> wrote:
>
>> Hi Team,
>>
>> Last week we released glance_store 2.3.0 which adds support for configuring cinder multiple stores as glance backend.
>> While adding functional tests in glance for the same [1], we have noticed that it is failing with some hard requirements from oslo side to use project_id instead of tenant and user_id instead of user.
>> It is really strange behavior as this failure occurs only in functional tests but works properly in the actual environment without any issue. The fix is proposed in glance_store [2] to resolve this issue.
>>
>> I would like to apply for FFE with this glance_store patch [2] to be approved and release a new version of glance_store 2.3.1.
>>
>> Kindly provide approval for the same.
>>
>> [1] https://review.opendev.org/#/c/750144/
>> [2] https://review.opendev.org/#/c/750131/
>>
>> Thanks and Regards,
>> Rajat Dhasmana
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200910/e27fe218/attachment-0001.html>

From fungi at yuggoth.org  Thu Sep 10 15:47:04 2020
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Thu, 10 Sep 2020 15:47:04 +0000
Subject: Is Storyboard really the future?
In-Reply-To: <CAKZ_x7_kN4PBRKfTPL0PNOyxqbkL3Di1MV9AFkYnaU75mzeD8Q@mail.gmail.com>
References: <CAKZ_x7_kN4PBRKfTPL0PNOyxqbkL3Di1MV9AFkYnaU75mzeD8Q@mail.gmail.com>
Message-ID: <20200910154704.3erw242ynqldlq63@yuggoth.org>

On 2020-09-10 13:10:44 +0200 (+0200), Radosław Piliszek wrote:
> The subject is the question I am posing. The general
> recommendation is to use Storyboard for new projects [1].

I agree that recommending a service without context is likely to
cause problems. StoryBoard is a service provided within OpenDev, and
I don't think we anticipate stopping to provide that service to
projects who wish to make use of it. Its use is not at all
mandatory. The deployment of it in OpenDev is at least minimally
functional and sufficient for light duty, though I understand people
who are in a situation of needing to interact with their defect and
task trackers constantly likely find some aspects of it frustrating.

> However, Storyboard does not seem to be receiving enough love
> recently [2] [3].

Yep, nobody works on it full-time and it could use some additional
developers, reviewers and sysadmins to help regain momentum. For
example, I could use some help figuring out fine-grained user
permissions for Rackspace's Swift-like object store, which is
currently blocking more effective vetting of the proposed
client-side support for Adam's story attachments work. We would also
love assistance getting the current Puppet module we're managing our
deployment with replaced by Ansible/docker-compose orchestration of
the container images we've started publishing to DockerHub. Even
just helping us triage and tag new stories for opendev/storyboard
and opendev/storyboard-webclient would be appreciated.

> It's generally deemed as slow [4]

Preliminary testing suggests https://review.opendev.org/742046 will
increase performance for the queries behind most common views by an
order of magnitude or more.

> and is missing quite a few usability enhancements [2]. Considering
> the alternative, and the actual previous recommendation, is
> Launchpad, I find it no-brainer to revert to recommending
> Launchpad still, even paving a way for projects wishing to escape
> the Storyboard nightmare. :-)

The smiley doesn't particularly soften the fact that you just rudely
referred to the product of someone's hard work and volunteered time
as a "nightmare."

One problem we were hoping to solve which Launchpad doesn't help us
with is that we have a number of potential contributors and users
who have balked at collaborating through OpenDev because our
services require them to have an "Ubuntu" login even though they're
not users of (and perhaps work for rivals/competitors of) that
distro. Once our Central Auth/SSO spec reaches implementation, being
able to offer some sort of cross-project task and defect tracking
integrated with our Gerrit code reviews, and using the same
authentication, gives projects who want to not require members of
their communities to have an UbuntuOne account that option.

> Don't get me wrong, I really like the Story/Task orientation but
> Storyboard results in a frustrating experience. In addition to
> being slow, it has issues with search/filter, sorting and
> pagination which make issue browsing an utter pain. I know
> Launchpad is not without issues but it's certainly a much better
> platform at the moment. And many projects are still there.

Again, I think Launchpad is a fine platform for some projects. It's
designed around bug tracking for packaging work targeting various
Ubuntu releases, but that doesn't mean it can't also be used
effectively for other sorts of activities (as evidenced by the many
software projects who do). They've recently improved their
development environment setup and build instructions too, so working
on a patch to fix something there isn't nearly as challenging as it
once was. If you use Launchpad and want to improve some aspect of
it, I wholeheartedly encourage you to try to collaborate with its
maintainers on that. And if projects want to move to (or back to)
Launchpad, I don't have a problem with that and am happy to get them
database exports of their SB stories and tasks... I think we can
just set the corresponding project entries to inactive so they can't
be selected for new tasks, though that will need a bit of testing to
confirm.

> The Launchpad-Storyboard split is also introducing confusion for
> users [5] and coordinability issues for teams as we need to
> cross-link manually to get proper visibility.

I'm not entirely convinced. Users are going to be confused and
sometimes open bugs in the wrong places regardless. Back when the
OpenStack Infra team existed and had a catch-all LP project for
tracking infrastructure-related issues and incidents, users often
got equally confused and opened Nova bugs under that. They also
still constantly wander into the #openstack-infra IRC channel asking
us how to run OpenStack. Turning off StoryBoard won't solve that.
Honestly, I doubt anything will (or even can) solve that. As for
cross-linking, you have to do that today if someone mistakenly opens
a Nova bug which turns out to be a Qemu or KVM issue instead. It's
unrealistic to expect all F/LOSS projects to use one common tracker.

> All in all, I ask you to consider recommending Launchpad again and
> encourage OpenStack projects to move to Launchpad.

I agree we shouldn't be recommending StoryBoard over other platforms
without providing some context as to when projects might consider
using it. I also won't attempt to dissuade anyone who wants to move
their tracking to other open source based services like (but not
necessarily limited to) Launchpad. Different projects have different
needs and no one work management tool is going to satisfy everyone.

> Extra note: I find it in a similar spot as ask.o.o - nice it has been
> tried, but unfortunately it did not stand the test of time.
> 
> [1] https://docs.opendev.org/opendev/infra-manual/latest/creators.html
> [2] https://storyboard.openstack.org/#!/project/opendev/storyboard
> [3] https://opendev.org/opendev/storyboard/commits/branch/master
> [4] https://storyboard.openstack.org/#!/story/2007829
> [5] https://storyboard.openstack.org/#!/story/2000890

I don't personally think it's quite the same situation as Ask
OpenStack, though I can see where you might draw parallels.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200910/a4c57162/attachment.sig>

From tonyliu0592 at hotmail.com  Thu Sep 10 16:42:01 2020
From: tonyliu0592 at hotmail.com (Tony Liu)
Date: Thu, 10 Sep 2020 16:42:01 +0000
Subject: [Keystone] 'list' object has no attribute 'get'
Message-ID: <MWHPR08MB2382D6FAC6391A4B3A61819BBD270@MWHPR08MB2382.namprd08.prod.outlook.com>

Is this known issue with openstack-keystone-17.0.0-1.el8.noarch?

2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context [req-3bcdd315-1975-4d8a-969d-166dd3e8a3b6 113ee63a9ed0466794e24d069efc302c 4c142a681d884010ab36a7ac687d910c - default default] 'list' object has no attribute 'get': AttributeError: 'list' object has no attribute 'get'
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context Traceback (most recent call last):
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py", line 103, in _inner
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     return method(self, request)
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py", line 353, in process_request
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     resp = super(AuthContextMiddleware, self).process_request(request)
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystonemiddleware/auth_token/__init__.py", line 411, in process_request
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     allow_expired=allow_expired)
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystonemiddleware/auth_token/__init__.py", line 445, in _do_fetch_token
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     data = self.fetch_token(token, **kwargs)
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py", line 248, in fetch_token
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     token, access_rules_support=ACCESS_RULES_MIN_VERSION)
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/common/manager.py", line 115, in wrapped
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     __ret_val = __f(*args, **kwargs)
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/token/provider.py", line 145, in validate_token
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     token = self._validate_token(token_id)
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "</usr/lib/python3.6/site-packages/decorator.py:decorator-gen-26>", line 2, in _validate_token
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/region.py", line 1360, in get_or_create_for_user_func
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     key, user_func, timeout, should_cache_fn, (arg, kw)
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/region.py", line 962, in get_or_create
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     async_creator,
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/lock.py", line 187, in __enter__
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     return self._enter()
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/lock.py", line 94, in _enter
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     generated = self._enter_create(value, createdtime)
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/lock.py", line 180, in _enter_create
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     return self.creator()
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/region.py", line 916, in gen_value
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     *creator_args[0], **creator_args[1]
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/token/provider.py", line 179, in _validate_token
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     token.mint(token_id, issued_at)
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/models/token_model.py", line 579, in mint
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     self._validate_token_resources()
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/models/token_model.py", line 471, in _validate_token_resources
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     if self.project and not self.project_domain.get('enabled'):
2020-09-10 09:35:53.638 28 ERROR keystone.server.flask.request_processing.middleware.auth_context AttributeError: 'list' object has no attribute 'get'


Thanks!
Tony



From radoslaw.piliszek at gmail.com  Thu Sep 10 16:45:20 2020
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Thu, 10 Sep 2020 18:45:20 +0200
Subject: Is Storyboard really the future?
In-Reply-To: <20200910154704.3erw242ynqldlq63@yuggoth.org>
References: <CAKZ_x7_kN4PBRKfTPL0PNOyxqbkL3Di1MV9AFkYnaU75mzeD8Q@mail.gmail.com>
 <20200910154704.3erw242ynqldlq63@yuggoth.org>
Message-ID: <CAKZ_x7-w41maMp=3YL2xKJFq66oSfrtZG1tvwPptgA8CxpeLGg@mail.gmail.com>

Hi Jeremy,

First of all, thank you for the writeup, it is really helpful and
contributes a lot to the discussion.

On Thu, Sep 10, 2020 at 5:59 PM Jeremy Stanley <fungi at yuggoth.org> wrote:
>
> On 2020-09-10 13:10:44 +0200 (+0200), Radosław Piliszek wrote:
> > The subject is the question I am posing. The general
> > recommendation is to use Storyboard for new projects [1].
>
> I agree that recommending a service without context is likely to
> cause problems. StoryBoard is a service provided within OpenDev, and
> I don't think we anticipate stopping to provide that service to
> projects who wish to make use of it. Its use is not at all
> mandatory. The deployment of it in OpenDev is at least minimally
> functional and sufficient for light duty, though I understand people
> who are in a situation of needing to interact with their defect and
> task trackers constantly likely find some aspects of it frustrating.
>
> > However, Storyboard does not seem to be receiving enough love
> > recently [2] [3].
>
> Yep, nobody works on it full-time and it could use some additional
> developers, reviewers and sysadmins to help regain momentum. For
> example, I could use some help figuring out fine-grained user
> permissions for Rackspace's Swift-like object store, which is
> currently blocking more effective vetting of the proposed
> client-side support for Adam's story attachments work. We would also
> love assistance getting the current Puppet module we're managing our
> deployment with replaced by Ansible/docker-compose orchestration of
> the container images we've started publishing to DockerHub. Even
> just helping us triage and tag new stories for opendev/storyboard
> and opendev/storyboard-webclient would be appreciated.

I feel you. I could not so far convince anyone to support me to work
on it, mostly because
Jira/GitHub/GitLab/Launchpad exists.
Not to mention many small internal projects are happy with just Trello. :-)
I feel this might be due to the audience Storyboard tries to cater to
(larger cross-project work)
which is not a common requirement (or rather just hard to organise for oneself).

> > It's generally deemed as slow [4]
>
> Preliminary testing suggests https://review.opendev.org/742046 will
> increase performance for the queries behind most common views by an
> order of magnitude or more.

That would be awesome.

> > and is missing quite a few usability enhancements [2]. Considering
> > the alternative, and the actual previous recommendation, is
> > Launchpad, I find it no-brainer to revert to recommending
> > Launchpad still, even paving a way for projects wishing to escape
> > the Storyboard nightmare. :-)
>
> The smiley doesn't particularly soften the fact that you just rudely
> referred to the product of someone's hard work and volunteered time
> as a "nightmare."

Ouch, you are right. I should have picked my words more responsibly.
I guess this was caused by one of longer sessions on Storyboard.
I sincerely apologise and hope nobody was offended.
As I wrote further below that line, I really appreciate Storyboard otherwise.
It's just that it does not really shine compared to <insert practically any
other competing issue tracking software here> these days.

> One problem we were hoping to solve which Launchpad doesn't help us
> with is that we have a number of potential contributors and users
> who have balked at collaborating through OpenDev because our
> services require them to have an "Ubuntu" login even though they're
> not users of (and perhaps work for rivals/competitors of) that
> distro. Once our Central Auth/SSO spec reaches implementation, being
> able to offer some sort of cross-project task and defect tracking
> integrated with our Gerrit code reviews, and using the same
> authentication, gives projects who want to not require members of
> their communities to have an UbuntuOne account that option.

I know this issue a bit. Hard to make everyone like each other.
As for Storyboard, since it still uses Ubuntu One for now, I could not obviously
see that as counting in favour of Storyboard. :-)

> > Don't get me wrong, I really like the Story/Task orientation but
> > Storyboard results in a frustrating experience. In addition to
> > being slow, it has issues with search/filter, sorting and
> > pagination which make issue browsing an utter pain. I know
> > Launchpad is not without issues but it's certainly a much better
> > platform at the moment. And many projects are still there.
>
> Again, I think Launchpad is a fine platform for some projects. It's
> designed around bug tracking for packaging work targeting various
> Ubuntu releases, but that doesn't mean it can't also be used
> effectively for other sorts of activities (as evidenced by the many
> software projects who do). They've recently improved their
> development environment setup and build instructions too, so working
> on a patch to fix something there isn't nearly as challenging as it
> once was. If you use Launchpad and want to improve some aspect of
> it, I wholeheartedly encourage you to try to collaborate with its
> maintainers on that. And if projects want to move to (or back to)
> Launchpad, I don't have a problem with that and am happy to get them
> database exports of their SB stories and tasks... I think we can
> just set the corresponding project entries to inactive so they can't
> be selected for new tasks, though that will need a bit of testing to
> confirm.
>
> > The Launchpad-Storyboard split is also introducing confusion for
> > users [5] and coordinability issues for teams as we need to
> > cross-link manually to get proper visibility.
>
> I'm not entirely convinced. Users are going to be confused and
> sometimes open bugs in the wrong places regardless. Back when the
> OpenStack Infra team existed and had a catch-all LP project for
> tracking infrastructure-related issues and incidents, users often
> got equally confused and opened Nova bugs under that. They also
> still constantly wander into the #openstack-infra IRC channel asking
> us how to run OpenStack. Turning off StoryBoard won't solve that.
> Honestly, I doubt anything will (or even can) solve that. As for
> cross-linking, you have to do that today if someone mistakenly opens
> a Nova bug which turns out to be a Qemu or KVM issue instead. It's
> unrealistic to expect all F/LOSS projects to use one common tracker.

You are right there that we can't necessarily solve this for everyone.
But at the moment it's confusing in that projects are partially there and
partially elsewhere *because of the recommendation*.
Obviously one can't do anything about escalation to libvirt/qemu/kernel
bugzillas but those are external projects.
For OpenStack projects we can have better guidelines.

> > All in all, I ask you to consider recommending Launchpad again and
> > encourage OpenStack projects to move to Launchpad.
>
> I agree we shouldn't be recommending StoryBoard over other platforms
> without providing some context as to when projects might consider
> using it. I also won't attempt to dissuade anyone who wants to move
> their tracking to other open source based services like (but not
> necessarily limited to) Launchpad. Different projects have different
> needs and no one work management tool is going to satisfy everyone.

I could not express it better.

> > Extra note: I find it in a similar spot as ask.o.o - nice it has been
> > tried, but unfortunately it did not stand the test of time.
> >
> > [1] https://docs.opendev.org/opendev/infra-manual/latest/creators.html
> > [2] https://storyboard.openstack.org/#!/project/opendev/storyboard
> > [3] https://opendev.org/opendev/storyboard/commits/branch/master
> > [4] https://storyboard.openstack.org/#!/story/2007829
> > [5] https://storyboard.openstack.org/#!/story/2000890
>
> I don't personally think it's quite the same situation as Ask
> OpenStack, though I can see where you might draw parallels.

I see how that could sound harsh as well.
I meant its confusing effect rather than the need to disable Storyboard
altogether and make it disappear, no.


All in all, I'd love to see Storyboard flourish as the approach appeals to me,
just the UX is far from ideal at the moment.
I meant this thread to be against the recommendation, not the software/instance
itself.
The recommendation introduced a feeling that Storyboard *should* be used,
Launchpad is not really mentioned any longer either.
To reiterate, I don't think it sounds like it *must* be used (and surely is not
a requirement) but *should* is enough to cause bad experience for both sides
(users trying to report and teams trying to keep track of reported issues).


> --
> Jeremy Stanley


From cohuck at redhat.com  Thu Sep 10 12:38:22 2020
From: cohuck at redhat.com (Cornelia Huck)
Date: Thu, 10 Sep 2020 14:38:22 +0200
Subject: device compatibility interface for live migration with assigned
 devices
In-Reply-To: <20200909021308.GA1277@joy-OptiPlex-7040>
References: <20200818113652.5d81a392.cohuck@redhat.com>
 <20200820003922.GE21172@joy-OptiPlex-7040>
 <20200819212234.223667b3@x1.home>
 <20200820031621.GA24997@joy-OptiPlex-7040>
 <20200825163925.1c19b0f0.cohuck@redhat.com>
 <20200826064117.GA22243@joy-OptiPlex-7040>
 <20200828154741.30cfc1a3.cohuck@redhat.com>
 <8f5345be73ebf4f8f7f51d6cdc9c2a0d8e0aa45e.camel@redhat.com>
 <20200831044344.GB13784@joy-OptiPlex-7040>
 <20200908164130.2fe0d106.cohuck@redhat.com>
 <20200909021308.GA1277@joy-OptiPlex-7040>
Message-ID: <20200910143822.2071eca4.cohuck@redhat.com>

On Wed, 9 Sep 2020 10:13:09 +0800
Yan Zhao <yan.y.zhao at intel.com> wrote:

> > > still, I'd like to put it more explicitly to make ensure it's not missed:
> > > the reason we want to specify compatible_type as a trait and check
> > > whether target compatible_type is the superset of source
> > > compatible_type is for the consideration of backward compatibility.
> > > e.g.
> > > an old generation device may have a mdev type xxx-v4-yyy, while a newer
> > > generation  device may be of mdev type xxx-v5-yyy.
> > > with the compatible_type traits, the old generation device is still
> > > able to be regarded as compatible to newer generation device even their
> > > mdev types are not equal.  
> > 
> > If you want to support migration from v4 to v5, can't the (presumably
> > newer) driver that supports v5 simply register the v4 type as well, so
> > that the mdev can be created as v4? (Just like QEMU versioned machine
> > types work.)  
> yes, it should work in some conditions.
> but it may not be that good in some cases when v5 and v4 in the name string
> of mdev type identify hardware generation (e.g. v4 for gen8, and v5 for
> gen9)
> 
> e.g.
> (1). when src mdev type is v4 and target mdev type is v5 as
> software does not support it initially, and v4 and v5 identify hardware
> differences.

My first hunch here is: Don't introduce types that may be compatible
later. Either make them compatible, or make them distinct by design,
and possibly add a different, compatible type later.

> then after software upgrade, v5 is now compatible to v4, should the
> software now downgrade mdev type from v5 to v4?
> not sure if moving hardware generation info into a separate attribute
> from mdev type name is better. e.g. remove v4, v5 in mdev type, while use
> compatible_pci_ids to identify compatibility.

If the generations are compatible, don't mention it in the mdev type.
If they aren't, use distinct types, so that management software doesn't
have to guess. At least that would be my naive approach here.

> 
> (2) name string of mdev type is composed by "driver_name + type_name".
> in some devices, e.g. qat, different generations of devices are binding to
> drivers of different names, e.g. "qat-v4", "qat-v5".
> then though type_name is equal, mdev type is not equal. e.g.
> "qat-v4-type1", "qat-v5-type1".

I guess that shows a shortcoming of that "driver_name + type_name"
approach? Or maybe I'm just confused.



From smooney at redhat.com  Thu Sep 10 12:50:11 2020
From: smooney at redhat.com (Sean Mooney)
Date: Thu, 10 Sep 2020 13:50:11 +0100
Subject: device compatibility interface for live migration with assigned
 devices
In-Reply-To: <20200910143822.2071eca4.cohuck@redhat.com>
References: <20200818113652.5d81a392.cohuck@redhat.com>
 <20200820003922.GE21172@joy-OptiPlex-7040>
 <20200819212234.223667b3@x1.home>
 <20200820031621.GA24997@joy-OptiPlex-7040>
 <20200825163925.1c19b0f0.cohuck@redhat.com>
 <20200826064117.GA22243@joy-OptiPlex-7040>
 <20200828154741.30cfc1a3.cohuck@redhat.com>
 <8f5345be73ebf4f8f7f51d6cdc9c2a0d8e0aa45e.camel@redhat.com>
 <20200831044344.GB13784@joy-OptiPlex-7040>
 <20200908164130.2fe0d106.cohuck@redhat.com>
 <20200909021308.GA1277@joy-OptiPlex-7040>
 <20200910143822.2071eca4.cohuck@redhat.com>
Message-ID: <7cebcb6c8d1a1452b43e8358ee6ee18a150a0238.camel@redhat.com>

On Thu, 2020-09-10 at 14:38 +0200, Cornelia Huck wrote:
> On Wed, 9 Sep 2020 10:13:09 +0800
> Yan Zhao <yan.y.zhao at intel.com> wrote:
> 
> > > > still, I'd like to put it more explicitly to make ensure it's not missed:
> > > > the reason we want to specify compatible_type as a trait and check
> > > > whether target compatible_type is the superset of source
> > > > compatible_type is for the consideration of backward compatibility.
> > > > e.g.
> > > > an old generation device may have a mdev type xxx-v4-yyy, while a newer
> > > > generation  device may be of mdev type xxx-v5-yyy.
> > > > with the compatible_type traits, the old generation device is still
> > > > able to be regarded as compatible to newer generation device even their
> > > > mdev types are not equal.  
> > > 
> > > If you want to support migration from v4 to v5, can't the (presumably
> > > newer) driver that supports v5 simply register the v4 type as well, so
> > > that the mdev can be created as v4? (Just like QEMU versioned machine
> > > types work.)  
> > 
> > yes, it should work in some conditions.
> > but it may not be that good in some cases when v5 and v4 in the name string
> > of mdev type identify hardware generation (e.g. v4 for gen8, and v5 for
> > gen9)
> > 
> > e.g.
> > (1). when src mdev type is v4 and target mdev type is v5 as
> > software does not support it initially, and v4 and v5 identify hardware
> > differences.
> 
> My first hunch here is: Don't introduce types that may be compatible
> later. Either make them compatible, or make them distinct by design,
> and possibly add a different, compatible type later.
> 
> > then after software upgrade, v5 is now compatible to v4, should the
> > software now downgrade mdev type from v5 to v4?
> > not sure if moving hardware generation info into a separate attribute
> > from mdev type name is better. e.g. remove v4, v5 in mdev type, while use
> > compatible_pci_ids to identify compatibility.
> 
> If the generations are compatible, don't mention it in the mdev type.
> If they aren't, use distinct types, so that management software doesn't
> have to guess. At least that would be my naive approach here.
yep that is what i would prefer to see too.
> 
> > 
> > (2) name string of mdev type is composed by "driver_name + type_name".
> > in some devices, e.g. qat, different generations of devices are binding to
> > drivers of different names, e.g. "qat-v4", "qat-v5".
> > then though type_name is equal, mdev type is not equal. e.g.
> > "qat-v4-type1", "qat-v5-type1".
> 
> I guess that shows a shortcoming of that "driver_name + type_name"
> approach? Or maybe I'm just confused.
yes i really dont like haveing the version in the mdev-type name 
i would stongly perfger just qat-type-1 wehere qat is just there as a way of namespacing.
although symmetric-cryto, asymmetric-cryto and compression woudl be a better name then type-1, type-2, type-3 if
that is what they would end up mapping too. e.g. qat-compression or qat-aes is a much better name then type-1
higher layers of software are unlikely to parse the mdev names but as a human looking at them its much eaiser to
understand if the names are meaningful. the qat prefix i think is important however to make sure that your mdev-types
dont colide with other vendeors mdev types. so i woudl encurage all vendors to prefix there mdev types with etiher the
device name or the vendor.
> 



From cboylan at sapwetik.org  Thu Sep 10 16:49:08 2020
From: cboylan at sapwetik.org (Clark Boylan)
Date: Thu, 10 Sep 2020 09:49:08 -0700
Subject: [cinder][stable] branch freeze for ocata, pike
In-Reply-To: <5af2fc9b-dfeb-f7cf-a491-fb4eab14f76f@suse.com>
References: <ed869983-18e0-b8b8-1c50-a697e990be72@gmail.com>
 <5af2fc9b-dfeb-f7cf-a491-fb4eab14f76f@suse.com>
Message-ID: <28b72a5a-e136-4233-854e-8eebbfd25933@www.fastmail.com>

On Thu, Sep 10, 2020, at 5:42 AM, Andreas Jaeger wrote:
> On 28.07.20 16:23, Brian Rosmaita wrote:
> > tl;dr - do not approve any backports to stable/ocata or stable/pike in
> > any Cinder project deliverable
> > 
> > stable/ocata has been tagged with ocata-eol in cinder, os-brick,
> > python-cinderclient, and python-brick-cinderclient-ext.  Nothing should
> > be merged into stable/ocata in any of these repositories during the
> > interim period before the branches are deleted.
> 
> When do you plan to delete those branches? We have Zuul jobs that are
> broken, for example due to removal of devstack-plugin-zmq and we either
> should remove these from the branch or delete the branch. Currently Zuul
> complains about broken jobs.
> 
> The two changes I talk about are:
> https://review.opendev.org/750887
> https://review.opendev.org/750886

I think we should go ahead and land those if we are waiting for a coordinated branch deletion. The zuul configs are branch specific and should be adjustable outside of normal backport procedures, particularly if they are causing problems like global zuul config errors. We've force merged some of these changes on stable branches in other projects if CI is generally unstable. Let us know if that is appropriate for this situation as well.

> 
> Andreas
> 
> > 
> > stable/pike: the changes discussed in [0] have merged, and I've
> > proposed the pike-eol tags [1].  Nothing should be merged into
> > stable/pike in any of our code repositories from now until the branches
> > are deleted.
> > 
> > [0]
> > http://lists.openstack.org/pipermail/openstack-discuss/2020-July/016076.html
> > 
> > [1] https://review.opendev.org/#/c/742523/
> > 


From tonyliu0592 at hotmail.com  Thu Sep 10 17:19:47 2020
From: tonyliu0592 at hotmail.com (Tony Liu)
Date: Thu, 10 Sep 2020 17:19:47 +0000
Subject: [Keystone] KeyError: 'domain_id'
Message-ID: <MWHPR08MB23823ED768DAD46D50EA771DBD270@MWHPR08MB2382.namprd08.prod.outlook.com>

Here is another exception. Any clues?

2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context [req-534d9855-8113-450d-8f9f-d93c0d961d24 113ee63a9ed0466794e24d069efc302c 4c142a681d884010ab36a7ac687d910c - default default] 'domain_id': KeyError: 'domain_id'
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context Traceback (most recent call last):
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py", line 103, in _inner
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     return method(self, request)
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py", line 353, in process_request
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     resp = super(AuthContextMiddleware, self).process_request(request)
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystonemiddleware/auth_token/__init__.py", line 411, in process_request
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     allow_expired=allow_expired)
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystonemiddleware/auth_token/__init__.py", line 445, in _do_fetch_token
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     data = self.fetch_token(token, **kwargs)
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py", line 248, in fetch_token
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     token, access_rules_support=ACCESS_RULES_MIN_VERSION)
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/common/manager.py", line 115, in wrapped
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     __ret_val = __f(*args, **kwargs)
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/token/provider.py", line 145, in validate_token
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     token = self._validate_token(token_id)
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "</usr/lib/python3.6/site-packages/decorator.py:decorator-gen-26>", line 2, in _validate_token
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/region.py", line 1360, in get_or_create_for_user_func
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     key, user_func, timeout, should_cache_fn, (arg, kw)
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/region.py", line 962, in get_or_create
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     async_creator,
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/lock.py", line 187, in __enter__
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     return self._enter()
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/lock.py", line 94, in _enter
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     generated = self._enter_create(value, createdtime)
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/lock.py", line 180, in _enter_create
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     return self.creator()
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/region.py", line 916, in gen_value
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     *creator_args[0], **creator_args[1]
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/token/provider.py", line 179, in _validate_token
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     token.mint(token_id, issued_at)
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/models/token_model.py", line 580, in mint
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     self._validate_token_user()
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/models/token_model.py", line 503, in _validate_token_user
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     if not self.user_domain.get('enabled'):
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/models/token_model.py", line 141, in user_domain
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     self.user['domain_id']
2020-09-10 10:16:45.050 28 ERROR keystone.server.flask.request_processing.middleware.auth_context KeyError: 'domain_id'


Thanks!
Tony



From tonyliu0592 at hotmail.com  Thu Sep 10 17:23:06 2020
From: tonyliu0592 at hotmail.com (Tony Liu)
Date: Thu, 10 Sep 2020 17:23:06 +0000
Subject: [Keystone] socket.timeout: timed out
Message-ID: <MWHPR08MB238261D23CE45D13DA3472ABBD270@MWHPR08MB2382.namprd08.prod.outlook.com>

Any clues on this timeout exception?

2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context [req-534d9855-8113-450d-8f9f-d93c0d961d24 113ee63a9ed0466794e24d069efc302c 4c142a681d884010ab36a7ac687d910c - default default] timed out: socket.timeout: timed out
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context Traceback (most recent call last):
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py", line 103, in _inner
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     return method(self, request)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py", line 353, in process_request
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     resp = super(AuthContextMiddleware, self).process_request(request)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystonemiddleware/auth_token/__init__.py", line 411, in process_request
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     allow_expired=allow_expired)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystonemiddleware/auth_token/__init__.py", line 445, in _do_fetch_token
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     data = self.fetch_token(token, **kwargs)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py", line 248, in fetch_token
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     token, access_rules_support=ACCESS_RULES_MIN_VERSION)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/common/manager.py", line 115, in wrapped
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     __ret_val = __f(*args, **kwargs)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/token/provider.py", line 145, in validate_token
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     token = self._validate_token(token_id)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "</usr/lib/python3.6/site-packages/decorator.py:decorator-gen-26>", line 2, in _validate_token
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/region.py", line 1360, in get_or_create_for_user_func
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     key, user_func, timeout, should_cache_fn, (arg, kw)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/region.py", line 962, in get_or_create
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     async_creator,  
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/lock.py", line 187, in __enter__
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     return self._enter()
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/lock.py", line 94, in _enter
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     generated = self._enter_create(value, createdtime)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/lock.py", line 180, in _enter_create
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     return self.creator()
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/region.py", line 916, in gen_value
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     *creator_args[0], **creator_args[1]
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/token/provider.py", line 179, in _validate_token
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     token.mint(token_id, issued_at)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/models/token_model.py", line 579, in mint
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     self._validate_token_resources()
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/models/token_model.py", line 471, in _validate_token_resources
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     if self.project and not self.project_domain.get('enabled'):
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/models/token_model.py", line 176, in project_domain
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     self.project['domain_id']
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/common/manager.py", line 115, in wrapped
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     __ret_val = __f(*args, **kwargs)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "</usr/lib/python3.6/site-packages/decorator.py:decorator-gen-27>", line 2, in get_domain
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/region.py", line 1360, in get_or_create_for_user_func
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     key, user_func, timeout, should_cache_fn, (arg, kw)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/region.py", line 962, in get_or_create
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     async_creator,  
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/lock.py", line 187, in __enter__
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     return self._enter()
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/lock.py", line 87, in _enter
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     value = value_fn()
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/region.py", line 902, in get_value
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     value = self.backend.get(key)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/common/cache/_context_cache.py", line 74, in get
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     value = self.proxied.get(key)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/backends/memcached.py", line 168, in get
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     value = self.client.get(key)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/oslo_cache/backends/memcache_pool.py", line 32, in _run_method
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     return getattr(client, __name)(*args, **kwargs)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/memcache.py", line 1129, in get
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     return self._get('get', key)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/memcache.py", line 1074, in _get
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     server, key = self._get_server(key)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/memcache.py", line 446, in _get_server
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     if server.connect():
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/memcache.py", line 1391, in connect
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     if self._get_socket():
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/memcache.py", line 1423, in _get_socket
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     self.flush()
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/memcache.py", line 1498, in flush
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     self.expect(b'OK')
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/memcache.py", line 1473, in expect
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     line = self.readline(raise_exception)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/memcache.py", line 1459, in readline
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     data = recv(4096)
2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context socket.timeout: timed out


Thanks!
Tony



From elod.illes at est.tech  Thu Sep 10 17:28:10 2020
From: elod.illes at est.tech (=?UTF-8?B?RWzFkWQgSWxsw6lz?=)
Date: Thu, 10 Sep 2020 19:28:10 +0200
Subject: [cinder][stable] branch freeze for ocata, pike
In-Reply-To: <28b72a5a-e136-4233-854e-8eebbfd25933@www.fastmail.com>
References: <ed869983-18e0-b8b8-1c50-a697e990be72@gmail.com>
 <5af2fc9b-dfeb-f7cf-a491-fb4eab14f76f@suse.com>
 <28b72a5a-e136-4233-854e-8eebbfd25933@www.fastmail.com>
Message-ID: <1ff00e0c-0819-710e-b984-c09e5861fba5@est.tech>

Just discussed with Clark and Fungi on IRC, that since the branches are 
already tagged (*-eol), merging the patches could cause some confusions. 
So it's easier to just wait until RC, as Brian suggested.

Thanks,

Előd


On 2020. 09. 10. 18:49, Clark Boylan wrote:
> On Thu, Sep 10, 2020, at 5:42 AM, Andreas Jaeger wrote:
>> On 28.07.20 16:23, Brian Rosmaita wrote:
>>> tl;dr - do not approve any backports to stable/ocata or stable/pike in
>>> any Cinder project deliverable
>>>
>>> stable/ocata has been tagged with ocata-eol in cinder, os-brick,
>>> python-cinderclient, and python-brick-cinderclient-ext.  Nothing should
>>> be merged into stable/ocata in any of these repositories during the
>>> interim period before the branches are deleted.
>> When do you plan to delete those branches? We have Zuul jobs that are
>> broken, for example due to removal of devstack-plugin-zmq and we either
>> should remove these from the branch or delete the branch. Currently Zuul
>> complains about broken jobs.
>>
>> The two changes I talk about are:
>> https://review.opendev.org/750887
>> https://review.opendev.org/750886
> I think we should go ahead and land those if we are waiting for a coordinated branch deletion. The zuul configs are branch specific and should be adjustable outside of normal backport procedures, particularly if they are causing problems like global zuul config errors. We've force merged some of these changes on stable branches in other projects if CI is generally unstable. Let us know if that is appropriate for this situation as well.
>
>> Andreas
>>
>>> stable/pike: the changes discussed in [0] have merged, and I've
>>> proposed the pike-eol tags [1].  Nothing should be merged into
>>> stable/pike in any of our code repositories from now until the branches
>>> are deleted.
>>>
>>> [0]
>>> http://lists.openstack.org/pipermail/openstack-discuss/2020-July/016076.html
>>>
>>> [1] https://review.opendev.org/#/c/742523/
>>>



From fungi at yuggoth.org  Thu Sep 10 17:55:27 2020
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Thu, 10 Sep 2020 17:55:27 +0000
Subject: Is Storyboard really the future?
In-Reply-To: <CAKZ_x7-w41maMp=3YL2xKJFq66oSfrtZG1tvwPptgA8CxpeLGg@mail.gmail.com>
References: <CAKZ_x7_kN4PBRKfTPL0PNOyxqbkL3Di1MV9AFkYnaU75mzeD8Q@mail.gmail.com>
 <20200910154704.3erw242ynqldlq63@yuggoth.org>
 <CAKZ_x7-w41maMp=3YL2xKJFq66oSfrtZG1tvwPptgA8CxpeLGg@mail.gmail.com>
Message-ID: <20200910175526.7phhyrdv3fw3trmf@yuggoth.org>

On 2020-09-10 18:45:20 +0200 (+0200), Radosław Piliszek wrote:
[...]
> You are right there that we can't necessarily solve this for
> everyone. But at the moment it's confusing in that projects are
> partially there and partially elsewhere *because of the
> recommendation*. Obviously one can't do anything about escalation
> to libvirt/qemu/kernel bugzillas but those are external projects.
> For OpenStack projects we can have better guidelines.

Also, while maybe not the perfect solution, the code browser at
https://opendev.org/openstack/nova has a prominent Issues link which
takes you directly to their https://bugs.launchpad.net/nova page
(for example).

[...]
> I meant this thread to be against the recommendation, not the
> software/instance itself. The recommendation introduced a feeling
> that Storyboard *should* be used, Launchpad is not really
> mentioned any longer either. To reiterate, I don't think it sounds
> like it *must* be used (and surely is not a requirement) but
> *should* is enough to cause bad experience for both sides (users
> trying to report and teams trying to keep track of reported
> issues).

Yes, perhaps part of the disconnect here is that StoryBoard is one
of the services provided by OpenDev so the OpenDev Manual is of
course going to describe how to make use of it. We do also provide
some Launchpad integration which warrants documenting, but as we
don't actually run Launchpad we aren't going to maintain extensive
documentation for the platform itself. On the other hand, the
OpenStack Contributor Guide, OpenStack Project Teams Guide, or
similar OpenStack-specific documentation certainly *can* document it
in much greater detail if that's useful to the OpenStack community
at large.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200910/521d244c/attachment-0001.sig>

From tonyliu0592 at hotmail.com  Thu Sep 10 18:06:46 2020
From: tonyliu0592 at hotmail.com (Tony Liu)
Date: Thu, 10 Sep 2020 18:06:46 +0000
Subject: [Keystone] TypeError: list indices must be integers or slices, not str
Message-ID: <MWHPR08MB2382C06B79CC6DB6C1B74B64BD270@MWHPR08MB2382.namprd08.prod.outlook.com>

Any clues to this error?

2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context Traceback (most recent call last):
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py", line 103, in _inner
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context     return method(self, request)
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py", line 353, in process_request
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context     resp = super(AuthContextMiddleware, self).process_request(request)
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystonemiddleware/auth_token/__init__.py", line 411, in process_request
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context     allow_expired=allow_expired)
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystonemiddleware/auth_token/__init__.py", line 445, in _do_fetch_token
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context     data = self.fetch_token(token, **kwargs)
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py", line 248, in fetch_token
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context     token, access_rules_support=ACCESS_RULES_MIN_VERSION)
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/common/manager.py", line 115, in wrapped
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context     __ret_val = __f(*args, **kwargs)
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/token/provider.py", line 146, in validate_token
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context     self._is_valid_token(token, window_seconds=window_seconds)
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/token/provider.py", line 199, in _is_valid_token
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context     self.check_revocation(token)
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/common/manager.py", line 115, in wrapped
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context     __ret_val = __f(*args, **kwargs)
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/token/provider.py", line 137, in check_revocation
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context     return self.check_revocation_v3(token)
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/common/manager.py", line 115, in wrapped
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context     __ret_val = __f(*args, **kwargs)
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/token/provider.py", line 133, in check_revocation_v3
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context     token_values = self.revoke_api.model.build_token_values(token)
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/models/revoke_model.py", line 245, in build_token_values
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context     if token.roles is not None:
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/models/token_model.py", line 458, in roles
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context     roles = self._get_project_roles()
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/models/token_model.py", line 423, in _get_project_roles
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context     roles.append({'id': r['id'], 'name': r['name']})
2020-09-10 11:03:44.913 30 ERROR keystone.server.flask.request_processing.middleware.auth_context TypeError: list indices must be integers or slices, not str


Thanks!
Tony



From skaplons at redhat.com  Thu Sep 10 19:34:13 2020
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Thu, 10 Sep 2020 21:34:13 +0200
Subject: [neutron] Drivers meeting 11.09.2020 cancelled
Message-ID: <20200910193413.rxfqazr3zfhr5bst@skaplons-mac>

Hi,

There is no any RFE for tomorrow drivers meeting so lets cancel it and focus on
review of the opened patches during that time.
See You all next week on the meetings.
Have a great weekend :)

-- 
Slawek Kaplonski
Principal software engineer
Red Hat



From mrunge at matthias-runge.de  Thu Sep 10 20:13:45 2020
From: mrunge at matthias-runge.de (Matthias Runge)
Date: Thu, 10 Sep 2020 22:13:45 +0200
Subject: [all][tc][goals] Migrate CI/CD jobs to new Ubuntu LTS Focal: Week
 R-4 Update
In-Reply-To: <17478418b45.c9cb264d62678.8113988885859095234@ghanshyammann.com>
References: <17468f8f785.1123a07e6307801.3844845549431858647@ghanshyammann.com>
 <1746feef403.c41c848411058.2421030943223377212@ghanshyammann.com>
 <1747442027f.bb3f3d1823475.212800600164097649@ghanshyammann.com>
 <17476128313.f7b6001e28321.7088729119972703547@ghanshyammann.com>
 <236b2c69-530a-2266-08e3-170b86c16a9d@gmail.com>
 <17478418b45.c9cb264d62678.8113988885859095234@ghanshyammann.com>
Message-ID: <67dc8bf5-ec1c-92c8-bc8e-e4aa3c855dfe@matthias-runge.de>

On 10/09/2020 15:43, Ghanshyam Mann wrote:
>  ---- On Thu, 10 Sep 2020 04:31:17 -0500 Yasufumi Ogawa <yasufum.o at gmail.com> wrote ----
>  > Hi gmann,
>  > 
>  > Sorry for that we've not merged your patch to Tacker because devstack on 
>  > Focal fails in functional test. It seems gnocchi installation on Focal 
>  > has some problems.
>  > 
>  > Anyway, although this issue isn't fixed yet, we'll proceed to merge the 
>  > patch immediately.
> 
> Thanks Yasufumi.
> 
> I reported the gnoochi issue in the below storyboard and tried to reach out to the ceilometer team
> also but found not get any response.  I will check what to do on this blocker.
> 
> https://storyboard.openstack.org/#!/story/2008121
> 
> 


So, how did you reach out, or who did you contact?

Since gnocchi is a separate project outside of OpenStack, you should
report these issues on https://github.com/gnocchixyz/gnocchi/issues.
Especially, one should use the usual way to report issues for a project.

Thank you for your patch for ceilometer, I did a review on it but did
not get an answer to my question.

Matthias

> -gmann
> 
>  > 
>  > Thanks,
>  > Yasufumi
>  > 
>  > On 2020/09/10 12:32, Ghanshyam Mann wrote:
>  > > Updates:
>  > > 
>  > > Fixed a few more projects today which I found failing on Focal:
>  > > 
>  > > - OpenStack SDKs repos : ready to merge
>  > > - All remaining Oslo lib fixes:  we are discussing FFE on these in separate ML thread.
>  > > - Keystone: Fix is up, it should pass now.
>  > > - Manila: Fix is up, it should pass gate.
>  > > - Tacker: Ready to merge
>  > > - neutron-dynamic-routing: Ready to merge
>  > > - Cinder- it seems l-c job still failing. I will dig into it tomorrow or it will be appreciated if anyone can take a look before my morning.
>  > > this is the patch -https://review.opendev.org/#/c/743080/
>  > > 
>  > > Note: all tox based jobs (Except py36/3.7) are running on Focal now so If any of you gate failing, feel free to ping me on #openstack-qa
>  > > 
>  > > No more energy left for today, I will continue the remaining work tomorrow.
>  > > 
>  > > -gmann
>  > > 
>  > >   ---- On Wed, 09 Sep 2020 14:05:17 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
>  > >   >  ---- On Tue, 08 Sep 2020 17:56:05 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
>  > >   >  > Updates:
>  > >   >  > After working more on failing one today and listing the blocking one, I think we are good to switch tox based testing today
>  > >   >  > and discuss the integration testing switch tomorrow in TC office hours.
>  > >   >  >
>  > >   >  > > * Part1: Migrating tox base job tomorrow (8th Sept):
>  > >   >  >
>  > >   >  > I have checked it again and fixed many repos that are up for review and merge. Most python clients are already fixed
>  > >   >  > or their fixes are up for merge so they can make it before the feature freeze on 10th. If any repo is broken then it will be pretty quick
>  > >   >  > to fix by lower constraint bump (see the example under https://review.opendev.org/#/q/topic:migrate-to-focal)
>  > >   >  >
>  > >   >  > Even if any of the fixes miss the victoria release then those can be backported easily. I am opening the tox base jobs migration to merge:
>  > >   >  >  - All patches in this series https://review.opendev.org/#/c/738328/
>  > >   >
>  > >   > All these tox base jobs are merged now and running on Focal. If any of your repo is failing, please fix on priority or ping me on IRC if failure not clear.
>  > >   > You can find most of the fixes for possible failure in this topic:
>  > >   > - https://review.opendev.org/#/q/topic:migrate-to-focal+(status:open+OR+status:merged)
>  > >   >
>  > >   > -gmann
>  > >   >
>  > >   >
>  > >   >  >
>  > >   >  >
>  > >   >  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
>  > >   >  >
>  > >   >  > We have three blocking open bugs here so I would like to discuss it in tomorrow's TC office hour also about how to proceed on this.
>  > >   >  >
>  > >   >  > 1. Nova: https://bugs.launchpad.net/nova/+bug/1882521  (https://bugs.launchpad.net/qemu/+bug/1894804)
>  > >   >  > 2. Barbican: https://storyboard.openstack.org/#!/story/2007732
>  > >   >  > 3. Ceilometer: https://storyboard.openstack.org/#!/story/2008121
>  > >   >  >
>  > >   >  >
>  > >   >  > -gmann
>  > >   >  >
>  > >   >  >
>  > >   >  >  ---- On Mon, 07 Sep 2020 09:29:40 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
>  > >   >  >  > Hello Everyone,
>  > >   >  >  >
>  > >   >  >  > Please find the week R-4 updates on 'Ubuntu Focal migration' community goal. Its time to force the base jobs migration which can
>  > >   >  >  > break the projects gate if not yet taken care of. Read below for the plan.
>  > >   >  >  >
>  > >   >  >  > Tracking: https://storyboard.openstack.org/#!/story/2007865
>  > >   >  >  >
>  > >   >  >  > Progress:
>  > >   >  >  > =======
>  > >   >  >  > * We are close to V-3 release and this is time we have to complete this migration otherwise doing it in RC period can add
>  > >   >  >  > unnecessary and last min delay. I am going to plan this migration in two-part. This will surely break some projects gate
>  > >   >  >  > which is not yet finished the migration but we have to do at some time. Please let me know if any objection to the below
>  > >   >  >  > plan.
>  > >   >  >  >
>  > >   >  >  > * Part1: Migrating tox base job tomorrow (8th Sept):
>  > >   >  >  >
>  > >   >  >  > ** I am going to open tox base jobs migration (doc, unit, functional, lower-constraints etc) to merge by tomorrow. which is this
>  > >   >  >  > series (all base patches of this):  https://review.opendev.org/#/c/738328/ .
>  > >   >  >  >
>  > >   >  >  > **There are few repos still failing on requirements lower-constraints job specifically which I tried my best to fix as many as possible.
>  > >   >  >  >  Many are ready to merge also. Please merge or work on your projects repo testing before that or fix on priority if failing.
>  > >   >  >  >
>  > >   >  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
>  > >   >  >  >
>  > >   >  >  > * We have few open bugs for this which are not yet resolved, we will see how it goes but the current plan is to migrate by 10th Sept.
>  > >   >  >  >
>  > >   >  >  > ** Bug#1882521
>  > >   >  >  > ** DB migration issues,
>  > >   >  >  > *** alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003
>  > >   >  >  >
>  > >   >  >  >
>  > >   >  >  > Testing Till now:
>  > >   >  >  > ============
>  > >   >  >  > * ~200 repos gate have been tested or fixed till now.
>  > >   >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+(status:abandoned+OR+status:merged)
>  > >   >  >  >
>  > >   >  >  > * ~100 repos are under test and failing. Debugging and fixing are in progress (If you would like to help, please check your
>  > >   >  >  > project repos if I am late to fix them):
>  > >   >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open
>  > >   >  >  >
>  > >   >  >  > * ~30repos fixes ready to merge:
>  > >   >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open+label%3AVerified%3E%3D1%2Czuul+NOT+label%3AWorkflow%3C%3D-1
>  > >   >  >  >
>  > >   >  >  >
>  > >   >  >  > Bugs Report:
>  > >   >  >  > ==========
>  > >   >  >  >
>  > >   >  >  > 1. Bug#1882521. (IN-PROGRESS)
>  > >   >  >  > There is open bug for nova/cinder where three tempest tests are failing for
>  > >   >  >  > volume detach operation. There is no clear root cause found yet
>  > >   >  >  > -https://bugs.launchpad.net/cinder/+bug/1882521
>  > >   >  >  > We have skipped the tests in tempest base patch to proceed with the other
>  > >   >  >  > projects testing but this is blocking things for the migration.
>  > >   >  >  >
>  > >   >  >  > 2. DB migration issues (IN-PROGRESS)
>  > >   >  >  > * alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003
>  > >   >  >  >
>  > >   >  >  > 3. We encountered the nodeset name conflict with x/tobiko. (FIXED)
>  > >   >  >  > nodeset conflict is resolved now and devstack provides all focal nodes now.
>  > >   >  >  >
>  > >   >  >  > 4. Bug#1886296. (IN-PROGRESS)
>  > >   >  >  > pyflakes till 2.1.0 is not compatible with python 3.8 which is the default python version
>  > >   >  >  > on ubuntu focal[1]. With pep8 job running on focal faces the issue and fail. We need to bump
>  > >   >  >  > the pyflakes to 2.1.1 as min version to run pep8 jobs on py3.8.
>  > >   >  >  > As of now, many projects are using old hacking version so I am explicitly adding pyflakes>=2.1.1
>  > >   >  >  > on the project side[2] but for the long term easy maintenance, I am doing it in 'hacking' requirements.txt[3]
>  > >   >  >  > nd will release a new hacking version. After that project can move to new hacking and do not need
>  > >   >  >  > to maintain pyflakes version compatibility.
>  > >   >  >  >
>  > >   >  >  > 5. Bug#1886298. (IN-PROGRESS)
>  > >   >  >  > 'Markupsafe' 1.0 is not compatible with the latest version of setuptools[4],
>  > >   >  >  > We need to bump the lower-constraint for Markupsafe to 1.1.1 to make it work.
>  > >   >  >  > There are a few more issues[5] with lower-constraint jobs which I am debugging.
>  > >   >  >  >
>  > >   >  >  >
>  > >   >  >  > What work to be done on the project side:
>  > >   >  >  > ================================
>  > >   >  >  > This goal is more of testing the jobs on focal and fixing bugs if any otherwise
>  > >   >  >  > migrate jobs by switching the nodeset to focal node sets defined in devstack.
>  > >   >  >  >
>  > >   >  >  > 1. Start a patch in your repo by making depends-on on either of below:
>  > >   >  >  > devstack base patch if you are using only devstack base jobs not tempest:
>  > >   >  >  >
>  > >   >  >  > Depends-on: https://review.opendev.org/#/c/731207/
>  > >   >  >  > OR
>  > >   >  >  > tempest base patch if you are using the tempest base job (like devstack-tempest):
>  > >   >  >  > Depends-on: https://review.opendev.org/#/c/734700/
>  > >   >  >  >
>  > >   >  >  > Both have depends-on on the series where I am moving unit/functional/doc/cover/nodejs tox jobs to focal. So
>  > >   >  >  > you can test the complete gate jobs(unit/functional/doc/integration) together.
>  > >   >  >  > This and its base patches - https://review.opendev.org/#/c/738328/
>  > >   >  >  >
>  > >   >  >  > Example: https://review.opendev.org/#/c/738126/
>  > >   >  >  >
>  > >   >  >  > 2. If none of your project jobs override the nodeset then above patch will be
>  > >   >  >  > testing patch(do not merge) otherwise change the nodeset to focal.
>  > >   >  >  > Example: https://review.opendev.org/#/c/737370/
>  > >   >  >  >
>  > >   >  >  > 3. If the jobs are defined in branchless repo and override the nodeset then you need to override the branches
>  > >   >  >  > variant to adjust the nodeset so that those jobs run on Focal on victoria onwards only. If no nodeset
>  > >   >  >  > is overridden then devstack being branched and stable base job using bionic/xenial will take care of
>  > >   >  >  > this.
>  > >   >  >  > Example: https://review.opendev.org/#/c/744056/2
>  > >   >  >  >
>  > >   >  >  > 4. If no updates need you can abandon the testing patch (https://review.opendev.org/#/c/744341/). If it need
>  > >   >  >  > updates then modify the same patch with proper commit msg, once it pass the gate then remove the Depends-On
>  > >   >  >  > so that you can merge your patch before base jobs are switched to focal. This way we make sure no gate downtime in
>  > >   >  >  > this migration.
>  > >   >  >  > Example: https://review.opendev.org/#/c/744056/1..2//COMMIT_MSG
>  > >   >  >  >
>  > >   >  >  > Once we finish the testing on projects side and no failure then we will merge the devstack and tempest
>  > >   >  >  > base patches.
>  > >   >  >  >
>  > >   >  >  >
>  > >   >  >  > Important things to note:
>  > >   >  >  > ===================
>  > >   >  >  > * Do not forgot to add the story and task link to your patch so that we can track it smoothly.
>  > >   >  >  > * Use gerrit topic 'migrate-to-focal'
>  > >   >  >  > * Do not backport any of the patches.
>  > >   >  >  >
>  > >   >  >  >
>  > >   >  >  > References:
>  > >   >  >  > =========
>  > >   >  >  > Goal doc: https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-jobs-to-ubuntu-focal.html
>  > >   >  >  > Storyboard tracking: https://storyboard.openstack.org/#!/story/2007865
>  > >   >  >  >
>  > >   >  >  > [1] https://github.com/PyCQA/pyflakes/issues/367
>  > >   >  >  > [2] https://review.opendev.org/#/c/739315/
>  > >   >  >  > [3] https://review.opendev.org/#/c/739334/
>  > >   >  >  > [4] https://github.com/pallets/markupsafe/issues/116
>  > >   >  >  > [5] https://zuul.opendev.org/t/openstack/build/7ecd9cf100194bc99b3b70fa1e6de032
>  > >   >  >  >
>  > >   >  >  > -gmann
>  > >   >  >  >
>  > >   >  >  >
>  > >   >  >
>  > >   >  >
>  > >   >
>  > >   >
>  > > 
>  > 
> 



From gmann at ghanshyammann.com  Thu Sep 10 23:05:21 2020
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Thu, 10 Sep 2020 18:05:21 -0500
Subject: [all][tc][goals] Migrate CI/CD jobs to new Ubuntu LTS Focal:
 Week R-4 Update
In-Reply-To: <67dc8bf5-ec1c-92c8-bc8e-e4aa3c855dfe@matthias-runge.de>
References: <17468f8f785.1123a07e6307801.3844845549431858647@ghanshyammann.com>
 <1746feef403.c41c848411058.2421030943223377212@ghanshyammann.com>
 <1747442027f.bb3f3d1823475.212800600164097649@ghanshyammann.com>
 <17476128313.f7b6001e28321.7088729119972703547@ghanshyammann.com>
 <236b2c69-530a-2266-08e3-170b86c16a9d@gmail.com>
 <17478418b45.c9cb264d62678.8113988885859095234@ghanshyammann.com>
 <67dc8bf5-ec1c-92c8-bc8e-e4aa3c855dfe@matthias-runge.de>
Message-ID: <1747a4427d1.b47bcff480039.5625062444763280406@ghanshyammann.com>

---- On Thu, 10 Sep 2020 15:13:45 -0500 Matthias Runge <mrunge at matthias-runge.de> wrote ----
 > On 10/09/2020 15:43, Ghanshyam Mann wrote:
 > >  ---- On Thu, 10 Sep 2020 04:31:17 -0500 Yasufumi Ogawa <yasufum.o at gmail.com> wrote ----
 > >  > Hi gmann,
 > >  > 
 > >  > Sorry for that we've not merged your patch to Tacker because devstack on 
 > >  > Focal fails in functional test. It seems gnocchi installation on Focal 
 > >  > has some problems.
 > >  > 
 > >  > Anyway, although this issue isn't fixed yet, we'll proceed to merge the 
 > >  > patch immediately.
 > > 
 > > Thanks Yasufumi.
 > > 
 > > I reported the gnoochi issue in the below storyboard and tried to reach out to the ceilometer team
 > > also but found not get any response.  I will check what to do on this blocker.
 > > 
 > > https://storyboard.openstack.org/#!/story/2008121
 > > 
 > > 
 > 
 > 
 > So, how did you reach out, or who did you contact?
 > 
 > Since gnocchi is a separate project outside of OpenStack, you should
 > report these issues on https://github.com/gnocchixyz/gnocchi/issues.
 > Especially, one should use the usual way to report issues for a project.
 > 
 > Thank you for your patch for ceilometer, I did a review on it but did
 > not get an answer to my question.

Hi Matthias, I posted about this on the telemetry IRC channel. I have reported it on gnoochi github also
- https://github.com/gnocchixyz/gnocchi/issues/1069

For the ceilometer patch, I updated it with lxml==4.2.3 which worked fine, hope it is ok now.

-gmann

 > 
 > Matthias
 > 
 > > -gmann
 > > 
 > >  > 
 > >  > Thanks,
 > >  > Yasufumi
 > >  > 
 > >  > On 2020/09/10 12:32, Ghanshyam Mann wrote:
 > >  > > Updates:
 > >  > > 
 > >  > > Fixed a few more projects today which I found failing on Focal:
 > >  > > 
 > >  > > - OpenStack SDKs repos : ready to merge
 > >  > > - All remaining Oslo lib fixes:  we are discussing FFE on these in separate ML thread.
 > >  > > - Keystone: Fix is up, it should pass now.
 > >  > > - Manila: Fix is up, it should pass gate.
 > >  > > - Tacker: Ready to merge
 > >  > > - neutron-dynamic-routing: Ready to merge
 > >  > > - Cinder- it seems l-c job still failing. I will dig into it tomorrow or it will be appreciated if anyone can take a look before my morning.
 > >  > > this is the patch -https://review.opendev.org/#/c/743080/
 > >  > > 
 > >  > > Note: all tox based jobs (Except py36/3.7) are running on Focal now so If any of you gate failing, feel free to ping me on #openstack-qa
 > >  > > 
 > >  > > No more energy left for today, I will continue the remaining work tomorrow.
 > >  > > 
 > >  > > -gmann
 > >  > > 
 > >  > >   ---- On Wed, 09 Sep 2020 14:05:17 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > >  > >   >  ---- On Tue, 08 Sep 2020 17:56:05 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > >  > >   >  > Updates:
 > >  > >   >  > After working more on failing one today and listing the blocking one, I think we are good to switch tox based testing today
 > >  > >   >  > and discuss the integration testing switch tomorrow in TC office hours.
 > >  > >   >  >
 > >  > >   >  > > * Part1: Migrating tox base job tomorrow (8th Sept):
 > >  > >   >  >
 > >  > >   >  > I have checked it again and fixed many repos that are up for review and merge. Most python clients are already fixed
 > >  > >   >  > or their fixes are up for merge so they can make it before the feature freeze on 10th. If any repo is broken then it will be pretty quick
 > >  > >   >  > to fix by lower constraint bump (see the example under https://review.opendev.org/#/q/topic:migrate-to-focal)
 > >  > >   >  >
 > >  > >   >  > Even if any of the fixes miss the victoria release then those can be backported easily. I am opening the tox base jobs migration to merge:
 > >  > >   >  >  - All patches in this series https://review.opendev.org/#/c/738328/
 > >  > >   >
 > >  > >   > All these tox base jobs are merged now and running on Focal. If any of your repo is failing, please fix on priority or ping me on IRC if failure not clear.
 > >  > >   > You can find most of the fixes for possible failure in this topic:
 > >  > >   > - https://review.opendev.org/#/q/topic:migrate-to-focal+(status:open+OR+status:merged)
 > >  > >   >
 > >  > >   > -gmann
 > >  > >   >
 > >  > >   >
 > >  > >   >  >
 > >  > >   >  >
 > >  > >   >  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
 > >  > >   >  >
 > >  > >   >  > We have three blocking open bugs here so I would like to discuss it in tomorrow's TC office hour also about how to proceed on this.
 > >  > >   >  >
 > >  > >   >  > 1. Nova: https://bugs.launchpad.net/nova/+bug/1882521  (https://bugs.launchpad.net/qemu/+bug/1894804)
 > >  > >   >  > 2. Barbican: https://storyboard.openstack.org/#!/story/2007732
 > >  > >   >  > 3. Ceilometer: https://storyboard.openstack.org/#!/story/2008121
 > >  > >   >  >
 > >  > >   >  >
 > >  > >   >  > -gmann
 > >  > >   >  >
 > >  > >   >  >
 > >  > >   >  >  ---- On Mon, 07 Sep 2020 09:29:40 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 > >  > >   >  >  > Hello Everyone,
 > >  > >   >  >  >
 > >  > >   >  >  > Please find the week R-4 updates on 'Ubuntu Focal migration' community goal. Its time to force the base jobs migration which can
 > >  > >   >  >  > break the projects gate if not yet taken care of. Read below for the plan.
 > >  > >   >  >  >
 > >  > >   >  >  > Tracking: https://storyboard.openstack.org/#!/story/2007865
 > >  > >   >  >  >
 > >  > >   >  >  > Progress:
 > >  > >   >  >  > =======
 > >  > >   >  >  > * We are close to V-3 release and this is time we have to complete this migration otherwise doing it in RC period can add
 > >  > >   >  >  > unnecessary and last min delay. I am going to plan this migration in two-part. This will surely break some projects gate
 > >  > >   >  >  > which is not yet finished the migration but we have to do at some time. Please let me know if any objection to the below
 > >  > >   >  >  > plan.
 > >  > >   >  >  >
 > >  > >   >  >  > * Part1: Migrating tox base job tomorrow (8th Sept):
 > >  > >   >  >  >
 > >  > >   >  >  > ** I am going to open tox base jobs migration (doc, unit, functional, lower-constraints etc) to merge by tomorrow. which is this
 > >  > >   >  >  > series (all base patches of this):  https://review.opendev.org/#/c/738328/ .
 > >  > >   >  >  >
 > >  > >   >  >  > **There are few repos still failing on requirements lower-constraints job specifically which I tried my best to fix as many as possible.
 > >  > >   >  >  >  Many are ready to merge also. Please merge or work on your projects repo testing before that or fix on priority if failing.
 > >  > >   >  >  >
 > >  > >   >  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
 > >  > >   >  >  >
 > >  > >   >  >  > * We have few open bugs for this which are not yet resolved, we will see how it goes but the current plan is to migrate by 10th Sept.
 > >  > >   >  >  >
 > >  > >   >  >  > ** Bug#1882521
 > >  > >   >  >  > ** DB migration issues,
 > >  > >   >  >  > *** alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003
 > >  > >   >  >  >
 > >  > >   >  >  >
 > >  > >   >  >  > Testing Till now:
 > >  > >   >  >  > ============
 > >  > >   >  >  > * ~200 repos gate have been tested or fixed till now.
 > >  > >   >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+(status:abandoned+OR+status:merged)
 > >  > >   >  >  >
 > >  > >   >  >  > * ~100 repos are under test and failing. Debugging and fixing are in progress (If you would like to help, please check your
 > >  > >   >  >  > project repos if I am late to fix them):
 > >  > >   >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open
 > >  > >   >  >  >
 > >  > >   >  >  > * ~30repos fixes ready to merge:
 > >  > >   >  >  > ** https://review.opendev.org/#/q/topic:migrate-to-focal+status:open+label%3AVerified%3E%3D1%2Czuul+NOT+label%3AWorkflow%3C%3D-1
 > >  > >   >  >  >
 > >  > >   >  >  >
 > >  > >   >  >  > Bugs Report:
 > >  > >   >  >  > ==========
 > >  > >   >  >  >
 > >  > >   >  >  > 1. Bug#1882521. (IN-PROGRESS)
 > >  > >   >  >  > There is open bug for nova/cinder where three tempest tests are failing for
 > >  > >   >  >  > volume detach operation. There is no clear root cause found yet
 > >  > >   >  >  > -https://bugs.launchpad.net/cinder/+bug/1882521
 > >  > >   >  >  > We have skipped the tests in tempest base patch to proceed with the other
 > >  > >   >  >  > projects testing but this is blocking things for the migration.
 > >  > >   >  >  >
 > >  > >   >  >  > 2. DB migration issues (IN-PROGRESS)
 > >  > >   >  >  > * alembic and few on telemetry/gnocchi side  https://github.com/sqlalchemy/alembic/issues/699, https://storyboard.openstack.org/#!/story/2008003
 > >  > >   >  >  >
 > >  > >   >  >  > 3. We encountered the nodeset name conflict with x/tobiko. (FIXED)
 > >  > >   >  >  > nodeset conflict is resolved now and devstack provides all focal nodes now.
 > >  > >   >  >  >
 > >  > >   >  >  > 4. Bug#1886296. (IN-PROGRESS)
 > >  > >   >  >  > pyflakes till 2.1.0 is not compatible with python 3.8 which is the default python version
 > >  > >   >  >  > on ubuntu focal[1]. With pep8 job running on focal faces the issue and fail. We need to bump
 > >  > >   >  >  > the pyflakes to 2.1.1 as min version to run pep8 jobs on py3.8.
 > >  > >   >  >  > As of now, many projects are using old hacking version so I am explicitly adding pyflakes>=2.1.1
 > >  > >   >  >  > on the project side[2] but for the long term easy maintenance, I am doing it in 'hacking' requirements.txt[3]
 > >  > >   >  >  > nd will release a new hacking version. After that project can move to new hacking and do not need
 > >  > >   >  >  > to maintain pyflakes version compatibility.
 > >  > >   >  >  >
 > >  > >   >  >  > 5. Bug#1886298. (IN-PROGRESS)
 > >  > >   >  >  > 'Markupsafe' 1.0 is not compatible with the latest version of setuptools[4],
 > >  > >   >  >  > We need to bump the lower-constraint for Markupsafe to 1.1.1 to make it work.
 > >  > >   >  >  > There are a few more issues[5] with lower-constraint jobs which I am debugging.
 > >  > >   >  >  >
 > >  > >   >  >  >
 > >  > >   >  >  > What work to be done on the project side:
 > >  > >   >  >  > ================================
 > >  > >   >  >  > This goal is more of testing the jobs on focal and fixing bugs if any otherwise
 > >  > >   >  >  > migrate jobs by switching the nodeset to focal node sets defined in devstack.
 > >  > >   >  >  >
 > >  > >   >  >  > 1. Start a patch in your repo by making depends-on on either of below:
 > >  > >   >  >  > devstack base patch if you are using only devstack base jobs not tempest:
 > >  > >   >  >  >
 > >  > >   >  >  > Depends-on: https://review.opendev.org/#/c/731207/
 > >  > >   >  >  > OR
 > >  > >   >  >  > tempest base patch if you are using the tempest base job (like devstack-tempest):
 > >  > >   >  >  > Depends-on: https://review.opendev.org/#/c/734700/
 > >  > >   >  >  >
 > >  > >   >  >  > Both have depends-on on the series where I am moving unit/functional/doc/cover/nodejs tox jobs to focal. So
 > >  > >   >  >  > you can test the complete gate jobs(unit/functional/doc/integration) together.
 > >  > >   >  >  > This and its base patches - https://review.opendev.org/#/c/738328/
 > >  > >   >  >  >
 > >  > >   >  >  > Example: https://review.opendev.org/#/c/738126/
 > >  > >   >  >  >
 > >  > >   >  >  > 2. If none of your project jobs override the nodeset then above patch will be
 > >  > >   >  >  > testing patch(do not merge) otherwise change the nodeset to focal.
 > >  > >   >  >  > Example: https://review.opendev.org/#/c/737370/
 > >  > >   >  >  >
 > >  > >   >  >  > 3. If the jobs are defined in branchless repo and override the nodeset then you need to override the branches
 > >  > >   >  >  > variant to adjust the nodeset so that those jobs run on Focal on victoria onwards only. If no nodeset
 > >  > >   >  >  > is overridden then devstack being branched and stable base job using bionic/xenial will take care of
 > >  > >   >  >  > this.
 > >  > >   >  >  > Example: https://review.opendev.org/#/c/744056/2
 > >  > >   >  >  >
 > >  > >   >  >  > 4. If no updates need you can abandon the testing patch (https://review.opendev.org/#/c/744341/). If it need
 > >  > >   >  >  > updates then modify the same patch with proper commit msg, once it pass the gate then remove the Depends-On
 > >  > >   >  >  > so that you can merge your patch before base jobs are switched to focal. This way we make sure no gate downtime in
 > >  > >   >  >  > this migration.
 > >  > >   >  >  > Example: https://review.opendev.org/#/c/744056/1..2//COMMIT_MSG
 > >  > >   >  >  >
 > >  > >   >  >  > Once we finish the testing on projects side and no failure then we will merge the devstack and tempest
 > >  > >   >  >  > base patches.
 > >  > >   >  >  >
 > >  > >   >  >  >
 > >  > >   >  >  > Important things to note:
 > >  > >   >  >  > ===================
 > >  > >   >  >  > * Do not forgot to add the story and task link to your patch so that we can track it smoothly.
 > >  > >   >  >  > * Use gerrit topic 'migrate-to-focal'
 > >  > >   >  >  > * Do not backport any of the patches.
 > >  > >   >  >  >
 > >  > >   >  >  >
 > >  > >   >  >  > References:
 > >  > >   >  >  > =========
 > >  > >   >  >  > Goal doc: https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-jobs-to-ubuntu-focal.html
 > >  > >   >  >  > Storyboard tracking: https://storyboard.openstack.org/#!/story/2007865
 > >  > >   >  >  >
 > >  > >   >  >  > [1] https://github.com/PyCQA/pyflakes/issues/367
 > >  > >   >  >  > [2] https://review.opendev.org/#/c/739315/
 > >  > >   >  >  > [3] https://review.opendev.org/#/c/739334/
 > >  > >   >  >  > [4] https://github.com/pallets/markupsafe/issues/116
 > >  > >   >  >  > [5] https://zuul.opendev.org/t/openstack/build/7ecd9cf100194bc99b3b70fa1e6de032
 > >  > >   >  >  >
 > >  > >   >  >  > -gmann
 > >  > >   >  >  >
 > >  > >   >  >  >
 > >  > >   >  >
 > >  > >   >  >
 > >  > >   >
 > >  > >   >
 > >  > > 
 > >  > 
 > > 
 > 
 > 
 > 


From laurentfdumont at gmail.com  Fri Sep 11 00:19:57 2020
From: laurentfdumont at gmail.com (Laurent Dumont)
Date: Thu, 10 Sep 2020 20:19:57 -0400
Subject: [neutron] Flow drop on agent restart with openvswitch firewall
 driver
In-Reply-To: <DM6PR17MB361085CE869B739505B1C5EDF2260@DM6PR17MB3610.namprd17.prod.outlook.com>
References: <DM6PR17MB36108DF4942A4B8C72675D73F2290@DM6PR17MB3610.namprd17.prod.outlook.com>
 <20200909075042.qyxbnq7li2zm5oo4@skaplons-mac>
 <DM6PR17MB361085CE869B739505B1C5EDF2260@DM6PR17MB3610.namprd17.prod.outlook.com>
Message-ID: <CAOAKi8yCGQGpi3TJxa+WR3yNDzJ+cEejGYV26XozT1MPFrfOuw@mail.gmail.com>

I'll see if I can reproduce this as well. We are running OVS as well in a
RH env.

(it would be nice to know because we are also restarting the agent
sometimes :pray:)

On Wed, Sep 9, 2020 at 3:39 PM Alexis Deberg <alexis.deberg at ubisoft.com>
wrote:

> Sure, opened https://bugs.launchpad.net/neutron/+bug/1895038 with all the
> details I got at hand.
> As I said in the bug report, I'll try to reproduce with a up to date
> devstack asap.
>
> Thanks
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200910/3520a724/attachment.html>

From rosmaita.fossdev at gmail.com  Fri Sep 11 01:51:42 2020
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Thu, 10 Sep 2020 21:51:42 -0400
Subject: [cinder] propose Lucio Seki for cinder core
Message-ID: <2f42f092-5037-5f9d-48d6-cc52097f2479@gmail.com>

Lucio Seki (lseki on IRC) has been very active this cycle doing reviews, 
answering questions in IRC, and participating in the Cinder weekly 
meetings and at the midcycles.  He's been particularly thorough and 
helpful in his reviews of backend drivers, and has also been helpful in 
giving pointers to new driver maintainers who are setting up third party 
CI for their drivers.  Having Lucio as a core reviewer will help improve 
the team's review bandwidth without sacrificing review quality.

In the absence of objections, I'll add Lucio to the core team just 
before the next Cinder team meeting (Wednesday, 16 September at 1400 UTC 
in #openstack-meeting-alt).  Please communicate any concerns to me 
before that time.

cheers,
brian


From sorrison at gmail.com  Fri Sep 11 03:15:51 2020
From: sorrison at gmail.com (Sam Morrison)
Date: Fri, 11 Sep 2020 13:15:51 +1000
Subject: [neutron][networking-midonet] Maintainers needed
In-Reply-To: <2AB30A6D-9B6C-4D18-8FAB-C1022965657A@gmail.com>
References: <0AC5AC07-E97E-43CC-B344-A3E992B8CCA4@netways.de>
 <610412AF-AADF-44BD-ABA2-BA289B7C8F8A@redhat.com>
 <5E2F5826-559E-42E9-84C5-FA708E5A122A@gmail.com>
 <CAH=wFzS6usQqLeUtZ3iwyzw5f+ph38eaHCEQ0xsKo2ZzMREBgA@mail.gmail.com>
 <43C4AF2B-C5C0-40EB-B621-AC6799471D01@gmail.com>
 <CAH=wFzRmjbCy5vQOrpu=rX4Be-_GYPOE602kDShvV-ZtX+eF6g@mail.gmail.com>
 <92959221-0353-4D48-8726-8FE71AFEA652@gmail.com>
 <4D778DBF-F505-462F-B85D-0B372085FA72@gmail.com>
 <CAH=wFzRiJd=93cYsK5FJxJcmMb6eY-XDco1zQOfueMw-0s2Tcw@mail.gmail.com>
 <AB1C90C1-96EE-4D1B-AA3B-63A565A41B61@gmail.com>
 <5B9D2CB0-8B81-4533-A072-9A51B4A44364@gmail.com>
 <CALg0jKksi08Tq-H7xXGiNXqO3W9rtioERr9y7mN_us24GN+mBQ@mail.gmail.com>
 <C4587E9A-5E13-4AB5-801E-129BB470F73C@gmail.com>
 <CALg0jK=qEWFSwA5T-+fKwKsamqTK_mqhUW+ZY6fqCxk5xm0m0A@mail.gmail.com>
 <17472f764b8.1292d333d6181.3892285235847293323@ghanshyammann.com>
 <2AB30A6D-9B6C-4D18-8FAB-C1022965657A@gmail.com>
Message-ID: <7E82CBA5-8352-4C16-B726-1ADCAA925163@gmail.com>

Made some more progress, got single and multinode working on bionic.

I’ve added a centos8 which is failing because it can’t find yum or yum_install to install the packages, needs more investigation. Will have a look into that next week.
The grenade job also won’t work until these changes get merged and back ported to ussuri I think.
I made these 2 jobs non-voting for now.

So now the only thing preventing the lucrative green +1 is the pep8 job which is failing because of neutron :-( 

So I think https://review.opendev.org/#/c/749857/ is now ready for review.

Thanks,
Sam



> On 10 Sep 2020, at 10:58 am, Sam Morrison <sorrison at gmail.com> wrote:
> 
> OK thanks for the fix for TaaS, https://review.opendev.org/#/c/750633/4 should be good to be merged (even though its failing)
> 
> Also https://review.opendev.org/#/c/749641/3 should be good to go. This will get all the unit tests working. 
> 
> The pep8 tests are broken due to the pecan 1.4.0 issue being discussed at https://review.opendev.org/#/c/747419/
> 
> My zuul v3 aio tempest devstack job is working well now, still having some issues with the multinode one which I’m working on now.
> 
> Sam
> 
> 
> 
>> On 9 Sep 2020, at 11:04 pm, Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
>> 
>> Also we need to merge the networking-l2gw project new location fix
>> 
>> - https://review.opendev.org/#/c/738046/
>> 
>> It's leading to many errors as pointed by AJaeger  - https://zuul.opendev.org/t/openstack/config-errors
>> 
>> 
>> -gmann
>> 
>> ---- On Wed, 09 Sep 2020 07:18:37 -0500 Lajos Katona <katonalala at gmail.com> wrote ----
>>> Hi,I pushed a fix for it https://review.opendev.org/750633, I added Deepak for reviewer as he is the owner of the taas patch.
>>> Sorry for the problem.Lajos (lajoskatona)
>>> Sam Morrison <sorrison at gmail.com> ezt írta (időpont: 2020. szept. 9., Sze, 12:49):
>>> 
>>> 
>>> On 9 Sep 2020, at 4:52 pm, Lajos Katona <katonalala at gmail.com> wrote:
>>> Hi,Could you please  point to the issue with taas?
>>> Networking-midonet unit tests [1] are failing with the addition of this patch [2]
>>> [1] https://b1a2669063d97482275a-410cecb8410320c66fb802e0a530979a.ssl.cf5.rackcdn.com/749857/18/check/openstack-tox-py36/0344651/testr_results.html[2] https://opendev.org/x/tap-as-a-service/commit/8332a396b1b046eb370c0cb377d836d0c6b6d6ca
>>> I’m not really familiar with all of this so not sure how to fix these up.
>>> Cheers,Sam
>>> 
>>> 
>>> 
>>> RegardsLajos (lajoskatona)
>>> Sam Morrison <sorrison at gmail.com> ezt írta (időpont: 2020. szept. 9., Sze, 0:44):
>>> 
>>> 
>>> On 8 Sep 2020, at 3:13 pm, Sam Morrison <sorrison at gmail.com> wrote:
>>> Hi Yamamoto,
>>> 
>>> On 4 Sep 2020, at 6:47 pm, Takashi Yamamoto <yamamoto at midokura.com> wrote:
>>> i'm talking to our infra folks but it might take longer than i hoped.
>>> if you or someone else can provide a public repo, it might be faster.
>>> (i have looked at launchpad PPA while ago. but it didn't seem
>>> straightforward given the complex build machinary in midonet.)
>>> 
>>> Yeah that’s no problem, I’ve set up a repo with the latest midonet debs in it and happy to use that for the time being.
>>> 
>>> 
>>> I’m not sure why the pep8 job is failing, it is complaining about pecan which makes me think this is an issue with neutron itself? Kinda stuck on this one, it’s probably something silly.
>>> 
>>> probably.
>>> 
>>> Yeah this looks like a neutron or neutron-lib issue
>>> 
>>> 
>>> For the py3 unit tests they are now failing due to db migration errors in tap-as-a-service, l2-gateway and vpnaas issues I think caused by neutron getting rid of the liberty alembic branch and so we need to squash these on these projects too.
>>> 
>>> this thing? https://review.opendev.org/#/c/749866/
>>> 
>>> Yeah that fixed that issue.
>>> 
>>> I have been working to get everything fixed in this review [1]
>>> The pep8 job is working but not in the gate due to neutron issues [2]The py36/py38 jobs have 2 tests failing both relating to tap-as-a-service which I don’t really have any idea about, never used it. [3]
>>> These are failing because of this patch on tap-as-a-service https://opendev.org/x/tap-as-a-service/commit/8332a396b1b046eb370c0cb377d836d0c6b6d6ca
>>> Really have no idea how this works, does anyone use tap-as-a-service with midonet and can help me fix it, else I’m wondering if we disable tests for taas and make it an unsupported feature for now.
>>> Sam
>>> 
>>> 
>>> The tempest aio job is working well now, I’m not sure what tempest tests were run before but it’s just doing what ever is the default at the moment.The tempest multinode job isn’t working due to what I think is networking issues between the 2 nodes. I don’t really know what I’m doing here so any pointers would be helpful. [4]The grenade job is also failing because I also need to put these fixes on the stable/ussuri branch to make it work so will need to figure that out too
>>> Cheers,Sam
>>> [1] https://review.opendev.org/#/c/749857/[2] https://zuul.opendev.org/t/openstack/build/e94e873cbf0443c0a7f25ffe76b3b00b[3] https://b1a2669063d97482275a-410cecb8410320c66fb802e0a530979a.ssl.cf5.rackcdn.com/749857/18/check/openstack-tox-py36/0344651/testr_results.html[4] https://zuul.opendev.org/t/openstack/build/61f6dd3dc3d74a81b7a3f5968b4d8c72
>>> 
>>> 
>>> 
>>> 
>>> 
>>> I can now start to look into the devstack zuul jobs.
>>> 
>>> Cheers,
>>> Sam
>>> 
>>> 
>>> [1] https://github.com/NeCTAR-RC/networking-midonet/commits/devstack
>>> [2] https://github.com/midonet/midonet/pull/9
>>> 
>>> 
>>> 
>>> 
>>> On 1 Sep 2020, at 4:03 pm, Sam Morrison <sorrison at gmail.com> wrote:
>>> 
>>> 
>>> 
>>> On 1 Sep 2020, at 2:59 pm, Takashi Yamamoto <yamamoto at midokura.com> wrote:
>>> 
>>> hi,
>>> 
>>> On Tue, Sep 1, 2020 at 1:39 PM Sam Morrison <sorrison at gmail.com> wrote:
>>> 
>>> 
>>> 
>>> On 1 Sep 2020, at 11:49 am, Takashi Yamamoto <yamamoto at midokura.com> wrote:
>>> 
>>> Sebastian, Sam,
>>> 
>>> thank you for speaking up.
>>> 
>>> as Slawek said, the first (and probably the biggest) thing is to fix the ci.
>>> the major part for it is to make midonet itself to run on ubuntu
>>> version used by the ci. (18.04, or maybe directly to 20.04)
>>> https://midonet.atlassian.net/browse/MNA-1344
>>> iirc, the remaining blockers are:
>>> * libreswan (used by vpnaas)
>>> * vpp (used by fip64)
>>> maybe it's the easiest to drop those features along with their
>>> required components, if it's acceptable for your use cases.
>>> 
>>> We are running midonet-cluster and midolman on 18.04, we dropped those package dependencies from our ubuntu package to get it working.
>>> 
>>> We currently have built our own and host in our internal repo but happy to help putting this upstream somehow. Can we upload them to the midonet apt repo, does it still exist?
>>> 
>>> it still exists. but i don't think it's maintained well.
>>> let me find and ask someone in midokura who "owns" that part of infra.
>>> 
>>> does it also involve some package-related modifications to midonet repo, right?
>>> 
>>> 
>>> Yes a couple, I will send up as as pull requests to https://github.com/midonet/midonet today or tomorrow
>>> 
>>> Sam
>>> 
>>> 
>>> 
>>> 
>>> 
>>> I’m keen to do the work but might need a bit of guidance to get started,
>>> 
>>> Sam
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> alternatively you might want to make midonet run in a container. (so
>>> that you can run it with older ubuntu, or even a container trimmed for
>>> JVM)
>>> there were a few attempts to containerize midonet.
>>> i think this is the latest one: https://github.com/midonet/midonet-docker
>>> 
>>> On Fri, Aug 28, 2020 at 7:10 AM Sam Morrison <sorrison at gmail.com> wrote:
>>> 
>>> We (Nectar Research Cloud) use midonet heavily too, it works really well and we haven’t found another driver that works for us. We tried OVN but it just doesn’t scale to the size of environment we have.
>>> 
>>> I’m happy to help too.
>>> 
>>> Cheers,
>>> Sam
>>> 
>>> 
>>> 
>>> On 31 Jul 2020, at 2:06 am, Slawek Kaplonski <skaplons at redhat.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Thx Sebastian for stepping in to maintain the project. That is great news.
>>> I think that at the beginning You should do 2 things:
>>> - sync with Takashi Yamamoto (I added him to the loop) as he is probably most active current maintainer of this project,
>>> - focus on fixing networking-midonet ci which is currently broken - all scenario jobs aren’t working fine on Ubuntu 18.04 (and we are going to move to 20.04 in this cycle), migrate jobs to zuulv3 from the legacy ones and finally add them to the ci again,
>>> 
>>> I can of course help You with ci jobs if You need any help. Feel free to ping me on IRC or email (can be off the list).
>>> 
>>> On 29 Jul 2020, at 15:24, Sebastian Saemann <Sebastian.Saemann at netways.de> wrote:
>>> 
>>> Hi Slawek,
>>> 
>>> we at NETWAYS are running most of our neutron networking on top of midonet and wouldn't be too happy if it gets deprecated and removed. So we would like to take over the maintainer role for this part.
>>> 
>>> Please let me know how to proceed and how we can be onboarded easily.
>>> 
>>> Best regards,
>>> 
>>> Sebastian
>>> 
>>> --
>>> Sebastian Saemann
>>> Head of Managed Services
>>> 
>>> NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg
>>> Tel: +49 911 92885-0 | Fax: +49 911 92885-77
>>> CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB25207
>>> https://netways.de | sebastian.saemann at netways.de
>>> 
>>> ** NETWAYS Web Services - https://nws.netways.de **
>>> 
>>> —
>>> Slawek Kaplonski
>>> Principal software engineer
>>> Red Hat
>>> 
>>> 
>>> 
>>> 
>>> 
> 



From tonyliu0592 at hotmail.com  Fri Sep 11 03:49:09 2020
From: tonyliu0592 at hotmail.com (Tony Liu)
Date: Fri, 11 Sep 2020 03:49:09 +0000
Subject: [Neutron] number of subnets in a network
Message-ID: <MWHPR08MB2382B217FA3BA97A81420830BD240@MWHPR08MB2382.namprd08.prod.outlook.com>

Hi,

Is there any hard limit to the number of subnets in a network?
In theory, would it be ok to put, like 5000 subnets, in a network?

Thanks!
Tony



From tonyliu0592 at hotmail.com  Fri Sep 11 04:15:54 2020
From: tonyliu0592 at hotmail.com (Tony Liu)
Date: Fri, 11 Sep 2020 04:15:54 +0000
Subject: "openstack server list" takes 30s
Message-ID: <MWHPR08MB23822F7953D333E26AB0234ABD240@MWHPR08MB2382.namprd08.prod.outlook.com>

Hi,

I built a Ussuri cluster with 3 controllers and 5 compute nodes.
OpenStack CLI ran pretty fast at the beginning, but gets slower
over time along with increased workloads. Right now, it takes
about 30s to list 10 VMs. The CPU, memory and disk usage are on
those 3 controllers are all in the range. I understand there are
many API calls happening behind CLI. I'd like to figure out how
this 30s is consumed, which call is the killer.
Any guidance or hint would be helpful.


Thanks!
Tony



From dev.faz at gmail.com  Fri Sep 11 05:38:03 2020
From: dev.faz at gmail.com (Fabian Zimmermann)
Date: Fri, 11 Sep 2020 07:38:03 +0200
Subject: "openstack server list" takes 30s
In-Reply-To: <MWHPR08MB23822F7953D333E26AB0234ABD240@MWHPR08MB2382.namprd08.prod.outlook.com>
References: <MWHPR08MB23822F7953D333E26AB0234ABD240@MWHPR08MB2382.namprd08.prod.outlook.com>
Message-ID: <CAA857Vz3Vm-sAT3s9-m6GZEnNUxG1sUWTDApQ-AsEYi2hi7enw@mail.gmail.com>

Hi,

You could try to use osProfiler.

 Fabian

Tony Liu <tonyliu0592 at hotmail.com> schrieb am Fr., 11. Sept. 2020, 06:24:

> Hi,
>
> I built a Ussuri cluster with 3 controllers and 5 compute nodes.
> OpenStack CLI ran pretty fast at the beginning, but gets slower
> over time along with increased workloads. Right now, it takes
> about 30s to list 10 VMs. The CPU, memory and disk usage are on
> those 3 controllers are all in the range. I understand there are
> many API calls happening behind CLI. I'd like to figure out how
> this 30s is consumed, which call is the killer.
> Any guidance or hint would be helpful.
>
>
> Thanks!
> Tony
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200911/6de7d2f7/attachment.html>

From radoslaw.piliszek at gmail.com  Fri Sep 11 07:07:39 2020
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Fri, 11 Sep 2020 09:07:39 +0200
Subject: [Keystone] socket.timeout: timed out
In-Reply-To: <MWHPR08MB238261D23CE45D13DA3472ABBD270@MWHPR08MB2382.namprd08.prod.outlook.com>
References: <MWHPR08MB238261D23CE45D13DA3472ABBD270@MWHPR08MB2382.namprd08.prod.outlook.com>
Message-ID: <CAKZ_x79PMBohiKq86gd4kP4mao=gyDkCeSw3ycKUW_sTkY8x4w@mail.gmail.com>

Hi Tony,

Well, it looks like memcached just timed out.
I'd check the load on it.

-yoctozepto

On Thu, Sep 10, 2020 at 7:24 PM Tony Liu <tonyliu0592 at hotmail.com> wrote:
>
> Any clues on this timeout exception?
>
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context [req-534d9855-8113-450d-8f9f-d93c0d961d24 113ee63a9ed0466794e24d069efc302c 4c142a681d884010ab36a7ac687d910c - default default] timed out: socket.timeout: timed out
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context Traceback (most recent call last):
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py", line 103, in _inner
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     return method(self, request)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py", line 353, in process_request
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     resp = super(AuthContextMiddleware, self).process_request(request)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystonemiddleware/auth_token/__init__.py", line 411, in process_request
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     allow_expired=allow_expired)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystonemiddleware/auth_token/__init__.py", line 445, in _do_fetch_token
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     data = self.fetch_token(token, **kwargs)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/server/flask/request_processing/middleware/auth_context.py", line 248, in fetch_token
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     token, access_rules_support=ACCESS_RULES_MIN_VERSION)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/common/manager.py", line 115, in wrapped
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     __ret_val = __f(*args, **kwargs)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/token/provider.py", line 145, in validate_token
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     token = self._validate_token(token_id)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "</usr/lib/python3.6/site-packages/decorator.py:decorator-gen-26>", line 2, in _validate_token
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/region.py", line 1360, in get_or_create_for_user_func
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     key, user_func, timeout, should_cache_fn, (arg, kw)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/region.py", line 962, in get_or_create
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     async_creator,
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/lock.py", line 187, in __enter__
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     return self._enter()
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/lock.py", line 94, in _enter
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     generated = self._enter_create(value, createdtime)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/lock.py", line 180, in _enter_create
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     return self.creator()
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/region.py", line 916, in gen_value
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     *creator_args[0], **creator_args[1]
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/token/provider.py", line 179, in _validate_token
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     token.mint(token_id, issued_at)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/models/token_model.py", line 579, in mint
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     self._validate_token_resources()
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/models/token_model.py", line 471, in _validate_token_resources
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     if self.project and not self.project_domain.get('enabled'):
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/models/token_model.py", line 176, in project_domain
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     self.project['domain_id']
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/common/manager.py", line 115, in wrapped
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     __ret_val = __f(*args, **kwargs)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "</usr/lib/python3.6/site-packages/decorator.py:decorator-gen-27>", line 2, in get_domain
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/region.py", line 1360, in get_or_create_for_user_func
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     key, user_func, timeout, should_cache_fn, (arg, kw)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/region.py", line 962, in get_or_create
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     async_creator,
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/lock.py", line 187, in __enter__
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     return self._enter()
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/lock.py", line 87, in _enter
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     value = value_fn()
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/region.py", line 902, in get_value
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     value = self.backend.get(key)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/keystone/common/cache/_context_cache.py", line 74, in get
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     value = self.proxied.get(key)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/dogpile/cache/backends/memcached.py", line 168, in get
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     value = self.client.get(key)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/oslo_cache/backends/memcache_pool.py", line 32, in _run_method
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     return getattr(client, __name)(*args, **kwargs)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/memcache.py", line 1129, in get
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     return self._get('get', key)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/memcache.py", line 1074, in _get
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     server, key = self._get_server(key)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/memcache.py", line 446, in _get_server
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     if server.connect():
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/memcache.py", line 1391, in connect
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     if self._get_socket():
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/memcache.py", line 1423, in _get_socket
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     self.flush()
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/memcache.py", line 1498, in flush
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     self.expect(b'OK')
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/memcache.py", line 1473, in expect
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     line = self.readline(raise_exception)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context   File "/usr/lib/python3.6/site-packages/memcache.py", line 1459, in readline
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context     data = recv(4096)
> 2020-09-10 10:10:33.981 28 ERROR keystone.server.flask.request_processing.middleware.auth_context socket.timeout: timed out
>
>
> Thanks!
> Tony
>
>


From oliver.weinmann at me.com  Fri Sep 11 07:53:40 2020
From: oliver.weinmann at me.com (Oliver Weinmann)
Date: Fri, 11 Sep 2020 07:53:40 -0000
Subject: =?utf-8?B?VXNzdXJpIC0gbWFrZSBhZGRlZCBtcHRzYXMgZHJpdmVyIHRvIGludHJvc3Bl?=
 =?utf-8?B?Y3Rpb24gaW5pdHJhbWZzIGxvYWQgYXV0b21hdGljYWxseQ==?=
Message-ID: <873eeade-c2f4-423d-81bb-c0be5976b0a0@me.com>

Hi,



I already asked this question on serverfault. But I guess here is a better place.



I have a very ancient hardware with a MPTSAS controller. I use this for TripleO deployment testing. With the release of Ussuri which is running CentOS8, I can no longer provision my overcloud nodes as the MPTSAS driver has been removed in CentOS8:

https://www.reddit.com/r/CentOS/comments/d93unk/centos8_and_removal_mpt2sas_dell_sas_drivers/


I managed to include the driver provided from ELrepo in the introspection image but It is not loaded automatically:

All commands are run as user "stack".

Extract the introspection image:


cd ~
mkdir imagesnew
cd imagesnew
tar xvf ../ironic-python-agent.tar
mkdir ~/ipa-tmp
cd ~/ipa-tmp
/usr/lib/dracut/skipcpio ~/imagesnew/ironic-python-agent.initramfs | zcat | cpio -ivd | pax -r


Extract the contents of the mptsas driver rpm:


rpm2cpio ~/kmod-mptsas-3.04.20-3.el8_2.elrepo.x86_64.rpm | pax -r


Put the kernel module in the right places. To figure out where the module has to reside I installed the rpm on a already deployed node and used find to locate it.

xz -c ./usr/lib/modules/4.18.0-193.el8.x86_64/extra/mptsas/mptsas.ko > ./usr/lib/modules/4.18.0-193.6.3.el8_2.x86_64/kernel/drivers/message/fusion/mptsas.ko.xz
mkdir ./usr/lib/modules/4.18.0-193.6.3.el8_2.x86_64/weak-updates/mptsas
sudo ln -sf /lib/modules/4.18.0-193.el8.x86_64/extra/mptsas/mptsas.ko lib/modules/4.18.0-193.6.3.el8_2.x86_64/weak-updates/mptsas.ko
sudo chown root . -R
find . 2>/dev/null | sudo cpio --quiet -c -o | gzip -8  > ~/images/ironic-python-agent.initramfs


Upload the new image


cd ~/images
openstack overcloud image upload --update-existing --image-path /home/stack/images/

Now when I start the introspection and ssh into the host I see no disks:


[root at localhost ~]# fdisk -l
[root at localhost ~]# lsmod | grep mptsas

Once i manually load the driver, I can see the disks:


[root at localhost ~]# modprobe mptsas
[root at localhost ~]# lsmod | grep mptsas
mptsas                 69632  0
mptscsih               45056  1 mptsas
mptbase                98304  2 mptsas,mptscsih
scsi_transport_sas     45056  1 mptsas
[root at localhost ~]# fdisk -l
Disk /dev/sda: 67.1 GiB, 71999422464 bytes, 140623872 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


But how can I make it so that it will automatically load on boot?


Best Regards,


Oliver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200911/94c5a3bd/attachment.html>

From e0ne at e0ne.info  Fri Sep 11 09:12:28 2020
From: e0ne at e0ne.info (Ivan Kolodyazhny)
Date: Fri, 11 Sep 2020 12:12:28 +0300
Subject: [cinder] propose Lucio Seki for cinder core
In-Reply-To: <2f42f092-5037-5f9d-48d6-cc52097f2479@gmail.com>
References: <2f42f092-5037-5f9d-48d6-cc52097f2479@gmail.com>
Message-ID: <CAGocpaH8io21rJ3LXYjuJE6gXru=8wyo-9_Ka5g=4C2mShZx8Q@mail.gmail.com>

+1 from me. Lucio does a lot of good contributions to Cinder.


Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/


On Fri, Sep 11, 2020 at 4:53 AM Brian Rosmaita <rosmaita.fossdev at gmail.com>
wrote:

> Lucio Seki (lseki on IRC) has been very active this cycle doing reviews,
> answering questions in IRC, and participating in the Cinder weekly
> meetings and at the midcycles.  He's been particularly thorough and
> helpful in his reviews of backend drivers, and has also been helpful in
> giving pointers to new driver maintainers who are setting up third party
> CI for their drivers.  Having Lucio as a core reviewer will help improve
> the team's review bandwidth without sacrificing review quality.
>
> In the absence of objections, I'll add Lucio to the core team just
> before the next Cinder team meeting (Wednesday, 16 September at 1400 UTC
> in #openstack-meeting-alt).  Please communicate any concerns to me
> before that time.
>
> cheers,
> brian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200911/8dd0f51c/attachment.html>

From skaplons at redhat.com  Fri Sep 11 10:50:39 2020
From: skaplons at redhat.com (Slawek Kaplonski)
Date: Fri, 11 Sep 2020 12:50:39 +0200
Subject: [Neutron] number of subnets in a network
In-Reply-To: <MWHPR08MB2382B217FA3BA97A81420830BD240@MWHPR08MB2382.namprd08.prod.outlook.com>
References: <MWHPR08MB2382B217FA3BA97A81420830BD240@MWHPR08MB2382.namprd08.prod.outlook.com>
Message-ID: <20200911105039.ehcdlb66iezfj3dh@skaplons-mac>

Hi,

I'm not aware about any such limit. There shouldn't be any IMHO.

On Fri, Sep 11, 2020 at 03:49:09AM +0000, Tony Liu wrote:
> Hi,
> 
> Is there any hard limit to the number of subnets in a network?
> In theory, would it be ok to put, like 5000 subnets, in a network?
> 
> Thanks!
> Tony
> 
> 

-- 
Slawek Kaplonski
Principal software engineer
Red Hat



From klemen at psi-net.si  Fri Sep 11 10:51:33 2020
From: klemen at psi-net.si (Klemen Pogacnik)
Date: Fri, 11 Sep 2020 12:51:33 +0200
Subject: [kolla-ansible] Ceph in Ussuri
Message-ID: <CAMAdsZ_+VCbHoyDDjf7vb3=+Tb=yrFXj_x0TPK7F_VatEtVHVw@mail.gmail.com>

I've done Ansible playbook to simplify Ceph integration with Openstack.
It's based on cephadm-ansible project (
https://github.com/jcmdln/cephadm-ansible)
Check:
https://gitlab.com/kemopq/it_addmodule-ceph
Any suggestions and/or help are appreciated!
Klemen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200911/83eda456/attachment.html>

From ignaziocassano at gmail.com  Fri Sep 11 11:12:58 2020
From: ignaziocassano at gmail.com (Ignazio Cassano)
Date: Fri, 11 Sep 2020 13:12:58 +0200
Subject: [Neutron] number of subnets in a network
In-Reply-To: <20200911105039.ehcdlb66iezfj3dh@skaplons-mac>
References: <MWHPR08MB2382B217FA3BA97A81420830BD240@MWHPR08MB2382.namprd08.prod.outlook.com>
 <20200911105039.ehcdlb66iezfj3dh@skaplons-mac>
Message-ID: <CAB7j8cUbQoQRmEg5vNrwRpCDsZRCYGyUzgKXkCXXiJGD749bcA@mail.gmail.com>

Hello, I know there is an issue with dhcp agent on queens when there are a
lot of subnets. The issue is solved in stein.
Ignazio

Il Ven 11 Set 2020, 12:58 Slawek Kaplonski <skaplons at redhat.com> ha scritto:

> Hi,
>
> I'm not aware about any such limit. There shouldn't be any IMHO.
>
> On Fri, Sep 11, 2020 at 03:49:09AM +0000, Tony Liu wrote:
> > Hi,
> >
> > Is there any hard limit to the number of subnets in a network?
> > In theory, would it be ok to put, like 5000 subnets, in a network?
> >
> > Thanks!
> > Tony
> >
> >
>
> --
> Slawek Kaplonski
> Principal software engineer
> Red Hat
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200911/7bbcbafd/attachment.html>

From mdulko at redhat.com  Fri Sep 11 11:50:57 2020
From: mdulko at redhat.com (=?UTF-8?Q?Micha=C5=82?= Dulko)
Date: Fri, 11 Sep 2020 13:50:57 +0200
Subject: [all][tc][goals] Migrate CI/CD jobs to new Ubuntu LTS Focal:
 Week R-4 Update
In-Reply-To: <1747442027f.bb3f3d1823475.212800600164097649@ghanshyammann.com>
References: <17468f8f785.1123a07e6307801.3844845549431858647@ghanshyammann.com>
 <1746feef403.c41c848411058.2421030943223377212@ghanshyammann.com>
 <1747442027f.bb3f3d1823475.212800600164097649@ghanshyammann.com>
Message-ID: <447841d8d8560f96475cb0a275e34464ece6352b.camel@redhat.com>

On Wed, 2020-09-09 at 14:05 -0500, Ghanshyam Mann wrote:
>  ---- On Tue, 08 Sep 2020 17:56:05 -0500 Ghanshyam Mann <
> gmann at ghanshyammann.com> wrote ----
>  > Updates:
>  > After working more on failing one today and listing the blocking
> one, I think we are good to switch tox based testing today
>  > and discuss the integration testing switch tomorrow in TC office
> hours. 
>  > 
>  > > * Part1: Migrating tox base job tomorrow (8th Sept):
>  >  
>  > I have checked it again and fixed many repos that are up for
> review and merge. Most python clients are already fixed
>  > or their fixes are up for merge so they can make it before the
> feature freeze on 10th. If any repo is broken then it will be pretty
> quick
>  > to fix by lower constraint bump (see the example under 
> https://review.opendev.org/#/q/topic:migrate-to-focal)
>  > 
>  > Even if any of the fixes miss the victoria release then those can
> be backported easily. I am opening the tox base jobs migration to
> merge: 
>  >  - All patches in this series 
> https://review.opendev.org/#/c/738328/
> 
> All these tox base jobs are merged now and running on Focal. If any
> of your repo is failing, please fix on priority or ping me on IRC if
> failure not clear.
> You can find most of the fixes for possible failure in this topic:
> - 
> https://review.opendev.org/#/q/topic:migrate-to-focal+(status:open+OR+status:merged)
> 
> -gmann

We're in a bit of a pickle here. So with kuryr-kubernetes we aim to
keep lower-constraints on the versions that can be found in
CentOS/RHEL8 and seems like cffi 1.11.5 won't compile with Python 3.8.
What should we do here? Is such assumption even possible given broader
OpenStack assumptions?

>  > 
>  > 
>  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
>  > 
>  > We have three blocking open bugs here so I would like to discuss
> it in tomorrow's TC office hour also about how to proceed on this.
>  > 
>  > 1. Nova: https://bugs.launchpad.net/nova/+bug/1882521  (
> https://bugs.launchpad.net/qemu/+bug/1894804)
>  > 2. Barbican: https://storyboard.openstack.org/#!/story/2007732
>  > 3. Ceilometer: https://storyboard.openstack.org/#!/story/2008121
>  > 
>  > 
>  > -gmann
>  > 
>  > 
>  >  ---- On Mon, 07 Sep 2020 09:29:40 -0500 Ghanshyam Mann <
> gmann at ghanshyammann.com> wrote ----
>  >  > Hello Everyone,
>  >  > 
>  >  > Please find the week R-4 updates on 'Ubuntu Focal migration'
> community goal. Its time to force the base jobs migration which can
>  >  > break the projects gate if not yet taken care of. Read below
> for the plan.
>  >  > 
>  >  > Tracking: https://storyboard.openstack.org/#!/story/2007865
>  >  > 
>  >  > Progress:
>  >  > =======
>  >  > * We are close to V-3 release and this is time we have to
> complete this migration otherwise doing it in RC period can add
>  >  > unnecessary and last min delay. I am going to plan this
> migration in two-part. This will surely break some projects gate
>  >  > which is not yet finished the migration but we have to do at
> some time. Please let me know if any objection to the below
>  >  > plan.
>  >  > 
>  >  > * Part1: Migrating tox base job tomorrow (8th Sept):
>  >  > 
>  >  > ** I am going to open tox base jobs migration (doc, unit,
> functional, lower-constraints etc) to merge by tomorrow. which is
> this
>  >  > series (all base patches of this):  
> https://review.opendev.org/#/c/738328/ . 
>  >  > 
>  >  > **There are few repos still failing on requirements lower-
> constraints job specifically which I tried my best to fix as many as
> possible.
>  >  >  Many are ready to merge also. Please merge or work on your
> projects repo testing before that or fix on priority if failing.
>  >  > 
>  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
>  >  > 
>  >  > * We have few open bugs for this which are not yet resolved, we
> will see how it goes but the current plan is to migrate by 10th Sept.
>  >  > 
>  >  > ** Bug#1882521
>  >  > ** DB migration issues,
>  >  > *** alembic and few on telemetry/gnocchi side  
> https://github.com/sqlalchemy/alembic/issues/699, 
> https://storyboard.openstack.org/#!/story/2008003
>  >  > 
>  >  > 
>  >  > Testing Till now:
>  >  > ============
>  >  > * ~200 repos gate have been tested or fixed till now.
>  >  > ** 
> https://review.opendev.org/#/q/topic:migrate-to-focal+(status:abandoned+OR+status:merged)
>  >  > 
>  >  > * ~100 repos are under test and failing. Debugging and fixing
> are in progress (If you would like to help, please check your
>  >  > project repos if I am late to fix them):
>  >  > ** 
> https://review.opendev.org/#/q/topic:migrate-to-focal+status:open
>  >  > 
>  >  > * ~30repos fixes ready to merge:
>  >  > ** 
> https://review.opendev.org/#/q/topic:migrate-to-focal+status:open+label%3AVerified%3E%3D1%2Czuul+NOT+label%3AWorkflow%3C%3D-1
>  >  > 
>  >  > 
>  >  > Bugs Report:
>  >  > ==========
>  >  > 
>  >  > 1. Bug#1882521. (IN-PROGRESS)
>  >  > There is open bug for nova/cinder where three tempest tests are
> failing for
>  >  > volume detach operation. There is no clear root cause found yet
>  >  > -https://bugs.launchpad.net/cinder/+bug/1882521
>  >  > We have skipped the tests in tempest base patch to proceed with
> the other
>  >  > projects testing but this is blocking things for the migration.
>  >  > 
>  >  > 2. DB migration issues (IN-PROGRESS)
>  >  > * alembic and few on telemetry/gnocchi side  
> https://github.com/sqlalchemy/alembic/issues/699, 
> https://storyboard.openstack.org/#!/story/2008003
>  >  > 
>  >  > 3. We encountered the nodeset name conflict with x/tobiko.
> (FIXED)
>  >  > nodeset conflict is resolved now and devstack provides all
> focal nodes now.
>  >  > 
>  >  > 4. Bug#1886296. (IN-PROGRESS)
>  >  > pyflakes till 2.1.0 is not compatible with python 3.8 which is
> the default python version
>  >  > on ubuntu focal[1]. With pep8 job running on focal faces the
> issue and fail. We need to bump
>  >  > the pyflakes to 2.1.1 as min version to run pep8 jobs on py3.8.
>  >  > As of now, many projects are using old hacking version so I am
> explicitly adding pyflakes>=2.1.1
>  >  > on the project side[2] but for the long term easy maintenance,
> I am doing it in 'hacking' requirements.txt[3]
>  >  > nd will release a new hacking version. After that project can
> move to new hacking and do not need
>  >  > to maintain pyflakes version compatibility.
>  >  > 
>  >  > 5. Bug#1886298. (IN-PROGRESS)
>  >  > 'Markupsafe' 1.0 is not compatible with the latest version of
> setuptools[4],
>  >  > We need to bump the lower-constraint for Markupsafe to 1.1.1 to
> make it work.
>  >  > There are a few more issues[5] with lower-constraint jobs which
> I am debugging.
>  >  > 
>  >  > 
>  >  > What work to be done on the project side:
>  >  > ================================
>  >  > This goal is more of testing the jobs on focal and fixing bugs
> if any otherwise
>  >  > migrate jobs by switching the nodeset to focal node sets
> defined in devstack.
>  >  > 
>  >  > 1. Start a patch in your repo by making depends-on on either of
> below:
>  >  > devstack base patch if you are using only devstack base jobs
> not tempest:
>  >  > 
>  >  > Depends-on: https://review.opendev.org/#/c/731207/
>  >  > OR
>  >  > tempest base patch if you are using the tempest base job (like
> devstack-tempest):
>  >  > Depends-on: https://review.opendev.org/#/c/734700/
>  >  > 
>  >  > Both have depends-on on the series where I am moving
> unit/functional/doc/cover/nodejs tox jobs to focal. So
>  >  > you can test the complete gate
> jobs(unit/functional/doc/integration) together.
>  >  > This and its base patches - 
> https://review.opendev.org/#/c/738328/
>  >  > 
>  >  > Example: https://review.opendev.org/#/c/738126/
>  >  > 
>  >  > 2. If none of your project jobs override the nodeset then above
> patch will be
>  >  > testing patch(do not merge) otherwise change the nodeset to
> focal.
>  >  > Example: https://review.opendev.org/#/c/737370/
>  >  > 
>  >  > 3. If the jobs are defined in branchless repo and override the
> nodeset then you need to override the branches
>  >  > variant to adjust the nodeset so that those jobs run on Focal
> on victoria onwards only. If no nodeset
>  >  > is overridden then devstack being branched and stable base job
> using bionic/xenial will take care of
>  >  > this.
>  >  > Example: https://review.opendev.org/#/c/744056/2
>  >  > 
>  >  > 4. If no updates need you can abandon the testing patch (
> https://review.opendev.org/#/c/744341/). If it need
>  >  > updates then modify the same patch with proper commit msg, once
> it pass the gate then remove the Depends-On
>  >  > so that you can merge your patch before base jobs are switched
> to focal. This way we make sure no gate downtime in
>  >  > this migration.
>  >  > Example: https://review.opendev.org/#/c/744056/1..2//COMMIT_MSG
>  >  > 
>  >  > Once we finish the testing on projects side and no failure then
> we will merge the devstack and tempest
>  >  > base patches.
>  >  > 
>  >  > 
>  >  > Important things to note:
>  >  > ===================
>  >  > * Do not forgot to add the story and task link to your patch so
> that we can track it smoothly.
>  >  > * Use gerrit topic 'migrate-to-focal'
>  >  > * Do not backport any of the patches.
>  >  > 
>  >  > 
>  >  > References:
>  >  > =========
>  >  > Goal doc: 
> https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-jobs-to-ubuntu-focal.html
>  >  > Storyboard tracking: 
> https://storyboard.openstack.org/#!/story/2007865
>  >  > 
>  >  > [1] https://github.com/PyCQA/pyflakes/issues/367
>  >  > [2] https://review.opendev.org/#/c/739315/
>  >  > [3] https://review.opendev.org/#/c/739334/
>  >  > [4] https://github.com/pallets/markupsafe/issues/116
>  >  > [5] 
> https://zuul.opendev.org/t/openstack/build/7ecd9cf100194bc99b3b70fa1e6de032
>  >  > 
>  >  > -gmann
>  >  > 
>  >  > 
>  > 
>  > 
> 




From smooney at redhat.com  Fri Sep 11 11:53:03 2020
From: smooney at redhat.com (Sean Mooney)
Date: Fri, 11 Sep 2020 12:53:03 +0100
Subject: [Neutron] number of subnets in a network
In-Reply-To: <CAB7j8cUbQoQRmEg5vNrwRpCDsZRCYGyUzgKXkCXXiJGD749bcA@mail.gmail.com>
References: <MWHPR08MB2382B217FA3BA97A81420830BD240@MWHPR08MB2382.namprd08.prod.outlook.com>
 <20200911105039.ehcdlb66iezfj3dh@skaplons-mac>
 <CAB7j8cUbQoQRmEg5vNrwRpCDsZRCYGyUzgKXkCXXiJGD749bcA@mail.gmail.com>
Message-ID: <95cfcb95500a6da897732c1a6d835ae1e42af6fa.camel@redhat.com>

is this request related to routed networks by anychance

im just interested in why you would need 5000 subnets in one network
in a non routed case you would like have issue with broadcast domains and that many networks
but with routed network that would not be an issue.

On Fri, 2020-09-11 at 13:12 +0200, Ignazio Cassano wrote:
> Hello, I know there is an issue with dhcp agent on queens when there are a
> lot of subnets. The issue is solved in stein.
> Ignazio
> 
> Il Ven 11 Set 2020, 12:58 Slawek Kaplonski <skaplons at redhat.com> ha scritto:
> 
> > Hi,
> > 
> > I'm not aware about any such limit. There shouldn't be any IMHO.
> > 
> > On Fri, Sep 11, 2020 at 03:49:09AM +0000, Tony Liu wrote:
> > > Hi,
> > > 
> > > Is there any hard limit to the number of subnets in a network?
> > > In theory, would it be ok to put, like 5000 subnets, in a network?
> > > 
> > > Thanks!
> > > Tony
> > > 
> > > 
> > 
> > --
> > Slawek Kaplonski
> > Principal software engineer
> > Red Hat
> > 
> > 
> > 



From radoslaw.piliszek at gmail.com  Fri Sep 11 12:13:14 2020
From: radoslaw.piliszek at gmail.com (=?UTF-8?Q?Rados=C5=82aw_Piliszek?=)
Date: Fri, 11 Sep 2020 14:13:14 +0200
Subject: [all][tc][goals] Migrate CI/CD jobs to new Ubuntu LTS Focal: Week
 R-4 Update
In-Reply-To: <447841d8d8560f96475cb0a275e34464ece6352b.camel@redhat.com>
References: <17468f8f785.1123a07e6307801.3844845549431858647@ghanshyammann.com>
 <1746feef403.c41c848411058.2421030943223377212@ghanshyammann.com>
 <1747442027f.bb3f3d1823475.212800600164097649@ghanshyammann.com>
 <447841d8d8560f96475cb0a275e34464ece6352b.camel@redhat.com>
Message-ID: <CAKZ_x78wV7knxNE=tmW8+MJhezCYDU4Dm4yyV-YO4y5VN04eKA@mail.gmail.com>

I agree with Michał that it kind of breaks the purpose of lower-constraints.
Supposedly lower-constraints should just be tested with the lowest
supported python version?
WDYT, Folks?

(That said, lots of projects already made lower-constraints break on
RDO due to these bumps.)

-yoctozepto

On Fri, Sep 11, 2020 at 2:02 PM Michał Dulko <mdulko at redhat.com> wrote:
>
> On Wed, 2020-09-09 at 14:05 -0500, Ghanshyam Mann wrote:
> >  ---- On Tue, 08 Sep 2020 17:56:05 -0500 Ghanshyam Mann <
> > gmann at ghanshyammann.com> wrote ----
> >  > Updates:
> >  > After working more on failing one today and listing the blocking
> > one, I think we are good to switch tox based testing today
> >  > and discuss the integration testing switch tomorrow in TC office
> > hours.
> >  >
> >  > > * Part1: Migrating tox base job tomorrow (8th Sept):
> >  >
> >  > I have checked it again and fixed many repos that are up for
> > review and merge. Most python clients are already fixed
> >  > or their fixes are up for merge so they can make it before the
> > feature freeze on 10th. If any repo is broken then it will be pretty
> > quick
> >  > to fix by lower constraint bump (see the example under
> > https://review.opendev.org/#/q/topic:migrate-to-focal)
> >  >
> >  > Even if any of the fixes miss the victoria release then those can
> > be backported easily. I am opening the tox base jobs migration to
> > merge:
> >  >  - All patches in this series
> > https://review.opendev.org/#/c/738328/
> >
> > All these tox base jobs are merged now and running on Focal. If any
> > of your repo is failing, please fix on priority or ping me on IRC if
> > failure not clear.
> > You can find most of the fixes for possible failure in this topic:
> > -
> > https://review.opendev.org/#/q/topic:migrate-to-focal+(status:open+OR+status:merged)
> >
> > -gmann
>
> We're in a bit of a pickle here. So with kuryr-kubernetes we aim to
> keep lower-constraints on the versions that can be found in
> CentOS/RHEL8 and seems like cffi 1.11.5 won't compile with Python 3.8.
> What should we do here? Is such assumption even possible given broader
> OpenStack assumptions?
>
> >  >
> >  >
> >  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
> >  >
> >  > We have three blocking open bugs here so I would like to discuss
> > it in tomorrow's TC office hour also about how to proceed on this.
> >  >
> >  > 1. Nova: https://bugs.launchpad.net/nova/+bug/1882521  (
> > https://bugs.launchpad.net/qemu/+bug/1894804)
> >  > 2. Barbican: https://storyboard.openstack.org/#!/story/2007732
> >  > 3. Ceilometer: https://storyboard.openstack.org/#!/story/2008121
> >  >
> >  >
> >  > -gmann
> >  >
> >  >
> >  >  ---- On Mon, 07 Sep 2020 09:29:40 -0500 Ghanshyam Mann <
> > gmann at ghanshyammann.com> wrote ----
> >  >  > Hello Everyone,
> >  >  >
> >  >  > Please find the week R-4 updates on 'Ubuntu Focal migration'
> > community goal. Its time to force the base jobs migration which can
> >  >  > break the projects gate if not yet taken care of. Read below
> > for the plan.
> >  >  >
> >  >  > Tracking: https://storyboard.openstack.org/#!/story/2007865
> >  >  >
> >  >  > Progress:
> >  >  > =======
> >  >  > * We are close to V-3 release and this is time we have to
> > complete this migration otherwise doing it in RC period can add
> >  >  > unnecessary and last min delay. I am going to plan this
> > migration in two-part. This will surely break some projects gate
> >  >  > which is not yet finished the migration but we have to do at
> > some time. Please let me know if any objection to the below
> >  >  > plan.
> >  >  >
> >  >  > * Part1: Migrating tox base job tomorrow (8th Sept):
> >  >  >
> >  >  > ** I am going to open tox base jobs migration (doc, unit,
> > functional, lower-constraints etc) to merge by tomorrow. which is
> > this
> >  >  > series (all base patches of this):
> > https://review.opendev.org/#/c/738328/ .
> >  >  >
> >  >  > **There are few repos still failing on requirements lower-
> > constraints job specifically which I tried my best to fix as many as
> > possible.
> >  >  >  Many are ready to merge also. Please merge or work on your
> > projects repo testing before that or fix on priority if failing.
> >  >  >
> >  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
> >  >  >
> >  >  > * We have few open bugs for this which are not yet resolved, we
> > will see how it goes but the current plan is to migrate by 10th Sept.
> >  >  >
> >  >  > ** Bug#1882521
> >  >  > ** DB migration issues,
> >  >  > *** alembic and few on telemetry/gnocchi side
> > https://github.com/sqlalchemy/alembic/issues/699,
> > https://storyboard.openstack.org/#!/story/2008003
> >  >  >
> >  >  >
> >  >  > Testing Till now:
> >  >  > ============
> >  >  > * ~200 repos gate have been tested or fixed till now.
> >  >  > **
> > https://review.opendev.org/#/q/topic:migrate-to-focal+(status:abandoned+OR+status:merged)
> >  >  >
> >  >  > * ~100 repos are under test and failing. Debugging and fixing
> > are in progress (If you would like to help, please check your
> >  >  > project repos if I am late to fix them):
> >  >  > **
> > https://review.opendev.org/#/q/topic:migrate-to-focal+status:open
> >  >  >
> >  >  > * ~30repos fixes ready to merge:
> >  >  > **
> > https://review.opendev.org/#/q/topic:migrate-to-focal+status:open+label%3AVerified%3E%3D1%2Czuul+NOT+label%3AWorkflow%3C%3D-1
> >  >  >
> >  >  >
> >  >  > Bugs Report:
> >  >  > ==========
> >  >  >
> >  >  > 1. Bug#1882521. (IN-PROGRESS)
> >  >  > There is open bug for nova/cinder where three tempest tests are
> > failing for
> >  >  > volume detach operation. There is no clear root cause found yet
> >  >  > -https://bugs.launchpad.net/cinder/+bug/1882521
> >  >  > We have skipped the tests in tempest base patch to proceed with
> > the other
> >  >  > projects testing but this is blocking things for the migration.
> >  >  >
> >  >  > 2. DB migration issues (IN-PROGRESS)
> >  >  > * alembic and few on telemetry/gnocchi side
> > https://github.com/sqlalchemy/alembic/issues/699,
> > https://storyboard.openstack.org/#!/story/2008003
> >  >  >
> >  >  > 3. We encountered the nodeset name conflict with x/tobiko.
> > (FIXED)
> >  >  > nodeset conflict is resolved now and devstack provides all
> > focal nodes now.
> >  >  >
> >  >  > 4. Bug#1886296. (IN-PROGRESS)
> >  >  > pyflakes till 2.1.0 is not compatible with python 3.8 which is
> > the default python version
> >  >  > on ubuntu focal[1]. With pep8 job running on focal faces the
> > issue and fail. We need to bump
> >  >  > the pyflakes to 2.1.1 as min version to run pep8 jobs on py3.8.
> >  >  > As of now, many projects are using old hacking version so I am
> > explicitly adding pyflakes>=2.1.1
> >  >  > on the project side[2] but for the long term easy maintenance,
> > I am doing it in 'hacking' requirements.txt[3]
> >  >  > nd will release a new hacking version. After that project can
> > move to new hacking and do not need
> >  >  > to maintain pyflakes version compatibility.
> >  >  >
> >  >  > 5. Bug#1886298. (IN-PROGRESS)
> >  >  > 'Markupsafe' 1.0 is not compatible with the latest version of
> > setuptools[4],
> >  >  > We need to bump the lower-constraint for Markupsafe to 1.1.1 to
> > make it work.
> >  >  > There are a few more issues[5] with lower-constraint jobs which
> > I am debugging.
> >  >  >
> >  >  >
> >  >  > What work to be done on the project side:
> >  >  > ================================
> >  >  > This goal is more of testing the jobs on focal and fixing bugs
> > if any otherwise
> >  >  > migrate jobs by switching the nodeset to focal node sets
> > defined in devstack.
> >  >  >
> >  >  > 1. Start a patch in your repo by making depends-on on either of
> > below:
> >  >  > devstack base patch if you are using only devstack base jobs
> > not tempest:
> >  >  >
> >  >  > Depends-on: https://review.opendev.org/#/c/731207/
> >  >  > OR
> >  >  > tempest base patch if you are using the tempest base job (like
> > devstack-tempest):
> >  >  > Depends-on: https://review.opendev.org/#/c/734700/
> >  >  >
> >  >  > Both have depends-on on the series where I am moving
> > unit/functional/doc/cover/nodejs tox jobs to focal. So
> >  >  > you can test the complete gate
> > jobs(unit/functional/doc/integration) together.
> >  >  > This and its base patches -
> > https://review.opendev.org/#/c/738328/
> >  >  >
> >  >  > Example: https://review.opendev.org/#/c/738126/
> >  >  >
> >  >  > 2. If none of your project jobs override the nodeset then above
> > patch will be
> >  >  > testing patch(do not merge) otherwise change the nodeset to
> > focal.
> >  >  > Example: https://review.opendev.org/#/c/737370/
> >  >  >
> >  >  > 3. If the jobs are defined in branchless repo and override the
> > nodeset then you need to override the branches
> >  >  > variant to adjust the nodeset so that those jobs run on Focal
> > on victoria onwards only. If no nodeset
> >  >  > is overridden then devstack being branched and stable base job
> > using bionic/xenial will take care of
> >  >  > this.
> >  >  > Example: https://review.opendev.org/#/c/744056/2
> >  >  >
> >  >  > 4. If no updates need you can abandon the testing patch (
> > https://review.opendev.org/#/c/744341/). If it need
> >  >  > updates then modify the same patch with proper commit msg, once
> > it pass the gate then remove the Depends-On
> >  >  > so that you can merge your patch before base jobs are switched
> > to focal. This way we make sure no gate downtime in
> >  >  > this migration.
> >  >  > Example: https://review.opendev.org/#/c/744056/1..2//COMMIT_MSG
> >  >  >
> >  >  > Once we finish the testing on projects side and no failure then
> > we will merge the devstack and tempest
> >  >  > base patches.
> >  >  >
> >  >  >
> >  >  > Important things to note:
> >  >  > ===================
> >  >  > * Do not forgot to add the story and task link to your patch so
> > that we can track it smoothly.
> >  >  > * Use gerrit topic 'migrate-to-focal'
> >  >  > * Do not backport any of the patches.
> >  >  >
> >  >  >
> >  >  > References:
> >  >  > =========
> >  >  > Goal doc:
> > https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-jobs-to-ubuntu-focal.html
> >  >  > Storyboard tracking:
> > https://storyboard.openstack.org/#!/story/2007865
> >  >  >
> >  >  > [1] https://github.com/PyCQA/pyflakes/issues/367
> >  >  > [2] https://review.opendev.org/#/c/739315/
> >  >  > [3] https://review.opendev.org/#/c/739334/
> >  >  > [4] https://github.com/pallets/markupsafe/issues/116
> >  >  > [5]
> > https://zuul.opendev.org/t/openstack/build/7ecd9cf100194bc99b3b70fa1e6de032
> >  >  >
> >  >  > -gmann
> >  >  >
> >  >  >
> >  >
> >  >
> >
>
>
>


From gmann at ghanshyammann.com  Fri Sep 11 12:30:28 2020
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Fri, 11 Sep 2020 07:30:28 -0500
Subject: [all][tc][goals] Migrate CI/CD jobs to new Ubuntu LTS Focal:
 Week R-4 Update
In-Reply-To: <CAKZ_x78wV7knxNE=tmW8+MJhezCYDU4Dm4yyV-YO4y5VN04eKA@mail.gmail.com>
References: <17468f8f785.1123a07e6307801.3844845549431858647@ghanshyammann.com>
 <1746feef403.c41c848411058.2421030943223377212@ghanshyammann.com>
 <1747442027f.bb3f3d1823475.212800600164097649@ghanshyammann.com>
 <447841d8d8560f96475cb0a275e34464ece6352b.camel@redhat.com>
 <CAKZ_x78wV7knxNE=tmW8+MJhezCYDU4Dm4yyV-YO4y5VN04eKA@mail.gmail.com>
Message-ID: <1747d254391.1106413e3106578.3208130175292980261@ghanshyammann.com>

 ---- On Fri, 11 Sep 2020 07:13:14 -0500 Radosław Piliszek <radoslaw.piliszek at gmail.com> wrote ----
 > I agree with Michał that it kind of breaks the purpose of lower-constraints.
 > Supposedly lower-constraints should just be tested with the lowest
 > supported python version?
 > WDYT, Folks?
 > 
 > (That said, lots of projects already made lower-constraints break on
 > RDO due to these bumps.)

This is something we discussed yesterday, there are both way we can argue whether
we should test l-c on lower supported python or available python on tested Disro which
we do with Ubuntu Focal for all tox based jobs. And believe be lower constraints are not
only python version things. But It is fine for projects say kuryr-kubernetes to keep running
the l-c job on Bionic or centos I can provide patch for that.

and for RHEL compatible version, it can be adjusted as I did in ceilometer for lxml
but I am not sure if we can test all of them for RHEL also.
- https://review.opendev.org/#/c/744612/

I am going to submit a Forum session to discuss on this topic so that we have
an agreed way of testing in future,  

-gman


 > 
 > -yoctozepto
 > 
 > On Fri, Sep 11, 2020 at 2:02 PM Michał Dulko <mdulko at redhat.com> wrote:
 > >
 > > On Wed, 2020-09-09 at 14:05 -0500, Ghanshyam Mann wrote:
 > > >  ---- On Tue, 08 Sep 2020 17:56:05 -0500 Ghanshyam Mann <
 > > > gmann at ghanshyammann.com> wrote ----
 > > >  > Updates:
 > > >  > After working more on failing one today and listing the blocking
 > > > one, I think we are good to switch tox based testing today
 > > >  > and discuss the integration testing switch tomorrow in TC office
 > > > hours.
 > > >  >
 > > >  > > * Part1: Migrating tox base job tomorrow (8th Sept):
 > > >  >
 > > >  > I have checked it again and fixed many repos that are up for
 > > > review and merge. Most python clients are already fixed
 > > >  > or their fixes are up for merge so they can make it before the
 > > > feature freeze on 10th. If any repo is broken then it will be pretty
 > > > quick
 > > >  > to fix by lower constraint bump (see the example under
 > > > https://review.opendev.org/#/q/topic:migrate-to-focal)
 > > >  >
 > > >  > Even if any of the fixes miss the victoria release then those can
 > > > be backported easily. I am opening the tox base jobs migration to
 > > > merge:
 > > >  >  - All patches in this series
 > > > https://review.opendev.org/#/c/738328/
 > > >
 > > > All these tox base jobs are merged now and running on Focal. If any
 > > > of your repo is failing, please fix on priority or ping me on IRC if
 > > > failure not clear.
 > > > You can find most of the fixes for possible failure in this topic:
 > > > -
 > > > https://review.opendev.org/#/q/topic:migrate-to-focal+(status:open+OR+status:merged)
 > > >
 > > > -gmann
 > >
 > > We're in a bit of a pickle here. So with kuryr-kubernetes we aim to
 > > keep lower-constraints on the versions that can be found in
 > > CentOS/RHEL8 and seems like cffi 1.11.5 won't compile with Python 3.8.
 > > What should we do here? Is such assumption even possible given broader
 > > OpenStack assumptions?
 > >
 > > >  >
 > > >  >
 > > >  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
 > > >  >
 > > >  > We have three blocking open bugs here so I would like to discuss
 > > > it in tomorrow's TC office hour also about how to proceed on this.
 > > >  >
 > > >  > 1. Nova: https://bugs.launchpad.net/nova/+bug/1882521  (
 > > > https://bugs.launchpad.net/qemu/+bug/1894804)
 > > >  > 2. Barbican: https://storyboard.openstack.org/#!/story/2007732
 > > >  > 3. Ceilometer: https://storyboard.openstack.org/#!/story/2008121
 > > >  >
 > > >  >
 > > >  > -gmann
 > > >  >
 > > >  >
 > > >  >  ---- On Mon, 07 Sep 2020 09:29:40 -0500 Ghanshyam Mann <
 > > > gmann at ghanshyammann.com> wrote ----
 > > >  >  > Hello Everyone,
 > > >  >  >
 > > >  >  > Please find the week R-4 updates on 'Ubuntu Focal migration'
 > > > community goal. Its time to force the base jobs migration which can
 > > >  >  > break the projects gate if not yet taken care of. Read below
 > > > for the plan.
 > > >  >  >
 > > >  >  > Tracking: https://storyboard.openstack.org/#!/story/2007865
 > > >  >  >
 > > >  >  > Progress:
 > > >  >  > =======
 > > >  >  > * We are close to V-3 release and this is time we have to
 > > > complete this migration otherwise doing it in RC period can add
 > > >  >  > unnecessary and last min delay. I am going to plan this
 > > > migration in two-part. This will surely break some projects gate
 > > >  >  > which is not yet finished the migration but we have to do at
 > > > some time. Please let me know if any objection to the below
 > > >  >  > plan.
 > > >  >  >
 > > >  >  > * Part1: Migrating tox base job tomorrow (8th Sept):
 > > >  >  >
 > > >  >  > ** I am going to open tox base jobs migration (doc, unit,
 > > > functional, lower-constraints etc) to merge by tomorrow. which is
 > > > this
 > > >  >  > series (all base patches of this):
 > > > https://review.opendev.org/#/c/738328/ .
 > > >  >  >
 > > >  >  > **There are few repos still failing on requirements lower-
 > > > constraints job specifically which I tried my best to fix as many as
 > > > possible.
 > > >  >  >  Many are ready to merge also. Please merge or work on your
 > > > projects repo testing before that or fix on priority if failing.
 > > >  >  >
 > > >  >  > * Part2: Migrating devstack/tempest  base job on 10th sept:
 > > >  >  >
 > > >  >  > * We have few open bugs for this which are not yet resolved, we
 > > > will see how it goes but the current plan is to migrate by 10th Sept.
 > > >  >  >
 > > >  >  > ** Bug#1882521
 > > >  >  > ** DB migration issues,
 > > >  >  > *** alembic and few on telemetry/gnocchi side
 > > > https://github.com/sqlalchemy/alembic/issues/699,
 > > > https://storyboard.openstack.org/#!/story/2008003
 > > >  >  >
 > > >  >  >
 > > >  >  > Testing Till now:
 > > >  >  > ============
 > > >  >  > * ~200 repos gate have been tested or fixed till now.
 > > >  >  > **
 > > > https://review.opendev.org/#/q/topic:migrate-to-focal+(status:abandoned+OR+status:merged)
 > > >  >  >
 > > >  >  > * ~100 repos are under test and failing. Debugging and fixing
 > > > are in progress (If you would like to help, please check your
 > > >  >  > project repos if I am late to fix them):
 > > >  >  > **
 > > > https://review.opendev.org/#/q/topic:migrate-to-focal+status:open
 > > >  >  >
 > > >  >  > * ~30repos fixes ready to merge:
 > > >  >  > **
 > > > https://review.opendev.org/#/q/topic:migrate-to-focal+status:open+label%3AVerified%3E%3D1%2Czuul+NOT+label%3AWorkflow%3C%3D-1
 > > >  >  >
 > > >  >  >
 > > >  >  > Bugs Report:
 > > >  >  > ==========
 > > >  >  >
 > > >  >  > 1. Bug#1882521. (IN-PROGRESS)
 > > >  >  > There is open bug for nova/cinder where three tempest tests are
 > > > failing for
 > > >  >  > volume detach operation. There is no clear root cause found yet
 > > >  >  > -https://bugs.launchpad.net/cinder/+bug/1882521
 > > >  >  > We have skipped the tests in tempest base patch to proceed with
 > > > the other
 > > >  >  > projects testing but this is blocking things for the migration.
 > > >  >  >
 > > >  >  > 2. DB migration issues (IN-PROGRESS)
 > > >  >  > * alembic and few on telemetry/gnocchi side
 > > > https://github.com/sqlalchemy/alembic/issues/699,
 > > > https://storyboard.openstack.org/#!/story/2008003
 > > >  >  >
 > > >  >  > 3. We encountered the nodeset name conflict with x/tobiko.
 > > > (FIXED)
 > > >  >  > nodeset conflict is resolved now and devstack provides all
 > > > focal nodes now.
 > > >  >  >
 > > >  >  > 4. Bug#1886296. (IN-PROGRESS)
 > > >  >  > pyflakes till 2.1.0 is not compatible with python 3.8 which is
 > > > the default python version
 > > >  >  > on ubuntu focal[1]. With pep8 job running on focal faces the
 > > > issue and fail. We need to bump
 > > >  >  > the pyflakes to 2.1.1 as min version to run pep8 jobs on py3.8.
 > > >  >  > As of now, many projects are using old hacking version so I am
 > > > explicitly adding pyflakes>=2.1.1
 > > >  >  > on the project side[2] but for the long term easy maintenance,
 > > > I am doing it in 'hacking' requirements.txt[3]
 > > >  >  > nd will release a new hacking version. After that project can
 > > > move to new hacking and do not need
 > > >  >  > to maintain pyflakes version compatibility.
 > > >  >  >
 > > >  >  > 5. Bug#1886298. (IN-PROGRESS)
 > > >  >  > 'Markupsafe' 1.0 is not compatible with the latest version of
 > > > setuptools[4],
 > > >  >  > We need to bump the lower-constraint for Markupsafe to 1.1.1 to
 > > > make it work.
 > > >  >  > There are a few more issues[5] with lower-constraint jobs which
 > > > I am debugging.
 > > >  >  >
 > > >  >  >
 > > >  >  > What work to be done on the project side:
 > > >  >  > ================================
 > > >  >  > This goal is more of testing the jobs on focal and fixing bugs
 > > > if any otherwise
 > > >  >  > migrate jobs by switching the nodeset to focal node sets
 > > > defined in devstack.
 > > >  >  >
 > > >  >  > 1. Start a patch in your repo by making depends-on on either of
 > > > below:
 > > >  >  > devstack base patch if you are using only devstack base jobs
 > > > not tempest:
 > > >  >  >
 > > >  >  > Depends-on: https://review.opendev.org/#/c/731207/
 > > >  >  > OR
 > > >  >  > tempest base patch if you are using the tempest base job (like
 > > > devstack-tempest):
 > > >  >  > Depends-on: https://review.opendev.org/#/c/734700/
 > > >  >  >
 > > >  >  > Both have depends-on on the series where I am moving
 > > > unit/functional/doc/cover/nodejs tox jobs to focal. So
 > > >  >  > you can test the complete gate
 > > > jobs(unit/functional/doc/integration) together.
 > > >  >  > This and its base patches -
 > > > https://review.opendev.org/#/c/738328/
 > > >  >  >
 > > >  >  > Example: https://review.opendev.org/#/c/738126/
 > > >  >  >
 > > >  >  > 2. If none of your project jobs override the nodeset then above
 > > > patch will be
 > > >  >  > testing patch(do not merge) otherwise change the nodeset to
 > > > focal.
 > > >  >  > Example: https://review.opendev.org/#/c/737370/
 > > >  >  >
 > > >  >  > 3. If the jobs are defined in branchless repo and override the
 > > > nodeset then you need to override the branches
 > > >  >  > variant to adjust the nodeset so that those jobs run on Focal
 > > > on victoria onwards only. If no nodeset
 > > >  >  > is overridden then devstack being branched and stable base job
 > > > using bionic/xenial will take care of
 > > >  >  > this.
 > > >  >  > Example: https://review.opendev.org/#/c/744056/2
 > > >  >  >
 > > >  >  > 4. If no updates need you can abandon the testing patch (
 > > > https://review.opendev.org/#/c/744341/). If it need
 > > >  >  > updates then modify the same patch with proper commit msg, once
 > > > it pass the gate then remove the Depends-On
 > > >  >  > so that you can merge your patch before base jobs are switched
 > > > to focal. This way we make sure no gate downtime in
 > > >  >  > this migration.
 > > >  >  > Example: https://review.opendev.org/#/c/744056/1..2//COMMIT_MSG
 > > >  >  >
 > > >  >  > Once we finish the testing on projects side and no failure then
 > > > we will merge the devstack and tempest
 > > >  >  > base patches.
 > > >  >  >
 > > >  >  >
 > > >  >  > Important things to note:
 > > >  >  > ===================
 > > >  >  > * Do not forgot to add the story and task link to your patch so
 > > > that we can track it smoothly.
 > > >  >  > * Use gerrit topic 'migrate-to-focal'
 > > >  >  > * Do not backport any of the patches.
 > > >  >  >
 > > >  >  >
 > > >  >  > References:
 > > >  >  > =========
 > > >  >  > Goal doc:
 > > > https://governance.openstack.org/tc/goals/selected/victoria/migrate-ci-cd-jobs-to-ubuntu-focal.html
 > > >  >  > Storyboard tracking:
 > > > https://storyboard.openstack.org/#!/story/2007865
 > > >  >  >
 > > >  >  > [1] https://github.com/PyCQA/pyflakes/issues/367
 > > >  >  > [2] https://review.opendev.org/#/c/739315/
 > > >  >  > [3] https://review.opendev.org/#/c/739334/
 > > >  >  > [4] https://github.com/pallets/markupsafe/issues/116
 > > >  >  > [5]
 > > > https://zuul.opendev.org/t/openstack/build/7ecd9cf100194bc99b3b70fa1e6de032
 > > >  >  >
 > > >  >  > -gmann
 > > >  >  >
 > > >  >  >
 > > >  >
 > > >  >
 > > >
 > >
 > >
 > >
 > 


From sean.mcginnis at gmx.com  Fri Sep 11 12:43:24 2020
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Fri, 11 Sep 2020 07:43:24 -0500
Subject: [cinder] propose Lucio Seki for cinder core
In-Reply-To: <2f42f092-5037-5f9d-48d6-cc52097f2479@gmail.com>
References: <2f42f092-5037-5f9d-48d6-cc52097f2479@gmail.com>
Message-ID: <e6bbc7c4-34fa-b50f-452f-53798617fbf2@gmx.com>

> Lucio Seki (lseki on IRC) has been very active this cycle doing
> reviews, answering questions in IRC, and participating in the Cinder
> weekly meetings and at the midcycles.  He's been particularly thorough
> and helpful in his reviews of backend drivers, and has also been
> helpful in giving pointers to new driver maintainers who are setting
> up third party CI for their drivers.  Having Lucio as a core reviewer
> will help improve the team's review bandwidth without sacrificing
> review quality.
>
> In the absence of objections, I'll add Lucio to the core team just
> before the next Cinder team meeting (Wednesday, 16 September at 1400
> UTC in #openstack-meeting-alt).  Please communicate any concerns to me
> before that time.
>
> cheers,
> brian
>
+1



From rajatdhasmana at gmail.com  Fri Sep 11 12:58:22 2020
From: rajatdhasmana at gmail.com (Rajat Dhasmana)
Date: Fri, 11 Sep 2020 18:28:22 +0530
Subject: [cinder] propose Lucio Seki for cinder core
In-Reply-To: <e6bbc7c4-34fa-b50f-452f-53798617fbf2@gmx.com>
References: <2f42f092-5037-5f9d-48d6-cc52097f2479@gmail.com>
 <e6bbc7c4-34fa-b50f-452f-53798617fbf2@gmx.com>
Message-ID: <CAPhBjvbqm0zUxE19hEDBqtrMaE3TA52NxvaYE+_02yX=1_uq_A@mail.gmail.com>

+1

On Fri, Sep 11, 2020, 6:17 PM Sean McGinnis <sean.mcginnis at gmx.com> wrote:

> > Lucio Seki (lseki on IRC) has been very active this cycle doing
> > reviews, answering questions in IRC, and participating in the Cinder
> > weekly meetings and at the midcycles.  He's been particularly thorough
> > and helpful in his reviews of backend drivers, and has also been
> > helpful in giving pointers to new driver maintainers who are setting
> > up third party CI for their drivers.  Having Lucio as a core reviewer
> > will help improve the team's review bandwidth without sacrificing
> > review quality.
> >
> > In the absence of objections, I'll add Lucio to the core team just
> > before the next Cinder team meeting (Wednesday, 16 September at 1400
> > UTC in #openstack-meeting-alt).  Please communicate any concerns to me
> > before that time.
> >
> > cheers,
> > brian
> >
> +1
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200911/eabacc1e/attachment.html>

From sean.mcginnis at gmx.com  Fri Sep 11 13:03:33 2020
From: sean.mcginnis at gmx.com (Sean McGinnis)
Date: Fri, 11 Sep 2020 08:03:33 -0500
Subject: [release] Release countdown for week R-4 Sept 14 - 18
Message-ID: <20200911130333.GB1087594@sm-workstation>

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

We just passed feature freeze! Until release branches are cut, you
should stop accepting featureful changes to deliverables following the
cycle-with-rc release model, or to libraries. Exceptions should be
discussed on separate threads on the mailing-list, and feature freeze
exceptions approved by the team's PTL.

Focus should be on finding and fixing release-critical bugs, so that
release candidates and final versions of the victoria deliverables can be
proposed, well ahead of the final victoria release date.

General Information
-------------------

We are still finishing up processing a few release requests, but the
victoria release requirements are now frozen. If new library releases are
needed to fix release-critical bugs in victoria, you must request a
Requirements Freeze Exception (RFE) from the requirements team before we
can do a new release to avoid having something released in victoria that
is not actually usable. This is done by posting to the openstack-discuss
mailing list with a subject line similar to:

        [$PROJECT][requirements] RFE requested for $PROJECT_LIB

Include justification/reasoning for why a RFE is needed for this lib.
If/when the requirements team OKs the post-freeze update, we can then
process a new release.

A soft String freeze is now in effect, in order to let the I18N team do the
translation work in good conditions. In Horizon and the various dashboard
plugins, you should stop accepting changes that modify user-visible
strings. Exceptions should be discussed on the mailing-list. By
September 24 this will become a hard string freeze, with no changes
in user-visible strings allowed.

Actions
-------

stable/victoria branches should be created soon for all not-already-branched
libraries. You should expect 2-3 changes to be proposed for each: a
.gitreview update, a reno update (skipped for projects not using reno),
and a tox.ini constraints URL update. Please review those in priority
so that the branch can be functional ASAP.

The Prelude section of reno release notes is rendered as the top level
overview for the release. Any important overall messaging for victoria
changes should be added there to make sure the consumers of your release
notes see them.

Finally, if you haven't proposed victoria cycle-highlights yet, you are
already late to the party. Please see
http://lists.openstack.org/pipermail/openstack-discuss/2020-September/016941.html
for details.

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

RC1 deadline: September 24 (R-3)
Final Victoria release: October 14
Open Infra Summit: October 19-23
Wallaby PTG: October 26-30


From gmann at ghanshyammann.com  Fri Sep 11 13:08:39 2020
From: gmann at ghanshyammann.com (Ghanshyam Mann)
Date: Fri, 11 Sep 2020 08:08:39 -0500
Subject: [oslo][release][requirement] FFE request for Oslo lib
In-Reply-To: <1747608f93e.d7ec085f28282.4985395579846058200@ghanshyammann.com>
References: <1746e64d702.ee80b0bc1249.5426348472779199647@ghanshyammann.com>
 <bc93768b-cf66-d66b-5fc6-78ac07797991@nemebean.com>
 <20200909192543.b2d2ksruoqtbgcfy@mthode.org>
 <174746eb120.1229d07d224552.356509349559116522@ghanshyammann.com>
 <1747608f93e.d7ec085f28282.4985395579846058200@ghanshyammann.com>
Message-ID: <1747d4839a4.10505a96f108873.8961642381266139796@ghanshyammann.com>

 ---- On Wed, 09 Sep 2020 22:22:13 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 >  ---- On Wed, 09 Sep 2020 14:54:05 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
 >  > 
 >  >  ---- On Wed, 09 Sep 2020 14:25:43 -0500 Matthew Thode <mthode at mthode.org> wrote ----
 >  >  > On 20-09-09 12:04:51, Ben Nemec wrote:
 >  >  > > 
 >  >  > > On 9/8/20 10:45 AM, Ghanshyam Mann wrote:
 >  >  > > > Hello Team,
 >  >  > > > 
 >  >  > > > This is regarding FFE for Focal migration work. As planned, we have to move the Victoria testing to Focal and
 >  >  > > > base job switch is planned to be switched by today[1].
 >  >  > > > 
 >  >  > > > There are few oslo lib need work (especially tox job-based testing not user-facing changes) to pass on Focal
 >  >  > > > - https://review.opendev.org/#/q/topic:migrate-to-focal-oslo+(status:open+OR+status:merged)
 >  >  > > > 
 >  >  > > > If we move the base tox jobs to Focal then these lib victoria gates (especially lower-constraint job) will be failing.
 >  >  > > > We can either do these as FFE or backport (as this is lib own CI fixes only) later once the victoria branch is open.
 >  >  > > > Opinion?
 >  >  > > 
 >  >  > > As I noted in the meeting, if we have to do this to keep the gates working
 >  >  > > then I'd rather do it as an FFE than have to backport all of the relevant
 >  >  > > patches. IMHO we should only decline this FFE if we are going to also change
 >  >  > > our statement of support for Python/Ubuntu in Victoria.
 >  >  > > 
 >  >  > > > 
 >  >  > > > [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017060.html
 >  >  > > > 
 >  >  > > > -gmann
 >  >  > > > 
 >  >  > > > 
 >  >  > > 
 >  >  > 
 >  >  > https://review.opendev.org/#/c/750089 seems like the only functional
 >  >  > change.  It has my ACK with my requirements hat on.
 > 
 > NOTE: There is one py3.8 bug fix also merged in oslo.uitls which is not yet released. This made py3.8 job voting in oslo.utils gate.
 > - https://review.opendev.org/#/c/750216/
 > 
 > Rest all l-c bump are now passing on Focal
 > - https://review.opendev.org/#/q/topic:migrate-to-focal-oslo+(status:open+OR+status:merged)

All the patches are merged now, requesting to reconsider this FEE so that we can avoid more delay in this.

-gmann

 > 
 > -gmann
 > 
 >  > 
 >  > yeah, and this one changing one test with #noqa  - https://review.opendev.org/#/c/744323/5
 >  > The rest all are l-c bump.
 >  > 
 >  > Also all the tox base jobs are migrated to Focal now.
 >  > - http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017136.html
 >  > 
 >  >  > 
 >  >  > -- 
 >  >  > Matthew Thode
 >  >  > 
 >  > 
 >  > 
 > 


From senrique at redhat.com  Fri Sep 11 13:11:38 2020
From: senrique at redhat.com (Sofia Enriquez)
Date: Fri, 11 Sep 2020 10:11:38 -0300
Subject: [cinder] propose Lucio Seki for cinder core
In-Reply-To: <2f42f092-5037-5f9d-48d6-cc52097f2479@gmail.com>
References: <2f42f092-5037-5f9d-48d6-cc52097f2479@gmail.com>
Message-ID: <CANtmtpGmzZrV1oP_PuDW1YOaSdYPRgp6sJ3apYzcsRi8R0Ahzw@mail.gmail.com>

Congratulations Lucio 🍻

On Thu, Sep 10, 2020 at 11:03 PM Brian Rosmaita <rosmaita.fossdev at gmail.com>
wrote:

> Lucio Seki (lseki on IRC) has been very active this cycle doing reviews,
> answering questions in IRC, and participating in the Cinder weekly
> meetings and at the midcycles.  He's been particularly thorough and
> helpful in his reviews of backend drivers, and has also been helpful in
> giving pointers to new driver maintainers who are setting up third party
> CI for their drivers.  Having Lucio as a core reviewer will help improve
> the team's review bandwidth without sacrificing review quality.
>
> In the absence of objections, I'll add Lucio to the core team just
> before the next Cinder team meeting (Wednesday, 16 September at 1400 UTC
> in #openstack-meeting-alt).  Please communicate any concerns to me
> before that time.
>
> cheers,
> brian
>
>

-- 

L. Sofía Enriquez

she/her

Associate Software Engineer

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

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

From melwittt at gmail.com  Fri Sep 11 14:36:10 2020
From: melwittt at gmail.com (melanie witt)
Date: Fri, 11 Sep 2020 07:36:10 -0700
Subject: "openstack server list" takes 30s
In-Reply-To: <MWHPR08MB23822F7953D333E26AB0234ABD240@MWHPR08MB2382.namprd08.prod.outlook.com>
References: <MWHPR08MB23822F7953D333E26AB0234ABD240@MWHPR08MB2382.namprd08.prod.outlook.com>
Message-ID: <36dac474-5d59-1756-ba80-32562b345e2b@gmail.com>

On 9/10/20 21:15, Tony Liu wrote:
> Hi,
> 
> I built a Ussuri cluster with 3 controllers and 5 compute nodes.
> OpenStack CLI ran pretty fast at the beginning, but gets slower
> over time along with increased workloads. Right now, it takes
> about 30s to list 10 VMs. The CPU, memory and disk usage are on
> those 3 controllers are all in the range. I understand there are
> many API calls happening behind CLI. I'd like to figure out how
> this 30s is consumed, which call is the killer.
> Any guidance or hint would be helpful.

To see the individual calls made by OSC and troubleshoot the reason for 
the slowness, you can use the --debug option:

$ openstack --debug server list

Besides that, there is something that I know of that can be slow: the 
flavor and image name lookup. This happens if you have a Large Number of 
flavors and/or images. There are a couple of options you can use to make 
this faster:

$ openstack server list --name-lookup-one-by-one

This will make OSC lookup flavors and images only once per unique 
flavor/image in the list and uses the cached value for subsequent 
appearances in the list [1]. I think this should have been made the 
default behavior when it was introduced but it was nacked and accepted 
only as opt-in.

The other option skips name lookup altogether and shows UUIDs only 
instead of names [2]:

$ openstack server list --no-name-lookup

Hope this helps,
-melanie

[1] 
https://docs.openstack.org/python-openstackclient/ussuri/cli/command-objects/server.html#cmdoption-openstack-server-list-name-lookup-one-by-one
[2] 
https://docs.openstack.org/python-openstackclient/ussuri/cli/command-objects/server.html#cmdoption-openstack-server-list-n


From eblock at nde.ag  Fri Sep 11 14:58:42 2020
From: eblock at nde.ag (Eugen Block)
Date: Fri, 11 Sep 2020 14:58:42 +0000
Subject: "openstack server list" takes 30s
In-Reply-To: <36dac474-5d59-1756-ba80-32562b345e2b@gmail.com>
References: <MWHPR08MB23822F7953D333E26AB0234ABD240@MWHPR08MB2382.namprd08.prod.outlook.com>
 <36dac474-5d59-1756-ba80-32562b345e2b@gmail.com>
Message-ID: <20200911145842.Horde.i6jVJiPIiSx8MrwK2wsZPJX@webmail.nde.ag>

Hi,

we had this a couple of years ago in our Ocata cloud, in our case  
memcached was not configured correctly. Since you might be  
experiencing another memcached issue according to your other thread  
[1] it could be worth double-checking your memcache configuration.

Regards,
Eugen

[1]  
http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017196.html

Zitat von melanie witt <melwittt at gmail.com>:

> On 9/10/20 21:15, Tony Liu wrote:
>> Hi,
>>
>> I built a Ussuri cluster with 3 controllers and 5 compute nodes.
>> OpenStack CLI ran pretty fast at the beginning, but gets slower
>> over time along with increased workloads. Right now, it takes
>> about 30s to list 10 VMs. The CPU, memory and disk usage are on
>> those 3 controllers are all in the range. I understand there are
>> many API calls happening behind CLI. I'd like to figure out how
>> this 30s is consumed, which call is the killer.
>> Any guidance or hint would be helpful.
>
> To see the individual calls made by OSC and troubleshoot the reason  
> for the slowness, you can use the --debug option:
>
> $ openstack --debug server list
>
> Besides that, there is something that I know of that can be slow:  
> the flavor and image name lookup. This happens if you have a Large  
> Number of flavors and/or images. There are a couple of options you  
> can use to make this faster:
>
> $ openstack server list --name-lookup-one-by-one
>
> This will make OSC lookup flavors and images only once per unique  
> flavor/image in the list and uses the cached value for subsequent  
> appearances in the list [1]. I think this should have been made the  
> default behavior when it was introduced but it was nacked and  
> accepted only as opt-in.
>
> The other option skips name lookup altogether and shows UUIDs only  
> instead of names [2]:
>
> $ openstack server list --no-name-lookup
>
> Hope this helps,
> -melanie
>
> [1]  
> https://docs.openstack.org/python-openstackclient/ussuri/cli/command-objects/server.html#cmdoption-openstack-server-list-name-lookup-one-by-one
> [2]  
> https://docs.openstack.org/python-openstackclient/ussuri/cli/command-objects/server.html#cmdoption-openstack-server-list-n





From gouthampravi at gmail.com  Fri Sep 11 15:39:52 2020
From: gouthampravi at gmail.com (Goutham Pacha Ravi)
Date: Fri, 11 Sep 2020 08:39:52 -0700
Subject: [cinder] propose Lucio Seki for cinder core
In-Reply-To: <2f42f092-5037-5f9d-48d6-cc52097f2479@gmail.com>
References: <2f42f092-5037-5f9d-48d6-cc52097f2479@gmail.com>
Message-ID: <CAKSuTPYS_ruU39Y2dAdZQYFOb3gX1Aj3fkyXiSTrFDHdpgHfMg@mail.gmail.com>

A +0.02 from an occasional lurker...
Great job Lucio!


On Thu, Sep 10, 2020 at 6:57 PM Brian Rosmaita <rosmaita.fossdev at gmail.com>
wrote:

> Lucio Seki (lseki on IRC) has been very active this cycle doing reviews,
> answering questions in IRC, and participating in the Cinder weekly
> meetings and at the midcycles.  He's been particularly thorough and
> helpful in his reviews of backend drivers, and has also been helpful in
> giving pointers to new driver maintainers who are setting up third party
> CI for their drivers.  Having Lucio as a core reviewer will help improve
> the team's review bandwidth without sacrificing review quality.
>
> In the absence of objections, I'll add Lucio to the core team just
> before the next Cinder team meeting (Wednesday, 16 September at 1400 UTC
> in #openstack-meeting-alt).  Please communicate any concerns to me
> before that time.
>
> cheers,
> brian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200911/e07a2101/attachment.html>

From gouthampravi at gmail.com  Fri Sep 11 15:56:55 2020
From: gouthampravi at gmail.com (Goutham Pacha Ravi)
Date: Fri, 11 Sep 2020 08:56:55 -0700
Subject: [manila][release] Some feature patches will merge today
Message-ID: <CAKSuTPYsR4oxwkUjiNR0yHfrHRU6+jiuwG_bzYMQhu3NsW5a=g@mail.gmail.com>

Hello Stackers,

As is unusual, we have found ourselves with a few unmerged feature patches
at the wrong side of the feature freeze:

[Container driver] Adds share and share server migration:
https://review.opendev.org/740831/
[NetApp] Enables configuring NFS transfer limits:
https://review.opendev.org/746568
[NetApp] Add support for share server migration:
https://review.opendev.org/747048/
[NetApp] Adding support for Adaptive QoS in NetApp driver with dhss false:
https://review.opendev.org/740532/

These patches have been getting review attention late in the cycle, and
were caught up in CI failures and code collisions. The code changes above
are isolated within driver modules in the code that are explicitly
configured/optionally enabled by deployers. These changes do not:

- introduce any new library dependencies to manila, or
- modify the API, DB, RPC, driver interface layers
- introduce new requirements into the client library (python-manilaclient)

They do introduce translatable exception strings - however, manila has not
received translation updates in the past. We're looking to get these merged
today. Hope that's okay - do let me know of any gotchas.

--
Goutham Pacha Ravi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200911/ec4ac5c7/attachment.html>

From jungleboyj at gmail.com  Fri Sep 11 16:13:45 2020
From: jungleboyj at gmail.com (Jay Bryant)
Date: Fri, 11 Sep 2020 11:13:45 -0500
Subject: [cinder] propose Lucio Seki for cinder core
In-Reply-To: <2f42f092-5037-5f9d-48d6-cc52097f2479@gmail.com>
References: <2f42f092-5037-5f9d-48d6-cc52097f2479@gmail.com>
Message-ID: <46054156-fe1c-0b16-8a27-cb6495da986a@gmail.com>

+2 from me.  Appreciate the energy and effort the Lucio has brought to 
the team lately!

On 9/10/2020 8:51 PM, Brian Rosmaita wrote:
> Lucio Seki (lseki on IRC) has been very active this cycle doing 
> reviews, answering questions in IRC, and participating in the Cinder 
> weekly meetings and at the midcycles.  He's been particularly thorough 
> and helpful in his reviews of backend drivers, and has also been 
> helpful in giving pointers to new driver maintainers who are setting 
> up third party CI for their drivers.  Having Lucio as a core reviewer 
> will help improve the team's review bandwidth without sacrificing 
> review quality.
>
> In the absence of objections, I'll add Lucio to the core team just 
> before the next Cinder team meeting (Wednesday, 16 September at 1400 
> UTC in #openstack-meeting-alt).  Please communicate any concerns to me 
> before that time.
>
> cheers,
> brian
>


From kennelson11 at gmail.com  Fri Sep 11 16:40:29 2020
From: kennelson11 at gmail.com (Kendall Nelson)
Date: Fri, 11 Sep 2020 09:40:29 -0700
Subject: [TC][PTG] Virtual PTG Planning
In-Reply-To: <CAJ6yrQh-OK+GMtzpHBJ4Kj+2jhZ7VjOumxc_meEd02hhfBXazw@mail.gmail.com>
References: <CAJ6yrQh-OK+GMtzpHBJ4Kj+2jhZ7VjOumxc_meEd02hhfBXazw@mail.gmail.com>
Message-ID: <CAJ6yrQjTMhWbPdLOQt2YwGYwYHdPpsGpuGU7LkM0pwvj_rDJdw@mail.gmail.com>

Reminder! We need your availability responses ASAP because the deadline to
sign up for the PTG is today!

-Kendall (diablo_rojo)

On Fri, Sep 4, 2020 at 10:58 AM Kendall Nelson <kennelson11 at gmail.com>
wrote:

> Hello!
>
> So as you might have seen, the deadline to sign up for PTG time by the end
> of next week. To coordinate our time to meet as the TC, please fill out the
> poll[1] that Mohammed kindly put together for us. *We need responses by
> EOD Thursday September 10th* so that we can book the time in the
> ethercalc and fill out the survey to reserve our space before the deadline.
>
> Also, I created this planning etherpad [2] to start collecting ideas for
> discussion topics!
>
> Can't wait to see you all there!
>
> -Kendall & Mohammed
>
> [1] https://doodle.com/poll/hkbg44da2udxging
> [2] https://etherpad.opendev.org/p/tc-wallaby-ptg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200911/58e9e112/attachment.html>

From t.schulze at tu-berlin.de  Fri Sep 11 17:08:11 2020
From: t.schulze at tu-berlin.de (thoralf schulze)
Date: Fri, 11 Sep 2020 19:08:11 +0200
Subject: [sdk] openstacksdk vs. server groups
Message-ID: <a66deb98-5258-67e5-27df-904e814d3dc8@tu-berlin.de>

hi there,

the current openstack-sdk crashes while trying to process instances that
are part of a server group. to give an example:
one of our instances shows up in the output of "openstack-inventory
--list --debug" as

[…]
REQ: curl -g -i -X GET
https://redacted:8774/v2.1/servers/352307ba-0c06-43e5-ba21-467ec25a4a2e
-H "OpenStack-API-Version: compute 2.72" -H "User-Agent:
openstacksdk/0.49.0 keystoneauth1/4.2.1 python-requests/2.
22.0 CPython/3.8.2" -H "X-Auth-Token: redacted" -H
"X-OpenStack-Nova-API-Version: 2.72"
RESP: [200] Connection: Keep-Alive Content-Length: 2024 Content-Type:
application/json Date: Fri, 11 Sep 2020 15:22:14 GMT Keep-Alive:
timeout=5, max=92 OpenStack-API-Version: compute 2.72 Server:
Apache/2.4.29 (Ubuntu) Vary: Op
enStack-API-Version,X-OpenStack-Nova-API-Version
X-OpenStack-Nova-API-Version: 2.72 x-compute-request-id:
req-54078034-3b9e-42bc-afeb-c9c2288db568 x-openstack-request-id:
req-54078034-3b9e-42bc-afeb-c9c2288db568
RESP BODY: {"server": {"id": "352307ba-0c06-43e5-ba21-467ec25a4a2e",
"name": "dss-test-aaai2hq3gmjc-node-0", "status": "ACTIVE", "tenant_id":
"56c37bc705364d34a5f423c531d9e1a7", "user_id":
"120258b9dbc7831140ed30b57366fe91feaa77608c7a118da9cf0f6288f1886b",
"metadata": {}, "hostId":
"16e275df317b4699aa6fdb52b437295c4e3beb83b5e4d15276314660", "image":
{"id": "41bb79e0-0962-4162-b9c5-ff178ab61218", "links": [{"rel":
"bookmark", "href":
"https://redacted/images/41bb79e0-0962-4162-b9c5-ff178ab61218"}]},
"flavor": {"vcpus": 8, "ram": 16384, "disk": 100, "ephemeral": 0,
"swap": 0, "original_name": "tx.medium", "extra_specs":
{"hw:mem_page_size": "large", "hw:watchdog_action": "reset",
"hw_rng:allowed": "true", "hw_rng:rate_bytes": "24",
"hw_rng:rate_period": "5000", "trait:CUSTOM_DC_CLASS_TEST":
"required"}}, "created": "2020-07-10T07:09:48Z", "updated":
"2020-07-10T07:09:59Z", "addresses": {"dss-test": [{"version": 4,
"addr": "10.0.0.42", "OS-EXT-IPS:type": "fixed",
"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:62:3e:69"}, {"version": 4, "addr":
"10.176.1.154", "OS-EXT-IPS:type": "floating",
"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:62:3e:69"}]}, "accessIPv4": "",
"accessIPv6": "", "links": [{"rel": "self", "href":
"https://redacted/v2.1/servers/352307ba-0c06-43e5-ba21-467ec25a4a2e"},
{"rel": "bookmark", "href":
"https://redacted/servers/352307ba-0c06-43e5-ba21-467ec25a4a2e"}],
"OS-DCF:diskConfig": "MANUAL", "progress": 0,
"OS-EXT-AZ:availability_zone": "BARZ", "config_drive": "", "key_name":
null, "OS-SRV-USG:launched_at": "2020-07-10T07:09:58.000000",
"OS-SRV-USG:terminated_at": null, "security_groups": [{"name":
"dss-test-aaai2hq3gmjc-secgroup_kube_minion-cjco6vmpgs6j"}],
"OS-EXT-STS:task_state": null, "OS-EXT-STS:vm_state": "active",
"OS-EXT-STS:power_state": 1, "os-extended-volumes:volumes_attached": [],
"locked": false, "description": null, "tags": [],
"trusted_image_certificates": null, "server_groups":
["2b9dfdd8-0a5e-45ec-af07-1a0437a7f61e"]}}

due to the value of "server_groups" not being a dict,
openstack/resource.py crashes while trying to process this instance:

  File
"/home/ubuntu/.local/lib/python3.8/site-packages/openstack/resource.py",
line 82, in _convert_type
    return data_type(value)
ValueError: dictionary update sequence element #0 has length 1; 2 is
required

is server_groups really supposed to be just a list of uuids? having it
dealt with in a manner akin to security_groups seems to be an obvious
choice …

thank you very much & with kind regards,
t.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200911/a3b78012/attachment-0001.sig>

From artem.goncharov at gmail.com  Fri Sep 11 17:23:07 2020
From: artem.goncharov at gmail.com (Artem Goncharov)
Date: Fri, 11 Sep 2020 19:23:07 +0200
Subject: [sdk] openstacksdk vs. server groups
In-Reply-To: <a66deb98-5258-67e5-27df-904e814d3dc8@tu-berlin.de>
References: <a66deb98-5258-67e5-27df-904e814d3dc8@tu-berlin.de>
Message-ID: <8883AE9B-B1AB-4192-8CE7-B78BE70F41BF@gmail.com>

Hi Thoralf,

This issue is already addressed (see https://review.opendev.org/#/c/749381/ <https://review.opendev.org/#/c/749381/>) and will be fixed in next release of SDK (pretty soon).

Regards,
Artem

> On 11. Sep 2020, at 19:08, thoralf schulze <t.schulze at tu-berlin.de> wrote:
> 
> hi there,
> 
> the current openstack-sdk crashes while trying to process instances that
> are part of a server group. to give an example:
> one of our instances shows up in the output of "openstack-inventory
> --list --debug" as
> 
> […]
> REQ: curl -g -i -X GET
> https://redacted:8774/v2.1/servers/352307ba-0c06-43e5-ba21-467ec25a4a2e
> -H "OpenStack-API-Version: compute 2.72" -H "User-Agent:
> openstacksdk/0.49.0 keystoneauth1/4.2.1 python-requests/2.
> 22.0 CPython/3.8.2" -H "X-Auth-Token: redacted" -H
> "X-OpenStack-Nova-API-Version: 2.72"
> RESP: [200] Connection: Keep-Alive Content-Length: 2024 Content-Type:
> application/json Date: Fri, 11 Sep 2020 15:22:14 GMT Keep-Alive:
> timeout=5, max=92 OpenStack-API-Version: compute 2.72 Server:
> Apache/2.4.29 (Ubuntu) Vary: Op
> enStack-API-Version,X-OpenStack-Nova-API-Version
> X-OpenStack-Nova-API-Version: 2.72 x-compute-request-id:
> req-54078034-3b9e-42bc-afeb-c9c2288db568 x-openstack-request-id:
> req-54078034-3b9e-42bc-afeb-c9c2288db568
> RESP BODY: {"server": {"id": "352307ba-0c06-43e5-ba21-467ec25a4a2e",
> "name": "dss-test-aaai2hq3gmjc-node-0", "status": "ACTIVE", "tenant_id":
> "56c37bc705364d34a5f423c531d9e1a7", "user_id":
> "120258b9dbc7831140ed30b57366fe91feaa77608c7a118da9cf0f6288f1886b",
> "metadata": {}, "hostId":
> "16e275df317b4699aa6fdb52b437295c4e3beb83b5e4d15276314660", "image":
> {"id": "41bb79e0-0962-4162-b9c5-ff178ab61218", "links": [{"rel":
> "bookmark", "href":
> "https://redacted/images/41bb79e0-0962-4162-b9c5-ff178ab61218"}]},
> "flavor": {"vcpus": 8, "ram": 16384, "disk": 100, "ephemeral": 0,
> "swap": 0, "original_name": "tx.medium", "extra_specs":
> {"hw:mem_page_size": "large", "hw:watchdog_action": "reset",
> "hw_rng:allowed": "true", "hw_rng:rate_bytes": "24",
> "hw_rng:rate_period": "5000", "trait:CUSTOM_DC_CLASS_TEST":
> "required"}}, "created": "2020-07-10T07:09:48Z", "updated":
> "2020-07-10T07:09:59Z", "addresses": {"dss-test": [{"version": 4,
> "addr": "10.0.0.42", "OS-EXT-IPS:type": "fixed",
> "OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:62:3e:69"}, {"version": 4, "addr":
> "10.176.1.154", "OS-EXT-IPS:type": "floating",
> "OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:62:3e:69"}]}, "accessIPv4": "",
> "accessIPv6": "", "links": [{"rel": "self", "href":
> "https://redacted/v2.1/servers/352307ba-0c06-43e5-ba21-467ec25a4a2e"},
> {"rel": "bookmark", "href":
> "https://redacted/servers/352307ba-0c06-43e5-ba21-467ec25a4a2e"}],
> "OS-DCF:diskConfig": "MANUAL", "progress": 0,
> "OS-EXT-AZ:availability_zone": "BARZ", "config_drive": "", "key_name":
> null, "OS-SRV-USG:launched_at": "2020-07-10T07:09:58.000000",
> "OS-SRV-USG:terminated_at": null, "security_groups": [{"name":
> "dss-test-aaai2hq3gmjc-secgroup_kube_minion-cjco6vmpgs6j"}],
> "OS-EXT-STS:task_state": null, "OS-EXT-STS:vm_state": "active",
> "OS-EXT-STS:power_state": 1, "os-extended-volumes:volumes_attached": [],
> "locked": false, "description": null, "tags": [],
> "trusted_image_certificates": null, "server_groups":
> ["2b9dfdd8-0a5e-45ec-af07-1a0437a7f61e"]}}
> 
> due to the value of "server_groups" not being a dict,
> openstack/resource.py crashes while trying to process this instance:
> 
>  File
> "/home/ubuntu/.local/lib/python3.8/site-packages/openstack/resource.py",
> line 82, in _convert_type
>    return data_type(value)
> ValueError: dictionary update sequence element #0 has length 1; 2 is
> required
> 
> is server_groups really supposed to be just a list of uuids? having it
> dealt with in a manner akin to security_groups seems to be an obvious
> choice …
> 
> thank you very much & with kind regards,
> t.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200911/681714f0/attachment.html>

From fungi at yuggoth.org  Fri Sep 11 17:47:05 2020
From: fungi at yuggoth.org (Jeremy Stanley)
Date: Fri, 11 Sep 2020 17:47:05 +0000
Subject: [all][tc][goals] Migrate CI/CD jobs to new Ubuntu LTS Focal:
 Week R-4 Update
In-Reply-To: <447841d8d8560f96475cb0a275e34464ece6352b.camel@redhat.com>
References: <17468f8f785.1123a07e6307801.3844845549431858647@ghanshyammann.com>
 <1746feef403.c41c848411058.2421030943223377212@ghanshyammann.com>
 <1747442027f.bb3f3d1823475.212800600164097649@ghanshyammann.com>
 <447841d8d8560f96475cb0a275e34464ece6352b.camel@redhat.com>
Message-ID: <20200911174705.eu44wamtoeybsikw@yuggoth.org>

On 2020-09-11 13:50:57 +0200 (+0200), Michał Dulko wrote:
[...]
> We're in a bit of a pickle here. So with kuryr-kubernetes we aim
> to keep lower-constraints on the versions that can be found in
> CentOS/RHEL8 and seems like cffi 1.11.5 won't compile with Python
> 3.8. What should we do here? Is such assumption even possible
> given broader OpenStack assumptions?
[...]

To rehash and summarize my opinion from our lengthy IRC discussion
in the #openstack-infra channel yesterday, I agree that it makes
sense to run lower-constraints jobs on the lowest Python interpreter
release listed in our tested runtimes for that cycle. However, you
also have to take into account the platform(s) which cause that
interpreter version to be included. Basically if we're going to
standardize Python 3.6 jobs of any kind in Victoria those should be
running on CentOS 8 (which is in our tested runtimes for Victoria
and why we included Python 3.6 at all), *not* on Ubuntu Bionic
(which is not included in our tested runtimes for Victoria).
Otherwise we're stuck supporting ubuntu-bionic images for testing
stable/victoria well into the future even though we didn't
technically list it as a target platform.

This gets more complicated though. We've, as a community overall,
tried repeatedly to pretend we're not testing specific platforms,
and instead just testing representative Python versions. Except we
don't actually test with real Python versions we test with the
patched Python interpreters shipped in distros. So our job names
pretend they're Python version specific for the most part, when to
actually meet the intent of our tested runtimes we really do need
distro-specific jobs. We test Python 3.6 for stable/ussuri changes
because Ubuntu Bionic is a tested runtime platform for Ussuri and
that's the default Python 3 it ships, but Python 3.6 is listed in
Victoria for the benefit of CentOS 8 not Ubuntu Bionic, so we need a
different py36 job on each branch, running on different distros.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200911/9a11a3fb/attachment.sig>

From pramchan at yahoo.com  Fri Sep 11 18:06:09 2020
From: pramchan at yahoo.com (prakash RAMCHANDRAN)
Date: Fri, 11 Sep 2020 18:06:09 +0000 (UTC)
Subject: [InteropWG] Seeking ideas for InteropWG  Branding  for Open Infra
References: <1398359147.1271387.1599847569117.ref@mail.yahoo.com>
Message-ID: <1398359147.1271387.1599847569117@mail.yahoo.com>

Hi all,
Please add your ideas for discussions for Forum
https://etherpad.opendev.org/p/2020-Wallaby-interop-brainstorming

Since any Interop case, it's best presented by PTLs their requirments, like to invite Ironic/metal3/MaaS and Container Projects(Zun,kuryr, magnum, kolla...) to help us define the new Branding strategy for Open Infra projects like (Airship, Starlingx, Kata, Zuul, Openlabs ...)
Note we see one opportunity coming out of BareMetal as a Service for Ironic routed through Metal3 which is now a CNCF Sandbox project.
The other we see OpenInfa-ready-k8s-container and/or based on Zun- CRI (Docker, Containerd, Kata...), CNI (kuryr) & CSI (?) & COE as Magnum

Please add your ideas and time you may need for us to go over these emerging ideas for re-imagining clusters in Open Infra with Baremetal as well VM Nodes over Private & Public clouds.
ThanksFor InteropWGPrakash

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200911/882972dd/attachment.html>

From alex.williamson at redhat.com  Thu Sep 10 18:02:44 2020
From: alex.williamson at redhat.com (Alex Williamson)
Date: Thu, 10 Sep 2020 12:02:44 -0600
Subject: device compatibility interface for live migration with assigned
 devices
In-Reply-To: <7cebcb6c8d1a1452b43e8358ee6ee18a150a0238.camel@redhat.com>
References: <20200818113652.5d81a392.cohuck@redhat.com>
 <20200820003922.GE21172@joy-OptiPlex-7040>
 <20200819212234.223667b3@x1.home>
 <20200820031621.GA24997@joy-OptiPlex-7040>
 <20200825163925.1c19b0f0.cohuck@redhat.com>
 <20200826064117.GA22243@joy-OptiPlex-7040>
 <20200828154741.30cfc1a3.cohuck@redhat.com>
 <8f5345be73ebf4f8f7f51d6cdc9c2a0d8e0aa45e.camel@redhat.com>
 <20200831044344.GB13784@joy-OptiPlex-7040>
 <20200908164130.2fe0d106.cohuck@redhat.com>
 <20200909021308.GA1277@joy-OptiPlex-7040>
 <20200910143822.2071eca4.cohuck@redhat.com>
 <7cebcb6c8d1a1452b43e8358ee6ee18a150a0238.camel@redhat.com>
Message-ID: <20200910120244.71e7b630@w520.home>

On Thu, 10 Sep 2020 13:50:11 +0100
Sean Mooney <smooney at redhat.com> wrote:

> On Thu, 2020-09-10 at 14:38 +0200, Cornelia Huck wrote:
> > On Wed, 9 Sep 2020 10:13:09 +0800
> > Yan Zhao <yan.y.zhao at intel.com> wrote:
> >   
> > > > > still, I'd like to put it more explicitly to make ensure it's not missed:
> > > > > the reason we want to specify compatible_type as a trait and check
> > > > > whether target compatible_type is the superset of source
> > > > > compatible_type is for the consideration of backward compatibility.
> > > > > e.g.
> > > > > an old generation device may have a mdev type xxx-v4-yyy, while a newer
> > > > > generation  device may be of mdev type xxx-v5-yyy.
> > > > > with the compatible_type traits, the old generation device is still
> > > > > able to be regarded as compatible to newer generation device even their
> > > > > mdev types are not equal.    
> > > > 
> > > > If you want to support migration from v4 to v5, can't the (presumably
> > > > newer) driver that supports v5 simply register the v4 type as well, so
> > > > that the mdev can be created as v4? (Just like QEMU versioned machine
> > > > types work.)    
> > > 
> > > yes, it should work in some conditions.
> > > but it may not be that good in some cases when v5 and v4 in the name string
> > > of mdev type identify hardware generation (e.g. v4 for gen8, and v5 for
> > > gen9)
> > > 
> > > e.g.
> > > (1). when src mdev type is v4 and target mdev type is v5 as
> > > software does not support it initially, and v4 and v5 identify hardware
> > > differences.  
> > 
> > My first hunch here is: Don't introduce types that may be compatible
> > later. Either make them compatible, or make them distinct by design,
> > and possibly add a different, compatible type later.
> >   
> > > then after software upgrade, v5 is now compatible to v4, should the
> > > software now downgrade mdev type from v5 to v4?
> > > not sure if moving hardware generation info into a separate attribute
> > > from mdev type name is better. e.g. remove v4, v5 in mdev type, while use
> > > compatible_pci_ids to identify compatibility.  
> > 
> > If the generations are compatible, don't mention it in the mdev type.
> > If they aren't, use distinct types, so that management software doesn't
> > have to guess. At least that would be my naive approach here.  
> yep that is what i would prefer to see too.
> >   
> > > 
> > > (2) name string of mdev type is composed by "driver_name + type_name".
> > > in some devices, e.g. qat, different generations of devices are binding to
> > > drivers of different names, e.g. "qat-v4", "qat-v5".
> > > then though type_name is equal, mdev type is not equal. e.g.
> > > "qat-v4-type1", "qat-v5-type1".  
> > 
> > I guess that shows a shortcoming of that "driver_name + type_name"
> > approach? Or maybe I'm just confused.  
> yes i really dont like haveing the version in the mdev-type name 
> i would stongly perfger just qat-type-1 wehere qat is just there as a way of namespacing.
> although symmetric-cryto, asymmetric-cryto and compression woudl be a better name then type-1, type-2, type-3 if
> that is what they would end up mapping too. e.g. qat-compression or qat-aes is a much better name then type-1
> higher layers of software are unlikely to parse the mdev names but as a human looking at them its much eaiser to
> understand if the names are meaningful. the qat prefix i think is important however to make sure that your mdev-types
> dont colide with other vendeors mdev types. so i woudl encurage all vendors to prefix there mdev types with etiher the
> device name or the vendor.

+1 to all this, the mdev type is meant to indicate a software
compatible interface, if different hardware versions can be software
compatible, then don't make the job of finding a compatible device
harder.  The full type is a combination of the vendor driver name plus
the vendor provided type name specifically in order to provide a type
namespace per vendor driver.  That's done at the mdev core level.
Thanks,

Alex



From oliver.weinmann at icloud.com  Fri Sep 11 07:47:45 2020
From: oliver.weinmann at icloud.com (Oliver Weinmann)
Date: Fri, 11 Sep 2020 07:47:45 -0000
Subject: Ussuri CentOS 8 add mptsas driver to introspection initramfs
Message-ID: <55c5b908-3d0e-4d92-8f8f-95443fbefb9f@me.com>

Hi,



I already asked this question on serverfault. But I guess here is a better place.



I have a very ancient hardware with a MPTSAS controller. I use this for TripleO deployment testing. With the release of Ussuri which is running CentOS8, I can no longer provision my overcloud nodes as the MPTSAS driver has been removed in CentOS8:

https://www.reddit.com/r/CentOS/comments/d93unk/centos8_and_removal_mpt2sas_dell_sas_drivers/


I managed to include the driver provided from ELrepo in the introspection image but It is not loaded automatically:

All commands are run as user "stack".

Extract the introspection image:


cd ~
mkdir imagesnew
cd imagesnew
tar xvf ../ironic-python-agent.tar
mkdir ~/ipa-tmp
cd ~/ipa-tmp
/usr/lib/dracut/skipcpio ~/imagesnew/ironic-python-agent.initramfs | zcat | cpio -ivd | pax -r


Extract the contents of the mptsas driver rpm:


rpm2cpio ~/kmod-mptsas-3.04.20-3.el8_2.elrepo.x86_64.rpm | pax -r


Put the kernel module in the right places. To figure out where the module has to reside I installed the rpm on a already deployed node and used find to locate it.

xz -c ./usr/lib/modules/4.18.0-193.el8.x86_64/extra/mptsas/mptsas.ko > ./usr/lib/modules/4.18.0-193.6.3.el8_2.x86_64/kernel/drivers/message/fusion/mptsas.ko.xz
mkdir ./usr/lib/modules/4.18.0-193.6.3.el8_2.x86_64/weak-updates/mptsas
sudo ln -sf /lib/modules/4.18.0-193.el8.x86_64/extra/mptsas/mptsas.ko lib/modules/4.18.0-193.6.3.el8_2.x86_64/weak-updates/mptsas.ko
sudo chown root . -R
find . 2>/dev/null | sudo cpio --quiet -c -o | gzip -8  > ~/images/ironic-python-agent.initramfs


Upload the new image


cd ~/images
openstack overcloud image upload --update-existing --image-path /home/stack/images/

Now when I start the introspection and ssh into the host I see no disks:


[root at localhost ~]# fdisk -l
[root at localhost ~]# lsmod | grep mptsas

Once i manually load the driver, I can see the disks:


[root at localhost ~]# modprobe mptsas
[root at localhost ~]# lsmod | grep mptsas
mptsas                 69632  0
mptscsih               45056  1 mptsas
mptbase                98304  2 mptsas,mptscsih
scsi_transport_sas     45056  1 mptsas
[root at localhost ~]# fdisk -l
Disk /dev/sda: 67.1 GiB, 71999422464 bytes, 140623872 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


But how can I make it so that it will automatically load on boot?


Best Regards,


Oliver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200911/5cca00c9/attachment-0001.html>

From dangerzonen at gmail.com  Fri Sep 11 08:14:15 2020
From: dangerzonen at gmail.com (dangerzone ar)
Date: Fri, 11 Sep 2020 16:14:15 +0800
Subject: Instance cannot ping external (Lan/Internet) Openstack AllinOne
 Packstack Virtualbox
Message-ID: <CADuLHcVYCcQsMdOnJe2h6EMT84-6OC7+4AjEpAL6aZffEa5iNg@mail.gmail.com>

Hi Team,
I have been struggling to get the solution. I'm testing openstack and
deploying it over virtualbox. I have shared my issue in SO with help from
berndbausch <https://stackoverflow.com/users/3548109/berndbausch> and
try to share it here also to get more help....as I have create and redeploy
few times with different openstack release.. deployment
methods..parameters....still the same problem.
I don't think my deployment is different with others as i follow the
guideline and common practise... just stuck on this problem...please do
help and assist me further.
Thank you to all....

Below is my environment setup.

Windos10_Virtualbox----Centos7------Openstack----VM instance
[192.168.0.0/24] - external network/public-ip
Pc host - 192.168.0.160
Home Lan GW - 192.168.0.1
Centos7 - 192.168.0.12 (VM virtualbox)
Openstack Router GW - 192.168.0.221
Virtualbox VM setting bridge (enp0s3) and promiscuous mode all
selinux permissive

add rules icmp and ssh.
create public-ip 192.168.0.0/24 (pool 220-230)
create router
create private subnet 10.0.0.0/24
attach router to private subnet
create router GW(public-ip)

>From LAN I can ping and ssh vm instance but from vm instance i cannot ping
to home Lan GW, pc host. VM instance can ping up to centos7 virtualbox and
openstack Router GW. Instance created with centos and cirros using direct
public-ip and also floating ip. Some instance created with direct public ip
and some with private subnet and using floating ip.

I have tested with queens, stein, train. With allinone and also using
answerfile and all end up I cannot ping external. I follows guideline
below:-

*hxxps://www.linuxtechi.com/single-node-openstack-liberty-installation-centos-7/
<http://www.linuxtechi.com/single-node-openstack-liberty-installation-centos-7/>*
*hxxps://www.rdoproject.org/install/packstack/
<http://www.rdoproject.org/install/packstack/>*

This some of answer file parameters that i edited

CONFIG_NEUTRON_L3_EXT_BRIDGE=br-ex
CONFIG_NEUTRON_ML2_TYPE_DRIVERS=flat,vxlan
CONFIG_NEUTRON_OVS_BRIDGE_MAPPINGS=extnet:br-ex
CONFIG_NEUTRON_OVS_BRIDGE_IFACES=br-ex:enp0s3
CONFIG_NEUTRON_OVS_BRIDGES_COMPUTE=br-ex
CONFIG_PROVISION_DEMO=n


ip netns list
qrouter-f6967bba-986e-4bb3-838e-d035a684e2c4 (id: 2)
qdhcp-dbd713cd-1af4-4e2c-9c57-d8a675a10608 (id: 1)
qdhcp-fa6fb1d6-b65e-4eb2-a4a4-5552fde8bb08 (id: 0)
[root at myospackanswer ~(keystone_admin)]# ip netns exec
qrouter-f6967bba-986e-4bb3-838e-d035a684e2c4 arp -an
? (192.168.0.211) at <incomplete> on qg-0ba7da31-7f
? (192.168.0.227) at fa:16:3e:ed:19:81 [ether] on qg-0ba7da31-7f (Instance IP)
? (192.168.0.160) at d4:d2:52:73:de:80 [ether] on qg-0ba7da31-7f (host pc IP)
? (192.168.0.1) at 80:26:89:b2:98:50 [ether] on qg-0ba7da31-7f (home router GW)
? (10.0.0.4) at fa:16:3e:01:63:42 [ether] on qr-7e6f9436-40 (private subnet)

ip r
default via 192.168.0.1 dev br-ex169.254.0.0/16 dev enp0s3 scope link
metric 1002169.254.0.0/16 dev br-ex scope link metric
1006192.168.0.0/24 dev br-ex proto kernel scope link src 192.168.0.121


qrouter-f6967bba-986e-4bb3-838e-d035a684e2c4 (id: 2)
qdhcp-dbd713cd-1af4-4e2c-9c57-d8a675a10608 (id: 1)
qdhcp-fa6fb1d6-b65e-4eb2-a4a4-5552fde8bb08 (id: 0)

sudo ip netns exec qrouter-f6967bba-986e-4bb3-838e-d035a684e2c4 ip route
default via 192.168.0.1 dev qg-0ba7da31-7f10.0.0.0/24 dev
qr-7e6f9436-40 proto kernel scope link src 10.0.0.1192.168.0.0/24 dev
qg-0ba7da31-7f proto kernel scope link src 192.168.0.221


ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master ovs-system state UP group default qlen 1000
    link/ether 08:00:27:98:9b:a3 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::a00:27ff:fe98:9ba3/64 scope link
       valid_lft forever preferred_lft forever
5: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
group default qlen 1000
    link/ether 8a:17:8b:e5:dc:c2 brd ff:ff:ff:ff:ff:ff
6: br-ex: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UNKNOWN group default qlen 1000
    link/ether 08:00:27:98:9b:a3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.121/24 brd 192.168.0.255 scope global br-ex
       valid_lft forever preferred_lft forever
    inet6 2001:e68:5435:d135:a00:27ff:fe98:9ba3/64 scope global
mngtmpaddr dynamic
       valid_lft 86399sec preferred_lft 86399sec
    inet6 fe80::a00:27ff:fe98:9ba3/64 scope link
       valid_lft forever preferred_lft forever
7: br-int: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN group
default qlen 1000
    link/ether 32:ff:0f:26:18:43 brd ff:ff:ff:ff:ff:ff
8: br-tun: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
    link/ether d6:52:08:a9:68:4f brd ff:ff:ff:ff:ff:ff
29: qbr1f637f14-9c: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc
noqueue state UP group default qlen 1000
    link/ether 42:95:e8:c0:a3:07 brd ff:ff:ff:ff:ff:ff
30: qvo1f637f14-9c at qvb1f637f14-9c:
<BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1450 qdisc noqueue
master ovs-system state UP group default qlen 1000
    link/ether 6e:2e:07:8d:79:86 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::6c2e:7ff:fe8d:7986/64 scope link
       valid_lft forever preferred_lft forever
31: qvb1f637f14-9c at qvo1f637f14-9c:
<BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1450 qdisc noqueue
master qbr1f637f14-9c state UP group default qlen 1000
    link/ether 42:95:e8:c0:a3:07 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::4095:e8ff:fec0:a307/64 scope link
       valid_lft forever preferred_lft forever
32: tap1f637f14-9c: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc
pfifo_fast master qbr1f637f14-9c state UNKNOWN group default qlen 1000
    link/ether fe:16:3e:05:2d:50 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc16:3eff:fe05:2d50/64 scope link
       valid_lft forever preferred_lft forever
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200911/ee6d6dc8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1osp.jpg
Type: image/jpeg
Size: 25859 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200911/ee6d6dc8/attachment-0001.jpg>

From kevin.tian at intel.com  Fri Sep 11 10:18:01 2020
From: kevin.tian at intel.com (Tian, Kevin)
Date: Fri, 11 Sep 2020 10:18:01 +0000
Subject: device compatibility interface for live migration with assigned
 devices
In-Reply-To: <20200911120806.5cfe203c.cohuck@redhat.com>
References: <20200825163925.1c19b0f0.cohuck@redhat.com>
 <20200826064117.GA22243@joy-OptiPlex-7040>
 <20200828154741.30cfc1a3.cohuck@redhat.com>
 <8f5345be73ebf4f8f7f51d6cdc9c2a0d8e0aa45e.camel@redhat.com>
 <20200831044344.GB13784@joy-OptiPlex-7040>
 <20200908164130.2fe0d106.cohuck@redhat.com>
 <20200909021308.GA1277@joy-OptiPlex-7040>
 <20200910143822.2071eca4.cohuck@redhat.com>
 <7cebcb6c8d1a1452b43e8358ee6ee18a150a0238.camel@redhat.com>
 <20200910120244.71e7b630@w520.home>	<20200911005559.GA3932@joy-OptiPlex-7040>
 <20200911120806.5cfe203c.cohuck@redhat.com>
Message-ID: <MWHPR11MB164559CBC9819565289BAAE98C240@MWHPR11MB1645.namprd11.prod.outlook.com>

> From: Cornelia Huck <cohuck at redhat.com>
> Sent: Friday, September 11, 2020 6:08 PM
> 
> On Fri, 11 Sep 2020 08:56:00 +0800
> Yan Zhao <yan.y.zhao at intel.com> wrote:
> 
> > On Thu, Sep 10, 2020 at 12:02:44PM -0600, Alex Williamson wrote:
> > > On Thu, 10 Sep 2020 13:50:11 +0100
> > > Sean Mooney <smooney at redhat.com> wrote:
> > >
> > > > On Thu, 2020-09-10 at 14:38 +0200, Cornelia Huck wrote:
> > > > > On Wed, 9 Sep 2020 10:13:09 +0800
> > > > > Yan Zhao <yan.y.zhao at intel.com> wrote:
> > > > >
> > > > > > > > still, I'd like to put it more explicitly to make ensure it's not
> missed:
> > > > > > > > the reason we want to specify compatible_type as a trait and
> check
> > > > > > > > whether target compatible_type is the superset of source
> > > > > > > > compatible_type is for the consideration of backward
> compatibility.
> > > > > > > > e.g.
> > > > > > > > an old generation device may have a mdev type xxx-v4-yyy,
> while a newer
> > > > > > > > generation  device may be of mdev type xxx-v5-yyy.
> > > > > > > > with the compatible_type traits, the old generation device is still
> > > > > > > > able to be regarded as compatible to newer generation device
> even their
> > > > > > > > mdev types are not equal.
> > > > > > >
> > > > > > > If you want to support migration from v4 to v5, can't the
> (presumably
> > > > > > > newer) driver that supports v5 simply register the v4 type as well,
> so
> > > > > > > that the mdev can be created as v4? (Just like QEMU versioned
> machine
> > > > > > > types work.)
> > > > > >
> > > > > > yes, it should work in some conditions.
> > > > > > but it may not be that good in some cases when v5 and v4 in the
> name string
> > > > > > of mdev type identify hardware generation (e.g. v4 for gen8, and v5
> for
> > > > > > gen9)
> > > > > >
> > > > > > e.g.
> > > > > > (1). when src mdev type is v4 and target mdev type is v5 as
> > > > > > software does not support it initially, and v4 and v5 identify
> hardware
> > > > > > differences.
> > > > >
> > > > > My first hunch here is: Don't introduce types that may be compatible
> > > > > later. Either make them compatible, or make them distinct by design,
> > > > > and possibly add a different, compatible type later.
> > > > >
> > > > > > then after software upgrade, v5 is now compatible to v4, should the
> > > > > > software now downgrade mdev type from v5 to v4?
> > > > > > not sure if moving hardware generation info into a separate
> attribute
> > > > > > from mdev type name is better. e.g. remove v4, v5 in mdev type,
> while use
> > > > > > compatible_pci_ids to identify compatibility.
> > > > >
> > > > > If the generations are compatible, don't mention it in the mdev type.
> > > > > If they aren't, use distinct types, so that management software
> doesn't
> > > > > have to guess. At least that would be my naive approach here.
> 
> [*]
> 
> > > > yep that is what i would prefer to see too.
> > > > >
> > > > > >
> > > > > > (2) name string of mdev type is composed by "driver_name +
> type_name".
> > > > > > in some devices, e.g. qat, different generations of devices are
> binding to
> > > > > > drivers of different names, e.g. "qat-v4", "qat-v5".
> > > > > > then though type_name is equal, mdev type is not equal. e.g.
> > > > > > "qat-v4-type1", "qat-v5-type1".
> > > > >
> > > > > I guess that shows a shortcoming of that "driver_name + type_name"
> > > > > approach? Or maybe I'm just confused.
> > > > yes i really dont like haveing the version in the mdev-type name
> > > > i would stongly perfger just qat-type-1 wehere qat is just there as a way
> of namespacing.
> > > > although symmetric-cryto, asymmetric-cryto and compression woudl be
> a better name then type-1, type-2, type-3 if
> > > > that is what they would end up mapping too. e.g. qat-compression or
> qat-aes is a much better name then type-1
> > > > higher layers of software are unlikely to parse the mdev names but as a
> human looking at them its much eaiser to
> > > > understand if the names are meaningful. the qat prefix i think is
> important however to make sure that your mdev-types
> > > > dont colide with other vendeors mdev types. so i woudl encurage all
> vendors to prefix there mdev types with etiher the
> > > > device name or the vendor.
> > >
> > > +1 to all this, the mdev type is meant to indicate a software
> > > compatible interface, if different hardware versions can be software
> > > compatible, then don't make the job of finding a compatible device
> > > harder.  The full type is a combination of the vendor driver name plus
> > > the vendor provided type name specifically in order to provide a type
> > > namespace per vendor driver.  That's done at the mdev core level.
> > > Thanks,
> >
> > hi Alex,
> > got it. so do you suggest that vendors use consistent driver name over
> > generations of devices?
> > for qat, they create different modules for each generation. This
> > practice is not good if they want to support migration between devices
> > of different generations, right?
> 
> Even if they create different modules, I'd assume that they have some
> kind of core with common functionality. I'd assume that as long they do
> any type registrations satisfying [*] in the core, they should be good.
> 
> > and can I understand that we don't want support of migration between
> > different mdev types even in future ?
> 
> From my point of view, I don't see anything that migration between
> different mdev types would buy that is worth the complexity in finding
> out which mdev types are actually compatible.

Agree. Different type means different device API. as long as the device
API doesn't change, different modules should expose it as the same type.
If qat really wants to attach module name to the type, it essentially implies
that qat has no generational compatibility.

Thanks
Kevin


From alexis.deberg at ubisoft.com  Fri Sep 11 16:03:55 2020
From: alexis.deberg at ubisoft.com (Alexis Deberg)
Date: Fri, 11 Sep 2020 16:03:55 +0000
Subject: [neutron] Flow drop on agent restart with openvswitch firewall
 driver
In-Reply-To: <CAOAKi8yCGQGpi3TJxa+WR3yNDzJ+cEejGYV26XozT1MPFrfOuw@mail.gmail.com>
References: <DM6PR17MB36108DF4942A4B8C72675D73F2290@DM6PR17MB3610.namprd17.prod.outlook.com>
 <20200909075042.qyxbnq7li2zm5oo4@skaplons-mac>
 <DM6PR17MB361085CE869B739505B1C5EDF2260@DM6PR17MB3610.namprd17.prod.outlook.com>,
 <CAOAKi8yCGQGpi3TJxa+WR3yNDzJ+cEejGYV26XozT1MPFrfOuw@mail.gmail.com>
Message-ID: <DM6PR17MB3610337E6995593D8551D995F2240@DM6PR17MB3610.namprd17.prod.outlook.com>

See my last comment in the opened bug, looks like upgrading to a more recent version brings some patches that fix the issue.

Thanks everyone, and especially to slaweq and rodolfo-alonso-hernandez

Cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200911/e7c36054/attachment-0001.html>

From alex.williamson at redhat.com  Fri Sep 11 16:51:55 2020
From: alex.williamson at redhat.com (Alex Williamson)
Date: Fri, 11 Sep 2020 10:51:55 -0600
Subject: device compatibility interface for live migration with assigned
 devices
In-Reply-To: <20200911005559.GA3932@joy-OptiPlex-7040>
References: <20200825163925.1c19b0f0.cohuck@redhat.com>
 <20200826064117.GA22243@joy-OptiPlex-7040>
 <20200828154741.30cfc1a3.cohuck@redhat.com>
 <8f5345be73ebf4f8f7f51d6cdc9c2a0d8e0aa45e.camel@redhat.com>
 <20200831044344.GB13784@joy-OptiPlex-7040>
 <20200908164130.2fe0d106.cohuck@redhat.com>
 <20200909021308.GA1277@joy-OptiPlex-7040>
 <20200910143822.2071eca4.cohuck@redhat.com>
 <7cebcb6c8d1a1452b43e8358ee6ee18a150a0238.camel@redhat.com>
 <20200910120244.71e7b630@w520.home>
 <20200911005559.GA3932@joy-OptiPlex-7040>
Message-ID: <20200911105155.184e32a0@w520.home>

On Fri, 11 Sep 2020 08:56:00 +0800
Yan Zhao <yan.y.zhao at intel.com> wrote:

> On Thu, Sep 10, 2020 at 12:02:44PM -0600, Alex Williamson wrote:
> > On Thu, 10 Sep 2020 13:50:11 +0100
> > Sean Mooney <smooney at redhat.com> wrote:
> >   
> > > On Thu, 2020-09-10 at 14:38 +0200, Cornelia Huck wrote:  
> > > > On Wed, 9 Sep 2020 10:13:09 +0800
> > > > Yan Zhao <yan.y.zhao at intel.com> wrote:
> > > >     
> > > > > > > still, I'd like to put it more explicitly to make ensure it's not missed:
> > > > > > > the reason we want to specify compatible_type as a trait and check
> > > > > > > whether target compatible_type is the superset of source
> > > > > > > compatible_type is for the consideration of backward compatibility.
> > > > > > > e.g.
> > > > > > > an old generation device may have a mdev type xxx-v4-yyy, while a newer
> > > > > > > generation  device may be of mdev type xxx-v5-yyy.
> > > > > > > with the compatible_type traits, the old generation device is still
> > > > > > > able to be regarded as compatible to newer generation device even their
> > > > > > > mdev types are not equal.      
> > > > > > 
> > > > > > If you want to support migration from v4 to v5, can't the (presumably
> > > > > > newer) driver that supports v5 simply register the v4 type as well, so
> > > > > > that the mdev can be created as v4? (Just like QEMU versioned machine
> > > > > > types work.)      
> > > > > 
> > > > > yes, it should work in some conditions.
> > > > > but it may not be that good in some cases when v5 and v4 in the name string
> > > > > of mdev type identify hardware generation (e.g. v4 for gen8, and v5 for
> > > > > gen9)
> > > > > 
> > > > > e.g.
> > > > > (1). when src mdev type is v4 and target mdev type is v5 as
> > > > > software does not support it initially, and v4 and v5 identify hardware
> > > > > differences.    
> > > > 
> > > > My first hunch here is: Don't introduce types that may be compatible
> > > > later. Either make them compatible, or make them distinct by design,
> > > > and possibly add a different, compatible type later.
> > > >     
> > > > > then after software upgrade, v5 is now compatible to v4, should the
> > > > > software now downgrade mdev type from v5 to v4?
> > > > > not sure if moving hardware generation info into a separate attribute
> > > > > from mdev type name is better. e.g. remove v4, v5 in mdev type, while use
> > > > > compatible_pci_ids to identify compatibility.    
> > > > 
> > > > If the generations are compatible, don't mention it in the mdev type.
> > > > If they aren't, use distinct types, so that management software doesn't
> > > > have to guess. At least that would be my naive approach here.    
> > > yep that is what i would prefer to see too.  
> > > >     
> > > > > 
> > > > > (2) name string of mdev type is composed by "driver_name + type_name".
> > > > > in some devices, e.g. qat, different generations of devices are binding to
> > > > > drivers of different names, e.g. "qat-v4", "qat-v5".
> > > > > then though type_name is equal, mdev type is not equal. e.g.
> > > > > "qat-v4-type1", "qat-v5-type1".    
> > > > 
> > > > I guess that shows a shortcoming of that "driver_name + type_name"
> > > > approach? Or maybe I'm just confused.    
> > > yes i really dont like haveing the version in the mdev-type name 
> > > i would stongly perfger just qat-type-1 wehere qat is just there as a way of namespacing.
> > > although symmetric-cryto, asymmetric-cryto and compression woudl be a better name then type-1, type-2, type-3 if
> > > that is what they would end up mapping too. e.g. qat-compression or qat-aes is a much better name then type-1
> > > higher layers of software are unlikely to parse the mdev names but as a human looking at them its much eaiser to
> > > understand if the names are meaningful. the qat prefix i think is important however to make sure that your mdev-types
> > > dont colide with other vendeors mdev types. so i woudl encurage all vendors to prefix there mdev types with etiher the
> > > device name or the vendor.  
> > 
> > +1 to all this, the mdev type is meant to indicate a software
> > compatible interface, if different hardware versions can be software
> > compatible, then don't make the job of finding a compatible device
> > harder.  The full type is a combination of the vendor driver name plus
> > the vendor provided type name specifically in order to provide a type
> > namespace per vendor driver.  That's done at the mdev core level.
> > Thanks,  
> 
> hi Alex,
> got it. so do you suggest that vendors use consistent driver name over
> generations of devices?
> for qat, they create different modules for each generation. This
> practice is not good if they want to support migration between devices
> of different generations, right?
> 
> and can I understand that we don't want support of migration between
> different mdev types even in future ?

You need to balance your requirements here.  If you're creating
different drivers per generation, that suggests different device APIs,
which is a legitimate use case for different mdev types.  However if
you're expecting migration compatibility, that must be seamless to the
guest, therefore the device API must be identical.  That suggests that
migration between different types doesn't make much sense.  If a new
generation device wants to expose a new mdev type with new features or
device API, yet also support migration with an older mdev type, why
wouldn't it simply expose both the old and the new type?  It seems much
more supportable to simply instantiate an instance of the older type
than to create an instance of the new type, which by the contents of
the migration stream is configured to behave as the older type.  The
latter sounds very difficult to test.

A challenge when we think about migration between different types,
particularly across different vendor drivers, is that the migration
stream is opaque, it's device and vendor specific.  Therefore it's not
only difficult for userspace to understand the compatibility matrix, but
also to actually support it in software, maintaining version and bug
compatibility across different drivers.  It's clearly much, much easier
when the same code base (and thus the same mdev type) is producing and
consuming the migration data.  Thanks,

Alex



From yan.y.zhao at intel.com  Fri Sep 11 00:56:00 2020
From: yan.y.zhao at intel.com (Yan Zhao)
Date: Fri, 11 Sep 2020 08:56:00 +0800
Subject: device compatibility interface for live migration with assigned
 devices
In-Reply-To: <20200910120244.71e7b630@w520.home>
References: <20200825163925.1c19b0f0.cohuck@redhat.com>
 <20200826064117.GA22243@joy-OptiPlex-7040>
 <20200828154741.30cfc1a3.cohuck@redhat.com>
 <8f5345be73ebf4f8f7f51d6cdc9c2a0d8e0aa45e.camel@redhat.com>
 <20200831044344.GB13784@joy-OptiPlex-7040>
 <20200908164130.2fe0d106.cohuck@redhat.com>
 <20200909021308.GA1277@joy-OptiPlex-7040>
 <20200910143822.2071eca4.cohuck@redhat.com>
 <7cebcb6c8d1a1452b43e8358ee6ee18a150a0238.camel@redhat.com>
 <20200910120244.71e7b630@w520.home>
Message-ID: <20200911005559.GA3932@joy-OptiPlex-7040>

On Thu, Sep 10, 2020 at 12:02:44PM -0600, Alex Williamson wrote:
> On Thu, 10 Sep 2020 13:50:11 +0100
> Sean Mooney <smooney at redhat.com> wrote:
> 
> > On Thu, 2020-09-10 at 14:38 +0200, Cornelia Huck wrote:
> > > On Wed, 9 Sep 2020 10:13:09 +0800
> > > Yan Zhao <yan.y.zhao at intel.com> wrote:
> > >   
> > > > > > still, I'd like to put it more explicitly to make ensure it's not missed:
> > > > > > the reason we want to specify compatible_type as a trait and check
> > > > > > whether target compatible_type is the superset of source
> > > > > > compatible_type is for the consideration of backward compatibility.
> > > > > > e.g.
> > > > > > an old generation device may have a mdev type xxx-v4-yyy, while a newer
> > > > > > generation  device may be of mdev type xxx-v5-yyy.
> > > > > > with the compatible_type traits, the old generation device is still
> > > > > > able to be regarded as compatible to newer generation device even their
> > > > > > mdev types are not equal.    
> > > > > 
> > > > > If you want to support migration from v4 to v5, can't the (presumably
> > > > > newer) driver that supports v5 simply register the v4 type as well, so
> > > > > that the mdev can be created as v4? (Just like QEMU versioned machine
> > > > > types work.)    
> > > > 
> > > > yes, it should work in some conditions.
> > > > but it may not be that good in some cases when v5 and v4 in the name string
> > > > of mdev type identify hardware generation (e.g. v4 for gen8, and v5 for
> > > > gen9)
> > > > 
> > > > e.g.
> > > > (1). when src mdev type is v4 and target mdev type is v5 as
> > > > software does not support it initially, and v4 and v5 identify hardware
> > > > differences.  
> > > 
> > > My first hunch here is: Don't introduce types that may be compatible
> > > later. Either make them compatible, or make them distinct by design,
> > > and possibly add a different, compatible type later.
> > >   
> > > > then after software upgrade, v5 is now compatible to v4, should the
> > > > software now downgrade mdev type from v5 to v4?
> > > > not sure if moving hardware generation info into a separate attribute
> > > > from mdev type name is better. e.g. remove v4, v5 in mdev type, while use
> > > > compatible_pci_ids to identify compatibility.  
> > > 
> > > If the generations are compatible, don't mention it in the mdev type.
> > > If they aren't, use distinct types, so that management software doesn't
> > > have to guess. At least that would be my naive approach here.  
> > yep that is what i would prefer to see too.
> > >   
> > > > 
> > > > (2) name string of mdev type is composed by "driver_name + type_name".
> > > > in some devices, e.g. qat, different generations of devices are binding to
> > > > drivers of different names, e.g. "qat-v4", "qat-v5".
> > > > then though type_name is equal, mdev type is not equal. e.g.
> > > > "qat-v4-type1", "qat-v5-type1".  
> > > 
> > > I guess that shows a shortcoming of that "driver_name + type_name"
> > > approach? Or maybe I'm just confused.  
> > yes i really dont like haveing the version in the mdev-type name 
> > i would stongly perfger just qat-type-1 wehere qat is just there as a way of namespacing.
> > although symmetric-cryto, asymmetric-cryto and compression woudl be a better name then type-1, type-2, type-3 if
> > that is what they would end up mapping too. e.g. qat-compression or qat-aes is a much better name then type-1
> > higher layers of software are unlikely to parse the mdev names but as a human looking at them its much eaiser to
> > understand if the names are meaningful. the qat prefix i think is important however to make sure that your mdev-types
> > dont colide with other vendeors mdev types. so i woudl encurage all vendors to prefix there mdev types with etiher the
> > device name or the vendor.
> 
> +1 to all this, the mdev type is meant to indicate a software
> compatible interface, if different hardware versions can be software
> compatible, then don't make the job of finding a compatible device
> harder.  The full type is a combination of the vendor driver name plus
> the vendor provided type name specifically in order to provide a type
> namespace per vendor driver.  That's done at the mdev core level.
> Thanks,

hi Alex,
got it. so do you suggest that vendors use consistent driver name over
generations of devices?
for qat, they create different modules for each generation. This
practice is not good if they want to support migration between devices
of different generations, right?

and can I understand that we don't want support of migration between
different mdev types even in future ?

Thanks
Yan



From cohuck at redhat.com  Fri Sep 11 10:08:06 2020
From: cohuck at redhat.com (Cornelia Huck)
Date: Fri, 11 Sep 2020 12:08:06 +0200
Subject: device compatibility interface for live migration with assigned
 devices
In-Reply-To: <20200911005559.GA3932@joy-OptiPlex-7040>
References: <20200825163925.1c19b0f0.cohuck@redhat.com>
 <20200826064117.GA22243@joy-OptiPlex-7040>
 <20200828154741.30cfc1a3.cohuck@redhat.com>
 <8f5345be73ebf4f8f7f51d6cdc9c2a0d8e0aa45e.camel@redhat.com>
 <20200831044344.GB13784@joy-OptiPlex-7040>
 <20200908164130.2fe0d106.cohuck@redhat.com>
 <20200909021308.GA1277@joy-OptiPlex-7040>
 <20200910143822.2071eca4.cohuck@redhat.com>
 <7cebcb6c8d1a1452b43e8358ee6ee18a150a0238.camel@redhat.com>
 <20200910120244.71e7b630@w520.home>
 <20200911005559.GA3932@joy-OptiPlex-7040>
Message-ID: <20200911120806.5cfe203c.cohuck@redhat.com>

On Fri, 11 Sep 2020 08:56:00 +0800
Yan Zhao <yan.y.zhao at intel.com> wrote:

> On Thu, Sep 10, 2020 at 12:02:44PM -0600, Alex Williamson wrote:
> > On Thu, 10 Sep 2020 13:50:11 +0100
> > Sean Mooney <smooney at redhat.com> wrote:
> >   
> > > On Thu, 2020-09-10 at 14:38 +0200, Cornelia Huck wrote:  
> > > > On Wed, 9 Sep 2020 10:13:09 +0800
> > > > Yan Zhao <yan.y.zhao at intel.com> wrote:
> > > >     
> > > > > > > still, I'd like to put it more explicitly to make ensure it's not missed:
> > > > > > > the reason we want to specify compatible_type as a trait and check
> > > > > > > whether target compatible_type is the superset of source
> > > > > > > compatible_type is for the consideration of backward compatibility.
> > > > > > > e.g.
> > > > > > > an old generation device may have a mdev type xxx-v4-yyy, while a newer
> > > > > > > generation  device may be of mdev type xxx-v5-yyy.
> > > > > > > with the compatible_type traits, the old generation device is still
> > > > > > > able to be regarded as compatible to newer generation device even their
> > > > > > > mdev types are not equal.      
> > > > > > 
> > > > > > If you want to support migration from v4 to v5, can't the (presumably
> > > > > > newer) driver that supports v5 simply register the v4 type as well, so
> > > > > > that the mdev can be created as v4? (Just like QEMU versioned machine
> > > > > > types work.)      
> > > > > 
> > > > > yes, it should work in some conditions.
> > > > > but it may not be that good in some cases when v5 and v4 in the name string
> > > > > of mdev type identify hardware generation (e.g. v4 for gen8, and v5 for
> > > > > gen9)
> > > > > 
> > > > > e.g.
> > > > > (1). when src mdev type is v4 and target mdev type is v5 as
> > > > > software does not support it initially, and v4 and v5 identify hardware
> > > > > differences.    
> > > > 
> > > > My first hunch here is: Don't introduce types that may be compatible
> > > > later. Either make them compatible, or make them distinct by design,
> > > > and possibly add a different, compatible type later.
> > > >     
> > > > > then after software upgrade, v5 is now compatible to v4, should the
> > > > > software now downgrade mdev type from v5 to v4?
> > > > > not sure if moving hardware generation info into a separate attribute
> > > > > from mdev type name is better. e.g. remove v4, v5 in mdev type, while use
> > > > > compatible_pci_ids to identify compatibility.    
> > > > 
> > > > If the generations are compatible, don't mention it in the mdev type.
> > > > If they aren't, use distinct types, so that management software doesn't
> > > > have to guess. At least that would be my naive approach here.  

[*]
  
> > > yep that is what i would prefer to see too.  
> > > >     
> > > > > 
> > > > > (2) name string of mdev type is composed by "driver_name + type_name".
> > > > > in some devices, e.g. qat, different generations of devices are binding to
> > > > > drivers of different names, e.g. "qat-v4", "qat-v5".
> > > > > then though type_name is equal, mdev type is not equal. e.g.
> > > > > "qat-v4-type1", "qat-v5-type1".    
> > > > 
> > > > I guess that shows a shortcoming of that "driver_name + type_name"
> > > > approach? Or maybe I'm just confused.    
> > > yes i really dont like haveing the version in the mdev-type name 
> > > i would stongly perfger just qat-type-1 wehere qat is just there as a way of namespacing.
> > > although symmetric-cryto, asymmetric-cryto and compression woudl be a better name then type-1, type-2, type-3 if
> > > that is what they would end up mapping too. e.g. qat-compression or qat-aes is a much better name then type-1
> > > higher layers of software are unlikely to parse the mdev names but as a human looking at them its much eaiser to
> > > understand if the names are meaningful. the qat prefix i think is important however to make sure that your mdev-types
> > > dont colide with other vendeors mdev types. so i woudl encurage all vendors to prefix there mdev types with etiher the
> > > device name or the vendor.  
> > 
> > +1 to all this, the mdev type is meant to indicate a software
> > compatible interface, if different hardware versions can be software
> > compatible, then don't make the job of finding a compatible device
> > harder.  The full type is a combination of the vendor driver name plus
> > the vendor provided type name specifically in order to provide a type
> > namespace per vendor driver.  That's done at the mdev core level.
> > Thanks,  
> 
> hi Alex,
> got it. so do you suggest that vendors use consistent driver name over
> generations of devices?
> for qat, they create different modules for each generation. This
> practice is not good if they want to support migration between devices
> of different generations, right?

Even if they create different modules, I'd assume that they have some
kind of core with common functionality. I'd assume that as long they do
any type registrations satisfying [*] in the core, they should be good.

> and can I understand that we don't want support of migration between
> different mdev types even in future ?

From my point of view, I don't see anything that migration between
different mdev types would buy that is worth the complexity in finding
out which mdev types are actually compatible.



From openstack at nemebean.com  Fri Sep 11 19:43:43 2020
From: openstack at nemebean.com (Ben Nemec)
Date: Fri, 11 Sep 2020 14:43:43 -0500
Subject: [oslo][release][requirement] FFE request for Oslo lib
In-Reply-To: <1747d4839a4.10505a96f108873.8961642381266139796@ghanshyammann.com>
References: <1746e64d702.ee80b0bc1249.5426348472779199647@ghanshyammann.com>
 <bc93768b-cf66-d66b-5fc6-78ac07797991@nemebean.com>
 <20200909192543.b2d2ksruoqtbgcfy@mthode.org>
 <174746eb120.1229d07d224552.356509349559116522@ghanshyammann.com>
 <1747608f93e.d7ec085f28282.4985395579846058200@ghanshyammann.com>
 <1747d4839a4.10505a96f108873.8961642381266139796@ghanshyammann.com>
Message-ID: <53ba067f-3c47-12ce-858c-c1de982166be@nemebean.com>



On 9/11/20 8:08 AM, Ghanshyam Mann wrote:
>   ---- On Wed, 09 Sep 2020 22:22:13 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
>   >  ---- On Wed, 09 Sep 2020 14:54:05 -0500 Ghanshyam Mann <gmann at ghanshyammann.com> wrote ----
>   >  >
>   >  >  ---- On Wed, 09 Sep 2020 14:25:43 -0500 Matthew Thode <mthode at mthode.org> wrote ----
>   >  >  > On 20-09-09 12:04:51, Ben Nemec wrote:
>   >  >  > >
>   >  >  > > On 9/8/20 10:45 AM, Ghanshyam Mann wrote:
>   >  >  > > > Hello Team,
>   >  >  > > >
>   >  >  > > > This is regarding FFE for Focal migration work. As planned, we have to move the Victoria testing to Focal and
>   >  >  > > > base job switch is planned to be switched by today[1].
>   >  >  > > >
>   >  >  > > > There are few oslo lib need work (especially tox job-based testing not user-facing changes) to pass on Focal
>   >  >  > > > - https://review.opendev.org/#/q/topic:migrate-to-focal-oslo+(status:open+OR+status:merged)
>   >  >  > > >
>   >  >  > > > If we move the base tox jobs to Focal then these lib victoria gates (especially lower-constraint job) will be failing.
>   >  >  > > > We can either do these as FFE or backport (as this is lib own CI fixes only) later once the victoria branch is open.
>   >  >  > > > Opinion?
>   >  >  > >
>   >  >  > > As I noted in the meeting, if we have to do this to keep the gates working
>   >  >  > > then I'd rather do it as an FFE than have to backport all of the relevant
>   >  >  > > patches. IMHO we should only decline this FFE if we are going to also change
>   >  >  > > our statement of support for Python/Ubuntu in Victoria.
>   >  >  > >
>   >  >  > > >
>   >  >  > > > [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-September/017060.html
>   >  >  > > >
>   >  >  > > > -gmann
>   >  >  > > >
>   >  >  > > >
>   >  >  > >
>   >  >  >
>   >  >  > https://review.opendev.org/#/c/750089 seems like the only functional
>   >  >  > change.  It has my ACK with my requirements hat on.
>   >
>   > NOTE: There is one py3.8 bug fix also merged in oslo.uitls which is not yet released. This made py3.8 job voting in oslo.utils gate.
>   > - https://review.opendev.org/#/c/750216/
>   >
>   > Rest all l-c bump are now passing on Focal
>   > - https://review.opendev.org/#/q/topic:migrate-to-focal-oslo+(status:open+OR+status:merged)
> 
> All the patches are merged now, requesting to reconsider this FEE so that we can avoid more delay in this.

The final Oslo releases with the focal changes are merged. We should be 
able to branch now and if anything else comes up we'll just have to 
backport.

Thanks to everyone for working with us to get this sorted out, and sorry 
I dropped the ball on this goal.


From tonyliu0592 at hotmail.com  Fri Sep 11 21:26:21 2020
From: tonyliu0592 at hotmail.com (Tony Liu)
Date: Fri, 11 Sep 2020 21:26:21 +0000
Subject: memchached connections
Message-ID: <MWHPR08MB23825850D103A4551150FC4DBD240@MWHPR08MB2382.namprd08.prod.outlook.com>

Hi,

Is there any guidance or experiences to estimate the number
of memcached connections?

Here is memcached connection on one of the 3 controllers.
Connection number is the total established connections to
all 3 memcached nodes.

Node 1:
10 Keystone workers have 62 connections.
11 Nova API workers have 37 connections.
6 Neutron server works have 4304 connections.
1 memcached has 4973 connections.

Node 2:
10 Keystone workers have 62 connections.
11 Nova API workers have 30 connections.
6 Neutron server works have 3703 connections.
1 memcached has 4973 connections.

Node 3:
10 Keystone workers have 54 connections.
11 Nova API workers have 15 connections.
6 Neutron server works have 6541 connections.
1 memcached has 4973 connections.

Before I increase the connection limit for memcached, I'd
like to understand if all the above is expected?

How Neutron server and memcached take so many connections?

Any elaboration is appreciated.

BTW, the problem leading me here is memcached connection timeout,
which results all services depending on memcached stop working
properly.


Thanks!
Tony



From rosmaita.fossdev at gmail.com  Fri Sep 11 21:29:19 2020
From: rosmaita.fossdev at gmail.com (Brian Rosmaita)
Date: Fri, 11 Sep 2020 17:29:19 -0400
Subject: [cinder] FEATURE FREEZE in effect
Message-ID: <8a9bebfd-850d-619a-b925-ba4abbb1958d@gmail.com>

The Victoria feature freeze is now in effect.  Please do not approve 
patches proposing features for master until after the stable/victoria 
branch is cut the week of 21 September.

Due to gate shenanigans over the past week, the following reviews have a 
feature freeze exception, and may be merged to master during the next week:

Default type overrides
- https://review.opendev.org/#/c/737707/
Adding support for Adaptive QoS in NetApp driver
- https://review.opendev.org/#/c/741327/


The following have been approved and have been making their way slowly 
through the gate today, but technically they haven't been merged yet, so 
these also have a FFE:
- https://review.opendev.org/#/c/747540/
- https://review.opendev.org/#/c/746941/
- https://review.opendev.org/#/c/746813/
(Hopefully by the time you read this, they've already been merged.)


cheers,
brian



From tonyliu0592 at hotmail.com  Fri Sep 11 21:37:15 2020
From: tonyliu0592 at hotmail.com (Tony Liu)
Date: Fri, 11 Sep 2020 21:37:15 +0000
Subject: [Keystone] socket.timeout: timed out
In-Reply-To: <CAKZ_x79PMBohiKq86gd4kP4mao=gyDkCeSw3ycKUW_sTkY8x4w@mail.gmail.com>
References: <MWHPR08MB238261D23CE45D13DA3472ABBD270@MWHPR08MB2382.namprd08.prod.outlook.com>
 <CAKZ_x79PMBohiKq86gd4kP4mao=gyDkCeSw3ycKUW_sTkY8x4w@mail.gmail.com>
Message-ID: <MWHPR08MB2382D3159F881127A335B151BD240@MWHPR08MB2382.namprd08.prod.outlook.com>

memcached load is heavy. I started another thread to get
clarifications. This is not Keystone specific issue.

Thanks!
Tony
> -----Original Message-----
> From: Radosław Piliszek <radoslaw.piliszek at gmail.com>
> Sent: Friday, September 11, 2020 12:08 AM
> To: Tony Liu <tonyliu0592 at hotmail.com>
> Cc: openstack-discuss <openstack-discuss at lists.openstack.org>
> Subject: Re: [Keystone] socket.timeout: timed out
> 
> Hi Tony,
> 
> Well, it looks like memcached just timed out.
> I'd check the load on it.
> 
> -yoctozepto
> 
> On Thu, Sep 10, 2020 at 7:24 PM Tony Liu <tonyliu0592 at hotmail.com> wrote:
> >
> > Any clues on this timeout exception?
> >
> > 2020-09-10 10:10:33.981 28 ERROR
> keystone.server.flask.request_processing.middleware.auth_context [req-
> 534d9855-8113-450d-8f9f-d93c0d961d24 113ee63a9ed0466794e24d069efc302c
> 4c142a681d884010ab36a7ac687d910c - default default] timed out:
> socket.timeout: timed out
> > 2020-09-10 10:10:33.981 28 ERROR
> keystone.server.flask.request_processing.middleware.auth_context
> Traceback (most recent call last):
> > 2020-09-10 10:10:33.981 28 ERROR
> keystone.server.flask.request_processing.middleware.auth_context   File
> "/usr/lib/python3.6/site-
> packages/keystone/server/flask/request_processing/middleware/auth_contex
> t.py", line 103, in _inner
> > 2020-09-10 10:10:33.981 28 ERROR
> keystone.server.flask.request_processing.middleware.auth_context
> return method(self, request)
> > 2020-09-10 10:10:33.981 28 ERROR
> keystone.server.flask.request_processing.middleware.auth_context   File
> "/usr/lib/python3.6/site-
> packages/keystone/server/flask/request_processing/middleware/auth_contex
> t.py", line 353, in process_request
> > 2020-09-10 10:10:33.981 28 ERROR
> keystone.server.flask.request_processing.middleware.auth_context
> resp = super(AuthContextMiddleware, self).process_request(request)
> > 2020-09-10 10:10:33.981 28 ERROR
> keystone.server.flask.request_processing.middleware.auth_context   File
> "/usr/lib/python3.6/site-
> packages/keystonemiddleware/auth_token/__init__.py", line 411, in
> process_request
> > 2020-09-10 10:10:33.981 28 ERROR
> keystone