- openstack-discuss - lists.openstack.org

Etherpad and Gerrit maintenance on 2020-04-10
by corvus＠inaugust.com 09 Apr '20

09 Apr '20

Hi, Tomorrow, April 10, 2020, the OpenDev team will be performing minor updates to two services. * Gerrit restart for https://review.opendev.org/ at 16:00 UTC. This should be a momentary outage to restart the service in a container. We will maintain the same version in the same configuration; this is a preparatory step in order to perform future version upgrades more easily. Other than a short outage of about a minute, there should be no service impact or visible changes, but since the environment is changing, we wanted to announce this in case any problems are detected. * Etherpad migration and domain change at 17:00 UTC. We will migrate the data currently hosted on etherpad.openstack.org to a new server, also running in a container, on etherpad.opendev.org. We will set up redirects so that on completion of the migration, all etherpad.openstack.org URLs will redirect to the same pages on etherpad.opendev.org. https://etherpad.opendev.org/ will become the new canonical service URL. This also includes an upgrade to the latest release of Etherpad Lite (1.8.0). This involves a database migration as well. The service will be unavailable for the duration of this migration (expected to be about 30 minutes). Please report any issues in #opendev on Freenode or to the service-discuss(a)lists.opendev.org mailing list. Note that this message is being sent to service-announce and several other lists. Future announcements of this type will only be sent to service-announce, so please sign up[1] for that list if you haven't already. [1] http://lists.opendev.org/cgi-bin/mailman/listinfo/service-announce -Jim

1 0

[release][oslo] FFE request for Oslo Policy
by Ghanshyam Mann 09 Apr '20

09 Apr '20

Hi, This is regarding the FFE request for policy for - https://review.opendev.org/#/c/717879/ This is part of introducing scope_type and new defaults in policies. During Nova implemtnation[1], we came across two things to solve before we release the new policies changes: 1. A lot of warnings as policy default are changing which end up filling the logs (226 MB n-api logs today). 2. Give operators an option to switch to the new system (scope and new defaults) at the same time without overwriting the policy file. We discussed those two things to solve via oslo_policy[2] which need FFE approval. Sorry for being late on this which should be planned early. Please let me know if it is ok to include these changes in the Ussuri release. [1] https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:ope… [2] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.… -gmann

4 5

[kolla] Kolla Klub first meeting tomorrow
by Mark Goddard 09 Apr '20

09 Apr '20

Hi Kollaborators, Just a reminder that we will meet tomorrow at 15:00 UTC. Join here: https://meet.google.com/hph-pynx-vsy I have created a Google doc for the meeting agenda and notes: https://docs.google.com/document/d/1EwQs2GXF-EvJZamEx9vQAOSDB5tCjsDCJyHQN5_…. See you tomorrow, Mark

1 1

[neutron] Drivers meeting - 10.04.2020
by Slawek Kaplonski 09 Apr '20

09 Apr '20

Hi, I will be on PTO on Good Friday so lets cancel our drivers meeting at that day. See You all on drivers meeting next week. And have a great holidays :) — Slawek Kaplonski Senior software engineer Red Hat

1 0

[tc][election] Simple question for the TC candidates
by Jean-Philippe Evrard 09 Apr '20

09 Apr '20

Hello, I read your nominations, and as usual I will ask what do you _technically_ will do during your mandate, what do you _actively_ want to change in OpenStack? This can be a change in governance, in the projects, in the current structure... it can be really anything. I am just hoping to see practical OpenStack-wide changes here. It doesn't need to be a fully refined idea, but something that can be worked upon. Thanks for your time. Regards, Jean-Philippe Evrard

12 26

[manila][release] Ussuri release preparation
by Goutham Pacha Ravi 09 Apr '20

09 Apr '20

Hi Stackers, (Following gibi's lead here on relaying release status to the ML) We're at feature freeze, and I'm providing the current state of Ussuri release deliverables from the manila team: openstack/python-manilaclient is waiting on a couple of changes: - Release patch: https://review.opendev.org/#/c/718254/ - Pending changes: bp/create-share-from-snapshot-in-another-pool-or-backend: - https://review.opendev.org/#/c/712543/ bp/graduate-share-groups-feature - https://review.opendev.org/#/c/708282/ openstack/manila-ui has a few open bug-fixes, we'll target a release in the next week or so: - https://review.opendev.org/#/q/topic:bug/1823078 openstack/manila has the following pending changes concerning Feature Freeze - bp/create-share-from-snapshot-in-another-pool-or-backend: - https://review.opendev.org/#/c/709697/ (Manila server side changes) - https://review.opendev.org/#/c/711611/ (ZFSOnLinux implementation) - https://review.opendev.org/#/c/712642/ (NetApp driver implementation) - bp/graduate-share-groups-feature - https://review.opendev.org/#/c/706959/ Ussuri Release goals status: - Drop Python 2.7 Support - Complete - Project Specific PTL and Contributor Documentation - In-Progress Thanks, Goutham

1 0

[StoryBoard][Security] The process to report a security bug
by Lingxian Kong 09 Apr '20

09 Apr '20

As most of the projects have migrated to storyboard for bug tracking, after reading https://security.openstack.org/vmt-process.html, I have two questions: 1. I didn't find openstack/ossa or ossa project exists in storyboard. 2. I didn't find a place in storyboard to attach a patch. Am I missing something? - Best regards, Lingxian Kong Catalyst Cloud

2 3

[all] Please remove all external resources from docs
by Thomas Goirand 09 Apr '20

09 Apr '20

Hi, I've wrote about this earlier I guess, but I believe I need to do it once more. Often I see in the docs things like this: .. image:: https://governance.openstack.org/tc/badges/<FOO>.svg :target: https://governance.openstack.org/tc/reference/tags/index.html [note: this is only one simple example, there's many of other types linking to external images, I've even seen stuff linking to CDNs...] I'd like to see these go away. Indeed, distributions like mine (ie: Debian) are packaging the doc. And it's *very* annoying when one browses the doc to have such an external link, and the browser going on the internet to fetch an external resource. So, in Debian, I'm patching these away. Often, the most ugly way where I don't care about the resulting document (as long as the doc is there). This is both annoying, and a loss of my time. The solution is simple: have the resource being *LOCAL* (ie: stored in the project's doc), not stored on an external site. Thanks to anyone who will follow this advice. Cheers, Thomas Goirand (zigo)

7 9

[nova] Ussuri release preparation
by Balázs Gibizer 09 Apr '20

09 Apr '20

Hi, Today is Feature Freeze for Ussuri and the final release of novaclient for Ussuri. Release TODOs are tracked in [1]. Any feature code in nova that is approved before end of today is OK to be rechecked or rebased if needed after the freeze. Features that are close to land but haven't approved until the freeze, needs a Feature Freeze Exception on the ML or they will be postponed to the Victoria cycle. When you request such FFE please try to find cores who support your request. Bug fixes, test coverage and documentation enhancements are still OK to be proposed after the freeze. However please be careful approving risky patches. Any release blocker issue should have a bug tagged with ussuri-rc-potential in launchpad. Please also add them the the etherpad [1] Cheers, gibi [1] https://etherpad.openstack.org/p/nova-ussuri-rc-potential

1 0

Re: [Release-job-failures] release-post job for openstack/releases for ref refs/heads/master failed
by Sean McGinnis 08 Apr '20

08 Apr '20

On 4/8/20 4:53 PM, zuul(a)openstack.org wrote: > Build failed. > > - tag-releases https://zuul.opendev.org/t/openstack/build/28b78b5235894878b4cb92822b95bbff : FAILURE in 5m 53s > - publish-tox-docs-releases https://zuul.opendev.org/t/openstack/build/None : SKIPPED This failure was due to a new operation we added to the branching process. Once working, the new code will propose patches to branched repos to update them to use the job template defined for the next release cycle, similar to how the patches are proposed to update reno. I think this was due to an error in a sed command that is used to perform that update, and will hopefully be fixed after https://review.opendev.org/718564 merges. No further action is needed here. The only thing missed was the publishing of the releases docs, but that will be corrected with the next release patch that goes through. Sean

1 0

[all][PTL][release] Call for Ussuri Cycle Highlights
by Kendall Nelson 08 Apr '20

08 Apr '20

Hello Everyone! Its time to start thinking about calling out 'cycle-highlights' in your deliverables! As PTLs, you probably get many pings towards the end of every release cycle by various parties (marketing, management, journalists, etc) asking for highlights of what is new and what significant changes are coming in the new release. By putting them all in the same place it makes them easy to reference because they get compiled into a pretty website like this from the last few releases: Rocky[1], Stein[2], Train[3]. We don't need a fully fledged marketing message, just a few highlights (3-4 ideally), from each project team. Looking through your release notes might be a good place to start. *The deadline for cycle highlights is the end of the R-5 week [4] on April 10th.* How To Reminder: ------------------------- Simply add them to the deliverables/train/$PROJECT.yaml in the openstack/releases repo like this: cycle-highlights: - Introduced new service to use unused host to mine bitcoin. The formatting options for this tag are the same as what you are probably used to with Reno release notes. Also, you can check on the formatting of the output by either running locally: tox -e docs And then checking the resulting doc/build/html/train/highlights.html file or the output of the build-openstack-sphinx-docs job under html/train/ highlights.html. Can't wait to see you all have accomplished this release! Thanks :) -Kendall Nelson (diablo_rojo) [1] https://releases.openstack.org/rocky/highlights.html [2] https://releases.openstack.org/stein/highlights.html [3] https://releases.openstack.org/train/highlights.html [4] htt <https://releases.openstack.org/train/schedule.html#t-cycle-highlights> https://releases.openstack.org/ussuri/schedule.html

2 5

No UC meeting this week
by Mohamed Elsakhawy 08 Apr '20

08 Apr '20

Hi All, There will be no UC meeting tomorrow. Our next meeting is on Thursday April 16th in our regular time. Thanks Mohamed

1 0

[all] Gate status: tempest-full broken on stein
by Ghanshyam Mann 08 Apr '20

08 Apr '20

Hello Everyone, tempest-full (py2 job) started failing on stable/stein gate because devstack try to install master Tempest on system-wide and fail for min require py version by Tempest. We did not set the INSTALL_TEMPEST flag to false for stable branches since stable/pike. I am going to add this as one of thing to do while cutting devstack stable branch. More details on Bug: https://bugs.launchpad.net/tempest/+bug/1871327 Here are the fixes, I am backporting from stable/train: Please hold the recheck until they are merged. https://review.opendev.org/#/q/I60949fb735c82959fb2cfcb6aeef9e33fb0445b6 -gmann

1 2

[tc][oslo] Looking for a Victoria Oslo PTL volunteer
by Thierry Carrez 08 Apr '20

08 Apr '20

Hello everyone, Nobody stepped up yet to continue the great work of Ben Nemec as PTL of the Oslo project team. Oslo handles common code between our various projects, and is key to reduce duplication of code and waste of effort. Oslo is very critical for OpenStack, as all other projects depend on its libraries, but can be relatively low-maintenance as most libraries are feature-complete. Being the Oslo PTL gives you a great horizontal perspective on OpenStack, so they are a great opportunity for smaller organizations that depend on OpenStack to keep track of what's happening and contribute back, without having to specialize in one of the larger projects. I suspect Ben can help answer any question on the workload it represents to be the Oslo PTL. Getting a new volunteer for Oslo PTL is our preferred solution. In case the PTL position is just too intimidating and nobody volunteers, the TC is considering experimenting with a PTL-less form of governance that would involve only designating two liaisons (a release liaison(s) and a security liaison(s)). That is the minimal accountability that we require of an openstack project team (someone(s) signing off releases, and someone(s) to contact in case of embargoed vulnerabilities). I say "someone(s)" as ideally multiple people sign up to be a liaison. In that form of governance, if there is any conflict in the team, the TC can ultimately arbitrate the conflict, instead of the PTL. That would be our plan B. So please let us know if you'd be interested in the Oslo PTL position, or if you'd be OK just for filling the duties of a specific liaison. Thanks for considering it! -- Thierry Carrez (ttx)

3 3

[tripleo] older packages in promoted repos
by Wesley Hayutin 08 Apr '20

08 Apr '20

Greetings, Please hold off any major changes in TripleO for 24 - 48 hours. As discussed in the #tripleo meeting this morning, old rpms from December 2019 have found their way into promoted RDO yum repos for CentOS-8 master [1]. The CI team and RDO team working together to resolve the issue. This is causing some jobs to fail, especially 3rd party jobs at the moment like featureset001. [2,3] We are working through each component yum repo to ensure the latest content is available and will have to repromote content to the upstream. Sorry for the delay and the bugs this is causing in getting your patches validated. [1] https://review.rdoproject.org/r/#/c/26294/ [2] https://bugs.launchpad.net/tripleo/+bug/1871010 [3] https://bugs.launchpad.net/tripleo/+bug/1871181

1 1

[largescale-sig] Next meeting: Apr 8, 8utc
by Thierry Carrez 08 Apr '20

08 Apr '20

Hi everyone, The Large Scale SIG will have a meeting this week on Wednesday, April 8 at 8 UTC[1] in #openstack-meeting on IRC. The meeting time was changed at the last meeting to be more friendly to our Asian participants, so please doublecheck how that translates for you at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20200408T08 Feel free to add topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting A reminder of the TODOs we had from last meeting, in case you have time to make progress on them: - ttx to push for oslo.metric spec approval - oneswig to contribute a scaling story on bare metal cluster scaling - amorin to create a wiki page for large scale documentation - amorin to propose patch against Nova doc Talk to you all on Wednesday, -- Thierry Carrez

1 1

[ironic][release] List cycle-with-intermediary deliverables that have not been released yet
by Herve Beraud 08 Apr '20

08 Apr '20

Hello ironic team, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Ussuri cycle: - bifrost - ironic-prometheus-exporter - ironic-ui Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release. Cheers, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

6 10

[stackalytics] x/stackalytics repo still used?
by Andreas Jaeger 08 Apr '20

08 Apr '20

Hi Sergey and stackalytics experts, the wiki at https://wiki.openstack.org/wiki/Stackalytics#Company_affiliation points to using the github site for stackalytics - but I see that there are still submissions to the opendev repo at https://review.opendev.org/#/q/project:x/stackalytics so, how are those repos used? Is it time to retire the x/stackalytics repository so that nobody can submit there? Andreas -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB

2 1

[nova][gate] status of some gate bugs
by melanie witt 08 Apr '20

08 Apr '20

Hey all, We've been having a tough time lately in the gate hitting various bugs while our patches go through CI. I just wanted to mention a few of them that I've seen often in my gerrit notifications and give a brief status on fix efforts. * http://status.openstack.org/elastic-recheck/#1813789 This one is where the nova-live-migration job fails a server evacuate test with: "Timeout waiting for [('network-vif-plugged', 'e3d3db3f-bce4-4889-b161-4b73648f79be')] for instance with vm_state error and task_state rebuild_spawning.: eventlet.timeout.Timeout: 300 seconds" in the screen-n-cpu.txt log. lyarwood has a WIP patch here: https://review.opendev.org/713674 and sean-k-mooney has a WIP patch here: https://review.opendev.org/713342 * https://launchpad.net/bugs/1867380 This one is where the nova-live-migration or nova-grenade-multinode job fail due to n-cpu restarting slowly after being reconfigured for ceph. The server will fail to build and it's because the test begins before nova-compute has fully come up and we see this error: "Instance spawn was interrupted before instance_claim, setting instance to ERROR state {{(pid=3783) _error_out_instances_whose_build_was_interrupted" in the screen-n-cpu.txt log. lyarwood has a patch approved here that we've been rechecking the heck out of that has yet to merge: https://review.opendev.org/713035 * https://launchpad.net/bugs/1844568 This one is where a job fails with: "Body: b'{"conflictingRequest": {"code": 409, "message": "Multiple possible networks found, use a Network ID to be more specific."}}'" gmann has a patch proposed to fix some of these here: https://review.opendev.org/711049 There might be more test classes that need create_default_network = True. * http://status.openstack.org/elastic-recheck/#1844929 This one is where a job fails and the following error is seen one of the logs, usually screen-n-sch.txt: "Timed out waiting for response from cell 8acfb79b-2e40-4e1c-bc3d-d404dac6db90". The TL;DR on this one is there's no immediate clue why it's happening. This bug used to hit more occasionally on "slow" nodes like nodes from the OVH or INAP providers (and OVH restricts disk iops [1]). Now, it seems like it's hitting much more often (still mostly on OVH nodes). I've been looking at it for about a week now and I've been using a DNM patch to add debug logging, look at dstat --disk-wait output, try mysqld my.cnf settings, etc: https://review.opendev.org/701478 So far, what I find is that when we get into the fail state, we get no rows back from the database server when we query for nova 'services' and 'compute_nodes' records, and we fail with the "Timed out waiting for response" error. Haven't figured out why yet, so far. The disk wait doesn't look high when this happens (or at any time during a run) so it's not seeming like it's related to disk IO. I'm continuing to look into it. Cheers, -melanie [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-November/010505…

5 8

[all][elections][tc] TC Voting Kickoff
by Kendall Nelson 07 Apr '20

07 Apr '20

Hello All, The poll for the TC Election is now open and will remain open until Apr 14, 2020 23:45 UTC. We are selecting 5 TC members, please rank all candidates in your order of preference. You are eligible to vote if you are a Foundation individual member[1] that also has committed to one of the official project teams' deliverable repositories[2] over the Mar 22, 2019 00:00 UTC - Apr 07, 2020 00:00 UTC timeframe (Train to Ussuri) or if you are one of the extra-atcs.[3] What to do if you don't see the email and have a commit in at least one of the official deliverables[2]: * check the trash or spam folder of your gerrit Preferred Email address[4], in case it went into trash or spam * wait a bit and check again, in case your email server is a bit slow * find the sha of at least one commit from an official deliverable repo[2] and email the election officials[1]. If we can confirm that you are entitled to vote, we will add you to the voters list and you will be emailed a ballot. Our democratic process is important to the health of OpenStack, please exercise your right to vote. Candidate statements/platforms can be found linked to Candidate names[6]. Happy voting! Thank you, -Kendall Nelson & the Election Officials [1] https://www.openstack.org/community/members/ [2] https://opendev.org/openstack/governance/raw/tag/0.5.0/reference/projects.y… [3] Look for the extra-atcs element in [2] [4] Sign into review.openstack.org: Go to Settings > Contact Information. Look at the email listed as your preferred email. That is where the ballot has been sent. [5] https://governance.openstack.org/election/#election-officials [6] https://governance.openstack.org/election/#victoria-tc-candidates

1 0

Inline comments from Zuul
by Monty Taylor 07 Apr '20

07 Apr '20

Hey everybody, Yesterday mnaser finished up a long-standing TODO list item we had of leveraging Zuul’s ability to leave inline comments on changes by parsing out things like linter output and dropping them on changes. This is now live. We’ve run in to a few gotchas (turns out there’s a lot of people doing a lot of different things) - all of which we’ve either fixed or have fixes in flight for. Notably there is a usage pattern of running pylint but only partially caring about the results, which turns inline comments from pylint output into complete noise. We’ve turned off the inline comments in openstack-tox-pylint: https://review.opendev.org/#/c/716599/ https://review.opendev.org/#/c/716600/ although if your project uses it and would like inline comments from it, they can be re-enabled in your project. Similarly the same flag can be used to disable inline comments if your project decides they don't want them for some reason. Work is under way to add parsing for Sphinx output and golangci-lint output. If anybody runs in to any issues - like the results are too noisy or something is breaking where it shouldn’t, please let us know and we’ll get on it as quickly as possible. Thanks! Monty

4 3

[k8s][zun] Introduce a new feature in Ussuri - CRI integration
by Hongbin Lu 07 Apr '20

07 Apr '20

Hi all, As we are approaching the end of Ussuri cycle, I would like to take a chance to introduce a new feature the Zun team implemented in this cycle - CRI integration [1]. As known by people, Zun is an OpenStack Container service. It provides API for users to create and manage application containers in an OpenStack cloud. The main concepts in Zun are "Container" and "Capsule". A container is a single container, while a capsule is a group of co-located and co-scheduled containers (basically the same as k8s pod). Probably, the "Container" concept is more widely used. People can use the /containers API endpoint to create and manage a single container. Under the hook, a container is a Docker container in a compute node. What is special is that each Docker container is given a Neutron port so the container is connected to a tenant network in Neutron. Kuryr-libnetwork is the Docker network plugin we use to perform the Neutron port binding which basically connects the container to the virtual switch managed by Neutron. As mentioned before, the concept of "Capsule" in Zun is basically the same as pod in k8s. We introduced this concept mainly for k8s integration. Roughly speaking, the Zun-k8s integration is achieved by (i) registering a special node in k8s, (ii) watching the k8s API for pods being scheduled to this node and (iii) invoking Zun's /capsules API endpoint to create a capsule for each incoming pod. The (i) and (ii) is done by a CNCF sandbox project called Virtual Kubelet [2]. The (iii) is achieved by providing an OpenStack provider [3] for Virtual Kubelet. The special node registered by Virtual Kubelet is called a virtual node because the node doesn't physically exist. Pods being scheduled to the virtual node is basically offloaded from the current k8s cluster, eventually landed on an external platform such as an OpenStack cloud. In high level, what is offered to end-users is a "serverless kubernetes pod" [4]. This term basically means the ability to run pods on demand without planing the capacity (i.e. nodes) upfront. An example of that is AWS EKS on Fargate [5]. In comparison, the traditional approach is to create an entire k8s cluster upfront in order to run the workload. Let's give a simple example. Suppose you want to run a pod, the traditional approach is to provision a k8s cluster with a worker node. Then, run the pod on the worker node. In contract, the "serverless" approach is to create a k8s cluster without any worker node and the pod is offloaded to a cloud provider that provisions the pods at runtime. This approach works well for applications who have fluctuated workloads so it is hard to provision a cluster with the right size for them. Furthermore, from cloud provider's perspective, if all tenant users offloads their pods to the cloud, the cloud provider might be able to pack the workload better (i.e. with fewer physical nodes) thus saving cost. Under the hook, a capsule is a podsandbox with one or more containers in a CRI runtime (i.e. containerd). Compared to Docker, a CRI runtime has a better support for the pod concept so we chose it to implement capsule. A caveat is that CRI requires a CNI plugin for the networking, so we need to implement a CNI plugin for Zun (called zun-cni). The role of CNI plugin is similar as kuryr-libnetwork that we are using for Docker except it implements a different networking model (CNI). I summaries it as below: +--------------+------------------------+---------------+ | Concept | Container | Capsule (Pod) | +--------------+------------------------+---------------+ | API endpoint | /containers | /capsules | | Engine | Docker | CRI runtime | | Network | kuryr-libnetwork (CNM) | zun-cni (CNI) | +--------------+------------------------+---------------+ Typically, a CRI runtime works well with Kata Container which provides hypervisor-based isolation for neighboring containers in the same node. As a result, it is secure to consolidate pods from different tenants into a single node which increases the resource utilization. For deployment, a typical stack looks like below: +----------------------------------------------+ | k8s control plane | +----------------------------------------------+ | Virtual Kubelet (OpenStack provider) | +----------------------------------------------+ | OpenStack control plane (Zun, Neutron, etc.) | +----------------------------------------------+ | OpenStack data plane | | (Zun compute agent, Neutron OVS agent, etc.) | +----------------------------------------------+ | Containerd (with CRI plugin) | +----------------------------------------------+ | Kata Container | +----------------------------------------------+ In this stack, if a user creates a deployment or pod in k8s, the k8s scheduler will schedule the pod to the virtual node registered by Virtual Kubelet. Virtual Kubelet will pick up the pod and let the configured cloud provider to handle it. The cloud provider invokes Zun API to create a capsule. Upon receiving the API request to create a capsule, Zun scheduler will schedule the capsule to a compute node. The Zun compute agent in that node will provision the capsule using a CRI runtime (containerd in this example). The Zun-CRI runtime communication is done via a gRPC protocol through a unix socket. The CRI runtime will first create the pod in Kata Container (or runc as an alternative) that realizes the pod using a lightweight VM. Furthermore, the CRI runtime will use a CNI plugin, which is the zun-cni binary, to setup the network. The zun-cni binary is a thin executable that dispatches the CNI command to a daemon service called zun-cni-daemon. The community is via HTTP within localhost. The zun-cni-daemon will look up the Neutron port information from DB and perform the port binding. In conclusion, starting from Ussuri, Zun adds support for CRI-compatible runtime. Zun uses CRI runtime to realize the concept of pod. Using this feature together with Virtual Kubelet and Kata Container, we can offer "serverless kubernetes pod" service which is comparable with AWS EKS with Fargate. [1] https://blueprints.launchpad.net/zun/+spec/add-support-cri-runtime <https://github.com/virtual-kubelet/openstack-zun> [2] https://github.com/virtual-kubelet/virtual-kubelet [3] https://github.com/virtual-kubelet/openstack-zun [4] https://aws.amazon.com/about-aws/whats-new/2019/12/run-serverless-kubernete… [5] https://aws.amazon.com/blogs/aws/amazon-eks-on-aws-fargate-now-generally-av…

3 8

[tc][election] campaign discussion: what we can improve in TC & how?
by Ghanshyam Mann 07 Apr '20

07 Apr '20

As we are in the campaigning phase of the TC election, where we start the debate on few topics. This is one of the topics where I would like to start the debate. First off, I'd like to thank all the candidates for showing interest to be part of or continuing as TC. What you think we should and must improve in TC ? This can be the involvement of TC in the process from the governance point of view or technical help for each project. Few of the question is below but feel free to add your improvement points. - Do we have too much restriction on project sides and not giving them a free hand? If yes, what we can improve and how? - Is there less interaction from TC with projects? I am sure few projects/members even do not know even what TC is for? What's your idea to solve this. -gmann

7 9

Re: [release-announce] pbr 5.4.5
by Thomas Goirand 07 Apr '20

07 Apr '20

On 4/7/20 12:16 PM, no-reply(a)openstack.org wrote: > We are overjoyed to announce the release of: > > pbr 5.4.5: Python Build Reasonableness > > [ ... ] > > Changes in pbr 5.4.4..5.4.5 > --------------------------- > > b821df5 Switch to Ussuri jobs > > > Diffstat (except docs and test files) > ------------------------------------- > > .zuul.yaml | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) I wonder, what's the point of such a micro release? I'm sure I'm missing something... Cheers, Thomas Goirand (zigo)

3 2

[all][TC][PTL][election] Nominations Close & Campaigning Begins
by Kendall Nelson 07 Apr '20

07 Apr '20

The PTL and TC Nomination periods are now over. The official candidate lists are available on the election website[0][1]. --PTL Election Details-- There are 16 projects without candidates, so according to this resolution[2], the TC will have to decide how the following projects will proceed: Adjutant Barbican Cloudkitty Congress I18n Infrastructure Loci Masakari Oslo Packaging_Rpm Placement Rally Swift Tacker Tricircle Zaqar There are no projects with more than one candidate so we won't need to hold any runoffs! Congratulations to our new and returning PTLs! [0] --TC Election Details-- The official candidate list is available on the election website[1]. There are will be a TC election following the campaigning period that has now begun and runs till Apr 07, 2020 23:45 UTC when the polling will begin. You are encouraged to ask questions to the candidates on the ML to help inform your decisions when polling begins. Thank you, -Kendall (diablo_rojo) & the Election Officials [0] https://governance.openstack.org/election/#victoria-ptl-candidates [1] https://governance.openstack.org/election/#victoria-tc-candidates [2] https://governance.openstack.org/resolutions/20141128-elections-process-for…

8 10

[all][Virtual PTG] Notes from the 'Running Virtual Meetups' session
by Artom Lifshitz 07 Apr '20

07 Apr '20

Hey all, Last week, Red Hat hosted a 'Running Virtual Meetups' virtual session, with presenters from both Red Hat and others in the industry. I attended, hoping to gleam potentially interesting insights into how we can run our virtual PTG. Here are my notes: In real PTG, the physical and geographical aspects of it make it much easier to separate from our usual work. The usual calls, tickets, emails, whatever, take a back seat due to the constraints of a PTG setting. In a virtual PTG, with us sitting at our usual desks, this will become much harder. This leads into the next point - participant engagement. Having technical conversations for 8 hours a day is already hard enough when you're in the same room as the people you're conversing with. When those people are pixels on your screen, it becomes even harder. The session I attended was geared more towards presentations than PTG-style roundtable discussion, so I'm not sure that the proposed mitigations would apply to us. For instance, live polls make no sense in a PTG context. One interesting suggestion was to do physical movement between topics/sessions. The online attention span of a human is estimated to be around 10-15 minutes, so having participants stand up and walk around their desk/kitchen/hallway 4 times an hour could be something worth trying. Another way to keep folks engaged is to actually do things besides talking. In our context, this could mean hacking on some POC code together, or collaboratively writing a spec. Again, the session I attended was geared more towards presentations, so the suggestion was to do live debugging. It's actually more engaging when things break and you fix them as a group, than when a presentation goes off without a hitch. That was about it. There was also a list of potentially useful tools, that I'll present here as a link dump because I've never used any of them: https://www.mentimeter.com/ https://pollev.com/ http://roll20.net/ https://obsproject.com/ https://www.sli.do/ The danger is that too much tech brings complexity that's difficult to manage, so sticking to simple well-known tools can also be an advantage. Hope this is useful, cheers!

1 0

[Watcher]about IRC meeting on April 8
by licanwei 07 Apr '20

07 Apr '20

Hi, We will have the team meeting tomorrow at 08:00 UTC on #openstack-meeting-alt. pls update the meeting agenda if you have something want to be discussed. thanks licanwei | | licanwei_cn | | 邮箱：licanwei_cn(a)163.com | 签名由网易邮箱大师定制

1 0

[neutron][OVN] Multiple mechanism drivers
by Sam Morrison 07 Apr '20

07 Apr '20

We are looking at using OVN and are having some issues with it in our ML2 environment. We currently have 2 mechanism drivers in use: linuxbridge and midonet and these work well (midonet is the default tenant network driver for when users create a network) Adding OVN as a third mechanism driver causes the linuxbridge and midonet networks to stop working in terms of CRUD operations etc. It looks as if the OVN driver thinks it’s the only player and is trying to do things on ports that are in linuxbridge or midonet networks. Am I missing something here? (We’re using Stein version) Thanks, Sam

5 6

[baremetal-sig][ironic] Baremetal whitepaper round 2: doodle
by Arne Wiebalck 07 Apr '20

07 Apr '20

Dear all, After the first very productive sessions on finishing the baremetal whitepaper (thanks to everyone contributing and reviewing afterwards!), we would like to keep the momentum and schedule a second round. I've set up a doodle here [0], and we will send out the call details once we have settled on the time slot(s). If you'd like to participate, please make sure you reply to the doodle before the end of this week. Thanks! Arne [0] https://doodle.com/poll/kyd5vvgmg68vxduv

1 0

[openstack-discuss] [puppet] Nominating Takashi Kajinami for core of the Puppet OpenStack modules
by Shengping Zhong 07 Apr '20

07 Apr '20

Hey Puppet Cores, I would like to nominate Takashi Kajinami as a Core reviewer for the Puppet OpenStack modules. He is an excellent contributor to our modules over the last several cycles. His stats for the last 90 days can be viewed here[0]. Please response with your +1 or any objections. If there are no objections by April 6 I will add him to the core list. As there were no objections, I have added Takashi to the core list. Keep up the good work. Thanks, Shengping. [0] https://www.stackalytics.com/report/contribution/puppet%20openstack-group/90

5 4

[tripleo] old tripleo bugs
by Wesley Hayutin 06 Apr '20

06 Apr '20

Sorry, This time w/ the right filter.. Greetings, As discussed launchpad bugs that are in new or triaged status and were opened over 365 days ago have been moved to incomplete status. The list is here [1] and 286 bugs were moved to incomplete. The subscribed users or reporters can set the bug back to triaged or new, if you need help ping me. Instead of leaving these bugs open forever, it's now up to the owner to flip the status back to something we'll track. We've been kicking hundreds of bugs down each release and that's just silly. Launchpad will expire and close the bugs in 60 days if they are not updated [2]. One note.. there were only 5 bugs in New and opened over 365 days. Thanks all! [1] http://paste.openstack.org/show/791712/ [2] https://help.launchpad.net/BugExpiry

1 0

old tripleo bugs
by Wesley Hayutin 06 Apr '20

06 Apr '20

Greetings, As discussed launchpad bugs that are in new or triaged status and were opened over 365 days ago have been moved to incomplete status. The list is here [1] and 286 bugs were moved to incomplete. The subscribed users or reporters can set the bug back to triaged or new, if you need help ping me. Instead of leaving these bugs open forever, it's now up to the owner to flip the status back to something we'll track. We've been kicking hundreds of bugs down each release and that's just silly. Launchpad will expire and close the bugs in 60 days if they are not updated [2]. One note.. there were only 5 bugs in New and opened over 365 days. Thanks all! [1] http://paste.openstack.org/show/791712/ [2] https://help.launchpad.net/BugExpiry

1 0

choosing object storage
by Tessa Plum 06 Apr '20

06 Apr '20

greetings, What object storage system to choose for integration with openstack environment? ceph or swift? Thank you.

5 5

[neutron][OVN] Issues trying to migrated to OVN using db sync util
by Sam Morrison 06 Apr '20

06 Apr '20

Hi Neutron/OVN devs/ops, We are in the process of migrating to OVN, we are having issues getting all our neutron data into OVN using neutron-ovn-db-sync-util tool Our neutron has: ~250 networks/subnets ~11,000 ports ~53,000 security groups ~200,000 security group rules The issues we have: We get a lot of timeouts with ovsdb transaction so we have made it commit transactions every 50 items. It takes ages to run, we haven’t got a full sync to happen but it has run for over 1.5 hours before we get an error. The main issue is we are getting this error [1] about dictionary changing which is preventing us from completing a full sync. I’m wondering if there are any sites out there running with this size of secgroups/ports etc. We have dedicated hardware for the ovsdb servers etc. so I don’t think it’s something we can chuck more hardware at We are running stein version and wondering if there has been any work in making this better in train or newer? Thanks in advance for any help you can provide us. Cheers, Sam [1] https://bugs.launchpad.net/networking-ovn/+bug/1871272

1 0

[qa] Proposing Martin Kopec to Tempest core
by Ghanshyam Mann 06 Apr '20

06 Apr '20

Hello Everyone, Martin Kopec (IRC: kopecmartin) has been doing great contribution in Tempest since a long time. He has been doing bugs Triage also in Ussuri cycle and has good understanding of Tempest. I would like to propose him for Tempest Core. You can vote/feedback on this email. If no objection by the end of this week, I will add him to the list. -gmann

9 9

New OpenDev Communication Channels
by Clark Boylan 06 Apr '20

06 Apr '20

Hello All, Recently, we've transitioned to using #opendev on Freenode for our synchronous IRC communications. Since then we've spun up a new service-discuss(a)lists.opendev.org mailing list [1] where we'll plan changes to services, notify of meetings, answer questions about services and usage, and otherwise communicate about OpenDev. service-announce(a)lists.opendev.org [2] will remain for important announcements. If you're interested in the developer infrastructure we run please join us on these mailing lists. We encourage every developer to at least subscribe to the service-announce[2] list. It will be very low traffic, and used only for important announcements with wide impact. We are also going to start having our weekly team meeting in #opendev-meeting. The time will continue to be 19:00 UTC Tuesdays. See you there, Clark [1] http://lists.opendev.org/cgi-bin/mailman/listinfo/service-discuss [2] http://lists.opendev.org/cgi-bin/mailman/listinfo/service-announce

2 2

[all] OSF Community Meeting Presentation & Recordings
by Allison Price 06 Apr '20

06 Apr '20

Hi everyone, Thank you to those who attended any of the community meetings last week! If you missed one of the calls last week, below are links to the presentation [1], recording in English [2], and recording in Mandarin [3]. A lot of links were discussed and you can find those in the meeting section of the notes as well as the chat from the recordings. We are planning to do this format with project and community updates and OSF event updates quarterly. Stay tuned for the next meeting, and let me know if you have any questions in the meantime. In addition to the quarterly meetings, we would like to hear from the project communities on topics you would like to cover in community meetings or have covered. If you have an idea you would like to share, please drop it in this etherpad [4]. If you see a topic already shared that you would like to collaborate on, please share your name, email and IRC nick next to the topic. Cheers, Allison [1] https://docs.google.com/presentation/d/1l05skj_BCfF8fgYWu4n0b1rQmbNhHp8sMeY… <https://docs.google.com/presentation/d/1l05skj_BCfF8fgYWu4n0b1rQmbNhHp8sMeY…> [2] https://zoom.us/rec/share/7vVXdIvopzxIYbPztF7SVpAKXYnbX6a82iMaqfZfmEl1b0Fqb… <https://zoom.us/rec/share/7vVXdIvopzxIYbPztF7SVpAKXYnbX6a82iMaqfZfmEl1b0Fqb…> [3] https://zoom.us/rec/share/zudNaIrQ6mNLR9Lvr2Xxf5QQIL7geaa8hCcf_vsIxEwoHkn0b… <https://zoom.us/rec/share/zudNaIrQ6mNLR9Lvr2Xxf5QQIL7geaa8hCcf_vsIxEwoHkn0b…> [4] https://etherpad.openstack.org/p/OSF_Community_Meetings <https://etherpad.openstack.org/p/OSF_Community_Meetings> Allison Price OpenStack Foundation allison(a)openstack.org

1 0

[release][oslo] FFE request for Oslo
by Ben Nemec 06 Apr '20

06 Apr '20

Like, all of it. :-) Okay, _most_ of it. Specifically the projects in https://review.opendev.org/#/c/717816/ These all had changes in them which normally don't require release, like doc and test changes. However, if we don't release them before the stable branches are cut, the stable branches won't include any of those doc and test changes. This means the docs will be out of date, and tests may break completely (it would not be the first time). We could backport, but there are kind of a lot of patches involved so it would be much easier to just do some trivial releases now and not have to mess with it later. Apologies for dropping the ball on this since it should have been proposed last week, but I hope you will take pity on me and grant an FFE to undo my mistake. :-) Thanks. -Ben

2 1

[neutron] Bug deputy report for week of March 30th
by Brian Haley 06 Apr '20

06 Apr '20

Hi, I was Neutron bug deputy last week. Below is a short summary about reported bugs. -Brian Critical bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1869862 - neutron-tempest-plugin-designate-scenario failes frequently with imageservice doesn't have supported version - https://review.opendev.org/#/c/715835/ merged (devstack issue) * https://bugs.launchpad.net/neutron/+bug/1870110 - neutron-rally-task fails in rally_openstack.task.scenarios.neutron.trunk.CreateAndListTrunks - https://review.opendev.org/#/c/716562/ proposed - revert of https://review.opendev.org/#/c/477286/ * https://bugs.launchpad.net/neutron/+bug/1870302 - [VPNaaS]: test_migrations_sync failed with alembic 1.4.2 - gate failure for vpnaas - Dongcan Ye took ownership High bugs --------- * https://bugs.launchpad.net/neutron/+bug/1869887 - L3 DVR ARP population gets incorrect MAC address in some cases - https://review.opendev.org/#/c/716302/ proposed * https://bugs.launchpad.net/neutron/+bug/1870313 - "send_ip_addr_adv_notif" can't use eventlet when called from "keepalived_state_change" - https://review.opendev.org/#/c/716944/ proposed * https://bugs.launchpad.net/neutron/+bug/1870352 - "ctypes.CDLL" C functions could release the GIL during the execution call - https://review.opendev.org/#/c/717017/ proposed * https://bugs.launchpad.net/neutron/+bug/1870569 - Unable to create network without default network_segment_range - Possible regression - https://review.opendev.org/#/c/717754/ proposed Medium bugs ----------- * https://bugs.launchpad.net/neutron/+bug/1870114 - Trunk subports aren't treated as dvr serviced ports - https://review.opendev.org/#/c/716642/ proposed * https://bugs.launchpad.net/neutron/+bug/1870228 - cloud-init metadata fallback broken - https://review.opendev.org/#/c/600421/ changed the bind address - asked if using the metadata "force" config option will help * https://bugs.launchpad.net/bugs/1870296 - [neutron-tempest-plugin]:fwaas Operation cannot be performed since associated firewall group is in PENDING UPDATE - https://review.opendev.org/716891 proposed * https://bugs.launchpad.net/neutron/+bug/1870400 - "ml2_vlan_allocations.vlan_id" value should be checked in the DB backend - https://review.opendev.org/#/c/717083/ proposed Low bugs -------- * https://bugs.launchpad.net/neutron/+bug/1869808 - reboot neutron-ovs-agent introduces a short interrupt of vlan traffic - asked if it could be reproduced on a later release Wishlist bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1869877 - Segment doesn't exist network info - https://review.opendev.org/#/c/716275/ proposed (nova) - https://review.opendev.org/#/c/715156/ proposed (neutron) * https://bugs.launchpad.net/neutron/+bug/1870319 - [RFE] Network cascade deletion API call - Slawek already added rfe-triaged tag Invalid bugs ------------ * https://bugs.launchpad.net/neutron/+bug/1869768 - devstack failed when Q_AGENT=ovn - Could not reproduce, suspect invalid local.conf * https://bugs.launchpad.net/neutron/+bug/1870002 - The operating_status value of loadbalancer is abnormal - LBaaS bug, moved to storyboard Further triage required ----------------------- * None

1 0

[ironic] Next weekly meeting canceled (April 13th)
by Iury Gregory 06 Apr '20

06 Apr '20

Hello Ironicers, During our weekly meeting today, we decided to cancel the next weekly meeting (April 13th), since it's a holiday for most of the contributors. Best regards, -- *Att[]'sIury Gregory Melo Ferreira **Software Engineer at Red Hat Czech* *MSc in Computer Science at UFCG* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

1 0

[openstack-ansible] Retirement of repo_build and pip_install roles
by Dmitriy Rabotyagov 06 Apr '20

06 Apr '20

4 3

[monasca][release] List cycle-with-intermediary deliverables that have not been released yet
by Herve Beraud 06 Apr '20

06 Apr '20

Hello monasca team, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Ussuri cycle: - monasca-thresh - monasca-ui Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release. Cheers, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[manila][release] List cycle-with-intermediary deliverables that have not been released yet
by Herve Beraud 06 Apr '20

06 Apr '20

Hello manila team, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Ussuri cycle: - manila-ui Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release. Cheers, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[magnum][release] List cycle-with-intermediary deliverables that have not been released yet
by Herve Beraud 06 Apr '20

06 Apr '20

Hello magnum team, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Ussuri cycle: - magnum-ui Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release. Cheers, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[heat][release] List cycle-with-intermediary deliverables that have not been released yet
by Herve Beraud 06 Apr '20

06 Apr '20

Hello heat team, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Ussuri cycle: - heat-agents Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release. Cheers, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[cloudkitty][release] List cycle-with-intermediary deliverables that have not been released yet
by Herve Beraud 06 Apr '20

06 Apr '20

Hello cloudkitty team, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Ussuri cycle: - cloudkitty Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release. Cheers, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[barbican][release] List cycle-with-intermediary deliverables that have not been released yet
by Herve Beraud 06 Apr '20

06 Apr '20

Hello barbican team, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the Ussuri cycle: - barbican-ui Those should be released ASAP, and in all cases before R-3 week (RC1 deadline Apr 20 - Apr 24) , so that we have a release to include in the final Ussuri release. Cheers, -- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[tc][zaqar]Wanna be the PTL of Zaqar project to help in V
by hao wang 04 Apr '20

04 Apr '20

Hi, all TC members I'm Wang Hao, be the Zaqar PTL since 2018. So sorry I missed the community vote for projects. But I still really want to be the Zaqar PTL in V to push this interesting project forward. Indeed, the contribution to Zaqar project has declined for a while. But there're still some projects that have dependencies on it like tripleo, heat, and manila, etc. and AFAIK, some Chinese cloud companies also use Zaqar as messaging service. If Zaqar is removed from core projects, it will have adverse impacts on those projects and companies. Also, we still have blueprints and list of works that should be implemented in V cycle. Finally, as a contributor in Zaqar since 2016, I really want to help this project going forward. Thank you!

2 1

[release] Release countdown for week R-5, April 6 - 10
by Sean McGinnis 03 Apr '20

03 Apr '20

Development Focus ----------------- We are getting close to the end of the Ussuri cycle! Next week on April 9 is the ussuri-3 milestone, also known as feature freeze. It's time to wrap up feature work in the services and their client libraries, and defer features that won't make it to the Ussuri cycle. General Information ------------------- This coming week is the deadline for client libraries: their last feature release needs to happen before "Client library freeze" on April 9. Only bugfix releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/ussuri branching request with the review (as an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/…) April 9 is also the deadline for feature work in all OpenStack deliverables following the cycle-with-rc model. To help those projects produce a first release candidate in time, only bugfixes should be allowed in the master branch beyond this point. Any feature work past that deadline has to be approved by the team PTL. Finally, feature freeze is also the deadline for submitting a first version of your cycle-highlights. Cycle highlights are the raw data hat helps shape what is communicated in press releases and other release activity at the end of the cycle, avoiding direct contacts from marketing folks. See https://docs.openstack.org/project-team-guide/release-management.html#cycle… for more details. Upcoming Deadlines & Dates -------------------------- Ussuri-3 milestone (feature freeze): April 9 (R-5 week) Cycle Highlights Due: April 9 (R-5 week) RC1 deadline: April 23 (R-3 week) Final RC deadline: May 7 (R-1 week) Final Ussuri release: May 13

1 0

[packaging] New package: ovn-octavia-provider
by Maciej Jozefczyk 03 Apr '20

03 Apr '20

Hello, During this cycle Neutron team merged networking-ovn code to Neutron [1]. As a consequence of it we needed to create a new project called: "OVN Octavia provider", which is a provider driver for Octavia. Before it the driver was placed in networking-ovn tree. Neutron cannot rely on Octavia-lib, so that is why this decision was made. The code move process to Neutron took some time and we released the OVN Octavia provider driver yesterday - under version 0.1.0. [2]. If you're working on distro packaging - please be aware that the driver is now delivered by a new package. RPM spec in RDO is ongoing: [3]. We are sorry for this late announcement. [1] https://blueprints.launchpad.net/neutron/+spec/neutron-ovn-merge [2] https://review.opendev.org/#/c/710200/ [3] https://review.rdoproject.org/r/#/c/25972/ -- Best regards, Maciej Józefczyk

2 1