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

[nova][neutron][ptg] Future of the routed network support
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] There is only basic scheduling support in nova for the neutron routed networks feature (server create with port.ip_allocation=deferred seems to work). There was multiple attempts in the past to complete the support (e.g.server create with port.ip_allocation=immediate or server move operations). The latest attempt started by Matt couple of cycles ago, and in the last cycle I tried to push that forward[1]. When I added this topic to the PTG etherpad I thought I will have time in the Victoria cycle to continue [1] but internal priorities has changed. So finishing this feature needs some developers. If there are volunteers for Victoria then please let me know and then we can keep this as a topic for the PTG but otherwise I will remove it from the schedule. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://review.opendev.org/#/q/topic:routed-networks-scheduling

2 2

[nova][ptg] Can we close old bugs?
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] We have more than 800 open bugs in nova [1] and the oldest is 8 years old. Can we close old bugs? If yes, what would be the closing criteria? Age and status? Personally I would close every bug that is not updated in the last 3 years and not in INPROGRESS state. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://bugs.launchpad.net/nova/+bugs?field.searchtext=&orderby=-importance…

5 7

[nova][ptg] bumping compute RPC to 6.0
by Balázs Gibizer 05 Jun '20

05 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] Do we want to bump the compute RPC to 6.0 in Victoria? We did not have the full view what we can gain[2] with such bump so Stephen and I searched through nova and collected the things we could clean up [1] eventually if we bump the compute RPC to 6.0 in Victoria. I can work on the RPC 6.0 patch during V and I think I can also help in with the possible cleanups later. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://etherpad.opendev.org/p/compute-rpc-6.0 [2] http://eavesdrop.openstack.org/meetings/nova/2020/nova.2020-04-16-16.00.log…

3 4

[manila][ptg] Minutes, recordings, final day items and Happy Hour!
by Goutham Pacha Ravi 04 Jun '20

04 Jun '20

Hello Zorillas and interested Stackers, It's Friday already, but it feels like we've been there every day this week! Thanks to note takers, we have the meeting etherpad up-to-date wrt the meetings we've had thus far. [1] Tomorrow, 5th June, Friday, we meet in the same room () between 1300 UTC and 1700 UTC - the schedule details are in the etherpad [1], however the main items are as below: - Optimize the quota processing logic for manage share (haixin) (1300-1330 UTC) - Share and share size quotas/limits per share server (carloss/dviroel) (1340-1410 UTC) - Share server migration (dviroel) (1420 - 1450 UTC) - Manila Container Storage Interface project update/roadmap/demo (tbarron) (1500-1530 UTC) - Manila OSC/CLI "common commands" discussion (maaritamm/vkmc) (1530-1550 UTC) - Virtual Happy Hour (all) (1600-1700 UTC) You'll find the recordings of our past discussions uploaded to YouTube [2]. Check the descriptions to skip ahead to specific topics. Please let me know if you have any difficulty accessing these videos. Hope to see you tomorrow! Thanks, Goutham Pacha Ravi [1] https://etherpad.opendev.org/p/victoria-ptg-manila [2] https://www.youtube.com/playlist?list=PLnpzT0InFrqBKkyIAQdA9RFJnx-geS3lp

1 0

[tripleo] Thanks for a great PTG :)
by Wesley Hayutin 04 Jun '20

04 Jun '20

Thanks all! Great topics, participation, discussion etc! Notes and a summary are in the works. And now your moment of zen.

1 0

[oslo][keystone][nova] Spec for moving policy format default to YAML
by Ben Nemec 04 Jun '20

04 Jun '20

One of the outcomes of the Oslo PTG session on Monday was that we need to make YAML the official default for olso.policy instead of just the unofficial default as it has been since policy-in-code happened. The reason this hasn't happened before now is that it is complex and fraught with security concerns, but the RBAC work going on now has made it clear that we need do it anyway. To that end, I've written a spec[0] that I believe captures the plan we outlined in the PTG session. If this is relevant to your interests, please take a look and leave feedback. Thanks. -Ben 0: https://review.opendev.org/733650

2 1

[ops] [cinder] [nova] How can I understand if "Delete volume on instance delete" was selected ?
by Massimo Sgaravatto 04 Jun '20

04 Jun '20

Hi I need to delete an instance created from volume, but I don't want to delete such volume. How can I know if the option "Delete volume on instance delete" was selected when creating such instance ? I can't find any information in openstack server/volume show outputs Thanks, Massimo

2 2

[Openstack] OpenStack Ussuri for Ubuntu 20.04 LTS and 18.04 LTS
by Corey Bryant 04 Jun '20

04 Jun '20

The Ubuntu OpenStack team at Canonical is pleased to announce the general availability of OpenStack Ussuri on Ubuntu 20.04 LTS and on Ubuntu 18.04 LTS via the Ubuntu Cloud Archive. Details of the Ussuri release can be found at: https://www.openstack.org/software/ussuri To get access to the Ubuntu Ussuri packages: == Ubuntu 20.04 LTS == OpenStack Ussuri is available by default for installation on Ubuntu 20.04. == Ubuntu 18.04 LTS == The Ubuntu Cloud Archive pocket for OpenStack Ussuri can be enabled on Ubuntu 18.04 by running the following commands: sudo add-apt-repository cloud-archive:ussuri The Ubuntu Cloud Archive for Ussuri includes updates for: aodh, barbican, ceilometer, ceph octopus (15.2.1), cinder, designate, designate-dashboard, dpdk (19.11.1), glance, gnocchi, heat, heat-dashboard, horizon, ironic, keystone, libvirt (6.0.0), magnum, manila, manila-ui, mistral, murano, murano-dashboard, networking-arista, networking-bagpipe, networking-bgpvpn, networking-hyperv, networking-l2gw, networking-mlnx, networking-odl, networking-sfc, neutron, neutron-dynamic-routing, neutron-fwaas, neutron-fwaas-dashboard, neutron-vpnaas, nova, octavia, octavia-dashboard, openstack-trove, trove-dashboard, openvswitch (2.13.0), ovn (20.03.0), ovn-octavia-provider, panko, placement, qemu (4.2), sahara, sahara-dashboard, senlin, swift, trove-dashboard, vmware-nsx, watcher, watcher-dashboard, and zaqar. For a full list of packages and versions, please refer to: http://reqorts.qa.ubuntu.com/reports/ubuntu-server/cloud-archive/ussuri_ver… == Branch package builds == If you would like to try out the latest updates to branches, we deliver continuously integrated packages on each upstream commit via the following PPA’s: sudo add-apt-repository ppa:openstack-ubuntu-testing/mitaka sudo add-apt-repository ppa:openstack-ubuntu-testing/queens sudo add-apt-repository ppa:openstack-ubuntu-testing/rocky sudo add-apt-repository ppa:openstack-ubuntu-testing/stein sudo add-apt-repository ppa:openstack-ubuntu-testing/train sudo add-apt-repository ppa:openstack-ubuntu-testing/ussuri == Reporting bugs == If you have any issues please report bugs using the 'ubuntu-bug' tool to ensure that bugs get logged in the right place in Launchpad: sudo ubuntu-bug nova-conductor Thank you to everyone who contributed to OpenStack Ussuri. Enjoy and see you in Victoria! Corey (on behalf of the Ubuntu OpenStack Engineering team)

3 6

[nova] [ops] user_id based policy enforcement
by Massimo Sgaravatto 04 Jun '20

04 Jun '20

Hi In my Rocky installation I am preventing users from deleting instances created by other users of the same project. This was implemented setting in the nova policy file: "os_compute_api:servers:delete": "rule:admin_api or user_id:%(user_id)s" This works, even if in the nova log file I see: The user_id attribute isn't supported in the rule 'os_compute_api:servers:delete'. All the user_id based policy enforcement will be removed in the future. Now I would also like preventing user to see the console log file of instances created by other users. I set in the nova policy file: "os_compute_api:os-console-output" : "rule:admin_api or user_id:%(user_id)s" but this doesn't work Any hints ? More in general: were the user_id based policy eventually removed in latest OpenStack releases ? Which are then the possible alternatives to implement my use case ? Thanks, Massimo

2 5

[nova][ptg] Runway process in Victoria
by Balázs Gibizer 04 Jun '20

04 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] In the last 4 cycles we used a process called runway to focus and timebox of the team's feature review effort. However compared to the previous cycles in ussuri we did not really keep the process running. Just compare the length of the Log section of each etherpad [1][2][3][4] to see the difference. So I have two questions: 1) Do we want to keep the process in Victoria? 2) If yes, how we can make the process running? 2.1) How can we keep the runway etherpad up-to-date? 2.2) How to make sure that the team is focusing on the reviews that are in the runway slots? Personally I don't want to advertise this process for contributors if the core team is not agreed and committed to keep the process running as it would lead to unnecessary disappointment. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://etherpad.opendev.org/p/nova-runways-rocky [2] https://etherpad.opendev.org/p/nova-runways-stein [3] https://etherpad.opendev.org/p/nova-runways-train [4] https://etherpad.opendev.org/p/nova-runways-ussuri

3 4

[nova][ptg] Feature Liaison
by Balázs Gibizer 04 Jun '20

04 Jun '20

Hi, [This is a topic from the PTG etherpad [0]. As the PTG time is intentionally kept short, let's try to discuss it or even conclude it before the PTG] Last cycle we introduced the Feature Liaison process [1]. I think this is time to reflect on it. Did it helped? Do we need to tweak it? Personally for me it did not help much but I think this is a fairly low cost process so I'm OK to keep it as is. Cheers, gibi [0] https://etherpad.opendev.org/p/nova-victoria-ptg [1] https://review.opendev.org/#/c/685857/

5 6

[ops][ptg] Virtual Ops Meetup at the PTG
by Erik McCormick 03 Jun '20

03 Jun '20

Hello all, Your friendly neighborhood Ops Meetup Team is hosting a first ever (and very experimental) Virtual Ops Meetup Wednesday, June 3rd at 13:00 UTC on the foundation Jitsi server. You can find us here: https://meetpad.opendev.org/victoria-ptg-ops-meetup Meetpad will open an integrated Ehterpad to go along with the meeting, but if you'd prefer to have it separate, just replace "meetpad" with "etherpad" in the URL. We recommend using Chrome wherever possible. If you're on a mobile device, there is also a Jitsi Meet app for iOS and Android that work pretty well. The schedule has us going until 15:00 UTC, but we'll continue as long as people are around and want to keep it going. I look forward to seeing a few (or many!) of you in a few hours! Cheers, Erik

2 3

[cinder] retrospective survey
by Brian Rosmaita 03 Jun '20

03 Jun '20

We're scheduled to hold our Cinder team Ussuri cycle retrospective tomorrow (Thursday, 4 June, see the etherpad for details and projected time): https://etherpad.opendev.org/p/victoria-ptg-cinder I posted a brief survey to help get you thinking. It's optional, but like I said, it may stimulate the thought process. Or if you won't be able to attend the retrospective, you can fill out the survey and we'll still be able to take your feedback into account. Here it is: https://rosmaita.wufoo.com/forms/cinder-ussuri-retrospective/ The survey is "sort of" anonymous (it collects your IP number). cheers, brian

1 0

[all][InteropWG] Please verify if Desigane+Heat Project needs any updates for Interop testing of user APIs
by prakash RAMCHANDRAN 03 Jun '20

03 Jun '20

HI all, This is second call to OpenStack Project Teams Core member for identfying any user APIs needed to submit patches for Brnading program.https://www.openstack.org/brand/interop/ Can Designate, Heat PTLs confirm that add-ons listed are all you need for add-on Branding programs for Orchestartion and DNS respetcively. Hi Designate & Heat Core team members, Hi add-ons (Heat + Designate teams) We are trying to run our ambassadors or volunteers to your meetings, but if we miss please reply with "Confirmed OK" to submit these draft to be merged for "OpenStack Powered Storage" approval. Please bring this your PTG meetings if needed to assign a volunteer to complete the verification and submit patch (if updates are needed). Add-ons: DNS: designate - Release notes - https://docs.openstack.org/releasenotes/designate/ussuri.htmladd-on program codes - https://opendev.org/openstack/interop/src/branch/master/add-ons/dns.2020.06… Confirmed OK - ? patch? Orchestration: heat - Release notes - https://docs.openstack.org/api-ref/orchestration/v1/index.htmladd-on program codes - https://opendev.org/openstack/interop/src/branch/master/add-ons/orchestrati… Confirmed OK - ? Patch? ThanksInterop Chair: PrakashVice Chair: Mark

1 0

Fw: [all][InteropWG] Please verify if Core Project needs any updates for Interop testing of user APIs
by prakash RAMCHANDRAN 03 Jun '20

03 Jun '20

Hi OpenStack Core team members, Please bring this to your PTG meetings if needed. Aassign a volunteer to complete the verification and/or submit patch (if updates are needed). We are trying to run our ambassadors or volunteers to your meetings, but if we miss please reply with "Confirmed OK" to submit these draft to be merged for "OpenStack Powered Compute" approval. Drfat to patch if you need updates is shown below.https://opendev.org/openstack/interop/src/branch/master/2020.06.json Line 100-178 (has all core API capability listed for you to verify)https://opendev.org/openstack/interop/src/branch/master/2020.06.json… All API Ussuri Release notes available on - https://docs.openstack.org/api-ref/ Following Core Team members can Confirm OK? Yes if you do not have any updatex Keystone:ConfirmOK ? or Submit patch for 2020.06.json ? Glance:ConfirmOK ? or Submit patch for 2020.06.json ? Nova:ConfirmOK ? or Submit patch for 2020.06.json ? Neutron:ConfirmOK ? or Submit patch for 2020.06.json ? Cinder:ConfirmOK ? or Submit patch for 2020.06.json ? We are trying to run our ambassadors to your meetings, but if we miss please reply with "Confirmed OK - Yes" to submit these draft for approvals to merge asap. ThanksInterop WG chair: Prakash& Vice chair: Mark

1 0

[kolla] voting on Victoria priorities
by Mark Goddard 03 Jun '20

03 Jun '20

Hi, Thanks to everyone who attended the Kolla PTG sessions, we covered a lot of ground. The Etherpad is available at [1]. At the end of the sessions we agreed on some candidate features for prioritisation during the Victoria cycle. I have moved these across to a second Etherpad [2]. Now is the time to vote! Please add your name against a maximum of 12 items across the 3 deliverables (kolla, kolla-ansible, kayobe) in the priorities [2] Etherpad. [1] https://etherpad.opendev.org/p/kolla-victoria-ptg [2] https://etherpad.opendev.org/p/kolla-victoria-priorities Thanks, Mark

1 0

[OSSN-0086] Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure
by Brian Rosmaita 03 Jun '20

03 Jun '20

Dell EMC ScaleIO/VxFlex OS Backend Credentials Exposure --- ### Summary ### This vulnerability is present when using Cinder with a Dell EMC ScaleIO or VxFlex OS storage backend. Note: The Dell EMC "ScaleIO" driver was rebranded as "VxFlex OS" in the Train release. ### Affected Services / Software ### Cinder / Ocata, Pike, Queens, Rocky, Stein, Train, Ussuri This vulnerability applies only when using a Dell EMC ScaleIO/VxFlex OS Backend with Cinder. Other drivers are not impacted. ### Discussion ### When using Cinder with the Dell EMC ScaleIO or VxFlex OS backend storage driver, credentials for the entire backend are exposed in the ``connection_info`` element in all Block Storage v3 Attachments API calls containing that element. This enables an end user to create a volume, make an API call to show the attachment detail information, and retrieve a username and password that may be used to connect to another user's volume. Additionally, these credentials are valid for the ScaleIO or VxFlex OS Management API, should an attacker discover the Management API endpoint. This issue was reported by David Hill and Eric Harney of Red Hat. ### Recommended Actions ### Remediation of this issue consists of the following: 1. Patching the ScaleIO or VxFlex OS Cinder driver so that it no longer provides the password to Cinder when a Block Storage v3 Attachments API response is constructed. 2. Patching the ScaleIO connector in the os-brick library so that it retrieves the password from a configuration file readable only by root. (Note: the connector was not rebranded; both ScaleIO and VxFlex OS backends use the 'scaleio' os-brick connector.) 3. Patching the ScaleIO os-brick privileged file that allows the scaleio connector to escalate privileges for specific operations; this is necessary to allow the connector process to access the configuration file that is readable only by root. 4. Deploying a configuration file containing the password (and replication password, if applicable) to all compute nodes, cinder nodes, and anywhere you would perform a volume attachment in your deployment. To refresh database information, all volumes should be detached and reattached. Because this remediation consists of deploying credentials in a root-readable-only file, it is not suitable for the use case of attaching a volume to a bare metal host. Thus, the Dell EMC ScaleIO/VxFlex OS storage backend for Cinder is *not recommended* for use with bare metal hosts. Note: The Ocata, Pike, Queens, and Rocky branches of OpenStack are in the Extended Maintenance phase. Point releases are no longer made from these branches and security patches are produced only on a reasonable effort basis. Patches for Queens and Rocky are provided as a courtesy. Patches for Ocata and Pike are not available. #### Patches #### Both cinder and os-brick must be patched. Documentation is provided as part of the cinder patch concerning the new configuration file that must be deployed to all compute nodes, cinder nodes, and anywhere you would perform a volume attachment in your deployment. Queens * cinder: https://review.opendev.org/733110 * os-brick: https://review.opendev.org/733104 Rocky * cinder: https://review.opendev.org/733109 * os-brick: https://review.opendev.org/733103 Stein * cinder: https://review.opendev.org/733108 * os-brick: https://review.opendev.org/733102 Train * cinder: https://review.opendev.org/733107 * os-brick: https://review.opendev.org/733100 Ussuri * cinder: https://review.opendev.org/733106 * os-brick: https://review.opendev.org/733099 Alternatively, point releases for Stein, Train, and Ussuri will be made as soon as possible. These will be: Stein: cinder 14.0.5, requires os-brick 2.8.5 Train: cinder 15.1.1, requires os-brick 2.10.3 Ussuri: cinder 16.0.1, requires os-brick 3.0.2 ### Contacts / References ### Author: Brian Rosmaita, Red Hat This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0086 Original LaunchPad Bug : https://bugs.launchpad.net/cinder/+bug/1823200 Mailing List : [Security] tag on openstack-discuss(a)lists.openstack.org OpenStack Security Project : https://launchpad.net/~openstack-ossg CVE: CVE-2020-10755

1 0

[all] OpenStack versions that can't practically be run with Python 3 ?
by Neil Jerram 03 Jun '20

03 Jun '20

Does anyone know the most recent OpenStack version that _can't_ easily be run with Python 3? I think the full answer to this may have to consider distro packaging, as well as the underlying code support. For example, I was just looking at switching an existing Queens setup, on Ubuntu Bionic, and it can't practically be done because all of the scripts - e.g. /usr/bin/nova-compute - have a hashbang line that says "python2". So IIUC Queens is a no for Python 3, at least in the Ubuntu packaging. Do you know if this is equally true for later versions than Queens? Or alternatively, if something systematic was done to address this problem in later releases? E.g. is there a global USE_PYTHON3 switch somewhere, or was the packaging for later releases changed to hardcode "python3" instead of "python2"? If so, when did that happen? Many thanks for any information around this! Best wishes, Neil

6 7

[keystone] Keystone PTG Schedule
by Nikolla, Kristi 03 Jun '20

03 Jun '20

Hi all, The Keystone team will be meeting Thursday and Friday 1300-1700 UTC. The schedule[0] can be found below and provides information on how to register and attend. In addition, I'm hoping to organize a team meetup Wednesday, Thursday or Friday on 1700UTC. Please fill in the doodle at [1]. More general PTG information can be found at [2]. [0]. https://etherpad.opendev.org/p/victoria-ptg-keystone [1]. https://doodle.com/poll/z7diwe6qyq4mbghe [2]. http://lists.openstack.org/pipermail/openstack-discuss/2020-May/015054.html

1 1

[cyborg][nova][neutron]Summaries of Smartnic support integration
by yumeng bao 03 Jun '20

03 Jun '20

Hi all, In cyborg pre-PTG meeting conducted last week[0],shaohe from Intel introduced SmartNIC support integrations,and we've reached some initial agreements: The workflow for a user to create a server with network acceleartor(accelerator is managed by Cyborg) is: 1. create a port with accelerator request specified into binding_profile field NOTE: Putting the accelerator request(device_profile) into binding_profile is one possible solution implemented in our POC. Another possible solution,adding a new attribute to port object for cyborg specific use instead of using binding_profile, is discussed in shanghai Summit[1]. This needs check with neutron team, which neutron team would suggest? 2.create a server with the port created Cyborg-nova-neutron integration workflow can be found on page 3 of the slide[2] presented in pre-PTG. And we also record the introduction! Please find the pre-PTG meeting vedio record in [3] and [4], they are the same, just for different region access. [0]http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014987.ht… [1]https://etherpad.opendev.org/p/Shanghai-Neutron-Cyborg-xproj [2]pre-PTG slides:https://docs.qq.com/slide/DVm5Jakx5ZlJXY3lw [3]pre-PTG vedio records in Youtube:https://www.youtube.com/watch?v=IN4haOK7sQg&feature=youtu.be [4]pre-PTG vedio records in Youku:http://v.youku.com/v_show/id_XNDY5MDA4NjM2NA==.html?x&sharefrom=iphon… Regards， Yumeng

5 7

[nova][neutron][cyborg][ptg] Nova changing from Jitsi to Zoom
by Balázs Gibizer 03 Jun '20

03 Jun '20

Hi, As multiple people reported problem with Jitsi from PRC [1][2] the Nova team is switching back to Zoom. We will use the Juno Zoom room [3] during this week. Cheers, gibi [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015207.html [2] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.… [3] https://www.openstack.org/ptg/rooms/juno

1 0

[all] Week Out PTG Details & Registration Reminder
by Kendall Nelson 02 Jun '20

02 Jun '20

Hello Everyone! We are so excited to see you next week at our first virtual PTG! Below are all the details you need to have a fun and successful event. First and foremost: PLEASE REGISTER; https://virtualptgjune2020.eventbrite.com/ If you don't register for the event, we have no way of sending you information about the event, specifically the passwords that we will have set on the zoom rooms. Registration is free. =Final Schedule= The final schedule for the event is available here[1] and in the PTGBot[2]. =Tooling & Passwords= For each virtual PTG meeting room, we will provide an official Zoom videoconference room, which will be reused by various groups across the day. Please make sure to leave the room at the end of your team meeting! We will be setting passwords on the rooms to prevent vandalism/harassment, and we will send those out 24 hours before the start of the event. OpenDev's Jitsi Meet instance is also available at https://meetpad.opendev.org as an alternative tooling option to create team-specific meetings. This is more experimental and may not work as well for larger groups, but has the extra benefit of including etherpad integration (the videoconference doubles as an etherpad document, avoiding jumping between windows). PTGBot can be used to publish the chosen meeting URL if you decide to not use the official Zoom one. The OpenDev Sysadmins can be reached in the #opendev IRC channel if any problems arise. We recommend you try out Zoom and Meetpad ahead of the PTG to solve audio/video issues. =IRC= The main form of synchronous communication between attendees during the PTG is on IRC. If you are not on IRC, learn how to get started here [3]. The main PTG IRC channel is #openstack-ptg on Freenode, and it's used to interact with the PTGbot. The OpenStack Foundation (OSF) staff will be present to help answer questions. =PTGbot= The PTGbot[2] is an open source tool that PTG room moderators use to surface what's currently happening at the event. Room moderators will send messages to the bot via IRC, and from that information the bot publishes a webpage with several sections of information: - The discussion topics currently discussed in the room ("now") - An indicative set of discussion topics coming up next ("next") - The schedule for the day with available extra slots you can book Learn more about the PTGbot via the documentation here [4]. =Help Desk= We are here to help! If you have any questions during the event week, we will have a dedicated Zoom room where an OSF staff member will be available to answer your event related questions. If a staff member is not there to help, you can always reach someone at ptg(a)openstack.org or on IRC in the #openstack-ptg channel. =Feedback= We have created an etherpad[5] to collect all of your feedback throughout the event. Please add your thoughts so we can continue improving our virtual events! =Virtual Event Best Practices= Check out our list of virtual event best practices[6] prior to the event to help make the most of your time at the PTG. =Code of Conduct= The PTG is for everyone. We have zero tolerance for harassment and other violations of the OSF Community Code of Conduct. Before the PTG begins, please review the Code of Conduct[7] and know how to report an issue. -The Kendalls (diablo_rojo & wendallkaters) [1] Schedule: https://www.openstack.org/ptg#tab_schedule [2] Live PTGBot: http://ptg.openstack.org/ptg.html [3] IRC Setup: https://docs.openstack.org/contributors/common/irc.html [4] PTGBot Documentation: https://github.com/openstack/ptgbot/blob/master/README.rst [5] Feedback Etherpad: https://etherpad.opendev.org/p/June2020-PTG-Feedback [6] PTG Best Practices: https://etherpad.opendev.org/p/virtual-ptg-best-practices [7] Code of Conduct: https://www.openstack.org/legal/community-code-of-conduct/

11 18

[cinder] virtual happy hour on Thursday 4 June
by Brian Rosmaita 02 Jun '20

02 Jun '20

The People have spoken and they have said that Thursday is the day we should hold the virtual happy hour. It's therefore scheduled for 15:30 UTC in the "Diablo room" (which is what I'm now calling my BlueJeans room): https://bluejeans.com/3228528973 This is an opportunity for us to have some informal virtual face-to-face time. Since the virtual drinks are unlimited, everyone is welcome, even if you don't contribute to cinder in the course of your normal work activities. The event will *not* be recorded :) See you there! brian

1 0

[tripleo] PTG day 3
by Emilien Macchi 02 Jun '20

02 Jun '20

Hi Folks For day 3, we'll stay on Zoom, it seems like the best option for our group so far. The agenda looks like it: 13:00 UTC Topic: Speeding up deployments, updates and upgrades Presenter: Jesse Pretorius (odyssey4me), Sofer Athlan (chem) 13:30 UTC Topic: Ceph requirements Presenter: fmount, fultonj, gfidente 14:00 UTC Topic: Running validations from within a container Presenter: cjeanneret (Tengu) 14:30 UTC Topic: Auto --limit scale-up of Compute nodes Presenter: Luke Short (ekultails) 15:00 UTC Topic: TripleO usability enhancements Presenter: Wes Hayutin 15:30 UTC Topic: Improvements in TLS Everywhere/ CI Presenter: rlandy, alee 16:00 UTC Topic: Container Security in TripleO Presenter: Grzegorz Grasza (xek), alee 16:30 UTC free slot Since we have a free slot, feel free to propose any new topic otherwise we'll finish earlier (could also be appreciated, specially for folks in EMEA/APAC). Thanks and see you tomorrow! -- Emilien Macchi

1 0

[diversity] Hour of Healing
by Amy Marrich 02 Jun '20

02 Jun '20

The OSF Diversity and Inclusion Working Group recognizes that this is a trying time for our communities and colleagues. We would like to invite you to 'An Hour of Healing' on Thursday (June 4th at 17:30 - 18:30 UTC) where you can talk to others in a safe place. We invite you to use this time to express your feelings, or to just be able to talk to others without being judged. This session will adhere to the OSF Code of Conduct <https://www.openstack.org/legal/community-code-of-conduct/>and zero tolerance for harassment policy, which means we will not be judging or condemning others (individuals or groups) inside OR outside of our immediate community. We will come together to heal, in mutually respectful dialogue, keeping in mind that while there are many different individual viewpoints, we all share pain collectively and can heal together. We will be using https://meetpad.opendev.org/PTGDiversityAndInclusion for this gathering. The OSF Diversity and Inclusion WG

1 0