From fandree at amazon.com Wed Apr 10 14:29:31 2019 From: fandree at amazon.com (Florescu, Andreea) Date: Wed, 10 Apr 2019 14:29:31 +0000 Subject: [Rust-VMM] License for kvm-ioctls & other crates Message-ID: <1554906570151.42298@amazon.com> Hey, As per our discussion on this issue https://github.com/rust-vmm/community/issues/14 but also from our last week sync call, we will update the license of existing crates to MIT and Apache-v.2.0 to accommodate both Qemu usecase and Firecracker. I am currently trying to publish version v0.1.0 of the kvm-ioctls crate to crates.io and before doing so I wanted to also update the license. I lack experience in the licensing domain so I am here to ask (pretty please) if anyone can submit a PR with the updated license or otherwise point me to relevant resources so I can update it myself. I am aiming for publishing the crate either at the end of this week or beginning of the next one. Any takers? Thanks, Andreea Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuel.ortiz at intel.com Wed Apr 10 14:37:41 2019 From: samuel.ortiz at intel.com (Samuel Ortiz) Date: Wed, 10 Apr 2019 16:37:41 +0200 Subject: [Rust-VMM] License for kvm-ioctls & other crates In-Reply-To: <1554906570151.42298@amazon.com> References: <1554906570151.42298@amazon.com> Message-ID: <20190410143741.GB27328@caravaggio> Hi Andreea, Let me send a PR. Cheers, Samuel. On Wed, Apr 10, 2019 at 02:29:31PM +0000, Florescu, Andreea wrote: > Hey, > > > As per our discussion on this issue https://github.com/rust-vmm/community/issues/14 but also from our last week sync call, we will update the license of existing crates to MIT and Apache-v.2.0 to accommodate both Qemu usecase and Firecracker. > > > I am currently trying to publish version v0.1.0 of the kvm-ioctls crate to crates.io and before doing so I wanted to also update the license. I lack experience in the licensing domain so I am here to ask (pretty please) if anyone can submit a PR with the updated license or otherwise point me to relevant resources so I can update it myself. I am aiming for publishing the crate either at the end of this week or beginning of the next one. Any takers? > > > Thanks, > > Andreea > > > > Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From claire at openstack.org Wed Apr 10 16:08:48 2019 From: claire at openstack.org (Claire Massey) Date: Wed, 10 Apr 2019 11:08:48 -0500 Subject: [Rust-VMM] Denver PTG Details - Get Ready Message-ID: Hi everyone, It’s time to prepare for the Project Teams Gathering (PTG) that’s co-located with the Open Infrastructure Summit the week of April 29. Both events will take place at the Colorado Convention Center in downtown Denver. The Rust-VMM community has a dedicated space reserved at the PTG all day, Thurs/Fri, May 2-3. *ACTION*, we need to start firming up the agenda with discussion topics - https://etherpad.openstack.org/p/rust-vmm-2019-ptg-denver. If you have not yet registered to attend, please make sure you do before arriving onsite - https://openinfrasummitandptgdenver.eventbrite.com. The hotel block at the Hyatt Regency still has rooms available, but you must book this week - https://www.hyatt.com/en-US/group-booking/DENCC/G-FNTE. The Rust-VMM team photo is scheduled for Thursday, May 2, at 4:10pm. You can view the full list of participating projects on the PTG schedule - https://www.openstack.org/ptg#tab_schedule. Make sure to check out the Open Infrastructure Summit schedule too - https://www.openstack.org/summit/denver-2019. Let me know if you have any questions. It’s going to be a fun and productive week! See you soon, Claire From samuel.ortiz at intel.com Thu Apr 11 08:25:54 2019 From: samuel.ortiz at intel.com (Samuel Ortiz) Date: Thu, 11 Apr 2019 10:25:54 +0200 Subject: [Rust-VMM] VMM related bindings Message-ID: <20190411082554.GE27328@caravaggio> All, In several cases, we need to generate kernel bindings for some of our crates (kvm, vhost, virtio), through rust-bindgen. There's been discussions about whether we should have those bindings as part of the related crate (e.g. a virtio/src/bindings.rs module for the virtio bindings) or as a separate crate (virtio-bindings, vhost-bindings, kvm-bindings). We (Andreea and myself) believe it makes more sense to have them as separate crates, and clearly distinguish generated bindings from actual code consuming them. It generates a few more repos, but that's a minor burden after all. Does anyone have strong opinions against that pattern? Cheers, Samuel. --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From pbonzini at redhat.com Thu Apr 11 09:31:48 2019 From: pbonzini at redhat.com (Paolo Bonzini) Date: Thu, 11 Apr 2019 11:31:48 +0200 Subject: [Rust-VMM] VMM related bindings In-Reply-To: <20190411082554.GE27328@caravaggio> References: <20190411082554.GE27328@caravaggio> Message-ID: <772d2015-47c1-0731-f548-d4f2feadc21c@redhat.com> On 11/04/19 10:25, Samuel Ortiz wrote: > In several cases, we need to generate kernel bindings for some of our > crates (kvm, vhost, virtio), through rust-bindgen. > There's been discussions about whether we should have those bindings as > part of the related crate (e.g. a virtio/src/bindings.rs module for the > virtio bindings) or as a separate crate (virtio-bindings, > vhost-bindings, kvm-bindings). > > We (Andreea and myself) believe it makes more sense to have them as > separate crates, and clearly distinguish generated bindings from actual > code consuming them. It generates a few more repos, but that's a minor > burden after all. > > Does anyone have strong opinions against that pattern? No objections for kvm-bindings and vhost-bindings; however, for virtio and vhost-user I would just write everything by hand (or clean up bindgen-generated code to actually be readable, and include it in the same crate) since there is a public specification rather than "/usr/include is the spec". Paolo From zachr at google.com Thu Apr 11 17:37:42 2019 From: zachr at google.com (Zach Reizner) Date: Thu, 11 Apr 2019 10:37:42 -0700 Subject: [Rust-VMM] VMM related bindings In-Reply-To: <772d2015-47c1-0731-f548-d4f2feadc21c@redhat.com> References: <20190411082554.GE27328@caravaggio> <772d2015-47c1-0731-f548-d4f2feadc21c@redhat.com> Message-ID: On Thu, Apr 11, 2019 at 2:34 AM Paolo Bonzini wrote: > On 11/04/19 10:25, Samuel Ortiz wrote: > > In several cases, we need to generate kernel bindings for some of our > > crates (kvm, vhost, virtio), through rust-bindgen. > > There's been discussions about whether we should have those bindings as > > part of the related crate (e.g. a virtio/src/bindings.rs module for the > > virtio bindings) or as a separate crate (virtio-bindings, > > vhost-bindings, kvm-bindings). > > > > We (Andreea and myself) believe it makes more sense to have them as > > separate crates, and clearly distinguish generated bindings from actual > > code consuming them. It generates a few more repos, but that's a minor > > burden after all. > > > > Does anyone have strong opinions against that pattern? > That's how we did it for `kvm-sys` and `kvm` inside of crosvm. I think the separation makes a lot of sense. > > No objections for kvm-bindings and vhost-bindings; however, for virtio > and vhost-user I would just write everything by hand (or clean up > bindgen-generated code to actually be readable, and include it in the > same crate) since there is a public specification rather than > "/usr/include is the spec". > > Paolo > > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgilbert at redhat.com Thu Apr 11 17:42:17 2019 From: dgilbert at redhat.com (Dr. David Alan Gilbert) Date: Thu, 11 Apr 2019 18:42:17 +0100 Subject: [Rust-VMM] VMM related bindings In-Reply-To: References: <20190411082554.GE27328@caravaggio> <772d2015-47c1-0731-f548-d4f2feadc21c@redhat.com> Message-ID: <20190411174216.GB2770@work-vm> * Zach Reizner (zachr at google.com) wrote: > On Thu, Apr 11, 2019 at 2:34 AM Paolo Bonzini wrote: > > > On 11/04/19 10:25, Samuel Ortiz wrote: > > > In several cases, we need to generate kernel bindings for some of our > > > crates (kvm, vhost, virtio), through rust-bindgen. > > > There's been discussions about whether we should have those bindings as > > > part of the related crate (e.g. a virtio/src/bindings.rs module for the > > > virtio bindings) or as a separate crate (virtio-bindings, > > > vhost-bindings, kvm-bindings). > > > > > > We (Andreea and myself) believe it makes more sense to have them as > > > separate crates, and clearly distinguish generated bindings from actual > > > code consuming them. It generates a few more repos, but that's a minor > > > burden after all. > > > > > > Does anyone have strong opinions against that pattern? > > > That's how we did it for `kvm-sys` and `kvm` inside of crosvm. I think the > separation makes a lot of sense. Yes, I'd like to see the separation so we can think more easily about how to use virtio devices in external programs (i.e. vhost-user processes). Dave > > > > No objections for kvm-bindings and vhost-bindings; however, for virtio > > and vhost-user I would just write everything by hand (or clean up > > bindgen-generated code to actually be readable, and include it in the > > same crate) since there is a public specification rather than > > "/usr/include is the spec". > > > > Paolo > > > > _______________________________________________ > > Rust-vmm mailing list > > Rust-vmm at lists.opendev.org > > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm > > > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm -- Dr. David Alan Gilbert / dgilbert at redhat.com / Manchester, UK From liuj97 at gmail.com Fri Apr 12 09:47:13 2019 From: liuj97 at gmail.com (Liu Jiang) Date: Fri, 12 Apr 2019 17:47:13 +0800 Subject: [Rust-VMM] VMM related bindings In-Reply-To: <772d2015-47c1-0731-f548-d4f2feadc21c@redhat.com> References: <20190411082554.GE27328@caravaggio> <772d2015-47c1-0731-f548-d4f2feadc21c@redhat.com> Message-ID: > On Apr 11, 2019, at 5:31 PM, Paolo Bonzini wrote: > > On 11/04/19 10:25, Samuel Ortiz wrote: >> In several cases, we need to generate kernel bindings for some of our >> crates (kvm, vhost, virtio), through rust-bindgen. >> There's been discussions about whether we should have those bindings as >> part of the related crate (e.g. a virtio/src/bindings.rs module for the >> virtio bindings) or as a separate crate (virtio-bindings, >> vhost-bindings, kvm-bindings). >> >> We (Andreea and myself) believe it makes more sense to have them as >> separate crates, and clearly distinguish generated bindings from actual >> code consuming them. It generates a few more repos, but that's a minor >> burden after all. >> >> Does anyone have strong opinions against that pattern? > > No objections for kvm-bindings and vhost-bindings; however, for virtio > and vhost-user I would just write everything by hand (or clean up > bindgen-generated code to actually be readable, and include it in the > same crate) since there is a public specification rather than > "/usr/include is the spec”. For the vhost_gen case, I have tried to include the vhost_gen code into the vhost crate, it does generate better code and simplify the maintenance. > > Paolo > > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm From fandree at amazon.com Fri Apr 12 10:09:27 2019 From: fandree at amazon.com (Florescu, Andreea) Date: Fri, 12 Apr 2019 10:09:27 +0000 Subject: [Rust-VMM] PR needing review Message-ID: <1555063766907.93218@amazon.com> Hey everyone, There are a bunch of PRs opened that would need some attention. Could you please take some time to review them? Also, if you are one of the people that have submitted a PR, please take some time to respond to comments and update your PRs based on the reviews. In kvm-ioctls: - helper functions for altering zero sized array structures (like kvm_cpuid2, kvm_msrs): https://github.com/rust-vmm/kvm-ioctls/pull/6 - high level documentation for kvm-ioctls (with an x86 example of usage): https://github.com/rust-vmm/kvm-ioctls/pull/26 - helper function for creating CpuId from kvm_entries: https://github.com/rust-vmm/kvm-ioctls/pull/29 In vmm-sys-utils: - Initial PR that adds helpers (this is blocking for adding new crates depending on sys-util) https://github.com/rust-vmm/vmm-sys-util/pull/1 In vhost: - Inital PR that adds the vhost code from Firecracker: https://github.com/rust-vmm/vhost/pull/2 In vm-memory: - Windows Support: https://github.com/rust-vmm/vm-memory/pull/10 If you want to be a reviewer for any of them please add yourself as a reviewer. If you don't have permission to do so let me know and I'll fix it. This list contains all PRs that don't have at least 2 reviewers already. I believe we agreed that the first PR in a repository (the one that essentially adds a lot of code) will be reviewed by at least 3 people coming from 3 different projects to ensure that the crate is usable by all interested parties. For all the others we can fall back to 2 reviews. What I am trying to avoid here is having same people reviewing all PRs because: 1. It takes some time to do reviews 2. Different people might have different views & find different problems in PRs. Thanks, Andreea Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fandree at amazon.com Wed Apr 17 08:41:25 2019 From: fandree at amazon.com (Florescu, Andreea) Date: Wed, 17 Apr 2019 08:41:25 +0000 Subject: [Rust-VMM] kvm-ioctls on crates.io Message-ID: <1555490484963.95304@amazon.com> Hey everyone, Quick update on kvm-ioctls. I just published v0.1.0 to crates.io [1]. The list of ioctls is not complete (not all ioctls used by CrosVM are added, but that's WIP) [2]. We are also still working on ARM support [3]. Adding coverage test is not really straightforward at the moment and we are refining the unit tests and code examples. For the full list of TODOs, please check the corresponding issues [4]. Regards, Andreea [1] https://crates.io/crates/kvm-ioctls [2] https://github.com/rust-vmm/kvm-ioctls/issues/11 [3] https://github.com/rust-vmm/kvm-ioctls/issues/8 [2] https://github.com/rust-vmm/kvm-ioctls/issues Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. -------------- next part -------------- An HTML attachment was scrubbed... URL: From drjones at redhat.com Wed Apr 17 12:43:03 2019 From: drjones at redhat.com (Andrew Jones) Date: Wed, 17 Apr 2019 14:43:03 +0200 Subject: [Rust-VMM] kvm-ioctls on crates.io In-Reply-To: <1555490484963.95304@amazon.com> References: <1555490484963.95304@amazon.com> Message-ID: <20190417124303.q56cdwl4nrjqgszd@kamzik.brq.redhat.com> On Wed, Apr 17, 2019 at 08:41:25AM +0000, Florescu, Andreea wrote: > Hey everyone, > > > Quick update on kvm-ioctls. I just published v0.1.0 to crates.io [1]. > > The list of ioctls is not complete (not all ioctls used by CrosVM are added, but that's WIP) [2]. > > We are also still working on ARM support [3]. Adding coverage test is not really straightforward at the moment and we are refining the unit tests and code examples. Is anyone signed up to do the ARM run_code and/or other ARM unit tests? If not, then I'll take a stab at it. Thanks, drew > > > For the full list of TODOs, please check the corresponding issues [4]. > > > Regards, > > Andreea > > > [1] https://crates.io/crates/kvm-ioctls > > [2] https://github.com/rust-vmm/kvm-ioctls/issues/11 > > [3] https://github.com/rust-vmm/kvm-ioctls/issues/8 > > [2] https://github.com/rust-vmm/kvm-ioctls/issues > > > > Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm From fandree at amazon.com Wed Apr 17 15:33:13 2019 From: fandree at amazon.com (Florescu, Andreea) Date: Wed, 17 Apr 2019 15:33:13 +0000 Subject: [Rust-VMM] kvm-ioctls on crates.io In-Reply-To: <20190417124303.q56cdwl4nrjqgszd@kamzik.brq.redhat.com> References: <1555490484963.95304@amazon.com>, <20190417124303.q56cdwl4nrjqgszd@kamzik.brq.redhat.com> Message-ID: <1555515192261.38275@amazon.com> Hey Drew, Feel fee to take the issues. Can you also comment on the issues or assign them to yourself? Andreea ________________________________________ From: Andrew Jones Sent: Wednesday, April 17, 2019 3:43 PM To: Florescu, Andreea Cc: rust-vmm ML Subject: Re: [Rust-VMM] kvm-ioctls on crates.io On Wed, Apr 17, 2019 at 08:41:25AM +0000, Florescu, Andreea wrote: > Hey everyone, > > > Quick update on kvm-ioctls. I just published v0.1.0 to crates.io [1]. > > The list of ioctls is not complete (not all ioctls used by CrosVM are added, but that's WIP) [2]. > > We are also still working on ARM support [3]. Adding coverage test is not really straightforward at the moment and we are refining the unit tests and code examples. Is anyone signed up to do the ARM run_code and/or other ARM unit tests? If not, then I'll take a stab at it. Thanks, drew > > > For the full list of TODOs, please check the corresponding issues [4]. > > > Regards, > > Andreea > > > [1] https://crates.io/crates/kvm-ioctls > > [2] https://github.com/rust-vmm/kvm-ioctls/issues/11 > > [3] https://github.com/rust-vmm/kvm-ioctls/issues/8 > > [2] https://github.com/rust-vmm/kvm-ioctls/issues > > > > Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. From seriorga at amazon.com Tue Apr 23 06:22:58 2019 From: seriorga at amazon.com (Iorga, Serban) Date: Tue, 23 Apr 2019 06:22:58 +0000 Subject: [Rust-VMM] [RFC] rust-vmm/common crate Message-ID: <1556000577362.3279@amazon.com> Hello everyone, I was working on implementing a generic solution for dealing with kvm structures that contain zero-sized arrays as part of the kvm-ioctls crate. This is the PR: https://github.com/rust-vmm/kvm-ioctls/pull/6 and there has been a suggestion there to have this code in a base rust-vmm crate since the issue is quite common. I wanted to get your input on creating a rust-vmm/common crate for this. Would anyone have any concerns about this approach ? Thanks, Serban Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jenny.mankin at crowdstrike.com Tue Apr 23 20:25:10 2019 From: jenny.mankin at crowdstrike.com (Jenny Mankin) Date: Tue, 23 Apr 2019 20:25:10 +0000 Subject: [Rust-VMM] Request for VCPU Create PR Reveiw Message-ID: <9bb89c76c34143ee8c96c7e16c9b3201@casmbox05.crowdstrike.sys> To anyone interested, the VCPU crate, which provides hypervisor-agnostic abstractions for VCPU functionality, is up for review here: https://github.com/rust-vmm/vmm-vcpu/pull/3. Thanks for any feedback! Jenny -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4901 bytes Desc: not available URL: From sebastien.boeuf at intel.com Tue Apr 23 23:43:54 2019 From: sebastien.boeuf at intel.com (Boeuf, Sebastien) Date: Tue, 23 Apr 2019 23:43:54 +0000 Subject: [Rust-VMM] [RFC] rust-vmm/common crate In-Reply-To: <1556000577362.3279@amazon.com> References: <1556000577362.3279@amazon.com> Message-ID: <60ced617accf28f567b9a2571c6c101fa334f5ab.camel@intel.com> Hi Serban, On Tue, 2019-04-23 at 06:22 +0000, Iorga, Serban wrote: Hello everyone, I was working on implementing a generic solution for dealing with kvm structures that contain zero-sized arrays as part of the kvm-ioctls crate. This is the PR: https://github.com/rust-vmm/kvm-ioctls/pull/6 and there has been a suggestion there to have this code in a base rust-vmm crate since the issue is quite common. I wanted to get your input on creating a rust-vmm/common crate for this. Would anyone have any concerns about this approach ? +1 from me. Might be worth taking a look at existing crates on crates.io first. "common" sounds very generic, I would lean towards something like "rust-common" instead. Thanks, Sebastien Thanks, Serban Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. _______________________________________________ Rust-vmm mailing list Rust-vmm at lists.opendev.org http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm -------------- next part -------------- An HTML attachment was scrubbed... URL: From thierry at openstack.org Wed Apr 24 11:18:25 2019 From: thierry at openstack.org (Thierry Carrez) Date: Wed, 24 Apr 2019 13:18:25 +0200 Subject: [Rust-VMM] [ptg] ptgbot HOWTO Message-ID: <90a0bc65-e6c6-7226-4fb5-4d25dcea9fbb@openstack.org> Hi everyone, In a few days, some contributor teams will meet in Denver for the 5th Project Teams Gathering. The event is organized around separate 'tracks' (generally tied to a specific team/group). Topics of discussion are loosely scheduled in those tracks, based on the needs of the attendance. This allows to maximize attendee productivity, but the downside is that it can make the event a bit confusing to navigate. To mitigate that issue, we are using an IRC bot to expose what's happening currently at the event at the following page: http://ptg.openstack.org/ptg.html It is therefore useful to have a volunteer in each room who makes use of the PTG bot to communicate what's happening. This is done by joining the #openstack-ptg IRC channel on Freenode and voicing commands to the bot. Usage of the bot is of course optional, but in past editions it was really useful to help attendees successfully navigate this dynamic event. How to keep attendees informed of what's being discussed in your room --------------------------------------------------------------------- To indicate what's currently being discussed, you will use the track name hashtag (found in the "Scheduled tracks" section on the above page), with the 'now' command: #TRACK now Example: #swift now brainstorming improvements to the ring You can also mention other track names to make sure to get people attention when the topic is transverse: #ops-meetup now discussing #cinder pain points There can only be one 'now' entry for a given track at a time. To indicate what will be discussed next, you can enter one or more 'next' commands: #TRACK next Example: #api-sig next at 2pm we'll be discussing pagination woes Note that in order to keep content current, entering a new 'now' command for a track will automatically erase any 'next' entry for that track. Finally, if you want to clear all 'now' and 'next' entries for your track, you can issue the 'clean' command: #TRACK clean Example: #ironic clean How to book reservable rooms ---------------------------- Like at every PTG, in Denver we will have additional reservable space for extra un-scheduled discussions. Two of those rooms (Ballroom 4 and Room 112) are equipped with a projector, so if your discussion would benefit from projection, you can also book time there. Finally, some of the smaller teams do not have any pre-scheduled space, and will solely be relying on this feature to book the time that makes the most sense for them. Those teams are the OpenStack release management team (#release-management) and requirements team (#requirements), the Extended Maintenance SIG (#extended-maint-sig), the Security SIG (#security-sig), the Bare Metal SIG (#baremetal-sig) and the Interoperability working group (#interop-wg). The PTG bot page shows which track is allocated to which room, as well as available reservable space, with a slot code (room name - time slot) that you can use to issue a 'book' command to the PTG bot: #TRACK book Example: #release-management book Room 112-ThuA1 Any track can book additional space and time using this system. All slots are 1h45-long. If your topic of discussion does not fall into an existing track, it is easy to add a track on the fly. Just ask PTG bot admins (ttx, diablo_rojo...) on the channel to create a track for you (which they can do by getting op rights and issuing a ~add command). For more information on the bot commands, please see: https://opendev.org/openstack/ptgbot/src/branch/master/README.rst Let me know if you have any additional questions. -- Thierry Carrez (ttx)