July 2020 - openstack-discuss - lists.openstack.org

[nova][dev] Revisiting qemu emulation where guest arch != host arch
by Apsey, Christopher 05 Jan '22

05 Jan '22

All, A few years ago I asked a question[1] about why nova, when given a hw_architecture property from glance for an image, would not end up using the correct qemu-system-xx binary when starting the guest process on a compute node if that compute nodes architecture did not match the proposed guest architecture. As an example, if we had all x86 hosts, but wanted to run an emulated ppc guest, we should be able to do that given that at least one compute node had qemu-system-ppc already installed and libvirt was successfully reporting that as a supported architecture to nova. It seemed like a heavy lift at the time, so it was put on the back burner. I am now in a position to fund a contract developer to make this happen, so the question is: would this be a useful blueprint that would potentially be accepted? Most of the time when people want to run an emulated guest they would just nest it inside of an already running guest of the native architecture, but that severely limits observability and the task of managing any more than a handful of instances in this manner quickly becomes a tangled nightmare of networking, etc. I see real benefit in allowing this scenario to run natively so all of the tooling that exists for fleet management 'just works'. This would also be a significant differentiator for OpenStack as a whole. Thoughts? [1] http://lists.openstack.org/pipermail/openstack-operators/2018-August/015653… Chris Apsey Director | Georgia Cyber Range GEORGIA CYBER CENTER 100 Grace Hopper Lane | Augusta, Georgia | 30901 https://www.gacybercenter.org

2 2

[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

[largescale-sig] OpenStack DB Archiver
by Arnaud Morin 10 Feb '21

10 Feb '21

Hello large-scalers! TLDR: we opensource a tool to help reducing size of databases. See https://github.com/ovh/osarchiver/ Few months ago, we released a tool, name osarchiver, which we are using on our production environment (at OVH) to help reduce the size of our tables in mariadb (or mysql) In fact, some tables are well know to grow very quickly. We use it, for example, to clean the OpenStack mistral database from old tasks, actions and executions which are older than a year. Another use case could be to archive some data in another table (e.g. with _archived as suffix) if they are 6 months old, and delete this data after 1 year. The source code of this tool is available here: https://github.com/ovh/osarchiver/ We were wondering if some other users would be interested in using the tool, and maybe move it under the opendev governance? Feel free to contact us and/or answer this thread. Cheers, -- Arnaud, Pierre-Samuel and OVH team

12 18

[qa][tempest] Update language in tempest code base
by Arx Cruz 05 Jan '21

05 Jan '21

Hello, I would like to start a discussion regarding the topic. At this moment in time we have an opportunity to be a more open and inclusive project by eliminating outdated naming conventions from tempest codebase, such as blacklist, whitelist. We should take the opportunity and do our best to replace outdated terms with their more inclusive alternatives. As you can see in [1] the TripleO project is already working on this initiative, and I would like to work on this as well on the tempest side. Any thoughts? Shall I start with a sepc, adding deprecation warnings? [1] https://review.opendev.org/#/c/740013/1/specs/victoria/renaming_rules.rst Kind regards, -- Arx Cruz Software Engineer Red Hat EMEA <https://www.redhat.com> arxcruz(a)redhat.com @RedHat <https://twitter.com/redhat> Red Hat <https://www.linkedin.com/company/red-hat> Red Hat <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

6 9

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

[Neutron] no L3 meeting this week (2020-June-01)
by LIU Yulong 28 Oct '20

28 Oct '20

Hi there, Due to the PTG meetings this week, we will cancel the L3 meeting this week. See you guys online next week. Regards, LIU Yulong

1 2

[tripleo][validations] new Validation Framework demos
by Mathieu Bultel 29 Sep '20

29 Sep '20

Hey TripleO, I have recorded three demos with the new Validation Framework (VF): 1st demo is similar to what Gael did few months ago but with the new code refactored (validations-libs/validations-common projects): https://asciinema.org/a/NRLULghjJa87qxRD9Nfq0FYoa 2nd demo is a use of the VF without any openstack/TripleO prerequisite, on a fresh and empty Ubuntu docker container, with only validations-libs and validations-common projects. It shows that only with a apt-get install git and python3-pip and with a basic python project installation we can run validations and use the framework: https://asciinema.org/a/2Jp9LZbN0xhJAR09zIpI6OpuB So it can answer a few demands such as: How to run validations as prep undercloud installation ? How to run validations on a non-openstack project ? What are the bare minimum requirements for being able to run Validations on a system ? May I run Validation remotely from my machine ? etc... The third one is mainly related to the deployment itself of TripleO. By using a simple PoC (https://review.opendev.org/#/c/724289/) I was able to make TripleO consuming the validations-libs framework and validation logging callback plugin. So it shows in this demo how the deploy steps playbook can be logged, parsed and shown with the VF CLI. This can be improve, modify & so on of course... it's basic usage. https://asciinema.org/a/344484 https://asciinema.org/a/344509 Mathieu.

4 5

[manila] Doc-a-thon event coming up next Thursday (Aug 6th)
by Victoria Martínez de la Cruz 24 Sep '20

24 Sep '20

Hi folks, We will be organizing a doc-a-thon next Thursday, August 6th, with the main goal of improving our docs for the next release. We will be gathering on our Freenode channel #openstack-manila after our weekly meeting (3pm UTC) and also using a videoconference tool (exact details TBC) to go over a curated list of opened doc bugs we have here [0]. *Your* participation is truly valued, being you an already Manila contributor or if you are interested in contributing and you didn't know how, so looking forward to seeing you there :) Cheers, Victoria [0] https://ethercalc.openstack.org/ur17jprbprxx

2 3

device compatibility interface for live migration with assigned devices
by Yan Zhao 15 Sep '20

15 Sep '20

hi folks, we are defining a device migration compatibility interface that helps upper layer stack like openstack/ovirt/libvirt to check if two devices are live migration compatible. The "devices" here could be MDEVs, physical devices, or hybrid of the two. e.g. we could use it to check whether - a src MDEV can migrate to a target MDEV, - a src VF in SRIOV can migrate to a target VF in SRIOV, - a src MDEV can migration to a target VF in SRIOV. (e.g. SIOV/SRIOV backward compatibility case) The upper layer stack could use this interface as the last step to check if one device is able to migrate to another device before triggering a real live migration procedure. we are not sure if this interface is of value or help to you. please don't hesitate to drop your valuable comments. (1) interface definition The interface is defined in below way: __ userspace /\ \ / \write / read \ ________/__________ ___\|/_____________ | migration_version | | migration_version |-->check migration --------------------- --------------------- compatibility device A device B a device attribute named migration_version is defined under each device's sysfs node. e.g. (/sys/bus/pci/devices/0000\:00\:02.0/$mdev_UUID/migration_version). userspace tools read the migration_version as a string from the source device, and write it to the migration_version sysfs attribute in the target device. The userspace should treat ANY of below conditions as two devices not compatible: - any one of the two devices does not have a migration_version attribute - error when reading from migration_version attribute of one device - error when writing migration_version string of one device to migration_version attribute of the other device The string read from migration_version attribute is defined by device vendor driver and is completely opaque to the userspace. for a Intel vGPU, string format can be defined like "parent device PCI ID" + "version of gvt driver" + "mdev type" + "aggregator count". for an NVMe VF connecting to a remote storage. it could be "PCI ID" + "driver version" + "configured remote storage URL" for a QAT VF, it may be "PCI ID" + "driver version" + "supported encryption set". (to avoid namespace confliction from each vendor, we may prefix a driver name to each migration_version string. e.g. i915-v1-8086-591d-i915-GVTg_V5_8-1) (2) backgrounds The reason we hope the migration_version string is opaque to the userspace is that it is hard to generalize standard comparing fields and comparing methods for different devices from different vendors. Though userspace now could still do a simple string compare to check if two devices are compatible, and result should also be right, it's still too limited as it excludes the possible candidate whose migration_version string fails to be equal. e.g. an MDEV with mdev_type_1, aggregator count 3 is probably compatible with another MDEV with mdev_type_3, aggregator count 1, even their migration_version strings are not equal. (assumed mdev_type_3 is of 3 times equal resources of mdev_type_1). besides that, driver version + configured resources are all elements demanding to take into account. So, we hope leaving the freedom to vendor driver and let it make the final decision in a simple reading from source side and writing for test in the target side way. we then think the device compatibility issues for live migration with assigned devices can be divided into two steps: a. management tools filter out possible migration target devices. Tags could be created according to info from product specification. we think openstack/ovirt may have vendor proprietary components to create those customized tags for each product from each vendor. e.g. for Intel vGPU, with a vGPU(a MDEV device) in source side, the tags to search target vGPU are like: a tag for compatible parent PCI IDs, a tag for a range of gvt driver versions, a tag for a range of mdev type + aggregator count for NVMe VF, the tags to search target VF may be like: a tag for compatible PCI IDs, a tag for a range of driver versions, a tag for URL of configured remote storage. b. with the output from step a, openstack/ovirt/libvirt could use our proposed device migration compatibility interface to make sure the two devices are indeed live migration compatible before launching the real live migration process to start stream copying, src device stopping and target device resuming. It is supposed that this step would not bring any performance penalty as -in kernel it's just a simple string decoding and comparing -in openstack/ovirt, it could be done by extending current function check_can_live_migrate_destination, along side claiming target resources.[1] [1] https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/libvi… Thanks Yan

14 118

Re: [neutron][networking-midonet] Maintainers needed
by Sebastian Saemann 10 Sep '20

10 Sep '20

Hi Slawek, we at NETWAYS are running most of our neutron networking on top of midonet and wouldn't be too happy if it gets deprecated and removed. So we would like to take over the maintainer role for this part. Please let me know how to proceed and how we can be onboarded easily. Best regards, Sebastian -- Sebastian Saemann Head of Managed Services NETWAYS Managed Services GmbH | Deutschherrnstr. 15-19 | D-90429 Nuernberg Tel: +49 911 92885-0 | Fax: +49 911 92885-77 CEO: Julian Hein, Bernd Erk | AG Nuernberg HRB25207 https://netways.de | sebastian.saemann(a)netways.de ** NETWAYS Web Services - https://nws.netways.de **

6 17

[cinder][stable] branch freeze for ocata, pike
by Brian Rosmaita 10 Sep '20

10 Sep '20

tl;dr - do not approve any backports to stable/ocata or stable/pike in any Cinder project deliverable stable/ocata has been tagged with ocata-eol in cinder, os-brick, python-cinderclient, and python-brick-cinderclient-ext. Nothing should be merged into stable/ocata in any of these repositories during the interim period before the branches are deleted. stable/pike: the changes discussed in [0] have merged, and I've proposed the pike-eol tags [1]. Nothing should be merged into stable/pike in any of our code repositories from now until the branches are deleted. [0] http://lists.openstack.org/pipermail/openstack-discuss/2020-July/016076.html [1] https://review.opendev.org/#/c/742523/

4 6

[tc] [all] Topics for Cross Community Discussion with Kubernetes ...
by Jay Bryant 09 Sep '20

09 Sep '20

All, Recently, the OpenStack TC has reached out to the Kubernetes Steering Committee for input as we have proposed adding a starter-kit:kubernetes-in-virt tag for projects in OpenStack. This request was received positively and as a result the TC has started brainstorming other topics that we could approach with the k8s community in this [1] etherpad. If you have topics that may be appropriate for this discussion please see the etherpad and add your ideas. Thanks! Jay IRC: jungleboyj [1] https://etherpad.opendev.org/p/kubernetes-cross-community-topics

3 3

Setuptools 48 and Devstack Failures
by Clark Boylan 31 Aug '20

31 Aug '20

Hello, Setuptools has made a new version 48 release. This appears to be causing problems for devstack because `pip install -e $PACKAGE_PATH` installs commands to /usr/bin and not /usr/local/bin on Ubuntu as it did in the past. `pip install $PACKAGE_PATH` continues to install to /usr/local/bin as expected. Devstack is failing because keystone-manage cannot currently be found at the specific /usr/local/bin/ path. Potential workarounds for this include not using `pip install -e` or relying on $PATH to find the commands rather than specifying rooted paths to them. I'll defer to the QA team on how they want to address this. While we can have devstack install an older setuptools version as well, generally this is not considered to be a good idea because anyone doing pip installs outside of devstack may get the newer behavior. It is actually important for us to try and keep up with setuptools changes as a result. Fungi indicated that setuptools expected this to be a bumpy upgrade. I'm not sure if they would consider `pip install -e` and `pip install` installing to different paths as a bug, and if they did which behavior is correct. It would probably be a good idea to file a bug upstream if we debug this further. Clark

5 6

Re: [cyborg] Temporary treatment plan for the 3rd-party driver
by yumeng bao 27 Aug '20

27 Aug '20

Brin, thanks for bringing this up! > Hi all： > This release we want to introduce some 3rd party drivers (e.g. Intel QAT, Inspur FPGA, and Inspur SSD etc.) in Cyborg, and we discussed the handling of 3rd-party driver CI in Cyborg IRC meeting [1]. > Due to the lack of CI test environment supported by hardware, we reached a temporary solution in two ways, as follows: > 1. Provide a CI environment and provide a tempest test for Cyborg, this method is recommended; > 2. If there is no CI environment, please provide the test results of this driver in the master branch or in the designated branch, which should be as complete as possible, sent to the Cyborg team, or pasted in the implementation of the commit. Providing test result can be our option. The test result can be part of the driver documentation[0] as this is public to users. And from my understanding, the test result should work as the role of tempest case and clarify at least: necessary configuration,test operations and test results. [0] https://docs.openstack.org/cyborg/latest/reference/support-matrix.html#driv… > [1] http://eavesdrop.openstack.org/meetings/openstack_cyborg/2020/openstack_cyb… Regards， Yumeng

4 4

[largescale-sig] RPC ping
by Arnaud Morin 20 Aug '20

20 Aug '20

Hey all, TLDR: I propose a change to oslo_messaging to allow doing a ping over RPC, this is useful to monitor liveness of agents. Few weeks ago, I proposed a patch to oslo_messaging [1], which is adding a ping endpoint to RPC dispatcher. It means that every openstack service which is using oslo_messaging RPC endpoints (almosts all OpenStack services and agents - e.g. neutron server + agents, nova + computes, etc.) will then be able to answer to a specific "ping" call over RPC. I decided to propose this patch in my company mainly for 2 reasons: 1 - we are struggling monitoring our nova compute and neutron agents in a correct way: 1.1 - sometimes our agents are disconnected from RPC, but the python process is still running. 1.2 - sometimes the agent is still connected, but the queue / binding on rabbit cluster is not working anymore (after a rabbit split for example). This one is very hard to debug, because the agent is still reporting health correctly on neutron server, but it's not able to receive messages anymore. 2 - we are trying to monitor agents running in k8s pods: when running a python agent (neutron l3-agent for example) in a k8s pod, we wanted to find a way to monitor if it is still live of not. Adding a RPC ping endpoint could help us solve both these issues. Note that we still need an external mechanism (out of OpenStack) to do this ping. We also think it could be nice for other OpenStackers, and especially large scale ops. Feel free to comment. [1] https://review.opendev.org/#/c/735385/ -- Arnaud Morin

10 31

[tripleo][ci] container pulls failing
by Wesley Hayutin 19 Aug '20

19 Aug '20

FYI... If you find your jobs are failing with an error similar to [1], you have been rate limited by docker.io via the upstream mirror system and have hit [2]. I've been discussing the issue w/ upstream infra, rdo-infra and a few CI engineers. There are a few ways to mitigate the issue however I don't see any of the options being completed very quickly so I'm asking for your patience while this issue is socialized and resolved. For full transparency we're considering the following options. 1. move off of docker.io to quay.io 2. local container builds for each job in master, possibly ussuri 3. parent child jobs upstream where rpms and containers will be build and host artifacts for the child jobs 4. remove some portion of the upstream jobs to lower the impact we have on 3rd party infrastructure. If you have thoughts please don't hesitate to share on this thread. Very sorry we're hitting these failures and I really appreciate your patience. I would expect major delays in getting patches merged at this point until things are resolved. Thank you! [1] HTTPError: 429 Client Error: Too Many Requests for url: http://mirror.ca-ymq-1.vexxhost.opendev.org:8082/v2/tripleotrain/centos-bin… [2] https://bugs.launchpad.net/tripleo/+bug/1889122

8 20

[cloudkitty][tc] Cloudkitty abandoned?
by Sean McGinnis 19 Aug '20

19 Aug '20

Posting here to raise awareness, and start discussion about next steps. It appears there is no one working on Cloudkitty anymore. No patches have been merged for several months now, including simple bot proposed patches. It would appear no one is maintaining this project anymore. I know there is a need out there for this type of functionality, so maybe this will raise awareness and get some attention to it. But barring that, I am wondering if we should start the process to retire this project. From a Victoria release perspective, it is milestone-2 week, so we should make a decision if any of the Cloudkitty deliverables should be included in this release or not. We can certainly force releases of whatever is the latest, but I think that is a bit risky since these repos have never merged the job template change for victoria and therefore are not even testing with Python 3.8. That is an official runtime for Victoria, so we run the risk of having issues with the code if someone runs under 3.8 but we have not tested to make sure there are no problems doing so. I am hoping this at least starts the discussion. I will not propose any release patches to remove anything until we have had a chance to discuss the situation. Sean

11 20

[masakari] Meetings
by Radosław Piliszek 14 Aug '20

14 Aug '20

Hello Fellow cloud-HA-seekers, I wanted to attend Masakari meetings but I found the current schedule unfit. Is there a chance to change the schedule? The day is fine but a shift by +3 hours would be nice. Anyhow, I wanted to discuss [1]. I've already proposed a change implementing it and looking forward to positive reviews. :-) That said, please reply on the change directly, or mail me or catch me on IRC, whichever option sounds best to you. [1] https://blueprints.launchpad.net/masakari/+spec/customisable-ha-enabled-ins… -yoctozepto

2 2

[Ocata][Heat] Strange error returned after stack creation failure -r aw template with id xxx not found
by Laurent Dumont 13 Aug '20

13 Aug '20

Hi! We are currently troubleshooting a Heat stack issue where one of the stack (one of 25 or so) is failing to be created properly (seemingly randomly). The actual error returned by Heat is quite strange and Google has been quite sparse in terms of references. The actual error looks like the following (I've sanitized some of the names): Resource CREATE failed: resources.potato: Resource CREATE failed: resources[0]: raw template with id 22273 not found heat resource-list STACK_NAME_HERE -n 50 > > +------------------+--------------------------------------+-------------------------+-----------------+----------------------+--------------------------------------------------------------------------+ > | resource_name | physical_resource_id | resource_type > | resource_status | updated_time | stack_name > | > > +------------------+--------------------------------------+-------------------------+-----------------+----------------------+--------------------------------------------------------------------------+ > | potato | RESOURCE_ID_HERE | OS::Heat::ResourceGroup | > CREATE_FAILED | 2020-07-18 T19:52:10Z | nested_stack_1_STACK_NAME_HERE > | > | potato_server_group | RESOURCE_ID_HERE | OS::Nova::ServerGroup | > CREATE_COMPLETE | 2020-07-21T19:52:10Z | nested_stack_1_STACK_NAME_HERE > | > | 0 | | potato1.yaml > | CREATE_FAILED | 2020-07-18T19:52:12Z | nested_stack_2_STACK_NAME_HERE > | > | 1 | | potato1.yaml > | INIT_COMPLETE | 2020-07- 18 T19:52:12Z | > nested_stack_2_STACK_NAME_HERE | > > +------------------+--------------------------------------+-------------------------+-----------------+----------------------+--------------------------------------------------------------------------+ > The template itself is pretty simple and attempts to create a ServerGroup and 2 VMs (as part of the ResourceGroup). My feeling is that one the creation of those machines fails and Heat get's a little cooky and returns an error that might not be the actual root cause. I would have expected the VM to show up in the resource list but I just see the source "yaml". Has anyone seen something similar in the past? Thanks!

2 3

Re: [Openstack-mentoring] Neutron subnet with DHCP relay - continued
by Amy Marrich 10 Aug '20

10 Aug '20

Hey Tom, Adding the OpenStack discuss list as I think you got several replies from there as well. Thanks, Amy (spotz) On Mon, Jul 13, 2020 at 5:37 PM Thomas King <thomas.king(a)gmail.com> wrote: > Good day, > > I'm bringing up a thread from June about DHCP relay with neutron networks > in Ironic, specifically using unicast relay. The Triple-O docs do not have > the plain config/neutron config to show how a regular Ironic setup would > use DHCP relay. > > The Neutron segments docs state that I must have a unique physical network > name. If my Ironic controller has a single provisioning network with a > single physical network name, doesn't this prevent my use of multiple > segments? > > Further, the segments docs state this: "The operator must ensure that > every compute host that is supposed to participate in a router provider > network has direct connectivity to one of its segments." (section 3 at > https://docs.openstack.org/neutron/pike/admin/config-routed-networks.html#p… - > current docs state the same thing) > This defeats the purpose of using DHCP relay, though, where the Ironic > controller does *not* have direct connectivity to the remote segment. > > Here is a rough drawing - what is wrong with my thinking here? > Remote server: 10.146.30.32/27 VLAN 2116<-----> Router with DHCP relay > <------> Ironic controller, provisioning network: 10.146.29.192/26 VLAN > 2115 > > Thank you, > Tom King > _______________________________________________ > openstack-mentoring mailing list > openstack-mentoring(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-mentoring >

3 12

[puppet][congress] Retiring puppet-congress
by Takashi Kajinami 10 Aug '20

10 Aug '20

Hello, As you know, Congress project has been retired already[1], so we will retire its puppet module, puppet-congress in openstack puppet project as well. [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014292.ht… Because congress was directly retired instead of getting migrated to x namespace, we'll follow the same way about puppet-congress retirement and won't create x/puppet-congress. Thank you for the contribution made for the project ! Please let us know if you have any concerns about this retirement. Thank you, Takashi Kajinami

2 1

[horizon] Victoria virtual mid-cycle poll
by Ivan Kolodyazhny 06 Aug '20

06 Aug '20

Hi team, As discussed at Horizon's Virtual PTG [1], we'll have a virtual mid-cycle meeting around Victoria-2 milestone. We'll discuss Horizon current cycle development priorities and the future of Horizon with modern JS frameworks. Please indicate your availability to meet for the first session, which will be held during the week of July 27-31: https://doodle.com/poll/3neps94amcreaw8q Please respond before 12:00 UTC on Tuesday 4 August. [1] https://etherpad.opendev.org/p/horizon-v-ptg Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

1 3

[horizon] patternfly?
by Mohammed Naser 06 Aug '20

06 Aug '20

Hi everyone, I was wondering if anyone in the community has explored the idea of implementing PatternFly inside Horizon. It seems like it shares a lot of the similar ideas that we use and we could really benefit from using a common library that already exists with a lot of good UX thought behind it. I know it's based on React which is a bit of a leap from where Horizon is today. However, I'd be curious if the Horizon team is interested in figuring out a plan to make a migration to something like this happen. Personally, I think I would be able to provide resources to have someone do this work. However, if this seems like a huge stretch and architecture change where it actually makes more sense to stand this up from scratch (and implement an architecture where the dashboard talks directly to the APIs?), perhaps we should explore that. I also would like to hear more from our extended community too, as I think we really need to improve our user interface experience. Thanks, Mohammed -- Mohammed Naser VEXXHOST, Inc.

11 31

[TC] [PTG] Victoria vPTG Summary of Conversations and Action Items
by Kendall Nelson 06 Aug '20

06 Aug '20

Hello Everyone! I hope you all had a productive and enjoyable PTG! While it’s still reasonably fresh, I wanted to take a moment to summarize discussions and actions that came out of TC discussions. If there is a particular action item you are interested in taking, please reply on this thread! For the long version, check out the etherpad from the PTG[1]. Tuesday ====== Ussuri Retrospective ---------------------------- As usual we accomplished a lot. Some of the things we accomplished were around enumerating operating systems per release (again), removing python2 support, and adding the ideas repository. Towards the end of the release, we had a lot of discussions around what to do with leaderless projects, the role of PTLs, and what to do with projects that were missing PTL candidates for the next release. We discussed office hours, their history and reason for existence, and clarified how we can strengthen communication amongst ourselves, the projects, and the larger community. TC Onboarding -------------------- It was brought up that those elected most recently (and even new members the election before) felt like there wasn’t enough onboarding into the TC. Through discussion about what we can do to better support returning members is to better document the daily, weekly and monthly tasks TC members are supposed to be doing. Kendall Nelson proposed a patch to start adding more detail to a guide for TC members already[2]. It was also proposed that we have a sort of mentorship or shadow program for people interested in joining the TC or new TC members by more experienced TC members. The discussion about the shadow/mentorship program is to be continued. TC/UC Merge ------------------ Thierry gave an update on the merge of the committees. The simplified version is that the current proposal is that UC members are picked from TC members, the UC operates within the TC, and that we are already setup for this given the number of TC members that have AUC status. None of this requires a by-laws change. One next step that has already begun is the merging of the openstack-users ML into openstack-discuss ML. Other next steps are to decide when to do the actual transition (disbanding the separate UC, probably at the next election?) and when to setup AUC’s to be defined as extra-ATC’s to be included in the electorate for elections. For more detail, check out the openstack-discuss ML thread[3]. Wednesday ========= Help Wanted List ----------------------- We settled on a format for the job postings and have several on the list. We talked about how often we want to look through, update or add to it. The proposal is to do this yearly. We need to continue pushing on the board to dedicate contributors at their companies to work on these items, and get them to understand that it's an investment that will take longer than a year in a lot of cases; interns are great, but not enough. TC Position on Foundation Member Community Contributions ---------------------------------------------------------------------------------- The discussion started with a state of things today - the expectations of platinum members, the benefits the members get being on the board and why they should donate contributor resources for these benefits, etc. A variety of proposals were made: either enforce or remove the minimum contribution level, give gold members the chance to have increased visibility (perhaps giving them some of the platinum member advantages) if they supplement their monetary contributions with contributor contributions, etc. The #ACTION that was decided was for Mohammed to take these ideas to the board and see what they think. OpenStack User-facing APIs -------------------------------------- Users are confused about the state of the user facing API’s; they’ve been told to use the OpenStackClient(OSC) but upon use, they discover that there are features missing that exist in the python-*clients. Partial implementation in the OSC is worse than if the service only used their specific CLI. Members of the OpenStackSDK joined discussions and explained that many of the barriers that projects used to have behind implementing certain commands have been resolved. The proposal is to create a pop up team and that they start with fully migrating Nova, documenting the process and collecting any other unresolved blocking issues with the hope that one day we can set the migration of the remaining projects as a community goal. Supplementally, a new idea was proposed- enforcing new functionality to services is only added to the SDK (and optionally the OSC) and not the project’s specific CLI to stop increasing the disparity between the two. The #ACTION here is to start the pop up team, if you are interested, please reply! Additionally, if you disagree with this kind of enforcement, please contact the TC as soon as possible and explain your concerns. PTL Role in OpenStack today & Leaderless Projects --------------------------------------------------------------------- This was a veeeeeeeerrrry long conversation that went in circles a few times. The very short version is that we, the TC, are willing to let project teams decide for themselves if they want to have a more deconstructed kind of PTL role by breaking it into someone responsible for releases and someone responsible for security issues. This new format also comes with setting the expectation that for things like project updates and signing up for PTG time, if someone on the team doesn’t actively take that on, the default assumption is that the project won’t participate. The #ACTION we need someone to take on is to write a resolution about how this will work and how it can be done. Ideally, this would be done before the next technical election, so that teams can choose it at that point. If you are interested in taking on the writing of this resolution, please speak up! Cross Project Work ------------------------- -Pop Up Teams- The two teams we have right now are Encryption and Secure Consistent Policy Groups. Both are making slow progress and will continue. -Reducing Community Goals Per Cycle- Historically we have had two goals per cycle, but for smaller teams this can be a HUGE lift. The #ACTION is to clearly outline the documentation for the goal proposal and selection process to clarify that selecting only one goal is fine. No one has claimed this action item yet. -Victoria Goal Finalization- Currently, we have three proposals and one accepted goal. If we are going to select a second goal, it needs to be done ASAP as Victoria development has already begun. All TC members should review the last proposal requesting selection[4]. -Wallaby Cycle Goal Discussion Kick Off- Firstly, there is a #ACTION that one or two TC members are needed to guide the W goal selection. If you are interested, please reply to this thread! There were a few proposed goals for VIctoria that didn’t make it that could be the starting point for W discussions, in particular, the rootwrap goal which would be good for operators. The OpenStackCLI might be another goal to propose for Wallaby. Detecting Unmaintained Projects Early --------------------------------------------------- The TC liaisons program had been created a few releases ago, but the initial load on TC members was large. We discussed bringing this program back and making the project health checks happen twice a release, either the start or end of the release and once in the middle. TC liaisons will look at previously proposed releases, release activity of the team, the state of tempest plugins, if regular meetings are happening, if there are patches in progress and how busy the project’s IRC channel is to make a determination. Since more than one liaison will be assigned to each project, those liaisons can divvy up the work how they see fit. The other aspect that still needs to be decided is where the health checks will be recorded- in a wiki? In a meeting and meeting logs? That decision is still to be continued. The current #ACTION currently unassigned is that we need to assign liaisons for the Victoria cycle and decide when to do the first health check. Friday ===== Reducing Systems and Friction to Drive Change ---------------------------------------------------------------- This was another conversation that went in circles a bit before realizing that we should make a list of the more specific problems we want to address and then brainstorm solutions for them. The list we created (including things already being worked) are as follows: - TC separate from UC (solution in progress) - Stable releases being approved by a separate team (solution in progress) - Making repository creation faster (especially for established project teams) - Create a process blueprint for project team mergers - Requirements Team being one person - Stable Team - Consolidate the agent experience - Figure out how to improve project <--> openstack client/sdk interaction. If you feel compelled to pick one of these things up and start proposing solutions or add to the list, please do! Monitoring in OpenStack (Ceilometer + Telemetry + Gnocchi State) ----------------------------------------------------------------------------------------- This conversation is also ongoing, but essentially we talked about the state of things right now- largely they are not well maintained and there is added complexity with Ceilometers being partially dependent on Gnocchi. There are a couple of ideas to look into like using oslo.metrics for the interface between all the tools or using Ceilometer without Gnocchi if we can clean up those dependencies. No specific action items here, just please share your thoughts if you have them. Ideas Repo Next Steps ------------------------------- Out of the Ussuri retrospective, it was brought up that we probably needed to talk a little more about what we wanted for this repo. Essentially we just want it to be a place to collect ideas into without worrying about the how. It should be a place to document ideas we have had (old and new) and keep all the discussion in one place as opposed to historic email threads, meetings logs, other IRC logs, etc. We decided it would be good to periodically go through this repo, likely as a forum session at a summit to see if there is any updating that could happen or promotion of ideas to community goals, etc. ‘tc:approved-release’ Tag --------------------------------- This topic was proposed by the Manila team from a discussion they had earlier in the week. We talked about the history of the tag and how usage of tags has evolved. At this point, the proposal is to remove the tag as anything in the releases repo is essentially tc-approved. Ghanshyam has volunteered to document this and do the removal. The board also needs to be notified of this and to look at projects.yaml in the governance repo as the source of truth for TC approved projects. The unassigned #ACTION item is to review remaining tags and see if there are others that need to be modified/removed/added to drive common behavior across OpenSack components. Board Proposals ---------------------- This was a pretty quick summary of all discussions we had that had any impact on the board and largely decided who would mention them. Session Feedback ------------------------ This was also a pretty quick topic compared to many of the others, we talked about how things went across all our discussions (largely we called the PTG a success) logistically. We tried to make good use of the raising hands feature which mostly worked, but it lacks context and its possible that the conversation has moved on by the time it’s your turn (if you even remember what you want to say). OpenStack 2.0: k8s Native ----------------------------------- This topic was brought up at the end of our time so we didn’t have time to discuss it really. Basically Mohammed wanted to start the conversation about adding k8s as a base service[5] and what we would do if a project proposed required k8s. Adding services that work with k8s could open a door to new innovation in OpenStack. Obviously this topic will need to be discussed further as we barely got started before we had to wrap things up. So. The tldr; Here are the #ACTION items we need owners for: - Start the User Facing API Pop Up Team - Write a resolution about how the deconstructed PTL roles will work - Update Goal Selection docs to explain that one or more goals is fine; it doesn’t have to be more than one - Two volunteers to start the W goal selection process - Assign two TC liaisons per project - Review Tags to make sure they are still good for driving common behavior across all openstack projects Here are the things EVERYONE needs to do: - Review last goal proposal so that we can decide to accept or reject it for the V release[4] - Add systems that are barriers to progress in openstack to the Reducing Systems and Friction list - Continue conversations you find important Thanks everyone for your hard work and great conversations :) Enjoy the attached (photoshopped) team photo :) -Kendall (diablo_rojo) [1] TC PTG Etherpad: https://etherpad.opendev.org/p/tc-victoria-ptg [2] TC Guide Patch: https://review.opendev.org/#/c/732983/ [3] UC TC Merge Thread: http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014736.html [4] Proposed V Goal: https://review.opendev.org/#/c/731213/ [5] Base Service Description: https://governance.openstack.org/tc/reference/base-services.html

3 2