April 2020 - openstack-discuss - lists.openstack.org

[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 06 Apr '20

06 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