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

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

14 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 02 Nov '20

02 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 23 Jun '20

23 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 19 Jun '20

19 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 16 Jun '20

16 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 15 Jun '20

15 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 09 Jun '20

09 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 06 Jun '20

06 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 06 Jun '20

06 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 06 Jun '20

06 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 06 Jun '20

06 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 03 Jun '20

03 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 03 Jun '20

03 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 03 Jun '20

03 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 02 Jun '20

02 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 01 Jun '20

01 Jun '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 01 Jun '20

01 Jun '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 01 Jun '20

01 Jun '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 01 Jun '20

01 Jun '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 01 Jun '20

01 Jun '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 01 Jun '20

01 Jun '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 01 Jun '20

01 Jun '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 30 May '20

30 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 30 May '20

30 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 30 May '20

30 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 30 May '20

30 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 30 May '20

30 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 30 May '20

30 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 29 May '20

29 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 29 May '20

29 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 29 May '20

29 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 29 May '20

29 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