Re: [openstack-dev] [neutron] PTL Non-Candidacy

2015-09-12 Thread Gary Kotton
Thanks! You did a great job. Looking back you made some very tough and healthy decisions. Neutron has a new lease on life! It is tradition that the exiting PTL buy drinks for the community :) From: "mest...@mestery.com"

Re: [openstack-dev] [neutron] PTL Non-Candidacy

2015-09-12 Thread Armando M.
On 12 September 2015 at 18:38, Gary Kotton wrote: > Thanks! You did a great job. Looking back you made some very tough and > healthy decisions. Neutron has a new lease on life! > It is tradition that the exiting PTL buy drinks for the community :) > Ok, none of these kind

Re: [openstack-dev] [neutron] PTL Non-Candidacy

2015-09-12 Thread Shiv Haris
Thanks you very much for the great job you did. Your cool while doing a tough job was noteworthy. You will be missed. -Shiv From: Kyle Mestery > Reply-To: OpenStack List

Re: [openstack-dev] [neutron] PTL Non-Candidacy

2015-09-12 Thread Ben Pfaff
Are you planning to remain involved with OpenStack? On Fri, Sep 11, 2015 at 2:12 PM, Kyle Mestery wrote: > I'm writing to let everyone know that I do not plan to run for Neutron PTL > for a fourth cycle. Being a PTL is a rewarding but difficult job, as Morgan > recently put

[openstack-dev] [kolla] Followup to review in gerrit relating to RHOS + RDO types

2015-09-12 Thread Steven Dake (stdake)
Hey folks, Sam had asked a reasonable set of questions regarding a patchset: https://review.openstack.org/#/c/222893/ The purpose of the patchset is to enable both RDO and RHOS as binary choices on RHEL platforms. I suspect over time, from-source deployments have the potential to become the

Re: [openstack-dev] questions about nova compute monitors extensions

2015-09-12 Thread Joe Cropper
The new framework does indeed support user-defined monitors. You just extend whatever monitor’d like (e.g., nova.compute.monitors.cpu.virt_driver.Monitor) and add your customized logic. And since the new framework uses stevedore-based extension points, you just need to be sure to add the

Re: [openstack-dev] [neutron] PTL Non-Candidacy

2015-09-12 Thread Irena Berezovsky
Kyle, Thank you for the hard work you did making neuron project and neutron community better! You have been open and very supportive as a neutron community lead. Hope you will stay involved. On Fri, Sep 11, 2015 at 11:12 PM, Kyle Mestery wrote: > I'm writing to let

Re: [openstack-dev] [Neutron] Allow for per-subnet dhcp options

2015-09-12 Thread Jonathan Proulx
On Fri, Sep 11, 2015 at 3:43 PM, Kyle Mestery wrote: > On Fri, Sep 11, 2015 at 2:04 PM, Jonathan Proulx wrote: >> >> I'm hurt that this blue print has seen no love in 18 months: >> https://blueprints.launchpad.net/neutron/+spec/dhcp-options-per-subnet >>

Re: [openstack-dev] [neutron] PTL Non-Candidacy

2015-09-12 Thread Gal Sagie
Kyle, Thank you for all the great time as PTL, you set a high bar for the next person. I think the Neutron community was lucky to have you in this position, your devotion and passion to OpenStackt, to Neutron and to Open source is inspiring and one of the reasons i love this community. In my eyes

[openstack-dev] [kolla][ptl] Kolla PTL Candidacy

2015-09-12 Thread Steven Dake (stdake)
My Peers, Liberty for Kolla was fantastically successful! We held our first in person mid-cycle and entered the Big Tent governance process. We successfully released 3 milestone releases within 3 days of deadline with increasing functionality. I believe our Kolla release of rc1 on September

Re: [openstack-dev] 回复: [Ceilometer][Gnocchi] Gnocchi cannot deal with combined resource-id ?

2015-09-12 Thread Julien Danjou
On Sat, Sep 12 2015, Luo Gangyi wrote: > I checked it again, no "ignored" is marked, seems the bug of devstack ;( I was talking about that: https://git.openstack.org/cgit/openstack/ceilometer/tree/etc/ceilometer/gnocchi_resources.yaml#n67 > And it's OK that gnocchi is not perfect now, but

Re: [openstack-dev] [Heat] Integration Test Questions

2015-09-12 Thread Pavlo Shchelokovskyy
Hi Sabeen, thank you for the effort :) More tests is always better than less, but unfortunately we are limited by the power of VM and time available for gate jobs. This is why we do no exhaustive functional testing of all resource plugins APIs, as every time a test goes out and makes an async API