June 2020 - openstack-discuss - lists.openstack.org

[openstackl][cinder][nova] attacched volume retype error
by Ignazio Cassano 15 Jun '20

15 Jun '20

Hello All, I am facing an issue when I retype a volume attached to a vm from netapp nfs to ceph on stein. It work fron nfs to iscsi but not from nfs to ceph. It seems a nova issue. I got an error in nova compute log: Failed to swap volume 26add23f-d643-4020-9935-9e856a0e9d93 for 1a2edc3a-cc3e-4a92-9488-6e6fabd01825: NotImplementedError: Swap only supports host devices I read there is an old blueprint for this but I do know if it has been implemented. Any help, please? Ignazio

2 2

[ironic][centos]grubaa64.efi request different filename
by Jeffrey Zhang 15 Jun '20

15 Jun '20

hey guys, I am testing a standalone ironic node on arm64 node through centos 7. Then dnsmasq is configured as following ``` enable-tftp tftp-root=/var/lib/ironic/public/boot/tftp # dhcp-option=option:router,192.168.122.1 # use static dhcp-range=10.0.0.167,static,60s log-queries log-dhcp dhcp-match=set:efi-arm64,option:client-arch,11 dhcp-boot=tag:efi-arm64,grubaa64.efi ``` the grubaa64.efi file come from `/boot/efi/EFI/centos/grubaa64.efi` on centos 7 But seems grubaa64.efi file are trying different grub.cfg filename like `grub.cfg-xx-xx-xx-xx`( check bellow) Whereas ironic generate filename like `xx:xx:xx:xx:xx.conf`. Is this a bug in ironic? or I made something wrong? ``` dnsmasq-dhcp[1]: 140425456 vendor class: PXEClient:Arch:00011:UNDI:003000 dnsmasq-dhcp[1]: 140425456 DHCPREQUEST(eth1) 10.0.0.171 52:54:00:ea:56:f2 dnsmasq-dhcp[1]: 140425456 tags: known, efi-arm64, eth1 dnsmasq-dhcp[1]: 140425456 DHCPACK(eth1) 10.0.0.171 52:54:00:ea:56:f2 pxe-uefi dnsmasq-dhcp[1]: 140425456 requested options: 1:netmask, 2:time-offset, 3:router, 4, 5, dnsmasq-dhcp[1]: 140425456 requested options: 6:dns-server, 12:hostname, 13:boot-file-size, dnsmasq-dhcp[1]: 140425456 requested options: 15:domain-name, 17:root-path, 18:extension-path, dnsmasq-dhcp[1]: 140425456 requested options: 22:max-datagram-reassembly, 23:default-ttl, dnsmasq-dhcp[1]: 140425456 requested options: 28:broadcast, 40:nis-domain, 41:nis-server, dnsmasq-dhcp[1]: 140425456 requested options: 42:ntp-server, 43:vendor-encap, 50:requested-address, dnsmasq-dhcp[1]: 140425456 requested options: 51:lease-time, 54:server-identifier, 58:T1, dnsmasq-dhcp[1]: 140425456 requested options: 59:T2, 60:vendor-class, 66:tftp-server, 67:bootfile-name, dnsmasq-dhcp[1]: 140425456 requested options: 97:client-machine-id, 128, 129, 130, 131, dnsmasq-dhcp[1]: 140425456 requested options: 132, 133, 134, 135 dnsmasq-dhcp[1]: 140425456 next server: 10.0.0.167 dnsmasq-dhcp[1]: 140425456 broadcast response dnsmasq-dhcp[1]: 140425456 sent size: 1 option: 53 message-type 5 dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 54 server-identifier 10.0.0.167 dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 51 lease-time 2m dnsmasq-dhcp[1]: 140425456 sent size: 13 option: 67 bootfile-name grubaa64.efi dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 58 T1 1m dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 59 T2 1m45s dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 1 netmask 255.255.255.0 dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 28 broadcast 10.0.0.255 dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 3 router 10.0.0.167 dnsmasq-dhcp[1]: 140425456 sent size: 4 option: 6 dns-server 10.0.0.167 dnsmasq-dhcp[1]: 140425456 sent size: 8 option: 12 hostname pxe-uefi dnsmasq-tftp[1]: error 8 User aborted the transfer received from 10.0.0.171 dnsmasq-tftp[1]: failed sending /var/lib/ironic/public/boot/tftp/grubaa64.efi to 10.0.0.171 dnsmasq-tftp[1]: sent /var/lib/ironic/public/boot/tftp/grubaa64.efi to 10.0.0.171 dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-01-52-54-00-ea-56-f2 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A0000AB not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A0000A not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A0000 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A000 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A00 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A0 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0A not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg-0 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/grub.cfg not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-01-52-54-00-ea-56-f2 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A0000AB not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A0000A not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A0000 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A000 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A00 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A0 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0A not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg-0 not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/grub.cfg not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/arm64-efi/command.lst not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/arm64-efi/fs.lst not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/arm64-efi/crypto.lst not found dnsmasq-tftp[1]: file /var/lib/ironic/public/boot/tftp/EFI/centos/arm64-efi/terminal.lst not found ``` --- Regards, Jeffrey Zhang Blog: http://xcodest.me

2 2

[Neutron] Neutron Bug Deputy report Jun 8-15
by Jakub Libosvar 15 Jun '20

15 Jun '20

Hi, I was bug deputy for the week of June 8, there are no critical bugs, which is good 🙂 Here is the summary: * Needs further triage * Improper routing between private networks * https://bugs.launchpad.net/neutron/+bug/1883288 * Needs more investigation * after FIP is assigned vm lost network connection * https://bugs.launchpad.net/neutron/+bug/1882860 * may be related to https://github.com/ovn-org/ovn/commit/fda9a1dd3c995f25cad9e828e701f8b41d347… * or DVR + VLAN provider network * internal server error on updating no-gateway on the dhcpv6 subnet * https://bugs.launchpad.net/neutron/+bug/1882873 * needs more info about reproducer * High * Fix flows l2 population related on br-tun being cleaned after RabbitMQ cluster has experienced a network partition * https://bugs.launchpad.net/neutron/+bug/1883071 * Triaged as High as it has an impact on tenant traffic because sometimes the flows related to tunnels in L2 pop gets cleaned * bagpipe: bagpipe-bgp does not start with EVPN and OVS driver * https://bugs.launchpad.net/neutron/+bug/1883102 * More options need to be passed to OVS in EVPN * Neutron OpenvSwitch DVR - connection problem * https://bugs.launchpad.net/neutron/+bug/1883321 * traffic of one VM on a compute node influences traffic of other VM, only on DVR ml2/ovs * Medium * [L3] floating IP failed to bind due to no agent gateway port(fip-ns) * https://bugs.launchpad.net/neutron/+bug/1883089 * Marked as Medium by reporter * Has a fix on review https://review.opendev.org/#/c/735432/ * Low * [neutron-tempest-plugin] "wait_for_interface_status" only retrieves the Nova server information, not the VM network * https://bugs.launchpad.net/neutron/+bug/1883095 * Fix proposed: https://review.opendev.org/#/c/735117/ * RFE * RFE: allow replacing the QoS policy of bound port * https://bugs.launchpad.net/neutron/+bug/1882804 * needs to be triaged by the drivers team

1 0

[glance] Victoria Virtual PTG
by Abhishek Kekane 15 Jun '20

15 Jun '20

Hi All, We had our first virtual summit last week from 1st June to 5th June 2020. Using meetpad we had lots of discussion around different topics for glance and glance + cinder. I have created etherpad [1] with Notes from session and which also includes the recordings of each discussion. Below is the list of what we discussed during PTG. 1. Image encryption (glance side work) 2. Unified Limits Integration with Glance 3. Calculate virtual_size during image creation 4. Remove usage of six library 5. Remove single store configuration from glance_store 6. Cluster awareness 7. Cache-API 8. Improve performance of ceph/rbd store of glance (multi-threaded rbd driver) 9. Duplicate downloads 10. Code cleanup, enhancements 11. Cinder/Glance creating image from volume with Ceph 12. Make a cinder store of glance compatible with multiple stores 13. Gate job for glance cinder store 14. Support for sparse image upload to ceph 15. Victoria priorities Kindly let me know if you have any questions about the same. [1] https://etherpad.opendev.org/p/glance-victoria-ptg Thank you, Abhishek

1 0

[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

[announce] [debian] New deb-status page and extrepo configuration available for OpenStack on Debian
by Thomas Goirand 14 Jun '20

14 Jun '20

Hi! We've just setup online a new deb-status system [2] to compare what's been released in OpenStack upstream and what has been packaged in Debian. This is an effort to keep each stable branch up-to-date in Debian. This has been possible thanks to Michal Arbet from ultimum.io who wrote os-version-checker [1]. So, a big up to him and ultimum technologies. Note that the Rocky page may not reflect reality, since most of the components are available directly in Debian Buster. Browsing this page, you will notice that both Train and Ussuri are pretty much in an up-to-date shape! :) Note that this page is updated every hours. Also, the Debian packages are now available using extrepo, to make it easier to install. Extrepo is an initiative from Wouter Verhelst to have something comparable to PPA, at least in the way to install the repositories (ie: super easy now...). For example, to install Ussuri in Buster, one can do: apt-get install -t buster-backports extrepo extrepo enable openstack_ussuri This will install the repository as: /etc/apt/sources.list.d/extrepo_openstack_train.sources then you can start using Ussuri using apt as usual. Last, we're searching for volunteers to mirror the osbpo.debian.net Buster backport repositories (to make sure it isn't only on the hands of me and my employer). The only thing that shall be done is to setup an rsync mirroring of the repositories. Best would be to have a mirror in north-America and in Asia. If you're volunteering for this, especially if you are administering a CDN, please get in touch. Hoping this will improve the OpenStack on Debian experience, Cheers, Thomas Goirand (zigo) [1] https://salsa.debian.org/openstack-team/debian/os-version-checker [2] http://osbpo.debian.net/deb-status/

1 0

[nova][doc] nova pdf building failing on new sphinx 3.1.0
by Ghanshyam Mann 13 Jun '20

13 Jun '20

Hello Everyone, With the new release of Sphinx 3.1.0, nova pdf-docs building started failing due to TeX memory issue (maybe this one - https://github.com/sphinx-doc/sphinx/issues/3099) I could not find the related changes in 3.1.0 which can cause this issue. The issue is to include the giant sample files(policy for now) in pdf doc. I am sure that was discussed previously also when we started pdf building in the Train cycle but do not know what was the solution? Luckily neutron is not facing this as their config sample files are as large as nova. I have logged bug[1] and provided the workaround[2] to unblock the nova gate. Workaround is to include the link to the sample file instead if its full content. Any thoughts on how to fix this? [1] https://bugs.launchpad.net/nova/+bug/1883200 [2] https://review.opendev.org/#/c/735279/ -gmann

1 1

Re: [Interop_WG] Today Fiday 6th June 10 AM PDT call
by prakash RAMCHANDRAN 13 Jun '20

13 Jun '20

Hi all, Can you help me on irc, should we be using #openstack-interop or #openstack-interopwgWHich of this we will be able to use the bit to record meetings besides the call? #topic 1 - Review of content for "OpenStack Powered DNS" and "OpenStack Powered Orchestration"#info We need to update the site https://www.openstack.org/brand/openstack-powered/ #topic 2 - Marketplace Vendors to validate their OpenStack Powered offers for Ussuri This can be tested on https://refstack.openstack.org/#/community_results I don't see any tests being made by any one on 11th or 12 th June, any reasons, is there a transition goin on or there is some issue with refstack-client? #action Prakash to follow up with Mark & Ghanshyam on both web site update for Logo add-on programs and refstack-client working wrt Refstack portal #topic 3 - Follow ups to close for Usuri actions items #action Seek help from Staff to update the formality to make "one or more co-chairs" in B192#link https://review.opendev.org/gitweb?p=openstack/interop.git;a=blob;f=doc/sour…... #info updated the googledocs for interops on CinderV2 apis being removed , correction it should have appeared as deprecated in 2019.11 , no issues as we have now dropped it out in 2020.11 approval#link https://docs.google.com/document/d/1vf8rxKxuFoXmZCxfMIIfHm4TzK1kuANktXyUHiu…... topic 4 - Formation new committee for Future Interop work - we discuss this before OpenDev June 29 and help get approvals next Board meeting #info consider Conformance vs Compliance to keep off legal part for new certifications or Logo programs Q1. Data points from MarketPlace?Please educate us how we collect Marketplace data - How customers use the Marketplace? Can we get Data points from Marketplace? If so How? Any answers from TC community or Users Community folks? Q2. Does Tempest testing Infra provider/Vendors offerings occur in real time or you run a batch and send report to interop and who receives this test results? Appreciate all the help from especially Mark, Ghanshyam and we like to have all support for community for interop continuation. ThanksPrakash On Thursday, June 11, 2020, 06:31:21 AM PDT, Ghanshyam Mann <gmann(a)ghanshyammann.com> wrote: Thanks Prakash for all your effort and energy. I can definitely help with guidelines and their testing part from Tempest point of view or you can count that as help from the community side. My concern is almost the same as Mark, I am involved in multiple areas so if interop requires more time then it might be an issue. As of now, I am ok to help to handle some code side part or as 2nd vice-chair hoping that would not take much bandwidth (i think we do not need 2nd vice-chair things as such :) but no strong opinion ). But the main issue for interop (i mentioned earlier also) is the maintainer for refstack and other repo. We really need some developers for that. -gmann ---- On Wed, 10 Jun 2020 21:07:13 -0500 prakash RAMCHANDRAN <pramchan(a)yahoo.com> wrote ---- > Mark, > OK let me handle it as chair, but let's refer or nominate Ghanshyam too as second vice chair and if needs to vote it lets do that. > I have submitted the change of irc channel to #openstack-interop as tested last week. and try pile all logs therein with startmeeting and endmeeting weekly to debate and arrive at how we proceed on this after tomorrows presentation which I like both of you to attend. > https://review.opendev.org/#/c/735034/1 > If we need anything to merge the above go ahead. > Arkady as usual is with me on Board is there to help us all, so we do have two from Board and two from TC and community. > So let me answer your latest email, and revise the presentation and web link for Board accordingly. > ThanksPrakash > > > > On Friday, June 5, 2020, 12:32:07 PM PDT, Mark Voelker <mvoelker(a)vmware.com> wrote: > > > So let us wait and check with OpenStack staff how they can help us if they can fix the web irc/time links, if not I will try fix it over week end. > Well, that’s sort of the point of having the meeting info housed in public repository: community members actually don’t need to go through the Foundation staff for things like this, they can just fix them with a few lines of text submitted via git! =) > If you’re not sure how to do that, let me know…it’ll only take a moment to submit a patch so I’m happy to help. > At Your Service, > Mark T. Voelker > > > On Jun 5, 2020, at 3:17 PM, prakash RAMCHANDRAN <pramchan(a)yahoo.com> wrote: > Mark, > I see that using irc does help take notes for weekly meetings, especially if there is frequent meetings weekly alternate week etc. > So let us wait and check with OpenStack staff how they can help us if they can fix the web irc/time links, if not I will try fix it over week end. > ThanksPrakash > On Friday, June 5, 2020, 11:49:22 AM PDT, Mark Voelker <mvoelker(a)vmware.com> wrote: > > Prakash, > Quick suggestion: since it looks you’re running these meetings on Zoom going forward, you may want to add the Zoom information to the upstream meetings calendar or alternately at least remove the old IRC meeting entry. See the "IRC meetings schedule” section here for information: > http://eavesdrop.openstack.org/ > The file that you’d want to submit a patch for is: > https://opendev.org/opendev/irc-meetings/src/branch/master/meetings/interop… > (Note that the times presented in the these files are in UTC rather than a local timezone.) > At Your Service, > Mark T. Voelker > > > On Jun 5, 2020, at 11:06 AM, prakash RAMCHANDRAN <pramchan(a)yahoo.com> wrote: > Hi all, > Prakash Ramchandran is inviting you to a scheduled Zoom meeting.To keep reliable zoom link have updated the weekly call to this one and see if you can join inspite of our ongoin PTG at 10 AM PDT. > Join from a browser: https://Dell.zoom.com/wc/join/99829924353 > Password: 101045 > Trying to consolidate what we got from PTG interactions to close the Draft updates. > https://etherpad.opendev.org/p/victoria-ptg-interop-wg > > > Closure in next week for Interop Guidline? > > What is the suggession for Board presentaion from team for Prakash on June 11th? > Anything you like to add on the call, we can keep it short and try close after PTG next week. > ThanksPrakash > > > > > > >

1 1

[release] Release countdown for week R-17, Jun 15 - Jun 19
by Sean McGinnis 12 Jun '20

12 Jun '20

Development Focus ----------------- The victoria-1 milestone is next week, on June 18! Project team plans for the Victoria cycle should now be solidified. General Information ------------------- If you planned to change the release model for any of your deliverables this cycle, please remember to do so ASAP, before milestone-1. Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library which had changes but has not been otherwise released since the Ussuri release. PTL's or release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well, by posting a -1. If we do not hear anything at all by the end of the week, we will assume things are OK to proceed. NB: If one of your libraries is still releasing 0.x versions, start thinking about when it will be appropriate to do a 1.0 version. The version number does signal the state, real or perceived, of the library, so we strongly encourage going to a full major version once things are in a good and usable state. Upcoming Deadlines & Dates -------------------------- Victoria-1 milestone: June 18 Victoria-2 milestone: July 30

1 0

[all][interopWG] Following up on approval of Interop Guidelines for Ussuri
by prakash RAMCHANDRAN 12 Jun '20

12 Jun '20

Hi all, This is a follow up to send feedback to all of core teams (Nova, Neutron, Cinder, Keystone, Glance) + (Swift) + (Add-ons DNS Designate & Orchestration Heat). This was the patch which Mark submitted to kickstart the next refstack test for https://www.openstack.org/brand/openstack-powered/ A. We need to decide on content for "OpenStack Powered DNS" and "OpenStack Powered Orchestration" to this site https://review.opendev.org/#/c/735159/ Community Reporting - Should start seeing program staring 2020.06 new ones and please let us know when you have something to share for Ussuri https://refstack.openstack.org/#/community_results B. We need Marketplace Vendors to validate their OpenStack Powered offers for Ussuri and send emails which we will discuss at tomorrows meeting. C. Meeting will be on irc Friday as usual weekly like #openstack-interopwg @17.00 UTC Friday (PDT 10 AM) Will plan on using zoom call after IRC logins if needed. Agenda we will take as what was discussed at Board and follow ups to close for Usuri and plan further for committee formation for future of interop. ThanksPrakash / Mrak/ GhanshyamFor interopwg

1 0