- openstack-discuss - lists.openstack.org

[cinder] reminder: weekly meeting location change
by Brian Rosmaita 23 Mar '20

23 Mar '20

(If you missed last week's meeting, this email may be the first you've heard about this change.) Beginning with this Wednesday (25 March), the Cinder team weekly meeting will be held in: #openstack-meeting-alt The time continues to be 1400 UTC on Wednesdays. cheers, brian

1 0

[neutron] Week 13 - bug deputy report
by Slawek Kaplonski 23 Mar '20

23 Mar '20

Hi, Last week I was on bug deputy. Below is my summary of it. *Critical* None *High* https://bugs.launchpad.net/neutron/+bug/1867936 - test_update_delete_extra_route failing due to timeout when creating subnets - HIGH as it’s gate failure This has no assignment yet. For me it looks like generall issue which we have from time to time with some very slow responses from API but it has to be verified. https://bugs.launchpad.net/neutron/+bug/1868237 - [tempest] Error in "test_multicast_between_vms_on_same_network" test case - HIGH as this is gate-failure No assignment yet. https://bugs.launchpad.net/neutron/+bug/1868110 - [OVN] neutron.tests.functional.plugins.ml2.drivers.ovn.mech_driver.ovsdb.test_ovn_db_sync.TestOvnNbSyncOverTcp.test_ovn_nb_sync_log randomly fails - HIGH as it’s gate failure maciejjozefczyk is working on it *Medium* https://bugs.launchpad.net/neutron/+bug/1868100 - ncat process isn't always spawned on guest vm in scenario tests - MEDIUM Already fixed https://bugs.launchpad.net/neutron/+bug/1868125 - [ovn] Metadata agent spawns haproxy quickly twice on a single new port binding - MEDIUM Already fixed https://bugs.launchpad.net/neutron/+bug/1868137 - default geneve overhead is set not enough - MEDIUM Someone from ovn subteam can take a look *Low* https://bugs.launchpad.net/neutron/+bug/1867869 - [OVN] Remove dependency on fip_object - LOW Patch proposed https://review.opendev.org/#/c/713585/ *Incomplete* https://bugs.launchpad.net/neutron/+bug/1868098 - Neutron openvswitch agent error - INCOMPLETE But would be good if someone can take a look *Stadium projects* https://bugs.launchpad.net/neutron/+bug/1868515 - vpnaas ike policy is not allowed to be updated No assignment yet. Needs someone from vpnaas team to take a look. -- Slawek Kaplonski Senior software engineer Red Hat

1 0

[all][privsep] Migrate from oslo.rootwrap to oslo.privsep
by Rodolfo Alonso 22 Mar '20

22 Mar '20

Hello all: With this mail I would like to propose the goal to move away from oslo.rootwrap and migrate to oslo.privsep. The last one offers a superior security model, faster and more secure. During the last cycles and since privsep was released, the Community has encouraged the usage of privsep and the deprecation of any existing code still using rootwrap. For any developer willing to collaborate, there are plenty of code examples, as I’ll provide later, implementing and using privsep for new methods and migrations. If this goal is approved, I'll open a Story (https://storyboard.openstack.org/) and any developer will be able to add a task for each patch or set of them related. This would be the tracker for this common effort. PROJECTS TO MIGRATE. -------------------- Projects that are still using rootwrap: http://codesearch.openstack.org/?q=rootwrap&i=nope&files=.*.py&repos= neutron os-brick designate cinder ironic-inspector neutron-vpnaas nova solum glance_store ironic zun magnum manila networking-bagpipe sahara ceilometer cinderlib freezer ironic-lib monasca-agent tacker tripleo-common USAGE DOCUMENTATION ABOUT PRIVSEP. ---------------------------------- How to create a privsep context, assign privileges and use it as a decorator: https://docs.openstack.org/oslo.privsep/latest/user/index.html HOW TO MIGRATE FROM ROOTWRAP TO PRIVSEP. ---------------------------------------- >From the same link provided previously, in the section “Converting from rootwrap to privsep”: https://docs.openstack.org/oslo.privsep/latest/user/index.html#converting-f… oslo.privsep provides a class, PrivContext, that can be used to create a decorator function. The instance created is a context of execution and has defined a list of capabilities, matching the Linux capabilities. The privsep context decorator should contain the minimum needed capabilities to execute the decorated function. For example: default = priv_context.PrivContext( __name__, cfg_section='privsep', pypath=__name__ + '.default', capabilities=[caps.CAP_SYS_ADMIN, caps.CAP_NET_ADMIN, caps.CAP_DAC_OVERRIDE, caps.CAP_DAC_READ_SEARCH, caps.CAP_SYS_PTRACE], ) The function “entrypoint” of this instance can be used as a decorator for another function: @privileged.default.entrypoint def delete_interface(ifname, namespace, **kwargs): _run_iproute_link("del", ifname, namespace, **kwargs) As commented in the given link, a straight 1:1 filter:function replacement generally results in functions that are still too broad for good security. It is better to replace each chmod rootwrap call with a narrow privsep function that will limit it to specific files. MIGRATION EXAMPLES. ------------------- Nova: https://review.opendev.org/#/q/project:openstack/nova+branch:master+topic:m… Neutron: https://review.opendev.org/#/q/status:merged+project:openstack/neutron+bran… os-vif: https://review.opendev.org/#/c/287725/ Thank you and regards.

6 7

[qeeens][neutron] migrating from iptables_hybrid to openvswitch
by Ignazio Cassano 22 Mar '20

22 Mar '20

Hello All, I am facing some problems migrating from iptables_hybrid frirewall to openvswitch firewall on centos 7 queens, I am doing this because I want enable security groups logs which require openvswitch firewall. I would like to migrate without restarting my instances. I startded moving all instances from compute node 1. Then I configured openvswitch firewall on compute node 1, Instances migrated from compute node 2 to compute node 1 without problems. Once the compute node 2 was empty, I migrated it to openvswitch. But now instances does not migrate from node 1 to node 2 because it requires the presence of qbr bridge on node 2 This happened because migrating instances from node2 with iptables_hybrid to compute node 1 with openvswitch, does not put the tap under br-int as requested by openvswich firewall, but qbr is still present on compute node 1. Once I enabled openvswitch on compute node 2, migration from compute node 1 fails because it exprects qbr on compute node 2 . So I think I should moving on the fly tap interfaces from qbr to br-int on compute node 1 before migrating to compute node 2 but it is a huge work on a lot of instances. Any workaround, please ? Ignazio

5 31

Diskimage-builder complex disk setup
by Stephen Nemeth 21 Mar '20

21 Mar '20

Hi all, We’re attempting to create user images to deploy with metal^3/ironic. I’m making almost no headway starting from any of the examples provided for the DIB_BLOCK_DEVICE_CONFIG setup. Is there a repository with practical values located anywhere? I’m finding the documentation insufficient to do anything more complicated than a single partition setup. Here’s what I’ve gotten so far. Help greatly appreciated: ``` [ { "local_loop": { "name": "image0", "size": "20GiB" } }, { "partitioning": { "base": "image0", "label": "gpt", "partitions": [ { "name": "ESP", "type": "EF00", "size": "16MiB" }, { "name": "boot", "type": "EF02", "size": "6GiB" }, { "name": "lvm", "type": 8, "size": "100%" } ] } }, { "lvm": { "name": "lvm2", "pvs": [ { "name": "pv", "options": [ "--force" ], "device": "lvm", "base": "image0" } ], "vgs": [ { "name": "vg", "base": [ "pv" ], "options": [ "--force" ] } ], "lvs": [ { "name": "root", "base": "vg", "extents": "100%FREE", "options": [ "--zero=n" ] } ] } }, { "mkfs": { { "name": "mkfs_root", "base": "root", "type": "btrfs", "label": "root", "opts": "-f", "mount": { "mount_point": "/" } }, { "name": "mkfs_efi", "base": "ESP", "type": "vfat", "label": "efi", "opts": "-f", "mount": { "mount_point": "/boot/efi/" } }, { "name": "mkfs_boot", "base": "boot", "type": "btrfs", "label": "boot", "opts": "-f", "mount": { "mount_point": "/boot/" } } } } ] ```

2 1

[tripleo] launchpad bug policy
by Wesley Hayutin 20 Mar '20

20 Mar '20

6 8

[neutron] How to fix break of connectivity in case of L3 HA after reboot of backup node
by Slawek Kaplonski 20 Mar '20

20 Mar '20

Hi, We have bug [1] to solve. Basically, when node which is backup node for some router, connectivity to external gateway may be broken for some time. It's like that because when host is up and L3 agent is configuring qrouter namespace, it flush all IPv6 addresses from the qg- interface. And due to that some MLDv2 packets are sent from this interface which may cause that ToR switch will learn qg port's mac address on wrong (backup) node. This don't happens every time and for every router because it is a race between L3 agent and OVS agent. When L3 agent creates qg interface in br-int, it sets tag 4095 for it and traffic sent with such vlan tag is always dropped in br-int. So if L3 agent will flush IPv6 addresses before OVS agent wires the port and sets correct tag for it, then all is fine. But if OVS agent is first, then MLDv2 packets are sent to the wire and there is this connectivity break. There are proposed 2 ways of fixing this: - [2] which propsoes to add some kind of "communication" between L3 agent and OVS agent and tell OVS agent that tag can be changed only after IPv6 config is finished by L3 agent. Downside of this solution is that it works for OVS agent only, Linuxbridge agent may still hit the same issue. But plus is that after initial configuration of the router, everything else regarding to failover is handled by keepalived only - in same way like it is now. - [3] which sets qg NIC to be DOWN always on backup nodes. So when keepalived failover active router to new node, L3 agent needs to come and switch interfaces to be UP before it will work. The plus of this solution is that it works for all OVS and Linuxbridge L2 agents (and probably for others too) but downside is that failover process is a bit longer and there may be potentially another race condition between L3 agent and keepalived. Keepalived tries to sent gARP packets after switch node to be active, first attempt will always fail as interface is still DOWN. But keepalived will retry those gARPs after some time and this should be fine if L3 agent will already bring interface to be UP. Both patches are waiting for pretty long time in gerrit and I want to bring more visibility for both of them. Please check them and maybe You will have some opinions about which solution would be better and which we should go with. [1] https://bugs.launchpad.net/neutron/+bug/1859832 [2] https://review.opendev.org/#/c/702856/ [3] https://review.opendev.org/#/c/707406/ -- Slawek Kaplonski Senior software engineer Red Hat

5 4

Neutron RabbitMQ issues
by Grant Morley 20 Mar '20

20 Mar '20

Hi all, We are currently experiencing some fairly major issues with our OpenStack cluster. It all appears to be with Neutron and RabbitMQ. We are seeing a lot of time out messages in responses to replies and because of this instance creation or anything to do with instances and networking is broken. We are running OpenStack Queens. We have already tuned Rabbit for Neutron by doing the following on neutron: heartbeat_timeout_threshold = 0 rpc_conn_pool_size = 300 rpc_thread_pool_size = 2048 rpc_response_timeout = 3600 rpc_poll_timeout = 60 ## Rpc all executor_thread_pool_size = 64 rpc_response_timeout = 3600 What we are seeing in the error logs for neutron for all services (l3-agent, dhcp, linux-bridge etc ) are these timeouts: https://pastebin.com/Fjh23A5a We have manually tried to get everything in sync by forcing fail-over of the networking which seems to get routers in sync. We are also seeing that there are a lot of "unacknowledged" messages in RabbitMQ for 'q-plugin' in the neutron queues. Some times restarting of the services on neutron gets these back acknowledged again, however the timeouts come back. The RabbitMQ servers themselves are not loaded at all. All memory, file descriptors and errlang processes have plenty of resources available. We are also seeing a lot of rpc issues: Timeout in RPC method release_dhcp_port. Waiting for 1523 seconds before next attempt. If the server is not down, consider increasing the rpc_response_timeout option as Neutron server(s) may be overloaded and unable to respond quickly enough.: MessagingTimeout: Timed out waiting for a reply to message ID 965fa44ab4f6462fa378a1cf7259aad4 2020-03-10 19:02:33.548 16242 ERROR neutron.common.rpc [req-a858afbb-5083-4e21-a309-6ee53582c4d9 - - - - -] Timeout in RPC method release_dhcp_port. Waiting for 3347 seconds before next attempt. If the server is not down, consider increasing the rpc_response_timeout option as Neutron server(s) may be overloaded and unable to respond quickly enough.: MessagingTimeout: Timed out waiting for a reply to message ID 7937465f15634fbfa443fe1758a12a9c Does anyone know if there is anymore tuning to be done at all? Upgrading for us at the moment to a newer version isn't really an option unfortunately. Because of our setup, we also have roughly 800 routers enabled and I know that will be putting a load on the system. However these problems have only started to happen roughly 1 week ago and have steadily got worse. If anyone has any use cases for this or any more recommendations that would be great. Many thanks,

3 25

[release] Release countdown for week R-7, March 23-27
by Sean McGinnis 20 Mar '20

20 Mar '20

Development Focus ----------------- We are entering the last weeks of the Ussuri development cycle. From now until the final release, we'll send a countdown email like this every week. It's probably a good time for teams to take stock of their library and client work that needs to be completed yet. The non-client library freeze is coming up, followed closely by the client lib freeze. Please plan accordingly so avoid any last minute rushes to get key functionality in. General Information ------------------- Next week is the Extra-ATC freeze, in preparation for elections. All contributions to OpenStack are valuable, but some are not expressed as Gerrit code changes. Please list active contributors to your project team who do not have a code contribution this cycle, and therefore won't automatically be considered an Active Technical Contributor and allowed to vote. This is done by adding extra-atcs to https://opendev.org/openstack/governance/src/branch/master/reference/projec… before the Extra-ATC freeze on March 26. A quick reminder of the upcoming freeze dates. Those vary depending on deliverable type: * General libraries (except client libraries) need to have their last feature release before Non-client library freeze (April 2). Their stable branches are cut early. * Client libraries (think python-*client libraries) need to have their last feature release before Client library freeze (April 9) * Deliverables following a cycle-with-rc model (that would be most services) observe a Feature freeze on that same date, April 9. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. After feature freeze, cycle-with-rc deliverables need to produce a first release candidate (and a stable branch) before RC1 deadline (April 23) * Deliverables following cycle-with-intermediary model can release as necessary, but in all cases before Final RC deadline (May 7) Finally, now is also a good time to start planning what highlights you want for your deliverables in the cycle highlights. The deadline to submit an initial version for those is set to Feature freeze (April 9). Background on cycle-highlights: http://lists.openstack.org/pipermail/openstack-dev/2017-December/125613.html Project Team Guide, Cycle-Highlights: https://docs.openstack.org/project-team-guide/release-management.html#cycle… knelson [at] openstack.org/diablo_rojo on IRC is available if you need help selecting or writing your highlights Note that cycle highlights are per-team, not per-deliverable. Upcoming Deadlines & Dates -------------------------- Extra-ATC freeze: March 26 (R-7 week) Non-client library freeze: April 2 (R-6 week) Client library freeze: April 9 (R-5 week) Ussuri-3 milestone: April 9 (R-5 week) Cycle Highlights Due: April 9 (R-5 week)

1 0

[queens][cinder][unity] iscsi driver
by Ignazio Cassano 20 Mar '20

20 Mar '20

Hello All, I would like to suggest to modify the unity iscsi cinder driver documentation. After 1 month of intensive test, we discovered the mutipath.conf needs the following option in multipath.conf kvm nodes: skip_kpartx yes Without the above option instances with more than 2 volumes attached could fail live migration because the os_brick code fails in "multipath -f" command reporting map in use error. Ignazio

1 0

[openstack.org] SEO Improvements
by Jimmy McArthur 19 Mar '20

19 Mar '20

Hi all - We've contracted a professional SEO firm to help improve search placement for all OSF projects. I'd like to crowd source this on each of the project mailing lists, so the community is able to be involved. Could you all help out in providing the below: “Wish List” of keywords: 8-12 big terms you think fit your domain (if you only have 4-5 to share, fewer is okay) - open source ci - ? At least 3 competitors - Jenkins - ? Any other input on positioning, offerings, etc. that you think will help best filter for relevance - ? Cheers, Jimmy

6 12

Re: [Release-job-failures] Tag of openstack/glance_store for ref refs/tags/rocky-em failed
by Sean McGinnis 19 Mar '20

19 Mar '20

On 3/19/20 4:56 PM, zuul(a)openstack.org wrote: > Build failed. > > - publish-openstack-releasenotes-python3 https://zuul.opendev.org/t/openstack/build/66b1173250724747bc9b7630277a5b1a : POST_FAILURE in 4m 24s > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures This failure appears to be from a temporary glitch that we've seen time to time in the gate: "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!" This was on publishing release notes. Since no new release notes have been added as part of this (just tagging rocky-em) it is safe to ignore this failure. Sean

1 0

[nova] bug triage
by Balázs Gibizer 19 Mar '20

19 Mar '20

Hi, We surpassed the somewhat magical line of having more than 100 untriaged nova bugs [1]. For me it seems that how we, as a team, are handling the incoming bugs is not sustainable. I'm guilty as well of not doing bug triage in a last two months. So I'm personally trying to change now and dedicate a weekly times lot to look at the bug list. But I also want to open a discussion about bug triage in genera. How can we handle the incoming bugs? I see that neutron does a weekly rotation of bug deputy and for them it works nicely. What do you think? Do we want to try that? Do we have enough volunteers to create a nice rotation period? Cheers, gibi [1] https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New

2 1

[python-openstackclient] --force bug
by jayaditya gupta 19 Mar '20

19 Mar '20

Hello all, new contributor/developer here. I have just submitted a bug for python-openstackclient project : https://storyboard.openstack.org/#!/story/2007440 I am not sure how to provide --force option to openstackclient .. I am comparing quota.py files in nova-client and in openstackclient.but can't seem to understand how to provide --force option. Any suggestions? Best Regards

3 3

[neutron]Drivers meeting cancelled
by Slawek Kaplonski 19 Mar '20

19 Mar '20

Hi, Due to lack of agenda, lets cancel tomorrows (20.03.2020) drivers meeting and lets focus on reviewing patches related to the already accepted RFEs [1]. [1] https://tinyurl.com/vezk6n6 — Slawek Kaplonski Senior software engineer Red Hat

1 0

[all][tc] Moving PTL role to "Maintainers"
by Mohammed Naser 19 Mar '20

19 Mar '20

Hi everyone: We're now in a spot where we have an increasing amount of projects that don't end up with a volunteer as PTL, even if the project has contributors .. no one wants to hold that responsibility alone for many reasons. With time, the PTL role has become far more overloaded with many extra responsibilities than what we define in our charter: https://governance.openstack.org/tc/reference/charter.html#project-team-lea… I think it's time to re-evaluate the project leadership model that we have. I am thinking that perhaps it would make a lot of sense to move from a single PTL model to multiple maintainers. This would leave it up to the maintainers to decide how they want to sort the different requirements/liaisons/contact persons between them. The above is just a very basic idea, I don't intend to diving much more in depth for now as I'd like to hear about what the rest of the community thinks. Thanks, Mohammed

24 34

[ops][cinder] deprecation notice: os-reset_status notifications
by Brian Rosmaita 19 Mar '20

19 Mar '20

tl;dr: the notifications themselves aren't being deprecated, there's a change in where they're being sent While working on https://launchpad.net/bugs/1863806, Walt discovered that notifications associated with the Block Storage API os-reset_status calls were being sent to nonstandard publisher_ids, namely: * 'volumeStatusUpdate' for volume status resets * 'volumeStatusUpdate' for snapshot status resets * 'backupStatusUpdate' for backup status resets Walt has a patch up to direct these notifications to the same publisher_id as other Cinder resource actions: * 'volume' for volume status resets * 'snapshot' for snapshot status resets * 'backup' for backup status resets Walt's patch continues to send the notifications to the nonstandard publisher_ids, but this behavior is DEPRECATED. In Ussuri, notifications will be sent to *both* publisher_ids. We propose to remove sending notifications to the nonstandard publisher_ids during the Victoria development cycle. This deprecation will be announced in the cinder release notes, but we wanted to give operators advance notice. No one currently working on cinder knows why these notifications were being sent to nonstandard publisher_ids, which makes it difficult to assess what, if any, impact this change will have on operators. If you have concerns about either the nonstandard publisher_ids being deprecated and removed, or about these notifications being sent to the standard publisher_ids, please express them on the following review before Tuesday 24 March: https://review.opendev.org/#/c/708563/ Thank you.

1 0

upgrade qemu 4.2 on CentOS 7.x for openstack
by Satish Patel 18 Mar '20

18 Mar '20

Folk, I am running openstack stein on CentOS 7.5 so default version of qemu-kvm is 2.12.x. as we know current qemu version is 4.2. Question: If i compile/install latest version of qemu 4.2 using source tarball on compute node in that case do i need to compile/install kvm or Libvirt? ~S

1 0

[all][elections][ptl][tc] Combined PTL/TC Election Season
by Kendall Nelson 18 Mar '20

18 Mar '20

Hello Everyone! Election details: https://governance.openstack.org/election/ The nomination period officially begins Mar 24, 2020 23:45 UTC. Please read the stipulations and timelines for candidates and electorate contained in this governance documentation. Due to circumstances of timing, PTL and TC elections for the coming cycle will run concurrently; deadlines for their nomination and voting activities are synchronized but will still use separate ballots. Please note, if only one candidate is nominated as PTL for a project team during the PTL nomination period, that candidate will win by acclaim, and there will be no poll. There will only be a poll if there is more than one candidate stepping forward for a project team's PTL position. There will be further announcements posted to the mailing list as action is required from the electorate or candidates. This email is for information purposes only. If you have any questions which you feel affect others please reply to this email thread. If you have any questions that you which to discuss in private please email any of the election officials[1] so that we may address your concerns. Thank you! -Kendall Nelson (diablo_rojo) & the Election Officials [1] https://governance.openstack.org/election/#election-officials

1 0

FW: 2020 OSF Events & coronavirus
by Mark Collier 18 Mar '20

18 Mar '20

I wanted to make sure everyone saw this thread on the foundation mailing list, since I know not everyone is subscribed to both lists: Archive: http://lists.openstack.org/pipermail/foundation/2020-March/002852.html Please join that ML thread to share feedback on this topic, or you can reach out directly to myself or jonathan(a)openstack.org I saw first hand how we all pulled together during the Snowpenstack in Dublin, so I know we'll once again pull together as a community to get through this! Mark On Friday, March 6, 2020 12:55pm, "Mark Collier" <mark(a)openstack.org> said: > Stackers, > > Before I get into the current plans for the OSF events in Vancouver and Berlin, I > wanted to say a few words in general about the virus impacting so many people > right now. > > First, I wanted to acknowledge the very difficult situation many are facing > because of COVID-19 (Coronavirus), across open source communities and local > communities in general (tech or otherwise). I also want to say to everyone who is > on the front lines managing events, from the full time staffers to the volunteers, > to the contractors and production partners, that we have some idea of what you're > going through and we know this is a tough time. If there's anything we can do to > help, please reach out. In the best of times, event organization can be grueling > and thankless, and so I just want to say THANK YOU to everyone who does the > organizing work in the communities we all care so much about. > > OSF 2020 EVENTS > > When it comes to the 2020 events OSF is managing, namely the OpenDev + PTG in > Vancouver June 8-11 and the Open Infrastructure Summit in Berlin October 19-23, > please read and bookmark this status page which we will continue to update: > https://www.openstack.org/events/covid-19-coronavirus-disease-updates > > When it comes to our community, the health of every individual is of paramount > concern. We have always aimed to produce events "of the community, by the > community" and the upcoming event in Vancouver is no exception. The OpenDev tracks > each morning will be programmed by volunteers from the community, and the project > teams will be organizing their own conversations as well each afternoon M-W, and > all day Thursday. > > But the larger question is here: should the show go on? > > The short answer is that as of now, the Vancouver and Berlin events are still > scheduled to happen in June (8-11) and October (19-23), respectively. > > However, we are willing to cancel or approach the events in a different way (i.e. > virtual) if the facts indicate that is the best path, and we know the facts are > changing rapidly. One of the most critical inputs we need is to hear from each of > you. We know that many of you rely on the twice-annual events to get together and > make rapid progress on the software, which is one reason we are not making any > decisions in haste. We also know that many of you may be unable or unwilling to > travel in June, and that is critical information to hear as we get closer to the > event so that we can make the most informed decision. > > I also wanted to answer a FAQ by letting everyone know that if either event is > cancelled, event tickets and sponsorships will be fully refunded. Please note that > if you're making travel arrangements (e.g. flights, hotels) those are outside of > our control. > > So as we continue to monitor the news and listen to health experts to make an > informed decision on any changes to our event plans, we'd like to hear from > everyone in the community who has a stake in these events. Our most pressing topic > is of course Vanvouver, but if you have questions or concerns about the Berlin > plan feel free to share those as well. > > If you'd like to connect directly, you can always contact Executive Director > Jonathan Bryce (jonathan(a)openstack.org) or myself (mark(a)openstack.org) > > Key Links: > - STATUS PAGE: > https://www.openstack.org/events/covid-19-coronavirus-disease-updates > - Vancouver OpenDev + PTG https://www.openstack.org/events/opendev-ptg-2020/ > - Berlin Open Infrastructure Summit: https://www.openstack.org/summit/berlin-2020/ > > Key Dates for OpenDev + PTG in Vancouver: > - Schedule will be published in early April > - Early bird deadline is April 4 > - Final day to sponsor will be May 4 > - Final registration price increase will be in early May > > Mark Collier > COO, OpenStack Foundation > @sparkycollier > >

11 11

Not running for TC this round
by Thierry Carrez 18 Mar '20

18 Mar '20

Hi everyone, I've been elected on the TC (or its previous incarnations) since we had community-elected seats in that body (2011). However, as announced during the previous election round (and in the discussion about reducing the number of TC seats) I do not plan to run for the TC in the upcoming election round. There are multiple reasons for this. The main one is that with name recognition and a Condorcet voting system, it's relatively easy for incumbents to be reelected. We only elect 5 seats this time, so I think it's important to make room for new names to step up. The second reason is that I'd like more people with an operational background to be present on the TC. I think we can simplify our governance by having a single elected body handling the open source project, rather than maintain separate representation for users and developers. As we get more people bringing operational perspective to the TC, that simplification will be even more obvious. The final reason is that I've always been saying that you can work on governance issues and voice your opinion on them, without being elected on the TC and formally voting on things. It's time for me to walk that talk. I do not intend to go anywhere, and I'll be as present as always in proposing the OpenStack governance changes that I deem needed in this day and age. I'll finish this email by encouraging anyone interested in open source project governance, or wanting to help shape the next chapter of the OpenStack story, to step up and run for TC election. As for all governance bodies, the experience can be frustrating, as you'd like to fix more things but there is only so much you can do. But it's a great experience, one that I recommend everyone working on open source project should have. The only prerequisite is an interest and care for "OpenStack" as a whole. No specific experience or diploma needed. If you wonder if you can do it, the answer is yes. Nominations[1] open up March 24. Please consider running, especially if you have operational experience with some cycles to spare. If you have any questions on the job, feel free to reach out to me -- you know where to find me. [1] https://governance.openstack.org/election/ -- Thierry Carrez (ttx)

3 2

[all][PTL][tc] U Community Goal: Project PTL & Contrib Docs Update #5
by Kendall Nelson 17 Mar '20

17 Mar '20

Hello Everyone! First off, I want to say thank you so much to Watcher, Trove, Searchlight, Qinling, Nova, Neutron, Kolla, Ironic, i18n, Glance, Cinder, and Blazar for getting started/completing the goal! For those projects that have not started yet, you can take a look at what the others have done for some inspiration[1], or simply fill in the template[2]. We did our best to make the process as low effort as possible. If you have any questions, please let me know or refer to the goal[3]. Once you get started, please make sure to keep the story up to date[4]. I look forward to reviewing your patches!! If there is anything I can do to help, please let me know. -Kendall (diablo_rojo) [1] Progress: https://review.opendev.org/#/q/topic:project-ptl-and-contrib-docs+(status:o… [2] Cookiecutter Template: https://opendev.org/openstack/cookiecutter/src/branch/master/%7b%7bcookiecu… [3] Accepted Goal: https://governance.openstack.org/tc/goals/selected/ussuri/project-ptl-and-c… [4] Task Tracking: https://storyboard.openstack.org/#!/story/2007236

1 0

Using #opendev on Freenode for OpenDev Infrastructure Discussions
by Clark Boylan 17 Mar '20

17 Mar '20

Hello all, We have reached a point in time where it now makes sense for us to use #opendev on Freenode for OpenDev discussions, rather than #openstack-infra. We are updating our various bots to reflect this change and are asking you to find us in the new channel. We expect this to be a time of transition so don't be afraid of bringing things up in either the old or new channel if you are unsure of where you should go; we'll get you pointed in the right direction. The old channel, #openstack-infra, won't be going away. We expect it to become more OpenStack specific. Topics like how to use Zuul for OpenStack jobs could go here. This likely will have some overlap with the #openstack-qa channel and we may end up collapsing them, but that can happen if we notice the conversations do overlap significantly. We hope this gives non OpenStack users a friendly neutral location to engage us. Sorry, for any disruptions this may cause. Clark

1 0

[all] Guides for newbies to OpenStack
by Mike Carden 17 Mar '20

17 Mar '20

Our small team at ${DAYJOB} has built a handful of OpenStack clusters based on Red Hat OpenStack 13 (aka Queens) over the last couple of years. We now find ourselves in the position of being 'gifted' human resources in the shape of mid-level 'IT people' who are sent to join our team for a short time to 'Learn OpenStack'. These tend to be people for whom, "Here's a Horizon URL and some creds - go log in and launch a VM"[1]... is a bit much. I've done a wee bit of web searching (enough to find the dead links) trying to find some newbie friendly tutorials on OpenStack basics. Before I attempt to re-invent the wheel, can anyone suggest some public resources I might point people to? Deity help us if we have to explain Tripleo's Undercloud, Overcloud, partially containered, partially pacemakered, fully flaky... underpinnings. Thanks, MC [1] Even with a step by step guide

5 4

[openstack-helm] Virtual Midcycle
by Gage Hugo 17 Mar '20

17 Mar '20

Good afternoon, The openstack-helm team will be hosting their virtual midcycle next Tuesday, March 24th 2020 at 1400 to 1700 UTC. Please check out the etherpad link for more details about the agenda and conferencing tool. Since this meeting is overlapping our normal meeting time, the actual IRC meeting will be canceled for next week. https://etherpad.openstack.org/p/osh-virtual-ptg-2020-03 Hope to see you all there.

1 0