[openstack-dev] New OpenStack Bug Smash
Hi all, We want to kick off the next OpenStack bug smash and it targets Nov 30 - Dec 2 (Wed - Fri) at Shenzhen in China, which was voted in the last bug smash at Hangzhou, for the next Ocata release. The release schedule and Thanksgiving day are considered for the date. Do any of you want to co-organize the bug smash in the other city simultaneously, and prepare together? Please let us know. Thanks. -- Shane __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] OpenStack: Happy 6th Birthday:)
__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Invitation to join Hangzhou Bug Smash
Anita, sorry about replying to you slowly. Because we are a committee from a couple of companies, and need discussion, which causes slowness. I am not the only decision maker. Thanks Anita;) Regards. -- Shane -Original Message- From: Anita Kuno [mailto:ante...@anteaya.info] Sent: Friday, June 17, 2016 7:18 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Invitation to join Hangzhou Bug Smash On 06/16/2016 07:03 PM, Matt Riedemann wrote: > On 6/14/2016 9:03 PM, Anita Kuno wrote: >> >> I'll reply in private first because I am a core reviewer on the >> project-config repo, which was not mentioned in your list but you >> might consider useful to you at the bug smash nonetheless. >> >> Let me know if you would like me to attend and I'll reply in public, >> if not no worries. >> >> Thank you, >> Anita >> >> _ >> _ >> >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > Busted! > Yeah, I know. I was tired and wasn't paying attention to the to: field. Good thing I pretend like everything I say in private is public anyway. Shane and folks are still welcome to tell me no, I didn't want them to feel obliged and I still don't. Even if I fail at private. Thanks Matt :) Anita. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [release] Invitation to join Hangzhou Bug Smash
That is what I want. It is better to map the day into the release schedule in the future. Can we make it since Otaca? And everyone is encouraged. Regards. -- Shane -Original Message- From: Rochelle Grober [mailto:rochelle.gro...@huawei.com] Sent: Wednesday, June 15, 2016 9:53 AM To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage questions) Cc: Zhuangzhen; Anni Lai; Liang, Maggie Subject: Re: [openstack-dev] [release] Invitation to join Hangzhou Bug Smash Perhaps the right way to schedule these bug smashes is to do it at the same time as the release scheduling is determined. Decide on a fixed time within the release cycle (it's been just after M3/feature freeze a few times) and when the schedule is put together, the bugsmash is part of the schedule. By having the release schedule determine the week of the bug smash, we have a long timeline to get the planning done and don't have to worry about development schedule conflicts. --Rocky -Original Message- From: Daniel P. Berrange [mailto:berra...@redhat.com] Sent: Monday, June 13, 2016 2:46 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Zhuangzhen; Anni Lai; Liang, Maggie Subject: Re: [openstack-dev] Invitation to join Hangzhou Bug Smash On Mon, Jun 13, 2016 at 08:06:50AM +, Wang, Shane wrote: > Hi, OpenStackers, > > As you know, Huawei, Intel and CESI are hosting the 4th China OpenStack Bug > Smash at Hangzhou, China. > The 1st China Bug Smash was at Shanghai, the 2nd was at Xi'an, and the 3rd > was at Chengdu. > > We are constructing the etherpad page for registration, and the date > will be around July 11 (probably July 6 - 8, but to be determined very soon). The newton-2 milestone release date is July 15th, so you certainly *don't* want the event during that week. IOW, the 8th July is the latest you should schedule it - don't let it slip into the next week starting July 11th, as during the week of the n-2 milestone focus of the teams will be almost exclusively on prep for that release, to the detriment of any bug smash event. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Invitation to join Hangzhou Bug Smash
OK, Got you, Sean, will let you know if there is any change. Regards. -- Shane -Original Message- From: Sean McGinnis [mailto:sean.mcgin...@gmx.com] Sent: Tuesday, June 14, 2016 3:10 AM To: OpenStack Development Mailing List (not for usage questions) Cc: Zhuangzhen; anni@huawei.com; Liang, Maggie Subject: Re: [openstack-dev] Invitation to join Hangzhou Bug Smash On Mon, Jun 13, 2016 at 08:06:50AM +, Wang, Shane wrote: > Hi, OpenStackers, > > As you know, Huawei, Intel and CESI are hosting the 4th China OpenStack Bug > Smash at Hangzhou, China. > The 1st China Bug Smash was at Shanghai, the 2nd was at Xi'an, and the 3rd > was at Chengdu. > > We are constructing the etherpad page for registration, and the date will be > around July 11 (probably July 6 - 8, but to be determined very soon). > > The China teams will still focus on Neutron, Nova, Cinder, Heat, Magnum, > Rally, Ironic, Dragonflow and Watcher, etc. projects, so need developers to > join and fix bugs as many as possible, and cores to be on site to moderate > the code changes and merges. Welcome to the smash mash at Hangzhou - > http://www.chinahighlights.com/hangzhou/attraction/. > > Good news is still that for the first two cores who are from those above > projects and respond to this invitation in my email inbox and copy the CC > list, the sponsors are pleased to sponsor your international travel, > including flight and hotel. Please simply reply to me. > > Best regards, > -- > China OpenStack Bug Smash Team > > Glad to see this continuing! I would like to participate in this event, but that current timeframe would conflict with OpenStack Days India. If that does end up being the final date, I will try to be online as much as possible to help with reviews. If it does end up being moved to another date, I would be interested in participating in person to help mentor. Thanks, Sean __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Invitation to join Hangzhou Bug Smash
Yes, sure, we encourage every company to host bug smash at its city globally, as the company wants, but should align with us. Actually last time it followed the model, for example, we have SUSE to host at Germany, and in the last minute we have Taiwan. For Hangzhou in PRC, we are also calling for sponsorship to work with us. So in the final accouchement, you will see company names. Regards. -- Shane -Original Message- From: Tom Fifield [mailto:t...@openstack.org] Sent: Monday, June 13, 2016 5:36 PM To: OpenStack Development Mailing List (not for usage questions) Cc: anni@huawei.com; Liang, Maggie Subject: Re: [openstack-dev] Invitation to join Hangzhou Bug Smash Hi, Are there plans to follow the OpenStack events policy this time? eg Commercial participants should have equal opportunity to sponsor and support the activity. When the number of sponsorships is limited, a best practice is to publish a sponsorship prospectus online on a date known in advance with sponsorships filled on a "first to sign" basis. Regards, Tom On 13/06/16 16:06, Wang, Shane wrote: > Hi, OpenStackers, > As you know, Huawei, Intel and CESI are hosting the 4th China > OpenStack Bug Smash at Hangzhou, China. > The 1st China Bug Smash was at Shanghai, the 2nd was at Xi'an, and the > 3rd was at Chengdu. > We are constructing the etherpad page for registration, and the date > will be around July 11 (probably July 6 - 8, but to be determined very > soon). > The China teams will still focus on Neutron, Nova, Cinder, Heat, > Magnum, Rally, Ironic, Dragonflow and Watcher, etc. projects, so need > developers to join and fix bugs as many as possible, and cores to be > on site to moderate the code changes and merges. Welcome to the smash > mash at Hangzhou -_http://www.chinahighlights.com/hangzhou/attraction/_. > Good news is still that for the first two cores who are from those > above projects and respond to this invitation in my email inbox and > copy the CC list, the sponsors are pleased to sponsor your > international travel, including flight and hotel. Please simply reply to me. > Best regards, > -- > China OpenStack Bug Smash Team > > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Invitation to join Hangzhou Bug Smash
I heard that from Doug, the best timing is before July 11. Thank you for the reminder. Regards. -- Shane -Original Message- From: Daniel P. Berrange [mailto:berra...@redhat.com] Sent: Monday, June 13, 2016 5:46 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Zhuangzhen; anni@huawei.com; Liang, Maggie Subject: Re: [openstack-dev] Invitation to join Hangzhou Bug Smash On Mon, Jun 13, 2016 at 08:06:50AM +, Wang, Shane wrote: > Hi, OpenStackers, > > As you know, Huawei, Intel and CESI are hosting the 4th China OpenStack Bug > Smash at Hangzhou, China. > The 1st China Bug Smash was at Shanghai, the 2nd was at Xi'an, and the 3rd > was at Chengdu. > > We are constructing the etherpad page for registration, and the date > will be around July 11 (probably July 6 - 8, but to be determined very soon). The newton-2 milestone release date is July 15th, so you certainly *don't* want the event during that week. IOW, the 8th July is the latest you should schedule it - don't let it slip into the next week starting July 11th, as during the week of the n-2 milestone focus of the teams will be almost exclusively on prep for that release, to the detriment of any bug smash event. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Invitation to join Hangzhou Bug Smash
Welcome to join us, Duncan. Regards. -- Shane From: Duncan Thomas [mailto:duncan.tho...@gmail.com] Sent: Monday, June 13, 2016 4:14 PM To: OpenStack Development Mailing List (not for usage questions) Cc: Zhuangzhen; anni@huawei.com; Liang, Maggie Subject: Re: [openstack-dev] Invitation to join Hangzhou Bug Smash Hi I would, once again, love to attend. If you find that other cores apply and you'd rather have a new face, I would be very understanding of the situation. Regards -- Duncan Thomas On 13 June 2016 at 11:06, Wang, Shane <shane.w...@intel.com<mailto:shane.w...@intel.com>> wrote: Hi, OpenStackers, As you know, Huawei, Intel and CESI are hosting the 4th China OpenStack Bug Smash at Hangzhou, China. The 1st China Bug Smash was at Shanghai, the 2nd was at Xi’an, and the 3rd was at Chengdu. We are constructing the etherpad page for registration, and the date will be around July 11 (probably July 6 – 8, but to be determined very soon). The China teams will still focus on Neutron, Nova, Cinder, Heat, Magnum, Rally, Ironic, Dragonflow and Watcher, etc. projects, so need developers to join and fix bugs as many as possible, and cores to be on site to moderate the code changes and merges. Welcome to the smash mash at Hangzhou - http://www.chinahighlights.com/hangzhou/attraction/. Good news is still that for the first two cores who are from those above projects and respond to this invitation in my email inbox and copy the CC list, the sponsors are pleased to sponsor your international travel, including flight and hotel. Please simply reply to me. Best regards, -- China OpenStack Bug Smash Team __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] RESEND: Invitation to join Hangzhou Bug Smash
Sorry I had a wrong person on the CC list, so resend. Hi, OpenStackers, As you know, Huawei, Intel and CESI are hosting the 4th China OpenStack Bug Smash at Hangzhou, China. The 1st China Bug Smash was at Shanghai, the 2nd was at Xi'an, and the 3rd was at Chengdu. We are constructing the etherpad page for registration, and the date will be around July 11 (probably July 6 - 8, but to be determined very soon). The China teams will still focus on Neutron, Nova, Cinder, Heat, Magnum, Rally, Ironic, Dragonflow and Watcher, etc. projects, so need developers to join and fix bugs as many as possible, and cores to be on site to moderate the code changes and merges. Welcome to the smash mash at Hangzhou - http://www.chinahighlights.com/hangzhou/attraction/. Good news is still that for the first two cores who are from those above projects and respond to this invitation in my email inbox and copy the CC list, the sponsors are pleased to sponsor your international travel, including flight and hotel. Please simply reply to me. Best regards, -- China OpenStack Bug Smash Team __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Invitation to join Hangzhou Bug Smash
Hi, OpenStackers, As you know, Huawei, Intel and CESI are hosting the 4th China OpenStack Bug Smash at Hangzhou, China. The 1st China Bug Smash was at Shanghai, the 2nd was at Xi'an, and the 3rd was at Chengdu. We are constructing the etherpad page for registration, and the date will be around July 11 (probably July 6 - 8, but to be determined very soon). The China teams will still focus on Neutron, Nova, Cinder, Heat, Magnum, Rally, Ironic, Dragonflow and Watcher, etc. projects, so need developers to join and fix bugs as many as possible, and cores to be on site to moderate the code changes and merges. Welcome to the smash mash at Hangzhou - http://www.chinahighlights.com/hangzhou/attraction/. Good news is still that for the first two cores who are from those above projects and respond to this invitation in my email inbox and copy the CC list, the sponsors are pleased to sponsor your international travel, including flight and hotel. Please simply reply to me. Best regards, -- China OpenStack Bug Smash Team __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka
Typo: view -> review:) From: Wang, Shane Sent: Saturday, March 05, 2016 2:09 PM To: OpenStack Development Mailing List (not for usage questions) Subject: RE: [bug-smash] Global OpenStack Bug Smash Mitaka A reminder for the community, the bug smashes are going to start next Monday, if you can't join those 11 sites, you can do virtual bug smash remotely by fixing the bugs in your offices. Also, please help do remote view. Thanks. Best Regards. -- Shane From: Wang, Shane [mailto:shane.w...@intel.com] Sent: Friday, February 05, 2016 11:42 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka Importance: High Hi all, After discussing with TC members and other community guys, we thought March 2-4 might not be a good timing for bug smash. So we decided to change the dates to be March 7 - 9 (Monday - Wednesday) in R4. Please join our efforts to fix bugs for OpenStack. Thanks. -- Shane From: Wang, Shane [mailto:shane.w...@intel.com] Sent: Thursday, January 28, 2016 5:12 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka Save the Date: Global OpenStack Bug Smash Wednesday-Friday, March 7-9, 2016 RSVP by Friday, February 24 How can you help make the OpenStack Mitaka release stable and bug-free while having fun with your peers? Join Intel, Rackspace, Mirantis, IBM, HP, Huawei, CESI and others in a global bug smash across four continents as we work together. Then, join us later in April in Austin, Texas, U.S.A. at the OpenStack Summit to get re-acquainted & celebrate our accomplishments! OUR GOAL Our key goal is to collaborate round-the-clock and around the world to fix as many bugs as possible across the wide range of OpenStack projects. In the process, we'll also help onboard and grow the number of OpenStack developers, and increase our collective knowledge of OpenStack tools and processes. To ease collaboration among all of the participants and ensure that core reviews can be conducted promptly, we will use the IRC channel, the mailing list, and Gerrit and enlist core reviewers in the event. GET INVOLVED Simply choose a place near you-and register by Friday, February 24. Registration is free, and we encourage you to invite others who may be interested. * Australia * China * India * Russia * United Kingdom * United States Visit the link below for additional details: https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka Come make the Mitaka release a grand success through your contributions, and ease the journey for newcomers! Regards. -- OpenStack Bug Smash team __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka
A reminder for the community, the bug smashes are going to start next Monday, if you can't join those 11 sites, you can do virtual bug smash remotely by fixing the bugs in your offices. Also, please help do remote view. Thanks. Best Regards. -- Shane From: Wang, Shane [mailto:shane.w...@intel.com] Sent: Friday, February 05, 2016 11:42 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka Importance: High Hi all, After discussing with TC members and other community guys, we thought March 2-4 might not be a good timing for bug smash. So we decided to change the dates to be March 7 - 9 (Monday - Wednesday) in R4. Please join our efforts to fix bugs for OpenStack. Thanks. -- Shane From: Wang, Shane [mailto:shane.w...@intel.com] Sent: Thursday, January 28, 2016 5:12 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka Save the Date: Global OpenStack Bug Smash Wednesday-Friday, March 7-9, 2016 RSVP by Friday, February 24 How can you help make the OpenStack Mitaka release stable and bug-free while having fun with your peers? Join Intel, Rackspace, Mirantis, IBM, HP, Huawei, CESI and others in a global bug smash across four continents as we work together. Then, join us later in April in Austin, Texas, U.S.A. at the OpenStack Summit to get re-acquainted & celebrate our accomplishments! OUR GOAL Our key goal is to collaborate round-the-clock and around the world to fix as many bugs as possible across the wide range of OpenStack projects. In the process, we'll also help onboard and grow the number of OpenStack developers, and increase our collective knowledge of OpenStack tools and processes. To ease collaboration among all of the participants and ensure that core reviews can be conducted promptly, we will use the IRC channel, the mailing list, and Gerrit and enlist core reviewers in the event. GET INVOLVED Simply choose a place near you-and register by Friday, February 24. Registration is free, and we encourage you to invite others who may be interested. * Australia * China * India * Russia * United Kingdom * United States Visit the link below for additional details: https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka Come make the Mitaka release a grand success through your contributions, and ease the journey for newcomers! Regards. -- OpenStack Bug Smash team __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka
Yes, sure, Markus, we are using https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka-Bugs to track. They were edited by those participants to share between different geos. Feel free to let the community know on communication channels, IRC channel (e.g. nova) or mail list. Let's talk via them to concentrate fixing from next Monday to next Wednesday. Thanks. -- Shane -Original Message- From: Markus Zoeller [mailto:mzoel...@de.ibm.com] Sent: Thursday, March 03, 2016 2:09 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka "Wang, Shane" <shane.w...@intel.com> wrote on 02/05/2016 04:42:21 AM: > From: "Wang, Shane" <shane.w...@intel.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Date: 02/05/2016 04:43 AM > Subject: Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka > > Hi all, > > After discussing with TC members and other community guys, we thought > March 2-4 might not be a good timing for bug smash. So we decided to > change the dates to be March 7 ? 9 (Monday ? Wednesday) in R4. > Please join our efforts to fix bugs for OpenStack. > > Thanks. Hi Shane, I'm the bug list maintainer of Nova, is it possible for me to propose a list of bugs which need fixes? Nova (and surely other projects too) would also benefit from: * a cleanup of inconsistencies in bug reports in Launchpad * triaging new bugs in Launchpad * reviews of pushed bug fixes in Gerrit Basically the steps from [1]. As we're heading to the rc phase in a few weeks it would be benefitial to have a lot of eyes on that. References: [1] https://wiki.openstack.org/wiki/BugTriage Regards, Markus Zoeller (markus_z) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka
Hi Robert, Thank you for your offering, it is great to have you in Germany. Best Regards. -- Shane -Original Message- From: Robert Simai [mailto:robert.si...@suse.com] Sent: Friday, February 05, 2016 5:28 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka All, I like to announce that SUSE joins these efforts, we're going to provide rooms in Nuremberg/Germany and have developers from our side available to contribute to the Mitaka bug smash. The etherpad page [1] is updated, the etherpad page for the location [2] is under construction. Hope to see some of you in Nuremberg! [1] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka [2] https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka-Nuremberg -- Thanks, Robert On Friday 05 February 2016, 03:42:21 Wang, Shane <shane.w...@intel.com> wrote: > Hi all, > > After discussing with TC members and other community guys, we thought > March > 2-4 might not be a good timing for bug smash. So we decided to change > the dates to be March 7 - 9 (Monday - Wednesday) in R4. Please join > our efforts to fix bugs for OpenStack. > > Thanks. > -- > Shane > From: Wang, Shane [mailto:shane.w...@intel.com] > Sent: Thursday, January 28, 2016 5:12 PM > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka > > Save the Date: > Global OpenStack Bug Smash > Wednesday-Friday, March 7-9, 2016 > RSVP by Friday, February 24 > > How can you help make the OpenStack Mitaka release stable and bug-free > while having fun with your peers? Join Intel, Rackspace, Mirantis, > IBM, HP, Huawei, CESI and others in a global bug smash across four > continents as we work together. Then, join us later in April in > Austin, Texas, U.S.A. at the OpenStack Summit to get re-acquainted & > celebrate our accomplishments! > > OUR GOAL > Our key goal is to collaborate round-the-clock and around the world to > fix as many bugs as possible across the wide range of OpenStack > projects. In the process, we'll also help onboard and grow the number > of OpenStack developers, and increase our collective knowledge of > OpenStack tools and processes. To ease collaboration among all of the > participants and ensure that core reviews can be conducted promptly, > we will use the IRC channel, the mailing list, and Gerrit and enlist core > reviewers in the event. > > GET INVOLVED > Simply choose a place near you-and register by Friday, February 24. > Registration is free, and we encourage you to invite others who may be > interested. > > * Australia > * China > * India > > * Russia > * United Kingdom > * United States > > > Visit the link below for additional details: > https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka > > Come make the Mitaka release a grand success through your > contributions, and ease the journey for newcomers! > > Regards. > -- > OpenStack Bug Smash team __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka
Hi Jeremy, You are over worried about the new contributors. We are going to limit the number of attendees, and from my experience and knowledge, most of developers who join bug smash are old and experienced OpenStack developers, and they already have ATC codes. On the other hand, if those events don't exist, you are not able to stop new contributors from submitting and merging individual patches or fixes. You might set a deadline of sending the ATC codes - say some Release Candidate. Regards. -- Shane -Original Message- From: Jeremy Stanley [mailto:fu...@yuggoth.org] Sent: Saturday, February 06, 2016 5:25 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka On 2016-02-05 03:42:21 + (+), Wang, Shane wrote: > After discussing with TC members and other community guys, we thought > March 2-4 might not be a good timing for bug smash. So we decided to > change the dates to be March 7 - 9 (Monday - Wednesday) in R4. Please > join our efforts to fix bugs for OpenStack. It's worth pointing out that this puts the event well after Mitaka feature freeze, which is traditionally when we stop sending Summit registration discount codes to new contributors to the release. Presumably that's not anyone's reason for participating in such an event, but just wanted to clarify it's my understanding that our conference organizers aren't prepared for the logistical challenges of generating extra codes for Bug Smash participants who haven't otherwise contributed to the release so close to the Summit dates. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka
Hi all, After discussing with TC members and other community guys, we thought March 2-4 might not be a good timing for bug smash. So we decided to change the dates to be March 7 - 9 (Monday - Wednesday) in R4. Please join our efforts to fix bugs for OpenStack. Thanks. -- Shane From: Wang, Shane [mailto:shane.w...@intel.com] Sent: Thursday, January 28, 2016 5:12 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka Save the Date: Global OpenStack Bug Smash Wednesday-Friday, March 7-9, 2016 RSVP by Friday, February 24 How can you help make the OpenStack Mitaka release stable and bug-free while having fun with your peers? Join Intel, Rackspace, Mirantis, IBM, HP, Huawei, CESI and others in a global bug smash across four continents as we work together. Then, join us later in April in Austin, Texas, U.S.A. at the OpenStack Summit to get re-acquainted & celebrate our accomplishments! OUR GOAL Our key goal is to collaborate round-the-clock and around the world to fix as many bugs as possible across the wide range of OpenStack projects. In the process, we'll also help onboard and grow the number of OpenStack developers, and increase our collective knowledge of OpenStack tools and processes. To ease collaboration among all of the participants and ensure that core reviews can be conducted promptly, we will use the IRC channel, the mailing list, and Gerrit and enlist core reviewers in the event. GET INVOLVED Simply choose a place near you-and register by Friday, February 24. Registration is free, and we encourage you to invite others who may be interested. * Australia * China * India * Russia * United Kingdom * United States Visit the link below for additional details: https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka Come make the Mitaka release a grand success through your contributions, and ease the journey for newcomers! Regards. -- OpenStack Bug Smash team __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for papers already closed?
Hope somebody on the website infrastructure can help us. I have one presentation which was filled into the form but not submitted. Best Regards. -- Shane -Original Message- From: Nick Chase [mailto:nch...@mirantis.com] Sent: Monday, February 01, 2016 4:09 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Call for papers already closed? It's definitely broken. We're getting the same messages for people who haven't submittted ANY talks. That said, the 3 proposal limit is NOT just for speakers, but also for SUBMITTERS. So be prepared, unless they broke it trying to change that, your colleagues are going to have to submit their own when it comes back up. - Nick On 2/1/2016 2:43 AM, Christian Berendt wrote: > Hello. > > I am a little bit confused, according to openstack.org: > > FEBRUARY 1 IS THE DEADLINE TO SUBMIT A TALK (11:59PM PST) > > I tried to edit a submitted talk and got the following message: > > Call for speaker closed! > > Also I have the following note in my interface: > > Warning! You reached presentations submissions limit (3). > > Is it not possible to submit more than 3 talks? Anyway, at the moment > I only have 2 talks (1 submitted be my, 1 submitted by a other > person). I am submitting the talks for all of my colleagues and we > prepared more than 3 talks. > > Christian. > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for papers already closed?
Yes, I was confused too. The time is yet up. -- Shane -Original Message- From: Christian Berendt [mailto:christ...@berendt.io] Sent: Sunday, January 31, 2016 11:43 PM To: OpenStack Development Mailing List Subject: [openstack-dev] Call for papers already closed? Hello. I am a little bit confused, according to openstack.org: FEBRUARY 1 IS THE DEADLINE TO SUBMIT A TALK (11:59PM PST) I tried to edit a submitted talk and got the following message: Call for speaker closed! Also I have the following note in my interface: Warning! You reached presentations submissions limit (3). Is it not possible to submit more than 3 talks? Anyway, at the moment I only have 2 talks (1 submitted be my, 1 submitted by a other person). I am submitting the talks for all of my colleagues and we prepared more than 3 talks. Christian. -- Christian Berendt Cloud Solution Architect Mail: bere...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka
Save the Date: Global OpenStack Bug Smash Wednesday-Friday, March 2-4, 2016 RSVP by Friday, February 19 How can you help make the OpenStack Mitaka release stable and bug-free while having fun with your peers? Join Intel, Rackspace, Mirantis, IBM, HP, Huawei, CESI and others in a global bug smash across four continents as we work together. Then, join us later in April in Austin, Texas, U.S.A. at the OpenStack Summit to get re-acquainted & celebrate our accomplishments! OUR GOAL Our key goal is to collaborate round-the-clock and around the world to fix as many bugs as possible across the wide range of OpenStack projects. In the process, we'll also help onboard and grow the number of OpenStack developers, and increase our collective knowledge of OpenStack tools and processes. To ease collaboration among all of the participants and ensure that core reviews can be conducted promptly, we will use the IRC channel, the mailing list, and Gerrit and enlist core reviewers in the event. GET INVOLVED Simply choose a place near you-and register by Friday, February 19. Registration is free, and we encourage you to invite others who may be interested. * Australia * China * India * Russia * United Kingdom * United States Visit the link below for additional details: https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka Come make the Mitaka release a grand success through your contributions, and ease the journey for newcomers! Regards. -- OpenStack Bug Smash team __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] hackathon day
Hi Rosa, I am one of the organizers of China Hackathons. I think it is a good idea to host a Hackathon in Europe right after the mid-cycle meetup. However, I suggest to allow more days instead of only 1 to fix bugs, or you have to get well prepared, because fixing bugs is about reproducing, fixing and reviewing - not that easy. When we did Hackathon in August, we had half a day to share techniques like meetups. So possibly you can combine mid-cycle meetup with hackathon, which is really a good idea to save the cost. Also I would like to tell that the core invitation is one of the key aspects to make the event succeed. Because the event will definitely attracts many developers, new or old, and you will have many fixes, it needs more cores to spend the bandwidth reviewing those fixes within 1-2 days. Best Regards. -- Shane -Original Message- From: Rosa, Andrea (HP Cloud Services) [mailto:andrea.r...@hpe.com] Sent: Thursday, November 12, 2015 7:15 PM To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org) Subject: [openstack-dev] [nova] hackathon day Hi I knew that people in China had a 3 days hackathon few months ago I was thinking to have a similar thing in Europe. My original idea was to propose to add an extra day after the mid-cycle but I am not sure if that is a good idea anymore: CONS: - the next mid-cycle is going to be the first one outside USA and as for any new things it has some level of uncertainty, we know that we could have a less participant than the other meetups, so it is a risk to add the hackathon at this time - probably it is better to have more than one day for getting the most out of an hackathon event - ppl attending the hackathon are not necessarily the same person attending a mid-cycle event, I think at the hackathon as a very good opportunity for new contributors - it is already late for this proposal, I know I had to propose it at the last summit, my fault PROS: - having the hackathon following the mid-cycle gives us the opportunity to have more core reviewers available, which is a key point for getting right directions and stuff done - cost effective: ppl interested in attending both events can save a travel It'd be good to have a feedback about the Chinese hackathon experience to understand if it's worth to put effort in making a similar event in other part of the world. If it's not the mid-cycle I think there are other events where it could be good to have a couple of extra days for the hackathon, I am thinking for example at Fosdem [1]... well not for 2016 as it is on the week-end after the mid-cycle :) Thanks -- Andrea Rosa [1] https://fosdem.org/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] hackathon day
Open the mid-cycle one day ahead, feasible? -Original Message- From: Daniel P. Berrange [mailto:berra...@redhat.com] Sent: Thursday, November 12, 2015 10:25 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] hackathon day On Thu, Nov 12, 2015 at 11:15:09AM +, Rosa, Andrea (HP Cloud Services) wrote: > Hi > > I knew that people in China had a 3 days hackathon few months ago I was > thinking to have a similar thing in Europe. > My original idea was to propose to add an extra day after the mid-cycle but I > am not sure if that is a good idea anymore: The day after the mid-cycle is the main day for travelling to FOSDEM, so a bad choice for people who want to attend FOSDEM too. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] hackathon day
Hey, how about driving a Hackathon on the same dates in 3 geos right before release? Who are interested in? Best Regards. -- Shane -Original Message- From: Wang, Shane [mailto:shane.w...@intel.com] Sent: Thursday, November 12, 2015 11:03 PM To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] hackathon day Open the mid-cycle one day ahead, feasible? -Original Message- From: Daniel P. Berrange [mailto:berra...@redhat.com] Sent: Thursday, November 12, 2015 10:25 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] hackathon day On Thu, Nov 12, 2015 at 11:15:09AM +, Rosa, Andrea (HP Cloud Services) wrote: > Hi > > I knew that people in China had a 3 days hackathon few months ago I was > thinking to have a similar thing in Europe. > My original idea was to propose to add an extra day after the mid-cycle but I > am not sure if that is a good idea anymore: The day after the mid-cycle is the main day for travelling to FOSDEM, so a bad choice for people who want to attend FOSDEM too. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][infra][third-party] Intel actively seeking solution to CI issue and getting close to a solution
Yes, Anita. We are seeking the alternatives to fix it and hope the CIs can be recovered very soon. Also please allow me to explain a little bit, we shut down the service without any email notification, but update the wiki (https://wiki.openstack.org/wiki/ThirdPartySystems/Intel-PCI-CI) only according to the suggestion from the Infra team. [09:18:52] anteaya then if anyone wonders what is happening with your system they check the status page [09:18:52] anteaya does that make sense? [09:19:13] anteaya correct [09:19:23] anteaya anytime you need to change the status of your ci [09:19:37] jyuso1 OK,thanks.I [09:19:37] anteaya change it here [09:19:45] jyuso1 I'll change it soon [09:19:49] anteaya and please don't send an email to the mailing list, people won't read it anyway We're going to make the CIs more stable in the future, and in case that any issue happened unexpectedly, we will let the community know. Sorry for inconvenience and thank you for your understanding. Best Regards. -- Shane -Original Message- From: Anita Kuno [mailto:ante...@anteaya.info] Sent: Thursday, July 16, 2015 10:34 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova][infra][third-party] Intel actively seeking solution to CI issue and getting close to a solution On 07/15/2015 10:19 PM, yongli he wrote: Hello OpenStackers! The Intel PCI/SRIOV/NGFW/PTAS CI located in China, due to reasons beyond our control, lost connectivity to the Jenkins servers. The great firewall of China is making quite a few folks unhappy. Although the CI system is working fine we haven't been able to report results back for about a month now. We are actively looking for a solution to this problem. Currently we are seeking a VM in AWS or similar public cloud to hold our CI logs, Have you taken a look at any of the fine offerings from companies who operate OpenStack public clouds? http://www.openstack.org/marketplace/public-clouds/ which will quickly give us a short term solution. For a longer term solution we are exploring moving to machines located in the US. Sorry for the inconvenience and your patience. Regards Yongli Thanks Yongli, Anita. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] How to properly detect and fence a compromised host (and why I dislike TrustedFilter)
AFAIK, TrustedFilter is using a sort of cache to cache the trusted state, which is designed to solve the performance issue mentioned here. My thoughts for deprecating it are: #1. We already have customers here in China who are using that filter. How are they going to do upgrade in the future? #2. Dependency should not be a reason to deprecate a module in OpenStack, Nova is not a stand-alone module, and it depends on various technologies and libraries. Intel is setting up the third party CI for TCP/OAT in Liberty, which is to address the concerns mentioned in the thread. And also, OAT is an open source project which is being maintained as the long-term strategy. For the situation that a host gets compromised, OAT checks trusted or untrusted from the start point of boot/reboot, it is hard for OAT to detect whether a host gets compromised when it is running, I don't know how to detect that without the filter? Back to Michael's question, the process of the verification is done by software automatically when a host boots or reboots, will that be an overhead for the admin to have a separate job? Thanks. -- Shane -Original Message- From: Michael Still [mailto:mi...@stillhq.com] Sent: Wednesday, June 24, 2015 7:49 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] How to properly detect and fence a compromised host (and why I dislike TrustedFilter) I agree. I feel like this is another example of functionality which is trivially implemented outside nova, and where it works much better if we don't do it. Couldn't an admin just have a cron job which verifies hosts, and then adds them to a compromised-hosts host aggregate if they're owned? I assume without testing it that you can migrate instances _out_ of a host aggregate you can't boot in? Michael On Tue, Jun 23, 2015 at 8:41 PM, Sylvain Bauza sba...@redhat.com wrote: Hi team, Some discussion occurred over IRC about a bug which was publicly open related to TrustedFilter [1] I want to take the opportunity for raising my concerns about that specific filter, why I dislike it and how I think we could improve the situation - and clarify everyone's thoughts) The current situation is that way : Nova only checks if one host is compromised only when the scheduler is called, ie. only when booting/migrating/evacuating/unshelving an instance (well, not exactly all the evacuate/live-migrate cases, but let's not discuss about that now). When the request goes in the scheduler, all the hosts are checked against all the enabled filters and the TrustedFilter is making an external HTTP(S) call to the Attestation API service (not handled by Nova) for *each host* to see if the host is valid (not compromised) or not. To be clear, that's the only in-tree scheduler filter which explicitly does an external call to a separate service that Nova is not managing. I can see at least 3 reasons for thinking about why it's bad : #1 : that's a terrible bottleneck for performance, because we're IO-blocking N times given N hosts (we're even not multiplexing the HTTP requests) #2 : all the filters are checking an internal Nova state for the host (called HostState) but that the TrustedFilter, which means that conceptually we defer the decision to a 3rd-party engine #3 : that Attestation API services becomes a de facto dependency for Nova (since it's an in-tree filter) while it's not listed as a dependency and thus not gated. All of these reasons could be acceptable if that would cover the exposed usecase given in [1] (ie. I want to make sure that if my host gets compromised, my instances will not be running on that host) but that just doesn't work, due to the situation I mentioned above. So, given that, here are my thoughts : a/ if a host gets compromised, we can just disable its service to prevent its election as a valid destination host. There is no need for a specialised filter. b/ if a host is compromised, we can assume that the instances have to resurrect elsewhere, ie. we can call a nova evacuate c/ checking if an host is compromised or not is not a Nova responsibility since it's already perfectly done by [2] In other words, I'm considering that security usecase as something analog as the HA usecase [3] where we need a 3rd-party tool responsible for periodically checking the state of the hosts, and if compromised then call the Nova API for fencing the host and evacuating the compromised instances. Given that, I'm proposing to deprecate TrustedFilter and explictly mention to drop it from in-tree in a later cycle https://review.openstack.org/194592 Thoughts ? -Sylvain [1] https://bugs.launchpad.net/nova/+bug/1456228 [2] https://github.com/OpenAttestation/OpenAttestation [3] http://blog.russellbryant.net/2014/10/15/openstack-instance-ha-proposa l/
Re: [openstack-dev] [nova] Dynamic scheduling
Ditto, I am also interested in that area. We're implementing a framework to monitor different metrics from Ceilometer, apply predefined policies from administrators, and take actions if some conditions are met for resource optimization purpose or SLA purpose. Jay, is IBM PRS open source? Thanks. -- Shane From: Susanne Balle [mailto:sleipnir...@gmail.com] Sent: Thursday, April 10, 2014 12:57 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova] Dynamic scheduling Ditto. I am interested in contributing as well. Does Gant work with Devstack? I am assuming the link will give me directions on how to test it and contribute to the project. Susanne On Wed, Apr 9, 2014 at 12:44 PM, Henrique Truta henriquecostatr...@gmail.commailto:henriquecostatr...@gmail.com wrote: @Oleg, @Sylvain, @Leandro, Thanls. I'll check the Gantt project and the blueprint 2014-04-09 12:59 GMT-03:00 Sylvain Bauza sylvain.ba...@gmail.commailto:sylvain.ba...@gmail.com: 2014-04-09 17:47 GMT+02:00 Jay Lau jay.lau@gmail.commailto:jay.lau@gmail.com: @Oleg, Till now, I'm not sure the target of Gantt, is it for initial placement policy or run time policy or both, can you help clarify? I don't want to talk on behalf of Oleg, but Gantt is targeted to be the forklift of the current Nova scheduler. So, a placement decision based on dynamic metrics would be worth it. That said, as Gantt is not targeted to be delivered until Juno at least (with Nova sched deprecated), I think any progress on a BP should target Nova with respect to the forklift efforts, so it would automatically be ported to Gantt once the actual fork would happen. -Sylvain Jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -- Ítalo Henrique Costa Truta ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Detect changes in object model
Hi Dan, are you going to cook a patch to expand the base class? Or we can do that ourselves? For the list, I also agree your dirty assumption. -- Shane -Original Message- From: Dan Smith [mailto:d...@danplanet.com] Sent: Friday, January 10, 2014 10:42 PM To: Wang, Shane; OpenStack Development Mailing List (not for usage questions) Cc: pmur...@hp.com; alex...@hp.com; Tan, Lin Subject: Re: [Nova] Detect changes in object model If an object A contains another object or object list (called sub-object), any change happened in the sub-object can't be detected by obj_what_changed() in object A. Well, like the Instance object does, you can override obj_what_changed() to expose that fact to the caller. However, I think it might be good to expand the base class to check, for any NovaObject fields, for the obj_what_changed() of the child. How does that sound? --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] Detect changes in object model
Hi Dan, There is a discussion in https://review.openstack.org/#/c/58199/ talking about the change detection in objects. If an object A contains another object or object list (called sub-object), any change happened in the sub-object can't be detected by obj_what_changed() in object A. A generic method might be to change make_class_properties() to add it into _changed_fields() for object A, even though any properties in the sub-object are changed. So save() in object A can get the correct obj_get_changes() before updating the db. However, in save() in instance.py (line 450), we found a set of special _save_%s() would be called to update those objects always, no matter whether they are changed or not. I am going to do the more generic way above. May I? What do you think on that? Thanks. -- Shane ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime
Lianhao Lu, Shuangtai Tian and I are also willing to join the team to contribute because we are also changing scheduler, but it seems the team is full. You can put us to the backup list. Thanks. -- Shane -Original Message- From: Robert Collins [mailto:robe...@robertcollins.net] Sent: Friday, November 22, 2013 4:59 AM To: OpenStack Development Mailing List Subject: [openstack-dev] [Nova][Schduler] Volunteers wanted for a modest proposal for an external scheduler in our lifetime https://etherpad.openstack.org/p/icehouse-external-scheduler I'm looking for 4-5 folk who have: - modest Nova skills - time to follow a fairly mechanical (but careful and detailed work needed) plan to break the status quo around scheduler extraction And of course, discussion galore about the idea :) Cheers, Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Help to review UBS patch
Hi stackers, From the design summit, Boris has a great idea to improve db performance but needs more evaluation because of memcached. For UBS, it seems we agree to go with the current solution and don't depend on Boris's great idea. Can someone help to review the ground work of UBS https://review.openstack.org/#/c/35759/? It has got 1 approval but needs 1 more. Again, for the other 2 patches depending on it, https://review.openstack.org/#/c/35764/ (already got 2 approvals) and https://review.openstack.org/#/c/35765/, we will rebase to the latest master after the ground work is merged. Thanks, due to time zone issue in China, I choose to send a junk mail instead of ping nobody in IRC, sorry for that;-) Thanks. -- Shane ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Help to review UBS patch
Hi stackers, From the design summit, Boris has a great idea to improve db performance but needs more evaluation because of memcached. For UBS, it seems we agree to go with the current solution and don't depend on Boris's great idea. Can someone help to review the ground work of UBS https://review.openstack.org/#/c/35759/? It has got 1 approval but needs 1 more. Again, for the other 2 patches depending on it, https://review.openstack.org/#/c/35764/ (already got 2 approvals) and https://review.openstack.org/#/c/35765/, we will rebase to the latest master after the ground work is merged. Thanks, due to time zone issue in China, I choose to send a junk mail instead of ping nobody in IRC, sorry for that;-) Thanks. -- Shane ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Frustrations with review wait times
Definitely, +1 ;-) -- Shane From: Joe Gordon [mailto:joe.gord...@gmail.com] Sent: Tuesday, August 27, 2013 11:40 PM To: Daniel P. Berrange; OpenStack Development Mailing List Subject: Re: [openstack-dev] [Nova] Frustrations with review wait times On Tue, Aug 27, 2013 at 11:04 AM, Daniel P. Berrange berra...@redhat.commailto:berra...@redhat.com wrote: On Tue, Aug 27, 2013 at 10:55:03AM -0400, Russell Bryant wrote: On 08/27/2013 10:43 AM, Daniel P. Berrange wrote: I tend to focus the bulk of my review activity on the libvirt driver, since that's where most of my knowledge is. I've recently done some reviews outside this area to help reduce our backlog, but I'm not so comfortable approving stuff in many of the general infrastructure shared areas since I've not done much work on those areas of code. I think Nova is large enough that it (mostly) beyond the scope of any one person to know all areas of Nova code well enough todo quality reviews. IOW, as we grow the nova-core team further, it may be worth adding more reviewers who have strong knowledge of specific areas can focus their review energy in those areas, even if their review count will be low when put in the context of nova as a whole. I'm certainly open to that. Another way I try to do this unofficially is give certain +1s a whole lot of weight when I'm looking at a patch. I do this regularly when looking over patches to hypervisor drivers I'm not very familiar with. Another thing we could consider is take this approach more officially. Oslo has started doing this for its incubator. A maintainer of a part of the code not on oslo-core has their +1 treated as a +2 on that code. http://git.openstack.org/cgit/openstack/oslo-incubator/tree/MAINTAINERS Yes, just having a list of expert maintainers for each area of Nova would certainly be helpful in identifying whose comments to place more weight by, regardless of anything else we might do. I think we can dynamically generate this based on git log/blame and gerrit statistics per file. For example if someone has authored half the lines in a file or reviewed most of the patches that touched that file, they are probably are very familiar with the file and would be a good person to review any change. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova] Requesting feedback on review 35759
Hi, We submitted the patches for bp https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling 1+ month ago. The first patch is to add a column to save metrics collected by plugins - https://review.openstack.org/#/c/35759/. Is there anyone who is interested in that, would it be possible to get some reviews for that? Thanks. -- Shane ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Monitoring plugin file names
I prefer nova/compute/plugins/virt/libvirt, because I think a plugin might not call libvirt or any virt driver. By the way, can nova core or those who are interested in the bp review our patch sets at https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/ubs,n,z? Thanks. -- Shane From: Gary Kotton [mailto:gkot...@vmware.com] Sent: Sunday, August 04, 2013 1:41 AM To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org) Subject: [openstack-dev] [Nova] Monitoring plugin file names Hi, As part of the BP blueprint utilization-aware-schedulinghttps://blueprints.launchpad.net/openstack/?searchtext=utilization-aware-scheduling a plugin has been added. I have an issue with the placement of the drivers (the code is looking good:)) and would like to know what the community thinks. Here are a few examples: 1. https://review.openstack.org/#/c/35760/17 - a new file has been added - nova/compute/plugins/libvirt_cpu_monitor_plugin.pyhttps://review.openstack.org/#/c/35760/17/nova/compute/plugins/libvirt_cpu_monitor_plugin.py 2. https://review.openstack.org/#/c/39190/ - a new file has been added - nova/compute/plugins/libvirt_memory_monitor_plugin.pyhttps://review.openstack.org/#/c/39190/1/nova/compute/plugins/libvirt_memory_monitor_plugin.py I think that these monitoring plugins should either reside in the directory nova/virt/libvirt/plugins or nova/compute/pluginshttps://review.openstack.org/#/c/39190/1/nova/compute/plugins/libvirt_memory_monitor_plugin.py/virt/libvirt. It would be interesting to know what others think. Thanks Gary ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] A simple way to improve nova scheduler
Thank you for your comments and questions, Boris. We will test it asap and get back to you. Thanks. -- Shane From: Boris Pavlovic [mailto:bo...@pavlovic.me] Sent: Wednesday, July 31, 2013 7:00 PM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] A simple way to improve nova scheduler Hi Shane, Thanks for implementing this one new approach. Yes, I agree that it solves problems with JOIN. But now I am worry about new problem db.compute_node_update() that changes every time field with TEXT type which means that this should work really slow. So I have some question about testing time, did you test just joins or joins with parallel N/60 updates/sec of compute_node_update() calls? Also we will need Russell confirmation to merge such a big change right before release. Russell what do you think? From what I know since we don't have a clear solution for this issue community agreed that it would be discussed on the coming summit. Best regards, Boris Pavlovic -- Mirantis Inc. On Wed, Jul 31, 2013 at 9:36 AM, Wang, Shane shane.w...@intel.commailto:shane.w...@intel.com wrote: Hi, I have a patchset ready for your review https://review.openstack.org/#/c/38802/ This patchset is to remove table compute_node_stats and add one more column stats in table compute_nodes as JSON dict. With that, compute_node_get_all() doesn't need to join another table when nova schedulers call it. My team has done some preliminary tests. The performance could be reduced to ~1.32 seconds from ~16.89 seconds, where we suppose there are 10K compute nodes and each node has 20 stats records in compute_node_stats. Thank you for your review, and what do you think? Thanks. -- Shane From: Joshua Harlow [mailto:harlo...@yahoo-inc.commailto:harlo...@yahoo-inc.com] Sent: Thursday, July 25, 2013 5:36 AM To: OpenStack Development Mailing List; Boris Pavlovic Subject: Re: [openstack-dev] A simple way to improve nova scheduler As far as the send only when you have to. That reminds me of this piece of work that could be resurrected that slowed down the periodic updates when nothing was changing. https://review.openstack.org/#/c/26291/ Could be brought back, the concept still feels useful imho. But maybe not to others :-P From: Boris Pavlovic bo...@pavlovic.memailto:bo...@pavlovic.me Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, July 24, 2013 12:12 PM To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] A simple way to improve nova scheduler Hi Mike, On Wed, Jul 24, 2013 at 1:01 AM, Mike Wilson geekinu...@gmail.commailto:geekinu...@gmail.com wrote: Again I can only speak for qpid, but it's not really a big load on the qpidd server itself. I think the issue is that the updates come in serially into each scheduler that you have running. We don't process those quickly enough for it to do any good, which is why the lookup from db. You can see this for yourself using the fake hypervisor, launch yourself a bunch of simulated nova-compute, launch a nova-scheduler on the same host and even with 1k or so you will notice the latency between the update being sent and the update actually meaning anything for the scheduler. I think a few points that have been brought up could mitigate this quite a bit. My personal view is the following: -Only update when you have to (ie. 10k nodes all sending update every periodic interval is heavy, only send when you have to) -Don't fanout to schedulers, update a single scheduler which in turn updates a shared store that is fast such as memcache I guess that effectively is what you are proposing with the added twist of the shared store. Absolutely agree with this. Especially with using memcached (or redis) as common storage for all schedulers. Best regards, Boris Pavlovic --- Mirantis Inc. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling
Sandy Walsh wrote on 2013-07-19: On 07/19/2013 09:47 AM, Day, Phil wrote: -Original Message- From: Sean Dague [mailto:s...@dague.net] Sent: 19 July 2013 12:04 To: OpenStack Development Mailing List Subject: Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduling (was: New DB column or new DB table?) On 07/19/2013 06:18 AM, Day, Phil wrote: Ceilometer is a great project for taking metrics available in Nova and other systems and making them available for use by Operations, Billing, Monitoring, etc - and clearly we should try and avoid having multiple collectors of the same data. But making the Nova scheduler dependent on Ceilometer seems to be the wrong way round to me - scheduling is such a fundamental operation that I want Nova to be self sufficient in this regard. In particular I don't want the availability of my core compute platform to be constrained by the availability of my (still evolving) monitoring system. If Ceilometer can be fed from the data used by the Nova scheduler then that's a good plus - but not the other way round. I assume it would gracefully degrade to the existing static allocators if something went wrong. If not, well that would be very bad. Ceilometer is an integrated project in Havana. Utilization based scheduling would be a new feature. I'm not sure why we think that duplicating the metrics collectors in new code would be less buggy than working with Ceilometer. Nova depends on external projects all the time. If we have a concern about robustness here, we should be working as an overall project to address that. -Sean Just to be cleat its about a lot more than just robustness in the code - its the whole architectural pattern of putting Ceilometer at the centre of Nova scheduling that concerns me. As I understand it Celiometer can collect metrics from more than one copy of Nova - which is good; I want to run multiple independent copies in different regions and I want to have all of my monitoring data going back to one place. However that doesn't mean that I now also want all of those independent copies of Nova depending on that central monitoring infrastructure for something as basic as scheduling. (I don't want to stop anyone that does either - but I don't see why I should be forced down that route). The original change that sparked this debate came not from anything to do with utilisation based scheduling, but the pretty basic and simple desire to add new types of consumable resource counters into the scheduler logic in a more general way that having to make a DB schema change. This was generally agreed to be a good thing, and it pains me to see that valuable work now blocked on what seems to be turning into an strategic discussion around the role of Ceilometer (Is it a monitoring tool or a fundamental metric bus, etc). At the point where Ceilomter can be shown to replace the current scheduler resource mgmt code in Nova, then we should be talking about switching to it - but in the meantime why can't we continue to have incremental improvements in the current Nova code ? +1 +1 We can keep discussion to determine RR for Nova and Ceilometer. Can we have a decision to make so we can move forward to have incremental improvements in Nova? Thanks. -- Shane Cheers Phil ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] New DB column or new DB table?
Daniel raised a good point, I also agreed that is not a good architecture. Nova can't touch any monitoring stuffs - I don't think that is good. At least, Ceilometer can be a monitoring hub for external utilities. On the other hand, for the options Lianhao raised. Is a query on a DB and a json column faster than the one on two-DB join? I have no experimental data but I doubt it. Thanks. -- Shane Dan Smith wrote on 2013-07-20: IIUC, Ceilometer is currently a downstream consumer of data from Nova, but no functionality in Nova is a consumer of data from Ceilometer. This is good split from a security separation point of view, since the security of Nova is self-contained in this architecture. If Nova schedular becomes dependant on data from ceilometer, then now the security of Nova depends on the security of Ceilometer, expanding the attack surface. This is not good architecture IMHO. Agreed. At the same time, I hear your concerns about the potential for duplication of stats collection functionality between Nova Ceilometer. I don't think we neccessarily need to remove 100% of duplication. IMHO probably the key thing is for the virt drivers to expose a standard API for exporting the stats, and make sure that both ceilometer nova schedular use the same APIs and ideally the same data feed, so we're not invoking the same APIs twice to get the same data. I imagine there's quite a bit that could be shared, without dependency between the two. Interfaces out of the virt drivers may be one, and the code that boils numbers into useful values, as well as perhaps the format of the JSON blobs that are getting shoved into the database. Perhaps a ceilo-core library with some very simple primitives and definitions could be carved out, which both nova and ceilometer could import for consistency, without a runtime dependency? --Dan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] A DB question for UniqueName/Event/Trait
Hi I am looking at ceilometer DB code. I find there are 3 tables (UniqueName, Event, Trait), and in Trait, the two columns name_id and event_id refer to table UniqueName and table Event. My question is why we need UniqueName and Event, because in both tables there are no many other columns, so why not fill unique_name into Trait directly. Thanks in advance. -- Shane ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] XML Support for Nova v3 API
+1 for that. If needed, some tools/languages could help to do XML transformation, regarding different XML schemas. I also agree with Hellmann that we shouldn't invent something new or a fixed schema for that. XML is flexible for data exchange, we can leave those mapping jobs to those XML transformation tools/languages, and focus on the current JSON work. Thanks. -- Shane -Original Message- From: Sean Dague [mailto:s...@dague.net] Sent: Friday, June 21, 2013 4:02 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] XML Support for Nova v3 API There are lots of nice things we could do, given time and people. But the reality is that relatively few people are actually working on the API code, documentation, tooling around it. I would much rather have us deliver a world class JSON API with validation and schema and comprehensive testing, than the current state of our JSON + XML approach which is poorly documented and only partially tested. -Sean On 06/20/2013 01:08 PM, John Garbutt wrote: We spoke about some nice validation frameworks at the summit, and here and there. Could we get away with XML-JSON then validate the JSON request (and assume XML parse error also means bad request)? John On 20 June 2013 17:44, Russell Bryant rbry...@redhat.com wrote: On 06/20/2013 12:00 PM, Thierry Carrez wrote: Christopher Yeoh wrote: Just wondering what people thought about how necessary it is to keep XML support for the Nova v3 API, given that if we want to drop it doing so during the v2-v3 transition is pretty much the ideal time to do so. Although I hate XML as much as anyone else, I think it would be interesting to raise that question on the general user mailing-list. We have been discussing that in the past, and while there was mostly consensus against XML (in OpenStack API) on the development list, when the issue was raised with users, in the end they made up a sufficiently-good rationale for us to keep it in past versions of the API :) Yes, and I suspect we'd arrive the same result again. I'd rather hear ideas for things that would make it easier to support both. The window is open for changes to make that easier. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Efficiently pin running VMs to physical CPUs automatically
Very glad to see that, too. We also have some thoughts to look at the usage of CPU resources (like cache) for each VM, and adjust to aggregate and bind VMs to physical CPUs for QoS. Look forward to seeing the initiatives proposed below to move forward. Thanks. -- Shane -Original Message- From: Qing He [mailto:qing...@radisys.com] Sent: Saturday, June 22, 2013 2:11 AM To: OpenStack Development Mailing List Subject: Re: [openstack-dev] Efficiently pin running VMs to physical CPUs automatically Russell, That's great initiative! I'm wondering if a framework/abstraction layer can be built so that different algorithms can be plugged in. I'm sure we can learn from the none-vm world: http://en.wikipedia.org/wiki/Processor_affinity Thanks, Qing -Original Message- From: Russell Bryant [mailto:rbry...@redhat.com] Sent: 20 June 2013 17:48 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Efficiently pin running VMs to physical CPUs automatically On 06/20/2013 10:36 AM, Giorgio Franceschi wrote: Hello, I created a blueprint for the implementation of: A tool for pinning automatically each running virtual CPU to a physical one in the most efficient way, balancing load across sockets/cores and maximizing cache sharing/minimizing cache misses. Ideally able to be run on-demand, as a periodic job, or be triggered by events on the host (vm spawn/destroy). Find it at https://blueprints.launchpad.net/nova/+spec/auto-cpu-pinning Any inputappreciated! I'm actually surprised to see a new tool for this kind of thing. Have you seen numad? -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
