April 2020 - openstack-discuss - lists.openstack.org

cross distro Virtual PTG planning
by Thomas Goirand 04 May '20

04 May '20

Dear package maintainers, We used to have a cross-distro discussion during each PTG (well, summits, since I didn't attend any PTG since the split). I was wondering if people from other distros would be interested in having such a session again. Please tell if you hare as a follow-up here, then maybe we can add ourselves in the ethercalc. I used to know everyone, like Haikel, people from SuSE, etc. Nowadays, I only know people from Canonical. I'd love to meet the new guys around. Cheers, Thomas Goirand (zigo)

3 2

[cinder] critical bugs/patches for RC-2
by Brian Rosmaita 03 May '20

03 May '20

The proposed list is here: https://etherpad.opendev.org/p/cinder-ussuri-rc-backport-potential Please prioritize your reviewing accordingly. There are several proposed but not approved bugs on the list; I could use some feedback on whether they are release-critical or not. Please reply on the etherpad. thanks, brian

1 2

[all] A call for consolidation and simplification
by Thierry Carrez 01 May '20

01 May '20

Hi all, I'd like to issue a call for consolidation and simplification for OpenStack development. In the early years of the project, we faced a lot of challenges. We had to spread the development load across manageable-size groups, so we encouraged the creation of a lot of project teams. We wanted to capture all the energy that was sent towards the project, so we passed project structure reforms (like the big tent) that would aggressively include new community groups in the "official" OpenStack community. We needed to remove bottlenecks, so we encouraged decentralized decision making. And we had to answer unique challenges, so we created software to match them (Zuul). In summary, we had a lot of people, and not enough systems to organize them, so we created those. Fast-forward to 2020, and our challenges are different. The many systems that we created in the early days have created silos, with very small groups of people working in isolation, making cross-project work more difficult than it should be. The many systems that we created generate a lot of fragmentation. Like we have too many meetings (76, in case you were wondering), too much energy spent running them, too much frustration when nobody joins. Finally, the many systems that we created represent a lot of complexity for newcomers to handle. We have 180 IRC channels, most of them ghost towns where by the time someone answers, the person asking the question is long gone. So I think it's time to generally think about simplifying and consolidating things. It's not as easy as it sounds. Our successful decentralization efforts make it difficult to make the centralized decision to regroup. It's hard to justify time and energy spent to /remove/ things, especially those that we spent time creating in the first place. But we now have too many systems and not enough people, so we need to consolidate and simplify. Back around Havana, when we had around the same number of active contributors as today, we used to have 36 meetings and 20 teams. Do we really need 180 IRC channels, 76 meetings, 63 project teams (not even counting SIGs)? Yes, we all specialized over time, so it's hard to merge for example Oslo + Requirements, or QA + Infrastructure, or Stable + Release Management, or Monasca + Telemetry. We are all overextended so it's hard to learn new tricks or codebases. And yet, while I'm not really sure what the best approach is, I think it's necessary. Comments, thoughts? -- Thierry Carrez (ttx)

9 16

[tripleo] CI
by Wesley Hayutin 01 May '20

01 May '20

Greetings, Status update... Master: GREEN Stable Branches impacted by: https://bugs.launchpad.net/tripleo/+bug/1875890 fixed Now we are trying to promote each branch to level out pacemaker on the node and containers. Queens is promoting now. Train: GREEN Queens: RED ( current priority ) In addition to the pacemaker issue which has resolved in our periodic testing jobs, we're hitting issues w/ instances timing out in tempest https://bugs.launchpad.net/tripleo/+bug/1876087 Stein: RED Also seems to have the same issue as Queens https://bugs.launchpad.net/tripleo/+bug/1876087 ( under investigation for Stein ) Rocky: RED Also seems to have the same issue as Queens https://bugs.launchpad.net/tripleo/+bug/1876087 ( under investigation for Rocky ) I will be promoting Rocky to level out pacemaker next. In order to get the voting jobs in queens back to green, I'm disabling tempest on containers-multinode. https://review.opendev.org/#/c/724703/ Additional notes may be found: https://hackmd.io/1pY-KQB_QwOe-a-5oEXTRg

2 2

[manila][stable] Additions and Removals from stable-core
by Goutham Pacha Ravi 01 May '20

01 May '20

Hello Stackers, I'd like to add a couple of maintainers to manila-stable-maint: https://review.opendev.org/#/admin/groups/1099,members - dviroel (Douglas Viroel) - silvacarlos (Carlos Eduardo) Both Douglas and Carlos understand the stable branch policy [1] and adhere to it. Thanks! Goutham [1] https://docs.openstack.org/project-team-guide/stable-branches.html

4 5

[qa][ptg] Virtual PTG planning
by Masayuki Igawa 30 Apr '20

30 Apr '20

Hi team, Short summary: 1. Please take a look at the QA PTG etherpad[2] and put your name and topics there 2. Please vote on the doodle poll[3] Details: As we discussed in the office hours, we're now collecting topics[3] for the PTG[1]. And, we need to fix our slots for the PTG. We have now 5 topics[2], and we'll have some more, possibly. So, we'll need 2 or 3 hours slots for 2 days or more if we have more topics. Anyway, please fill out the doodle poll[3] if you'd like to participate in the PTG. And, please add your name and topics to the etherpad so that we can discuss them during the following office hours. [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014126.ht… [2] https://etherpad.opendev.org/p/qa-victoria-ptg [3] https://doodle.com/poll/5awstyshtquuwcq3 -- Masayuki

1 2

[manila][ptg] Victoria Cycle PTG in Vancouver - Planning
by Goutham Pacha Ravi 30 Apr '20

30 Apr '20

Hello Zorillas and other interested Stackers, We've requested space to gather at the Open Infrastructure PTG event in Vancouver, BC between June 8th-11th 2020. This event gives us the opportunity to catch up in person (and via telepresence) and discuss the next set of goals for manila and its ecosystem of projects. As has been the norm, there's now a planning etherpad for us to collect topics and vote upon [1]. Depending on how much space/time we are budgeted, we will select and schedule these topics. Please take a look and add your topics to the etherpad. Thanks, Goutham [1] https://etherpad.openstack.org/p/vancouver-ptg-manila-planning

1 1

[tacker][ptg] Virtual PTG Planning
by Yasufumi Ogawa 30 Apr '20

30 Apr '20

Hi Tacker team, As talked in the last IRC meeting, we have decided to have vTPG on 2nd and 3rd June [1]. We have etherpad for the discussion [2], so please add your name and topics if you have any suggestions for the next release. - 02 June: 6am-8am UTC - 03 June: 6am-8am UTC [1] http://eavesdrop.openstack.org/meetings/tacker/2020/tacker.2020-04-28-08.07… [2] https://etherpad.opendev.org/p/Tacker-PTG-Victoria Thanks, Yasufumi

1 0

[openstack-helm][ptg] Virtual PTG Planning
by Gage Hugo 30 Apr '20

30 Apr '20

As we discussed in Tuesday's meeting, we have schedules some tentative time-slots for the virtual PTG across multiple days: Current Time-Slots: - 1300 - 1700 UTC Tue June 2nd - 1300 - 1700 UTC Wed June 3rd We also have an etherpad for topics if anyone has anything they want to discuss. Hope to see you there! https://etherpad.opendev.org/p/openstack-helm-ptg-victoria

1 0

[security][ptg] Virtual PTG Planning
by Gage Hugo 30 Apr '20

30 Apr '20

Hello, As discussed in today's meeting, the Security SIG has scheduled some tentative timeslots for the virtual PTG to discuss any topics. We also have an etherpad to fill out if anyone has anything they want to discuss. Hope to see you there! Current Timeslots: - 1500 - 1700 UTC Mon June 1st 2020 - 2100 - 2300 UTC Mon June 1st 2020 https://etherpad.opendev.org/p/security-sig-ptg-victoria

1 0

[ironic][redfish] Breaking (for us) underlying schema/behavior change and what do we do?
by Julia Kreger 30 Apr '20

30 Apr '20

Greetings fellow awesome sentient beings, and the occasional text indexers! We have a growing conundrum with Redfish. A long time ago, in a red shifted galaxy inhabited by Redfish, a feature was defined early on in the DMTF specification defining a "BootSourceOverrideEnabled" field as part of the ComputerSystem Boot object[0]. This setting, in concert with the "BootSourceOverrideTarget" and "BootSourceOverrideMode" setting allowed Ironic to signal an override preference in regards to what device the machine should boot to. As time as moved forward, schema field descriptions were added, and notes further detailed (observable by looking at [1], see ComputerSystem 1.0.0, 1.5.0, 1.6.0, 1.8.0). One such case, at least depending on what field you looked at also noted that "BootSourceOverrideEnabled" was not possible with the "Continuous" setting, however that was only noted under the one time override option "UefiTargetBootSourceOverride" which is leveraged by the explicit "UEFITarget" target option, at least until ComputerSystem 1.8.0. In ComputerSystem 1.8.0, an explicit note was added into the description text for "BootSourceOverrideEnabled" detailing that one time override use was the only option for UEFI. The published documents also have not been very clear on this, but there are numerous documents on the subject so it seems very easy for the schema details note being added and enhanced in 1.8.0 drove vendors to begin to change the logic around their "BootSourceOverrideEnabled" option to represent what the current documentation detailed, regardless of their schema version. Also, the schema/api versions are disjointed and BMCs out there exist without some of the defined fields. It just kind of is our life with hardware. So why now? The ironic team has had reports recently, across multiple vendors, where with newer firmware versions beginning to implement the changes in schema 1.8.0, where it seems we will no longer be able to use the option we were using, which seemed logical at least when looking at the BMC conformance to the standard. And while some may view the fact it worked on multiple vendors as a regression, I'm sure they see it as a bug as it was seemingly never intended to work that way when we look at the "UEFITargetBootSourceOverride" field notes from the early schemas. tl;dr: As BMC's vendors add the newer schema fields and resulting behavior, the existing redfish driver's ability to assert persistent boot devices breaks. With all of that having been said, I think we should remove our persistent setting capability in our redfish driver, and back port the fix where possible. That being said, this is also a behavior change, so it is time to get everyone's thoughts, since we will need to stress that machines by default should boot from persistent storage instead of network by default. We also need to launch a long term effort to try and duplicate the setting capabilities through the other BMC interfaces/methods/settings, but the variation by vendor is what is going to make it very difficult until the latest redfish schema version is implemented by vendors. Of course, that too may be a while. Thoughts? -Julia [0]: DMTF Redfish Schema Supplement 2019.1a, Page 71: https://www.dmtf.org/sites/default/files/standards/documents/DSP0268_2019.1… or the 2016.2 version of the document, Page 16: https://www.dmtf.org/sites/default/files/standards/documents/DSP2046_2016.2… And the same information can be found in the and 2019.2, 2019.3 schema document versions. [1]: Latest schema bundle pack: https://www.dmtf.org/sites/default/files/standards/documents/DSP8010_2019.4…

2 3

[MURANO] DevStack Murano "yaql_function" Error
by İzzettin Erdem 30 Apr '20

30 Apr '20

Hello folk, Is there anyone who used murano before? I am trying to install Murano on devstack stable/train release. When i try to deploy an environment, it throws an error. At murona-engine logs error is: "func.__yaql_function__ = fd: murano.dsl.dsl_exception.MuranoPlException: [AttributeError]: 'method' object has no attribute '__yaql_function__'" Any suggestioıns? Thanks. Regards.

3 4

[puppet][packaging] Switching to policy.yaml (over policy.json)
by Thomas Goirand 30 Apr '20

30 Apr '20

Hi team! In the light of the discussion that recently happened in #openstack-nova, it looks like switching from a .json file to a .yaml file is what we should do. Indeed, the file generated in .json format, if used pristine with the nova.conf and without enforcing scope, makes a nova-api service that simply doesn't work. Please read https://bugs.launchpad.net/nova/+bug/1875418 for more insights. The issue is that both packages are generating a .json (at least in Debian and Ubuntu) and puppet expect a policy.json, not a policy.yaml. With the policy.yaml, we don't have the same problem as by default, all policies are commented out. Operators just need to uncomment to activate. So, my proposal is the following: before the final release of OpenStack, I will modify all Debian OpenStack packages to generate (and package) both policy.json and policy.yaml. Then puppet-openstack can switch over to the .yaml file, and uncomment only the parts that the operator sees as relevant. I also would like to add a policy.d folder by default in each package, where operators can override stuff. Just having the folder will be a sign to operators that they are invited to write stuff in there, and that it will not be overwritten by a package upgrade. Then what I would like to do, is get puppet-openstack to only write there, for example in /etc/nova/policy.d/my-custom-policy.yaml. The file in /etc/nova/policy.yaml will be marked as "CONFFILE" in Debian, meaning that dpkg will prompt for changes on upgrades, while what's in the policy.d will remain. Last, I do believe that the yaml files are a way more easy to handle with puppet than the .json counterpart. Indeed, we could use something like the .ini management thing, with the : (Semicolumn) sign replacing the = (equal) sign. Moreover, the .yaml files contain comments which the .json files are lacking, making it auto-documented for operators. The only reason why I didn't use .yaml files earlier in the Debian packages was that, somehow, loading them with the API didn't work. I confirm that now it looks like working (though I'd have to test if changing a value is taken into account, I didn't do that yet). Your thoughts everyone? Cheers, Thomas Goirand (zigo)

2 1

[all] Curating the openstack org on GitHub
by Thierry Carrez 30 Apr '20

30 Apr '20

Hi everyone, As you know, for practical and "code marketing" reasons, we maintain mirrors of the opendev.org/openstack repositories on GitHub: https://github.com/openstack/ A few months ago jroll and I took on the task of maintaining the "openstack" organization on GitHub... In particular pushing "moved" final commits to repositories that are now maintained elsewhere on Opendev, and marking them retired. It's all a bit of a challenge. GitHub does not let you set the "mirror" flag by API (you have to ask GitHub support to manually do it, and they don't like it when you ask for it to be set on 1,831 repositories). The "pinned repositories" UI fails miserably and does not let us select "Nova" (again, probably too many repositories, GitHub support does not have a solution for us). There are limited opportunities to describe the fact that we actually only use GitHub as a mirror, leading to confusion. For inactive repositories (no longer under OpenStack governance), the situation is even more confusing. Some are noted "MOVED" or "RETIRED" in their description, some have a closing commit (some others don't), some have the "archived" flag. Some don't have anything and appear active while they are not (see attached CSV for those who like data). There is also the openstack-dev and openstack-attic organizations, which are leftovers from ancient times. In summary, for a "code marketing" opportunity, it does not paint a great picture. I'd like to make the following suggestion: - aggressively delete all non-openstack things from the openstack org, keeping only official, active repositories - delete the openstack-dev and openstack-attic organizations We shied away from doing that in the past, mostly to not break people who may have cloned those repositories... But I think the benefits of cleaning up now outweigh the drawbacks. The reference code always exists at opendev.org anyway. Also maybe once we are back to a more reasonable number of visible repositories, the pins UI will work again. And GitHub will actually be OK with setting the mirror flag. Thoughts, comments ? -- Thierry Carrez (ttx)

13 27

[neutron] network converting from flat to vlan
by Ionut Biru 29 Apr '20

29 Apr '20

Hi guys, I made a mistake a long time ago creating a flat network instead of vlan. Is there a way to convert this network to vlan? Did anyone try to do that and have a procedure in place? I'm running rocky. -- Ionut Biru - https://fleio.com

1 0

[neutron] CI meeting cancelled
by Slawek Kaplonski 29 Apr '20

29 Apr '20

Hi, As 1st of May is Labor Day and public holiday in Poland, I will not be available to chair drivers meeting. Lets cancel it this week. See You all on the meeting next week. Have a great (long) weekend :) -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[TC] Ussuri Virtual Celebration!
by Kendall Nelson 29 Apr '20

29 Apr '20

Hello :) So! Since we won't be able to see each other in June and celebrate the recent release together, is there interest in doing a virtual cheers as a community? We could do something fun like.. trivia or a baking contest or something? I am reaching out to the TC specifically because we would probably want to do more than one of these and spread across all timezones so we could have a TC member or two 'host' the cheers. Can't wait to hear what you all think! -Kendall (diablo_rojo)

9 12

[openstack-helm-infra][elasticsearch]Error deploying chart in k8s cluster with local storage
by Sanjay K 29 Apr '20

29 Apr '20

Hello everyone, I have been trying to deploy elasticsearch helm chart in my k8s cluster consisting of 4 nodes (1 k8s master, 1 controller and 2 computes) after deploying fluentbit and fluentd helm charts which are deployed with success. I have plan to make the EFK (Elasticsearch-Fluentd-Kibana) stack running in my k8s cluster setup for logs management. However I face issues while deploying elasticsearch helm chart using the below command : $ helm install elasticsearch local/elasticsearch --values values_overrides/local-storage.yaml -n openstack Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: ValidationError(StatefulSet.spec): unknown field "strategy" in io.k8s.api.apps.v1.StatefulSetSpec Can anyone point me if I missing anything? What are the prerequisites before deploying elasticsearch chart which intended to use local storage/pv in my case avoiding the default S3 storage as per the chart? Thanks for your pointers and suggestions. ' best regards, SanjayK

2 7

[requirements][all] - requirements is now frozen for non-critical updates
by Matthew Thode 29 Apr '20

29 Apr '20

After the Ussuri-3 milestone, only critical requirements and constraints changes will be allowed. Freezing our requirements list gives packagers downstream an opportunity to catch up and prepare packages for everything necessary for distributions of the upcoming release. The requirements remain frozen until the stable branches are created, with the release candidates. All future changes not previously approved will need a FFE request set to the list, please prefix it with [FFE][requirements][PROJECTNAME]. -- Matthew Thode

1 1

Re: [TripleO][train][rdo] installation of undercloud fails during Run container-puppet tasks step1
by Ruslanas Gžibovskis 29 Apr '20

29 Apr '20

During installation, I can see them running fro 25sec max. not sure if it is as expected, Can I check somehow, how to get them up? if I do podman run -it Image_ID will it be enough to test if images are good? On Wed, 29 Apr 2020 at 12:01, Wu, Heng <wuh.fnst(a)cn.fujitsu.com> wrote: > > I am new to containers, can I somehow transfer these images between, as > I understand, it might help? > > > > The image will be downloaded automatically with the installation, you > don't need to do it manually. > > The problem seems to be that the container failed to start, not the errors > in the images themselves. > > You may need to check the configuration of undercloud.conf and proxy > settings (if they exist). > > > > *From:* Ruslanas Gžibovskis <ruslanas(a)lpic.lt> > *Sent:* 2020年4月29日 15:48 > *To:* Alex Schultz <aschultz(a)redhat.com> > *Cc:* Openstack-discuss <openstack-discuss(a)lists.openstack.org>; > kent.martin(a)ericsson.com > *Subject:* Re: [TripleO][train][rdo] installation of undercloud fails > during Run container-puppet tasks step1 > > > > On the other installation I have, I see a bit more images: > > > > > I am new to containers, can I somehow transfer these images between, as I > understand, it might help? > > > > On Wed, 29 Apr 2020 at 09:45, Ruslanas Gžibovskis <ruslanas(a)lpic.lt> > wrote: > > I just now realized, that I have seen in some log, messages, missing some > puppet-dependencies... Cannot find log again... > > > > On Wed, 29 Apr 2020 at 09:39, Ruslanas Gžibovskis <ruslanas(a)lpic.lt> > wrote: > > podman ps -a = clean, no containers at all. > > I have a watch -d "sudo podman ps -a ; sudo podman images -a ; sudo df -h" > > > > paunch.log is empty. (I did several reinstallations). > > > > > > > Later I saw connectionpool retrying, but I have not seen " > tripleo_common.image.image_uploader" with same. > > > > > > > On Tue, 28 Apr 2020 at 20:10, Alex Schultz <aschultz(a)redhat.com> wrote: > > On Tue, Apr 28, 2020 at 11:57 AM Ruslanas Gžibovskis <ruslanas(a)lpic.lt> > wrote: > > > > Hi all, > > > > I am running a fresh install of rdo train, on centos7 > > I almost a week I am facing error at this step: > > TASK [Run container-puppet tasks (generate config) during step 1] > > > > So I have ansible.log attached, I cannot find anything, where it is > failing. > > According to some understanding in ansible, it fails if it finds stderr > output. > > I cannot find error/fail or smth, I see Notices and Warnings, but I > believe it is not stderr? > > > > I see containers running and removed after some time. > > (as it should be I think)... > > > > Could you help me, where to dig? > > > > 2020-04-27 22:27:46,147 p=132230 u=root | TASK [Start containers for > step 1 using paunch] > > ***************************************************************************************************************************** > 2020-04-27 22:27:46,148 p=132230 u=root | Monday 27 April 2020 > 22:27:46 +0200 (0:00:00.137) 0:04:44.326 **********? > 2020-04-27 22:27:46,816 p=132230 u=root | ok: [remote-u] > 2020-04-27 22:27:46,914 p=132230 u=root | TASK [Debug output for > task: Start containers for step 1] > > ******************************************************************************************************************* > 2020-04-27 22:27:46,915 p=132230 u=root | Monday 27 April 2020 > 22:27:46 +0200 (0:00:00.767) 0:04:45.093 **********? > 2020-04-27 22:27:46,977 p=132230 u=root | fatal: [remote-u]: FAILED! => { > "failed_when_result": true,? > "outputs.stdout_lines | default([]) | union(outputs.stderr_lines | > default([]))": [] > > Check /var/log/paunch.log. It probably has additional information as > to why the containers didn't start. You might also check the output > of 'sudo podman ps -a' to see if any containers exited with errors. > > > -- > > Ruslanas Gžibovskis > > +370 6030 7030 > > > > > -- > > Ruslanas Gžibovskis > +370 6030 7030 > > > > > -- > > Ruslanas Gžibovskis > +370 6030 7030 > > > > > -- > > Ruslanas Gžibovskis > +370 6030 7030 > -- Ruslanas Gžibovskis +370 6030 7030

1 1

[neutron] CI meeting
by Slawek Kaplonski 29 Apr '20

29 Apr '20

Hi, Sorry for late notice but I totally forgot about it. I need to cancel today's Neutron CI meeting. There is RH Summit going on and I have some sessions which I want to attend during our CI meeting. I checked grafana, and I don't see any urgent issues related to our CI so lets cancel this meeting and see You all next week :) -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[Neutron] Cancel neutron L3 meeting
by LIU Yulong 29 Apr '20

29 Apr '20

Hi there, Because I have to some local workload, I will not be able to run the L3 meeting tonight. And I'm going to take a vacation next week. So the next L3 meeting will be set on 13th May 2020. See you guys online then. Regards, LIU Yulong

1 0

Re: [TripleO][train][rdo] installation of undercloud fails during Run container-puppet tasks step1
by Ruslanas Gžibovskis 29 Apr '20

29 Apr '20

Moving output to pastebin I have found it very interesting, that I was able to download images by running some pull commands (below), podman images -a show it, but the installation still gets 401 errors. http://paste.debian.net/1143698/ > > On Wed, 29 Apr 2020 at 09:47, Ruslanas Gžibovskis <ruslanas(a)lpic.lt> > wrote: > >> On the other installation I have, I see a bit more images: >> >> I am new to containers, can I somehow transfer these images between, as I >> understand, it might help? >> >> On Wed, 29 Apr 2020 at 09:45, Ruslanas Gžibovskis <ruslanas(a)lpic.lt> >> wrote: >> >>> I just now realized, that I have seen in some log, messages, missing >>> some puppet-dependencies... Cannot find log again... >>> >>> On Wed, 29 Apr 2020 at 09:39, Ruslanas Gžibovskis <ruslanas(a)lpic.lt> >>> wrote: >>> >>>> podman ps -a = clean, no containers at all. >>>> I have a watch -d "sudo podman ps -a ; sudo podman images -a ; sudo df >>>> -h" >>>> >>>> paunch.log is empty. (I did several reinstallations). >>>> >>>> I found in image logs: >>>> 2020-04-29 08:52:49,854 140572 DEBUG urllib3.connectionpool [ ] >>>> https://registry-1.docker.io:443 "GET /v2/ HTTP/1.1" 401 87 >>>> 2020-04-29 08:52:49,855 140572 DEBUG >>>> tripleo_common.image.image_uploader [ ] >>>> https://registry-1.docker.io/v2/ status code 401 >>>> 2020-04-29 08:52:49,855 140572 DEBUG >>>> tripleo_common.image.image_uploader [ ] Token parameters: params {'scope': >>>> 'repository:tripleotrain/centos-binary-zaqar-wsgi:pull', 'service': ' >>>> registry.docker.io'} >>>> >>>> Later I saw connectionpool retrying, but I have not seen " >>>> tripleo_common.image.image_uploader" with same. >>>> >>>> On Tue, 28 Apr 2020 at 20:10, Alex Schultz <aschultz(a)redhat.com> wrote: >>>> >>>>> On Tue, Apr 28, 2020 at 11:57 AM Ruslanas Gžibovskis <ruslanas(a)lpic.lt> >>>>> wrote: >>>>> > >>>>> > Hi all, >>>>> > >>>>> > I am running a fresh install of rdo train, on centos7 >>>>> > I almost a week I am facing error at this step: >>>>> > TASK [Run container-puppet tasks (generate config) during step 1] >>>>> > >>>>> > So I have ansible.log attached, I cannot find anything, where it is >>>>> failing. >>>>> > According to some understanding in ansible, it fails if it finds >>>>> stderr output. >>>>> > I cannot find error/fail or smth, I see Notices and Warnings, but I >>>>> believe it is not stderr? >>>>> > >>>>> > I see containers running and removed after some time. >>>>> > (as it should be I think)... >>>>> > >>>>> > Could you help me, where to dig? >>>>> > >>>>> >>>>> 2020-04-27 22:27:46,147 p=132230 u=root | TASK [Start containers for >>>>> step 1 using paunch] >>>>> >>>>> ***************************************************************************************************************************** >>>>> 2020-04-27 22:27:46,148 p=132230 u=root | Monday 27 April 2020 >>>>> 22:27:46 +0200 (0:00:00.137) 0:04:44.326 **********? >>>>> 2020-04-27 22:27:46,816 p=132230 u=root | ok: [remote-u] >>>>> 2020-04-27 22:27:46,914 p=132230 u=root | TASK [Debug output for >>>>> task: Start containers for step 1] >>>>> >>>>> ******************************************************************************************************************* >>>>> 2020-04-27 22:27:46,915 p=132230 u=root | Monday 27 April 2020 >>>>> 22:27:46 +0200 (0:00:00.767) 0:04:45.093 **********? >>>>> 2020-04-27 22:27:46,977 p=132230 u=root | fatal: [remote-u]: FAILED! >>>>> => { >>>>> "failed_when_result": true,? >>>>> "outputs.stdout_lines | default([]) | union(outputs.stderr_lines | >>>>> default([]))": [] >>>>> >>>>> Check /var/log/paunch.log. It probably has additional information as >>>>> to why the containers didn't start. You might also check the output >>>>> of 'sudo podman ps -a' to see if any containers exited with errors. >>>>> >>>>> -- Ruslanas Gžibovskis +370 6030 7030

1 0

[all][TC][PTL][release] Ussuri Community Meeting Proposal
by Allison Price 28 Apr '20

28 Apr '20

Hi everyone, As we prepare for the upcoming Ussuri release on May 13, I wanted to see if there was interest among the community to do a community meeting with folks presenting release highlights / answering questions that people may have. We were thinking that atleast one member from the TC or release management team could moderate the discussion and call on various PTLs to present what their teams accomplished during this cycle. If possible, we could do one that is around 1400 UTC to hit Europe and the United States and potentially another one around 0200 UTC for APAC, so we may need two volunteers. We would also like to promote Ussuri demos in the release comms, including the landing page and promotional materials. If you are planning to do a demo or would like to, please let me know and we can include it on the Ussuri landing page. Let me know what y’all think about doing a community meeting and if particular folks would like to volunteer to moderate and / or present. Looking forward to hearing feedback, and, in particular, if anyone is interested in volunteering to help moderate or participate in the Ussuri focused community meeting. Thanks! Allison Allison Price OpenStack Foundation allison(a)openstack.org <mailto:allison@openstack.org>

7 12

[magnum] issues with cloud-init and user-data on fedora-atomic image
by Jean-Philippe Méthot 28 Apr '20

28 Apr '20

Hi, I’ve been testing out magnum (rocky) in my staging environment and I’ve been running into an issue I can’t really explain. Essentially, Magnum is able to provision all the VMs it needs according to the template. However, when it comes time to install kubernetes through cloud-init, cloud-init is unable to fetch the user-data. I must specify that ONLY the user-data is affected. Everything else that’s read from the metadata gets through without any issue. I can also do 'curl http://169.254.169.254/2009-04-04/' <http://169.254.169.254/2009-04-04/'> from the VM without any issue. When I try to curl http://169.254.169.254/2009-04-04/user-data <http://169.254.169.254/2009-04-04/user-data> , curl just hangs without any data showing up : sudo curl -v http://169.254.169.254/2009-04-04/user-data * Trying 169.254.169.254... * TCP_NODELAY set * Connected to 169.254.169.254 (169.254.169.254) port 80 (#0) > GET /2009-04-04/user-data HTTP/1.1 > Host: 169.254.169.254 > User-Agent: curl/7.59.0 > Accept: */* Tcpdump -vvv looks like this : sudo tcpdump -vvv -i eth0 host 169.254.169.254 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 20:36:22.284195 IP (tos 0x0, ttl 64, id 11248, offset 0, flags [DF], proto TCP (6), length 60) kubernetes-cluster-f4anhakchpkj-minion-0.staging.planethoster.ne.56896 > 169.254.169.254.http: Flags [S], cksum 0x5e34 (incorrect -> 0x51a5), seq 2359174217, win 26730, options [mss 8910,sackOK,TS val 583688334 ecr 0,nop,wscale 7], length 0 20:36:22.284793 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 169.254.169.254.http > kubernetes-cluster-f4anhakchpkj-minion-0.staging.planethoster.ne.56896: Flags [S.], cksum 0x9ed1 (correct), seq 2099498427, ack 2359174218, win 26694, options [mss 8910,sackOK,TS val 4068504964 ecr 583688334,nop,wscale 9], length 0 20:36:22.284875 IP (tos 0x0, ttl 64, id 11249, offset 0, flags [DF], proto TCP (6), length 52) kubernetes-cluster-f4anhakchpkj-minion-0.staging.planethoster.ne.56896 > 169.254.169.254.http: Flags [.], cksum 0x5e2c (incorrect -> 0x522e), seq 1, ack 1, win 209, options [nop,nop,TS val 583688335 ecr 4068504964], length 0 20:36:22.284962 IP (tos 0x0, ttl 64, id 11250, offset 0, flags [DF], proto TCP (6), length 151) kubernetes-cluster-f4anhakchpkj-minion-0.staging.planethoster.ne.56896 > 169.254.169.254.http: Flags [P.], cksum 0x5e8f (incorrect -> 0xb692), seq 1:100, ack 1, win 209, options [nop,nop,TS val 583688335 ecr 4068504964], length 99: HTTP, length: 99 GET /2009-04-04/user-data HTTP/1.1 Host: 169.254.169.254 User-Agent: curl/7.59.0 Accept: */* 20:36:22.325212 IP (tos 0x0, ttl 64, id 47160, offset 0, flags [DF], proto TCP (6), length 52) 169.254.169.254.http > kubernetes-cluster-f4anhakchpkj-minion-0.staging.planethoster.ne.56896: Flags [.], cksum 0x523e (correct), seq 1, ack 100, win 53, options [nop,nop,TS val 4068505005 ecr 583688335], length 0 20:36:33.546523 IP (tos 0x0, ttl 64, id 11251, offset 0, flags [DF], proto TCP (6), length 52) kubernetes-cluster-f4anhakchpkj-minion-0.staging.planethoster.ne.56896 > 169.254.169.254.http: Flags [F.], cksum 0x5e2c (incorrect -> 0x25a4), seq 100, ack 1, win 209, options [nop,nop,TS val 583699596 ecr 4068505005], length 0 20:36:33.586154 IP (tos 0x0, ttl 64, id 47169, offset 0, flags [DF], proto TCP (6), length 52) 169.254.169.254.http > kubernetes-cluster-f4anhakchpkj-minion-0.staging.planethoster.ne.56896: Flags [.], cksum 0x91fc (correct), seq 26695, ack 101, win 53, options [nop,nop,TS val 4068516266 ecr 583699596], length 0 So the instance does receive packets as a reply to the curl, but they’re empty. I have tested on both Fedora-Atomic-27-20180212.2.x86_64.qcow2 and Fedora-AtomicHost-28-20180425.0.x86_64.qcow2 images and reproduced the issue both times. Nova-api and neutron-metadata logs show http 200 for each of my requests to nova. What could be blocking the user-data from reaching the instance in this case? Is there a way to set magnum-created intances to use configdrive instead? I must also specify that user-data works on all regular instances. It’s only affecting instances created by magnum. Best regards, Jean-Philippe Méthot Senior Openstack system administrator Administrateur système Openstack sénior PlanetHoster inc.

1 0