May 2020 - openstack-discuss - lists.openstack.org

[stein][neutron] gratuitous arp
by Ignazio Cassano 13 May '21

13 May '21

Hello, I have a problem on stein neutron. When a vm migrate from one node to another I cannot ping it for several minutes. If in the vm I put a script that ping the gateway continously, the live migration works fine and I can ping it. Why this happens ? I read something about gratuitous arp. Please, help me ? Any workaround , please ? Best Regards Ignazio

3 33

Re: [openstack-dev] Are we ready to put stable/ocata into extended maintenance mode?
by Alex Schultz 03 Mar '21

03 Mar '21

On Tue, Sep 18, 2018 at 1:30 PM Alex Schultz <aschultz(a)redhat.com> wrote: > > On Tue, Sep 18, 2018 at 1:27 PM, Matt Riedemann <mriedemos(a)gmail.com> wrote: > > The release page says Ocata is planned to go into extended maintenance mode > > on Aug 27 [1]. There really isn't much to this except it means we don't do > > releases for Ocata anymore [2]. There is a caveat that project teams that do > > not wish to maintain stable/ocata after this point can immediately end of > > life the branch for their project [3]. We can still run CI using tags, e.g. > > if keystone goes ocata-eol, devstack on stable/ocata can still continue to > > install from stable/ocata for nova and the ocata-eol tag for keystone. > > Having said that, if there is no undue burden on the project team keeping > > the lights on for stable/ocata, I would recommend not tagging the > > stable/ocata branch end of life at this point. > > > > So, questions that need answering are: > > > > 1. Should we cut a final release for projects with stable/ocata branches > > before going into extended maintenance mode? I tend to think "yes" to flush > > the queue of backports. In fact, [3] doesn't mention it, but the resolution > > said we'd tag the branch [4] to indicate it has entered the EM phase. > > > > 2. Are there any projects that would want to skip EM and go directly to EOL > > (yes this feels like a Monopoly question)? > > > > I believe TripleO would like to EOL instead of EM for Ocata as > indicated by the thead > http://lists.openstack.org/pipermail/openstack-dev/2018-September/134671.ht… > Bringing this backup to see what we need to do to get the stable/ocata branches ended for the TripleO projects. I'm bringing this up because we have https://review.openstack.org/#/c/647009/ which is for the upcoming rename but CI is broken and we have no interest in continue to keep the stable/ocata branches alive (or fix ci for them). Thanks, -Alex > Thanks, > -Alex > > > [1] https://releases.openstack.org/ > > [2] > > https://docs.openstack.org/project-team-guide/stable-branches.html#maintena… > > [3] > > https://docs.openstack.org/project-team-guide/stable-branches.html#extended… > > [4] > > https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.… > > > > -- > > > > Thanks, > > > > Matt > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

5 11

Fwd: [MURANO] DevStack Murano "yaql_function" Error
by İzzettin Erdem 01 Nov '20

01 Nov '20

Thanks Andy. Regards. Forwarded Conversation Subject: [MURANO] DevStack Murano "yaql_function" Error ------------------------ Gönderen: Andy Botting <andy(a)andybotting.com> Date: 30 Nis 2020 Per, 14:13 To: İzzettin Erdem <root.mch(a)gmail.com> Cc: Rong Zhu <aaronzhu1121(a)gmail.com>, < openstack-discuss(a)lists.openstack.org> Hi İzzettin, Thanks for your interest. Complete log link is at below. It is happening > when i try to deploy or update an environment. > > http://paste.openstack.org/show/792444/ > I've encountered the error AttributeError: 'method' object has no attribute '__yaql_function__' in our environment recently. I believe it started after we upgraded to the Stein release. I haven't tracked it down yet, but calls to the YAQL function: std:Project.getEnvironmentOwner() in a Murano app seem to generate it. It's good to know that at least someone else has reproduced this. cheers, Andy ---------- Gönderen: İzzettin Erdem <root.mch(a)gmail.com> Date: 2 May 2020 Cmt, 16:08 To: Andy Botting <andy(a)andybotting.com> Hi Andy, I solved this problem, it is happening when you try to create or update an environment on existing network. If you change the network with "create new" parameter, it stuck on "creating -or updating- environment" state and after that throws connection error. So i searched Murano network errors and i found this: https://docs.oracle.com/cd/E73172_01/E73173/html/issue-21976631.html. I applied these steps and i created successfully an environment just only with "create new" network parameter. After all these, i realized my devstack environment has no internet connection and because of this murano-agent could not install. So i tried to install Murano on my OSA stable/train test environment and i came with success until last step. Murano-agent installed but this time agent could not connect to rabbitmq instance. I discussed this with OSA IRC channel and i think i have to struggle with this for a long time. Apologize for this long mail but i wanted to inform you. Thanks. Regards. ---------- Gönderen: Andy Botting <andy(a)andybotting.com> Date: 3 May 2020 Paz, 14:24 To: İzzettin Erdem <root.mch(a)gmail.com> Hi İzzettin, Glad you got it sorted. I think you've probably just worked around the issue. Using your new method, you're probably just avoiding the std:Project.getEnvironmentOwner YAQL call now. I've also worked around it in our environment, but I'd like to solve it properly. When I get some time to look into it properly, I'll let you know. cheers, Andy

3 3

[ceilometer][octavia] polling meters
by Ionut Biru 14 Jul '20

14 Jul '20

Hello guys, I was trying to add in polling.yaml and pipeline from ceilometer the following: - network.services.lb.active.connections - network.services.lb.health_monitor - network.services.lb.incoming.bytes - network.services.lb.listener - network.services.lb.loadbalancer - network.services.lb.member - network.services.lb.outgoing.bytes - network.services.lb.pool - network.services.lb.total.connections But it doesn't work, I think they are for the old lbs that were supported in neutron. I found https://docs.openstack.org/ceilometer/latest/admin/telemetry-dynamic-pollst… but this is not available in stein or train. I was wondering if there is a way to meter loadbalancers from octavia. I mostly want for start to just meter if a loadbalancer was deployed and has status active. -- Ionut Biru - https://fleio.com

3 17

[all][stable] Moving the stable/ocata to 'Unmaintained' phase and then EOL
by Ghanshyam Mann 02 Jul '20

02 Jul '20

Hello Everyone, Ocata is in the 'Extended Maintenance' phase[1] but its gate is broken and difficult to fix now. The main issue started for gate is about Tempest and its deps constraint is correctly used on Ocata or not. We fixed most of those issues when things started failing during py2 drop[2]. But now things are broken due to newer stestr is installed in Ocata jobs[2]. As Sean also mentioned in this backport[4] that stestr is not constraint in Ocata[5] as it was not in g-r that time so cannot be added in u-c. Tempest old tag cannot be fixed to have that with cap on the tempest side. The only option left to unblock the gate is to remove the integration testing from Ocata gate. But it will untested after that as we cannot say unit testing is enough to mark it tested. At least from QA perspective, I would not say it is tested if there is no integration job running there. Keeping it untested (no integration testing) and saying it is Maintained in the community can be very confusing things. I think its time to move it to the 'Unmaintained' phase and then EOL. Thought? [1] https://releases.openstack.org/ [2] https://review.opendev.org/#/q/topic:fix-stable-gate+(status:open+OR+status… [3] https://zuul.opendev.org/t/openstack/build/e477d0919ff14eea9cd8a6235ea00c3d… [4] https://review.opendev.org/#/c/726931/ [5] https://opendev.org/openstack/requirements/src/branch/stable/ocata/upper-co… -gmann

8 12

[tc][election] campaign discussion: how TC can solve the less contributor issue?
by Ghanshyam Mann 22 Jun '20

22 Jun '20

This topic is a very important and critical area to solve in the OpenStack community. I personally feel and keep raising this issue wherever I get the opportunity. To develop or maintain any software, the very first thing we need is to have enough developer resources. Without enough developers (either open or closed source), none of the software can survive. OpenStack current situation on contributors is not the same as it was few years back. Almost every project is facing the less contributor issue as compare to requirements and incoming requests. Few projects already dead or going to be if we do not solve the less contributors issue now. I know, TC is not directly responsible to solve this issue but we should do something or at least find the way who can solve this. What do you think about what role TC can play to solve this? What platform or entity can be used by TC to raise this issue? or any new crazy Idea? -gmann

14 26

[all][InteropWG] Request to review tests your Distro for 2020.06 draft guidelines
by prakash RAMCHANDRAN 18 Jun '20

18 Jun '20

Hi all, Please review your tests for Draft 2020.06 guidelines to be proposed to Board.You can do that on and should start appearing in next 24-48 hours depending on Zuulhttps://refstack.openstack.org/#/community_results Plus please register for InteropWG PTG meet on June 1 st 6AM-*AM PDT slot See etherpadsPTG eventhttps://etherpad.opendev.org/p/interop_virtual_ptg_planning_june_2020S… invite Tempest, TC members, QA/API SIG teams, Edge SIG WG , Baremetal SIG (for Ironic), K8s SIG (for OoK / KoO) & Scientific SIG teams. Other discussions https://etherpad.opendev.org/p/interop2020 Welcome to join weekly Friday Meetings (Refer NA/EU/APJ in etherpad below) https://etherpad.opendev.org/p/interop Appreciate all support from committee and special appreciation to Mark T Voelker for providing the bridge.He has been immensely valuable in bringing as Vice Chair the wealth of history to enable this Interop WG. ThanksPrakash

2 3

Openstack user surver - questions
by Slawek Kaplonski 17 Jun '20

17 Jun '20

Hi, First of all sorry if I didn't look for it long enough but I have couple of questions about user surver and I couldn't find answer for them anywhere. 1. I was looking at [1] for some Neutron related data and I found only one questions about used backends in "Deployment Decisions". Problem is that this graph is for me a bit unreadable due to many things on x-axis which overlaps each other. Is there any place where I can find some "raw data" to check? 2. Another question about the same chart is: is there any way to maybe change possible replies in the surver for next years? I'm asking about that becasue I have a feeling that e.g. responses "Open vSwitch" and "ML2 - Open vSwitch" may be confusing for users. My understanding is that "Open vSwitch" means simply old "Open vSwitch" core plugin instead of ML2 plugin but this old plugin was removed around "Libery" cycle so I really don't think that still 37% of users are using it. 3. Is there any way to propose new, more detailed questions about e.g Neutron? For example what service plugins they are using. [1] https://www.openstack.org/analytics -- Slawek Kaplonski Senior software engineer Red Hat

2 4

[tc][uc][all] Starting community-wide goals ideas for V series
by Ghanshyam Mann 15 Jun '20

15 Jun '20

Hello everyone, We are in R14 week of Ussuri cycle which means It's time to start the discussions about community-wide goals ideas for the V series. Community-wide goals are important in term of solving and improving a technical area across OpenStack as a whole. It has lot more benefits to be considered from users as well from a developers perspective. See [1] for more details about community-wide goals and process. We have the Zuulv3 migration goal already accepted and pre-selected for v cycle. If you are interested in proposing a goal, please write down the idea on this etherpad[2] - https://etherpad.openstack.org/p/YVR-v-series-goals Accordingly, we will start the separate ML discussion over each goal idea. Also, you can refer to the backlogs of community-wide goals from this[3] and ussuri cycle goals[4]. NOTE: TC has defined the goal process schedule[5] to streamlined the process and ready with goals for projects to plan/implement at the start of the cycle. I am hoping to start that schedule for W cycle goals. [1] https://governance.openstack.org/tc/goals/index.html [2] https://etherpad.openstack.org/p/YVR-v-series-goals [3] https://etherpad.openstack.org/p/community-goals [4] https://etherpad.openstack.org/p/PVG-u-series-goals [5] https://governance.openstack.org/tc/goals/#goal-selection-schedule -gmann

10 22

[all][infra] Upcoming removal of preinstalled pip and virtualenv from base images
by Ian Wienand 14 Jun '20

14 Jun '20

Hello, This is to notify the community of the planned upcoming removal of the "pip-and-virtualenv" element from our infra image builds. This is part of the "cleanup test node python" spec documented at [1]. tl;dr ----- - pip and virtualenv tools will no longer be pre-installed on the base images we use for testing, but will be installed by jobs themselves. - most current jobs will depend on common Zuul base jobs that have been updated to install these tools already *i.e. in most cases there should be nothing to do* - in general, jobs should ensure they depend on roles that install these tools if they require them - if you do find your job failing due to the lack of either of these tools, use the ensure-pip or ensure-virtualenv roles provided in zuul-jobs - we have "-plain" node types that implement this now. If you think there might be a problem, switch the job to run run against one of these node types described below for testing. History ------- The "pip-and-virtualenv" element is part of diskimage-builder [2] and installs the latest version of pip and virtualenv, and related tools like setuptools, into the system environment for the daily builds. This has a long history of working around various issues, but has become increasingly problematic to maintain. One of the more noticable effects is that to prevent the distribution packages overwriting the upstream installs, we put various pip, setuptools and virtualenv packages on "hold" in CI images. This prevents tests resinstalling packaged tools which can create, in short, a big mess. Both destroying the extant environment and having the tools on hold have been problems for various projects at various times. Another other problem is what happens when you call "pip" or "virtualenv" has diverged. It used to be that "pip" would install the package under Python2, while pip3 would install under python3. However, modern distributions now have "pip" installing under Python 3. To keep having "pip" install Python 2 packages on these platforms is not just wrong, but drags in Python 2 dependences to our images that aren't required. The addition of Python 3's venv and the split with virtualenv makes things even more confusing again. Future ------ As famously said "the only winning move is not to play". [3] By dropping this element, images will not have non-packaged pip/virtualenv/setuptools/etc. pre-installed. No packages will be on hold. The "ensure-pip" role [4] will ensure that dependencies for "pip:" commands will work. Because of the way base jobs are setup, it is most likely that this role has already run. If you wish to use a virtual environment to install a tool, I would suggest using the "ensure_pip_virtualenv_cmd" this role exports. This will default to "python3 -m venv". An example is [5]. In a Python 3 word, you probably do not *need* virtualenv; "python3 -m venv" is available and works after the "ensure-pip" role is run. However, if you require some of the features that virtualenv provides that venv does not (explained at [6]) there is a role "ensure-virtualenv" [7]. For example, we do this on the devstack branches because it is common to use "virtualenv" there due to the long history [8]. If you need specific versions of pip or virtualenv, etc. beyond the system-packaged versions installed with the above, you should have your job configure these. There is absolutely no problem with jobs installing differing versions of pip/virtuatlenv/etc in any way they want -- we just don't want the base images to have any of that by default. Of course, you should consider if you're building/testing something that is actually useful outside the gate, but that is a global concern. Testing ------- We have built parallel nodes with the suffix "-plain" where you can test any jobs in the new environment. For example [9] speculatively tests devstack. The node types available are centos-7-plain centos-8-plain ubuntu-xenial-plain ubuntu-bionic-plain The newer focal images do not have pip pre-installed, neither do the faster moving Fedora images, any SUSE images, or any ARM64 images. Rollout ------- We would like to make the switch soon, to shake out any issues early in the cycle. This would mean on or about the 8th June. Thanks, -i [1] https://docs.opendev.org/opendev/infra-specs/latest/specs/cleanup-test-node… [2] https://opendev.org/openstack/diskimage-builder/src/branch/master/diskimage… [3] https://en.wikipedia.org/wiki/WarGames [4] https://zuul-ci.org/docs/zuul-jobs/python-roles.html#role-ensure-pip [5] https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/bindep/tasks/ins… [6] https://virtualenv.pypa.io/en/latest/ [7] https://zuul-ci.org/docs/zuul-jobs/python-roles.html#role-ensure-virtualenv [8] https://opendev.org/openstack/devstack/commit/23cfb9e6ebc63a4da4577c0ef9e34… [9] https://review.opendev.org/#/c/712211/11/.zuul.yaml

3 3

[oslo] Ping List for Victoria
by Ben Nemec 08 Jun '20

08 Jun '20

Hi, With the start of a new cycle, we refresh our courtesy ping list for the start of the meeting. We do this to avoid spamming people who may no longer be working on Oslo but haven't explicitly removed their name from the ping list. To that end, I've added a new ping list above the agenda template[0]. If you wish to continue receiving courtesy pings, please add your name there. In a couple of weeks we will switch to using this new list. Thanks. -Ben 0: https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_Template

1 1

[kolla-ansible] Proposing Doug Szumski as Kolla Ansible core
by Radosław Piliszek 05 Jun '20

05 Jun '20

Hi Folks! This mail serves to propose Doug Szumski from StackHPC (dougsz @IRC, CC'ed) as Kolla Ansible core. Doug coauthored the Nova cells support and helps greatly with monitoring and logging facilities available in Kolla. Please give your feedback in this thread. If there are no objections, I will add Doug after a week from now (that is roughly when PTG is over). -yoctozepto

9 9

[nova][ptg] virtual PTG
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, I need to book slots for nova discussions on the official schedule[2] of the virtual PTG[1]. I need two things to do that: 1) What topics we have that needs real-time discussion. Please add those to the etherpad [3] 2) Who wants to join such real-time discussion and what time slots works for you. Please fill the doodle[4] Based on the current etherpad content we need 2-3 slots for nova discussion and a half slot for cross project (current neutron) discussion. Please try to provide your topics and options before the Thursday's nova meeting. Cheers, gibi [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014126.ht… [2] https://ethercalc.openstack.org/126u8ek25noy [3] https://etherpad.opendev.org/p/nova-victoria-ptg [4] https://doodle.com/poll/ermn3vxy9v53aayy

1 5

[nova][neutron][ptg] How to increase the minimum bandwidth guarantee of a running instance
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] As a next step in the minimum bandwidth QoS support I would like to solve the use case where a running instance has some ports with minimum bandwidth but then user wants to change (e.g. increase) the minimum bandwidth used by the instance. I see two generic ways to solve the use case: Option A - interface attach --------------------------- Attach a new port with minimum bandwidth to the instance to increase the instance's overall bandwidth guarantee. This only impacts Nova's interface attach code path: 1) The interface attach code path needs to read the port's resource request 2) Call Placement GET /allocation_candidates?in_tree=<compute RP of the instance> 3a) If placement returns candidates then select one and modify the current allocation of the instance accordingly and continue the existing interface attach code path. 3b) If placement returns no candidates then there is no free resource left on the instance's current host to resize the allocation locally. Option B - QoS rule update -------------------------- Allow changing the minimum bandwidth guarantee of a port that is already bound to the instance. Today Neutron rejects such QoS rule update. If we want to support such update then: * either Neutron should call placement allocation_candidates API and the update the instance's allocation. Similarly what Nova does in Option A. * or Neutron should tell Nova that the resource request of the port has been changed and then Nova needs to call Placement and update instance's allocation. The Option A and Option B are not mutually exclusive but still I would like to see what is the preference of the community. Which direction should we move forward? Both options have the limitation that if the instance's current host does not have enough free resources for the requested change then Nova will not do a full scheduling and move the instance to another host where resource is available. This seems a hard problem to me. Do you have any idea how can we remove / ease this limitation without boiling the ocean? For example: Does it make sense to implement a bandwidth weigher in the scheduler so instances can be spread by free bandwidth during creation? Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg

3 6

[nova][neutron][ptg] Future of the routed network support
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] There is only basic scheduling support in nova for the neutron routed networks feature (server create with port.ip_allocation=deferred seems to work). There was multiple attempts in the past to complete the support (e.g.server create with port.ip_allocation=immediate or server move operations). The latest attempt started by Matt couple of cycles ago, and in the last cycle I tried to push that forward[1]. When I added this topic to the PTG etherpad I thought I will have time in the Victoria cycle to continue [1] but internal priorities has changed. So finishing this feature needs some developers. If there are volunteers for Victoria then please let me know and then we can keep this as a topic for the PTG but otherwise I will remove it from the schedule. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://review.opendev.org/#/q/topic:routed-networks-scheduling

2 2

[nova][ptg] Can we close old bugs?
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] We have more than 800 open bugs in nova [1] and the oldest is 8 years old. Can we close old bugs? If yes, what would be the closing criteria? Age and status? Personally I would close every bug that is not updated in the last 3 years and not in INPROGRESS state. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://bugs.launchpad.net/nova/+bugs?field.searchtext=&orderby=-importance…

5 7

[nova][ptg] bumping compute RPC to 6.0
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] Do we want to bump the compute RPC to 6.0 in Victoria? We did not have the full view what we can gain[2] with such bump so Stephen and I searched through nova and collected the things we could clean up [1] eventually if we bump the compute RPC to 6.0 in Victoria. I can work on the RPC 6.0 patch during V and I think I can also help in with the possible cleanups later. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://etherpad.opendev.org/p/compute-rpc-6.0 [2] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-04-16-16.00.log…

3 4

[nova][ptg] Runway process in Victoria
by Balázs Gibizer 04 Jun '20

04 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] In the last 4 cycles we used a process called runway to focus and timebox of the team's feature review effort. However compared to the previous cycles in ussuri we did not really keep the process running. Just compare the length of the Log section of each etherpad [1][2][3][4] to see the difference. So I have two questions: 1) Do we want to keep the process in Victoria? 2) If yes, how we can make the process running? 2.1) How can we keep the runway etherpad up-to-date? 2.2) How to make sure that the team is focusing on the reviews that are in the runway slots? Personally I don't want to advertise this process for contributors if the core team is not agreed and committed to keep the process running as it would lead to unnecessary disappointment. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://etherpad.opendev.org/p/nova-runways-rocky [2] https://etherpad.opendev.org/p/nova-runways-stein [3] https://etherpad.opendev.org/p/nova-runways-train [4] https://etherpad.opendev.org/p/nova-runways-ussuri

3 4

[nova][ptg] Feature Liaison
by Balázs Gibizer 04 Jun '20

04 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] Last cycle we introduced the Feature Liaison process [1]. I think this is time to reflect on it. Did it helped? Do we need to tweak it? Personally for me it did not help much but I think this is a fairly low cost process so I'm OK to keep it as is. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://review.opendev.org/#/c/685857/

5 6

[keystone] Keystone PTG Schedule
by Nikolla, Kristi 03 Jun '20

03 Jun '20

Hi all, The Keystone team will be meeting Thursday and Friday 1300-1700 UTC. The schedule[0] can be found below and provides information on how to register and attend. In addition, I'm hoping to organize a team meetup Wednesday, Thursday or Friday on 1700UTC. Please fill in the doodle at [1]. More general PTG information can be found at [2]. [0]. https://etherpad.opendev.org/p/victoria-ptg-keystone [1]. https://doodle.com/poll/z7diwe6qyq4mbghe [2]. http://lists.openstack.org/pipermail/openstack-discuss/2020-May/015054.html

1 1

[cyborg][nova][neutron]Summaries of Smartnic support integration
by yumeng bao 03 Jun '20

03 Jun '20

Hi all, In cyborg pre-PTG meeting conducted last week[0],shaohe from Intel introduced SmartNIC support integrations,and we've reached some initial agreements: The workflow for a user to create a server with network acceleartor(accelerator is managed by Cyborg) is: 1. create a port with accelerator request specified into binding_profile field NOTE: Putting the accelerator request(device_profile) into binding_profile is one possible solution implemented in our POC. Another possible solution,adding a new attribute to port object for cyborg specific use instead of using binding_profile, is discussed in shanghai Summit[1]. This needs check with neutron team, which neutron team would suggest? 2.create a server with the port created Cyborg-nova-neutron integration workflow can be found on page 3 of the slide[2] presented in pre-PTG. And we also record the introduction! Please find the pre-PTG meeting vedio record in [3] and [4], they are the same, just for different region access. [0]http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014987.ht… [1]https://etherpad.opendev.org/p/Shanghai-Neutron-Cyborg-xproj [2]pre-PTG slides:https://docs.qq.com/slide/DVm5Jakx5ZlJXY3lw [3]pre-PTG vedio records in Youtube:https://www.youtube.com/watch?v=IN4haOK7sQg&feature=youtu.be [4]pre-PTG vedio records in Youku:http://v.youku.com/v_show/id_XNDY5MDA4NjM2NA==.html?x&sharefrom=iphon… Regards， Yumeng

5 7

[all] Week Out PTG Details & Registration Reminder
by Kendall Nelson 02 Jun '20

02 Jun '20

Hello Everyone! We are so excited to see you next week at our first virtual PTG! Below are all the details you need to have a fun and successful event. First and foremost: PLEASE REGISTER; https://virtualptgjune2020.eventbrite.com/ If you don't register for the event, we have no way of sending you information about the event, specifically the passwords that we will have set on the zoom rooms. Registration is free. =Final Schedule= The final schedule for the event is available here[1] and in the PTGBot[2]. =Tooling & Passwords= For each virtual PTG meeting room, we will provide an official Zoom videoconference room, which will be reused by various groups across the day. Please make sure to leave the room at the end of your team meeting! We will be setting passwords on the rooms to prevent vandalism/harassment, and we will send those out 24 hours before the start of the event. OpenDev's Jitsi Meet instance is also available at https://meetpad.opendev.org as an alternative tooling option to create team-specific meetings. This is more experimental and may not work as well for larger groups, but has the extra benefit of including etherpad integration (the videoconference doubles as an etherpad document, avoiding jumping between windows). PTGBot can be used to publish the chosen meeting URL if you decide to not use the official Zoom one. The OpenDev Sysadmins can be reached in the #opendev IRC channel if any problems arise. We recommend you try out Zoom and Meetpad ahead of the PTG to solve audio/video issues. =IRC= The main form of synchronous communication between attendees during the PTG is on IRC. If you are not on IRC, learn how to get started here [3]. The main PTG IRC channel is #openstack-ptg on Freenode, and it's used to interact with the PTGbot. The OpenStack Foundation (OSF) staff will be present to help answer questions. =PTGbot= The PTGbot[2] is an open source tool that PTG room moderators use to surface what's currently happening at the event. Room moderators will send messages to the bot via IRC, and from that information the bot publishes a webpage with several sections of information: - The discussion topics currently discussed in the room ("now") - An indicative set of discussion topics coming up next ("next") - The schedule for the day with available extra slots you can book Learn more about the PTGbot via the documentation here [4]. =Help Desk= We are here to help! If you have any questions during the event week, we will have a dedicated Zoom room where an OSF staff member will be available to answer your event related questions. If a staff member is not there to help, you can always reach someone at ptg(a)openstack.org or on IRC in the #openstack-ptg channel. =Feedback= We have created an etherpad[5] to collect all of your feedback throughout the event. Please add your thoughts so we can continue improving our virtual events! =Virtual Event Best Practices= Check out our list of virtual event best practices[6] prior to the event to help make the most of your time at the PTG. =Code of Conduct= The PTG is for everyone. We have zero tolerance for harassment and other violations of the OSF Community Code of Conduct. Before the PTG begins, please review the Code of Conduct[7] and know how to report an issue. -The Kendalls (diablo_rojo & wendallkaters) [1] Schedule: https://www.openstack.org/ptg#tab_schedule [2] Live PTGBot: http://ptg.openstack.org/ptg.html [3] IRC Setup: https://docs.openstack.org/contributors/common/irc.html [4] PTGBot Documentation: https://github.com/openstack/ptgbot/blob/master/README.rst [5] Feedback Etherpad: https://etherpad.opendev.org/p/June2020-PTG-Feedback [6] PTG Best Practices: https://etherpad.opendev.org/p/virtual-ptg-best-practices [7] Code of Conduct: https://www.openstack.org/legal/community-code-of-conduct/

11 18

[cinder] [ironic] Any update on Cinder Ceph ISCSI Driver?
by kevinz 02 Jun '20

02 Jun '20

Hi Cinder, We are looking forward to the IRONIC boot from Cinder Ceph Volume. I went through the mailist and found the conversation last year, the main gap for the Ironic boot from Cinder volume(Ceph BACKEND) is lacking Cinder Ceph iscsi driver. http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006041.html So I'm sending to ask the current status for this. We are from Linaro, all our machines are under Ironic and we use Ceph as backend storage. Recently we are looking at the Diskless server boot plan from the Ceph cluster. Any info or update or advice, I really appreciate it. Look forward to hearing from you.

3 4

[cinder][security] propose Rajat Dhasmana for cinder coresec
by Brian Rosmaita 02 Jun '20

02 Jun '20

Jay Bryant is stepping down from the Cinder core security team due to time constraints. I am proposing to replace him with Rajat Dhasmana (whoami-rajat on IRC). Rajat is has been a cinder core since January 2019 and is a thorough and respected reviewer and developer. Additionally, he'll extend our time zone coverage so that there will always be someone available to review/work on security patches around the clock. I intend to add Rajat to cinder coresec on Tuesday, 2 June; please communicate any concerns to me before then. cheers, brian

4 4

Re: [Openstack-mentoring] Neutron subnet with DHCP relay
by Amy Marrich 01 Jun '20

01 Jun '20

Hey Tom, Forwarding to the OpenStack discuss list where you might get more assistance. Thanks, Amy (spotz) On Thu, May 28, 2020 at 3:32 PM Thomas King <thomas.king(a)gmail.com> wrote: > Good day, > > We have Ironic running and connected via VLANs to nearby machines. We want > to extend this to other parts of our product development lab without > extending VLANs. > > Using DHCP relay, we would point to a single IP address to serve DHCP > requests but I'm not entirely sure of the Neutron network/subnet > configuration, nor which IP address should be used for the relay agent on > the switch. > > Is DHCP relay supported by Neutron? > > My guess is to add a subnet in the provisioning network and point the > relay agent to the linuxbridge interface's IP: > 14: brq467f6775-be: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc > noqueue state UP group default qlen 1000 > link/ether e2:e9:09:7f:89:0b brd ff:ff:ff:ff:ff:ff > inet 10.10.0.1/16 scope global brq467f6775-be > valid_lft forever preferred_lft forever > inet6 fe80::5400:52ff:fe85:d33d/64 scope link > valid_lft forever preferred_lft forever > > Thank you, > Tom King > _______________________________________________ > openstack-mentoring mailing list > openstack-mentoring(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-mentoring >

5 8

[tc] changing meeting time
by Mohammed Naser 01 Jun '20

01 Jun '20

Hello everyone, The PTG is happening online next week, on the same day as our TC monthly meeting. Since the PTG is only every six months, and we will meet the month after, how does everyone feel about skipping this month's meeting and considering the PTG as our meeting instead? Your comments are appreciated, Thanks, -- Mohammed Naser VEXXHOST, Inc.

5 4

[nova][ptg] Documentation in nova
by Stephen Finucane 01 Jun '20

01 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] Our documentation in nova is suffering from bit rot, the ongoing effects of the documentation migration during Pike (I think), and general lack of attention. I've been working to tackle this but progress has been very slow. I suggested this a couple of PTGs ago, but once again I'd like to explore going on a solo run with these by writing and self-approving (perhaps after a agreed interval) *multiple* large doc refactors. I've left some notes below, copied from the Etherpad, but in summary I believe this is the only realistic way we will ever be able to fix our documentation. Cheers, Stephen [0] https://etherpad.opendev.org/p/nova-victoria-ptg --- Documentation reviews are appreciated but are generally seen as low priority. See: * https://review.opendev.org/667165 (docs: Rewrite quotas documentation) * https://review.opendev.org/667133 (docs: Rewrite host aggregate, availability zone docs) * https://review.opendev.org/664396 (docs: Document how to revert, confirm a cold migration) * https://review.opendev.org/635243 (docs: Rework the PCI passthrough guides) * https://review.opendev.org/640730 (docs: Rework all things metadata'y) * https://review.opendev.org/625878 (doc: Rework 'resize' user doc) * ... I (stephenfin) want permission to iterate on documentation and merge unilaterally unless someone expresses a clear interest Pros: * Documentation gets better * I can iterate *much* faster Cons: * Possibility of mistakes or "bad documentation is worse than no documentation" * Counterpoint: Our documentation is already bad/wrong and is getting worse due to bitrot. * Better is subjective * Counterpoints: The general structure of the patches I listed above was accepted in each case, I have other projects I have authored to point to (e.g. patchwork.readthedocs.io/) * Merge conflicts * Counterpoint: It's docs. Just drop these (non-functional) hunks if it's awkward.

4 4

[openstack-helm] IRC Meeting Cancelled - June 02nd
by Gage Hugo 31 May '20

31 May '20

Hello everyone, The openstack-helm meeting this week, June 02nd, will be cancelled due to the PTG happening this week. We will continue regular meetings again next week.

1 0

[security] Security SIG meeting June 04th Cancellation
by Gage Hugo 31 May '20

31 May '20

Hello everyone, The Security SIG meeting this week, June 04th, will be cancelled due to the PTG happening this week. We will continue regular meetings again next week.

1 0

[openstack-helm] OpenStack-Helm PTG Schedule
by Gage Hugo 31 May '20

31 May '20

Hello, The OpenStack-Helm team will be meeting for the PTG on Tue, June 2nd and Wednesday, June 3rd from 1300-1700 UTC. The current agenda etherpad can be found here[0]. Hope to see you there! [0] https://etherpad.opendev.org/p/openstack-helm-ptg-victoria

1 0

[security] Security SIG PTG Schedule
by Gage Hugo 31 May '20

31 May '20

Hello, The Security SIG will be meeting for the PTG on Monday, June 1st from 1500-1700 UTC & 2100-2300 UTC. The current agenda etherpad can be found here[0]. Hope to see you there! [0] https://etherpad.opendev.org/p/security-sig-ptg-victoria

1 0

[neutron] Drivers meeting on Friday 5.06.2020 cancelled
by Slawek Kaplonski 31 May '20

31 May '20

Hi, It's PTG time so lets cancel this week meeting. -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[neutron] CI meeting on Wednesday 03.06.2020 cancelled
by Slawek Kaplonski 31 May '20

31 May '20

Hi, It's PTG time so lets cancel this week CI meeting. -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[neutron] Team meeting on Tuesday 02.06.2020 cancelled
by Slawek Kaplonski 31 May '20

31 May '20

Hi, We have PTG sessions in same time, so lets cancel IRC meeting this week. See You all on the PTG sessions :) -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[scientific-sig] Virtual PTG sessions on Monday
by Stig Telfer 31 May '20

31 May '20

Hi All - We have the Scientific SIG sessions at the PTG on Monday at 15:00-17:00 UTC and 21:00-23:00 UTC. Everyone is welcome. We have been gathering details and planning content in the Etherpad provided at https://etherpad.opendev.org/p/victoria-ptg-scientific-sig <https://etherpad.opendev.org/p/victoria-ptg-scientific-sig> The broad plan is to try to get a little more in-depth than our usual discussions on IRC and Slack, and for people to bring topics for discussion to share information with other science cloud operators in the SIG. Good topics would be pain points, problems, functional gaps, etc, for which others might have creative solutions. Cheers, Stig

1 0

[swift] Object Versioning: How to retrieve old versions of deleted objects?
by Bernd Bausch 31 May '20

31 May '20

According to documentation of Swift's new object versioning middleware [1], a deleted object won't be visible but previous version content is still recoverable. Documentation doesn't say how, though. After deleting /myobject/, I can see its versions: $ openstack object delete testcontainer myobject $ curl http://192.168.1.200:8080/v1/$ACCOUNT/testcontainer?versions -H "x-auth-token: $T" | python -m json.tool | grep -e version_id -e name "name": "myobject", "version_id": "1590896642.07497" "name": "myobject", "version_id": "1590892906.83929" "name": "myobject", "version_id": "1590892899.36921" But I can't GET old versions of /myobject/: $ curl -i http://192.168.1.200:8080/v1/$ACCOUNT/testcontainer/myobject?version-id="1590896642.07497" -H "x-auth-token: $T" HTTP/1.1 404 Not Found After creating another object with the same name /myobject/, old versions are accessible again. This is a solution, but dare I say not a very elegant one. *Can **a deleted, versioned object be recovered without creating a dummy object with the same name?* [1] https://docs.openstack.org/swift/latest/middleware.html#object-crud-operati…

1 1

Dropping python2.7 from diskimage-builder
by Monty Taylor 29 May '20

29 May '20

Heya, I just pushed up: https://review.opendev.org/728889 Drop support for python2 Which drops support for installing diskimage-builder using python2. It doesn’t drop support for in-image python2, that would be a whole different story. It seems that since the two largest DIB users, OpenStack and Zuul, are both now python3 only, it’s a safe move to make. IBM PowerKVM CI is running third-party CI with python2-based tests. We should probably either update those or just drop it? Thoughts? Monty

8 9

[tripleo] TripleO CI Summary: Unified Sprint 27
by Rafael Folco 29 May '20

29 May '20

Greetings, The TripleO CI team has just completed **Unified Sprint 27** (May 07 thru May 27). The following is a summary of completed work during this sprint cycle [1]: - Completed stable branching work (ussuri). - Internal pipeline: created integration and component jobs. - Continued to fix promoter tests on CentOS8 and built an internal promoter server. - Submitted change reviews for the TripleO IPA multinode job. - Started backporting to train - Built CentOS8 train full promotion pipeline and a job to upgrade from train to ussuri. - Landing these jobs in upstream soon - Ruck/Rover recorded notes [2]. The planned work for the next sprint [3] extends the work started in the previous sprint and focuses on creating tests for ci-config repository. The Ruck and Rover for this sprint are Rafael Folco (rfolco) and Poja Jadhav (pojadhav). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes to be tracked in etherpad [4]. Thanks, rfolco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-27 [2] https://hackmd.io/2MdkNAUuT7aBcM0Yck4xnw [3] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-28 [4] https://hackmd.io/YAqFJrKMThGghTW4P2tabA -- Rafael Folco Senior Software Engineer

1 0

[Diversity] [PTG] Diversity WG at PTG
by Amy Marrich 29 May '20

29 May '20

The Diversity and Inclusion WG will be having a session at 16:00 UTC on Monday at https://meetpad.opendev.org/PTGDiversityAndInclusion As a WG reporting to the OSF Board we would like to invite all OSF projects to come and learn what the WG can do for their project. The WG oversees the Diversity and Inclusion surveys as well as the OpenStack mentoring program. Hope to see new faces on Monday! Amy Marrich (spotz)

1 0

[heat] Deprecations in heat stack / apis
by prakash RAMCHANDRAN 29 May '20

29 May '20

Hi all, Can heat team send us representation for Heat Interop testing. Based on the triplo deprecating tripleo-heat-template, appears there are deprications and we did have been requesting help to review the add-ons to interop refer : https://github.com/openstack/interop/blob/master/next.json& https://github.com/openstack/interop/blob/master/2020.06.json& https://github.com/openstack/heat-tempest-plugin/blob/master/heat_tempest_p… Add you topics to support Heat orchestrtion for interop.https://etherpad.opendev.org/p/interop_virtual_ptg_planning_june_20… ThanksPrakash - Chain Interop WG

3 3

[cinder] PTG schedule
by Brian Rosmaita 29 May '20

29 May '20

The Cinder team will be meeting in the zoom Diablo room, Tuesday-Friday 1300-1600 UTC. Make sure you register for the PTG so you will receive the passwords to the video meeting: https://virtualptgjune2020.eventbrite.com/ The complete schedule for the PTG is here: https://www.openstack.org/ptg#tab_schedule Although Cinder won't be meeting on Monday, there are plenty of interesting sessions you can attend. See this helpful email for general PTG info: http://lists.openstack.org/pipermail/openstack-discuss/2020-May/015054.html The official Cinder etherpad for the PTG is: https://etherpad.opendev.org/p/victoria-ptg-cinder It contains the schedule. Please look it over so you can see when you'll be leading a discussion. Feel free to enhance any topic with additional information or questions. The schedule is organized like this: Tuesday - Current Cinder Issues Wednesday - Third Party Drivers Thursday - Cinder Improvements Friday - Cross-Project and Cinder Project Business see you next week! brian

1 0

[oslo] PTG Plans
by Ben Nemec 29 May '20

29 May '20

Hi, Sorry for the late notice on this. Many firedrills this week. I've made some updates to the etherpad[0] to reflect more concrete plans for both location and timing of topics. It worked out to just give everything 15 minutes for the first hour, and I reserved the second hour for cross-project discussions with Nova. As always, we can be flexible with the scheduling if something needs more or less discussion. The only timing constraint I saw mentioned was that Thierry needed the oslo.metrics topic to be early, so he gets to go first. :-) I also added a meetpad URL there. We used Jitsi pretty successfully for our previous virtual PTG so I don't see any reason to move off the open platform. I suggest trying to join ahead of time to make sure everything works for you. We do have a Zoom reserved for that time as well in case something catastrophic happens. If you have any concerns about the plan, let me know ASAP. Otherwise I'll see you all on Monday! -Ben 0: https://etherpad.opendev.org/p/oslo-victoria-topics

1 0

Re: [all][dev][qa] cirros 0.5.1
by Radosław Piliszek 29 May '20

29 May '20

Hello OpenStack Folks! Since it's early in the Victoria cycle, it's a good time to revisit the cirros 0.5.1 migration in common CI. The patch [1] is getting a cleanup due to nova fix increasing instance memory limits upfront but I propose to merge it as soon as we clean it up properly. It has been tested with Ussuri in Kolla CI and had positive results from Tempest jobs for Neutron and Ironic. It would be great if we made sure projects no longer use the old cirros 0.4.0 nor some old Ubuntus. [1] https://review.opendev.org/711492 -yoctozepto

1 1

[TripleO][rdo][train][centos7] fails at ovn_south_db_server: Start containers for step 4 using paunch
by Ruslanas Gžibovskis 29 May '20

29 May '20

Hi all, I am running this deployment described here [1]. I am getting error on: Start containers for step 4 using paunch Error in link bellow [2] Running podman containers [3] links: 1 - https://github.com/qw3r3wq/homelab/tree/master/overcloud 2 - https://pastebin.com/HTUbz7Ry 3 - https://pastebin.com/1ApfiEyE -- Ruslanas Gžibovskis +370 6030 7030

3 5

[puppet] Puppet 5 is officially unsupported in Victoria release
by Tobias Urdin 29 May '20

29 May '20

Hello, Just a heads up that we've had a warning in the Ussuri release about it being the last release where we are going to support Puppet 5. This patch [1] was now submitted to remove this warning and officially state that Puppet 5 is unsupported from the Victoria release. [1] https://review.opendev.org/726310?

4 20

[tripleo] better observability into containers management in the post-paunch world
by Bogdan Dobrelya 29 May '20

29 May '20

Hello, as you may know, Paunch [0] was originally developed for simple containers management in TripleO. Today we have Paunch deprecated for the preference of ansible module [1]. It uses ansible async executions and performs management actions in batches. While that's great and novel and works faster, Paunch's logs were simple to follow and its code was easy to debug with pdb breakpoints. Howewer, debugging experience and overall observability (please excuse me that buzzword) has changed [2], when switched it to ansible. In order improve that situation, I propose that data aggregator [3] for post-processing of the containers data under the module's management. It is based on setting facts, using already developed custom filters [4], and ansible's set_stats [5]. That data is just a (big) dictionary that contains: * input containers configs fetched from json files for all deploy steps, * snapshotted runtime info as it was consumed by the containers management tasks, * internal processing results (identified logical state, like 'changed' or 'broken') That is for all of the batches of managed containers in a deployment, per hosts basis. And that's basically it. How to use that data is out of scope at this point of discussion. Please share your thoughts on the topic. Note that the aggregator itiself is simple (~140 LOC). Please don't call it over-engineered :) It *only* allows users and tripleo devs to build whatever complex and over-engineered data analysing pipelines on top of it. Those may be colored graphs of dependencies and states, or simple json parsing, like that prototype [5] (WIP, only for a standalone deployments). Wrapping it up, it's up to devs and users how to use that data aggregator. Let's just simplify their lives with debugging containers management framework please. [0] https://opendev.org/openstack/paunch [1] https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ans… [2] https://launchpad.net/bugs/1879455 [3] https://review.opendev.org/#/q/topic:bug/1879455 [4] https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ans… [5] https://docs.ansible.com/ansible/latest/modules/set_stats_module.html -- Best regards, Bogdan Dobrelya, Irc #bogdando

1 0

[tripleo] Deprecating tripleo-heat-templates firstboot
by Steve Baker 28 May '20

28 May '20

Soon nova will be switched off by default on the undercloud and all overcloud deployments will effectively be deployed-server based (either provisioned manually or via the baremetal provision command) This means that the docs for running firstboot scripts[1] will no longer work, and neither will our collection of firstboot scripts[2]. In this email I'm going to propose what we could do about this situation and if there are still unresolved issues by the PTG it might be worth having a short session on it. The baremetal provisioning implementation already uses cloud-init cloud-config internally for user creation and key injection[3] so I'm going to propose an enhancement the the baremetal provisioning yaml format so that custom cloud-config instructions can be included either inline or as a file path. I think it is worth going through each firstboot script[2] and deciding what its fate should be (other than being deprecated in Ussuri): https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firs… This has no parameters, so it could be converted to a standalone cloud-config file, but should it? Can this be achieved with kernel args? Does it require a reboot anyway, and so can be done with extraconfig? https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firs… I'm not sure why this is implemented as first boot, it seems to consume the parameter |NetConfigDataLookup and transforms it to the format os-net-config needs for the file ||/etc/os-net-config/mapping.yaml. It looks like this functionality should be moved to where os-net-config is actually invoked, and the |||NetConfigDataLookup parameter should be officially supported. || | | |https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firstboot/userdata_dev_rsync.yaml| |I suggest deleting this and including a cloud-config version in the baremetal provisioning docs.| |||| |https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firstboot/userdata_heat_admin.yaml| |Delete this, there is already an abstraction for this built into the baremetal provisioning format[4]| | | |https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firstboot/userdata_root_password.yaml| |Delete this and include it as an example in the baremetal provisioning docs.| | | |https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firstboot/userdata_timesync.yaml| |Maybe this could be converted to an extraconfig/all_nodes script[5], but it would be better if this sort of thing could be implemented as an ansible role or playbook, are there any plans for an extraconfig mechanism which uses plain ansible semantics?| | | |cheers | [1] https://docs.openstack.org/project-deploy-guide/tripleo-docs/latest/feature… [2] https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/firs… [3] https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ans… [4] https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ans… https://opendev.org/openstack/tripleo-ansible/src/branch/master/tripleo_ans… [5] https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/extr…

3 5

[tripleo] PTG next week
by Wesley Hayutin 28 May '20

28 May '20

Greetings, PTG is next week. Please update the schedule if you have posted a topic Please register if you have not yet.. https://virtualptgjune2020.eventbrite.com/ All the information you should need should be posted on the following link. https://etherpad.opendev.org/p/tripleo-ptg-victoria See ya next week :)

1 0

[tc] Monthly meeting
by Mohammed Naser 28 May '20

28 May '20

Hi everyone, Our monthly TC meeting is scheduled for next Thursday, June 4, at 1400 UTC. If you would like to add topics for discussion, please go to https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting and fill out your suggestions by Wednesday, June 3, at 1900 UTC. Thank you. -- Mohammed Naser VEXXHOST, Inc.

1 0

[tripleo] Deprecating Paunch in Ussuri
by Emilien Macchi 28 May '20

28 May '20

Hi folks, In Ussuri we manage to successfully replace Paunch by Ansible (role + modules) to manage the container lifecycle in TripleO. As a reminder, this effort was part of the Simplification work that is being done in TripleO to reduce our number of tools and align it with our deployment framework based on Ansible. https://docs.openstack.org/tripleo-ansible/latest/roles/role-tripleo_contai… Paunch has been turned off for some time now and isn't tested anymore in upstream CI (master only). I would like to propose its deprecation in Ussuri and a removal in Victoria (or later if any valid pushback). https://review.opendev.org/#/c/720598/ Thanks, -- Emilien Macchi

2 3

Ussuri RDO Release Announcement
by Amy Marrich 28 May '20

28 May '20

If you're having trouble with the formatting, this release announcement is available online https://blogs.rdoproject.org/2020/05/rdo-ussuri-released/ --- *RDO Ussuri Released* The RDO community is pleased to announce the general availability of the RDO build for OpenStack Ussuri for RPM-based distributions, CentOS Linux and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Ussuri is the 21st release from the OpenStack project, which is the work of more than 1,000 contributors from around the world. The release is already available on the CentOS mirror network at http://mirror.centos.org/centos/8/cloud/x86_64/openstack-ussuri/. The RDO community project curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Linux and is a member of the CentOS Cloud Infrastructure SIG. The Cloud Infrastructure SIG focuses on delivering a great user experience for CentOS Linux users looking to build and maintain their own on-premise, public or hybrid clouds. All work on RDO and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. PLEASE NOTE: At this time, RDO Ussuri provides packages for CentOS8 only. Please use the previous release, Train, for CentOS7 and python 2.7. *Interesting things in the Ussuri release include:* - Within the Ironic project, a bare metal service that is capable of managing and provisioning physical machines in a security-aware and fault-tolerant manner, UEFI and device selection is now available for Software RAID. - The Kolla project, the containerised deployment of OpenStack used to provide production-ready containers and deployment tools for operating OpenStack clouds, streamlined the configuration of external [Ceph]( https://ceph.io/) integration, making it easy to go from Ceph-Ansible-deployed Ceph cluster to enabling it in OpenStack. *Other improvements include:* - Support for IPv6 is available within the Kuryr project, the bridge between container framework networking models and OpenStack networking abstractions. - Other highlights of the broader upstream OpenStack project may be read via https://releases.openstack.org/ussuri/highlights.html. - A new Neutron driver networking-omnipath has been included in RDO distribution which enables the Omni-Path switching fabric in OpenStack cloud. - OVN Neutron driver has been merged in main neutron repositon from networking-ovn. *Contributors* During the Ussuri cycle, we saw the following new RDO contributors: - Amol Kahat - Artom Lifshitz - Bhagyashri Shewale - Brian Haley - Dan Pawlik - Dmitry Tantsur - Dougal Matthews - Eyal - Harald Jensås - Kevin Carter - Lance Albertson - Martin Schuppert - Mathieu Bultel - Matthias Runge - Miguel Garcia - Riccardo Pittau - Sagi Shnaidman - Sandeep Yadav - SurajP - Toure Dunnon Welcome to all of you and Thank You So Much for participating! But we wouldn’t want to overlook anyone. A super massive Thank You to all 54 contributors who participated in producing this release. This list includes commits to rdo-packages and rdo-infra repositories: - Adam Kimball - Alan Bishop - Alan Pevec - Alex Schultz - Alfredo Moralejo - Amol Kahat - Artom Lifshitz - Arx Cruz - Bhagyashri Shewale - Brian Haley - Cédric Jeanneret - Chandan Kumar - Dan Pawlik - David Moreau Simard - Dmitry Tantsur - Dougal Matthews - Emilien Macchi - Eric Harney - Eyal - Fabien Boucher - Gabriele Cerami - Gael Chamoulaud - Giulio Fidente - Harald Jensås - Jakub Libosvar - Javier Peña - Joel Capitao - Jon Schlueter - Kevin Carter - Lance Albertson - Lee Yarwood - Marc Dequènes (Duck) - Marios Andreou - Martin Mágr - Martin Schuppert - Mathieu Bultel - Matthias Runge - Miguel Garcia - Mike Turek - Nicolas Hicher - Rafael Folco - Riccardo Pittau - Ronelle Landy - Sagi Shnaidman - Sandeep Yadav - Soniya Vyas - Sorin Sbarnea - SurajP - Toure Dunnon - Tristan de Cacqueray - Victoria Martinez de la Cruz - Wes Hayutin - Yatin Karel - Zoltan Caplovic *The Next Release Cycle* At the end of one release, focus shifts immediately to the next, Victoria, which has an estimated GA the week of 12-16 October 2020. The full schedule is available at https://releases.openstack.org/victoria/schedule.html. Twice during each release cycle, RDO hosts official Test Days shortly after the first and third milestones; therefore, the upcoming test days are 25-26 June 2020 for Milestone One and 17-18 September 2020 for Milestone Three. *Get Started* There are three ways to get started with RDO. To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works. For a production deployment of RDO, use the TripleO Quickstart and you’ll be running a production cloud in short order. Finally, for those that don’t have any hardware or physical resources, there’s the OpenStack Global Passport Program. This is a collaborative effort between OpenStack public cloud providers to let you experience the freedom, performance and interoperability of open source infrastructure. You can quickly and easily gain access to OpenStack infrastructure via trial programs from participating OpenStack public cloud providers around the world. *Get Help* The RDO Project participates in a Q&A service at https://ask.openstack.org. We also have our users(a)lists.rdoproject.org for RDO-specific users and operrators. For more developer-oriented content we recommend joining the dev(a)lists.rdoproject.org mailing list. Remember to post a brief introduction about yourself and your RDO story. The mailing lists archives are all available athttps://mail.rdoproject.org. You can also find extensive documentation on RDOproject.org. The #rdo channel on Freenode IRC is also an excellent place to find and give help. We also welcome comments and requests on the CentOS devel mailing list and the CentOS and TripleO IRC channels (#centos, #centos-devel, and #tripleo on irc.freenode.net) however we have a more focused audience within the RDO venues. *Get Involved* To get involved in the OpenStack RPM packaging effort, check out the RDO contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO packaging documentation. Join us in #rdo and #tripleo on the Freenode IRC network and follow us on Twitter @RDOCommunity. You can also find us on Facebook and YouTube. Amy Marrich (spotz) https://www.rdoproject.org http://community.redhat.com

1 0

[tc] Monthly update (to become Weekly)
by Mohammed Naser 28 May '20

28 May '20

Hello everyone, Here’s an update of what’s happened in the OpenStack TC during the last month. Moving forward, I’ll be sending an update on a weekly basis. You can get more information by checking for changes in openstack/governance repository. # CHANGES PENDING - Rename ansible-role-lunasa-hsm deliverable: https://review.opendev.org/#/c/731313/ - Add whitebox-tempest-plugin under QA: https://review.opendev.org/#/c/714480/ - Select migrate-to-focal goal for Victoria cycle: https://review.opendev.org/#/c/731213/ - Clarify the support for linux distro: https://review.opendev.org/#/c/727238/ - Add QA branchless projects also in py3.5 support list: https://review.opendev.org/#/c/729325/ - Remove congress and tricircle project teams: https://review.opendev.org/#/c/728818/ - [draft] Add assert:supports-standalone: https://review.opendev.org/#/c/722399/ # PROJECT UPDATES - Adding Storlets in the list of keeping py2: https://review.opendev.org/#/c/720714/ - Transfer Policy team co-lead role: https://review.opendev.org/#/c/722101/ - Add keystoneauth to the python3.5 list: https://review.opendev.org/#/c/721093/ - Add note that OpenStackSDK kept 3.5 support: https://review.opendev.org/#/c/721083/ - Retire i18n-specs: https://review.opendev.org/#/c/721723/ - Migrate from mock to built in unittest.mock: https://review.opendev.org/#/c/722924/ - Migrate from olso.rootwrap to oslo.privsep: https://review.opendev.org/#/c/718177/ - Appoint Yasufumi Ogawa as Tacker PTL: https://review.opendev.org/#/c/719091/ # GOAL UPDATES - Infrastructure project team is now the TaCT SIG: https://review.opendev.org/#/c/721621/ - Add ansible role for managing Luna SA HSM: https://review.opendev.org/#/c/721348/ - Drop deprecated release-management flag for xstatic repos: https://review.opendev.org/#/c/721046/ # ABANDONED CHANGES - Remove CentOS 8 from tested runtimes for Ussuri: https://review.opendev.org/#/c/720005/ - Goals: add container-images: https://review.opendev.org/#/c/720107/ # GENERAL UPDATES - Add goal to migrate CI/CD jobs to Ubuntu Focal: https://review.opendev.org/#/c/728158/ - Fix hacking min version to 3.0.1: https://review.opendev.org/#/c/730161/ - Appoint Javier Peña as rpm-packaging PTL: https://review.opendev.org/#/c/728088/ - Add repository for oslo.metrics: https://review.opendev.org/#/c/725848/ - Require PTL signoff for project-update changes: https://review.opendev.org/#/c/727704/ - Allow for faster addition of projects: https://review.opendev.org/#/c/726932/ - Retire syntribos: https://review.opendev.org/#/c/726507/ - Loosen voting for community goal proposals: https://review.opendev.org/#/c/724142/ - Add TrilioVault Charms to OpenStack Charms: https://review.opendev.org/#/c/720533/ - Cleanup retired repositories: https://review.opendev.org/#/c/724334/ - Move i18n into a SIG: https://review.opendev.org/#/c/721605/ # OTHER - Cap jsonschema 3.2.0 as the minimal version: https://review.opendev.org/#/c/730948/ - Fix bullet list formatting for drop-py2 goal: https://review.opendev.org/#/c/729314/ Thanks and sorry for the delay in getting those out. -- Mohammed Naser VEXXHOST, Inc.

1 0

Re: Uniting TC and UC
by Mohamed Elsakhawy 28 May '20

28 May '20

Hi All, As you may know already, there has been an ongoing discussion to merge UC and TC under a single body. Three options were presented, along with their impact on the bylaws. http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012806… We had several discussions in the UC on the three options as well as the UC items that need to be well-represented under the common committee, and here’s what we propose for the merger: 1- There’s consensus on utilizing option 1, thus requiring no bylaws change and merging AUC and ATC : 1- No bylaws change As bylaws changes take a lot of time and energy, the simplest approach would be to merge the TC and UC without changing the bylaws at all. The single body (called TC) would incorporate the AUC criteria by adding all AUC members as extra-ATC. It would tackle all aspects of our community. To respect the letter of the bylaws, the TC would formally designate 5 of its members to be the 'UC' and those would select a 'UC chair'. But all tasks would be handled together. 2- Two main core UC responsibilities need to continue to be represented under TC - Representing the user community to the broader community (Board of directors, TC...) - Working with user groups worldwide to keep the community vibrant and informed. 3- The current active workgroups under UC’s governance will be moved to be under TC’s governance. 4- AUC and ATC to be merged into a single list, potentially called AC (Active Contributor) 5- We hope to have the merger finalized before the upcoming UC elections in September 2020. In addition to discussions over the mailing list, we also have the opportunity of "face-to-face" discussions at the upcoming PTG. Thanks Mohamed --melsakhawy

8 11

[blazar][ptg] IRC meetings cancelled due to PTG
by Pierre Riteau 28 May '20

28 May '20

Hello, The Blazar community will meet several times through the PTG event next week. Let's cancel the IRC meetings originally scheduled on June 2 and June 4. Talk to you soon, Pierre Riteau (priteau)

1 0

[glance] "true is not of type boolean" when creating protected image
by Bernd Bausch 28 May '20

28 May '20

This problem occurs on a stable Ussuri Devstack. I issue this command to create a protected image: $ openstack image create myimage2 --file ~/myvm1.qcow2 --disk-format qcow2 --protected and get this error message back: BadRequestException: 400: Client Error for url: http://192.168.1.200/image/v2/images, 400 Bad Request: On instance['protected']:: 'type': 'boolean'}: {'description': 'If true, image will not be deletable.',: 'True': Provided object does not match schema 'image': 'True' is not of type 'boolean': Failed validating 'type' in schema['properties']['protected']: It seems that image creation fails because 'True' is not of type 'boolean' Am I looking at a bug or am I doing something wrong? I do have a great workaround: First, create the image without the protected flag. Then: $ openstack image set --protected myimage2 This works.

2 1

[all] [kolla] Kolla Builder - next generation
by Radosław Piliszek 28 May '20

28 May '20

Hello fellow OpenStackers and Kollars (or Koalas) in particular, today is the day when I finally sit down to write up my thoughts on Kolla, and I mean *Kolla*, the container image building project for OpenStack and friends, nothing more (nor less). *** Some background on Kolla to get everyone on the same page (or close enough): Kolla builds images for production use. Kolla is upstream for TripleO containers and Kolla-Ansible deployment. These are container images, think OCI and Docker in particular since Kolla actually relies on Dockerfile format to specify build recipes and Docker runs building (TripleO runs buildah on the same recipes). Kolla supports three distributions as bases: CentOS (TripleO does override this for RHEL as well), Debian and Ubuntu. In the interim periods Kolla supports two distribution releases to ease/smooth the transition process for operators (like currently CentOS 7 and 8 in Train, while Ussuri is 8 only). What is more, each distro has two flavours (or 'types' as they are called for now): binary and source. This 'type' applies only to OpenStack software. Binary means that Kolla uses downstream packages (rpm/deb) while source means to use pip and install from official tarballs (or repos if it is master) and PyPI for deps, utilising venv to keep it separate from distro stuff. Finally, there is particular target architecture: x86_64, aarch64 and ppc64le. All of above affect the support matrix which is based on 3 or 4 dimensions (distro, flavour, arch and sometimes distro version). [1] Kolla offers a high level of customisability via various overrides levels. See docs for details [2] Kolla engine offers hierarchical approach to image building, under the assumption that more than one image is often deployed on the same machine so layer sharing is beneficial. Kolla helps collect sources for OpenStack projects to build desired versions of them. All recipes are templated using Jinja2 syntax. Images contain both run-time and, mostly in the case of 'source' flavour, build-time tools and libraries. *** That's it for the background. :-) So where is the problem you might ask? Oh, there are plenty. The general is that Kolla has lots of logic in templates. Thankfully, Kolla has macros for most stuff but still Jinja2 limitations make it hard to document exceptions (no inline comments in arrays anyone?). We lose visibility into real dependency graphs and may be easily reinstalling same stuff, any optimisations are limited and would require parsing of both Jinja2 and Dockerfile syntax. In general the current approach is ugly and becomes unwieldy (e.g. getting warnings about empty continuation lines). There is layering hell: dependency on long &&ed commands which are templated out to avoid useless layers. Support matrix is great for an overview. There is a hidden layer to it though, different combinations may support different features. This is not documented so far and not so easy to follow from sources. This stems from the fact that different extra components have different availability in distros, but this is not easily apparent from sources. Also, there is no way to turn feature on/off. You might do an override, but then again, which to keep, which not to? Which is which? Oh! Finally, the images tend to be heavy due to inclusion of build-time deps. *** That's it for issues (hopefully!) My idea is to reuse Kolla engine where it shines: sources collection, system of plugins, hierarchical building; but replace the part that smells - Jinja2 templating. Giving up on Jinja2 might encompass giving up on Dockerfile syntax, but that is optional and depends on what makes it more amenable to avoid further pitfalls. With giving up on Jinja2, the idea is to generate building recipes fully programmatically from Python. It would be possible to introduce "Features" - sets of packages to install based on the (distro, arch) tuple. This would result in more flexibility - turning them on/off (some could be optional, some not). There could be more than one optimization strategy regarding when packages get installed: you want only standalone blah-blah? Then Kolla won't be installing XYZ and ABC just because ugma-ugma and tickle-tickle require them and you "could save some space" (TM). In the same vein, features could declare which components are build-time and which are run-time and this would make it straightforward to separate the sides. The above effort could well be coordinated with different projects to reuse bindep contents. So far Kolla does not use bindep because it often installs too much and not enough at the same time. Do note it would still be bindep-less for external services. There would still need to exist a general mechanism for providing custom command executions required by some images. For contributors and cores this new approach would bring more sanity as to the scope of proposed changes. Also, it would be possible to get quick insight into feature support and autogenerate docs for that as well. Similarly, current concept of unbuildable images would no longer be required because unbuildability would be dictated by lack of support for a required feature. *** Looking forward to your opinions/thoughts. *** [1] https://docs.openstack.org/kolla/train/support_matrix.html [2] https://docs.openstack.org/kolla/train/admin/image-building.html -yoctozepto

5 9

Re:[Cyborg]Edge sync up at the PTG
by yumeng bao 28 May '20

28 May '20

Hi Ildikó, Thanks for the post! Cyborg team would be glad to join ! I have added this edge group meeting session to our PTG schedule : https://etherpad.opendev.org/p/cyborg-victoria-goals Please help to add links for the discussion if there is any. Regards， Yumeng

2 2

[kolla] Virtual PTG
by Mark Goddard 28 May '20

28 May '20

Hi, Just a reminder that it's the virtual PTG next week. We have an Etherpad [1] which has lots of information, and remember to register (free) [2] if you haven't already. Kendall sent some useful information [3] recently also. If you plan to attend, please add your name to the Etherpad so we know who to expect for each session (although you are welcome to turn up if you have not). The Etherpad is currently quite light on proposed discussion topics. Please do spend some time to consider what we should be using this time to discuss. It doesn't have to be a shiny new feature, it could be a long standing bug that we should agree on how to address, or a discussion on how to improve our processes. If we are left with time to spare however, I think it will be well spent on some reflection, maintenance, and planning. Cheers, Mark [1] https://etherpad.opendev.org/p/kolla-victoria-ptg [2] https://virtualptgjune2020.eventbrite.com/ [3] http://lists.openstack.org/pipermail/openstack-discuss/2020-May/015054.html

1 0

[sdk][osc][cli][ptg][project_cleanup] PTG Week planning
by Artem Goncharov 28 May '20

28 May '20

Hi everyone interested :) The PTG planning for the OpenStackSDK and the CLI is there: https://etherpad.opendev.org/p/SDK-VictoriaPTG-Planning <https://etherpad.opendev.org/p/SDK-VictoriaPTG-Planning> Please enter yourself there if interested and add topics you want to discuss. We have currently 2 slots: 01 June: 15:00 - 17:00 UTC Juno 03 June: 15:00 - 17:00 UTC Bexar And we plan to be using meetpad (fingers crossed). Interesting topics: - June 01 15:00-16:00 project cleanup - long standing topic across the projects - June 01 16:00-17:00 openstackclient-first - a one time failed community goal, and now maybe multi-release goal for joining all individual service clients into OSC to give users seamless UX Hear from you soon, Artem

2 1

[glance][ptg] Victoria Virtual PTG updates
by Abhishek Kekane 27 May '20

27 May '20

Hello All, Greetings!!! First virtual PTG is around the corner and if you haven't already registered, please do so as soon as possible [1]. I have created a Virtual PTG planning etherpad [2] and also added day wise topics along with timings we are going to discuss. Kindly let me know if you have any concerns with allotted time slots. As a reminder, these are the time slots for our discussion. Monday 01 June 2020 1400 UTC to 1700 UTC Folsom Tuesday 02 June 2020 2100 UTC to 00 UTC Austin Wednesday 03 June 2020 2100 UTC to 00 UTC Austin Thursday 04 June 2020 2100 UTC to 00 UTC Folsom Friday 05 June 2020 1400 UTC to 1700 UTC Folsom We will be using meetpad [3] for our discussion, kindly try to use it once before the actual discussion. I will publish the meeting URL before the PTG and which will be the same throughout the PTG. [1] https://virtualptgjune2020.eventbrite.com/ [2] https://etherpad.opendev.org/p/Glance-Victoria-PTG-planning [3] https://meetpad.opendev.org Thank you, Abhishek

1 0

[manila][ptg] Victoria Virtual PTG Items
by Goutham Pacha Ravi 27 May '20

27 May '20

Hello Zorillas and other interested Stackers, If you haven't already registered to be part of the virtual PTG, please do so as soon as possible [1]. There's now an etherpad posted to gather topics for the Ussuri Team Retrospective [2]. Please take a look and add your thoughts before the event. Also take a look at our Virtual PTG planning etherpad [3], and let me know if you have a problem with the draft schedule posted. As a reminder, these are the time slots for our meeting: == Monday, 1st June 2020 == 1400 UTC - 1700 UTC == Tuesday, 2nd June 2020 == 1500 UTC - 1700 UTC 2100 UTC - 2300 UTC == Friday, 5th June 2020 == 1400 UTC - 1700 UTC Our meetings are on Zoom and will be recorded. The Zoom Room is called "Cactus" and is linked out of the PTG Schedule page [4]. So make sure to bookmark it :) Looking forward to a happy week of designing with you all! -- Goutham Ravi [1] https://virtualptgjune2020.eventbrite.com/ [2] https://etherpad.opendev.org/p/manila-ussuri-retrospective [3] https://etherpad.opendev.org/p/vancouver-ptg-manila-planning [4] http://ptg.openstack.org/ptg.html

1 0

[nova][ptg] Healthchecks API
by Ghanshyam Mann 27 May '20

27 May '20

Hello Everyone, This is one of the PTG topic[1] but it will be good if we can get some discussion to happen before PTG and utilize the PTG time. I am sorry for starting this thread late. To provide the healthchecks API for nova, I have done 1 PoC which is basically extending the oslo healthchecks middleware plugins to add the real checks. - https://review.opendev.org/#/c/731396/ I am writing the details on this etherpad[2] where you can see the response and the flow of new plugins. Also describing briefly here: oslo provides healthchecks middleware with plugin framework. oslo provides two basic plugins which does file/port based health checks - disable_by_file - disable_by_files_ports New Idea is to extend those checks with new plugins on nova side: Nova can provide three plugins which are configurable[3]: 1. Nova_DB_healthcheck: Checks if API, cell0 and at least one cell DB is up. If so then return Healthy otherwise Unhealthy 2. Nova_MQ_healthcheck: Checks if at least one cells MQ is up. If so then return Healthy otherwise Unhealthy 3. Nova_services_healthcheck: Checks if at least one cell has at least one conductor and one compute service running. If so then return Healthy otherwise Unhealthy All plugins will return the dict of results for example DB dict of API, all cells DB with status, Please refer the example response in later part. TODO: Auth part for various plugins Flow diagrame of new plugins: - Nova_DB_healthcheck: -->API DB is up | --> cell0 DB and at least one cell DB is up I --> Return OK - Nova_MQ_healthcheck: -->API MQ is up | --> At leask: one cell MQ is up I --> Return OK - Nova_services_healthcheck: --> At least one cell has at least one conductor and one compute running --> TODO: need to check other services for example scheduler at least I --> Return OK Result: 200 OK if all enabled plugins return OK otherwise 503 Service Unavailable. Opinion/thoughts? [1] https://etherpad.opendev.org/p/nova-victoria-ptg [2]https://etherpad.opendev.org/p/nova-healthchecks [3] https://review.opendev.org/#/c/731396/1/etc/nova/api-paste.ini@107

1 0

[sdk][api-sig][ptg] Victoria PTG planning
by Artem Goncharov 27 May '20

27 May '20

Hi everyone interested :) The PTG planning for the API-SIG is there: https://etherpad.opendev.org/p/API-SIG-VictoriaPTG-Planning <https://etherpad.opendev.org/p/SDK-VictoriaPTG-Planning> Please enter yourself there if interested and add topics you want to discuss. We have currently 1 slot, so hurry up not to loose the chance: 02 June: 16:00 - 17:00 UTC Liberty And we plan to be using meetpad (fingers crossed). Hear from you soon, Artem

2 1

[all][interop WG] Call for Participationin for Virtual PTG interop WG and seek ambassadors
by prakash RAMCHANDRAN 27 May '20

27 May '20

Hi all, We are looking for participation & presenters, contributors form different OpenStack and adjacent projects in Open Infrastructure , k8s, CNCF, OPNFV, ONAP, OCN etc. Please register in etherpad and review for anything you like to share wrt user level API for Multi Cloud, Hybrid Cloud and Edge cloud Interop capability or compatibility. The bridge will be tested this Friday May 29th before we finalize the location or bridge, Add you name topic and your inputs for rapid delivery slots of say 5-10 mts each on June 1st. https://etherpad.opendev.org/p/interop_virtual_ptg_planning_june_2020 Schedule June 1 (UTC 13-15 hrs = 6AM-8 AM PDT = 9AM-11 AM EST = 9PM-11PM BJT) First hr will focus on Project team like Nova, Neutron, Ciner, Keystone, Glance & Swift.Second Hour - Open for new ideas Additionally we would like ambassadors who can register and attend other Virtual PTG projects and provide us feedback after attending them as what they can provide to us for Interop WG from all other projects. ThanksFor Interop WGChair PrakashVice Chair Mark

1 0

[tripleo] Ussuri containers
by Wesley Hayutin 27 May '20

27 May '20

Greetings, FYI we had a squatter in docker.io steal away the tripleoussuri namespace. We are investigating using quay but we need to do quite a bit of testing for it. For now please remind folks that the default container registry namespace is not tripleo$release for ussuri. We're using "tripleou" [1]. If you want to pull from the rdo registry, you will find those containers in tripleoussuri for now [2], but will be moved to use tripleou as well for consistency. Note the following update to tripleo-common as well [3] Full story is that we attempted to contact docker.io support several times as they have a policy around removing squatting namespaces. The support team never responded. Our goal is drop docker.io and use quay.io but taking a step by step phased approach to that. Thanks all [1] https://hub.docker.com/u/tripleou [2] https://registry.rdoproject.org:8443/oapi/v1/namespaces/tripleoussuri/image… [3] https://review.opendev.org/#/c/731244/

1 0

[Nova][CentOS] extrem slow first boot Centos 8.1 with failures
by Nicolas Ghirlanda 27 May '20

27 May '20

Hello all, I created a centos image with a pretty similar kickstart config like from that link https://github.com/CentOS/sig-cloud-instance-build/pull/159/commits/2c542bb… Packer is building the image fine, also the post installation tasks after a reboot in qemu (which is running fine and fast), so everything looks good so far. Then upload to openstack and on first boot, the instance is booting fine until that point of boot: [[0;32m OK [0m] Started D-Bus System Message Bus. [[0;32m OK [0m] Started Hardware RNG Entropy Gatherer Daemon. Starting OpenSSH rsa Server Key Generation... Starting System Security Services Daemon... [ 9.913211] piix4_smbus 0000:00:01.3: SMBus Host Controller at 0x700, revision 0 [ 9.988763] input: PC Speaker as /devices/platform/pcspkr/input/input6 [ 10.137969] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 10.332234] cirrus 0000:00:02.0: vgaarb: deactivate vga console [ 10.419654] Console: switching to colour dummy device 80x25 [ 10.421488] [TTM] Zone kernel: Available graphics memory: 2017692 kiB [ 10.422946] [TTM] Initializing pool allocator [ 10.424036] [TTM] Initializing DMA pool allocator [ 10.425630] [drm] fb mappable at 0xFC000000 [ 10.426612] [drm] vram aper at 0xFC000000 [ 10.427436] [drm] size 33554432 [ 10.428108] [drm] fb depth is 16 [ 10.428884] [drm] pitch is 2048 [ 10.449202] fbcon: cirrusdrmfb (fb0) is primary device [ 10.465230] Console: switching to colour frame buffer device 128x48 [ 10.499394] cirrus 0000:00:02.0: fb0: cirrusdrmfb frame buffer device [ 10.524033] [drm] Initialized cirrus 1.0.0 20110418 for 0000:00:02.0 on minor 0 On the console there is no further update from here. In the boot log it slowly progresses, but with Failures of starting services e.g. Starting RPC Bind... Starting Security Auditing Service... [ 9.500362] audit: type=1400 audit(1590589814.846:4): avc: denied { read } for pid=784 comm="auditd" name="group" dev="sda1" ino=259654 scontext=system_u:system_r:auditd_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 [ 9.517988] audit: type=1400 audit(1590589814.863:5): avc: denied { read } for pid=783 comm="rpcbind" name="passwd" dev="sda1" ino=259634 scontext=system_u:system_r:rpcbind_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 [[0;1;31mFAILED[0m] Failed to start RPC Bind. See 'systemctl status rpcbind.service' for details. or [[0;32m OK [0m] Started OpenSSH ecdsa Server Key Generation. [[0;32m OK [0m] Started GSSAPI Proxy Daemon. [[0;32m OK [0m] Started OpenSSH ed25519 Server Key Generation. [[0;32m OK [0m] Started OpenSSH rsa Server Key Generation. [[0;1;31mFAILED[0m] Failed to start Authorization Manager. See 'systemctl status polkit.service' for details. [[0;1;33mDEPEND[0m] Dependency failed for Dynamic System Tuning Daemon. [[0;1;31mFAILED[0m] Failed to start NTP client/server. See 'systemctl status chronyd.service' for details. Also cloud-init is not able to assign an ip. [[0;32m OK [0m] Started D-Bus System Message Bus. Starting Network Manager... [ 550.962041] cloud-init[1070]: Cloud-init v. 18.5 running 'init' at Wed, 27 May 2020 14:37:46 +0000. Up 460.76 seconds. [ 550.964516] cloud-init[1070]: ci-info: +++++++++++++++++++++++++++Net device info++++++++++++++++++++++++++++ [ 550.967275] cloud-init[1070]: ci-info: +--------+-------+-----------+-----------+-------+-------------------+ [ 550.970075] cloud-init[1070]: ci-info: | Device | Up | Address | Mask | Scope | Hw-Address | [ 550.972524] cloud-init[1070]: ci-info: +--------+-------+-----------+-----------+-------+-------------------+ [ 550.975221] cloud-init[1070]: ci-info: | ens3 | False | . | . | . | fa:16:3e:a3:7d:d5 | [ 550.977970] cloud-init[1070]: ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | host | . | [ 550.980623] cloud-init[1070]: ci-info: | lo | True | ::1/128 | . | host | . | [ 550.983300] cloud-init[1070]: ci-info: +--------+-------+-----------+-----------+-------+-------------------+ [ 550.986164] cloud-init[1070]: ci-info: +++++++++++++++++++Route IPv6 info+++++++++++++++++++ [ 550.988469] cloud-init[1070]: ci-info: +-------+-------------+---------+-----------+-------+ [ 550.991092] cloud-init[1070]: ci-info: | Route | Destination | Gateway | Interface | Flags | [ 550.993576] cloud-init[1070]: ci-info: +-------+-------------+---------+-----------+-------+ [ 550.996326] cloud-init[1070]: ci-info: +-------+-------------+---------+-----------+-------+ After that time, the system is up, but no hostname is set (due to cloud-init issues). If I now reboot, everything is working fine, cloud-init is working etc. If I set selinux from enforcing to permissive in the kickstart config, the issues are not showing up, but I need selinux to stay enforcing. Anyone with the same issues or any hints appreciated. regards Nicolas

1 1

[ironic] [ptg] PTG week schedule
by Dmitry Tantsur 27 May '20

27 May '20

Hi ironicers! The PTG is next week, and I'd like to share our plans for it. We don't have anything planned on Monday, and the weekly meeting is cancelled as well. 2-hour slots are reserved Tuesday to Friday 14:00 UTC - 16:00 UTC in the Liberty room. The up-to-date schedule and notes are available on https://etherpad.opendev.org/p/Ironic-VictoriaPTG-Planning, the current version is as follows: Tue, Jun 2nd: 14:00-15:00: Releases, perceptions and our place in the world: governance and perceptions 15:00-16:00: Releases, perceptions and our place in the world: standalone future Wed, Jun 3rd: 14:00-15:00: Deployment Efficency 15:00-16:00: Aborting non-waiting transient states Thu, Jun 4th: 14:00-15:00: Fishy future 15:00-16:00: IPAM integrations outside of Neutron Fri, Jun 5th: 14:00-15:00: Operator suggestions/feedback/painpoints 15:00-16:00: Ideas and brainstorming I would like to highlight the operators feedback slot on Friday at 14:00 UTC. We would like to hear more opinions from people running ironic! Please join us. Hear from you soon, Dmitry

1 0

[kolla-ansible] External Ceph and cinder-volumes
by Alfredo De Luca 27 May '20

27 May '20

Hi all. I am sing kolla-ansible 4.0 with and external ceph already deployed. I have in globals.yml the following setting: enable_ceph: "no" glance_backend_ceph: "yes" nova_backend_ceph: "yes" cinder_backend_ceph: "yes" enable_cinder_backend_lvm: "no" When I run kolla-ansible I got an error about not having cinder-volumes group Cannot process volume group cinder-volumes Do you know why it keeps looking for the cinder volumes? I ve done it before with no problem but maybe something in the global not correctly configured? Cheers -- */Alfredo*

2 7

[cyborg] Edge sync up at the PTG
by Ildiko Vancsa 27 May '20

27 May '20

Hi Cyborg Team, I’m reaching out to check if you are available during next week to continue discussions on edge related topics that we started in Shanghai. The OSF Edge Computing Group is meeting next week and we have a slot reserved to sync up with OpenStack projects such as Cyborg on Wednesday (June 3) at 1300 UTC - 1400 UTC. Would the team be available to join at that time? Thanks, Ildikó

1 0

[tripleo][operators] Removal of mistral from the TripleO Undercloud
by Kevin Carter 26 May '20

26 May '20

Hello stackers, In the pursuit to remove Mistral from the TripleO undercloud, we've discovered an old capability that we need to figure out how best to handle. Currently, we provide the ability for an end-user (operator / deployer) to pass in "N" Mistral workflows as part of a given deployment plan which is processed by python-tripleoclient at runtime [0][1]. From what we have documented, and what we can find within the code-base, we're not using this feature by default. That said, we do not remove something if it is valuable in the field without an adequate replacement. The ability to run arbitrary Mistral workflows at deployment time was first created in 2017 [2] and while present all this time, its documented [3] and intra-code-base uses are still limited to samples [4]. As it stands now, we're on track to making Mistral inert this cycle and if our progress holds over the next couple of weeks the capability to run arbitrary Mistral workflows will be the only thing left within our codebase that relies on Mistral running on the Undercloud. So the question is what do we do with functionality. Do we remove this ability out right, do we convert the example workflow [5] into a stand-alone Ansible playbook and change the workflow runner to an arbitrary playbook runner, or do we simply leave everything as-is and deprecate it to be removed within the next two releases? Although it would be perfectly acceptable to keep Mistral around a little while longer, it would also be a bummer if this one capability was the only reason we were not able to remove Mistral from the Undercloud. Any and all feedback from operators, deployers, developers, former developers, etc would be greatly appreciated. Thank you in advance. [0] https://opendev.org/openstack/python-tripleoclient/src/commit/af719b795bc9b… [1] https://opendev.org/openstack/python-tripleoclient/src/commit/af719b795bc9b… [2] https://review.opendev.org/#/c/457874 [3] https://specs.openstack.org/openstack/tripleo-specs/specs/pike/tripleo-deri… [4] https://opendev.org/openstack/tripleo-heat-templates/src/commit/48da6a13936… [5] https://opendev.org/openstack/tripleo-common/src/commit/cc4f9c57b708259e9e9… Kevin Carter IRC: kecarter

5 9

[tripleo] TripleO Ussuri has been released
by Wesley Hayutin 26 May '20

26 May '20

Greetings, I'm pleased to announce that TripleO Ussuri has been released today. Special thanks to Chandan Kumar and Emilien Macchi for the extra time and effort in getting everything in place for the release. Thanks to everyone else as well for your contributions, bug reports, patches and participation! Some highlights from the TripleO release: * The mistral to ansible conversion blueprint is complete * The nova-less-deploy feature is complete * The TripleO-Operator-Ansible feature is complete * The RDO and CI teams completed work on component based DLRN rpm repos and CI. * TLS and TripleO deployments tested together in upstream CI. * Support for CentOS-8 * Many other improvements and updates Congratulations to the following individual contributors for their reviews across ALL openstack projects!! Alex Schultz, the #1 reviewer for all projects in Ussuri Herve Beraud, the #3 reviewer for all projects in Ussuri Emilien Macchi, the #4 reviewer for all projects in Ussuri Followed closely behind in reviews by Stephen Finucane Dmitry Tantsur Slawek Kaplonski Thanks to all our TripleO contributors!! https://www.stackalytics.com/?release=ussuri&metric=commits&project_type=op… Oh by the way TripleO fixed 558 bugs this release as well :) Additional statistics can be found here: https://docs.google.com/presentation/d/1RV30OVxmXv1y_z33LuXMVB56TA54Urp7oHI… <https://docs.google.com/presentation/d/1RV30OVxmXv1y_z33LuXMVB56TA54Urp7oHI…> Release notes can be found per TripleO project: https://docs.openstack.org/releasenotes/ At the time of writing this email not all the release notes have been published. Thanks all and I'm looking forward to seeing you at the PTG!

2 1

[PTG][neutron] Draft of the agenda
by Slawek Kaplonski 26 May '20

26 May '20

Hi neutrinos, I just prepared draft of the agenda for the Neutron team for the upcoming virtual PTG. It's available in the etherpad [1]. Please take a look into it and reach out to me if You: * want to change day/time of topic(s) which You are interested in mostly due to e.g. some conflicts which You may have with some other meetings, * if You want to add some new topics which, to make sure that agenda is modified to include that, * if You see anything else which You thinks that should be changed there :) See You all on the virtual PTG next week :) [1] https://etherpad.opendev.org/p/neutron-victoria-ptg -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[all][policy] Secure Default Policies Popup team meeting
by Ghanshyam Mann 26 May '20

26 May '20

Hello Everyone, To speed up the work on Secure Default Policies Popup team[1], we are going to start the biweekly meeting to discuss the pending things to finish if any or project need help on implementing the new default policy. We encourage projects interested to implement the new defaults or at least those listed on the wiki page [2] to join that meeting. Meeting details are on the wiki[3] also I have proposed the patch to book the slot: https://review.opendev.org/#/c/730935/ Agenda is slightly open for now which we will be moving to concrete as we progress and timing is biweekly-even on Thursday starting from this week on 28th 1800 UTC. We can adjust the timing also if needed. NOTE: First meeting on this week Thursday 28th 1800UTC on #openstack-meeting [1] https://governance.openstack.org/tc/reference/popup-teams.html#secure-defau… [2] https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popu… [3] https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popu… -gmann

1 0

[openstack-helm] Stepping down as core reviewer
by Steve Wilkerson 26 May '20

26 May '20

Hey everyone, I hope you're all staying safe and well. I switched jobs a few months back that took me in a different direction from my previous employer, and as a result I've not had the time to remain involved with the OpenStack community (especially as my day job no longer involves working with OpenStack). I think it's best that I step down from the openstack-helm core reviewer team, as I can't realistically make the time to do my due diligence in providing thorough, useful code reviews. I greatly appreciate the opportunities that working with the OpenStack community at large has provided me over the past 5 years. Cheers, srwilkers

2 1

[kolla-ansible][kolla][cinder]Cinder volume is not attached to instance
by Sanjay K 26 May '20

26 May '20

Hello Openstackers, I have used Cinder stein release (v14.0.2) source base and deployed in All-In-One setup on ubuntu16.04 using Kolla-Ansible. The cinder image was built using python 2.7 somewhere which i am trying to deploy in my new setup having python3.5. All services are deployed and running fine. However when I try to attach one volume to an instance, it shows below error in /var/log/kolla/cinder/cinder-volume.log. 2020-05-26 08:10:07.026 35 INFO oslo.privsep.daemon [req-db287360-876c-425e-b8df-a4f3b0db3163 bc13e1a279854a6fa1d553c7b7a0214c 9bdfc4ffefaa4edb823ff9ba5383ab42 - default default] Running privsep helper: ['sudo', 'cinder-rootwrap', '/etc/cinder/rootwrap.conf', 'privsep-helper', '--config-file', '/etc/cinder/cinder.conf', '--privsep_context', 'cinder.privsep.sys_admin_pctxt', '--privsep_sock_path', '/tmp/tmpan8c8r/privsep.sock'] 2020-05-26 08:10:10.952 35 INFO oslo.privsep.daemon [req-db287360-876c-425e-b8df-a4f3b0db3163 bc13e1a279854a6fa1d553c7b7a0214c 9bdfc4ffefaa4edb823ff9ba5383ab42 - default default] Spawned new privsep daemon via rootwrap 2020-05-26 08:10:10.647 1071 INFO oslo.privsep.daemon [-] privsep daemon starting 2020-05-26 08:10:10.721 1071 INFO oslo.privsep.daemon [-] privsep process running with uid/gid: 0/0 2020-05-26 08:10:10.725 1071 INFO oslo.privsep.daemon [-] privsep process running with capabilities (eff/prm/inh): CAP_CHOWN|CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_FOWNER|CAP_NET_ADMIN|CAP_SYS_ADMIN/CAP_CHOWN|CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_FOWNER|CAP_NET_ADMIN|CAP_SYS_ADMIN/none 2020-05-26 08:10:10.726 1071 INFO oslo.privsep.daemon [-] privsep daemon running as pid 1071 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server [req-db287360-876c-425e-b8df-a4f3b0db3163 bc13e1a279854a6fa1d553c7b7a0214c 9bdfc4ffefaa4edb823ff9ba5383ab42 - default default] Exception during message handling: ProcessExecutionError: Unexpected error while running command. Command: tgtadm --lld iscsi --op show --mode target Exit code: 107 Stdout: u'' Stderr: u'tgtadm: failed to send request hdr to tgt daemon, Transport endpoint is not connected\n' 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 166, in _process_incoming 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 265, in dispatch 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 194, in _do_dispatch 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/cinder/volume/manager.py", line 4517, in attachment_update 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server connector) 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/cinder/volume/manager.py", line 4445, in _connection_create 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server volume, connector) 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/cinder/volume/drivers/lvm.py", line 830, in create_export 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server volume_path) 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/cinder/volume/targets/iscsi.py", line 210, in create_export 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server **portals_config) 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/cinder/utils.py", line 818, in _wrapper 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server return r.call(f, *args, **kwargs) 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/retrying.py", line 206, in call 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server return attempt.get(self._wrap_exception) 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/retrying.py", line 247, in get 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server six.reraise(self.value[0], self.value[1], self.value[2]) 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/retrying.py", line 200, in call 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server attempt = Attempt(fn(*args, **kwargs), attempt_number, False) 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/cinder/volume/targets/tgt.py", line 126, in create_iscsi_target 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server (out, err) = cinder.privsep.targets.tgt.tgtadm_show() 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_privsep/priv_context.py", line 244, in _wrap 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server return self.channel.remote_call(name, args, kwargs) 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python2.7/site-packages/oslo_privsep/daemon.py", line 203, in remote_call 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server raise exc_type(*result[2]) 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server ProcessExecutionError: Unexpected error while running command. 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server Command: tgtadm --lld iscsi --op show --mode target 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server Exit code: 107 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server Stdout: u'' 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server Stderr: u'tgtadm: failed to send request hdr to tgt daemon, Transport endpoint is not connected\n' 2020-05-26 08:10:11.550 35 ERROR oslo_messaging.rpc.server When I check inside cinder-volume container, the tgtd is not running. SO I started tgtd from root user. Now the volume attachment happens for few seconds and then it is detached. 2020-05-26 08:14:39.221 35 INFO cinder.volume.manager [req-5da81388-33ce-4994-9114-52442a08ac2a bc13e1a279854a6fa1d553c7b7a0214c 9bdfc4ffefaa4edb823ff9ba5383ab42 - default default] attachment_update completed successfully. 2020-05-26 08:14:52.622 35 INFO cinder.volume.manager [req-cbaa1b6c-4fa8-4ece-b08b-8ca09f78ecaf bc13e1a279854a6fa1d553c7b7a0214c 9bdfc4ffefaa4edb823ff9ba5383ab42 - default default] Terminate volume connection completed successfully. 2020-05-26 08:14:52.840 35 INFO cinder.volume.targets.tgt [req-cbaa1b6c-4fa8-4ece-b08b-8ca09f78ecaf bc13e1a279854a6fa1d553c7b7a0214c 9bdfc4ffefaa4edb823ff9ba5383ab42 - default default] Removing iscsi_target for Volume ID: d713ce55-1fa6-4d96-a69e-69368494f8f9 2020-05-26 08:14:53.739 35 WARNING py.warnings [req-cbaa1b6c-4fa8-4ece-b08b-8ca09f78ecaf bc13e1a279854a6fa1d553c7b7a0214c 9bdfc4ffefaa4edb823ff9ba5383ab42 - default default] /var/lib/kolla/venv/lib/python2.7/site-packages/sqlalchemy/orm/evaluator.py:99: SAWarning: Evaluating non-mapped column expression 'updated_at' onto ORM instances; this is a deprecated use case. Please make use of the actual mapped columns in ORM-evaluated UPDATE / DELETE expressions. "UPDATE / DELETE expressions." % clause I also used the cinder 14.0.4 source tag to build the new image, but the same error persists. Can you please point me what is the issue in my test case or setup. Appreciate your help. best regards, Sanjay

2 1

[Horizon] Failing to configure the Instance Launch dialog
by Bernd Bausch 26 May '20

26 May '20

On an Ussuri Devstack, I would like to launch instances with ephemeral storage from Horizon and remove the volume storage switch from the instance launch dialog. Prior to Train, the dialog was configured with the LAUNCH_INSTANCE_DEFAULTS dictionary in /local_settings.py/. This is my dictionary; I set /create_volume /to /False /and /hide_create_volume /to /True/: LAUNCH_INSTANCE_DEFAULTS = { 'config_drive': False, 'create_volume': False, 'hide_create_volume': True, 'disable_image': False, 'disable_instance_snapshot': False, 'disable_volume': False, 'disable_volume_snapshot': False, 'enable_scheduler_hints': True, } Starting with Train, the dictionary is in /.../openstack_dashboard/defaults.py/, but the changes I made there have no effect. Adding the dictionary to /local_settings.py/ has no effect either. To test whether /defaults.py/ is used at all, I added a syntactically incorrect line, and indeed, the syntax error is logged in /horizon_error.log/. I wonder what I am doing wrong. I am convinced it worked like this on Stein. Any ideas? Bernd Bausch

2 3

[TripleO] External network on compute node
by Reza Bakhshayeshi 26 May '20

26 May '20

Hi all. The default way of compute node for accessing Internet if through undercloud. I'm going to assign an IP from External network to each compute node with default route. But the deployment can't assign an IP to br-ex and fails with: " raise AddrFormatError('invalid IPNetwork %s' % addr)", "netaddr.core.AddrFormatError: invalid IPNetwork ", Actually 'ip_netmask': '' is empty during deployment for compute nodes. I've added external network to compute node role: External: subnet: external_subnet and for network interface: - type: ovs_bridge name: bridge_name mtu: get_param: ExternalMtu dns_servers: get_param: DnsServers use_dhcp: false addresses: - ip_netmask: get_param: ExternalIpSubnet routes: list_concat_unique: - get_param: ExternalInterfaceRoutes - - default: true next_hop: get_param: ExternalInterfaceDefaultRoute members: - type: interface name: nic3 mtu: get_param: ExternalMtu use_dhcp: false primary: true Any suggestion would be grateful. Regards, Reza

2 6

[Nova][Scheduler] Reducing race-conditions and re-scheduling during creation of multiple high-ressources instances or instances with anti-affinity.
by Laurent Dumont 25 May '20

25 May '20

Hey everyone, We are seeing a pretty consistent issue with Nova/Scheduler where some instances creation are hitting the "max_attempts" limits of the scheduler. Env : Red Hat Queens Computes : All the same hardware and specs (even weight throughout) Nova : Three nova-schedulers This can be due to two different factors (from what we've seen) : - Anti-affinity rules are getting triggered during the creation (two claims are done within a few milliseconds on the same compute) which counts as a retry (we've seen this when spawning 40+ VMs in a single server group with maybe 50-55 computes - or even less 14 instances on 20ish computes). - We've seen another case where MEMORY_MB becomes an issue (we are spinning new instances in the same host-aggregate where VMs are already running. Only one VM can run per compute but there are no anti-affinity groups to force that between the two deployments. The ressource requirements prevent anything else from getting spun on those). - The logs look like the following : - Unable to submit allocation for instance 659ef90e-33b8-42a9-9c8e-fac87278240d (409 {"errors": [{"status": 409, "request_id": "req-429c2734-2f2d-4d2d-82d1-fa4ebe12c991", "detail": "There was a conflict when trying to complete your request.\n\n Unable to allocate inventory: Unable to create allocation for 'MEMORY_MB' on resource provider '35b78f3b-8e59-4f2f-8cad-eaf116b7c1c7'. The requested amount would exceed the capacity. ", "title": "Conflict"}]}) / Setting instance to ERROR state.: MaxRetriesExceeded: Exceeded maximum number of retries. Exhausted all hosts available for retrying build failures for instance f6d06cca-e9b5-4199-8220-e3ff2e5c2a41. - I do believe we are hitting this issue as well : https://bugs.launchpad.net/nova/+bug/1837955 - In all the cases where the Stacks creation failed, one instance was left in the Build state for 120 minutes and then finally failed. >From what we can gather, there are a couple of parameters that be be tweaked. 1. host_subset_size (Return X number of host instead of 1?) 2. randomize_allocation_candidates (Not 100% on this one) 3. shuffle_best_same_weighed_hosts (Return a random of X number of computes if they are all equal (instance of the same list for all scheduling requests)) 4. max_attempts (how many times the Scheduler will try to fit the instance somewhere) We've already raised "max_attempts" to 5 from the default of 3 and will raise it further. That said, what are the recommendations for the rest of the settings? We are not exactly concerned with stacking vs spreading (but that's always nice) of the instances but rather making sure deployments fail because of real reasons and not just because Nova/Scheduler keeps stepping on it's own toes. Thanks!

3 6

[all][interop] Please suggest capabilities to deprecate-remove and add to the OpenStack Powered Programs
by prakash RAMCHANDRAN 25 May '20

25 May '20

Hi all, Please help the Interop WG to review and finalize the draft version for the next interop guidelines. https://review.opendev.org/gitweb?p=openstack/interop.git;a=blob;f=2020.06.… Link for the DNS add-on: https://review.opendev.org/gitweb?p=openstack/interop.git;a=blob;f=add-ons/… Link for the Heat add-on: https://review.opendev.org/gitweb?p=openstack/interop.git;a=blob;f=add-ons/… This guidelines is intended to cover "Stein" , "Train", "Ussuri" and "Victoria" releases of OpenStack. We request that PTLs or Core team members please confirm any updates you may want to include or exclude in link above. The Projects currently covered under OpenStack Powered Programs include "Keystone", "Glance", "Nova", "Neutron", "Cinder", "Swift" and add-on programs "Designate", "Heat". A more human-readable view of the capabilities can be found in RefStack: https://refstack.openstack.org/#/guidelines We would like have feedback by next Interop call on Friday. - Can attend 10 AM PDT call refer etherpad - https://etherpad.opendev.org/p/interop If you have any additional topics to discuss at PTG please add them to https://etherpad.opendev.org/p/interop_virtual_ptg_planning_june_2020 The conference Bridge will be assigned once we know the number of participants. Please add your names/topics to ether pad interop ptg planning. Optionally reply to this email with your inputs/patches. Please Register to attend the Interop WG slot scheduled for Virtual PTG on June 1 6-8 AM PDT / 9-11 AM EST / 14-16 UTC / 9-11 PM BJT https://www.openstack.org/ptg/ Thanksfor Interop WGChair - Prakash RamchandranVice Chair - Mark Voelker

4 4

Bug deputy report for week of 2020-05-18
by Maciej Jozefczyk 25 May '20

25 May '20

Hello, Hey, Here's the bug deputy report for last week: ===== High ===== * https://bugs.launchpad.net/neutron/+bug/1879301 [OVN] networking-ovn-tempest-dsvm-ovs-release-python2 job starts to fail on tempest py2 installation fix already merged: https://review.opendev.org/#/c/728817/ * https://bugs.launchpad.net/neutron/+bug/1879307 Recent stable/rocky change breaks networking-calico's interface driver fix proposed: https://review.opendev.org/#/c/729167/ * https://bugs.launchpad.net/neutron/+bug/1879950 [OVN] neutron-ovn-db-sync-util wipes out hash ring nodes fix proposed: https://review.opendev.org/#/c/729997/ ===== Medium ===== * https://bugs.launchpad.net/neutron/+bug/1879215 [L3] Unexcepted HA router scheduled instance shows up after manully scheduling Unassigned. * https://bugs.launchpad.net/neutron/+bug/1879502 [ovn] neutron-ovn-db-sync-util fails with PortContext has no session fix proposed: https://review.opendev.org/#/c/729264/ * https://bugs.launchpad.net/neutron/+bug/1879747 [DOC] Manual install & Configuration in neutron fix proposed: https://review.opendev.org/#/c/729894/ ===== Low ===== * https://bugs.launchpad.net/neutron/+bug/1879407 [OVN] Modifying FIP that is no associated causes ovn_revision_numbers to go stale unassigned, no big deal * https://bugs.launchpad.net/neutron/+bug/1879716 Policy is not enforced for network mtu config unassigned ==== Reopened ==== https://bugs.launchpad.net/neutron/+bug/1742401 Fullstack tests neutron.tests.fullstack.test_securitygroup.TestSecurityGroupsSameNetwork fails often ===== Incomplete ===== * https://bugs.launchpad.net/neutron/+bug/1878719 DHCP Agent's iptables CHECKSUM rule causes skb_warn_bad_offload kernel * https://bugs.launchpad.net/neutron/+bug/1878905 when I use dvr mode for neutron,it's not functional * https://bugs.launchpad.net/neutron/+bug/1879009 attaching extra port to server raise duplicate dns-name error fix proposed: https://review.opendev.org/#/c/729440/ (in progress) See you, Maciej -- Best regards, Maciej Józefczyk

1 0

[neutron] Team meeting on Monday 25.05.2020 cancelled
by Slawek Kaplonski 25 May '20

25 May '20

Hi, As today is the Memorial Day in the USA, and many from team members are on holidays, lets cancel today's team meeting. Next week there is virtual PTG so we will meet there :) -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[swift] Rolling upgrade, any version relationships?
by Mark Kirkwood 24 May '20

24 May '20

Hi, we are looking at upgrading our 2.7.0 Swift cluster. In the past I've modeled this on a dev system by upgrading storage nodes one by one (using 2.17 as the target version). This seemed to work well - I deliberately left the cluster half upgraded for an extended period to test for any cross version weirdness (didn't see any). However I'm wanting to check that I have not missed something important. So my questions are: - If upgrading from 2.7.0 is it safe to just grab the latest version (e.g 2.23)? - If not is there a preferred version to jump to first? - Is it ok for the upgrade to take extended time (e.g weeks) and therefore be running with some new and some old storage nodes for that time? regards Mark

3 5

[keystone][devstack][openstackclient] Problem with Keystone setup in stable/ussuri devstack install
by Neil Jerram 22 May '20

22 May '20

+ ./stack.sh:main:1091 : create_keystone_accounts + lib/keystone:create_keystone_accounts:314 : local admin_project ++ lib/keystone:create_keystone_accounts:315 : oscwrap project show admin -f value -c id WARNING: Failed to import plugin identity. ++ functions-common:oscwrap:2370 : return 2 + lib/keystone:create_keystone_accounts:315 : admin_project='openstack: '\''project show admin -f value -c id'\'' is not an openstack command. See '\''openstack --help'\''. I believe this is a completely mainline Keystone setup by devstack. The top-level stack.sh code is echo_summary "Starting Keystone" if [ "$KEYSTONE_AUTH_HOST" == "$SERVICE_HOST" ]; then init_keystone start_keystone bootstrap_keystone fi create_keystone_accounts ... bootstrap_keystone succeeded but create_keystone_accounts failed as shown above, trying to execute openstack project show "admin" -f value -c id IIUC, the rootmost problem here is "WARNING: Failed to import plugin identity.", indicating that python-openstackclient is failing to import its openstackclient.identity.client module. But I don't know any more about why that would be. Any ideas? Many thanks, Neil

2 3

[all][qa] Gate Status: week 20-21
by Ghanshyam Mann 22 May '20

22 May '20

Hello Everyone, I am highlighting the few of the gate issues we fixed or in-progress recently in case you are facing the same in your projects gate or 3rd party CI. 1. Bug# 1880219. A job using older Tempest (ubuntu xenial node jobs) on stable stein onwards gate or 3rd party CI fail. This is failing the same type of job I reported a few weeks back but with different issues and happening on 3rd party CI as I have not seen such a job or failure on upstream yet. I am reproducing the scenario to test the fixes[1]. Earlier issue[2] was fixed by using the older Tempest. Now it started failing as we use the master constraint on stein and train and master constraints are no more compatible with older Tempest[3]. The solution for this will be to use stable constraints if older Tempest is not used. This fix needs modification on devstack as well as the tempest side. Devstack changes[4] working fine but I need to fix it on the Tempest side also. 2. Bug#1880217. In-tree Tempest plugins python2 jobs on stable/stein or Train failing This might be a rare case but still possible as we do have in-tree plugins for older stable branches. For in-tree plugins (in case it's still present even we migrated most of the tempest plugins into separate repo ), 'all-plugins' tox env which is supposed to detect the system-wide installed plugins will not work now for python2.7 jobs. This is because Tempest is now py3-only and so create py3 venv even on py2 jobs. 'all-plugins' venv which is py3 no longer detect the tempest plugins installed as python2.7 site-packages. Failure example: https://zuul.opendev.org/t/openstack/build/7d3f36f464bb4642bb1647f4b0b8e91f… If you encounter this issue then a quick fix for that will be to install the in-tree plugins in Tempest venv via TEMPEST_PLUGINS and run tests with 'all' tox venv. Example: https://review.opendev.org/#/c/730378/2 3. hacking fix for new flake8 3.8.0 merged in master might need to be backported to stable branches also but not for all projects. But to have a safe guard against future flake8 3.9.0(which can also cause same issue), you can backport the hacking min version fix: - http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014828.html Have a happy weekend and feel free to append more gate bugs here you have encountered or fixed recently. [1] https://review.opendev.org/#/c/729611/3 [2] http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014601.html [3] https://review.opendev.org/#/c/720264/ [4] https://review.opendev.org/#/c/729722/6 -gmann

1 0

[swift] Erasure code hardware offloading
by Mark Kirkwood 22 May '20

22 May '20

Hi, Can Swift make use of an Erasure Code offload card (e.g https://community.mellanox.com/s/article/understanding-erasure-coding-offlo… regards Mark

2 1

[charms] Propose Aurelien Lourot for OpenStack Charms core
by Frode Nordahl 22 May '20

22 May '20

Hello all, I would like to propose adding Aurelien Lourot as core developer for the Charms project. -- Frode Nordahl

4 3

[release] Release countdown for week R-20, May 25 - 29
by Sean McGinnis 22 May '20

22 May '20

Welcome back to the release countdown emails! These will be sent at major points in the Victoria development cycle, which should conclude with a final release on October 16, 2020. Development Focus ----------------- At this stage in the release cycle, focus should be on planning the Victoria development cycle, assessing Victoria community goals and approving Victoria specs. General Information ------------------- Victoria is a 22 week development cycle, which is already underway. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/victoria/schedule.html By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the Ussuri release are continued in the Victoria series with a similar release model. If you intend to drop a deliverable, or modify its release model, please do so before the victoria-1 milestone by proposing a change to the deliverable file at: https://opendev.org/openstack/releases/src/branch/master/deliverables/victo… Upcoming Deadlines & Dates -------------------------- Virtual Victoria PTG: June 1-5 Victoria-1 milestone: June 18

1 0

[neutron][operators]
by Dincer Celik 22 May '20

22 May '20

Hi, You know in public cloud world, most users prefer using VPCs (aka tenant networks for us), and when they need to connect two separate VPC, they have VPC peering functionality. For OpenStack, we have routers, RBACs, static routes and floating IPs, but there is nothing functioning like a real VPC peering. I see this was discussed at Stein PTG[1] under L3 topics but seems there is no progress about it. So I would like to ask what is the most common way to let two separate tenant networks under different accounts talk to each other? Thanks! Dincer [1] https://etherpad.opendev.org/p/neutron-stein-ptg

1 0

[charms] OpenStack Charms 20.05 release is now available
by Peter Matulis 22 May '20

22 May '20

The OpenStack Charms team is happy to announce the 20.05 charms release, introducing support for OpenStack Ussuri and Ceph Octopus on Ubuntu 18.04 LTS and Ubuntu 20.04 LTS. This release also brings several new and valuable features to the existing OpenStack Charms deployments for Queens, Rocky, Stein, Train, Ussuri and many other stable combinations of Ubuntu + OpenStack. Please see the Release Notes for full details: https://docs.openstack.org/charm-guide/latest/2005.html == Highlights == * OpenStack Ussuri OpenStack Ussuri is now supported on Ubuntu 18.04 LTS (via UCA) and Ubuntu 20.04 LTS natively. * Ceph Octopus The Octopus release of Ceph is now supported, starting with OpenStack Ussuri. * New charms: MySQL 8 The MySQL 8 charms (mysql-innodb-cluster and mysql-router) have been promoted to supported status. These charms allow for a completely native cloud database HA cluster (no need for the hacluster charm). The legacy solution (percona-cluster charm) is not supported on Ubuntu 20.04 LTS. Migration documentation is available. * New charms: Masakari The Masakari charms (masakari and masakari-monitors) and the requisite pacemaker-remote charm have been promoted to supported status, starting with OpenStack Stein. Masakari provides automated recovery of OpenStack instances (shared storage required). * New charms: OVN The OVN charms (neutron-api-plugin-ovn, ovn-central, ovn-chassis, and ovn-dedicated-chassis) have been promoted to supported status. OVN provides virtual networking for Open vSwitch and is the preferred default for new deployments of OpenStack Ussuri. * Ceph iSCSI Ceph iSCSI gateway functionality is available as a tech preview. These gateways provide iSCSI targets backed by a Ceph cluster. == OpenStack Charms team == The OpenStack Charms team can be contacted on the #openstack-charms IRC channel on Freenode. == Thank you == Lots of thanks to the below 67 charm contributors who squashed 89 bugs, enabled support for a new release of OpenStack, improved documentation, and added exciting new functionality! James Page Alex Kavanagh Frode Nordahl Liam Young Peter Matulis David Ames Corey Bryant Chris MacNaughton Ghanshyam Mann Aurelien Lourot Sahid Orentino Ferdjaoui Stamatis Katsaounis Ryan Beisner inspurericzhang Tiago Pasqualini Andrew McLeod ShangXiao Edward Hope-Morley Felipe Reyes kangyufei Adam Dyess Andreas Jaeger wangfaxin Xuan Yandong Arif Ali José Pekkarinen Chris Johnston Hemanth Nakkina Alexandros Soumplis Jose Guedez Qitao Tytus Kurek Seyeong Kim Dmitrii Shcherbakov Dongdong Tao Drew Freiberger Haw Loeung Jorge Niedbalski Andrea Ieri Xav Paice Qiu Fossen Yanos Angelopoulos Syed Mohammad Adnan Karim JiaSiRui Sérgio Filipe Marques Manso Vladimir Grevtsev George Kraft Marco Filipe Moutinho da Silva Xiyue Wang Adam Dyess Jose Delarosa Alexander Balderson Facundo Ciccioli Jacek Nykis Eduardo Sousa Thobias Trevisan Rodrigo Barbieri Alejandro Santoyo Gonzalez Sean McGinnis Claudio Pisa Shuo Liu Matus Kosut Stephen Muss Camille Rodriguez zhangboye Aggelos Kolaitis Nicolas Bock -- OpenStack Charms Team

2 1

[neutron] Drivers meeting 22.05.2020
by Slawek Kaplonski 21 May '20

21 May '20

Hi, Due to lack of agenda for the next drivers meeting, lets cancel it this week. See You all next week. BTW. Please maybe check Nate's email [1] - this isn't exactly RFE but something which IMO drivers team should check too :) [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014820.html -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[kolla] Kolla klub meeting
by Mark Goddard 21 May '20

21 May '20

Hi, Just a reminder that we will host a project onboarding session for the next Kolla Klub meeting on Thursday 21st May. We'll cover a variety of topics on the many different ways you can contribute to the project. Gaël Therond will also fill us in on some of the questions put to him since the last meeting about his case studies. https://docs.google.com/document/d/1EwQs2GXF-EvJZamEx9vQAOSDB5tCjsDCJyHQN5_… Thanks, Mark

1 1

review of tripleo-ci-centos-8-standalone-on-multinode-ipa
by Wesley Hayutin 21 May '20

21 May '20

Greetings, Please review the following new standalone + ipa deployment [1]. The keystone folks would like this deployment to run by default on all THT changes vs. the current set of files [2]. Looking for any strong objects to running the job on any THT change and or more files to target the job against in [2] If you need specific information about the job please contact rlandy @ redhat pojadhav @ redhat Thanks [1] https://zuul.openstack.org/builds?job_name=tripleo-ci-centos-8-standalone-o… [2] https://opendev.org/openstack/tripleo-heat-templates/src/branch/master/zuul…

1 0

[Heat] Heat Stack Create Authorization Failed
by İzzettin Erdem 21 May '20

21 May '20

Hello everyone, When I launch a cluster on Sahara, it gives a heat stack authorization error. I also use Murano service and it is working with heat. I could not find the solution and I discuss this error with the Sahara-devel team. They are also searching for this. Could you help me, please? Both the error log of Sahara and Heat are below. Sahara-engine: http://paste.openstack.org/show/793671/ Heat-engine: http://paste.openstack.org/show/793673/ Thanks. Regards.

4 4

[ptg][cyborg][neutron][nova]Smartnic support integration via cyborg neutron and nova? - Cyborg Pre-PTG Meeting
by yumeng bao 21 May '20

21 May '20

Hi, As agreed on the IRC, tomorrow, we will have a cyborg Pre-PTG Zoom Meeting. Shaohe Feng from Intel will introduce SmartNIC support from the following aspects: * the cyborg-neutron-nova integration workflow when creating a server with a port of SmartNIC which is managed by cyborg *what changes needs to be done in nova, neutron to support SmartNIC feature? Please find the Pre-PTG meeting Link below: Zoom URL: https://us04web.zoom.us/j/9575741145?pwd=cVZydHl6blYzTGtNVlU4QU96ZWxiZz09 Meeting ID：957 574 1145 Password：9XhFhK The reserved meeting time is in total one and a half hours, but divided into three time slots(if time is not enough, we can extend another half hour time slot). *May 22 Friday 2:30 UTC -3:00 UTC *May 22 Friday 3:00 UTC -3:30UTC *May 22 Friday 3:30 UTC -4:00UTC * *And Please be aware: The three slots use the same URL, same Meeting ID and same Password. This means, when time of the slot is running out,and if you're kicked out of the Zoom, then you will need to login to the same Zoom URL again to join the next time slot. (And there’s also possibility that we don’t need to do the re-login, this depends on the number of people.） For others interested but not quite familiar with this topic, here’s some background information: Cyborg, served as a general purpose management framework for acceleration resources, is trying to support various types of accelerators.(FPGA, GPU, SPDK and so on) We continuously got questions from operators if cyborg supports SmartNIC, and this motivated us to support SmartNIC. Actually, we’ve made a discussion on SmartNIC with neutron team at the Shanghai Summit[1] 2019. We are now planning to continue discussing SmartNICs support integration in the coming Virtual PTG and try to move forward in Victoria Release. Cyborg will discuss about this topic internally first, and then later discuss with nova and neutron at PTG cross-project session[2][3]. [1] https://etherpad.opendev.org/p/Shanghai-Neutron-Cyborg-xproj [2] https://etherpad.opendev.org/p/nova-victoria-ptg [3] https://etherpad.opendev.org/p/cyborg-victoria-goals Regards， Yumeng

1 0

[nova][cinder][linstor] VM creation failed with invalid libvirt xml <source dev='None'/>
by Volodymyr Litovka 21 May '20

21 May '20

Hi colleagues, does anybody here use Linstor as backend for Openstack? I can not launch VM (synopsis below) while everything looks fine until the last step :-) Few words about Openstack's storage configuration: - controllers: cinder-api, cinder-scheduler, cinder-volume (modified with latest driver from Linstor's git), linstor-client, python-linstor - compute nodes: linstor-controller, linstor-satellite, linstor-client, python-linstor; node types - Combined - cinder.conf[1] - volume-type registered with corresponding properties[2] I'm able to manipulate volumes - create/delete[3] and every existing volume has the corresponding drbd/linstor repr[4] and LVM LV[5] on the compute nodes, so, from storage point of view, it looks as correct and ready to use. The problem is when I try to create VM using $ openstack server create --flavor [...] --network [...] --volume 15c4fa98-76a5-44d6-9701-c89a8a848b82 fearst Nova fails[6] because of invalid VM's libvirt XML definition (note "source dev='None'" below): <devices> <emulator>/usr/bin/qemu-system-x86_64</emulator> <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none'/> <source dev='None'/> <target dev='vda' bus='virtio'/> <serial>15c4fa98-76a5-44d6-9701-c89a8a848b82</serial> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> I do not have another working DRBD/Linstor/Openstack installation and can't even imagine, where to look into the problem - whether it is in Nova, Cinder or in Linstor configuration itself. I will appreciate if anybody can give me some guidance on where to seek for the solution to the problem. In my lab I'm using Openstack Train on Ubuntu 18.04.4: nova-compute 2:20.1.1-0ubuntu1~cloud0 nova-compute-kvm 2:20.1.1-0ubuntu1~cloud0 nova-compute-libvirt 2:20.1.1-0ubuntu1~cloud0 nova-api 2:20.1.1-0ubuntu1~cloud0 nova-common 2:20.1.1-0ubuntu1~cloud0 nova-conductor 2:20.1.1-0ubuntu1~cloud0 nova-novncproxy 2:20.1.1-0ubuntu1~cloud0 nova-scheduler 2:20.1.1-0ubuntu1~cloud0 cinder-api 2:15.1.0-0ubuntu1~cloud0 cinder-common 2:15.1.0-0ubuntu1~cloud0 cinder-scheduler 2:15.1.0-0ubuntu1~cloud0 cinder-volume 2:15.1.0-0ubuntu1~cloud0 python3-cinder 2:15.1.0-0ubuntu1~cloud0 python3-cinderclient 1:5.0.0-0ubuntu2~cloud0 python3-nova 2:20.1.1-0ubuntu1~cloud0 python3-novaclient 2:15.1.0-0ubuntu2~cloud0 Thank you! ==================================== [1] cinder.conf [DEFAULT] enabled_backends = linstor default_volume_type = linstor [linstor] storage_availability_zone = nova volume_backend_name = linstor volume_driver = cinder.volume.drivers.linstordrv.LinstorDrbdDriver linstor_autoplace_count = 2 linstor_default_volume_group_name=DfltRscGrp linstor_default_uri=linstor://runner linstor_default_storage_pool_name=drbdpool linstor_default_resource_size=1 linstor_volume_downsize_factor=4096 where 'runner' is virtual ip of linstor-controller, protected by pacemaker. ==================================== [2] openstack volume type show linstor +--------------------+--------------------------------------+ | Field | Value | +--------------------+--------------------------------------+ | access_project_ids | None | | description | None | | id | d2025962-503a-4f37-93bd-b766bb346a42 | | is_public | True | | name | linstor | | properties | volume_backend_name='linstor' | | qos_specs_id | None | +--------------------+--------------------------------------+ ==================================== [3] openstack volume show fearst +--------------------------------+-----------------------------------------------------+ | Field | Value | +--------------------------------+-----------------------------------------------------+ | attachments | [] | | availability_zone | nova | | bootable | true | | consistencygroup_id | None | | created_at | 2020-05-21T08:42:11.000000 | | description | None | | encrypted | False | | id | 15c4fa98-76a5-44d6-9701-c89a8a848b82 | | migration_status | None | | multiattach | False | | name | fearst | | os-vol-host-attr:host | ctrl1@linstor#linstor | | os-vol-mig-status-attr:migstat | None | | os-vol-mig-status-attr:name_id | None | | os-vol-tenant-attr:tenant_id | 7acec404393344cbabde07a22bbe6b3f | | properties | | | replication_status | None | | size | 5 | | snapshot_id | None | | source_volid | None | | status | available | | type | linstor | | updated_at | 2020-05-21T08:42:18.000000 | | user_id | 1048a19e94234451a61c3d9d46907ceb | | volume_image_metadata | {'signature_verified': 'False', | | | 'image_id': '15e992e8-a601-44cd-a2f0-8f34588a4d18',| | | 'image_name': 'cirros', | | | 'checksum': '1d3062cd89af34e419f7100277f38b2b', | | | 'container_format': 'bare', | | | 'disk_format': 'qcow2', | | | 'min_disk': '0', | | | 'min_ram': '0', | | | 'size': '16338944'} | +--------------------------------+-----------------------------------------------------+ ==================================== [4] linstor r l ╭───────────────────────────────────────────────────────────────────────────────────╮ ┊ ResourceName ┊ Node ┊ Port ┊ Usage ┊ Conns ┊ State ┊ ╞═══════════════════════════════════════════════════════════════════════════════════╡ ┊ CV_15c4fa98-76a5-44d6-9701-c89a8a848b82 ┊ cmp1 ┊ 7000 ┊ Unused ┊ Ok ┊ UpToDate ┊ ┊ CV_15c4fa98-76a5-44d6-9701-c89a8a848b82 ┊ cmp2 ┊ 7000 ┊ Unused ┊ Ok ┊ UpToDate ┊ ╰───────────────────────────────────────────────────────────────────────────────────╯ Note, that cmp3 is arbiter and has no 'by-disk' representation: root@cmp1:~# ls -lR /dev/drbd* brw-rw---- 1 root disk 147, 1000 May 21 11:42 /dev/drbd1000 /dev/drbd/by-disk/sds: lrwxrwxrwx 1 root root 17 May 21 11:42 CV_15c4fa98-76a5-44d6-9701-c89a8a848b82_00000 -> ../../../drbd1000 /dev/drbd/by-res/CV_15c4fa98-76a5-44d6-9701-c89a8a848b82: lrwxrwxrwx 1 root root 17 May 21 11:42 0 -> ../../../drbd1000 root@cmp2:~# ls -lR /dev/drbd* brw-rw---- 1 root disk 147, 1000 May 21 11:42 /dev/drbd1000 /dev/drbd/by-disk/sds: lrwxrwxrwx 1 root root 17 May 21 11:42 CV_15c4fa98-76a5-44d6-9701-c89a8a848b82_00000 -> ../../../drbd1000 /dev/drbd/by-res/CV_15c4fa98-76a5-44d6-9701-c89a8a848b82: lrwxrwxrwx 1 root root 17 May 21 11:42 0 -> ../../../drbd1000 root@cmp3:~# ls -lR /dev/drbd* brw-rw---- 1 root disk 147, 1000 May 21 11:42 /dev/drbd1000 /dev/drbd/by-res/CV_15c4fa98-76a5-44d6-9701-c89a8a848b82: lrwxrwxrwx 1 root root 17 May 21 11:42 0 -> ../../../drbd1000 ==================================== [5] root@cmp1:~# lvdisplay [ ... ] --- Logical volume --- LV Path /dev/sds/CV_15c4fa98-76a5-44d6-9701-c89a8a848b82_00000 LV Name CV_15c4fa98-76a5-44d6-9701-c89a8a848b82_00000 VG Name sds LV UUID jGzcIQ-yRpH-RKxP-ExsH-JSn6-kTFn-8kpKYO LV Write Access read/write LV Creation host, time cmp1, 2020-05-21 11:42:14 +0300 LV Pool name thin LV Status available # open 2 LV Size 5.00 GiB Mapped size 0.02% Current LE 1280 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:4 root@cmp2:~# lvdisplay [ ... ] --- Logical volume --- LV Path /dev/sds/CV_15c4fa98-76a5-44d6-9701-c89a8a848b82_00000 LV Name CV_15c4fa98-76a5-44d6-9701-c89a8a848b82_00000 VG Name sds LV UUID 8pVwMo-e3ed-Sy0w-06IZ-M7Mh-YVIL-BtKZEG LV Write Access read/write LV Creation host, time cmp2, 2020-05-21 11:42:14 +0300 LV Pool name thin LV Status available # open 2 LV Size 5.00 GiB Mapped size 0.02% Current LE 1280 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:4 ==================================== [6] Traceback of nova-compute: 3304 ERROR nova.compute.manager [] Traceback (most recent call last): 3304 ERROR nova.compute.manager [] File "/usr/lib/python3/dist-packages/nova/compute/manager.py", line 2419, in _build_and_run_instance 3304 ERROR nova.compute.manager [] block_device_info=block_device_info) 3304 ERROR nova.compute.manager [] File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 3474, in spawn 3304 ERROR nova.compute.manager [] power_on=power_on) 3304 ERROR nova.compute.manager [] File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 6261, in _create_domain_and_network 3304 ERROR nova.compute.manager [] destroy_disks_on_failure) 3304 ERROR nova.compute.manager [] File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 3304 ERROR nova.compute.manager [] self.force_reraise() 3304 ERROR nova.compute.manager [] File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 3304 ERROR nova.compute.manager [] six.reraise(self.type_, self.value, self.tb) 3304 ERROR nova.compute.manager [] File "/usr/lib/python3/dist-packages/six.py", line 693, in reraise 3304 ERROR nova.compute.manager [] raise value 3304 ERROR nova.compute.manager [] File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 6230, in _create_domain_and_network 3304 ERROR nova.compute.manager [] post_xml_callback=post_xml_callback) 3304 ERROR nova.compute.manager [] File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 6164, in _create_domain 3304 ERROR nova.compute.manager [] guest.launch(pause=pause) 3304 ERROR nova.compute.manager [] File "/usr/lib/python3/dist-packages/nova/virt/libvirt/guest.py", line 143, in launch 3304 ERROR nova.compute.manager [] self._encoded_xml, errors='ignore') 3304 ERROR nova.compute.manager [] File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 3304 ERROR nova.compute.manager [] self.force_reraise() 3304 ERROR nova.compute.manager [] File "/usr/lib/python3/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 3304 ERROR nova.compute.manager [] six.reraise(self.type_, self.value, self.tb) 3304 ERROR nova.compute.manager [] File "/usr/lib/python3/dist-packages/six.py", line 693, in reraise 3304 ERROR nova.compute.manager [] raise value 3304 ERROR nova.compute.manager [] File "/usr/lib/python3/dist-packages/nova/virt/libvirt/guest.py", line 138, in launch 3304 ERROR nova.compute.manager [] return self._domain.createWithFlags(flags) 3304 ERROR nova.compute.manager [] File "/usr/local/lib/python3.6/dist-packages/eventlet/tpool.py", line 190, in doit 3304 ERROR nova.compute.manager [] result = proxy_call(self._autowrap, f, *args, **kwargs) 3304 ERROR nova.compute.manager [] File "/usr/local/lib/python3.6/dist-packages/eventlet/tpool.py", line 148, in proxy_call 3304 ERROR nova.compute.manager [] rv = execute(f, *args, **kwargs) 3304 ERROR nova.compute.manager [] File "/usr/local/lib/python3.6/dist-packages/eventlet/tpool.py", line 129, in execute 3304 ERROR nova.compute.manager [] six.reraise(c, e, tb) 3304 ERROR nova.compute.manager [] File "/usr/lib/python3/dist-packages/six.py", line 693, in reraise 3304 ERROR nova.compute.manager [] raise value 3304 ERROR nova.compute.manager [] File "/usr/local/lib/python3.6/dist-packages/eventlet/tpool.py", line 83, in tworker 3304 ERROR nova.compute.manager [] rv = meth(*args, **kwargs) 3304 ERROR nova.compute.manager [] File "/usr/lib/python3/dist-packages/libvirt.py", line 1110, in createWithFlags 3304 ERROR nova.compute.manager [] if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', dom=self) 3304 ERROR nova.compute.manager [] libvirt.libvirtError: Cannot access storage file 'None': No such file or directory -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

1 0

[neutron][release] Missing tarballs for networking-mlnx, networking-l2gw and vmware-nsx
by Mark Goddard 21 May '20

21 May '20

Hi, There are no tarballs published for ussuri networking-mlnx or vmware-nsx. The most recently published tarballs were in February. Is this expected? networking-l2gw also has no ussuri tarballs, although master was updated recently. Thanks, Mark

7 8

[kolla] deprecating kolla-cli
by Mark Goddard 21 May '20

21 May '20

Hi, We previously planned to retire kolla-cli due to lack of interest, but at the last minute there was an offer to help support it. That support is no longer available, and we are not aware of the project having gained traction since our original decision. We are therefore adding a deprecation notice [1] to the Ussuri release notes, with a plan to remove it from governance in Victoria if there is no response to the call for help. [1] https://review.opendev.org/729855 Thanks, Mark

1 0

[keystone][ldap]
by Amjad Kotobi 20 May '20

20 May '20

Hi all, I’m integrating keystone with LDAP, and having “service account” e.g. Nova, keystone etc.. which are in database. As soon as connecting it to ldap all authentication getting failed, how can I have both “service account” and “LDAP users” connected to Keystone? Here is my keystone.conf ################### [ldap] url = ldap://XXXXX user = uid=XXX,cn=sysaccounts,cn=etc,dc=XXX,dc=de password = dkrzprox user_tree_dn = cn=users,cn=accounts,dc=XXX,dc=de user_objectclass = posixAccount user_id_attribute = uid user_name_attribute = uid user_allow_create = false user_allow_update = false user_allow_delete = false group_tree_dn = cn=groups,cn=accounts,dc=XXX,dc=de group_objectclass = groupOfNames group_id_attribute = cn group_name_attribute = cn group_member_attribute = member group_desc_attribute = description group_allow_create = false group_allow_update = false group_allow_delete = false use_pool = true use_auth_pool = true debug_level = 4095 query_scope = sub [identity] driver = ldap ##################### OS: Centos7 OpenStack-Release: Train Any idea or example of options gonna be great! Thank you

3 2

[keystone]
by Amjad Kotobi 20 May '20

20 May '20

Hi, I have keystone running in HA multiple nodes, and after reboot one of the node it started in logs to pop up below messages “""WARNING keystone.server.flask.application [req-fe993224-cc7e-4e5f-83a8-1e925e60b995 24dfa0beaaaa48848b4eee68e449f2de d1fecbdb49ef4871b94b201b7856eed3 - default default] Could not recognize Fernet token: TokenNotFound: Could not recognize Fernet token””” And in command line “”"Unauthorized: The request you have made requires authentication. (HTTP 401) (Request-ID: req-1145c696-6275-4c78-9486-a690b98548ed)””" During command lines when request lands on machine which hasn’t rebooted or so, the result comes but on the rest fore-mentioned message always in place. Openstack release Train, and deployed manually. How can I tackle it down? Any ideas? Thanks Amjad

2 1

[docs][all] Important changes in recent openstackdocstheme updates
by Andreas Jaeger 20 May '20

20 May '20

A couple of changes recently merged into openstackdocstheme to fix problems reported. These had some surprises in it and we'd like to inform you about the changes: * Config options are now prefixed with openstackdocs_, the old names will be removed in a future release * The 'project' config option is now only respected (and displayed in the left menu) if 'openstackdocs_auto_name = False' is set. By default, the theme uses the package name (from setup.cfg) * The HTML files show the version number by default (with exception of releasenotes and api docs) calculated from git. If you want to use your own version number or disable it, set 'openstackdocs_auto_version = False' and manually configure the 'version' and 'release' options. * Previously, the theme always used 'pygments_style = "native"' and overrode the setting of 'sphinx' that many repos have. Now the setting is respected. For a few repos this lead to unreadable code snippets. If you see this or want to go back to the previous theme, configure 'pygments_style = "native"'. * Many projects have written PDF documents. openstackdocstheme can now optionally link to them. Set 'openstackdocs_pdf_link' to True to show the icon with path. Note that the PDF file is placed on docs.openstack.org in the top of the html files while in check/gate it's in a separate PDF folder. Thus, the site preview will show in check/gate a broken link - but it works fine, check [2]. * Both reno (since version 3.1.0) and openstackdocsstheme are now declared parallel safe, the CI jobs automatically build releasenotes in parallel [1]. You can modify your local tox job to do this by adding the '-j auto' parameter to your 'sphinx-build' invocation. We're releasing openstackdocstheme version 2.2.1 soon with two further fixes: * PDF documents will now show the version number like html document, no need to configure versions in conf.py for this anymore [3]. * small bug fix (if you set auto_name = False in doc/source/conf.py, this hit so far 5 repos)[4]. Everything is documented in the documentation of openstackdocstheme [2]. If there are any questions, best ask in #openstack-oslo. Andreas has started pushing changes to update projects with topic:reno-openstackdocstheme. Hope that's all for Victoria on the openstackdocstheme, Stephen and Andreas [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014902.html [2] https://docs.openstack.org/openstackdocstheme/ [3] https://review.opendev.org/729554 [4] https://review.opendev.org/729031 -- Andreas Jaeger aj(a)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

1 0